RAG 환각의 근본 원인
깨진 파싱

실패 체인은 검색 이전부터 시작됩니다

검색 증강 생성은 네 단계로 이루어진 체인이며, 각 단계는 이전 단계가 만들어낸 결과를 그대로 이어받습니다. 파서는 페이지를 텍스트로, 가능하다면 구조로 변환합니다. 청커는 그 텍스트를 검색 단위로 나눕니다. 검색기는 단위를 선택합니다. 모델은 검색기가 전달한 내용을 바탕으로 답변을 작성합니다.

이 체인이 중요한 이유는 청커가 파서가 제공한 내용만 분할할 수 있고, 파서가 버린 구조를 다시 추가할 수 없기 때문입니다. 테이블이 하나의 긴 줄로 평탄화되어 들어오면 청커는 존중할 행 경계가 없습니다. 두 개의 열이 서로 섞여 들어오면 어떤 청크 크기로도 다시 분리할 수 없습니다. 파싱 단계가 바닥을 설정하며, 이후의 모든 단계는 그 위에 놓입니다.

이것은 드문 예외 사례가 아닙니다. ICCV 2025에서 발표된 OHR-Bench 연구는 7개의 실제 RAG 애플리케이션 도메인에 걸친 8,561개의 비정형 문서 이미지와 8,498개의 질문-답변 쌍으로 구성된 테스트 세트를 구축한 다음, OCR 노이즈가 검색과 생성 과정을 통해 어떻게 전파되는지 측정했습니다. 벤치마크에서 가장 우수한 OCR 솔루션조차 깨끗한 정답 텍스트 구조화 데이터보다 최소 14% 부족했으며, 의미적 노이즈가 경미한 수준에서 심각한 수준으로 높아짐에 따라 대부분의 검색기와 언어 모델은 성능의 거의 절반을 잃었습니다 (Zhang et al., "OCR Hinders RAG", arXiv:2412.02592).

그 14%의 격차는 팀들이 과소평가하는 부분입니다. 파싱 오류는 파싱 단계에 머물지 않습니다. 그것은 청크가 되고, 임베딩이 되고, 검색 결과가 되고, 답변 속 문장이 됩니다.

파싱은 그 위에 있는 모든 것의 상한선을 설정합니다. 어떤 청킹 전략도 파서가 평탄화한 테이블 행을 다시 추가하거나, 가로질러 읽은 두 열을 다시 분리할 수 없습니다.

모델이 비난을 받는 이유

RAG 시스템이 실제로 실패할 때, 그 실패는 대개 생성기가 아니라 검색이나 콘텐츠에 있습니다. Deakin University의 경험 보고서는 세 가지 실제 RAG 사례 연구와 15,000개 문서 및 1,000개 질문에 대한 실증적 실행을 분석한 후, 일곱 가지 실패 지점을 분류했습니다. 그중 세 가지가 정확히 이 패턴을 설명합니다: 답변이 반환될 만큼 높은 순위에 오르지 못했거나, 검색되었지만 컨텍스트 조립 과정에서 유실되었거나, 컨텍스트에 존재했음에도 모델이 이를 추출하지 못한 경우입니다. 저자들은 이를 너무 많은 노이즈 또는 상충되는 정보 때문이라고 설명합니다 (Barnett et al., "Seven Failure Points When Engineering a RAG System", arXiv:2401.05856).

"노이즈 또는 상충되는 정보"가 핵심 문구입니다. 숫자가 라벨을 잃은 청크에 대해 추론하는 모델은 잘못 추출된 실제 데이터에 근거하고 있으며, 라벨이 누락되었다는 사실을 알 방법이 없습니다. 문서 중심 환경에서 한 실무자는 몇 주간의 청크 변경, 임베딩 교체, 리랭커 실험 끝에 동일한 발견을 설명했습니다: 원본 문서 자체가 텍스트로 제대로 변환되지 않고 있었고, 겉보기 환각의 상당수는 모델이 잘못 추출된 데이터에 근거한 것이었습니다 (r/Rag, 2026년 3월).

