콘텐츠로 이동

02-예시-설계

“Relevant: Mirror your actual use case closely. Diverse: Cover edge cases and vary enough that Claude doesn’t pick up unintended patterns.” — Prompting best practices, Anthropic

의역: “연관성: 실제 사용 사례를 가깝게 비추라. 다양성: 에지 케이스를 다루고, 의도치 않은 패턴을 학습하지 않도록 충분히 변주하라.”

여기에 한 가지를 더한다.

  • 연관성(Relevance) — 실제 입력과 비슷한가
  • 다양성(Diversity) — 우연한 패턴을 학습하지 않게 변주
  • 명료성(Clarity) — 사람이 봐도 즉시 “왜 이 정답인지” 이해 가능한가

경험적 권장 범위:

작업권장 예시 수
단순 이진 분류2~4
다중 분류 (3~10 클래스)클래스당 12, 총 612
톤·문체 강제2~3
구조화 추출(JSON)1~3 (스키마와 함께)
복잡한 추론4~8 + CoT

너무 많으면 (a) 토큰 비용이 늘고, (b) 모델이 “맨 마지막 예시” 또는 “가장 흔한 예시”에 편향될 수 있다.

모델은 마지막 예시에 가까운 답을 내는 경향이 있다(recency bias). 두 가지 전략:

  • 정답 분포를 균형 있게 섞는다 (예: 클래스 A, B, A, B 순)
  • 가장 어려운 / 가장 흔한 케이스를 마지막에 둔다

”라벨이 무작위여도 낫다”의 함의

섹션 제목: “”라벨이 무작위여도 낫다”의 함의”

Min et al. 결과는 예시를 만들 때 시간을 어디에 쓸지 알려준다. 완벽한 정답을 한 시간 고민하기보다, 다양한 형식을 갖춘 예시 5개를 만드는 데 그 시간을 쓰는 게 낫다. 다만 이는 학술적 발견이지 “정답을 막 적어도 된다”는 뜻은 아니다 — 형식·분포가 더 중요하다는 강조일 뿐이다.

다음은 흔히 빠지는 에지 케이스다. 이것을 예시에 포함하지 않으면 운영 중 사고가 난다.

  • 빈 입력 — "" / “N/A”
  • 모호한 입력 — 어느 카테고리에도 안 맞는 것
  • 여러 카테고리 동시 해당
  • 악성 입력 — 인젝션 시도
  • 다국어 입력