1M 토큰의 함정: LLM 컨텍스트가 길어지면 성능이 떨어지는 이유

우리는 보통 AI가 헛소리를 하면 “정보를 못 찾았나 보네”라고 생각합니다. 그래서 더 비싼 검색 엔진(Retriever)을 달고 리랭커(Reranker)를 추가하죠. 그런데 최근 발표된 논문 “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval”은 충격적인 사실을 보여줍니다.

실험 내용

Llama-3, GPT-4o 같은 모델에게 정답이 담긴 문장을 토씨 하나 안 틀리고 딱 집어준 상태에서(Perfect Retrieval), 문맥의 ‘길이’만 늘려보았습니다.

실험 결과

Llama-3.1-8B: 30k 토큰 길이에서 검색은 완벽했지만, 정답률은 24.2% 폭락했습니다.
Mistral-v0.3-7B: 검색 점수는 95.3%인데, 수학 문제 정답률은 34.2%나 떨어졌습니다.

쉽게 비유하자면, 시험을 볼 때 정답이 적힌 페이지를 펼쳐 줬는데도, 책 두께가 너무 두꺼우면 학생이 정신을 못 차리고 오답을 내는 꼴입니다. 정보가 어디 있는지 알아도, 그걸 활용해 ‘추론’하는 단계에서 뇌가 멈춰버리는 것이죠.

공백의 저주: “비어 있어도 길면 싫다”

더 놀라운 건 ‘공백 실험’ 결과입니다. 보통은 “관련 없는 텍스트(노이즈)가 섞여서 헷갈리는 것”이라고 생각하기 쉽죠? 연구진은 관련 없는 내용을 전부 ‘흰 공백(Whitespace)’으로 채워봤습니다. 정보량은 0이고, 그저 스크롤만 길어진 셈입니다.

결과는 어땠을까요? 놀랍게도 성능 저하는 여전했습니다.

실험 1: 100페이지 분량의 텍스트에 정답 하나 섞어 넣기
실험 2: 1페이지 분량의 텍스트와 99페이지 분량의 ‘공백’ 뒤에 정답 넣기

이것은 모델의 성능 저하가 정보의 간섭 때문이 아니라, ‘물리적인 거리’ 그 자체 때문임을 시사합니다. 책상이 너무 넓으면 아무리 깨끗해도 물건 찾기가 힘든 것과 비슷합니다.

해결책: ‘입력 다이어트’ (Retrieve-then-Reason)

그렇다면 우리는 100만 토큰 시대를 어떻게 활용해야 할까요? 답은 간단합니다. 모델에게 한 번에 모든 것을 시키지 말고 ‘단계를 나누는 것’입니다. 논문에서는 이를 ‘Retrieve-then-Reason(검색 후 추론)’ 전략이라 부릅니다.

🛠️ 적용 방법: 받아쓰기 후 요약하기

Step 1 (Recite): 긴 문서에서 질문과 관련된 핵심 문장만 ‘있는 그대로’ 베껴 쓰게 합니다. (추론 금지, 복사만 시킴)
Step 2 (Reason): 모델이 방금 받아쓰기한 ‘핵심 증거’만 따로 떼어내어, 그것만 보고 최종 답변을 쓰게 합니다.

이 간단한 조치만으로 GPT-4o의 성능이 최대 4% 더 향상되었습니다. 긴 문맥 문제를 억지로 짧은 문맥 문제로 변환해 모델의 ‘주의력(Attention)’을 집중시킨 덕분입니다.

✅ 즉시 적용 가능한 프롬프트 예시

시스템 프롬프트를 아래와 같은 구조로 수정해 보세요.

[지침]
당신은 긴 문서에서 질문에 필요한 '증거'를 찾아야 합니다.

먼저, 질문과 관련된 문장을 원문 그대로 발췌(Recite) 하세요. 
절대 내용을 수정하지 마세요.

그 후, 발췌한 'Evidence' 내용만을 바탕으로 
최종 답변(Answer)을 작성하세요.

[형식]
Evidence: [원문 발췌 내용]
Answer: [최종 답변]

결론: 길이는 여전히 ‘비용’입니다

컨텍스트 윈도우가 늘어났다고 해서 AI의 집중력까지 무한대가 된 것은 아닙니다. 이번 연구는 ‘검색 능력’과 ‘추론 능력’은 별개라는 점을 명확히 보여줍니다.

여러분의 RAG 시스템이 똑똑해지길 원한다면, 더 비싼 모델을 찾기 전에 프롬프트에 들어가는 군더더기부터 쳐내세요. 때로는 ‘더 적게 주는 것’이 AI를 ‘더 똑똑하게’ 만드는 지름길입니다.

“긴 문맥은 AI에게 빅데이터가 아니라 빅노이즈입니다.”

1M 토큰의 함정: LLM 컨텍스트가 길어지면 성능이 떨어지는 이유