RAG의 병목은 검색이다? EBG가 밝힌 근거 누락과 해결법

AI가 자신 있게 정답을 말했습니다. 그런데 함께 제시한 인용 문장을 확인해 보니, 그 문장은 답변을 제대로 뒷받침하지 않습니다. 혹은 답변에 필요한 근거가 두 개인데 하나만 인용되어 있습니다. 이런 시스템을 중요한 업무에 믿고 사용할 수 있을까요?

바로 이 지점에서 기존 RAG의 한계가 드러납니다. 지금까지 많은 RAG 시스템은 “관련 문서를 찾아 답을 생성하는 능력”에 집중했습니다. 하지만 실제 신뢰성은 정답처럼 보이는 문장을 만드는 데서 결정되지 않습니다. 답변을 구성한 모든 주장에 대해 충분하고 검증 가능한 증거를 확보했는가가 더 중요합니다.

정답과 근거는 같은 문제가 아니다

일반적인 RAG 파이프라인은 질문과 의미적으로 가까운 문서 조각, 즉 chunk를 검색한 뒤 이를 LLM의 입력 문맥에 넣습니다. 이후 모델은 검색 결과와 자체 지식을 바탕으로 답변을 생성합니다.

문제는 다음과 같은 상황이 충분히 발생할 수 있다는 점입니다.

• 답변은 우연히 맞지만, 검색된 문서가 아닌 모델의 사전 지식에 의존한 경우
• 검색 결과에는 필요한 근거 A와 B가 모두 있지만, 답변에는 A만 인용된 경우
• 인용은 포함됐지만 해당 문장이 실제 주장과 다른 내용을 말하는 경우
• 질문에 필요한 핵심 근거 하나를 검색하지 못했는데도, 모델이 그럴듯하게 빈칸을 채운 경우

예를 들어 “정책 변경의 배경과 적용 시점을 설명해 달라”는 질문에는 최소 두 종류의 증거가 필요합니다. 정책이 왜 바뀌었는지 설명하는 문서와, 언제부터 적용되는지 명시한 최신 공지가 모두 있어야 합니다.

하지만 단순 유사도 검색은 질문과 가장 비슷한 chunk 하나를 잘 찾는 데 최적화되어 있습니다. 즉, 관련 정보 하나를 찾는 것과 답변에 필요한 모든 정보를 빠짐없이 확보하는 것은 전혀 다른 문제입니다.

“관련 문서가 검색되었는가?”보다 중요한 질문은 “이 답변에 필요한 모든 증거가 검색되었는가?”입니다.

Evidence-Based Generation이 바꾸는 기준

Evidence-Based Generation, 즉 EBG는 RAG의 결과물을 단순한 답변으로 보지 않습니다. 답변과 함께 각 주장에 연결되는 검증 가능한 근거까지 하나의 결과로 평가합니다.

형식은 단순합니다.

답변: 방법 A는 다중 문서 질의에서 더 안정적이다. [근거 1]
      다만 문서 간 관계를 명시적으로 다루지 않으면
      핵심 증거를 누락할 수 있다. [근거 2]

여기서 핵심은 인용의 존재 자체가 아닙니다. 다음 네 가지를 함께 확인해야 합니다.

1. 답변의 내용이 사실인가?
2. 인용된 문장이 해당 주장을 직접 뒷받침하는가?
3. 답변에 필요한 증거가 빠짐없이 포함되었는가?
4. 모델이 검색된 근거보다 자신의 오래된 사전 지식을 우선하지 않았는가?

이 기준은 특히 법률, 의료, 금융, 기업 리서치처럼 “답”보다 “답의 출처”가 중요한 환경에서 결정적입니다. 사용자는 AI의 결론을 그대로 받아들이는 것이 아니라, 어떤 문서의 어느 부분을 근거로 했는지 확인할 수 있어야 합니다.

RAG의 병목은 읽기가 아니라 검색 완전성이다

최신 연구가 던지는 메시지는 명확합니다. 많은 실패의 원인은 LLM이 긴 문서를 읽지 못해서가 아니라, 애초에 답변에 필요한 증거가 검색 문맥에 들어오지 않았기 때문입니다.

