RAG 답변은 왜 필요한 근거를 다 가져오지 못할까

RAG는 질문에 필요한 근거 중 하나는 잘 찾아오지만, 여러 개가 필요할 때 전부를 가져오는 일은 드물었어요. 뉴스 기사 질문 2,255개에서 상위 10개 청크 안에 근거가 하나라도 들어온 비율은 82%였는데, 필요한 근거가 모두 들어온 비율은 19%였어요 ^[1]. 이 연구는 아랍에미리트 MBZUAI와 Inception42 연구진이 2026년 10월 arXiv에 올린 논문이에요. 동료 심사 전 단계이고, 저자들은 RAG를 긴 문맥 모델로 바꾸자는 게 아니라 RAG의 구조적 한계를 측정 가능하게 만드는 게 목적이라고 밝혔어요 ^[1].

이 글은 arXiv 원문 v1의 본문과 표 1·3·4·5, 그림 1–3을 2026년 10월에 읽고 수치를 하나씩 대조해 정리했어요 ^[1]. 저자가 공개한 코드와 데이터는 직접 돌려 보지 않았어요. 저자와 이해관계는 없어요.

RAG는 질문에 필요한 근거를 모두 찾아오나요

RAG 시스템은 보통 답이 맞았는지만으로 평가해요. 그러면 두 가지 실패가 섞여요. 검색기가 필요한 문단을 못 가져온 실패와, 가져온 문단을 모델이 제대로 못 읽은 실패예요. 저자들은 이 둘을 떼어 보려고 증거 기반 생성(EBG)이라는 과제를 만들었어요. 모델이 답과 함께 그 답을 뒷받침하는 입력 줄 번호를 내야 하고, 답(Ans)과 근거(Evid)가 둘 다 맞아야 정답(Ans+Evid)으로 쳐요 ^[1].

검색 쪽 실패부터 봤어요. MultiHop-RAG는 뉴스 기사 609개에 질문을 달아 둔 벤치마크인데, 질문마다 서로 다른 기사에 흩어진 근거 2–4개가 있어야 답할 수 있어요. 저자들은 기사를 256토큰 창으로 잘라 청크 6,296개를 만들고, OpenAI text-embedding-3-large로 질문과 유사도가 높은 순서대로 청크를 뽑았어요 ^[1].

결과는 하나와 전부 사이의 차이였어요. 상위 10개 청크 안에 필요한 근거가 하나라도 들어온 질문은 82%였지만, 2–4개 근거가 모두 들어온 질문은 19%였어요. 추론형(멀티홉) 질문만 보면 8%였어요. 상위 50개로 늘려도 모두 들어온 비율은 57%, 100개에서 71%였어요 ^[1].

그림 1. 필요한 근거 중 하나를 찾는 일은 쉬웠지만, 모두를 찾는 일은 어려웠어요. 상위 10개 기준 82%와 19%로 벌어졌어요 ^[1].

저자들은 이 "모두 들어온 비율"을 RAG가 근거에 충실하게 답할 수 있는 상한으로 봤어요. 필요한 근거가 하나라도 빠지면 그 답은 근거에 충실할 수 없으니, 상위 10개 기준 추론형 질문의 90% 넘게가 모델을 부르기도 전에 이미 실패가 정해진다는 해석이에요 ^[1].

청킹은 RAG 답변에 어떤 영향을 주나요

두 번째 한계는 청킹이에요. 문단을 잘라 내면 그 문단이 어느 문서의 어느 절에 있었는지, 제목과 저자가 무엇인지가 같이 떨어져 나가요. 저자들은 이 문제를 QASPER-MP로 쟀어요. NLP 논문 질문마다 정답 논문 하나에 다른 논문 10편을 섞고, 질문이 논문을 저자 성("Smith 외")이나 제목 일부로만 가리키게 바꿨어요 ^[1].

같은 11편 후보 안에서 비교하면, 긴 문맥 모델에 논문 전체를 넣은 조건(LC-EBG)이 가장 좋은 RAG 변형보다 다섯 프런티어 모델 모두에서 판정 점수가 0.05–0.13점 높았어요. 겉으로 합계 점수가 비슷해 보인 건 RAG가 검색에 실패한 질문에서 답을 포기했기 때문이에요. 답할 수 있는 질문에서 RAG의 답 포기 비율은 24–40%로, LC-EBG(13–18%)보다 높았어요 ^[1].

그림 2. 검색한 문단을 그냥 이어 붙인 조건보다 제목·초록 구조를 다시 붙인 조건에서 다섯 모델 중 네 모델의 점수가 올랐어요. 그래도 논문 전체를 넣은 조건에는 못 미쳤어요 ^[1].

흥미로운 건 구조를 복원한 변형이에요. 상위 3개 문단을 순서대로 이어 붙인 조건(flat)과, 그 문단에 논문·제목·초록 틀을 다시 감싸고 끊긴 곳에 표시를 넣은 조건(structured)을 비교했어요. Opus-4.6은 0.474에서 0.566으로, GPT-5는 0.500에서 0.553으로 올랐고, Sonnet-4.5만 0.513에서 0.474로 내려갔어요. 문단에 출처 정체성을 되돌려 주는 것만으로 검색 결과를 더 잘 쓴 셈이에요 ^[1].

AI 답이 맞으면 근거도 제대로 쓴 건가요

