RAG의 품질은 최신 문서를 얼마나 빨리 반영하느냐에 크게 좌우됩니다. 오래된 문서가 검색되면 답변은 그럴듯해도 실제로는 틀릴 수 있습니다.
이 글은 데이터 신선도를 운영 지표로 보고, ingestion부터 index 갱신까지 무엇을 설계해야 하는지 설명합니다.
개요 #
데이터 신선도는 단순한 “최신성"이 아닙니다. 문서 수집 시점, 전처리 시점, 인덱싱 시점, 검색 가능 시점이 모두 연결된 개념입니다.
운영에서는 다음 질문에 답할 수 있어야 합니다.
- 최신 문서는 얼마나 빨리 들어오는가
- 들어온 문서가 얼마 만에 검색 가능한가
- 오래된 문서가 얼마나 빨리 교체되는가
- stale document를 어떻게 식별하는가
왜 중요한가 #
데이터 신선도가 낮으면 RAG는 내부 문서를 가진 검색 엔진이 아니라 오래된 캐시처럼 동작합니다.
- 정책 문서가 바뀌었는데 예전 버전이 검색된다
- 제품 스펙이 바뀌었는데 옛값이 답변에 섞인다
- FAQ가 업데이트됐는데 검색 결과가 늦게 반영된다
- 운영팀은 최신 문서를 넣었는데 사용자에게는 예전 답변이 나온다
이 문제는 RAG Ops에서 가장 먼저 잡아야 합니다.
운영 포인트 #
데이터 신선도는 보통 네 단계로 관리합니다.
- Source freshness: 원본이 언제 바뀌었는가
- Ingestion freshness: 변경을 언제 감지했는가
- Index freshness: 벡터 인덱스에 언제 반영됐는가
- Retrieval freshness: 사용자 query에서 최신 문서가 실제로 선택되는가
신선도 설계는 Qdrant Cloud처럼 관리형 인프라를 써도 필요하고, Hybrid Search를 써도 필요합니다. 최신성만으로 품질이 보장되지는 않기 때문에 Retrieval Quality Metrics도 같이 봐야 합니다.
아키텍처 도식 #
구성은 보통 이렇게 나눕니다.
- 원본 소스 감지
- 변경분 추출
- 전처리와 chunking
- incremental indexing
- freshness metadata 기록
- stale 문서 제거
문서가 바뀔 때 전체 재색인만 고집하면 비용이 커집니다. 변경분만 빠르게 반영하는 흐름을 먼저 설계하는 편이 좋습니다.
체크리스트 #
- 문서별 last updated 메타데이터가 있는가
- 변경 감지 주기가 명확한가
- incremental indexing이 가능한가
- stale 문서를 검색에서 제외할 수 있는가
- 최신성과 정확성 둘 다 측정하는가
- 사용자 query에서 최신 문서가 우선되는가
- 운영자에게 freshness lag가 보이는가
결론 #
RAG 데이터 신선도는 검색 품질의 전제조건입니다. 최신 문서가 빨리 들어오지 않으면 evaluation을 아무리 돌려도 실서비스 품질은 떨어집니다.
최소한 source, ingestion, index, retrieval 네 단계의 지연을 분리해서 보아야 합니다.