특히 여러 문서에 흩어진 정보를 연결해야 하는 multi-hop 질문에서 문제가 커집니다. 첫 번째 문서에서 인물, 논문, 기관, 날짜 같은 단서를 찾고, 그 단서를 바탕으로 두 번째 문서를 검색해야 하는 경우가 대표적입니다.

이때 RAG는 한 번의 top-k 검색만으로 충분하지 않습니다. 필요한 것은 다음과 같은 흐름입니다.

질문 분석
→ 하위 질문 분해
→ 첫 번째 근거 검색
→ 엔터티·날짜·문서명 추출
→ 후속 근거 재검색
→ 근거 간 관계 검증
→ 답변과 주장별 인용 생성

결국 신뢰할 수 있는 RAG는 “문서를 찾아주는 챗봇”을 넘어야 합니다. 답변을 만들기 위한 증거를 수집하고, 빠진 근거를 점검하며, 각 문장이 무엇에 기반하는지 보여주는 시스템이 되어야 합니다.

AI가 맞는 말을 했다는 사실만으로는 충분하지 않습니다. 중요한 것은 그 답이 검증 가능한 증거 위에 서 있는가입니다.

검색된 조각들 사이에서 사라지는 RAG 문서 맥락

“이 방법은 이전 연구보다 향상됐다.”

RAG가 이 문장 하나만 찾아왔다면, 정말 질문에 답할 수 있을까요?

겉보기에는 관련 있는 문장입니다. 하지만 정작 중요한 정보는 빠져 있습니다. “이 방법”이 무엇인지, “이전 연구”가 어떤 연구인지, 그리고 무엇이 얼마나 향상됐는지를 알 수 없기 때문입니다. 문서를 잘게 나누는 순간, 검색 효율은 높아질 수 있지만 답변을 이해하는 데 필요한 문서의 구조와 관계는 사라질 수 있습니다.

chunk는 편리하지만, 문서 전체를 대신하지 못한다

일반적인 RAG는 긴 문서를 작은 chunk로 분할한 뒤, 질문과 의미적으로 유사한 조각을 찾아 LLM에 전달합니다. 이 방식은 특정 정의나 수치처럼 하나의 문장 안에서 답을 찾을 수 있는 질문에 효과적입니다.

그러나 실제 문서는 문장 하나의 집합이 아닙니다. 문서에는 다음과 같은 맥락이 함께 존재합니다.

• 문서 제목과 작성자
• 섹션과 하위 섹션의 구조
• 앞 문단에서 정의된 용어
• 표·그림·각주의 설명
• 문서 내 인용 관계
• 앞뒤 문단의 논리적 흐름

예를 들어 검색된 chunk에 다음 문장만 있다고 가정해 보겠습니다.

이 방법은 이전 연구보다 다중 문서 환경에서 더 높은 성능을 보였다.

이 한 문장만으로는 답변을 신뢰하기 어렵습니다. 최소한 다음 정보가 추가로 필요합니다.

1. 이 방법은 어떤 방법인가?
2. 이전 연구는 어느 논문 또는 모델인가?
3. 성능은 정확도, 재현율, 처리 속도 중 무엇을 의미하는가?
4. 결과는 어떤 데이터셋과 실험 조건에서 얻었는가?
5. 성능 차이는 통계적으로 의미 있는 수준인가?

즉, 검색 결과가 문장 자체로는 관련 있어 보여도, 독립적으로 해석할 수 없다면 충분한 evidence가 될 수 없습니다.

RAG의 chunking이 만드는 ‘문서 수준 맥락 손실’

이 문제는 단순히 chunk 크기를 키우면 해결되지 않습니다. chunk를 크게 만들면 주변 맥락은 더 보존되지만, 검색 정확도가 떨어지고 불필요한 내용까지 함께 들어갈 수 있습니다. 반대로 chunk를 작게 만들면 검색은 정밀해질 수 있지만, 대명사·약칭·참조 표현이 가리키는 대상이 사라집니다.

특히 다음 표현은 분리된 chunk에서 쉽게 의미를 잃습니다.

