긴 문서 속 근거를 AI가 정말 찾았는지 확인하는 법

긴 문서의 답을 잘 찾았다는 시연은 무엇을 검증했을까. NoLiMa와 Lost in the Middle을 바탕으로 근거 위치, 질문 표현, 입력 길이를 분리해 업무용 AI를 점검하는 방법을 살펴본다.

GPT Image 2로 생성한 개념 이미지.

운영팀이 긴 행사 준비 문서를 AI에게 읽히는 상황을 생각해 보자. 질문은 어느 행사의 운영 방식을 바꿔야 하는지 묻는다. 관련 문장이 문서 앞부분에 있고 질문과 같은 단어까지 포함하면 답은 쉽게 나온다. 그 문장을 중간으로 옮기거나, 같은 뜻을 다른 표현으로 물어도 결과가 유지될까.

이것은 가상의 업무 장면이다. 시연에서 정답을 한 번 얻었다는 사실과, 문서 묶음이 바뀌어도 근거를 찾아내는 능력을 구분하기 위해 설정했다. 팀이 실제로 맡길 일에는 여러 부서의 표현, 관계없는 보고, 드문 예외가 함께 들어온다. 파일을 모두 업로드했다는 표시만으로 그 예외까지 활용했다고 판단하기는 어렵다.

긴 문맥을 평가할 때는 입력 가능한 양과 답을 뒷받침한 근거를 따로 확인해야 한다. 특히 근거의 위치가 달라졌을 때, 질문의 단어가 원문에 그대로 나타나지 않을 때를 구분해 보면 짧은 시연이 감춘 실패를 더 구체적으로 찾을 수 있다.

앞에 있을 때 찾은 근거를 중간에서도 찾는가

Liu 등의 TACL 2024 논문 Lost in the Middle은 여러 문서에서 답을 찾는 과제와 키에 해당하는 값을 회수하는 과제에서 관련 정보의 위치를 바꿨다. 연구가 평가한 모델들은 근거가 입력의 처음이나 끝에 있을 때 상대적으로 잘 수행하고, 가운데 있을 때 성능이 떨어지는 경향을 보였다. 긴 문맥을 명시적으로 지원하는 모델에서도 이런 문제가 관찰됐다.[1]

이 결과는 문서 순서가 단순한 포장 방식에 그치지 않을 수 있음을 보여 준다. 검색기가 올바른 문단을 회수했더라도 그 문단이 긴 입력 안에서 제대로 활용됐는지는 별도의 문제다. 다만 당시 결과를 오늘 사용하는 모든 모델의 성능표로 읽어서는 안 된다. 이 연구에서 가져올 것은 현재 모델을 대신 판정하는 점수보다 위치를 바꿔 비교하는 실험 방식이다.

실무 자료를 무작정 섞는 것도 정확한 시험은 아니다. 시간 순서에 의미가 있는 회의록이나, 앞 조항을 참조하는 규정의 문단을 뒤섞으면 질문 자체의 조건이 달라질 수 있다. 처음에는 독립적으로 읽히는 문서 블록을 쓰고, 블록 안의 제목·날짜·조건·문서 식별자는 유지하는 편이 낫다. 순서를 바꿔도 사람이 판단하는 정답이 같은지 먼저 확인해야 한다.

앞쪽에서만 맞고 가운데에서 놓쳤다면 다음 조치는 전체 자료를 더 넣는 일이 아닐 수 있다. 필요한 문서를 먼저 추리거나 근거 주변을 다시 읽게 하는 방식이 후보가 된다. 어떤 조치를 택하든 같은 문제를 다시 풀려 비교해야 한다. 중요한 문장을 앞으로 옮겼다는 사실만으로 다른 위치의 실패까지 해결됐다고 할 수는 없다.

같은 단어를 찾는 일과 의미를 연결하는 일

2025년 공개된 NoLiMa는 또 다른 지름길에 주목했다. 긴 텍스트 속 특정 정보를 찾는 시험이라도 질문과 근거가 눈에 띄는 단어를 공유하면 표면적인 일치가 탐색을 도울 수 있다. 연구진은 질문과 근거 사이의 어휘 중복을 최소화하고, 배경지식이나 상식에 따른 연결을 이용해야 답을 찾을 수 있는 과제를 만들었다.[2]

여기에는 단순히 문장을 동의어로 바꾸는 것보다 넓은 문제가 있다. 질문이 요구하는 속성과 문서에 적힌 사실을 연결해야 하는 것이다. 연구는 짧은 문맥에서 과제를 풀 수 있는지도 확인하고, 주변 글이 길어질 때 성능이 어떻게 달라지는지 비교했다. 모호한 정답이나 우연한 단어 단서가 결과를 흐리지 않도록 주변 텍스트도 걸렀다.

이 글에서 확인한 2025년 2월 공개판은 긴 문맥으로 갈수록 평가 모델들의 성능이 크게 낮아졌다고 보고한다. 이것은 그 시험에 포함된 모델과 구성에서 얻은 관찰이다. 실제 조직의 문서 전체를 재현한 결과도, 현재 제품의 우열을 정한 순위도 아니다. NoLiMa의 유용한 질문은 우리 시험의 정답이 표현의 우연한 일치에 얼마나 기대고 있는가다.

