RAG 5단계 실패와 인용 환각 방지

세 줄 요약

무슨 변화/핵심 이슈인가? RAG는 인덱싱 → 분할 → 임베딩 → 검색 → 생성의 5단계 중 한 곳만 흔들려도 “찾았는데 틀린 답”과 “문서에 없는 인용”이 나온다.
왜 중요한가? FACTUM(논문 ID: arXiv:2601.05866)은 긴 형식 RAG에서 citation hallucination을 주요 실패로 다루고, RefusalBench(논문 ID: arXiv:2510.10390)는 문맥이 부족할 때의 선택적 거절이 안전과 직결된다고 본다.
독자는 뭘 하면 되나? 분할 규칙 점검 → 검색/리랭킹 점검 → 근거 부족 시 거절 평가를 3단계 체크리스트로 돌리고, “문서에 없으면 인용하지 않기”를 테스트로 확인한다.

회의실에서 “이번 분기 환불 정책을 예외 조항까지 포함해 요약해달라”는 질문이 나온다. 챗봇 답은 그럴듯하지만, 원문을 확인하니 인용 문장이 문서 어디에도 없다. RAG(검색증강생성) 파이프라인은 이런 식으로 “검색은 했는데, 근거가 틀린” 상태가 되면서 신뢰를 잃는다.

예: 팀 회의에서 누군가가 정책 요약을 부탁한다. 답변은 매끈하지만, 동료가 문서 원문을 펼쳐 보니 해당 문장이 보이지 않는다. 사람들은 도구를 쓰는 대신 다시 문서를 뒤적이기 시작한다.

이 글은 RAG를 **인덱싱(ingestion) → 분할(chunking) → 임베딩(embedding) → 검색(retrieval) → 생성(generation)**으로 나눠, 각 단계에서 정확도를 무너뜨리는 실패 패턴과 회피법을 정리한다. 포인트는 단순하다. RAG 품질은 모델 자체보다 문서 구조·분할·질의·랭킹·근거 통제에서 무너지는 경우가 반복된다.

현황

RAG 적용이 늘면서, “답은 그럴듯하지만 근거가 문서와 어긋나는” 문제가 실무 리스크로 커지고 있다. OpenAI 도움말은 파일 업로드로 지식 검색을 켜면 내부적으로 **chunking(문서를 더 작은 섹션으로 분할)**과 embedding(벡터화) 같은 과정이 진행된다고 설명한다. 즉, RAG는 “문서를 나누고, 의미 공간에 넣고, 관련 조각을 찾아, 그 조각으로 답을 쓰는” 5단계 파이프라인으로 볼 수 있다.

문제는 파이프라인이 길수록 실패 지점이 늘어난다는 점이다. 조사 결과 기준으로 대표 실패는 크게 4갈래로 묶인다.
(1) 인덱싱/ingestion에서 문서 구조나 운영 메타데이터(예: 권한/버전)를 보존하지 못해 이후 단계가 흔들리고,
(2) chunking이 너무 작거나 크거나 문서 구조를 무시해 문맥이 깨지면서 임베딩과 검색 품질이 함께 떨어지며,
(3) retrieval에서 질의가 모호하거나 랭킹/리랭킹·필터링 설계가 약해 관련 문서를 못 찾고,
(4) generation에서 검색 문맥이 부족할 때 모델이 환각—특히 근거 없는 인용/출처—을 만들 수 있다.

학계는 이 문제를 더 구체적으로 다룬다. FACTUM(arXiv:2601.05866)은 긴 형식 RAG에서 citation hallucination을 “모델이 출처를 제시하지만, 그 출처가 주장을 지지하지 않는 실패”로 설명한다. RefusalBench(arXiv:2510.10390)는 반대로, 문맥이 불충분할 때 모델이 선택적으로 답변을 거절해야 안전해지는데도 이것이 반복적으로 실패할 수 있다고 본다.

분석

핵심은 “정확도”가 단일 지표가 아니라는 점이다. RAG는 최소한 3가지를 함께 맞춰야 한다.
(1) 검색이 맞는가(관련성), (2) 생성이 검색 근거에 묶여 있는가(grounding), (3) 근거가 부족할 때 멈출 수 있는가(refusal).
chunking이 틀어지면 검색이 약해지고, 검색이 약해지면 생성은 빈칸을 메우려 하며, 그 결과가 인용 환각으로 이어질 수 있다. 이 연결고리를 끊지 못하면 “모델을 바꿨는데도 품질이 크게 달라지지 않는” 상황이 생긴다.

