auditRag: RAG 응답의 청크 수준 출처 보존과 충실도 검사 도구

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 LangChain 기반 RAG 파이프라인에서 데이터가 흐르는 동안 청크 수준 출처가 손실되는 문제를 해결하기 위해 auditRag를 공개하고 실무 규칙을 제시했다. 핵심 방법은 인제스션 시점에 불변의 청크 ID를 결정하고 모델에는 간단한 정수 라벨만 노출시키며, 벡터스토어는 인덱스로 취급하고 원문 텍스트는 별도 DB에 보관하는 아키텍처이다. 생성된 주장마다 인용된 청크 텍스트와 문자적으로 대조하여 supported/partial/unsupported/uncited로 판정하는 충실도 검증을 추가하고 페이지 경계를 유지하면 감사 가능한 증거와 정확한 페이지 인용을 확보할 수 있다. 이 접근은 검색 품질과의 작은 트레이드오프를 수반하지만 출처 검증이 중요한 감사용 애플리케이션에서 실질적 이점을 제공한다.

실용적 조언

청크 ID는 도큐먼트 해시와 페이지·인덱스 조합으로 단번에 결정하고 파이프라인 전반에서 불변으로 유지해야 한다는 점이 실무상 유효하다. 이 방식은 색인과 리트리벌 이후에도 응답의 인용을 원문 청크에 정확히 연결할 수 있게 하며, ID 재발급으로 인한 출처 소실을 예방한다. 데이터 인제스션 단계에서 ID를 생성하는 절차를 표준화하면 추후 감사 로그와 리포트 생성도 단순해진다.
LLM에 노출되는 식별자는 작은 정수 라벨로 대체하고 해당 라벨과 실제 청크 ID의 매핑은 요청 컨텍스트에만 유지하는 방법은 환각된 인용을 자동으로 탐지하는 수단을 제공한다. 모델이 존재하지 않는 라벨을 인용하면 그 즉시 환각으로 표시되어 추가 검증을 트리거할 수 있다. 이 설계는 실제 ID 유출을 방지하면서 응답 검증을 자동화하는 구조를 만든다.
벡터스토어는 임베딩 검색을 위한 인덱스로만 사용하고, 원문 텍스트의 단일 신뢰 소스를 별도 데이터베이스로 유지하는 운영 패턴이 권장된다. 작성자는 SQLite를 예시로 들며 간단한 쿼리로 청크 원문을 회수하여 검증과 리포트를 만들 수 있음을 보였다. 벡터스토어 내부 포맷이나 구현 세부에 의존하지 않도록 설계해야 장기적으로 감사 가능성이 높아진다.

섹션별 상세

생산 환경에서 RAG 응답의 주요 문제는 검색 품질 자체보다 데이터가 파이프라인을 통과하면서 출처 식별자가 소실되는 일이었다. 입력 문서가 청크로 분할되어도 파이프라인 중간에 ID가 재생성되면 최종적으로 사용자에게 전달되는 인용은 문서 수준의 넓은 링크로 희석된다. 작성자는 이 문제를 반복 관찰한 경험을 근거로 청크 수준의 불변 식별자가 필요하다고 결론지었다.

작성자는 청크 ID를 도큐먼트 해시, 페이지, 청크 인덱스를 조합한 형식으로 단일 시점에 결정하여 도입 단계에서만 생성하고 이후에는 변경하지 않는 방식을 권장했다. 이 방식은 입력 단계에서 고유 키를 고정함으로써 추후 검색, 색인, 리트리벌 결과와 LLM 응답 사이의 직접적인 매핑을 가능하게 한다. 작성자는 대부분의 출처 소실이 중간 단계에서 ID가 재키되거나 재발급될 때 발생한다고 지적했다.

LLM이 실제 식별자를 직접 보지 못하게 하고 작은 정수 라벨로 대체한 뒤 요청 범위에만 라벨→ID 매핑을 유지하는 아키텍처가 제안되었다. 이 방법은 모델에 노출되는 식별값을 단순화하여 모델이 반환한 라벨을 즉시 검증할 수 있게 하며, 예컨대 제공된 청크가 5개뿐인데 모델이 [7]을 인용하면 즉시 환각된 인용으로 판별된다. 라벨 매핑을 요청 범위에서 관리하면 리턴된 인용을 재연결하여 자동화된 오류 검출을 수행할 수 있다.