업무 자료에서는 이 연결의 근거를 어디서 얻는지도 명시해야 한다. 예를 들어 가상의 문서 묶음에 “야외 행사는 우천 시 실내로 전환한다”는 공통 규칙과 “해솔 행사는 옥상 정원에서 진행한다”는 행사 기록이 있다고 하자. “비가 오면 장소를 바꿔야 하는 행사는?”에 답하려면 장소의 성격과 규칙을 연결해야 한다. 장소가 야외라는 설명도 자료 안에 명시하면 모델의 외부 상식에 덜 의존하는 시험을 만들 수 있다.

이 예시는 NoLiMa의 실제 문항이 아니라 필자가 제안한 업무용 변형이다. 규칙을 입력에 제공하는 시험과 모델의 배경지식에 맡기는 시험은 측정하는 능력이 다르다. 둘을 같은 점수로 묶기 전에 팀이 어느 쪽을 필요로 하는지 정해야 한다.

문서를 늘리기 전에 바꿔볼 조건

다음 표는 두 연구의 문제의식을 업무 평가로 옮긴 제안이다. 이 글에서 모델을 실행해 얻은 성능 결과는 아니다. 이미 사람이 정답과 근거 위치를 확인한 사례를 준비하고, 한 번에 바꾸는 조건을 제한하는 데 목적이 있다.

먼저 짧은 기준 사례를 풀 수 있는지 봐야 한다. 여기서부터 실패하면 긴 문맥 때문에 생긴 오류라고 설명하기 어렵다. 질문이 모호하거나, 필요한 규칙이 빠졌거나, 정답표가 잘못됐을 수 있다. 짧은 입력에서 성공한 사례를 길게 확장하면 무엇이 새로 어려워졌는지 더 좁혀볼 수 있다.

위치 시험에서는 같은 문서 집합을 사용한다. 길이 시험에서는 근거의 상대 위치도 함께 기록하고, 각 길이에서 앞·중간·뒤 조건을 비교한다. 길이만 늘렸다고 생각했는데 근거가 입력의 앞쪽에서 가운데로 이동했다면 두 효과가 섞인다. 입력이 실제로 잘려 나가지 않았는지, 답변에 남긴 출력 여유가 같은지도 확인할 필요가 있다.

표현을 바꾸는 시험은 사람이 다시 검토해야 한다. 원문에 없는 조건을 질문에 추가하거나, 고유명을 지워 정답이 여럿이 되면 공정한 비교가 아니다. 단어 중복을 줄인 사례가 실패했을 때도 곧바로 의미를 이해하지 못했다고 단정해서는 안 된다. 필요한 연결 지식이 빠졌는지와 문서에서 정보를 회수하지 못했는지를 나누어 본다.

기록에는 최종 답만 두지 않는 편이 좋다. 사용한 문서 묶음, 입력 길이, 근거 위치, 질문 변형, 모델 버전과 설정, 답변이 제시한 근거 구간을 함께 남긴다. 같은 조건에서도 결과가 흔들릴 수 있으므로 한 번의 성공으로 통과시키기보다 반복해서 확인할 횟수를 정한다. 허용할 실패율은 업무의 영향과 사람 검토 범위에 따라 미리 결정한다.

평가 결과를 업무의 범위로 되돌리기

결과를 평균 점수 하나로 합치면 중요한 차이가 사라질 수 있다. 짧은 입력에서는 안정적이지만 긴 문서의 중간에서 반복적으로 근거를 놓치는 도구라면, 문서 전체를 한 번에 맡기는 범위를 조정할 이유가 있다. 반대로 위치와 길이가 달라도 근거 구간을 정확히 찾는다면 더 넓은 문서 묶음을 시험할 근거가 된다.

RAG를 쓰는 팀은 검색 결과 안에 정답 근거가 있었는지부터 구분할 수 있다. 없었다면 검색 단계의 문제를 먼저 보고, 있었는데도 답에 반영되지 않았다면 입력 구성과 생성 단계를 살핀다. 사람이 확인한 정답 근거를 직접 넣은 비교 조건도 유용하다. 다만 근거를 잘 찾았다는 평가와 최종 판단이 맞았다는 평가를 합쳐버리지는 말아야 한다.

완화 방법에도 비용과 손실이 따른다. 문서를 줄이면 예외를 빠뜨릴 수 있고, 요약하면 조건이나 부정이 사라질 수 있다. 읽기를 여러 번 나누면 지연과 비용이 늘고, 마지막 결합 단계에서 다시 오류가 날 수 있다. 개선 후에는 처음 실패한 조건과 다른 위치의 사례를 함께 재시험해야 한다.

긴 문서를 맡길 수 있는지는 용량 표기만으로 정해지지 않는다. 우리 문서의 표현과 배치가 바뀌어도 필요한 근거를 찾아 답에 반영하는지, 실패했을 때 어느 단계에서 멈추고 사람이 확인할 수 있는지가 실제 위임 범위를 만든다.

---

[1] Nelson F. Liu 외, Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics 12, 2024. 위치 민감도에 관한 역사적 연구이며 현재 모델 성능을 직접 대변하지 않는다.

[2] Ali Modarressi 외, NoLiMa: Long-Context Evaluation Beyond Literal Matching, 2025년 2월 7일 공개판. 특히 §3의 과제 구성과 §4.3의 짧은 기준 성능·평가 방법을 참고했다.

함께 읽기: 에이전트의 맥락은 작업마다 다시 편성되어야 한다 · 관련 문서를 찾았는데도 RAG가 답하면 안 되는 이유