← Back to Blog
AI · AX Article · 2026.09.29

관련 문서를 찾았는데도 RAG가 답하면 안 되는 이유

RAG에서 관련성 높은 검색 결과와 질문에 답하기 충분한 맥락을 구분하고, 검색 실패·생성 실패·응답 정책 실패를 따로 진단하는 방법을 살펴본다.

AIRAGcontext-engineeringevaluationAKM

질문에서 출발한 빛이 여러 자료 조각을 지나지만 일부 근거가 비어 있어 답변으로 이어지지 못하는 추상 개념 이미지

이 글의 개념을 표현하기 위해 GPT Image 2로 생성한 이미지이며, 실제 RAG 시스템의 화면이나 성능 측정 결과가 아니다.

사내 규정을 검색하는 RAG에 "프리랜서도 교육비를 지원받을 수 있는가"라고 물었다고 하자. 검색기는 교육비라는 단어가 여러 번 등장하는 최신 규정을 찾아낸다. 문서에는 지원 금액과 신청 기한이 자세히 적혀 있지만, 지원 대상의 고용 형태는 없다. 이 결과는 질문과 관련이 높다. 그러나 답을 결정할 정보는 빠져 있다.

이때 모델이 "가능합니다"라고 답하면 흔히 환각이라고 부른다. 그 말만으로는 고칠 곳을 찾기 어렵다. 검색기가 엉뚱한 문서를 골랐는지, 관련 문서 안에서 필수 조건을 놓쳤는지, 모델이 주어진 근거를 제대로 쓰지 못했는지, 정보가 부족한데도 답하게 만든 정책이 문제인지가 한데 섞이기 때문이다.

2025년 ICLR에 발표된 《Sufficient Context: A New Lens on Retrieval Augmented Generation Systems》은 이 문제를 "맥락이 질문에 답하기 충분한가"라는 별도 축으로 본다.[1] 검색 결과의 관련성 점수를 높이는 일과 답변 가능성을 확인하는 일을 분리한다.

관련성은 주제의 거리이고, 충분성은 답의 조건이다

논문은 질문과 검색된 맥락의 쌍을 기준으로 충분성을 정의한다. 주어진 맥락만으로 질문에 확정적인 답을 구성하는 데 필요한 정보가 모두 있으면 충분하다. 필요한 정보가 빠졌거나, 결론을 내릴 수 없거나, 서로 모순되면 불충분하다. 이 판정에는 정답 문장이 반드시 필요하지 않다. 질문과 맥락만 보고 답에 필요한 재료가 갖춰졌는지를 묻는다.[1]

관련성은 더 느슨한 기준이다. 404 오류의 원인과 해결법을 설명한 문서는 404에 관한 질문과 밀접하다. 그러나 "404라는 이름이 유래했다는 방은 어느 연구소에 있었는가"라는 질문에는 연구소 이름이 있어야 답할 수 있다. Google Research가 소개한 사례처럼, 주제가 정확히 맞아도 요구한 사실이 없으면 맥락은 불충분하다.[2]

검색 결과가 많다는 사실만으로는 안심할 수 없다. 상위 다섯 문서가 모두 같은 빠진 정보를 반복할 수 있다. 반대로 짧은 한 문단이 질문의 모든 조건을 담고 있을 수도 있다. 유사도와 문서 수는 충분성의 대리 지표가 될 수 있지만, 그 자체가 충분성을 보장하지는 않는다.

논문의 충분성 판정은 참·거짓의 이진 분류다. 연구진은 사람이 판정한 질문–맥락 예시 115개를 기준으로 LLM 자동 평가자가 얼마나 같은 판단을 내리는지 살폈다.[1] 이 수치는 충분성을 완전히 자동화할 수 있다는 보증이 아니다. 판정 모델도 조건을 놓치거나, 모순을 잘못 읽거나, 이미 아는 사실이 맥락에 들어 있다고 착각할 수 있다. 실제 업무에서는 자동 판정을 기록 가능한 가설로 다루고 표본 검토를 남겨야 한다.

실패를 검색기와 생성기 사이에서 나눈다