• 이 방법, 해당 모델, 앞선 접근법
• 본 연구, 이전 결과, 위 실험
• 그 논문, 해당 기관, 저자들은
• 표 2의 결과, 그림 4의 비교
• 이를 바탕으로, 그러나, 반면에

이런 표현은 문장 내부가 아니라 문서 구조 속에서만 의미가 완성됩니다. 따라서 RAG가 검색한 조각을 그대로 LLM에 전달하면, 모델은 빠진 정보를 추론으로 채우려 할 수 있습니다. 그리고 이 추론은 그럴듯해 보여도 원문 근거와 다를 수 있습니다.

특히 ‘누가·어떤 문서가·무엇을 했는가’에 약하다

문서 맥락 손실은 사람, 저자, 기관, 논문 제목처럼 정체성 정보가 중요한 질문에서 더 크게 드러납니다.

가령 다음과 같은 질문을 생각해 볼 수 있습니다.

특정 연구자가 이전 논문의 한계로 지적한 문제는 무엇인가?

이 질문에 정확히 답하려면 단순히 “한계”라는 단어가 들어간 chunk를 찾는 것만으로는 부족합니다. 검색 시스템은 적어도 다음 연결을 유지해야 합니다.

연구자 → 해당 논문 → 참조한 이전 연구 → 지적한 한계

하지만 독립 chunk는 이 연결 고리를 끊어 놓기 쉽습니다. 한 조각에는 한계 설명만 있고, 다른 조각에는 저자 정보만 있으며, 또 다른 조각에는 이전 연구의 제목만 있을 수 있습니다. 유사도 검색은 각각을 찾아낼 수 있어도, 그것들이 같은 문서 흐름 안에서 어떤 관계를 맺는지는 보장하지 않습니다.

해결의 방향은 ‘더 많은 chunk’가 아니라 ‘복원 가능한 구조’

이 문제를 줄이려면 RAG 인덱스에 본문만 저장해서는 안 됩니다. 각 chunk가 어느 문서와 섹션에 속하는지, 앞뒤 문맥은 무엇인지 함께 보존해야 합니다.

실무적으로는 다음과 같은 메타데이터가 유용합니다.

{
  "text": "이 방법은 이전 연구보다 다중 문서 환경에서 더 높은 성능을 보였다.",
  "document_title": "논문 제목",
  "section": "Experiments",
  "subsection": "Multi-document Evaluation",
  "authors": ["저자 A", "저자 B"],
  "position": "page 8, lines 12-18",
  "previous_chunk": "chunk_104",
  "next_chunk": "chunk_106",
  "entities": ["Method A", "Baseline B"]
}

이 구조가 있으면 검색 결과를 받은 뒤 다음과 같은 후속 처리가 가능해집니다.

• 해당 chunk의 앞뒤 문단을 확장해 읽기
• 문서 제목과 섹션 제목을 함께 제공하기
• “이 방법”이 가리키는 entity를 이전 문맥에서 복원하기
• 표·그림·각주 등 연결된 자료를 함께 조회하기
• 같은 문서 안의 관련 근거를 추가 검색하기

결국 좋은 RAG는 가장 비슷한 문장을 가져오는 시스템이 아닙니다. 검색된 문장이 원래 문서 안에서 어떤 의미를 가졌는지 복원할 수 있는 시스템이어야 합니다.

문서가 잘게 쪼개질수록 검색은 빨라질 수 있습니다. 그러나 답변의 신뢰성은 조각의 유사도만으로 만들어지지 않습니다. 필요한 것은 조각 하나가 아니라, 그 조각이 속해 있던 문서의 맥락과 관계입니다.

EBG와 RAG: 답변에 증거의 주소를 붙이는 생성

답변의 모든 주장을 원문 속 특정 줄까지 추적할 수 있다면 어떨까요?

기존 RAG는 관련 문서를 검색해 답변을 만드는 데 집중했습니다. 그러나 답변이 그럴듯하고 심지어 정답처럼 보여도, 사용자는 중요한 질문을 남기게 됩니다.

“그래서 이 답변의 근거는 정확히 어디에 있나요?”

