07. 예시로 가르치기 (zero/one/few-shot)

"백 마디 설명보다 한 번 보여주기"

원하는 출력의 모양을 길게 설명하는 것보다, 예시 하나를 보여주는 게 훨씬 효과적일 때가 많습니다. 한 제공자는 "예시는 LLM에게 천 마디 말의 가치가 있는 그림"이라고 표현합니다. 이 장은 그 "그림"을 잘 그리는 법입니다.

용어 정리 — shot이 뭔가

"shot"은 프롬프트에 넣는 예시의 개수를 뜻합니다.

[zero-shot]  지시만:  "이 후기를 긍정/부정으로 분류해줘: '배송 느림'"

[few-shot]   예시 + 지시:
  후기: "포장 꼼꼼하고 빨라요"  → 긍정
  후기: "한 달째 감감무소식"    → 부정
  후기: "가격은 그저 그래요"    → 중립
  후기: "배송 느림"            →

few-shot에서는 마지막 줄을 비워, 모델이 앞선 예시의 패턴을 이어 채우게 합니다. 2장의 "다음 토큰 예측"이 그대로 작동하는 거죠 — 모델은 앞 예시들이 만든 패턴의 가장 그럴듯한 연속을 내놓습니다.

왜 예시가 강력한가 — 원리

예시는 두 가지를 동시에 전달합니다.

첫째, 형식입니다. "긍정/부정/중립 중 하나로, 한 단어로" 같은 출력 모양을 말로 설명하는 대신 직접 보여줍니다. 여러 가이드가 "few-shot 예시의 주된 목적 중 하나가 응답 형식을 보여주는 것"이라고 말하는 이유입니다.

둘째, 판단 기준입니다. 위 예에서 "가격은 그저 그래요 → 중립"은 "미온적 표현은 중립으로 분류한다"는 암묵적 규칙을 말없이 가르칩니다. 규칙을 일일이 글로 적기 어려운 미묘한 경계를, 예시가 보여줍니다.

📌 핵심: 예시는 형식과 판단 기준을 동시에, 그것도 말보다 정확하게 전달합니다. 설명하기 어려운 것일수록 예시가 유리합니다.

좋은 예시의 세 조건

예시는 강력한 만큼 잘못 쓰면 해롭습니다. 좋은 예시는 세 조건을 만족합니다.

조건 1: 형식이 완벽하게 일관된다

모든 예시의 구조·구분자·띄어쓰기·줄바꿈이 동일해야 합니다. 한 제공자는 "few-shot 예시는 XML 태그·공백·줄바꿈·구분자까지 일관돼야 하며, 그렇지 않으면 원치 않는 형식의 응답이 나온다"고 경고합니다. 예시 간 형식이 흔들리면 모델은 "어느 형식을 따라야 하지?"로 혼란에 빠집니다.

나쁜 예 ❌ (형식 불일치)
입력: 사과  -> 과일
"바나나" => 과일입니다
당근...채소

좋은 예 ✅ (형식 일관)
입력: 사과   → 과일
입력: 바나나 → 과일
입력: 당근   → 채소

조건 2: 대표성이 있다

예시는 실제 마주칠 입력을 잘 대표해야 합니다. 쉬운 경우만 보여주면 모델은 까다로운 경우에 약합니다. 핵심적이고 전형적인(canonical) 사례를 고르세요.

조건 3: 다양하되 과하지 않다

경계가 미묘하면 서로 다른 유형을 골고루 보여주는 게 좋습니다. 단, 모든 엣지케이스를 욱여넣지는 마세요. 한 제공자는 "엣지케이스 목록을 프롬프트에 잔뜩 쌓지 말고, 다양하고 대표적인 정준 예시를 큐레이션하라"고 권합니다. 또 예시가 너무 많으면 모델이 예시에 과적합해 새 입력에 일반화하지 못할 수 있습니다.

⚠️ 흔한 실수·미신: "예시는 많을수록 좋다"는 틀렸습니다. 4장의 attention 예산을 떠올리세요 — 예시가 길어질수록 정작 새 입력에 쓸 주의가 묽어지고, 비용·지연도 늘며, 과적합 위험이 커집니다. 적은 수의 잘 고른 예시가 많은 수의 평범한 예시를 이깁니다.

예시의 가장 위험한 함정 — 편향 전이

예시는 형식뿐 아니라 당신이 의도하지 않은 패턴까지 가르칩니다. 이것이 가장 놓치기 쉬운 함정입니다.

의도치 않은 편향 ❌
  지원자: 김민수, 서울대, 남성  → 합격
  지원자: 이지은, 연세대, 남성  → 합격
  지원자: 박서연, 지방대, 여성  → 불합격
  지원자: 최junho, ???        →

