Few-shot의 예시는 당신이 생각하는 방식으로 작동하지 않는다── '예시를 보여주면 학습한다'는 오해를 풀다
요약
Few-shot 프롬프팅이 단순히 예시를 통해 모델을 학습시키는 것이 아니라, 문맥 내 학습(In-Context Learning) 관점에서 어떻게 작동하는지 분석합니다. 지시문(Instruction)의 한계를 예시가 어떻게 보완하는지, 그리고 일반적인 통념과 실제 연구 결과 사이의 차이를 다룹니다.
핵심 포인트
- Few-shot은 언어화하기 어려운 암묵적 규칙을 전달하는 데 효과적임
- 지시는 언어적 한계가 있으나, 예시는 문맥을 통해 이를 극복함
- Few-shot의 작동 원리는 단순 학습이 아닌 In-Context Learning(ICL)과 연관됨
- 기존의 '예시를 통한 학습'이라는 통념에 대한 비판적 접근
지난번에는 Chain-of-Thought (사고의 연쇄) 를 다루었습니다. "단계별로 생각해보세요"가 왜 효과적인지에 대한 이야기였습니다.
결론은 이랬습니다.
CoT는 AI를 똑똑하게 만드는 기술이 아니다.
"암산 제한"을 해제하여, 계산 루프를 종이 위에 외장형으로 붙이는 기술이다.
그리고 "단계별로"라는 지시가 모호함에도 불구하고 효과적인 이유는, 절차를 가르치는 것이 아니라 출력하는 문장의 장르를 전환하고 있기 때문이다.
이번에 다룰 것은 Few-shot (퓨샷) —— "예시를 보여준 뒤 요청한다"라는, 이 또한 누구나 사용하고 있는 기법입니다.
그리고 미리 말씀드리자면, 이번에도 거의 같은 지점에 도달하게 됩니다. 완전히 다른 연구군을 따라가고 있음에도 말입니다.
이것은 우연이 아니라고 생각합니다. 그 이유도 마지막에 쓰겠습니다.
갑자기 연구 이야기로 들어가기 전에, 용어를 제대로 정리하겠습니다. 이곳을 모호하게 둔 채 진행하면 후반부 이야기가 전부 흐릿해집니다.
AI에게 요청하는 방식은 모범 사례를 몇 개 보여주느냐에 따라 이름이 바뀝니다.
Zero-shot (제로샷) ── 모범 사례 0개. 그냥 요청만 함.
다음 문의문을 「긴급」 「통상」 「대응 불필요」 중 하나로 분류해 주세요.
문의: 「결제 화면에서 500 에러가 발생하여 구매할 수 없습니다」
분류:
One-shot (원샷) ── 모범 사례 1개.
문의: 「비밀번호를 잊어버렸습니다」
분류: 통상
문의: 「결제 화면에서 500 에러가 발생하여 구매할 수 없습니다」
...
Few-shot (퓨샷) ── 모범 사례를 몇 개.
문의: 「비밀번호를 잊어버렸습니다」
분류: 통상
문의: 「서비스 전체에 접속할 수 없습니다」
...
이것뿐입니다. 어려운 기술이 아닙니다. 모범 사례를 나열하고, 마지막에 본래의 질문을 놓는다. 그것뿐입니다.
그리고 이것이 놀라울 정도로 효과적입니다. 그렇기에 모두가 사용하고 있습니다.
"말로 설명하면 되지 않느냐"라고 생각할지도 모릅니다. 실제로 Zero-shot에서도 지시를 정중하게 쓰면 나름대로 작동합니다.
하지만 실무에서는 말로 다 설명할 수 없는 것이 산더미처럼 있습니다.
예를 들어, 사내 문의 분류. 「긴급」의 정의를 말로 쓰려고 하면 다음과 같습니다.
「긴급」이란, 서비스의 지속에 중대한 영향을 미치거나, 다수의 사용자에게
영향을 미치거나, 혹은 금전적 손해가 발생할 수 있거나, 혹은 법령상의 대응 기한이
임박한 경우를 가리킵니다. 단, 단일 사용자의 조작 실수에 기인하는 경우는
...
쓰면 쓸수록 예외가 늘어나, 아무도 읽지 않는 사양서가 됩니다. 게다가 현장의 인간은 이 정의를 읽지 않아도 올바르게 분류할 수 있습니다. 과거의 사례를 보고 왔기 때문입니다.
Few-shot은 이 "사례를 보고 파악하는 감각"을 그대로 전달하는 방법입니다.
| Zero-shot (말로 설명) | Few-shot (예시를 보여줌) |
|---|---|
| 특기 | 일반 상식으로 판단할 수 있는 태스크 |
| ... |
이전 연재에서 "예시는 지시보다 강하다"라는 이야기를 몇 번 했지만, 그 이유의 일환이 여기에 있습니다. 지시는 언어화의 한계에 묶이지만, 예시는 묶이지 않습니다.
……라는 것이 일반적으로 믿어지고 있는 설명입니다. 이번 기사는 이 설명이 어디까지 옳은지를 연구를 따라가며 검증해 나갑니다.
미리 예고하자면, 위의 설명은 상당히 수상합니다.
이 기사에 나오는 용어를 미리 정리해 둡니다. 건너뛰었다가 막히면 돌아오세요.
| 용어 | 의미 | 쉽게 말하자면 |
|---|---|---|
| Few-shot | 예시를 몇 개 보여준 뒤 요청하는 방식 | 모범 사례를 나열함 |
| ... |
Few-shot에서 일어나고 있는 일은 연구 세계에서는 In-Context Learning (문맥 내 학습, ICL) 이라고 불립니다.
이 "학습"이라는 단어가 이 분야에서 가장 오해를 불러일으키고 있다고 생각합니다.
보통 "AI가 학습한다"라고 하면, 모델의 내부(파라미터, 가중치)가 바뀌는 것을 가리킵니다. 훈련(Training)입니다. 한 번 학습하면 다음번 이후에도 그 지식은 남습니다.
Few-shot에서는 그것이 전혀 일어나지 않습니다.
모델의 내부은 1비트도 변하지 않습니다. 예시를 보여주는 동안에만, 그 자리의 입력란에 쓰인 글자로서 예시가 존재할 뿐입니다. 대화가 끝나면 흔적도 없이 사라집니다.
인간으로 치면 이렇습니다.
공부해서 외운 것이 아닙니다.
책상 위에 견본을 올려두고, 그것을 힐끗힐끗 보면서 쓰고 있는 것과 같습니다.
견본을 치워버리면, 아무것도 남지 않습니다.
이 차이는 기사 후반부에서 결정적인 역할을 합니다. 「가르친」 것이 아니라 「보여주고 있을」 뿐입니다. 이 점을 꼭 유념해 두시기 바랍니다.
자, 이제 본론으로 들어가겠습니다.
Few-shot 설계에서 많은 사람이 가장 신경 쓰는 것은 무엇일까요? 아마도 "올바른 예시를 준비하는 것"일 것입니다. 잘못된 예시를 보여주면 잘못된 것을 배워버릴 것 같으니까요.
그 상식을 정면으로 파괴한 것이 바로 Min et al. (2022) (EMNLP 2022) 연구입니다.
먼저 무엇을 했는지 차근차근 설명하겠습니다.
일반적인 Few-shot은 다음과 같은 형태를 띠고 있습니다.
입력: 「이 영화는 지루했다」
감정: 네거티브
입력: 「훌륭한 연기였다」
...
연구팀이 한 일은, 이 「감정:」 뒤의 정답을 전부 엉터리로 만드는 것이었습니다.
입력: 「이 영화는 지루했다」
감정: 포지티브 ← 틀림
입력: 「훌륭한 연기였다」
...
모범 답안이 전부 엉터리입니다. 상식적으로 생각하면 성능이 급격히 떨어져야 합니다.
하지만 거의 떨어지지 않았습니다.
GPT-3를 포함한 12종의 모델에서 분류 태스크(Classification task)와 다지선다 태스크(Multiple-choice task) 모두에서 확인되었습니다. 정답을 무작위로 교체해도 성능에 미치는 타격은 극히 미미했습니다.
반면, 예시를 단 하나도 보여주지 않는 경우(Zero-shot)와 비교하면, 명확하게 성능이 올라가 있습니다.
즉, 이런 뜻입니다.
예시를 보여주면 효과가 있다. 하지만 예시의 정답이 맞는지 틀린지는 거의 상관이 없다.
이 내용을 처음 읽었을 때, 저는 세 번이나 다시 읽었습니다. 정답 쌍을 정성스럽게 만들어온 노력이 대체 무엇이었나 싶어서 말이죠.
동일한 연구는 그 이유에 대해서도 답을 내놓았습니다. 효과가 있었던 것은 다음 세 가지였습니다.
라벨 공간 (Label space) ── 「정답으로서 어떤 단어를 사용하는가" -
입력 텍스트의 분포 (Input text distribution) ── 「어떤 종류의 입력이 들어오는가" -
전체 포맷 (Overall format) ── "어떤 형식으로 나열되어 있는가" -
여기에 이를 보강하는 실험도 있는데, 입력 텍스트 쪽을 전혀 무관한 문장으로 교체하면 이번에는 성능이 크게 떨어졌습니다. 심지어 예시를 보여주지 않는 편이 나을 정도로 성능이 추락하는 경우도 있었습니다.
정답은 망가뜨려도 괜찮다. 하지만 입력의 질감을 망가뜨리면 치명적이다.
이것을 이렇게 생각하면 납득이 갑니다.
시험 전에 기출문제를 받았다고 가정해 봅시다. 단, 해답란은 엉터리입니다. 전부 틀린 답이 적혀 있습니다.
그럼에도 당신은 기출문제를 통해 방대한 정보를 얻습니다.
서술형이 아니라 기호 선택형이구나 (= 포맷) -
답은 「가~라」로 쓰는구나 (= 라벨 공간) -
이런 느낌의 문장제가 나오는구나 (= 입력의 분포) -
그리고 본 시험에서는, 이 "틀"에 맞춰 자신의 지식으로 답합니다. 해답란이 틀렸었다는 사실은 그리 큰 문제가 되지 않습니다.
모델이 하고 있는 것도 바로 이것입니다.
예시는 교과서가 아닙니다. 답안지의 템플릿입니다.
추상적인 이야기가 이어졌으므로, 각각이 실무에서 무엇을 의미하는지 자세히 풀어보겠습니다.
① 라벨 공간 = 정답에 사용할 수 있는 어휘 메뉴
예시 중에 「긴급」, 「통상」, 「대응 불필요」가 등장한다면, 모델은 "정답은 이 세 가지 중에서 고르는 것이구나"라고 읽어냅니다.
역으로 말하면, 예시 속에 한 번도 등장하지 않은 라벨은 선택되기 어려워집니다. 네 번째 분류인 「에스컬레이션」을 준비해 두었더라도, 예시에 한 번도 나오지 않는다면 모델의 선택지에서 사실상 누락될 가능성이 있습니다.
② 입력의 분포 = 어떤 질감의 입력이 들어오는가
이는 "문장의 길이", "사용되는 어휘", "문체", "전문 용어의 밀도"와 같이 내용이 아닌 **질감(Texture)**에 관한 이야기입니다.
실제 상황에서 다루는 것이 「시스템 로그 발췌본」인데, 예시가 「정중한 비즈니스 메일」이라면 내용이 아무리 비슷해도 어긋나게 됩니다. 반대로 내용이 다소 빗나가더라도 질감이 맞으면 제대로 작동합니다.
③ 포맷 = 나열되는 방식의 틀
이것이 가장 눈에 띄지 않지만, 사실 효과가 큽니다.
문의: 〇〇
분류: 통상
이 "라벨명 + 콜론 + 값", "예시와 예시 사이는 빈 줄 하나"와 같은 구조 그 자체가 신호가 됩니다.
따라서 포맷이 흔들리면 망가집니다. 첫 번째만 「분류：」(전각 콜론), 두 번째는 「분류:」(반각 콜론)와 같이 통일되지 않은 형태는 인간에게는 오차일지 몰라도 모델에게는 다른 신호로 보일 수 있습니다.
COBOL에서 Java로 전환하는 현장의 관점에서 말하자면
레거시 시스템(Legacy) 마이그레이션 문서 생성을 AI에 맡길 때, 저는 종종 몇 개의 변환된 샘플을 예시로 제공합니다.
이때 실제로 효과를 발휘하는 것은 '변환 내용 자체가 정확하다는 것'이라기보다는,
- 출력에 사용되는 핵심 단어(헤드워드)가 고정된다는 점 (즉, 라벨 공간)
- COBOL 코드 조각이라는 특수한 형태의 입력을 전제로 할 수 있다는 점 (즉, 입력 분포)
- '원문 → 논점 → 변환 방침'이라는 순서가 형식으로 정착된다는 점 (즉, 포맷)
이었습니다.
실감상으로도 이는 맞습니다. 샘플의 변환 내용에 약간의 허술함이 있어도 출력은 안정적인데, 샘플의 형식을 통일하는 것을 잊었을 때만 출력이 제멋대로가 됩니다. 경험적으로 알고 있던 사실에 이름이 붙여진 느낌입니다.
알게 된 분들도 계실 겁니다.
지난번 CoT(Chain-of-Thought)에서는 이런 결론이었습니다.
'단계별로 생각하라'는 것이 모호한데도 효과가 있는 것은,
절차를 가르치고 있기 때문이 아니라, 출력하는 글의 장르를 전환하고 있기 때문입니다.
이번 Few-shot은 이렇습니다.
예시가 효과적인 것은,
task(과제)를 알려주고 있기 때문이 아니라, 출력의 틀(어휘・형식・입력의 질감)을 지정해주고 있기 때문입니다.
다른 연구 그룹들을 다른 방향에서 추적하다가 같은 장소에 도착했다.
이는 우연이 아니라고 생각합니다. 둘 다 1차 때 작성했던 'LLM은 계산기가 아니라 직관 기계(Intuition Machine)이다'라는 전제에서 나오는 귀결이기 때문입니다.
직관 기계는 배우고 이해하는 것이 아니라, 어떤 모드로 행동할지 전환할 수 있습니다. 프롬프트 기술이란 경우가 많게 '교육'이 아니라 '모드 선택'인 것이라고 생각합니다.
여기까지 듣고 '그럼 예시는 아무거나 써도 되는 거 아닌가?'라고 생각하신 분들, 그렇지 않습니다.
아무렇게나 만든 예시를 아무렇게나 순서대로 배열하면 성능이 붕괴됩니다.
여기서 말하는 '순서'는 예시 블록 자체를 배열하는 순서를 의미합니다. 하나의 예시 내용(‘입력: → 분류:’라는 내부 구조)은 고정되어 있으므로 제외 대상입니다.
[예시 1] → [예시 2] → [예시 3] → [예시 4] → [실제 질문]
이 네 개의 블록을 어떤 순서로 배열하느냐. 내용물은 전혀 바꾸지 않고, 이 배열만 바꿉니다.
Lu et al. (2022)의 연구입니다. 제목이 재미있어서 'Fantastically Ordered Prompts(환상적으로 배열된 프롬프트)'라고 합니다.
완전히 똑같은 예시를 사용해서, 배열 순서만 바꾼다. 그것만으로 무엇이 일어나는지 보십시오.
'거의 최고 성능'에서 '거의 엉터리 답변'까지 변동합니다.
다른 연구(Zhao et al. 2021)에서도 감성 분석 태스크에서 배열 순서 변경만으로 정답률이 **54%(거의 우연에 의한 추측)에서 93%(거의 최고 수준)**까지 움직인 것이 보고되었습니다.
예시 내용은 동일합니다. 순서만 다릅니다. 그것만으로 40포인트 가까이 변동합니다.
Lu et al.은 추가로 이렇게 보고했습니다.
① 모델 크기가 커져도 사라지지 않는다. '대규모 모델이면 신경 쓸 필요 없다'는 뜻이 아닙니다. 당시 최고 수준의 모델에서도 발생합니다.
② 특정 '나쁜 예시' 때문이 아니다. '이상한 예시가 섞여 있어서'가 아니라, 좋은 예시만 모아도 순서에 따라 무너집니다.
③ 좋은 배열 순서는 다른 모델로 전이되지 않는다. 어떤 모델을 위해 고생해서 찾은 최적의 배열은, 다른 모델에서는 의미가 없어집니다.
③이 실무적으로 가장 아픕니다. 프롬프트는 모델 고유의 설정 파일이라는 것입니다. 모델을 교체하면, 배열 순서 튜닝은 처음부터 다시 해야 합니다.
메커니즘 수준의 설명은 Zhao et al. (2021) (ICML 2021)에 있습니다. 모델에는 세 가지 편향이 있다는 것입니다.
| 편향 | 내용 | 사람으로 비유하면 |
|---|---|---|
| 다수파 라벨 편향(majority label bias) | 프롬프트 내에서 많이 나오는 답을 고르기 쉽다 | 회의에서 다수 의견에 휩쓸린다 |
| 최근성 편향(recency bias) | 프롬프트 후반부에 나온 답을 반복하기 쉽다 | 면접에서 마지막 지원자의 인상이 강하게 남는다 |
| 빈출 토큰 편향(common token bias) | 사전 학습에서 자주 본 단어를 고르기 쉽다 | 희귀한 국가명보다 '미국'이라고 말해버린다 |
구체적인 예시로 보면 이해하기 쉽습니다.
[예시 1]: ... → 부정적
[예시 2]: ... → 긍정적
[예시 3]: ... → 부정적
...
이러한 배열이라면 모델은 **부정적(Negative)이라고 답하기 쉬워집니다**. 이유는 두 가지가 겹쳐 있는데, 전체적으로 부정적 답변이 많은 것(다수파 편향, Majority Bias)과 마지막 예시가 부정적인 것(최근 편향, Recency Bias)입니다.
**예시의 내용과는 무관하게, 배열 방식만으로 답이 편향됩니다.**
세 번째로 자주 등장하는 토큰 편향(Token Bias)도 실무에서는 은근히 영향을 미칩니다. 라벨 이름을 '대응 불필요'가 아니라 'NoAction'과 같이 생소한 표기로 정하면, 그것만으로도 모델이 선택하기 어려워질 가능성이 있다는 뜻입니다. 라벨의 **이름 선택** 또한 설계 요소인 셈입니다.
### Lost in the Middle와의 연결——단, 정확히 말하자면
연재 제2회에서 다루었던 **Lost in the Middle**(긴 문맥의 중간 정보가 무시되기 쉬운 현상)을 기억하시나요?
"위치에 따라 정보의 효력이 다르다"는 바로 그 이야기입니다.
인수인계 자료 단계에서는 "이것이 예시의 배열 순서에도 직격하고 있을 것"이라는 가설이 있었습니다. 조사한 결과, **절반은 맞고 절반은 과장된 것**이었습니다. 정확하게 기술하겠습니다.
**Lost in the Middle와 Zhao et al.의 최근 편향(Recency Bias)은 사실 서로 다른 실험 계열에서 나온 별개의 것입니다.**
- **Lost in the Middle**(제2회)이 측정하고 있었던 것은, "**대량의 문서 중에서 정답이 적힌 하나를 찾아낼 수 있는가**"라는 검색(Retrieval)에 가까운 현상
- **Zhao et al.의 최근 편향**이 측정하고 있었던 것은, "**마지막 예시의 라벨 패턴을 그대로 반복하기 쉬운가**"라는, 자기회귀(Autoregressive, 직전의 내용을 지속하기 쉬운 성질)에서 유래한 현상
**두 가지를 동일한 현상이라고 단정하기에는 아직 부족합니다.** 하지만 정황 증거는 상당히 모여 있습니다.
Lost in the Middle는 최근의 이론 연구를 통해, **모델을 훈련하기 전의 초기 상태에서도 이미 나타난다**는 것이 밝혀졌습니다. 원인은 특정 태스크의 습성이 아니라, **주의 메커니즘(Attention)과 잔차 연결(Residual Connection)이라는 트랜스포머(Transformer) 구조 그 자체의 기하학적 성질**이라는 설명입니다. 문두(문장 시작 부분)에는 강력한 영향력이 로그 단위로 쌓이고(Primacy Tail), 문미(문장 끝 부분)에는 고립된 강력한 영향력이 생기며(Recency Delta), 그 골짜기에 해당하는 중간 부분이 구조적으로 불리해진다는 것입니다.
이것이 맞다면, 대상이 '문서의 나열'이든 'Few-shot 예시의 나열'이든 **똑같은 골짜기에 빠질 것입니다**. 검색 태스크에 국한된 현상이 아니라, 나열된 것 전반에 영향을 미치는 구조적 성질이기 때문입니다.
반면, 이에 반론을 제기하는 최근 연구도 있습니다. 모델은 이전 예시를 바탕으로 각 예시의 표현을 다시 만들며, **그 상황의 문맥 속에서 정보량이 더 많고 혼동이 적은 예시에 주의를 재배분한다**는 사실이 밝혀졌습니다. 즉, 위치만이 전부가 아니라, **내용의 두드러짐이 위치의 불리함을 어느 정도 상쇄할 수 있는** 가능성이 있습니다.
**따라서 정확한 표현은 다음과 같습니다.**
위치만 놓고 보면 중간은 구조적으로 불리하다. 이는 아키텍처 레벨의 근거가 있다.
다만, 그 예시가 충분히 정보량이 많고 다른 것과 섞이지 않는 내용이라면, 위치의 불리함을 어느 정도 상쇄할 가능성이 있다.
"중간의 예시는 반드시 Lost in the Middle 현상을 겪는다"라고 단언하는 것은, 현시점에서는 검증되지 않은 외삽(Extrapolation)입니다.
확실히 확인된 것은 **마지막 부분(Recency 측)의 효과뿐**입니다. 중간과 앞부분의 관계는 아직 그 정도로 확정되지 않았습니다.
위 내용을 바탕으로 한 실무 지침입니다.
| 우선순위 | 지침 | 근거 |
|---|---|---|
| 높음 | 가장 전형적이며 포맷의 본보기가 될 예시를 맨 앞에 배치한다 | Primacy 측면. 이후 전체의 형식을 결정하는 토대 역할을 함 |
| 높음 | 마지막 라벨이 특정 클래스에 편향되지 않도록 한다 | 최근 편향은 실증됨. 마지막 답변에 최종 예측이 끌려감 |
| 높음 | 묻히고 싶지 않거나 놓치면 곤란한 예시는 중간을 피해 양 끝에 배치한다 | 위치에 따른 불리함을 피하는 가장 확실한 대책 |
| 중간 | 예시가 3~10개 정도의 소수라면 순서의 효과가 크다. 16개를 넘어가면 급격히 옅어진다 | 실측에서도 소수 예시에서는 재배열에 따른 변동이 크지만, 예시 수가 늘어나면 축소됨이 확인됨 |
| 중간 | 묻히고 싶지 않은 예시가 여러 개라면 양 끝에 분산시키고, 중간은 '평범하지만 타당한 예시'로 채운다 | Primacy와 Recency를 모두 활용하면서, 중간의 리스크를 감수하지 않는 예시로 채움 |
| 낮음 | 최적의 배열 순서는 결국 모델마다 다르다. 시간이 있다면 여러 배열을 실측하여 비교한다 | 이전 섹션에서 언급했듯이, 좋은 배열은 다른 모델로 전이되지 않음 |
가장 단순한 지침을 하나만 고른다면, 이것입니다.
가장 중요한 예시를 처음과 마지막, 양쪽 모두에 배치한다. (같은 예시를 두 번 사용해도 괜찮다)
가운데는 있어도 없어도 큰 영향이 없는, 평범하지만 타당한 예시들로 채운다.
이렇게 하면 "가운데 있는 예시가 정말로 Lost in the Middle(중간 소실) 현상을 일으키는지" 엄격하게 알지 못하더라도, **가운데에 중요한 정보를 두지 않음으로써 리스크 자체를 회피**할 수 있습니다. 제2회에서 썼던 "중요한 정보는 양 끝에"라는 대책과 발상은 동일합니다.
**실무에서의 즉효 테크닉**
만약 분류 태스크 (Classification Task)에서 Few-shot을 사용하고 있는데, 출력이 특정 클래스에 편향되어 있다고 느껴진다면, 가장 먼저 의심해야 할 것은 **예시의 순서와 클래스 균형 (Class Balance)**입니다.
- 각 클래스의 예시 수를 맞춘다 (다수파 편향 대책)
- 마지막에 동일한 라벨을 연속해서 두지 않는다 (최근성 편향 (Recency Bias) 대책)
- 라벨 이름은 자연스럽고 일반적인 단어로 한다 (빈출 토큰 편향 대책)
- 가장 중요한 예시는 맨 앞과 맨 뒤에 배치하고, 가운데에는 평범한 예시를 둔다 (위치 편향 대책)
프롬프트의 문구를 수정하기 전에, 이것을 확인하는 것이 더 빠른 경우가 많습니다.
다음은 "몇 개가 최적인가"입니다.
오랫동안 Few-shot의 "Few"는 말 그대로 몇 개였습니다. 컨텍스트 윈도우 (Context Window, 한 번에 모델에 전달할 수 있는 글자 수의 상한)가 작았기 때문에 물리적으로 그만큼밖에 들어가지 않았기 때문입니다.
하지만 컨텍스트가 100만 토큰급까지 늘어나면서, **수백~수천 개의 예시를 전달하는 것**이 가능해졌습니다. 이를 **many-shot (메니샷)**이라고 부릅니다.
**Agarwal et al. (2024)** (NeurIPS 2024)가 이를 체계적으로 조사했습니다. Gemini 1.5 Pro (100만 토큰 컨텍스트)를 사용하여, few-shot에서 many-shot으로 이행했을 때 어떤 일이 일어나는지를 말이죠.
**폭넓은 태스크에서 성능이 대폭 향상되었습니다.** 생성형 태스크에서도, 분류형 태스크에서도 말입니다.
흥미로운 점은 이 연구가 "예시를 준비하는 비용"이라는 현실적인 벽에도 도전하고 있다는 것입니다. 수백 개의 고품질 예시를 수작업으로 만드는 것은 비현실적이므로, 두 가지 대안을 시도했습니다.
- **Reinforced ICL** ── 인간이 쓴 예시 대신, **모델 스스로 생성한 추론 과정**을 예시로 사용
- **Unsupervised ICL** ── 예시에서 정답을 제거하고, **문제문만** 대량으로 나열
두 방법 모두, 특히 복잡한 추론 태스크에서 상당히 유효했다고 보고되었습니다.
"정답을 제거해도 효과가 있다"는 점은 섹션 2의 Min et al.의 이야기와 깔끔하게 일치합니다. **역시 정답은 본체가 아닙니다.**
후속 연구에서는 또 다른 흥미로운 사실이 보고되었습니다.
**예시가 매우 많은 영역에서는 순서 변경에 대한 민감도가 낮아진다.**
생각해 보면 당연합니다. 예시가 4개라면 마지막 1개는 전체의 25%를 차지합니다. 하지만 예시가 400개라면 마지막 1개는 0.25%입니다. 최근성 편향의 영향이 상대적으로 옅어집니다.
즉, 섹션 3에서 끊임없이 위협했던 순서 문제는 **예시를 많이 넣을 수 있다면 어느 정도 물량으로 해결할 수 있다**는 뜻입니다.
이 부분은 솔직하게 쓰겠습니다. many-shot에는 명확한 비용이 따릅니다.
| 비용 | 내용 |
|---|---|
| 과금 | 매번 수백 개의 예시에 해당하는 토큰을 보내야 함 |
| ... | |
특히 마지막 점. 연재 제3회에서 다루었던 **Context Rot** (문맥이 길어질수록 성능이 떨어지는 현상)과 many-shot은 정면으로 충돌합니다. "예시를 늘리면 성능이 올라간다"와 "길어지면 저하된다"가 동시에 성립하므로, **어딘가에 최적점이 있을 것**입니다.
그리고 그 최적점은 태스크에 따라서도, 모델에 따라서도 다릅니다. **측정할 수밖에 없습니다.**
마지막 질문, "좋은 예시란 무엇인가"입니다.
**Liu et al. (2022)**의 연구가 이 분야의 표준적인 수법을 만들었습니다. 제목은 그 자체로 명확합니다: "What Makes Good In-Context Examples for GPT-3? (GPT-3에게 좋은 예시란 무엇인가)"
방법은 간단합니다. **앞으로 풀게 하고 싶은 문제와 의미적으로 가까운 예시를 예시 풀(Pool)에서 검색하여 사용하는 것**입니다. 무작위로 예시를 고르는 것보다 일관되게 성능이 향상됨이 확인되었습니다. 태스크에 따라서는 40% 이상의 개선도 보고되었습니다.
**"의미적으로 가깝다"를 기계는 어떻게 측정하는가**
여기서 **임베딩 (embedding)**이라는 기술이 등장합니다.
문장을 수백 차원의 좌표(숫자의 나열)로 변환하는 기술입니다. 의미가 가까운 문장일수록 좌표상에서 가까운 위치에 배치되도록 만들어져 있습니다.
즉, "의미의 지도"를 만들어 그 지도 위에서의 거리를 측정하는 것입니다. 지도상에서 가장 가까운 예시를 k개 선택하기 때문에, **kNN 검색 (k-Nearest Neighbors search)** 이라고 불립니다.
쉽게 말하자면 "유사한 문의를 과거의 대응 이력에서 가져오는 것"뿐입니다. 고객 지원(Customer Support)의 FAQ 검색과 하는 일은 같습니다.
예리한 분들은 의구심이 들었을 것입니다.
섹션 2에서는 "정답의 정확도는 효과가 없다"라고 말했습니다. 그런데 여기서는 "좋은 예시를 선택하면 효과가 있다"라고 말하고 있습니다. **모순되지 않나요?**
모순되지 않습니다. 그리고 이 모순을 풀면 이해가 한 단계 깊어집니다.
기억해 보세요. 효과가 있었던 3가지 요소 중 두 번째는 "**입력 텍스트의 분포 (Distribution of input text)**"였습니다. 그리고 입력을 무관한 문장으로 교체하면 성능이 처참하게 무너진다는 실험도 있었습니다.
**유사도 검색이 효과적인 이유는, "정답을 가르쳐주고 있기 때문"이 아닙니다.**
**입력의 분포를 앞으로 풀 문제의 분포에 가깝게 맞추고 있기 때문입니다.**
과거 문제 예시로 돌아가 봅시다. 수학 시험 전에 화학 과거 문제를 받아봐도 의미가 없습니다. 같은 수학의, 그것도 같은 단원의 과거 문제이기 때문에 "이런 느낌의 문제가 나오는구나"라는 틀이 올바르게 설정됩니다.
**유사도 검색은 교사 데이터 (Training data)의 공급이 아니라, 분포 맞추기입니다.**
이 이해의 차이는 실무에서 큰 차이를 만듭니다. "올바른 모범 답안을 만들어야 해"라고 부담을 갖기보다, "**실전과 같은 질감의 입력을 나열하는 것**"이 우선순위가 더 높다는 뜻이기 때문입니다.
지금까지 "정답은 효과가 없다"라고 반복해 왔지만, 솔직하게 보충해야 할 점이 있습니다.
**Min et al.의 결론에는 반증과 제한 조건이 있습니다.**
후속 연구 (Ground-Truth Labels Matter)에서는 입력과 라벨(Label) 사이의 대응에 대한 둔감함이 **모든 실험 설정에서 일관되게 나타나는 것은 아니다**라고 지적합니다. 실험 조건에 따라서는 라벨의 정확도가 효과를 발휘하는 장면이 있습니다.
더 극단적인 현상도 보고되었습니다.
라벨을 랜덤하게 설정해도 괜찮은데, **모든 예시의 라벨을 동일한 것으로 통일하면 정확도가 처참하게 떨어진다** (여러 모델과 태스크에서 12% 이하로 저하)는 보고입니다.
더 흥미로운 점은, 의미 없는 조어 (foo, bar 등)를 라벨로 사용하더라도 모델은 **그 조어의 집합 안에서 답을 선택하려고 시도한다**는 것입니다. 본래의 정답이 후보군에서 벗어나 있음에도 불구하고 말입니다.
"라벨은 아무렇게나 해도 된다"는 뜻이 아닙니다. 정확히는,
라벨의 "정확성"보다 라벨 집합의 "보여지는 방식"이 더 지배적이라는 뜻입니다.
모델은 라벨 칸을 보고, "답으로서 허용되는 어휘는 이것이다"라는 **메뉴 (Menu)**를 읽어내고 있습니다.
- 메뉴가 다양함 (=라벨 공간이 올바르게 제시됨) $\rightarrow$ 내용이 틀려도 기능함
- 메뉴가 단조로움 (=전부 동일함) $\rightarrow$ 선택지가 하나뿐이라고 해석하여 망가짐
정답의 맞고 틀림이 아니라, **정답의 다양성**이 정보였던 것입니다.
**실무상의 함의**
이것은 "대충 해도 된다"는 이야기가 아니라, **대충 해도 되는 부분이 다르다**는 이야기입니다.
- 우선순위 높음: 라벨의 종류를 전부 등장시킴 / 클래스 균형 (Class balance)을 맞춤 / 입력의 질감을 실전과 유사하게 맞춤 / 포맷을 통일함
- 우선순위 낮음: 하나하나의 예시의 정답을 완벽하게 검증함
물론 정답이 올바른 것이 가장 좋습니다. 다만, 한정된 공수를 어디에 투입할 것인가라는 질문에 대해서는 위의 순서가 더 효율적이라는 의미입니다.
지금까지의 내용에서 생길 법한 의문을 미리 짚어보겠습니다.
능력이 향상된 것이 아닙니다. **동일한 능력 그대로, 출력의 틀이 바뀌었을 뿐**입니다.
지난번 CoT와 대비하면 이해하기 쉽습니다. CoT는 "암산 제약을 해제하여 사용할 수 있는 계산량을 늘리는" 기법이었습니다. 그것은 **능력의 해방**입니다.
Few-shot은 다릅니다. 계산량은 변하지 않습니다. 변하는 것은 "어떤 형식으로, 어떤 어휘로 답할 것인가"라는 **출력의 설정**입니다.
따라서, **근본적으로 풀 수 없는 문제는 예시를 보여줘도 풀 수 없습니다**. 예시를 100개 나열해도 모델이 모르는 업무 규칙을 추측할 수 있게 되지는 않습니다. 할 수 있는 것은 "알고 있는 것을 올바른 형식으로 내뱉게 하는 것"까지입니다.
전달되지 않습니다. 모델의 내부 상태는 변하지 않았으므로, **새로운 대화에서는 완전히 제로(Zero) 상태**입니다.
동일한 대화 중이라 하더라도, 문맥이 길어지면 Context Rot(제3회에서 다룸)에서 다루었던 열화가 발생하며, 연재 제9회에서 다루었던 Instruction Drift(지시가 점차 효과를 잃는 현상)와 마찬가지로 예시의 효과가 희석될 수도 있습니다.
예시는 "한 번 전달하면 기억해 주는 것"이 아니라, **매번 다시 전달해야 하는 소모품**이라고 생각하는 것이 실태에 더 부합합니다.
**위험합니다.** 섹션 2의 내용을 떠올려 보세요. 모델은 라벨(Label) 칸을 "정답으로서 허용되는 어휘의 메뉴"로 읽습니다.
즉, 나쁜 예시를 나열하면, **그 나쁜 예시의 질감이 "입력의 분포(Input Distribution)\
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기