Evidence-Based Generation(EBG)은 이 질문에 답하기 위한 접근입니다. 단순히 답변을 생성하는 것이 아니라, 답변 안의 각 주장에 대해 이를 뒷받침하는 line-level citation, 즉 원문 줄 단위의 인용 주소를 함께 제시하도록 요구합니다.

답변만 맞으면 충분하지 않은 이유

일반적인 RAG 응답은 다음과 비슷합니다.

방법 A는 방법 B보다 다중 문서 질의에서 안정적입니다.

이 문장은 맞을 수 있습니다. 하지만 어떤 문서의 어떤 실험 결과인지, 예외 조건은 없는지, 모델이 검색된 문서를 읽고 말한 것인지 아니면 학습 데이터의 사전 지식으로 답한 것인지는 알기 어렵습니다.

EBG에서는 같은 답변이 다음처럼 바뀝니다.

방법 A는 방법 B보다 다중 문서 질의에서 더 안정적인 결과를 보였다. [L12-L18]

다만 문서 간 관계를 명시적으로 추적하지 않으면,
두 번째 핵심 근거를 누락할 수 있다. [L31-L36]

이제 사용자는 답변을 그대로 믿을 필요가 없습니다. 인용된 줄로 이동해 원문이 정말 해당 주장을 뒷받침하는지 직접 확인할 수 있습니다.

EBG가 요구하는 세 가지 조건

EBG 관점에서 좋은 RAG 답변은 단순히 정답을 말하는 답변이 아닙니다. 최소한 다음 세 가지를 충족해야 합니다.

1. 답변이 정확해야 합니다.
   질문에 대한 결론 자체가 사실과 일치해야 합니다.

2. 각 주장에 근거가 있어야 합니다.
   답변의 중요한 문장마다 검색된 문서의 위치가 연결되어야 합니다.

3. 근거가 충분해야 합니다.
   여러 사실을 결합해야 하는 질문이라면, 한 조각의 인용만으로는 부족합니다. 답변을 완성하는 데 필요한 모든 핵심 증거가 포함되어야 합니다.

특히 여러 문서의 정보를 연결하는 multi-hop 질문에서는 세 번째 조건이 중요합니다. A라는 사실과 B라는 사실을 모두 찾아야 결론을 낼 수 있는데, 한쪽 근거만 인용하면 답변은 검증 가능한 형태가 되지 못합니다.

인용이 있다고 해서 근거 기반 답변은 아니다

여기서 주의할 점이 있습니다. 인용 표기가 존재한다고 해서 자동으로 신뢰할 수 있는 것은 아닙니다.

다음과 같은 실패가 가능합니다.

• 인용한 문장이 실제 주장과 무관한 경우
• 두 개의 근거가 필요한데 하나만 인용한 경우
• 문서의 결론이 아니라 주변 설명을 인용한 경우
• 검색 문서에는 최신 정보가 있지만, 모델이 오래된 사전 지식으로 답한 경우
• 서로 다른 문서의 내용을 잘못 연결한 경우

따라서 EBG는 “인용이 있는가?”만 보지 않습니다. 인용이 해당 주장을 직접 지지하는지, 그리고 필요한 근거가 빠짐없이 포함됐는지까지 평가합니다.

이를 위해 논문은 답변 정확성과 증거 품질을 함께 보는 Ans+Evid 관점을 제시합니다. 답이 맞더라도 인용이 부정확하거나 불완전하면 높은 품질의 응답으로 평가하지 않는 방식입니다.

RAG의 출력 형식도 바뀌어야 한다

EBG를 적용한 RAG는 최종 답변을 만들기 전에 주장과 근거를 먼저 정리하는 편이 좋습니다.

질문 분석
→ 하위 질문 분해
→ 근거 검색
→ 근거 간 관계 확인
→ 주장별 인용 연결
→ 답변 생성
→ 인용-주장 일치 검증

실무에서는 다음과 같은 출력 구조를 고려할 수 있습니다.

구성 요소	역할
Answer	사용자가 읽는 자연어 답변
Claim	답변에 포함된 개별 사실 또는 결론
Citation	해당 주장을 뒷받침하는 문서·페이지·줄 위치
Evidence text	인용 위치의 실제 원문
Verification	인용이 주장을 지지하는지 확인한 결과

