Lost in the Middle: LLM은 왜 긴 글의 중간을 기억하지 못할까?

Lost in the Middle: LLM은 왜 긴 글의 중간을 기억하지 못할까?

대규모 언어 모델(LLM) 기반의 챗봇에게 긴 보고서나 여러 문서를 주고 요약을 요청했을 때, 어딘가 중요한 내용이 빠진 듯한 느낌을 받은 적이 있으신가요? 이는 단순히 모델의 실수가 아니라, 현재 LLM 기술이 가진 흥미로운 한계를 보여주는 현상입니다. LLM이 긴 문맥(Context)의 중간에 있는 정보를 제대로 활용하지 못하는 이 문제를 'Lost in the Middle' 이라고 부릅니다. 이 현상은 '건초더미에서 바늘 찾기(Needle-in-a-Haystack)'라는 유명한 테스트를 통해 널리 알려졌습니다. 이 테스트는 Paul Graham의 에세이들을 취합하여 최대 128K 토큰에 가까운 긴 문서를 준비하고, 문서 내에 "샌프란시스코에서 가장 좋은 것은 화창한 날 돌로레스 공원에 앉아 샌드위치를 먹는 것이다"와 같이 전체 맥락과 무관한 특정 문장(바늘)을 숨겨두고, 모델이 이 문장을 찾아내는지 시험하는 방식입니다. 놀랍게도 GPT-4와 같은 최신 LLM들조차 이 '바늘'이 글의 중간 부분에 있을 때 찾아내지 못하는 경향을 보였습니다. 그렇다면 LLM은 왜 이런 모습을 보이는 걸까요? 이번 글에서는 그 원인과 의미를 개념, 예시, 비유를 통해 쉽게 파헤쳐 보겠습니다.

---

기억의 U자 곡선: 시작과 끝만 기억하는 LLM의 편향성

'Lost in the Middle' 현상의 핵심은 LLM의 정보 처리 능력이 정보의 위치에 따라 달라진다는 점입니다. 마치 사람이 긴 강의를 들을 때, 맨 처음 도입부와 마지막 결론은 선명하게 기억하지만 중간 내용은 희미해지는 것과 유사합니다.

개념: U자형 성능 곡선 (U-shaped Performance Curve)
LLM의 성능은 중요 정보가 입력된 프롬프트의 시작(초두 효과, Primacy Bias)이나 끝(최신 효과, Recency Bias)에 있을 때 가장 높고, 중간 부분으로 갈수록 현저히 떨어지는 패턴을 보입니다. 이를 그래프로 그리면 양 끝이 높고 가운데가 움푹 파인 U자 모양이 되어 'U자형 성능 곡선'이라고 부릅니다.

비유: 긴 소설책을 읽는 독자
한 권의 두꺼운 소설책을 다 읽고 난 후를 상상해 보세요. 소설의 흥미진진했던 첫 장면과 충격적인 결말은 생생하게 떠오르지만, 중간 부분의 세세한 사건 전개나 등장인물의 대사는 가물가물할 수 있습니다. LLM도 마찬가지로, 긴 문맥이라는 '책'을 읽을 때 시작과 끝에 있는 정보에 더 강하게 집중하고 중간 부분의 정보는 '잃어버리는' 경향을 보입니다.

예시: 다중 문서 질의응답 실험
연구진은 이 현상을 증명하기 위해 NaturalQuestions-Open 데이터셋을 활용한 '다중 문서 질의응답' 실험을 설계했습니다.