위 예시는 "학벌·성별"이라는 의도치 않은 신호를 가르칩니다. 모델은 당신이 원한 기준이 아니라, 예시에 우연히 들어간 패턴을 학습해 차별적 판단을 이어갈 수 있습니다. 예시의 분포가 곧 출력의 분포가 됩니다.

🧪 직접 검증법: 분류·평가용 few-shot을 만들었다면, 예시에서 정답과 무관한 속성(이름·순서·길이 등)이 한쪽으로 쏠려 있지 않은지 점검하세요. 예시의 라벨 순서(긍정-긍정-부정처럼)도 모델이 "다음은 부정 차례"로 오해할 수 있으니 섞으세요.

zero-shot을 먼저 시도하라

요즘 권고는 "성급하게 few-shot으로 가지 말고, zero-shot을 먼저 시도하라"는 쪽입니다. 최신 모델은 단순·전형적 작업을 예시 없이도 잘 처리하는 경우가 많고, 그러면 예시를 만드는 수고·토큰·과적합 위험을 모두 아낄 수 있습니다.

다만 제공자별로 강조점이 다릅니다. 어떤 가이드는 "zero-shot부터 시도하라"고 하고, 다른 가이드는 "few-shot을 항상 포함하고 zero-shot은 선호하지 않는다"고 합니다. 정답은 작업과 모델에 따라 다르다는 것입니다.

💡 팁: 의사결정 순서로 기억하세요. ① zero-shot으로 해본다 → ② 형식·경계가 어긋나면 → ③ one-shot으로 형식을 잡는다 → ④ 여전히 경계가 미묘하면 → ⑤ few-shot으로 다양한 사례를 보여준다. 필요한 만큼만 올라가세요.

flowchart TB
    start["작업 시작"] --> z["zero-shot 시도"]
    z --> ok1{"형식·경계<br/>충분한가?"}
    ok1 -->|예| done["완료"]
    ok1 -->|형식 문제| one["one-shot 추가"]
    one --> ok2{"충분한가?"}
    ok2 -->|예| done
    ok2 -->|경계 미묘| few["few-shot: 다양한<br/>대표 예시 2~5개"]
    few --> done

    classDef step fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef good fill:#dcfce7,stroke:#22c55e,color:#14532d
    classDef dec fill:#fef9c3,stroke:#eab308,color:#713f12
    class z,one,few step
    class done good
    class ok1,ok2 dec

🔧 개발자 노트: API에서는 few-shot 예시를 보통 user/assistant 메시지 쌍으로 번갈아 넣어, "이런 입력엔 이렇게 답한다"는 대화 형태로 구성합니다. 예시가 없으면 자동 생성하는 도구(테스트 케이스 생성기 등)를 제공하는 플랫폼도 있으니, 직접 만든 뒤 이상적 출력으로 다듬어 쓰면 됩니다. 또한 예시는 프롬프트 앞쪽 정적 영역에 두면 캐싱 이점도 얻을 수 있습니다(6부).

이 장에서 배운 것

• shot은 예시 개수다. zero(0)/one(1)/few(보통 2~5)로 나뉘며, 작업 난이도에 따라 올려간다.
• 예시는 형식과 판단 기준을 말보다 정확하게 동시에 전달한다. 설명하기 어려운 미묘한 경계일수록 유리하다.
• 좋은 예시의 조건은 형식 일관성, 대표성, 적당한 다양성이다. 엣지케이스를 쌓기보다 정준 예시를 큐레이션한다.
• 가장 위험한 함정은 의도치 않은 편향 전이다. 예시의 분포가 곧 출력의 분포가 되므로, 정답과 무관한 속성의 쏠림과 라벨 순서를 점검한다.
• zero-shot을 먼저 시도하고 필요한 만큼만 예시를 올리는 것이 비용·과적합 면에서 유리하다. 단, 최적은 작업·모델마다 다르다.

✍️ 확인 문제

1. "예시는 많을수록 좋다"가 왜 틀렸는지, attention 예산과 과적합 두 개념을 모두 사용해 설명해보세요.

1. 다음 few-shot 예시의 문제점을 두 가지 찾아보세요.

```

리뷰: 최고예요!!! → 별 5개

리뷰: 좋아요 → 별 5개

리뷰: 별로 → 별 1개

리뷰: 괜찮아요 →

```

1. (실습) 고객 문의를 "환불/배송/기술지원/기타" 4가지로 분류하는 few-shot 프롬프트를 만들어보세요. 형식 일관성과 라벨 다양성 조건을 어떻게 충족했는지 한 줄로 설명도 함께.

다음 → 08. 출력 형식 지정
이전 ← 06. 역할과 페르소나 부여 · 목차