핵심은 답변을 먼저 만들고 나중에 출처를 장식처럼 붙이는 것이 아닙니다. 증거를 수집하고, 증거가 충분한지 확인한 뒤, 그 범위 안에서만 답변을 생성하는 것이 EBG의 방향입니다.

신뢰가 중요한 분야에서 더 큰 차이를 만든다

이 방식은 특히 틀린 답변의 비용이 큰 업무에서 유용합니다.

• 법률: 조항, 판례, 계약서의 정확한 문구를 추적해야 하는 경우
• 의료: 진료 지침, 논문, 허가 정보의 근거를 확인해야 하는 경우
• 금융: 공시, 규정, 리스크 보고서의 출처가 필요한 경우
• 연구: 여러 논문의 주장과 실험 결과를 교차 검증해야 하는 경우
• 기업 지식 검색: 정책 변경, 내부 규정, 기술 문서의 최신성을 확인해야 하는 경우

결국 EBG는 RAG를 더 정직한 시스템으로 만듭니다. 모델이 “답을 알고 있다”고 주장하는 대신, “이 답은 여기에서 왔습니다”라고 증명하도록 요구하기 때문입니다.

RAG의 실패를 검색과 생성으로 나눠 진단하다

긴 문서를 한 번에 읽는 모델이 RAG보다 더 좋은 답을 내놓는다면, 우리는 흔히 이렇게 결론 내립니다.

“역시 모델의 장문 읽기 능력이 더 뛰어나다.”

하지만 Evidence-Based Generation(EBG)이 던지는 질문은 다릅니다.

정말 생성 모델이 더 잘 읽은 것일까?
아니면 RAG가 답변에 필요한 증거를 애초에 검색하지 못했던 것일까?

이 차이는 매우 중요합니다. 문제의 원인을 잘못 진단하면, 기업은 더 큰 모델이나 더 긴 context window에 비용을 투자하면서도 정작 검색 파이프라인의 결함은 그대로 남겨 둘 수 있기 때문입니다.

장문 모델의 우세가 의미하는 것

Long-context 모델은 수십만~수백만 자에 이르는 문서를 한 번에 입력받아 처리할 수 있습니다. 따라서 근거가 문서의 앞부분과 뒷부분, 혹은 여러 섹션에 흩어져 있어도 직접 찾아 연결할 가능성이 있습니다.

반면 일반적인 RAG는 먼저 검색 단계에서 일부 chunk만 선택합니다. 여기서 필요한 근거 하나가 빠지면, 이후 생성 모델이 아무리 뛰어나도 완전한 답을 만들기 어렵습니다.

예를 들어 다음 질문을 보겠습니다.

연구 A의 저자가 연구 B의 한계로 지적한 내용은 무엇인가?

이 질문에 답하려면 최소한 다음 정보가 필요합니다.

1. 연구 A의 저자 또는 문서 식별 정보
2. 연구 A가 연구 B를 언급한 부분
3. 연구 B의 방법 또는 주장
4. 연구 A가 제시한 비판이나 한계 분석

장문 모델은 전체 문서 집합에서 이 단서를 모두 발견할 수 있습니다. 그러나 RAG가 “한계”, “방법”, “성능”처럼 질문과 표면적으로 유사한 chunk만 가져온다면, 저자 정보나 문서 간 인용 관계가 담긴 핵심 근거를 놓칠 수 있습니다.

이때 장문 모델이 더 좋은 답을 냈다고 해서 반드시 읽기 능력의 승리라고 단정할 수는 없습니다. 더 정확한 해석은 다음과 같습니다.

장문 모델: 필요한 근거를 문맥 안에서 모두 볼 수 있었다.
RAG: 필요한 근거 중 일부를 검색 단계에서 누락했다.

즉, 병목은 생성이 아니라 retrieval일 수 있습니다.

RAG 오류를 분리해서 봐야 하는 이유

RAG의 실패는 크게 두 종류로 나눌 수 있습니다.