• 실험 설계: 모델에게 하나의 질문과 k개의 위키피디아 문단을 함께 제공합니다. 이 중 단 하나의 문서에만 정답이 포함되어 있고, 나머지 k-1개는 질문과 관련은 있지만 정답이 없는 '방해꾼(distractor)' 문서입니다.
• 측정 방식: 정답이 포함된 문서의 위치를 입력 프롬프트의 맨 앞, 중간, 맨 뒤로 옮겨가며 모델의 정답률을 측정했습니다.
• 결과: GPT-3.5-Turbo, Claude-1.3, 심지어 GPT-4까지 대부분의 LLM이 정답 문서가 프롬프트의 시작이나 끝에 있을 때 가장 높은 성능을 보였고, 중간에 있을 때는 성능이 최대 20% 이상 급격히 하락했습니다. 극단적인 경우에는 문서 없이 질문에만 답변하는 것(closed-book)보다 더 낮은 성능을 보이기도 했습니다. 이는 컨텍스트 창(Context Window)이 10만 토큰이 넘는 모델에서도 동일하게 나타나, 단순히 처리 용량의 문제가 아님을 시사합니다.

---

원인 심층 분석: LLM의 기억력 한계는 어디까지인가?

연구진은 이 현상이 단순히 복잡한 문서를 이해하는 과정에서 발생하는 문제인지, 아니면 모델의 근본적인 정보 검색 능력의 한계인지를 확인하기 위해 추가 실험을 진행했습니다.

키-값 검색 (Key-value Retrieval): 순수한 검색 능력 테스트
자연어의 복잡성을 배제하고 모델의 순수한 정보 검색 능력을 시험하기 위해, k개의 키-값 쌍을 포함하는 텍스트 형태의 JSON 데이터를 주고 특정 키에 해당하는 값을 찾도록 했습니다. 모든 키와 값은 고유한 랜덤 UUID로 구성되어 자연어 이해 능력이 아닌 순수한 검색 능력만을 평가했습니다. 그 결과, Claude-1.3과 Claude-1.3 (100K)는 거의 완벽한 성능을 보였지만, GPT-3.5-Turbo, MPT-30B-Instruct 등 다른 모델들은 이 단순화된 실험에서도 U자형 성능 곡선을 보였습니다. 이는 'Lost in the Middle' 현상이 문맥의 의미 해석뿐 아니라, 긴 시퀀스 내에서 특정 정보의 위치를 찾아내는 기본적인 능력과도 관련 있음을 보여줍니다.

모델 아키텍처의 영향
GPT와 같은 '디코더-전용(Decoder-only)' 모델과 T5와 같은 '인코더-디코더(Encoder-Decoder)' 모델을 비교한 결과, 흥미로운 차이점이 발견되었습니다. 인코더-디코더 모델(Flan-T5-XXL, Flan-UL2)은 인코더가 입력 전체를 양방향으로 볼 수 있기 때문에 컨텍스트 창 내에서는 정보의 위치에 비교적 영향을 덜 받았습니다. 예를 들어, Flan-UL2의 경우 최악과 최선의 성능 차이가 1.9%에 불과했습니다. 하지만 처리 가능한 길이를 넘어서는 긴 입력이 주어지자 이 모델들 역시 U자형 성능 곡선을 보였습니다.

모델 크기의 영향: 크면 클수록 심해지는 편향성
Llama-2 모델의 크기(7B, 13B, 70B)를 달리하여 실험한 결과, U자형 성능 곡선은 13B 이상의 충분히 큰 모델에서 뚜렷하게 나타났습니다. 반면 가장 작은 7B 모델은 주로 입력의 끝부분만 기억하는 '최신 효과(Recency Bias)'만을 강하게 보였습니다. 이는 시작과 끝을 모두 잘 기억하는 U자형 패턴이 모델의 규모가 커지면서 나타나는 일종의 '창발적 특성(Emergent Property)'일 수 있음을 시사합니다.

Query-aware Contextualization의 효과
연구진은 쿼리(질문 또는 검색할 키)를 문서 전후에 배치하는 Query-aware Contextualization 기법의 효과를 테스트했습니다. 키-값 검색 작업에서는 모든 모델이 75, 140, 300 키-값 쌍에서 거의 완벽한 성능을 달성하는 극적인 향상을 보였습니다. 하지만 다중 문서 질의응답 작업에서는 제한적인 영향만을 미쳤는데, 이는 단순한 검색 작업에는 효과적이지만 더 복잡한 추론이 필요한 작업에서는 한계가 있음을 시사합니다.