그리고 모두가 가장 먼저 떠올리는 해결책이 있습니다: 모델에 더 많은 컨텍스트를 제공하는 것입니다. 이는 도움이 되기보다 역효과를 내는 경우가 더 많습니다.

언어 모델이 긴 입력을 사용하는 방식에 대한 연구는 U자형 성능 곡선을 발견했습니다. 모델은 컨텍스트의 맨 처음이나 맨 끝에 있는 정보를 가장 잘 활용하며, 관련 구절이 중간에 묻혀 있으면 성능이 떨어집니다. 한 오픈 도메인 테스트에서 검색 문서를 20개에서 50개로 늘렸을 때 리더 정확도는 약 1.5%만 향상된 반면, 입력량은 크게 증가했습니다 (Liu et al., "Lost in the Middle", arXiv:2307.03172).

top-k 또는 컨텍스트 창을 늘리면 모델이 추론할 자료가 더 많아집니다. 손상된 자료가 더 깨끗해지지는 않습니다.

실제로 RAG를 망치는 파싱 실패 유형

수집 실패는 무작위로 발생하지 않습니다. 대부분은 몇 가지 반복되는 유형에 속하며, 각각은 이후 체인에서 알아볼 수 있는 증상을 남깁니다. 아래 표에 정리했습니다.

사람은 평면화된 테이블을 읽을 때 문맥에서 격자 구조를 재구성할 수 있습니다. 그러나 청커는 그럴 수 없고 임베딩도 마찬가지입니다. 숫자와 헤더 사이의 관계는 파서가 이를 포착했을 때만 존재합니다. 이것이 두 파싱 계열의 차이입니다. 위치 기반 OCR은 문자를 읽고 위치에서 구조를 추론하는 반면, 비전 모델은 의미를 기준으로 페이지를 읽고 라벨을 값에 연결된 상태로 유지할 수 있습니다. 이 차이를 뒷받침하는 벤치마크 증거는 전통적인 OCR과 문서 파싱 비전 모델을 비교한 참조 페이지에서 확인할 수 있습니다.

파싱 레이어가 문제인지 확인하는 방법

어느 단계에서 실패했는지 추측할 필요가 없습니다. 체인의 모든 연결고리마다 테스트가 있으며, 테스트 비용은 저렴합니다. 순서대로 실행하고 답을 얻는 즉시 중단하세요.

가장 깔끔한 단일 테스트: 모델에게 답이 나온 페이지의 정답 텍스트를 제공하세요. 답을 정확히 맞히면 검색과 생성이 문제가 아니었던 것입니다.

이러한 점검은 일반적인 추출 문제 해결과 겹치며, 특정 문서 유형이 같은 방식으로 계속 실패할 때 문서 추출 문제 진단 가이드의 증상-원인 매핑 이 유용한 참고 자료가 됩니다. 측정에 관한 한 가지 주의사항: 문자 수준 점수는 우수한 파서를 최악의 성능으로 평가할 수 있으므로, 이 CER이 문서 파싱을 오도하는 이유 분석에서 설명하듯이 단일 파싱 품질 수치를 주의해서 다루세요.

추출 계층에서 문제 해결

해결책은 페이지를 텍스트로 변환하는 첫 번째 계층에 있습니다. 구조가 여전히 보존될 수 있는 유일한 계층이기 때문입니다. 파싱 출력이 원시 문자 스트림이라면, 청커는 경계를 임의로 만들어야 하고 검색기는 노이즈를 순위화해야 합니다. 파싱 출력이 이미 구조화되고 레이블이 지정되어 있다면, 다운스트림 단계는 작업할 신뢰할 수 있는 데이터를 갖게 됩니다.

실질적인 변화는 위치 기반 판독에서 의미 기반 판독으로의 전환입니다. 위치 기반 OCR은 페이지를 문자로 변환하고 좌표로 배치한 다음, 레이아웃 규칙에 의존하여 제목, 값 또는 표 셀을 추측합니다. 비전 모델은 대신 페이지의 의미를 읽을 수 있으며, 이것이 맞춤 열 추출의 기반이 되는 접근 방식입니다. "Invoice Number", "Account Number" 또는 "Contract Value"와 같이 원하는 열 이름을 입력하면 AI가 필드의 의미를 이해하여 페이지 어디에서든 각 값을 찾습니다. 각 문서는 정의한 레이블에 값이 이미 연결된 상태로 열이 채워진 행으로 출력됩니다.