오류 유형	설명	대표적인 증상
검색 실패	답변에 필요한 evidence가 context에 들어오지 않음	핵심 문서·표·메타데이터·두 번째 근거 누락
생성 실패	필요한 evidence는 있었지만 모델이 잘못 해석하거나 연결함	잘못된 요약, 잘못된 추론, 근거와 다른 결론

이 구분 없이 최종 답변만 평가하면 문제가 생깁니다.

예를 들어 답변이 틀렸을 때, 단순 평가 방식은 “모델이 답을 못 했다”고 결론 내릴 수 있습니다. 하지만 실제로는 모델이 실패한 것이 아니라, 검색기가 필요한 문서를 보여 주지 않았을 가능성이 있습니다.

반대로 검색 결과에 모든 근거가 들어 있었는데도 모델이 이를 무시하거나 잘못 연결했다면, 이는 retrieval 문제가 아니라 generation 또는 reasoning 문제입니다.

EBG는 바로 이 지점을 진단하기 위해 답변뿐 아니라 문장별 인용 근거를 함께 확인합니다.

질문
  ↓
검색된 evidence 확인
  ↓
답변의 각 claim 확인
  ↓
claim별 citation 확인
  ↓
검색 누락인지, 생성 오류인지 분리

이 구조를 적용하면 “답변이 틀렸다”는 모호한 결론 대신 다음과 같이 더 구체적인 분석이 가능합니다.

• 필요한 문서가 검색되지 않았는가?
• 문서는 검색됐지만 관련 줄이 context에서 잘렸는가?
• 근거는 충분했지만 모델이 두 사실을 연결하지 못했는가?
• 모델이 검색 근거보다 기존 사전 지식을 우선했는가?
• 답변은 맞지만 핵심 claim의 인용이 빠졌는가?

정답만으로는 RAG를 평가할 수 없다

가령 모델이 다음과 같이 답했다고 가정해 보겠습니다.

정책 X는 2026년에 적용 기준이 변경되었다.

답변 자체는 맞을 수 있습니다. 그러나 그 정답이 최신 검색 문서에 근거한 것인지, 모델이 학습 데이터에서 기억한 정보를 재생한 것인지는 별개의 문제입니다.

특히 최신 정책, 내부 규정, 계약 조건, 의료 지침처럼 정보가 자주 바뀌는 환경에서는 이 차이가 치명적입니다. 모델의 사전 지식이 우연히 맞았더라도, 사용자는 그 답변을 신뢰할 수 있는 근거를 확인해야 합니다.

따라서 EBG 관점의 RAG 평가는 다음 세 가지를 동시에 묻습니다.

1. 정답인가?
2. 검색된 evidence에 근거한 답변인가?
3. 답변의 모든 핵심 주장이 충분한 인용으로 뒷받침되는가?

이 중 하나라도 빠지면 운영 환경에서는 위험할 수 있습니다. 특히 “답은 맞지만 인용이 틀린 경우”는 겉으로는 성공처럼 보이지만, 감사·검토·재현이 필요한 업무에서는 실패에 가깝습니다.

실무에서는 진단 로그가 필요하다

RAG 시스템을 개선하려면 최종 답변만 저장해서는 부족합니다. 최소한 다음 정보를 함께 기록해야 합니다.

• 사용자 질문
• 질문을 분해한 하위 질문
• 검색된 문서와 chunk
• 검색 순위 및 검색 점수
• 누락된 것으로 판정된 evidence
• 답변의 claim 단위 구성
• claim별 citation
• citation이 claim을 직접 지지하는지에 대한 검증 결과

이 로그가 있어야 운영팀은 문제를 올바르게 해결할 수 있습니다.

예를 들어 evidence가 누락됐다면 다음 개선이 필요합니다.

• query expansion
• hybrid search
• iterative retrieval
• 문서·섹션·메타데이터 검색
• entity 기반 재검색
• chunk 주변 문맥 복원

반대로 evidence가 충분했는데 답변이 틀렸다면, 생성 프롬프트·추론 단계·citation entailment 검증·모델 선택을 개선해야 합니다.

