Quick Reference

multishot example은 규칙을 장황하게 설명하는 대신 원하는 입출력 경계를 보여 주는 방법입니다. 출력 형식, tone, label 선택이 자주 흔들릴 때 3~5개의 실제 사례를 넣습니다. 예시는 모델에게 학습을 시키는 데이터가 아니라 현재 request에서 판단 기준을 보여 주는 testable contract이므로, 실제 입력과 다른 예시는 오히려 오류를 고정합니다.

<examples>
  <example>
    <input>배송은 빠른데 포장이 찢어졌어요.</input>
    <output>{"sentiment":"mixed","action":"packaging_review"}</output>
  </example>
  <example>
    <input>인증 메일이 오지 않습니다.</input>
    <output>{"sentiment":"negative","action":"account_verification"}</output>
  </example>
</examples>

좋은 예시의 조건

좋은 example은 실제 사용 case와 가깝고(relevant), 서로 다른 실패 경계를 덮으며(diverse), instruction·실제 input과 구분됩니다(structured). 시작점으로 3~5개를 쓰되 숫자가 정답은 아닙니다. 모두 같은 형식·어휘·난이도라면 다섯 개여도 하나의 패턴만 보여 주는 셈입니다.

최소 구성
- 정상 case: 원하는 기본 동작
- 경계 case: 비슷한 label 사이의 선택
- 예외 case: 거절·추가 정보 요청·unknown

추가할 때
- 운영에서 실제로 실패한 입력을 익명화해 포함한다.
- 바꾸고 싶은 한 가지 차이만 예시에 넣는다.
- 설명보다 input과 output의 대응이 분명한지 확인한다.

example output은 사실의 근거가 아닙니다. 분류 규칙을 보여 주는 예시가 잘못된 label을 갖고 있거나, 현재 policy와 다른 날짜 기준을 쓰면 Claude는 그 오류도 충실히 따라 할 수 있습니다. source 기반 답변에는 multishot과 별도로 source·citation·검증 기준이 필요합니다.

예시와 지시를 함께 쓰는 법

example은 원하는 결과를 보여 주고, instruction은 범위·금지·fallback을 정합니다. 한쪽만 길게 쓰기보다 둘의 책임을 나눕니다. 특히 output 형식이 중요하면 "JSON으로 답해"만 쓰지 말고, required key와 invalid input 처리까지 지시에 적습니다.

<instructions>
  입력을 sentiment와 action으로 분류한다.
  근거가 부족하면 action을 "needs_review"로 둔다.
  output은 설명 없이 JSON object 하나만 반환한다.
</instructions>

<input>{{customer_message}}</input>

평가로 닫기

예시를 추가했다면 예시 자체가 아니라 holdout input에서 좋아졌는지 봅니다. 정상·경계·실패 case를 별도 evaluation set으로 두고, 예시 추가 전후의 정확도·format violation·fallback 비율을 비교합니다. 예시가 trigger됐다는 사실은 output 품질의 증명이 아닙니다.