모듈 1 마무리 — 네 가지 기반 점검

Q1동료가 "같은 프롬프트 두 개는 반드시 같은 텍스트를 돌려줘야 한다"고 말합니다. 가장 정확한 답변은 무엇일까요?

샘플링이 생성을 비결정적으로 만듭니다. 그래서 테스트는 정확한 텍스트가 아니라 속성과 의미를 기준으로 판정하게 됩니다. 스트리밍 여부나 모델 크기는 이 성질과 관계가 없습니다.

Q2모델 선택과 추론 모드를 가장 잘 구분한 설명은 무엇일까요?

두 설정은 서로 독립적이면서 함께 쓸 수 있습니다. 어느 모델을 고를지와 확장 사고를 켤지는 별개의 결정입니다.

Q3짧고 명확하게 정의된 분류 과제가 제로샷으로 이미 정답을 돌려줍니다. 여기에 예시 세 개를 더하면 어떻게 될까요?

예시는 출력 구조가 틀릴 때 더하는 것입니다. 제로샷으로 이미 잘 되는 과제라면 예시를 더해도 얻는 것이 거의 없고, 매 호출의 토큰 비용만 늘어나게 됩니다.

Q4수천 건의 입력을 오프라인에서 가장 낮은 비용으로 처리해야 합니다. 어떤 형태가 맞을까요?

배치는 결과를 늦게 받는 대신 토큰당 비용이 낮고, 동기 루프가 부딪히는 호출 한도 문제도 피합니다. 컨텍스트 윈도우 크기는 요청 형태와는 다른 문제입니다.

S1같은 분류 과제를 temperature 0으로 실행할 때와 높은 temperature로 실행할 때, 반복 실행에서 출력이 어떻게 달라질까요?

temperature는 모델이 샘플링하는 확률 분포의 모양을 바꿀 뿐, 출력을 고정하거나 샘플링을 끄지 않습니다. 낮은 temperature는 분포를 좁혀 반복 실행을 훨씬 일관되게 만들고(그래도 동일 출력이 보장되지는 않습니다), 분류기에 필요한 것이 바로 이 동작입니다. 최신 모델에서는 샘플링 파라미터를 아예 생략합니다 — 기본값이 아닌 값을 넣으면 에러가 나고, 반복 가능성은 프롬프트 설계로 관리합니다. temperature를 높이면 분포가 퍼져 라벨과 표현이 달라질 수 있게 됩니다.

S2제로샷 프롬프트에서 출력이 계속 잘못된 구조로 돌아오는 과제가 있습니다. 멀티샷으로 바꾸면 무엇이 달라질까요?

프롬프트 속 예시는 학습이 아니고, 비용을 낮추지도 않습니다. 예시는 프롬프트 안에 남아 정확한 출력 형태를 보여 주고, 호출마다 토큰을 더합니다. 구조가 틀릴 때 멀티샷을 꺼내되, 필요한 최소 개수에서 멈추면 됩니다.

S3기다리는 사용자 없이 문서 5만 건을 밤사이 처리해야 하는 파이프라인이 있습니다. 어떤 요청 형태가 맞고, 이유는 무엇일까요?

요청 형태는 사용자가 기다리고 있는지에 맞춥니다. 지켜보는 사람 없이 수만 건을 처리한다면 Message Batches API가 맞는 자리입니다 — 요청을 한 번에 제출해 두고 완료를 확인하면, 기다림이 길어지는 대신 비용이 내려갑니다. 동기 루프는 이 규모에서 호출 한도에 부딪히고, 스트리밍은 출력이 도착하는 것을 지켜보는 사람이 있을 때만 도움이 됩니다.

S4컨텍스트 윈도우가 계속 차오르는 긴 멀티턴 에이전트 세션이 있습니다. 증상은 무엇이고, 어느 예산이 원인일까요?

컨텍스트 윈도우는 고정 예산입니다. 넘치는 입력은 생성이 시작되기 전에 에러로 거절되고, 생성 도중 한도에 닿으면 응답이 중간에 끊긴 채 중단 사유로 model_context_window_exceeded가 남습니다. 가장 오래된 내용이 조용히 버려지는 일은 없습니다. 증상은 테스트에서 통과하던 세션이 입력과 턴이 늘면서 실패하는 것이고, 그래서 기록 정리는 애플리케이션의 일이 됩니다.