결국 EBG가 제시하는 핵심은 단순합니다. RAG가 틀렸을 때 먼저 생성 모델을 탓하지 말고, 답변에 필요한 증거가 실제로 검색됐는지부터 확인해야 한다는 것입니다. 장문 모델이 더 잘한 것처럼 보이는 순간에도, 진짜 경쟁력은 “더 잘 읽는 능력”이 아니라 “필요한 evidence를 빠짐없이 확보하는 능력”에 있을 수 있습니다.

RAG, 검색 후 생성에서 증거 수집·검증·인용으로

RAG의 성공을 단지 “관련 문서를 찾았는가?”로 판단하던 기준은 이제 충분하지 않습니다. 특히 여러 문서의 정보를 연결해야 하는 업무에서는 더 까다로운 질문이 필요합니다.

답변에 필요한 모든 증거를 확보했는가? 그리고 각 주장을 사용자가 검증할 수 있는 방식으로 제시했는가?

이 관점에서 RAG는 더 이상 단순한 검색 → 답변 생성 파이프라인이 아닙니다. 신뢰할 수 있는 시스템이 되려면 증거 수집, 근거 완전성 확인, 주장별 인용, 인용 검증까지 하나의 흐름으로 설계되어야 합니다.

답변이 맞아도 신뢰할 수 없는 이유

예를 들어 모델이 “정책 A는 2026년에 변경되었다”고 답했다고 가정해 보겠습니다. 답변 자체는 맞을 수 있습니다. 하지만 다음 질문에는 답하지 못할 수 있습니다.

• 어느 문서의 어떤 문장이 이 답을 뒷받침하는가?
• 변경 시점과 변경 내용을 모두 확인했는가?
• 최신 정책 문서가 아니라 모델의 과거 지식에 의존한 것은 아닌가?
• 인용된 문장이 실제로 해당 주장을 직접 지지하는가?

일반적인 RAG는 검색 결과에 관련 chunk가 포함되어 있고, 최종 답변이 그럴듯하면 성공으로 처리하기 쉽습니다. 그러나 실제 업무에서는 관련 정보 하나를 찾는 것만으로 충분하지 않습니다. 답변이 여러 주장으로 구성되어 있다면, 각 주장에는 대응하는 근거가 필요합니다.

좋은 답변 = 정답성 + 근거 충실성 + 인용 완전성

이 기준이 없으면 모델은 일부 정보만 검색한 뒤 빈 부분을 사전 지식이나 추론으로 채울 수 있습니다. 결과적으로 답변은 자연스럽지만, 사용자가 검증할 수 없는 답변이 됩니다.

EBG가 바꾸는 RAG의 작업 흐름

Evidence-Based Generation(EBG)은 RAG의 결과물을 답변 하나로 보지 않습니다. 답변과 함께 그 답변을 지지하는 증거를 생성하고, 증거의 충분성까지 평가합니다.

기존 흐름은 비교적 단순합니다.

질문
→ 유사한 chunk 검색
→ 검색 결과를 LLM에 입력
→ 답변 생성

반면 EBG 관점의 흐름은 다음과 같이 확장됩니다.

질문 분석
→ 하위 질문과 필요한 증거 유형 식별
→ 문서·섹션·메타데이터 검색
→ 부족한 근거를 위한 반복 검색
→ 문서 수준 맥락 복원
→ 근거 완전성 검사
→ 답변 생성
→ 주장별 citation 연결
→ citation entailment 검증

핵심 차이는 검색의 목표입니다. 기존 RAG는 질문과 비슷한 문장을 찾는 데 집중합니다. EBG 중심 RAG는 답변을 완성하는 데 필요한 증거 집합을 빠짐없이 확보하는 것을 목표로 합니다.

“관련 문서”가 아니라 “완전한 증거 체인”을 찾아야 한다

다중 문서 질의에서는 검색 결과에 관련 자료가 하나 포함되어 있어도 답변이 완성되지 않을 수 있습니다.

가령 다음과 같은 질문을 생각해 볼 수 있습니다.

특정 연구자가 이전 논문의 방법론에 대해 어떤 한계를 지적했는가?

이 질문에 답하려면 적어도 다음 증거가 필요할 수 있습니다.

