인사이트
긴 문서를 읽는 AI는 왜 중요한 내용을 놓칠까? ― ‘Lost in the Middle’ 문제와 위슬리의 개선 전략
Dec 30, 2025
긴 문서를 AI에게 맡기면, 정말 더 정확해질까?
사내 문서 검색이나 질의응답에 AI를 적용할 때 가장 흔하게 드는 생각은 이것입니다.
“관련 정보를 최대한 많이 주면 AI가 더 정확한 답을 하지 않을까?”
하지만 실제 운영 환경에서는 이 직관이 항상 맞지 않습니다.
오히려 문서가 길어질수록,
또는 한 번에 제공하는 정보량이 늘어날수록
AI의 답변 정확도가 떨어지는 경우를 자주 마주하게 됩니다.
이 현상은 최근 연구와 실무 사례에서 공통적으로 관찰되는 ‘Lost in the Middle’ 문제와 깊은 관련이 있습니다.
'Lost in the Middle' 현상이란?
대형 언어 모델(LLM)은 이제 수만, 수십만 토큰에 이르는 긴 문서를 입력으로 처리할 수 있습니다.
그러나 처리 가능하다는 것과 효과적으로 활용한다는 것은 다른 문제입니다.
여러 연구에 따르면 LLM은 컨텍스트 길이가 길어질수록 중간 부분의 정보 활용 능력이 떨어지는 경향을 보입니다.
문서 앞부분의 정보 → 잘 활용
문서 뒷부분의 정보 → 잘 활용
문서 중간에 위치한 정보 → 활용도가 급격히 감소
즉, 성능이 U자형 곡선을 그리며 중앙부 정보에서 가장 취약해지는 현상이 발생합니다.
이를 ‘Lost in the Middle’이라고 부릅니다.
중요한 점은 이 문제가 단순히 컨텍스트 길이가 부족해서가 아니라는 것입니다.
GPT-4, Claude 등 초장문 모델에서도 동일한 패턴이 반복적으로 관찰됩니다.
왜 이런 현상이 발생할까?
이 문제의 핵심은 LLM이 긴 문맥을 ‘읽는 방식’에 있습니다.
LLM은 긴 문서를 처음부터 끝까지 정독하지 않습니다.
대신 문맥의 앞부분과 끝부분을 통해
“이 문맥이 어떤 종류의 질문인지”,
“어떤 방향의 답을 기대하는지”를 빠르게 추론합니다.
그 과정에서 문서 중간에 위치한 정보는 상대적으로 중요 신호로 인식되지 못하고 우선순위에서 밀려나기 쉽습니다.
결국 이는 Transformer 계열 모델의 주의력 분포가 토큰의 물리적 위치에 영향을 크게 받는 구조적 한계로 볼 수 있습니다.
문서 기반 RAG에서 특히 치명적인 이유
이 현상은 일반적인 대화형 AI보다 문서 기반 RAG(Retrieval-Augmented Generation) 환경에서 훨씬 더 큰 문제를 일으킵니다.
기업 문서는 대부분 길고 구조가 복잡하며
핵심 정보가 본문 중간에 위치하는 경우가 많고
RAG 파이프라인에서는 여러 문서·청크를 한 번에 모델에 전달하는 경우가 잦기 때문입니다.
실제로 문서를 많이 넣을수록:
중간에 위치한 청크들이 무시되고
답변 정확도가 떨어지며
토큰 비용만 증가하는 상황이 발생합니다.
“충분한 문맥을 제공했는데도 답이 틀리는” 아이러니한 상황이 여기서 만들어집니다.
기존 접근 방식의 한계
이 문제를 완화하기 위해 다양한 컨텍스트 엔지니어링 기법이 제안되어 왔습니다.
중요 정보 재배치: 답변에 결정적인 문서나 문장을 프롬프트 앞이나 끝에 배치해 모델의 주의를 집중시킵니다. 단순한 컨텍스트 순서 조정만으로도 추가 비용 없이 성능을 개선할 수 있습니다.
검색 결과 선별 활용: 검색된 결과 전체를 쓰기보다, 중요도 기준으로 재정렬한 뒤 상위 일부만 컨텍스트로 선택해 사용합니다. 이는 재배치 전략을 확장한 방식으로, 불필요한 정보는 제거하고 핵심만 남기는 데 목적이 있습니다.
프롬프트 압축: 중복되거나 중요도가 낮은 내용을 제거·요약해 프롬프트 길이를 줄이고, 모델이 핵심 정보에 집중하도록 합니다.
이 외에도 초장문 특화 모델을 추가로 미세튜닝하는 연구, 위치 임베딩을 조정하는 기법 등 다양한 시도가 계속되고 있습니다.
그러나 완벽한 해결책은 아직 없으며, 현실적으로는 위 전략들을 조합해 점진적으로 개선하는 추세입니다.
위슬리의 접근
Retrieval 결과를 “줄이고, 재구성하다”
문서 RAG에서 흔히 발생하는 문제 중 하나는
검색 단계는 정확한데, 답변 단계에서 성능이 무너지는 경우입니다.
위슬리 팀이 내부 분석을 통해 확인한 원인은 명확했습니다.
검색 정확도보다 더 큰 문제는 “검색된 결과를 LLM에게 “어떻게 전달하느냐”였다.
문제 1: “많이 찾는 것”이 오히려 독이 된다
초기 RAG 파이프라인에서는 벡터 검색 결과 상위 20~30개 청크를 그대로 LLM에 전달하고 있었습니다.
이 방식에는 두 가지 문제가 있었습니다.
중요하지 않은 청크가 주의력을 분산
답에 결정적인 청크가 컨텍스트 중앙에 묻혀 사라짐
즉, 검색 단계에서는 Recall이 높아졌지만
LLM 입장에서는 “무엇이 중요한지 알기 어려운 컨텍스트”가 된 것입니다.
해결 전략 1: Retrieval은 Recall, 컨텍스트는 Precision
위슬리는 Retrieval 단계와 LLM 입력 단계의 역할을 의도적으로 분리했습니다.
Retrieval 단계
LLM 입력 컨텍스트
이를 위해 다음과 같은 구조를 적용했습니다.
검색 단계에서는 비교적 넓게 후보를 수집
이후 별도의 기준으로 후보를 다시 압축
최종적으로 5개 이하의 핵심 청크만 LLM에 전달
이렇게 함으로써 LLM이 실제로 “집중해서 읽을 수 있는” 컨텍스트만 남겼습니다.
해결 전략 2: 중요도 ≠ 유사도, 그래서 재정렬이 필요하다
벡터 검색 결과는 기본적으로 질의와의 의미적 유사도 순으로 정렬됩니다.
하지만 위슬리 팀의 실험 결과,
“유사도가 가장 높은 청크”와 “답변에 가장 결정적인 청크”는 반드시 일치하지 않았습니다.
그래서 단순 유사도 순 정렬 대신, 다음 요소를 종합해 출력 순서를 재구성했습니다.
질의 의도와의 직접성
해당 청크가 결론·정의·수치를 포함하는지
다른 청크들과의 정보 중복 여부
이 과정은 LangChain의 LongContextReorder 개념과 유사하지만,
위슬리의 문서 구조와 질의 유형에 맞게 자체 기준으로 커스터마이징되었습니다.
해결 전략 3: “가장 중요한 청크는 맨 마지막에 둔다”
재정렬의 핵심 규칙은 단순합니다.
답을 포함할 가능성이 가장 높은 청크를 프롬프트의 끝부분에 배치한다
이는 ‘Lost in the Middle’ 연구에서 확인된 LLM의 최근 효과(Recency Bias)를 의도적으로 활용한 설계입니다.
LLM은 답변을 생성하기 직전에 읽은 정보를 가장 잘 활용하는 경향이 있기 때문에,
결정적인 청크를 마지막에 두면 답변 생성 시 해당 정보가 자연스럽게 반영됩니다.
적용 결과
개선된 구조를 적용한 이후,
위슬리 서비스의 응답 정확도와 사용자 만족도 모두 뚜렷하게 개선되었습니다.
내부 평가 셋으로 질의응답 테스트를 진행한 결과, 전체 정답률(Accuracy)은 약 15%p 향상되었습니다.
특히 답이 문서 중간에 위치한 질의에서 응답 성공률이 눈에 띄게 높아졌습니다.
실제 사용자 피드백에서도 긍정적인 변화가 확인되었습니다.
평균 답변 만족도 점수는 4.1/5에서 4.5/5로 상승했으며,
“이전에는 찾기 어려웠던 세부 내용까지 답변에 잘 포함된다”는 의견이 다수 접수되었습니다
성능 개선은 정확도에만 그치지 않았습니다.
불필요한 청크가 줄어들면서, 질문당 평균 검색 시간이 20% 이상 단축되었습니다.
LLM에 전달되는 토큰 수도 감소해 API 비용 절감이라는 부수적인 효과도 얻을 수 있었습니다.
이러한 컨텍스트 재정렬과 압축 덕분에, 동일한 모델 환경(Gemini 3.0, Claude 4.5 Sonnet)에서도 이전보다 더 안정적이고 완성도 높은 답변을 제공할 수 있게 되었습니다.
마치며
물론 이러한 개선에도 불구하고 'Lost in the Middle' 현상이 완전히 사라진 것은 아닙니다.
여전히 매우 긴 문서를 다룰 때는 복잡한 추론이 필요한 경우 일부 중간 맥락을 놓치는 사례가 존재합니다.
그러나 최신 연구의 기법들을 접목함으로써 현저한 성능 개선을 이루었고, 사용자 입장에서 체감할 수 있을 정도로 답변의 정확성과 완성도가 높아진 것은 고무적입니다.
위슬리 팀은 앞으로도 컨텍스트 처리 최적화에 대한 최신 연구 동향을 빠르게 도입하여, 남은 한계들도 극복해 나갈 계획입니다.
추천 콘텐츠
