Lost in the Middle: 답을 프롬프트에 넣었는데도 모델이 못 찾는 이유
문서 검색이 잘됐다. 답이 들어 있는 문단도 프롬프트에 넣었다. 그런데 모델은 엉뚱한 답을 한다. 이런 실패를 보면 검색기를 먼저 의심하기 쉽지만, 답을 가져오는 일과 가져온 답을 사용하는 일은 다르다. Lost in the Middle은 문서 내용보다 문서의 위치를 바꾸며 이 차이를 보여 준다. 긴 입력을 받을 수 있다는 기능을, 긴 입력을 골고루 활용한다는 능력과 구별하게 만드는 논문이다.
답은 그대로 두고 자리만 옮긴다
저자들은 여러 문서를 제공하고 질문에 답하게 하는 과제를 만든다. 정답 정보를 담은 문서 하나와 다른 문서들을 함께 넣은 뒤, 그 정답 문서의 위치를 앞, 중간, 뒤로 바꾼다. 문서 수를 바꾸어 입력 길이의 영향도 살핀다. 핵심은 정답 정보가 있는지 여부를 고정하고 위치 효과를 분리해 보는 것이다.
원문에서 여러 모델은 관련 정보가 입력 앞이나 뒤에 있을 때 성능이 높고 중간에 있을 때 떨어지는 U자 모양의 경향을 보인다. 긴 문맥을 지원하는 당시 모델도 이 문제에서 자동으로 자유롭지는 않았다. 이는 논문이 평가한 모델과 과제에 대한 관찰이다. 모든 시점의 모든 언어 모델에 적용되는 불변 법칙으로 읽으면 안 된다. 논문 원문
가상의 사내 검색을 만들어 보자. '장애 대응 담당 팀은 어디인가'를 물었고, 열 개 문서 중 하나에 '야간 대응은 플랫폼 운영 팀이 맡는다'는 문장이 있다. 이 문서를 첫 번째와 다섯 번째, 마지막에 각각 배치한다. 답 문장이 달라지지 않았는데 결과가 달라진다면, 문제는 검색 재현율만으로 설명되지 않는다. 프롬프트를 구성하는 순서가 읽기 성능의 일부가 되는 것이다.
이런 실험은 추상적인 긴 문맥 벤치마크보다 제품 문제와 연결하기 쉽다. 모델이 처리 가능한 최대 토큰 수를 늘리는 것만으로 사용자가 겪는 답변 실패를 모두 해결하지는 못한다. 입력 용량은 컨테이너의 크기이고, 그 안에서 필요한 정보를 찾고 활용하는 능력은 별도로 평가해야 한다.
상식이 끼어들 틈을 줄인 실험
질문 답변은 단순히 문장을 찾아 복사하는 것보다 복잡하다. 모델이 기억한 사실을 이용할 수도 있고, 여러 문서를 해석하는 과정에서 실패할 수도 있다. 그래서 저자들은 키와 값의 목록을 주고 지정한 키의 값을 반환하게 하는 합성 과제도 사용한다. 긴 JSON에서 필요한 항목을 찾는 최소한의 검색 실험에 가깝다.
예를 들어 task-17에 연결된 임의 문자열을 찾게 하고, 그 항목을 목록 중간으로 옮겨 본다. 임의의 키와 값이라면 모델이 사전학습 지식으로 정답을 맞히기는 어렵다. 논문에서는 일부 모델이 이 과제를 매우 잘 수행하는 반면, 다른 모델은 중간 위치에서 어려움을 보인다. 복잡한 지식 추론만의 문제가 아닐 수 있다는 증거다. 공식 데이터와 실험 코드
다만 키값 검색을 잘한다고 긴 보고서를 잘 읽는 것은 아니다. 정확히 일치하는 문자열을 찾는 능력과, 여러 조건을 종합해 답하는 능력은 다른 요구를 갖는다. 반대로 합성 과제 하나의 실패로 실무 문서 읽기 전체를 평가하는 것도 조심해야 한다. 저자들이 두 종류의 과제를 함께 둔 이유를 이렇게 읽을 수 있다.
내가 더해 보고 싶은 테스트는 조건 간의 거리다. 정답 문장 하나를 옮기는 대신, 본문에는 일반 규칙을 두고 멀리 떨어진 부록에 예외 조건을 둔다. 모델이 둘을 결합하는지 평가한다. 이는 원문의 실험 결과가 아니라, 위치 효과를 업무 문서로 확장할 때 떠오르는 후속 실험이다.
문서를 더 주면 답도 더 좋아질까
검색 시스템은 보통 관련 문서를 더 가져오면 답을 포함할 확률이 올라간다. 하지만 독자 역할의 모델은 더 긴 입력을 읽어야 한다. 추가 문서에는 유용한 정보뿐 아니라 방해 정보와 유사한 표현도 들어 있다. 따라서 검색 재현율의 개선이 최종 정답률의 같은 개선으로 이어진다고 가정할 수 없다.
원문은 실제 검색과 질문 답변을 묶은 사례 분석에서도 이 간극을 살핀다. 문서를 더 가져오면서 검색 재현율이 증가해도, 최종 성능은 그보다 이른 시점에 포화하는 모습을 보고한다. 원문 검색과 독자 분석
내가 이 결과를 적용한다면 top-k를 하나의 고정된 성능 손잡이로 보지 않겠다. k를 늘리는 선택은 '찾을 가능성'과 '읽어야 할 부담'을 동시에 바꾼다. 검색, 재정렬, 중복 제거, 문단 선택을 함께 보아야 한다. 특히 거의 같은 문서가 여러 개 들어가면 토큰을 많이 쓰면서 새로운 정보는 별로 늘지 않을 수 있다.
프롬프트 앞이나 뒤에 중요한 문서를 놓자는 처방도 테스트할 가설이다. 여러 문서의 상호 관계가 중요한 과제에서는 순서를 임의로 바꾸면 다른 문제가 생길 수 있다. 시간순 사건 기록이라면 날짜가 흐트러지고, 여러 규정이 충돌한다면 우선순위를 명시해야 한다. 위치가 중요하다는 관찰을 '가장 중요한 문서 하나만 뒤로 옮기면 해결'이라는 보편 규칙으로 줄이고 싶지는 않다.
왜 가운데가 어려운지, 어디까지 알 수 있나
이 논문의 힘은 원인을 하나로 확정하는 데보다 현상을 분리해 측정하는 데 있다. 모델 구조, 학습 길이, 질문의 배치, 지시 미세조정 여부 등을 분석한다. 질문을 문서 전후에 함께 두는 방식은 합성 키값 검색에서 큰 도움이 되지만, 문서 질문 답변의 위치 경향을 같은 정도로 해결하지는 않는다.
따라서 '모델은 최근 내용만 기억한다'거나 '위치 인코딩 하나 때문에 그렇다'는 짧은 설명은 원문이 제시한 범위를 넘을 수 있다. 앞부분도 잘 활용하는 결과가 있고, 과제와 모델 구조에 따라 양상이 달라진다. 관찰된 성능 곡선을 뇌의 기억 곡선과 비슷하게 말할 수는 있어도, 같은 작동 원리를 증명한 것으로 볼 수는 없다.
나는 이 신중함이 이 논문의 실무적인 가치라고 생각한다. 막연히 '긴 문맥 모델이니까 괜찮다'고 믿거나, 반대로 '모델은 긴 문서를 못 읽는다'고 포기하는 대신, 어느 위치의 어떤 정보에서 실패하는지 실험할 수 있다. 문제가 구체적으로 보이면 개선도 구체적으로 설계할 수 있다.
평균 점수 옆에 위치별 점수를 놓기
새 문서 질의 시스템을 평가한다면 같은 질문과 근거를 여러 위치에 놓는 테스트를 포함하겠다. 앞, 4분의 1, 중간, 4분의 3, 뒤에 정답 문서를 배치하고 입력 길이를 바꾼다. 답이 들어 있는지 확인한 뒤 결과를 비교해야 검색 실패와 읽기 실패를 구분할 수 있다.
평가표에는 전체 평균뿐 아니라 가장 약한 위치의 점수도 넣고 싶다. 실제 사용자는 중요한 정보가 언제나 유리한 위치에 놓인 문서를 주지 않는다. 길이가 비슷해도 표, 코드, 반복 문구가 많은 문서는 읽기 요구가 다를 수 있으므로 실제 업무 문서를 함께 사용한다. 이런 제안은 논문의 평가 철학에서 가져온 나의 적용 방법이다.
요약을 먼저 만드는 구조도 후보가 되지만, 요약 단계가 예외 조항을 버릴 위험은 다시 측정해야 한다. 문맥을 줄인다는 선택이 유용한 정보까지 줄이는지 확인할 필요가 있다. 위치별 검증을 원문 독자와 요약 독자 모두에 적용하면 병목이 어느 단계로 이동했는지 볼 수 있을 것이다.
긴 문맥은 모델의 중요한 자원이다. 다만 자원이 있다는 사실과 필요한 순간에 그 자원을 잘 쓰는지는 다르다. Lost in the Middle은 토큰 수라는 큰 숫자 옆에 더 작은 질문을 놓는다. 정답이 여기 있을 때도, 모델은 그것을 찾는가.
읽은 논문: Nelson F. Liu 외, Lost in the Middle: How Language Models Use Long Contexts, 사전 공개 2023, TACL 2024. 출판 논문 · 공식 코드와 데이터