중간에서 길을 잃다: 언어 모델의 긴 문맥 활용

중간에서 길을 잃다: 언어 모델의 긴 문맥 활용

긴 입력 속에서 정답이 든 문서의 위치만 바꿔 가며 언어 모델을 시험해 보니, 정답이 맨 앞이나 맨 뒤에 있을 때는 잘 쓰고 가운데에 있으면 크게 못 쓰는 'U자 곡선' 이 나타났다는 분석 논문입니다. 문맥 창이 긴 모델이라고 문맥을 더 잘 쓰는 것도 아니었고, RAG에서 문서를 더 많이 넣어도 성능이 금방 포화됐습니다.

들어가기 전에

이 해설은 아래 내용을 안다고 보고 씁니다. 처음이라면 먼저 읽고 오면 수식과 손계산을 훨씬 쉽게 따라올 수 있습니다.

• 검색 증강 생성 (RAG) — 검색기(DPR)와 생성기(BART)를 함께 미세조정해 문서를 보고 답을 생성하는 RAG의 원조 논문

한눈에 보기

• 언어 모델이 긴 입력의 어느 위치 정보를 잘 쓰고 못 쓰는지, 그 모양(U자 곡선)을 알게 됩니다.
• 위치 효과를 깔끔하게 재는 두 실험 — 다중 문서 QA 와 키-값 찾기 — 의 설계를 이해합니다.
• 모델 구조 · 질문 위치 · 지시 미세조정이 이 현상에 어떤 영향을 주는지 압니다.
• RAG를 만들 때 "문서를 몇 개, 어떤 순서로 넣을지"를 판단하는 실무 기준을 얻습니다.

초록 (번역)

최근 언어 모델은 긴 문맥을 입력으로 받을 수 있게 됐지만, 긴 문맥을 얼마나 잘 활용하는지는 상대적으로 알려진 것이 적습니다. 우리는 입력 문맥에서 관련 정보를 찾아내야 하는 두 과제, 다중 문서 질의응답과 키-값 검색에서 언어 모델의 성능을 분석합니다. 관련 정보의 위치를 바꾸면 성능이 크게 떨어질 수 있음을 발견했는데, 이는 현재 언어 모델이 긴 입력 문맥의 정보를 견고하게 활용하지 못한다는 뜻입니다. 특히 관련 정보가 입력 문맥의 시작이나 끝에 있을 때 성능이 가장 높은 경우가 많고, 긴 문맥의 중간에 있는 관련 정보에 접근해야 할 때는 명시적으로 긴 문맥용으로 만든 모델조차 성능이 크게 떨어집니다. 우리의 분석은 언어 모델이 입력 문맥을 어떻게 활용하는지 더 잘 이해하게 해 주며, 앞으로의 긴 문맥 언어 모델을 위한 새로운 평가 방식을 제시합니다.

무엇을 풀었나

트랜스포머의 계산량은 입력 길이의 제곱으로 늘어서, 예전 언어 모델은 512~2,048토큰 정도의 짧은 문맥으로 학습됐습니다. 하드웨어와 알고리즘이 발전하면서 4K · 32K · 100K 토큰을 받는 모델이 나왔습니다. 문서 전체, 긴 대화 기록, 검색 결과 여러 개를 한꺼번에 넣을 수 있게 된 것입니다.

하지만 "넣을 수 있다"와 "잘 쓴다"는 다릅니다. 이 논문의 질문은 이것입니다. 긴 문맥 속 정보를 모델이 위치와 상관없이 고르게 활용하는가? 만약 그렇다면, 정답이 든 문서를 앞에 두든 가운데 두든 뒤에 두든 성능은 거의 같아야 합니다.

이 질문은 RAG에 바로 연결됩니다. 검색 결과를 몇 개 넣을지, 어떤 순서로 넣을지는 모든 RAG 시스템이 정해야 하는 설계 선택이기 때문입니다.

핵심 아이디어

이 논문은 새 모델을 제안하지 않습니다. 대신 위치 효과를 정확히 재는 통제 실험 을 설계했습니다.

