Lost in the Middle 논문 리뷰: 긴 문맥의 위치에 따라 달라진 성능

Lost in the Middle: How Language Models Use Long Contexts(arXiv:2307.03172 v3) 논문은 입력 문맥의 길이와 관련 정보의 위치를 통제해 바꾸는 방식으로 언어 모델이 긴 문맥을 얼마나 잘 쓰는지 측정했습니다 (GitHub, arXiv). 저자들은 정답 정보가 문맥 맨 앞이나 맨 끝에 있을 때 성능이 높고 가운데에 있을 때 떨어지는 U자형 곡선을 보고했습니다 (arXiv). 이 결과는 논문에서 평가한 모델에 대한 저자 보고값이며, 최신 모델에도 같은 경향이 있는지는 원문에서 다루지 않습니다.

연구 질문: 긴 문맥을 받는 것과 쓰는 것은 다르다

연구의 출발점은 최근 언어 모델이 긴 문맥을 입력으로 받을 수는 있지만, 그것을 얼마나 잘 쓰는지는 거의 알려지지 않았다는 점입니다 (arXiv). 저자들은 모델이 긴 문맥을 강건하게 쓴다면 관련 정보가 어디에 있든 성능이 거의 영향을 받지 않아야 한다는 판정 기준을 세웠습니다 (arXiv).

확인한 논문 판은 arXiv:2307.03172 v3이며, cs.CL(계산 언어학) 분류로 2023년 11월 20일 날짜가 표기되어 있습니다 (arXiv). 저자는 Nelson F. Liu, Percy Liang 등 7명입니다 (GitHub).

실험 설계: 두 과제는 무엇이 달랐나

다중 문서 질의응답에서는 질문 하나와 문서 k개를 주고, 그중 정확히 하나만 정답을 담게 했습니다 (arXiv). 데이터는 NaturalQuestions-Open에서 긴 답이 문단인 질의 2655개이고, 문서는 최대 100토큰 길이의 위키백과 구절입니다 (arXiv). 방해 문서는 Contriever 검색기로 질의와 관련성이 높으면서 정답이 없는 조각을 골랐습니다 (arXiv). 정답 위치는 문서 순서를 바꿔, 문맥 길이는 방해 문서 수를 늘리거나 줄여 조정했습니다 (arXiv).

key-value 검색은 입력 문맥에서 일치하는 토큰을 꺼내는 기본 능력을 시험하는 합성 과제입니다 (arXiv). 무작위 UUID(식별용 무작위 문자열)로 된 키-값 쌍 k개의 JSON 객체와 키 하나를 주고, 그 키의 값을 돌려받습니다 (arXiv). 저자들은 자연어 의미가 교란 요인이 될 수 있어 이를 최대한 제거하려고 UUID를 썼다고 밝혔습니다 (arXiv).

OpenAI 모델은 0613 버전을 썼고, 최대 문맥 길이 8192 토큰인 MPT-30B-Instruct와 LongChat-13B (16K) 등도 평가했습니다 (arXiv). 출력은 그리디 디코딩(매 단계 가장 확률 높은 토큰을 고르는 방식)으로 생성했습니다 (arXiv).

핵심 결과: 맨 앞과 맨 끝은 잘 썼고 가운데는 놓쳤다

다중 문서 질의응답에서 정답이 맨 앞(초두 편향)이나 맨 끝(최신 편향)에 있을 때 성능이 높고, 가운데 정보를 써야 할 때 떨어지는 U자형 곡선이 보고됐습니다 (arXiv). GPT-4는 다른 모델보다 절대 성능이 높았지만 같은 U자형 곡선을 보였다고 밝혔습니다 (arXiv).

두 모델의 문맥 창에 모두 들어가는 입력에서는 문맥 확장형 모델과 원래 모델의 성능이 거의 같았고, 저자들은 문맥 확장형 모델이 문맥 활용에서 반드시 더 낫지는 않다고 결론지었습니다 (arXiv). key-value 과제에서도 GPT-3.5-Turbo, GPT-3.5-Turbo (16K), MPT-30B-Instruct는 키-값 쌍이 가운데 있을 때 성능이 가장 낮았습니다 (arXiv). LongChat-13B (16K)는 140쌍 조건에서 다른 경향을 보였습니다 (arXiv).

오픈 도메인 질의응답 사례 연구에서는 리더 모델(검색 문서를 읽고 답하는 모델)의 성능이 검색기 성능보다 훨씬 먼저 정체됐고, 저자들은 리더가 추가 문맥을 효과적으로 쓰지 못한다고 해석했습니다 (arXiv).

재현과 적용 한계

저자들은 코드와 평가 데이터를 공개한다고 밝혔고, 저장소는 MIT 라이선스로 배포됩니다 (arXiv, GitHub). README는 질의응답 데이터 생성 전 Contriever 검색 결과 다운로드, key-value 데이터 생성 스크립트 scripts/make_kv_retrieval_data.py, EXPERIMENTS.md의 실행·평가 절차를 안내합니다 (GitHub).

이 글은 저장소 코드를 실행하거나 논문 수치를 직접 재현하지 않았습니다. 제3자의 독립 재현 여부, EXPERIMENTS.md의 구체적 내용, 실행 환경은 원문에서 확인되지 않았습니다. 비용과 관련해 저자들은 GPT-4를 다중 문서 질의응답의 일부 실험에서만 평가했으며, 다중 문서 질의응답과 key-value 실험 전체를 GPT-4로 평가하면 6000달러를 넘는다고 밝혔습니다 (arXiv). 그 밖의 모델 실행 비용은 원문에서 확인되지 않았습니다.

독자 시사점: 결과보다 평가 기준이 오래 쓰인다

저자들은 긴 문맥을 강건하게 쓴다고 주장하려면 최고·최저 성능 차이처럼 정보 위치에 따른 성능 변화가 작음을 보여야 한다고 제안했습니다 (arXiv). 새 모델의 긴 문맥 성능 주장을 읽을 때 위치별 결과를 함께 제시했는지 확인하는 기준으로 쓸 수 있다고 해석할 수 있습니다.

검색 문서를 재순위화해 관련 정보를 앞쪽으로 옮기거나 검색 문서 수를 줄이는 방법은 저자들이 유망한 방향으로 제안한 것이며, 이 논문에서 효과를 검증한 결과는 아닙니다 (arXiv). 특정 최신 모델의 긴 문맥 성능 수치가 필요한 독자에게는 이 논문이 답을 주지 않습니다. 저자들이 공개한 코드·평가 데이터와 제안한 평가 기준을 참고해 해당 모델로 따로 확인하는 것이 필요하다는 것이 이 글의 해석입니다 (arXiv).