충분성을 따로 보면 같은 오답도 원인이 달라진다.

맥락이 충분한데 답이 틀렸다면 검색 범위를 넓히는 것만으로는 해결되지 않는다. 필요한 근거는 이미 들어왔다. 모델이 여러 구절을 결합하지 못했거나, 조건과 부정을 놓쳤거나, 답변 형식으로 옮기는 과정에서 오류를 냈을 가능성을 봐야 한다. 논문도 충분한 맥락이 주어진 사례에서 모델이 오답을 내는 비율이 적지 않았다고 보고한다.[1]

맥락이 불충분한데도 단정했다면 검색과 응답 정책을 함께 살펴야 한다. 검색기는 필수 근거를 회수하지 못했고, 생성기는 빈칸을 내부 지식이나 추정으로 메웠다. 더 큰 모델도 이 조건에서 언제나 멈추지 않았다. 논문이 분석한 성능이 높은 모델들은 충분한 맥락에서는 강했지만, 불충분한 맥락에서는 답변 보류보다 틀린 답을 내는 경우가 있었다.[1]

맥락이 불충분한데 답이 우연히 맞는 경우도 있다. 모델의 사전 지식이 맞았거나 단서로 추론했을 수 있다. 업무 RAG에서 이 결과를 성공으로 세면 근거 추적이 무너진다. 질문에 맞는 답과 제공된 자료로 뒷받침되는 답은 별도 상태다. 특히 규정, 계약, 일정처럼 현재 문서가 권위의 기준인 업무에서는 모델이 알고 있던 일반 지식이 정확해도 채택 근거가 될 수 없다.

RagChecker는 다른 각도에서 이 분해를 돕는다.[3] 검색기가 정답에 필요한 주장 중 얼마를 가져왔는지는 claim recall로 본다. 가져온 문서 조각 중 관련 조각의 비율은 context precision으로 본다. 생성기가 검색 맥락에 근거했는지는 faithfulness로, 회수된 관련 정보를 답에 얼마나 썼는지는 context utilization으로 나눈다. 이 지표들이 곧 충분성 판정은 아니다. 다만 "자료가 없었다"와 "자료는 있었지만 쓰지 못했다"를 한 점수 안에 감추지 않게 한다.

답변 전에 근거 슬롯을 확인한다

AKM 업무에서는 검색 뒤에 바로 생성을 붙이지 말고, 질문이 요구하는 근거 슬롯부터 적을 수 있다. 앞의 교육비 질문이라면 최소 슬롯은 지원 대상, 지원 항목, 한도, 신청 기한, 적용 시점이다. 질문에 따라 일부만 필요할 수도 있다. 중요한 점은 문서가 무엇을 많이 말하는지가 아니라, 이번 답을 결정하는 슬롯이 채워졌는지 확인하는 것이다.

다음 흐름은 논문의 구현을 복제한 것이 아니라, 충분성 개념을 AKM에 옮긴 DEXA의 설계 제안이다.

  1. 질문을 답변에 필요한 주장과 조건으로 나눈다.
  2. 검색 결과마다 어떤 근거 슬롯을 채우는지, 원문의 정확한 위치가 어디인지 남긴다.
  3. 생성 전에 충분, 부분, 충돌을 판정한다.
  4. 충분할 때만 전체 답을 만들고, 부분 상태에서는 확인된 범위와 빠진 근거를 함께 돌려준다.
  5. 답의 각 주장에 사용한 원문을 연결하고, 검색됐지만 쓰지 않은 자료도 구분한다.

여기서 부분과 충돌은 논문의 이진 레이블이 아니라 운영을 위한 제안이다. 부분 상태는 일부 질문에는 답할 수 있지만 전체 결론에는 필요한 정보가 빠진 경우다. 충돌 상태는 필요한 정보가 여러 출처에 있지만 값이나 적용 조건이 맞지 않는 경우다. 둘을 모두 "불충분"으로만 저장하면 다음 행동이 흐려진다. 부분 상태에는 추가 검색이, 충돌 상태에는 권위와 시점 확인이 먼저 필요하다.