123456789flowchart LR
  Q[NQ 질문] --> G[정답 문서 1개]
  Q --> D[Contriever로 찾은 방해 문서 k-1개]
  G --> P{정답 문서 위치 바꾸기: 1번 · 5번 · 10번 · …}
  D --> P
  P --> CTX[문서 k개를 이어 붙인 입력]
  CTX --> M[언어 모델: 탐욕적 디코딩]
  M --> ACC[정답 문자열 포함 여부 = 정확도]
  ACC --> U[위치별 정확도 곡선]

1. 실험 ① 다중 문서 질의응답

직관. 시험지에 참고 자료 20장을 주는데, 그중 정답이 적힌 건 한 장뿐이고 나머지는 그럴듯하지만 답이 없는 자료입니다. 정답 자료를 1번에 두느냐 10번에 두느냐만 바꿔서 학생의 점수가 어떻게 달라지는지 봅니다.

단계별 설명.

1. NaturalQuestions-Open에서 정답이 '문단'으로 표시된 질문 2,655개를 고릅니다.
2. 정답이 든 위키백과 문단(최대 100토큰) 1개를 준비합니다.
3. Contriever(MS-MARCO 미세조정)로 질문과 관련 깊지만 정답은 없는 문단 $k-1$개를 방해 문서로 가져옵니다(관련도 내림차순 정렬).
4. 정답 문서의 위치 를 바꾸고, 방해 문서 수로 길이 를 바꿉니다(문서 10 · 20 · 30개, 대략 2K · 4K · 6K 토큰).
5. 모델 출력에 정답 문자열이 들어 있으면 맞은 것으로 봅니다.

수식 (설명용 정리). 위치 $i$에 정답 문서를 두었을 때의 정확도를 $\mathrm{Acc}(i)$라 하면, 모델이 문맥을 '견고하게' 쓴다는 것은 다음 차이가 작다는 뜻입니다.

논문은 앞으로 긴 문맥 모델이 "문맥을 잘 쓴다"고 주장하려면 이 최고-최악 차이가 작아야 한다는 평가 기준을 제안합니다.

숫자로 해 보기 (설명용 예시, 논문 수치 아님). 문서 5개 실험에서 위치별 정확도가 $(75, 62, 55, 60, 72)$%라면 $\Delta = 75 - 55 = 20$%p입니다. 가운데(3번)가 가장 낮은 U자 모양입니다. 만약 정답 없이 답하는 정확도가 58%라면, 정답을 3번에 둔 경우(55%)는 문서를 안 주느니만 못한 셈입니다.

두 기준점.

• 닫힌 책(closed-book): 문서 없이 모델 기억만으로 답한 정확도
• 오라클(oracle): 정답 문서 하나만 준 정확도

2. 실험 ② 합성 키-값 찾기

직관. 자연어의 의미를 다 걷어 내고, "이 열쇠 번호에 맞는 값을 그대로 찾아 적어라"만 시킵니다. 이것조차 못한다면 모델은 문맥에서 '찾는 것' 자체가 어렵다는 뜻입니다.

단계별 설명.

1. 키와 값이 모두 무작위 128비트 UUID인 JSON 객체를 만듭니다(키-값 쌍 75 · 140 · 300개, 각 500개 예시).
2. 그중 하나의 키를 주고 해당 값을 출력하게 합니다.
3. 찾을 키의 위치를 바꿔 가며 정확도를 잽니다.

왜 UUID인가. 자연어 단어를 쓰면 모델이 특정 언어 특징에 다르게 반응하는 등 잡음이 끼어들 수 있으므로, 의미를 최대한 없애 '정확히 같은 토큰 찾기' 능력만 봅니다.

3. 무엇이 영향을 주나: 구조 · 질문 위치 · 지시 미세조정