1. 해당 연구자가 누구인지 확인하는 정보
2. 그 연구자가 작성한 문서 또는 발언
3. 이전 논문이 제안한 방법론
4. 그 방법론의 한계를 지적한 문장

벡터 검색은 이 가운데 질문과 가장 의미적으로 가까운 문단을 찾을 수 있습니다. 하지만 한계 분석 문단만 찾고, 그것이 어떤 방법론을 가리키는지 설명하는 문단을 놓칠 수도 있습니다. 또는 저자 정보가 문서 첫 페이지의 메타데이터에 있어 본문 chunk 검색에서 누락될 수도 있습니다.

따라서 RAG는 검색 결과의 개수보다 다음을 확인해야 합니다.

• 모든 하위 질문에 대응하는 근거가 있는가?
• 각 근거는 같은 대상과 문맥을 가리키는가?
• 서로 다른 문서의 정보를 잘못 연결하지 않았는가?
• 답변의 핵심 주장마다 직접 인용할 수 있는 원문이 있는가?

이 과정은 검색 품질을 단순 Recall@k가 아니라 evidence completeness, 즉 증거 완전성의 문제로 바라보게 합니다.

인용은 장식이 아니라 검증 인터페이스다

답변 뒤에 출처 링크 하나를 붙이는 것만으로는 충분하지 않습니다. 긴 보고서나 여러 문서가 섞인 검색 환경에서는 사용자가 어떤 문장이 어떤 근거에 기반하는지 빠르게 확인할 수 있어야 합니다.

가장 바람직한 방식은 주장 단위의 인용입니다.

방법 A는 다중 문서 질의에서 더 안정적인 결과를 보였다. [문서 1, 12~18행]

다만 문서 간 관계를 명시적으로 추적하지 않으면
두 번째 핵심 근거가 누락될 수 있다. [문서 2, 31~36행]

이 구조는 단순히 출처를 보여 주는 것을 넘어, 답변의 검증 경로를 제공합니다. 사용자는 다음을 빠르게 판단할 수 있습니다.

• 인용된 원문이 실제로 주장을 지지하는가?
• 핵심 주장에 인용이 빠지지 않았는가?
• 인용은 최신 문서에 기반하는가?
• 모델이 검색된 근거와 다른 내용을 말하고 있지는 않은가?

특히 법률, 의료, 금융, 연구 분석처럼 설명 책임이 필요한 분야에서는 답변의 유창함보다 이 검증 가능성이 더 중요할 수 있습니다.

실무 RAG가 갖춰야 할 최소 점검 항목

EBG의 관점을 적용하려면 모델 응답을 생성한 뒤 평가하는 것만으로는 부족합니다. 답변 생성 전후에 증거 상태를 점검해야 합니다.

다음 체크리스트를 파이프라인에 포함하는 것이 실용적입니다.

[ ] 질문을 답변 가능한 하위 질문으로 분해했는가?
[ ] 각 하위 질문에 필요한 문서, 엔터티, 날짜, 표 정보를 찾았는가?
[ ] 문서 제목·섹션·저자·발행일 등 메타데이터를 보존했는가?
[ ] 필요한 근거가 여러 문서에 걸쳐 있다면 반복 검색을 수행했는가?
[ ] 답변의 모든 핵심 claim에 citation이 연결되었는가?
[ ] citation이 claim을 직접 지지하는가?
[ ] 검색 근거와 모델의 사전 지식이 충돌하지 않는가?
[ ] 근거가 부족한 경우 단정 대신 불확실성을 표시했는가?

결국 차세대 RAG의 경쟁력은 더 많은 문서를 빠르게 검색하는 데만 있지 않습니다. 필요한 모든 증거를 수집하고, 문서 맥락을 보존하며, 답변의 각 주장에 검증 가능한 인용을 연결하는 능력에 있습니다.

검색 후 생성은 시작점일 뿐입니다. 신뢰할 수 있는 RAG는 검색한 정보를 바탕으로 답하는 시스템이 아니라, 증거를 수집하고 검증하며 설명 가능한 형태로 제시하는 시스템이어야 합니다.