답만 채점하면 근거를 잘못 짚고도 맞는 경우가 가려져요. 근거 두 개가 있어야 풀리는 긴 문맥 과제에서 모델별로 두 근거를 각각 얼마나 인용했는지 봤더니, Gemini-3-Flash(99.5%·99.8%)와 GPT-5(95.1%·98.6%)는 둘 다 잘 인용했어요. GPT-4o는 첫 근거 71.3%, 두 번째 근거 20.9%였고 Sonnet-4.5도 64.6%와 21.4%로 한쪽만 인용하는 경향이 컸어요 ^[1].

그림 3. 같은 과제에서도 두 근거를 고르게 인용한 모델과 한쪽만 인용한 모델이 갈렸어요. 답만 채점하면 이 차이가 보이지 않아요 ^[1].

문맥 속 근거가 모델이 원래 알던 상식과 어긋나면 이 격차는 더 커졌어요. 답은 상식대로 맞히면서 그 답을 뒷받침해야 할 문맥의 근거는 제대로 짚지 못하는 실패예요. 저자들은 "맞는 답만으로는 모델이 긴 문맥 근거를 충실히 쓰는 능력을 크게 부풀려 볼 수 있다"고 결론 냈어요 ^[1].

근거를 내라고 요구하는 것 자체가 답을 돕기도 했어요. 근거 인용을 요구한 프롬프트는 답만 요구한 프롬프트보다 30만–90만 자 문맥에서 Sonnet과 Gemini 모델의 답 정확도를 9–19%p 올렸어요. 다만 문맥이 짧거나 방해 문장이 쉬운 합성 과제에서는 차이가 없었어요 ^[1].

AI 검색에 인용되려면 문단을 어떻게 써야 하나요

여기서부터는 TRAIL의 해석이에요. 이 논문은 RAG를 만드는 쪽을 위한 연구지만, 생성형 검색이 웹 문서를 청크 단위로 가져다 쓰는 구조라면 글을 내는 쪽에도 시사점이 있어요.

첫째, 검색된 조각은 혼자 읽혀요. 문단에 "이 제품은", "그 회사는"만 있고 주어가 앞 문단에 있으면, 잘려 나간 조각만으로는 무엇에 대한 이야기인지 사라져요. 논문에서 제목·초록을 다시 붙였을 때 점수가 오른 결과와 같은 방향이에요. 둘째, 답에 근거가 여러 개 필요하면 그 근거가 문서 곳곳에 흩어질수록 전부 함께 검색될 확률이 낮아져요. 질문 하나에 필요한 핵심 근거는 한 문단 안에 모아 두는 편이 유리해요. 검색에 걸리는 것과 인용되는 것의 차이는 AI 검색에서 수집과 인용은 어떻게 다른가에서 더 다뤘어요.

이 연구의 한계는 무엇인가요

저자가 밝힌 한계부터요. 벤치마크가 합성이거나 반합성이라 실제 법률·의료·과학 문서의 복잡성을 다 담지 못하고, 근거를 줄 단위로 채점해 구절 단위 정밀도는 보지 않았어요. MultiHop-RAG와 QASPER-MP의 프런티어 모델 실험은 질문 50개 규모의 예비 실험이에요. 질의 재작성, 하이브리드 검색, 적응형 문맥 선택 같은 검색 변형은 탐색하지 않아서 이 상한이 달라질 수 있어요 ^[1].

MultiHop-RAG 비교에서 긴 문맥 조건은 정답 기사를 모두 받고 RAG는 전체 기사에서 찾아야 해서, 두 조건의 후보군이 같지 않아요. 상위 10개 기준 26–34%p 차이는 전체 코퍼스 검색의 비용까지 포함한 값이라 순수한 RAG와 긴 문맥 모델의 차이로 읽으면 안 된다고 저자들이 직접 적었어요. 생성형 검색 엔진이 실제로 어떤 청크 단위와 검색 방식을 쓰는지는 이 논문이 다루지 않아요 ^[1].

TRAIL에게 주는 의미

TRAIL Search의 페이지 진단에는 엔진이 페이지에서 어느 부분을 가져갈지 흉내 내는 청크 시뮬레이터가 있어요. 페이지를 청크로 나눠 각 청크의 자기완결성(대명사·지시어 비율과 고유명사 포함 여부)과 답 밀도(정의문·초반 직답·수치·출처)를 채점해요. 글 작성기도 "섹션 하나만 떼어 읽어도 직답과 근거가 완결되는가"를 검사해요. 이 논문의 청킹 결과는 그 설계가 겨냥한 문제와 같아요.

이 논문이 보여준 빈자리도 있어요. 우리 시뮬레이터는 청크를 하나씩 따로 채점해서, 질문 하나에 필요한 근거 여러 개가 한꺼번에 검색될지는 재지 않아요. 멀티팩트 질문을 겨냥한 글이라면 필요한 근거가 몇 개의 청크에 흩어져 있는지를 보는 진단이 다음 후보예요. 같은 질문을 여러 번 재야 하는 이유는 AI 검색 가시성은 한 번 재면 못 믿어요에 정리했어요.

Debopriyo Banerjee 외, "The Bottleneck Is Retrieval, Not Reading: Diagnosing Evidence-Based Generation with RAG for Long Context Question Answering", arXiv 2610.26951 (2026).