RAG 파이프라인의 경우, 이는 청커에 대한 입력을 변경합니다. 숫자의 벽 대신 표 행은 헤더를 유지합니다. 값에서 분리된 레이블 대신 쌍이 하나의 단위로 이동합니다. 추출 계층은 청크 경계를 결정하거나 임베딩 모델을 선택하지 않습니다. 다음 단계에 구조화되고 레이블이 지정된 출력을 전달하여, 그로부터 구축된 청크가 손상된 텍스트 위에 구축되지 않도록 합니다.

추출 계층을 스프레드시트가 아닌 자체 코드에 연결하려면 v1 API가 통합 지점입니다. 문서 업로드와 배치 작업을 처리하고 구조화된 JSON을 반환하며, 처리가 완료되면 웹훅을 통해 시스템에 알릴 수 있어 추출이 자체 애플리케이션이나 워크플로 뒤에 위치할 수 있습니다. 하나의 논리적 문서가 여러 페이지에 걸쳐 있는 말뭉치(예: 은행 명세서나 계약서)의 경우 Multi-Page Merge가 페이지를 단일 레코드로 다시 그룹화하므로 청크가 문서의 절반으로 구성되지 않습니다. 데이터 후처리 단계에서 추출 중 날짜와 금액을 고정 형식으로 정규화하여 식별자가 청크 간에 일관되게 유지되도록 할 수도 있습니다.

이것이 대체하는 것은 문서 읽기 단계이지 RAG 스택이 아닙니다. 대부분의 팀은 검색기, 벡터 저장소, 모델을 유지합니다. 추출 계층은 단순히 이미 손상된 텍스트를 그들에게 공급하지 않을 뿐입니다. 파싱 작업 자체에 대해 설명된 동일한 메커니즘은 AI 문서 파서 페이지에서 확인할 수 있습니다.

해결하지 못하는 것

여기서는 깔끔한 홍보보다 정직함이 더 중요합니다. 과장된 주장 위에 구축된 RAG 프로젝트는 파이프라인과 같은 방식으로 실패하기 때문입니다.

RAG 시스템을 구축하거나 실행하지 않습니다. 검색에 공급되는 문서 읽기 계층을 처리합니다. 벡터 데이터베이스를 설정하거나, 검색 전략을 선택하거나, 생성 단계를 실행하지 않습니다.

청크 경계나 임베딩 모델을 선택하지 않습니다. 이러한 결정은 파이프라인의 몫입니다. 추출 계층은 이러한 결정이 작동하는 텍스트의 품질만 변경합니다.

문서 간 필드를 매칭하지 않습니다. 각 문서 내의 필드를 명명된 열에 매핑합니다. 한 문서의 값을 다른 문서의 값과 비교하고 자동으로 결정하는 것은 별개의 작업이며 다운스트림 로직에 속합니다.

문서에 없는 값을 만들어낼 수 없습니다. 필드가 실제로 없는 경우 출력은 조작된 값이 아닌 공백입니다. 이것이 올바른 동작이며, 공백은 신뢰할 숫자가 아니라 출처를 확인하라는 신호입니다.

품질이 낮은 스캔은 여전히 정확도를 떨어뜨립니다. 바랜 감열지 영수증, 심한 기울어짐, 저해상도 사진은 어떤 시스템에서도 여전히 어렵습니다. 이러한 출력은 검토 과정이 필요합니다. 목표는 인간의 판단을 파이프라인 수정에서 재확인이 필요한 몇 가지 값 확인으로 옮기는 것입니다.

자주 묻는 질문

검색 결과가 관련성 있어 보이는데 RAG가 환각을 일으키는 이유는 무엇인가요?