답변을 보류하면서 확인한 범위까지 숨길 필요는 없다. "확인할 수 없습니다"와 함께 무엇을 확인했는지, 어떤 조건이 빠졌는지, 어느 자료가 서로 충돌하는지를 보여 줄 수 있다. 다만 이 형식을 또 하나의 그럴듯한 설명으로 만들지 않으려면, 빠진 슬롯과 확인한 출처를 구조화된 기록에서 가져와야 한다.

충분성 판정도 평가 대상이다

충분성 게이트를 추가하면 오류가 사라지는 대신 새 판정기가 생긴다. 거짓 양성은 특히 위험하다. 근거가 모자란데 충분하다고 표시해 생성으로 넘기기 때문이다. 거짓 음성은 답할 수 있는 질문을 보류시켜 업무 효율을 떨어뜨린다. 두 오류의 비용은 업무에 따라 다르다. 행사 추천의 불필요한 보류와 계약 의무의 근거 없는 단정에 같은 임계값을 쓸 이유가 없다.

평가를 결과 정답률 하나로 뭉치지 않는다. 최소한 네 칸이 필요하다.

  • 충분한 맥락에서 정답을 냈는가
  • 충분한 맥락에서 근거를 놓쳤는가
  • 불충분한 맥락에서 답변 범위를 줄이거나 보류했는가
  • 불충분한 맥락에서 외부 지식을 사실처럼 섞었는가

여기에 검색 단계의 필수 주장 회수율과 생성 단계의 근거 사용률을 붙이면 수정할 모듈이 보인다. 충분한 맥락에서 계속 실패하면 프롬프트, 모델, 컨텍스트 배열, 합성 방식을 살핀다. 불충분 판정이 많다면 검색 범위, 문서 분할, 질의 재작성, 원문 자체의 공백을 구분한다. 검색으로 존재하지 않는 정책 문구를 만들어 낼 수는 없다.

논문은 충분성 정보를 이용해 생성 여부를 조절하는 selective generation을 실험했고, 답을 한 경우 중 정답의 비율이 모델에 따라 2~10% 개선됐다고 보고했다.[1] 이는 모든 요청의 정답률이 그만큼 올랐다는 뜻이 아니다. 답하지 않는 사례가 늘면 coverage가 줄 수 있다. 정확도와 응답률을 함께 공개해야 보류가 만든 이득을 판단할 수 있다.

더 많은 맥락이 항상 충분한 맥락은 아니다

긴 문서를 더 넣으면 빠진 근거를 찾을 가능성은 커지지만 잡음도 늘어난다. 서로 다른 시행일의 규정이 한 맥락에 들어오면 필요한 정보가 모두 있어 보여도 어느 값을 적용할지 결정할 수 없다. 충분성은 토큰 수가 아니라 질문, 조건, 출처 권위, 시점의 조합에 달려 있다.

판정 비용도 생긴다. 질문을 분해하고 맥락을 평가하는 호출은 지연과 비용을 늘린다. 단순한 사내 용어 조회까지 복잡한 게이트를 거치게 하면 운영 부담이 이득보다 커질 수 있다. 위험도가 낮고 정답 조건이 단순한 질문에는 규칙 기반 필수 필드 검사로 충분할 수 있다. 여러 문서를 결합하거나 잘못된 단정의 비용이 큰 업무부터 적용하는 편이 낫다.

마지막으로 충분성은 진실성 전체를 보증하지 않는다. 맥락 안에 답을 만들 재료가 모두 있어도 그 문서가 오래됐거나 잘못됐을 수 있다. 모델이 문서를 충실히 요약해도 출처 자체가 틀리면 답도 틀린다. 충분성 게이트 뒤에는 권위, 최신성, 충돌, 인용 정확도 검사가 남는다.

RAG의 검색 결과를 볼 때 "관련 문서를 찾았는가"에서 멈추지 말아야 한다. 이번 질문의 결론을 정하는 정보가 실제로 들어왔는지, 들어왔다면 모델이 그것을 썼는지, 없다면 시스템이 멈췄는지를 따로 기록해야 한다. 세 경계를 나눠 기록해야 어디를 고칠지 알 수 있다.

참고 자료