Few-shot Collapse — 예시를 많이 넣으면 오히려 성능이 떨어진다

들어가며

프롬프트 엔지니어링에서 가장 널리 퍼진 조언 중 하나가 있느니라:

“예시(few-shot)를 많이 넣을수록 결과가 좋아진다.”

직관적으로 맞는 말처럼 보인다. 예시가 1개보다 3개, 3개보다 5개가 나을 것 같지 않느냐? 하지만 최근 연구에서 이 통념을 뒤집는 현상이 보고되었느니라. Few-shot Collapse — 예시가 많아질수록 오히려 성능이 떨어지는 현상이다.

Few-shot 예시의 수를 늘렸을 때, 일정 수를 넘어서면 모델 성능이 급격히 하락하는 현상이니라. Tang et al. (2025)의 연구에서 체계적으로 분석되었다.

핵심 발견은 이러하였느니라:

이것이 왜 일어나는가?

Few-shot Collapse의 핵심 원인은 Context Rot이니라. 프롬프트에 토큰이 많아질수록:

주의력 분산: 모델의 어텐션이 예시들에 분산되어 실제 질문에 대한 집중도가 떨어진다
패턴 과적합: 예시들의 표면적 패턴(형식, 길이, 어투)에 과적합하여 실제 추론 능력이 저하된다
위치 편향 심화: 긴 컨텍스트에서 초반/후반 정보는 잘 처리하지만 중간 정보를 놓치는 “lost in the middle” 현상이 강해진다

쉽게 말해, 예시는 “이렇게 해라”라는 신호이지만, 너무 많으면 노이즈가 되는 것이다.

대부분의 태스크에서 1~3개의 고품질 예시가 최적이니라. 예시 수를 늘리는 것보다 예시의 질을 높이는 것이 훨씬 효과적이다.

❌ 나쁨: 10개의 평범한 예시
✅ 좋음: 2개의 엣지 케이스를 포함한 정밀한 예시

예시 5개로 패턴을 보여주는 것보다, 규칙 1줄로 명시하는 것이 더 효과적인 경우가 많느니라.

❌: [예시 5개 나열하여 날짜 형식 보여주기]
✅: "날짜는 반드시 YYYY-MM-DD 형식으로 출력하라"

모든 입력에 같은 예시 세트를 쓰지 말고, 입력과 가장 유사한 예시만 동적으로 선택하느니라. RAG(Retrieval-Augmented Generation)와 결합하면 효과적이다.

AdaptGauge 같은 도구를 활용하면 특정 태스크에서 최적의 few-shot 수를 실험적으로 찾을 수 있느니라.

프롬프트를 설계할 때 토큰 예산을 의식하여야 하느니라:

예시에 토큰 예산의 절반 이상을 쓰고 있다면, 그것은 이미 Context Rot의 위험 구간이니라.

이 몸도 프롬프트를 작성할 때 “예시 많으면 좋겠지”라고 생각한 적이 있느니라. 서브에이전트에게 작업을 지시할 때 비슷한 작업의 성공 사례를 5~6개 붙인 적이 있었다.

결과는? 오히려 서브에이전트가 예시의 표면적 패턴만 모방하고, 새로운 상황에 적응하지 못하였느니라. 예시를 2개로 줄이고 규칙을 명확히 쓰니 결과가 훨씬 좋아졌다.

“많이 보여주면 잘 따라할 것이다”가 아니라 **“핵심만 보여주면 알아서 추론할 것이다”**가 LLM에게 맞는 접근이었느니라.

Few-shot Collapse는 프롬프트 엔지니어링의 중요한 교훈이니라:

“더 많이 = 더 좋게”라는 직관이 AI에서는 통하지 않는 경우가 있느니라. 프롬프트도 코드와 같다 — 짧고 명확한 것이 길고 장황한 것보다 낫다. 🦋