• 모델 구조: 인코더-디코더(Flan-UL2, Flan-T5-XXL)는 학습 때 본 길이 안에서는 위치에 비교적 둔감했습니다(Flan-UL2는 2,048토큰 안에서 최고-최악 차이 1.9%p). 하지만 학습 길이보다 긴 입력에서는 다시 U자 곡선이 나타났습니다. 양방향 인코더가 문서를 질문 맥락 속에서 처리할 수 있기 때문일 것이라고 봅니다.
• 질문을 앞뒤에 모두 두기(query-aware contextualization): 디코더 전용 모델은 앞 토큰만 볼 수 있어, 질문이 맨 뒤에 있으면 문서를 읽는 동안 질문을 모릅니다. 질문을 문서 앞에도 두면 키-값 찾기는 거의 완벽해졌습니다(예: GPT-3.5-Turbo (16K)가 300쌍에서 만점, 없을 때 최악 45.6%). 그러나 다중 문서 QA의 추세는 거의 바뀌지 않았습니다.
• 지시 미세조정: 기본 모델 MPT-30B와 지시 미세조정한 MPT-30B-Instruct 모두 U자 곡선을 보였습니다. 미세조정은 최고-최악 차이를 10%p 가까이에서 약 4%p로 줄였을 뿐입니다. Llama-2 실험에서는 7B는 끝쪽만 잘 쓰는(최신 편향) 모양이었고, 13B · 70B에서 U자 곡선이 나타났습니다.

숫자로 해 보기 (설명용). 질문을 앞뒤에 모두 두면 디코더 전용 모델의 입력은 [질문] [문서1] … [문서k] [질문]이 됩니다. 문서를 읽는 시점에 이미 질문을 봤으므로 "무엇을 찾아야 하는지" 알고 읽게 됩니다. 키-값 찾기처럼 '정확한 문자열 대조'에는 이것만으로 충분했지만, 의미를 이해하고 종합해야 하는 QA에는 부족했습니다.

4. 사례 연구: 문서를 더 넣으면 더 좋아지나

직관. 자료를 많이 줄수록 정답 자료가 들어 있을 확률은 오르지만, 학생이 읽고 골라내야 할 양도 늘어납니다. 어느 순간부터는 자료를 더 줘도 점수가 오르지 않습니다.

단계별 설명.

1. NaturalQuestions-Open 질문으로 Contriever가 위키백과에서 상위 $k$개 문서를 검색합니다(이번에는 정답 문서가 0개일 수도, 여러 개일 수도 있음).
2. $k$를 늘려 가며 검색 재현율 (정답 문서가 $k$개 안에 있는 비율)과 모델 정확도 를 함께 봅니다.

결과. 모델 성능은 검색 재현율보다 훨씬 먼저 포화됐습니다. 문서를 20개에서 50개로 늘려도 GPT-3.5-Turbo는 약 1.5%, Claude-1.3은 약 1%만 올랐습니다.

결과

닫힌 책 · 오라클 정확도 (다중 문서 QA)

위치 효과 (다중 문서 QA)

• 모든 모델에서 정답 문서가 맨 앞(초두 편향) 또는 맨 뒤(최신 편향)일 때 가장 잘했고, 가운데일 때 크게 떨어지는 U자 곡선이 나타났습니다.
• GPT-3.5-Turbo는 위치에 따라 20% 넘게 떨어졌고, 문서 20 · 30개 설정의 최악 위치에서는 닫힌 책 성능(56.1%)보다도 낮았습니다. 문서를 넣은 것이 오히려 손해였던 셈입니다.
• 긴 문맥 버전이 더 낫지 않았습니다. 입력이 두 모델의 문맥 창에 모두 들어가는 경우(예: 문서 10 · 20개에서 GPT-3.5-Turbo와 16K 버전), 위치별 성능 곡선이 거의 겹쳤습니다.
• GPT-4(8K)로 일부 실험을 했을 때도 절대 성능은 높았지만 비슷한 추세였습니다.

키-값 찾기

• Claude-1.3과 Claude-1.3 (100K)는 모든 길이에서 거의 완벽했습니다.
• 다른 모델은 특히 140 · 300쌍에서 어려워했고, GPT-3.5-Turbo · GPT-3.5-Turbo (16K) · MPT-30B-Instruct는 가운데 키를 찾을 때 가장 낮았습니다.

왜 중요한가 · 이후 영향