운영 리스크도 분리해서 봐야 한다. 조사 결과는 ingestion 단계에서 문서 구조·메타데이터(권한/버전 등) 보존 실패를 원인으로 든다. 여기서 “답변이 맞느냐”와 “서비스가 안전하냐”가 갈라진다. 예를 들어 폐기된 문서 버전을 검색해도 답은 그럴듯해 보일 수 있다. 하지만 감사, 규정 준수, 내부 정책처럼 “어떤 버전을 근거로 했는지”가 중요한 업무에서는 그 자체가 사고로 이어질 수 있다. 다만 권한(ACL) 기반 메타데이터 설계 실패를 업계 전반의 일반적 현상으로 단정하기는 어렵고, 추가 확인이 필요하다(원문에서도 Unverified로 언급됨).

한계도 분명하다. RAG는 “문서가 있으면 정답”을 보장하지 않는다. 문서가 틀릴 수도 있고, 문서가 맞아도 chunking이 문맥을 찢을 수 있으며, 검색이 맞아도 모델이 인용을 과장할 수 있다. FACTUM이 다루는 인용 환각은 특히 “출처가 있으니 맞아 보이는” 형태가 될 수 있어, 탐지와 사후 대응 비용이 커질 수 있다. RefusalBench가 던지는 질문도 실무적이다. “근거가 부족할 때, 모델은 정말 멈추는가?” RAG를 프로덕션에 넣는 순간, 이 질문은 품질뿐 아니라 안전 문제로 바뀐다.

실전 적용

RAG를 운영하는 팀은 파이프라인을 ‘기능’이 아니라 ‘제품’으로 다루는 편이 낫다. ingestion에서는 문서 구조와 출처 단서를 가능한 한 보존하고, chunking에서는 문단 같은 물리 단위만 따르기보다 논리 블록(제목-본문-표-각주 등) 기준을 설계한다. retrieval에서는 “검색이 되느냐”보다 “원하는 문서가 상단에 오느냐”를 확인한다. generation에서는 문체보다 근거 통제(인용은 문서에 있을 때만, 부족하면 거절)를 우선순위로 둔다.

예: 한 팀이 내부 문서로 답하는 도우미를 만든다. 초기에 조각을 잘게 나눴더니 검색 결과가 많이 나오는데도 답이 흔들린다. 조각 경계가 제목과 본문을 갈라 놓고, 예외 조항이 다른 조각으로 떨어진다. 팀은 논리 단위로 분할 규칙을 바꾸고, 검색 단계에서 필터와 리랭킹을 조정한다. 마지막으로 “근거가 없으면 모른다고 말하기”를 통과 조건으로 둔다. 그 뒤 답변은 짧아지지만, 인용 오류는 줄어든다.

오늘 바로 할 일:

샘플 문서로 chunking 결과를 확인하고, 제목-섹션-조항이 같은 조각에 남는지 점검한다.
모호한 질의에서도 관련 문서가 상단에 오도록 retrieval의 필터링/리랭킹 규칙을 검토한다.
근거가 부족한 입력을 넣어 generation이 일관되게 답변을 거절하는지 테스트 케이스로 평가한다.

FAQ

Q1. RAG에서 제일 먼저 손대야 할 건 뭔가?
A. 조사 결과가 반복해서 가리키는 첫 지점은 chunking이다. 너무 작거나 크거나 구조를 무시하면 임베딩과 검색이 함께 약해질 수 있다. 먼저 “문맥이 끊기는 분할”이 있는지부터 확인하는 편이 비용 대비 효과가 나을 때가 많다.

Q2. 인용 환각(citation hallucination)은 왜 더 위험한가?
A. FACTUM이 설명하듯, 인용 환각은 “출처를 댔기 때문에 맞는 것처럼 보이지만 실제로는 근거가 없는” 실패다. 사람 검토를 통과할 가능성이 커지고, 나중에 발견되면 신뢰 손실과 수정 비용이 늘 수 있다.

Q3. ‘모르면 모른다’는 기능이 왜 RAG에서 중요하나?
A. RefusalBench가 지적하듯, RAG는 문맥이 결함일 때 모델이 선택적으로 거절해야 안전해진다. 검색 문맥이 불충분한데도 답을 강행하면, 그 순간 RAG는 “근거 기반”이 아니라 “그럴듯한 작문”으로 동작하게 된다.

결론

RAG는 모델을 붙인 검색이 아니라, 문서 분할·검색 설계·근거 통제가 맞물린 생산 라인에 가깝다. 분할 → 검색 → 생성에서 작은 결정이 인용 환각과 선택적 거절 실패로 이어질 수 있다는 점을 염두에 둬야 한다. 다음 단계는 단순 고도화가 아니라, “근거가 없으면 멈추는가”를 제품 요구사항으로 올려두고 검증하는 일이다.

Aionda

RAG 5단계 실패와 인용 환각 방지

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기