---

실용적 함의: 더 많은 정보가 항상 정답일까?

이 연구는 우리에게 중요한 질문을 던집니다. LLM에게 더 많은 문맥을 제공하는 것이 항상 성능 향상으로 이어질까요? 연구진은 검색 시스템(Retriever)이 찾아준 문서들을 LLM(Reader)이 읽고 답하는 환경에서, 제공하는 문서의 수를 늘려가며 정확도를 측정했습니다.

• 성능 포화 현상: Reader 모델의 성능은 Retriever recall이 포화되기 훨씬 전에 포화되었습니다. 이는 Reader 모델이 추가로 검색된 문서를 효과적으로 활용하지 못한다는 것을 의미합니다.
• 제한적인 개선 효과: 20개 이상의 검색된 문서를 사용하는 것은 Reader 성능을 미미하게만 향상시켰습니다. GPT-3.5-Turbo는 약 1.5%, Claude-1.3은 약 1% 향상에 그쳤습니다.

비유: 중요한 회의 전 참고 자료
중요한 회의를 앞두고 핵심 요약 보고서 5개를 받는 것과, 관련 있을 법한 자료 100개를 통째로 받는 것을 비교해 봅시다. 자료가 많을수록 정보는 풍부해지겠지만, 정작 핵심을 파악하기는 더 어려워지고 중요한 내용을 놓칠 수 있습니다. LLM도 마찬가지로, 무작정 많은 정보를 주기보다는 핵심 정보를 효과적으로 전달하는 전략이 필요합니다.

---

해결 방안과 최적화 전략

연구 결과를 바탕으로 멀티 에이전트 서비스를 만들 때, 다음과 같은 실용적인 해결 방안들을 제안할 수 있습니다.

효과적인 재순위화 (Effective Reranking)
관련 정보를 입력 프롬프트의 시작 부분에 더 가깝게 배치하는 전략입니다. 검색 시스템이 찾아낸 문서들 중 가장 중요한 것들을 프롬프트의 앞부분에 배치하여 모델이 놓치지 않도록 합니다.

적절한 문서 수 제한 (Ranked List Truncation)
무작정 많은 문서를 제공하기보다는, 적절한 경우 더 적은 수의 고품질 문서를 검색하는 것이 효과적입니다. 연구 결과에 따르면 20개 이상의 문서는 성능 향상에 거의 기여하지 않습니다.

프롬프트 구조 최적화
가장 중요한 정보나 핵심 질문, 지시사항을 입력의 맨 앞이나 맨 뒤에 배치하는 것이 효과적입니다. 이는 모델이 정보를 '잃어버리지' 않고 우리의 의도를 명확하게 파악하도록 돕는 간단하면서도 강력한 방법입니다.

---

마무리하며

'Lost in the Middle' 현상은 최신 LLM들이 긴 문맥을 처리하는 능력에 명백한 한계가 있음을 보여줍니다. 이는 단순히 컨텍스트 창의 크기를 늘리는 것만으로는 해결되지 않는, 모델 아키텍처와 학습 방식에 내재된 문제입니다. 심지어 확장된 컨텍스트 창을 가진 모델들(예: GPT-3.5-Turbo 16K)도 기본 모델과 거의 동일한 성능을 보였습니다. 이 연구는 LLM을 사용하는 개발자와 연구자들에게 중요한 교훈을 줍니다. 현재 기술 수준에서는 정보의 양보다는 "질과 배치"가 더 중요하며, 모델의 한계를 이해하고 이에 맞는 전략을 수립하는 것이 필요합니다.

---

https://arxiv.org/abs/2307.03172

Lost in the Middle: How Language Models Use Long Contexts