3.4.1.2 RAG 시스템을 위한 문서 청크(Chunk) 매핑 전략

RAG(Retrieval-Augmented Generation) 파이프라인에서 ’사실 기반 정답지(Fact-based Ground Truth)’를 구축할 때 겪는 가장 큰 기술적 난관은 지식 베이스의 단편화(Fragmentation)다. 방대한 엔터프라이즈 문서는 벡터 데이터베이스(Vector DB)에 인제스천(Ingestion)되기 전, 임베딩 모델의 컨텍스트 길이에 맞추어 수백 개의 청크(Chunk)로 쪼개진다.

이때 오라클(Oracle)이 검증해야 할 ’사실(Fact)’은 파편화된 청크 들 어딘가에 흩어지게 되며, 이를 추적하고 정답지와 연결하는 정교한 매핑(Mapping) 전략이 결정론적 검증의 핵심이 된다.

1. 다중 청크 식별자(Multi-Chunk ID) 매핑

하나의 원본 문서가 여러 청크로 분할되었을 때, 사용자의 질의에 대한 정답(사실)이 특정 단일 청크에만 존재하리라는 보장은 없다. 예를 들어, “2024년 프로젝트 A의 예산안“에 대한 사실이 Chunk-105(개요)와 Chunk-108(상세 예산표)에 걸쳐 존재할 수 있다.

전략: 정답지 스키마는 단일 문서 ID가 아닌, 정답을 구성하는 데 필요한 ’필수 청크 ID 배열’을 매핑해야 한다.
오라클의 검증: 오라클은 RAG 시스템의 검색기(Retriever)가 반환한 Top-K 청크 리스트를 가로채어, 정답지에 명시된 필수 청크 ID들이 모두 포함되었는지(Recall 100%) 수학적 부분집합(Subset) 연산으로 검증한다. 단 하나의 필수 청크라도 누락되었다면, 이후 LLM이 우연히 올바른 대답을 생성했다 하더라도 이는 파라메트릭 환각(Parametric Hallucination)으로 간주하여 Fail 처리한다.

2. 청크 해시(Hash) 기반의 버전 관리

엔터프라이즈 환경에서 지식 문서는 끊임없이 수정된다. 문서의 특정 문단만 변경되어 벡터 DB가 업데이트되었을 때, 기존 구축해 둔 사실 기반 정답지가 여전히 유효한지 어떻게 확신할 수 있는가?

전략: 정답지에는 문서 ID와 함께, 해당 정답을 추출했던 당시 원본 청크의 ’데이터 해시값(예: SHA-256)’을 메타데이터로 함께 기록한다.
연쇄적 검증 파이프라인:

오라클이 작동하기 전, 정답지에 기록된 해시값과 현재 벡터 DB에 적재된 타겟 청크의 해시값을 비교한다.
해시값이 일치하면 정상적으로 오라클 검증을 수행한다.
해시값이 불일치(문서가 수정됨)한다면, 오라클은 해당 테스트 케이스를 STALE(만료됨) 상태로 격리하고 CI/CD 파이프라인에서 일시적으로 제외시켜 거짓 음성(False Negative)을 방어해야 한다.

3. 답변의 출처 지시자(Citation Marker) 런타임 제약

RAG 시스템에서 사실을 정확히 전달하는 것만큼 중요한 것은, “어느 문서에서 그 사실을 가져왔는가“에 대한 출처(Citation)의 투명성이다.

전략: 프롬프트 엔지니어링을 통해 LLM이 답변을 생성할 때 참조한 청크의 ID를 본문에 마커(Marker) 형태로 강제 삽입하도록 지시한다. (예: 주 52시간 근무제는 2021년부터 전면 시행되었습니다. [Chunk-HR-04])
오라클 적용: 오라클은 정규표현식을 통해 생성된 텍스트에서 출처 마커([Chunk-HR-04])를 추출하고, 이 마커가 정답지에 매핑된 청크 ID와 일치하는지, 그리고 실제 검색기가 해당 청크를 LLM에게 제공했는지 3자 교차 검증(Tripartite Cross-Validation)을 수행한다.

청크 매핑 전략을 통제하지 못하는 RAG 오라클은 사상누각에 불과하다. 결정론적 정답지는 단순히 ’무엇’을 대답해야 하는지가 아니라, 데이터를 조각낸 벡터 공간(Vector Space)의 ’어디’에서 그 사실을 증명할 수 있는지를 정확한 좌표로 가리키고 있어야 한다.