• RAG 실무의 상식이 됐습니다. "가장 관련 있는 문서를 문맥의 앞(또는 끝)에 두라", "문서를 무작정 많이 넣지 말고 재순위 · 압축으로 줄여라"는 조언의 대표 근거입니다.
• 긴 문맥 모델 평가 기준을 바꿨습니다. 문맥 창 크기만이 아니라 '위치에 따른 성능 차이'를 함께 보고해야 한다는 평가 방식을 제안했고, 이후 '건초 더미 속 바늘(needle in a haystack)' 같은 위치별 평가가 널리 쓰이는 흐름과 맞닿아 있습니다.
• 사람의 기억과 닮은 현상 이라는 점도 흥미롭습니다. 목록의 처음과 끝을 잘 기억하는 심리학의 계열 위치 효과(serial-position effect)와 비슷한 모양이 나타났습니다. 셀프 어텐션은 원리상 어느 토큰이든 똑같이 볼 수 있는데도 그렇다는 점이 놀랍다고 논문은 말합니다.

실무에서 바로 해 볼 점 (이 논문 결과에서 끌어낸 해설).

1. 검색 결과를 넣을 때 재순위 점수가 가장 높은 문서를 맨 앞에 둡니다.
2. 문서 개수를 늘리기 전에, 늘렸을 때 실제 정확도가 오르는지 작은 평가 세트로 확인합니다.
3. 질문을 문서 앞에도 한 번 적어 두면, 정확한 값 찾기 같은 과제에서는 효과가 클 수 있습니다.
4. 쓰려는 모델로 '정답 위치만 바꾼' 간단한 시험을 돌려, 그 모델의 U자 곡선이 얼마나 깊은지 직접 재 봅니다.

한계 · 주의할 점

• 2023년 모델 기준의 측정입니다. GPT-3.5-Turbo, Claude-1.3, MPT-30B 등 당시 모델을 평가했습니다. 이후 모델들은 긴 문맥 활용이 개선됐을 수 있으므로, 쓰는 모델에서 직접 위치 효과를 확인하는 것이 좋습니다.
• 원인 분석은 예비적입니다. 구조 · 질문 위치 · 지시 미세조정의 영향을 살폈지만, U자 곡선이 생기는 근본 원인을 확정하지는 않았습니다.
• 과제 범위: 단일 정답 문서가 있는 QA와 합성 키-값 찾기 위주입니다. 여러 문서를 종합해야 하는 과제에서는 양상이 다를 수 있습니다.
• 방해 문서의 성질: 질문과 관련 깊은 방해 문서를 일부러 넣었기 때문에, 실제 검색 결과의 분포와는 차이가 있을 수 있습니다(논문은 무작위 순서 등 변형 실험에서도 같은 추세를 확인했다고 밝힙니다).

스스로 점검

1. 정답 문서 위치별 정확도가 (70, 58, 52, 61, 68)%일 때 최고-최악 차이는? 어떤 모양인가요?

   $70 - 52 = 18$%p이고, 가운데가 가장 낮은 U자 모양입니다.

2. 질문을 문서 앞뒤에 모두 두는 방법이 키-값 찾기에는 효과가 컸지만 QA에는 작았던 이유는?

   디코더 전용 모델이 문서를 읽기 전에 무엇을 찾을지 알게 되어 정확한 문자열 대조는 쉬워졌지만, QA는 의미를 이해하고 쓰는 과정이 필요해 위치 효과가 그대로 남았습니다.

3. RAG에서 문서를 20개에서 50개로 늘리면 어떻게 됐나요? 실무 시사점은?

   검색 재현율은 오르지만 모델 정확도는 GPT-3.5-Turbo 약 1.5%, Claude-1.3 약 1%만 올랐습니다. 문서 수를 늘리기보다 재순위로 좋은 문서를 앞에 두고 개수를 줄이는 편이 효율적입니다.

용어 정리

이어서 읽을 것

• 앞: 밀집 문단 검색 (DPR) · Contriever · Fusion-in-Decoder
• 뒤: RAPTOR · 교정 검색 증강 생성 (CRAG) · RAG 총정리 (서베이)

다음에 볼 것

이 글을 이해했다면 이어서 보면 좋은 항목입니다.

• 직접 해 보기: 작은 RAG 만들기 (BM25 + 벡터 + RRF + 평가) — 검색 · 융합 · 평가를 코드로 직접 돌려 보는 실습
• 대형 언어 모델을 위한 RAG 총정리 (서베이) — RAG를 Naive·Advanced·Modular로 나누고 검색·생성·증강 기법과 평가를 정리한 서베이

출처

• 원문: arxiv.org/abs/2307.03172 (2023 · Nelson F. Liu 외)