거대 언어 모델(LLM)이 사실이 아닌 내용을 그럴듯하게 지어내는 '환각(Hallucination)' 현상은 인공지능의 실제 서비스 적용을 가로막는 가장 큰 장벽 중 하나입니다. 현재 산업계에서는 이를 해결하기 위해 외부 지식 베이스에서 관련 문서를 검색해 모델의 프롬프트에 함께 제공하는 RAG(검색 증강 생성, Retrieval-Augmented Generation) 기술을 표준처럼 사용하고 있습니다.
그렇다면 여기서 근본적인 질문을 던져볼 수 있습니다. "검색을 통해 최대한 많은 문서를 찾아 LLM의 컨텍스트 창(Context Window)에 밀어 넣으면 환각 문제가 완전히 해결될까요?"
스탠포드 대학교 연구진이 발표한 논문 "Lost in the Middle: How Language Models Use Long Contexts"는 이 질문에 대해 구조적인 한계를 지적하며 "아니오"라고 답합니다. 이번 파트에서는 현재 LLM들이 긴 문맥을 처리할 때 겪는 인지적 한계와, 단순한 검색량 확장의 함정을 분석해 봅니다.
1. "가운데는 잊어버렸습니다": U자형 성능 곡선 (Lost in the Middle)
연구진은 LLM이 입력된 긴 문맥 속의 정보를 얼마나 잘 활용하는지 평가하기 위해 '다중 문서 질의응답(Multi-document QA)' 실험을 진행했습니다. 질문에 대한 정답이 포함된 문서 1개와 정답이 없는 방해 문서(Distractor) 여러 개를 프롬프트에 넣고, 정답 문서의 '위치'를 맨 앞부터 맨 뒤까지 바꿔가며 정답률을 측정한 것입니다.
실험 결과, LLM의 정보 처리 능력에서 매우 뚜렷한 U자형 성능 곡선이 발견되었습니다.
- 초두 효과 (Primacy bias): 관련 정보가 프롬프트의 맨 처음에 위치할 때 모델은 가장 높은 성능을 보였습니다.
- 최신 효과 (Recency bias): 관련 정보가 프롬프트의 맨 마지막(즉, 질문과 가장 가까운 곳)에 위치할 때도 비교적 높은 성능을 유지했습니다.
- 가운데의 상실 (Lost in the Middle): 하지만 정답 정보가 프롬프트의 '중간'에 위치할 때, 모델은 해당 정보를 심각하게 놓치며 성능이 급격히 저하되었습니다.
특히 주목할 만한 점은, 정답이 중간에 끼어 있을 때의 성능이 아무런 문서도 주지 않고 모델의 내재된 기본 지식만으로 풀게 했을 때(Closed-book)의 성능보다 오히려 더 낮아지는 현상이 관찰되었다는 것입니다.
💡 미니 실험: 의미 없는 텍스트에서도 가운데를 잊어버릴까?
연구진은 이 현상이 모델의 단순한 '독해력' 부족 때문인지 확인하기 위해 자연어가 배제된 '키-값(Key-Value) 검색 실험'을 추가로 진행했습니다. 수백 개의 무의미한 JSON 데이터 속에서 특정 키의 값을 찾게 한 결과, Claude 등 일부 모델은 이를 완벽히 수행했지만 GPT-3.5를 포함한 대부분의 모델은 정보가 중간에 위치할 때 여전히 U자형 성능 하락을 보였습니다. 이는 LLM이 긴 문맥 속에서 정보를 '검색'하고 '추출'하는 기본 능력 자체가 취약함을 증명합니다.
2. 왜 모델은 가운데를 놓치는 걸까? 디코더 전용(Decoder-only) 아키텍처의 한계
논문은 이러한 정보 누락 현상의 근본적인 원인 중 하나로 최신 모델들의 '아키텍처 설계'를 지목합니다.
[Image comparing decoder-only attention mechanism (left-to-right causal masking) with encoder-decoder bidirectional attention]
현재 대세가 된 GPT, Llama 등의 모델은 대부분 '디코더 전용(Decoder-only)' 구조를 채택하고 있습니다. 이 구조는 텍스트를 오직 '왼쪽에서 오른쪽으로만(Left-to-Right)' 읽어 나가며 다음 단어를 예측하도록 최적화되어 있습니다.
반면, 훈련 과정에서 문맥을 양방향(Bidirectional)으로 동시에 읽고 이해할 수 있는 '인코더-디코더(Encoder-Decoder)' 기반 모델(예: Flan-UL2)들은 자신이 훈련받은 컨텍스트 길이 내에서는 정보의 위치가 바뀌어도 상대적으로 안정적인 성능을 유지했습니다. 즉, 효율성 면에서 압도적인 디코더 전용 LLM 구조가 본질적으로 '긴 문맥 내에서 정보의 상대적 위치에 따른 중요도를 파악하는 데' 태생적인 한계를 지니고 있다는 뜻입니다.
3. 확장된 컨텍스트의 역설: 입력창 크기와 이해도는 비례하지 않는다
최근 AI 모델들은 16K, 32K, 심지어 100K 토큰 이상의 방대한 컨텍스트 창을 지원합니다. "문맥 창이 큰 모델을 쓰면 해결되지 않을까?"라고 기대하기 쉽지만, 연구 결과는 이러한 예상을 빗나갑니다.
연구진은 16K를 지원하는 GPT-3.5-Turbo (16K) 모델과 100K를 지원하는 Claude-1.3 (100K) 모델을 대상으로 실험한 결과, 각각의 기본 모델(Base model, 4K 또는 8K)과 성능 차이가 없음을 확인했습니다. 입력된 전체 텍스트가 확장된 모델과 기본 모델의 컨텍스트 창 모두에 여유 있게 들어갈 수 있는 상황에서도 성능 곡선은 거의 완벽하게 겹쳐 나타났습니다.
즉, 입력창이 커졌다는 것은 '물리적으로 더 많은 데이터를 넣을 수 있다'는 뜻일 뿐, 모델이 그 데이터를 '균일하고 완벽하게 이해한다'는 뜻은 아님을 시사합니다.
4. 실전 RAG 시스템을 위한 3가지 최적화 전략
이러한 발견은 RAG 시스템 설계에 매우 중요한 실무적 시사점을 제공합니다. 단순히 검색 문서 개수()를 늘리는 것은 환각을 줄이는 정답이 아닙니다. 논문의 발견을 토대로 다음과 같은 구체적인 최적화 전략을 적용할 수 있습니다.
① 질문(Query)의 양방향 배치 (Query-Aware Contextualization)
텍스트를 한 방향으로만 읽는 디코더 모델의 한계를 보완하기 위해, 사용자의 질문을 프롬프트의 맨 위(문서 시작 전)와 맨 아래(문서 끝난 후)에 중복해서 배치해 보세요. 연구 결과, 이렇게 쿼리를 인식시킨 것만으로도 단순 정보 검색 능력이 완벽에 가깝게 향상되었습니다.
② 검색 결과 재배치 (Reranking)
벡터 검색 엔진이 찾아온 문서들의 순서를 모델이 가장 잘 읽는 위치로 강제 조정해야 합니다. 가장 관련성이 높은 핵심 문서를 프롬프트의 맨 처음이나 맨 끝(질문과 가장 가까운 곳)에 배치하고, 상대적으로 덜 중요한 문서를 중간에 몰아넣어 '가운데의 상실'로 인한 피해를 구조적으로 최소화해야 합니다.
③ 과감한 문서 자르기 (Truncation)
연구진의 실험에 따르면, 모델에게 20개의 문서를 주었을 때와 50개의 문서를 주었을 때의 정답률 차이는 불과 1~1.5% 수준의 향상에 그쳤습니다. 무작정 많은 문서를 넣는 것은 환각 유발 가능성을 높일 뿐만 아니라, 토큰 비용과 응답 지연 시간(Latency)을 막대하게 낭비할 뿐입니다. 최적의 개수(Top-)를 찾아 과감히 잘라내는 것이 효율적입니다.
다음 파트를 위한 예고: 검색이 정답일까?
재배치(Reranking)와 과감한 자르기(Truncation)는 현재의 RAG 시스템에서 즉각적으로 도입할 수 있는 훌륭한 물리적 조치입니다. 하지만 여기에는 여전히 근본적인 의문이 남습니다. 만약 검색 엔진이 찾아온 10개의 문서 자체가 모두 오답이거나 노이즈라면 어떻게 될까요? 아무리 순서를 잘 배치해도, 모델은 결국 쓰레기 정보를 바탕으로 환각을 만들어낼 수밖에 없습니다.
결국 문서의 개수나 순서를 조절하는 수동적인 방법을 넘어, LLM 스스로 '이 질문에 검색이 필요한지, 그리고 가져온 문서가 진짜 쓸모 있는지' 판단하게 만들어야 합니다.
다음 [Part 2. 무조건 검색하지 마라, 스스로 판단하고 비판하라 (Self-RAG)] 편에서는 외부 지식에 끌려다니지 않고 스스로 검열하는 능동적 RAG의 진화를 살펴보겠습니다.
