예시 기반 학습 패턴
few-shot은 모델에게 작업 규칙을 말로 설명하는 대신, "입력 → 기대 출력" 예시를 몇 개 보여 패턴을 추론하게 하는 방식이다. Claude API에서 예시는 별도 파라미터가 없다. 예시는 messages 배열 안에서 user 메시지(입력)와 assistant 메시지(모범 답안)를 번갈아 배치해 표현하며, 진짜 질문은 마지막 user 턴에 둔다.
# few_shot_classify.pyresponse = client.messages.create( model="claude-opus-4-8", max_tokens=256, messages=[ {"role": "user", "content": "리뷰: 배송이 느렸어요"}, {"role": "assistant", "content": "부정"}, {"role": "user", "content": "리뷰: 품질이 기대 이상!"}, {"role": "assistant", "content": "긍정"}, {"role": "user", "content": "리뷰: 가격은 적당하네요"}, ],)여기서 중간에 등장하는 assistant 메시지는 모델의 실제 답이 아니라 우리가 손으로 작성한 예시 답안이다. 대화 흐름상 assistant 역할이지만, 이것은 정상적인 few-shot이며 허용된다.
함정은 prefill과의 혼동이다. 마지막 턴을 assistant로 채워 답을 미리 시작하게 하는 prefill은 claude-opus-4-8을 포함한 최신 모델군에서 400 오류를 반환한다. 즉 "중간 assistant 예시는 OK, 끝에 붙는 assistant prefill은 금지"가 핵심 구분이다. 형식을 강제하려고 마지막에 {"role": "assistant", "content": "{"} 같은 prefill을 넣던 습관은 이제 output_config.format(구조화 출력)이나 시스템 프롬프트 지시로 대체해야 한다.
시험은 두 가지를 자주 묻는다. 첫째, 위 예시 코드에서 어떤 메시지가 few-shot 예시이고 무엇이 prefill인지 식별하게 한다. 둘째, prefill이 400을 내는 상황에서 올바른 대안을 고르게 한다.
예시 설계에서 개수보다 중요한 것은 품질·일관성·다양성이다. 모든 예시의 라벨 표기·형식이 일관돼야 모델이 같은 형식으로 답하며, 예시 간 형식이 어긋나면 출력이 흔들린다. 또한 예시가 한쪽 케이스에 치우치면 모델도 편향되므로, 긍정·부정·중립처럼 클래스를 고르게 담고 까다로운 경계 사례를 포함하는 편이 효과적이다. capable 모델일수록 예시 두세 개로 패턴을 잡으므로, 모순되거나 잡음 섞인 예시를 무더기로 넣으면 오히려 품질이 떨어진다.
성능·비용 관점에서 또 하나 알아야 할 것은 캐싱과의 결합이다. 큰 few-shot 블록은 요청마다 동일하게 반복되는 안정적 prefix다. 따라서 공유되는 예시 묶음의 끝에 cache_control 브레이크포인트를 두고, 매번 달라지는 실제 질문은 그 뒤에 배치한다. 이 "공유 prefix, 가변 suffix" 패턴을 지키면 예시 토큰이 캐시에서 읽혀(약 0.1배 비용) 반복 호출 비용이 크게 줄어든다. 브레이크포인트를 질문 뒤에 두면 매 요청이 서로 다른 캐시 항목을 쓰게 되어 캐시 적중이 일어나지 않는다.
정리
- Claude API에서 few-shot 예시는
messages안 user·assistant 메시지 쌍으로 표현하며, 실제 질문은 마지막 user 턴에 둔다. - 중간 assistant 예시는 정상이지만, trailing assistant prefill은 claude-opus-4-8 등 최신 모델에서 400을 반환한다 — 시험의 핵심 함정.
- prefill로 형식을 강제하던 패턴은
output_config.format이나 시스템 프롬프트 지시로 대체한다. - 예시는 개수가 아니라 품질·일관성·다양성이 결정적이며, capable 모델에 과도한 예시는 역효과다.
- 큰 예시 블록은 공유 prefix 끝에
cache_control을 두어 캐싱과 결합하면 반복 호출 비용을 절감한다.