관련성과 정확성은 서로 다른 개념입니다. 검색된 청크가 질문과 주제적으로 유사하더라도 답변에 필요한 값을 포함하지 않거나, 해당 값을 라벨에서 분리된 채로 포함할 수 있습니다. OHR-Bench 연구는 파싱 노이즈가 검색과 생성 모두를 저하시키는 것을 측정했으며, 따라서 관련성 있어 보이는 결과도 모델이 충실히 추론하는 손상된 증거일 수 있습니다.

더 큰 컨텍스트 창이나 더 높은 top-k로 RAG 환각을 해결할 수 있나요?

거의 그렇지 않습니다. 장문 컨텍스트 모델에 대한 연구에 따르면 모델은 컨텍스트의 시작과 끝 부분의 정보를 가장 잘 활용하고 중간 부분에서는 성능이 저하되며, 일정 수준 이상으로 문서를 추가하면 이득이 매우 작습니다. 더 많은 컨텍스트는 모델이 추론할 자료를 더 많이 제공할 뿐입니다. 잘못된 파싱으로 만들어진 청크를 복구하지는 못합니다.

어떤 문서 파싱 오류가 RAG 실패를 가장 많이 유발하나요?

평면화된 테이블, 다중 열 페이지에서 뒤섞인 읽기 순서, 라벨에서 분리된 값, 손실된 섹션 계층 구조, 유출된 머리글과 바닥글, 스캔 문서의 OCR 노이즈입니다. 테이블 오류가 가장 큰 피해를 주는데, 셀과 헤더 간의 관계는 파서가 이를 포착했을 때만 존재하며, 어떤 후속 단계도 파싱 과정에서 살아남지 못한 그리드를 재구성할 수 없기 때문입니다.

RAG 문제가 파싱 문제인지 검색 문제인지 어떻게 테스트하나요?

알려진 오답에 대해 검색이 반환한 청크를 가져와 그 안에서 올바른 값을 찾아보세요. 테이블 페이지의 원시 파싱 출력을 원본과 대조하고, 두 열 페이지에서 읽기 순서를 확인하세요. 그런 다음 동일한 페이지의 정답 텍스트를 모델에 입력해 보세요. 깨끗한 텍스트로 올바르게 답하면 문제는 검색이 아닌 수집에 있는 것입니다.

ImageToTable.ai가 RAG 파이프라인을 구축하거나 실행하나요?

아닙니다. 이 제품은 추출 계층입니다. 문서를 읽고 구조화되고 라벨링된 데이터를 Excel, CSV, JSON 또는 Word로 반환합니다. 검색, 벡터 저장소 및 생성은 여러분의 몫입니다. 이 제품은 이러한 시스템에 공급되는 파싱 단계를 처리하며, 그 이상은 처리하지 않습니다.

RAG 파이프라인을 위해 추출 계층이 생성하는 출력은 무엇인가요?

문서당 한 행씩, 여러분이 지정한 열과 함께 v1 API를 통한 구조화된 JSON을 생성합니다. 값이 정의한 라벨에 연결되어 도착하므로, 다운스트림 청크 및 검색은 원시 문자 스트림이 아닌 구조화된 텍스트에서 작동합니다.

스캔된 PDF와 다중 페이지 문서를 처리할 수 있나요?

비밀번호로 보호된 PDF, JPG 및 PNG 이미지, WebP 및 AVIF 파일, 스크린샷을 지원하며 인쇄된 텍스트와 손글씨 텍스트를 인식합니다. 다중 페이지 병합은 동일한 논리 문서의 페이지를 하나의 레코드로 그룹화하여, 명세서나 계약서의 일부에서 청크가 생성되는 경우에 유용합니다. 품질이 매우 낮은 스캔에서는 정확도가 여전히 떨어지므로 해당 출력은 검토가 필요합니다.

가장 비용이 많이 드는 RAG 버그는 모델 문제처럼 보여서 프롬프트, 청크 크기, 리랭커를 조정하게 만들지만 실제 손상은 검색이 실행되기 전에 발생한 경우입니다. 먼저 파싱을 감사하세요. 파이프라인에 들어가는 텍스트가 구조화되고 올바르게 라벨링되면 모델은 마침내 신뢰할 만한 증거를 기반으로 추론하게 됩니다.