RAG 파이프라인에도 '출처 추적'이 필요한 이유
시스템을 만들 때 다들 검색 품질, 즉 청킹(, 문서를 잘게 나누는 방식)이나 임베딩, 재순위화(), 프롬프트를 개선하는 데만 집중한다. 하지만 그만큼 중요한 것이 출처 추적()이다. 실제 서비스에서는 그럴듯한 답변을 내놓는 것만으로는 부족하다. 그 답이 어느 문서에서 나왔는지, 어떤 청크가 검색됐는지, 그 청크가 수정된 적은 없는지, 답변이 실제로 검색된 근거에 기반했는지를 알 수 있어야 한다.
출처 추적이 없으면 디버깅이 매우 어려워진다. 답이 틀렸을 때 원인이 OCR(광학 문자 인식)인지, 청킹인지, 메타데이터인지, 검색인지, 재순위화인지, 생성 단계인지, 아니면 오래된 원본 데이터 때문인지 알기 어렵다. 답이 맞았더라도 왜 믿을 만한지 설명하기 힘들다. 출처 추적은 원본 문서, 파서 출력, 청크 경계, 메타데이터, 생성된 QA 쌍, 필터링 결정, 평가 점수, 최종 색인 데이터에 이르기까지 전체에 걸쳐 존재해야 한다.
특히 문서에 버전, 권한, 작성자, 타임스탬프, 상충하는 정책, 컴플라이언스 요구사항이 얽혀 있는 기업용 RAG에서는 더더욱 중요하다. 잘 만든 이라면 모든 답변을 그 답을 만들어낸 데이터 변환 과정까지 거슬러 추적할 수 있어야 한다.
핵심 포인트
- RAG는 검색 품질(청킹·임베딩·재순위화)뿐 아니라 출처 추적도 중요하다
- 출처 추적이 없으면 답이 틀렸을 때 원인(OCR·청킹·메타데이터·검색·생성 등)을 특정하기 어렵다
- 출처 추적은 원본 문서부터 최종 색인 데이터까지 파이프라인 전 단계에 걸쳐 있어야 한다
- 기업용 RAG는 문서 버전·권한·컴플라이언스 요구사항 때문에 출처 추적이 특히 중요하다