벡터 저장소는 임베딩 기반의 색인 역할을 하는 것일 뿐 실제 텍스트의 신뢰할 수 있는 저장소로 삼아서는 안 된다는 점이 강조되었다. 작성자는 실제 청크 텍스트를 SQLite 같은 단순하고 신뢰 가능한 원본 저장소에 보관하여 검증과 증거 리포트 생성이 벡터스토어 내부 구현에 의존하지 않도록 설계했다. 이 분리는 검증 단계에서 텍스트를 일관되게 조회하고 감사 가능한 증거를 출력하는 데 필수적이라고 설명되었다.

생성물의 주장마다 인용된 청크의 원문과 대조하는 충실도 검증 단계를 추가하여 각 주장에 대해 'supported', 'partial', 'unsupported', 'uncited' 네 가지 판정을 부여하는 절차가 제안되었다. 이 검증은 LLM이 반환한 주장을 그대로 신뢰하는 대신 인용된 텍스트와의 문자적 대조를 통해 근거 수준을 명시적으로 표기한다. 작성자는 LLM으로 LLM을 판정하는 한계가 존재하더라도 잘못된 주장을 표기하는 것이 아무 표기도 없이 넘어가는 것보다 더 안전하다고 결론지었다.

페이지 경계를 준수하는 청킹 정책이 인용의 유용성을 높인다는 관찰이 제시되었다. 청크가 페이지를 넘어가지 않으면 각 주장은 정확한 페이지 번호를 한정된 근거로 갖게 되어 감사와 검증이 쉬워지지만, 이로 인해 검색 품질이 약간 저하되는 트레이드오프가 발생한다. 작성자는 감사용 애플리케이션에서는 검색 품질의 소폭 저하를 감수하고서라도 페이지 경계 준수를 선택하는 것이 전체 시스템 목적에 부합한다고 보고 있다.

용어 해설

문서 청킹(Chunking): — 문서를 일정 크기 단위로 분할하여 임베딩과 검색 단위로 사용하는 방법으로, 입력 텍스트를 페이지·문단·토큰 기준으로 쪼개어 검색 정확도와 출처 매핑을 관리하는 데 중요하다. 이 글에서는 청크가 불변의 식별자와 함께 유지되어야 출처 증명이 보존된다고 보고 있다. 청킹 전략은 페이지 경계 유지 여부와 근거 검증 능력에 직접적인 영향을 준다.
벡터 저장소(Vector store): — 임베딩된 텍스트 벡터를 저장하고 유사도 검색을 수행하는 색인 역할의 시스템으로, 실제 원문 텍스트를 대신 보관하는 진실의 단일 소스가 될 수 없다고 본문에서 지적했다. 글에서는 벡터 저장소를 단순한 인덱스로 취급하고 원문 텍스트는 별도 DB에서 관리해야 한다고 권장했다. 벡터 검색 결과는 참조 포인터로 사용하고 검증과 리포팅은 원문 데이터베이스에 의존해야 한다.
출처 증명(Provenance): — 생성된 주장이나 응답이 어떤 원문 청크와 어떤 위치에 근거하는지를 추적하는 체계로, 파이프라인을 통과하면서 식별자가 재생성되면 출처 정보가 소실되는 문제가 발생한다. 글은 식별자 불변성, 라벨 매핑, 원문 저장소 분리를 통해 청크 수준의 출처 증명을 보장해야 한다고 기술했다. 출처 증명은 감사용 리포트와 충실도 판정의 근거가 된다.
충실도 검사(Faithfulness Check): — 생성 모델의 각 주장에 대해 인용된 원문 청크의 텍스트와 대조하여 '지원됨/부분지원/미지원/무인용' 식으로 판정하는 단계로, LLM이 다른 LLM을 평가하는 문제점이 존재해도 오탐을 표시하는 것이 무표시보다 유리하다고 결론지었다. 글은 판정 결과를 근거로 감사 가능한 리포트를 생성할 것을 권장했다. 충실도 검사는 자동화된 검증 파이프라인의 핵심 구성요소이다.

언급된 도구

LangChain중립

RAG 워크플로 구성과 문서 관리에 사용되는 프레임워크

Elasticsearch중립

검색 인덱싱과 리트리벌용 백엔드로 사용된 사례

SQLite추천

청크 원문을 신뢰 가능한 원천으로 저장하기 위해 사용된 경량 DB

Vector store중립

임베딩 기반 색인과 유사도 검색을 수행하는 인덱스 역할

언급된 리소스

GitHubauditRag GitHub