Embedding Refresh Strategy는 문서가 바뀌었을 때 벡터를 다시 만들고, 언제 다시 만들지 결정하는 운영 규칙입니다. 이 규칙이 없으면 검색 품질은 서서히 망가지고, 비용은 조용히 커집니다.
이 글에서는 전체 재임베딩과 증분 갱신을 언제 선택해야 하는지, 그리고 RAG 데이터 신선도, RAG 인덱싱 파이프라인, 임베딩 모델 선택, 벡터 저장 비용, RAG Ops와 어떻게 연결되는지 정리합니다.
개요 #
임베딩은 한 번 만들고 끝나는 자산이 아닙니다. 소스 문서가 바뀌고, 모델이 바뀌고, 청킹 방식이 바뀌면 벡터도 다시 맞춰야 합니다.
그래서 실무에서는 refresh strategy를 별도로 설계합니다. 문서 수정 이벤트, 스케줄, 모델 교체, 검색 품질 저하 같은 트리거를 기준으로 어떤 범위까지 다시 임베딩할지 정합니다.
왜 중요한가 #
- 문서가 수정됐는데 오래된 벡터가 남아 있으면 답변이 틀어집니다.
- 모델을 바꿨는데 일부 문서만 갱신하면 결과가 섞입니다.
- 무조건 전체 재임베딩을 돌리면 비용이 커집니다.
- refresh 타이밍이 불명확하면 운영자가 수동으로 개입하게 됩니다.
이 문제는 RAG 데이터 신선도와 거의 같은 문제입니다. 신선도를 유지하려면 refresh 전략이 필요합니다.
파이프라인 설계 #
기본 설계는 아래 순서가 좋습니다.
- 문서 변경 이벤트를 감지합니다.
- 변경 범위를 계산합니다.
- 전체 재임베딩인지 증분 갱신인지 선택합니다.
- 새 임베딩 버전을 생성합니다.
- 벡터 DB에 upsert합니다.
- 품질 검증 후 구 버전을 정리합니다.
선택 기준 #
- 문서 구조가 그대로이고 내용만 조금 바뀌면 증분 갱신이 유리합니다.
- 청킹 규칙이나 임베딩 모델이 바뀌면 전체 재임베딩이 안전합니다.
- 검색 품질이 급락했으면 부분 백필을 먼저 검토합니다.
- 데이터셋이 작고 운영 부담이 적으면 전체 재색인이 단순합니다.
이 판단은 벡터 저장 비용과 같이 봐야 합니다. refresh 빈도가 올라가면 저장 비용보다 연산 비용이 더 커질 수 있습니다.
아키텍처 도식 #
권장 아키텍처는 다음과 같습니다.
- Change detector가 문서 변경을 감지합니다.
- Refresh queue가 작업을 분산합니다.
- Embedding worker가 모델 버전을 명시해 재생성합니다.
- Vector DB가 새 버전을 저장합니다.
- Eval job이 샘플 쿼리로 품질을 확인합니다.
- Cleanup job이 오래된 버전을 정리합니다.
이 흐름은 단순 배치가 아니라 운영 파이프라인입니다. RAG Ops와 같이 보면 refresh 실패와 검색 실패를 함께 추적할 수 있습니다.
체크리스트 #
- 문서 변경 트리거가 정의되어 있는가
- full refresh와 incremental refresh의 기준이 있는가
- 임베딩 버전이 문서 버전과 같이 저장되는가
- refresh 실패 시 재시도 경로가 있는가
- 품질 저하를 감지하는 샘플 쿼리가 있는가
- 오래된 벡터를 정리하는 정책이 있는가
- refresh 비용과 latency를 모니터링하는가
결론 #
Embedding Refresh Strategy는 검색 품질을 유지하는 유지보수 규칙입니다. 한 번 만든 벡터를 영구 자산처럼 대하면 RAG는 금방 오래됩니다. 변경 감지, 증분 갱신, 전체 재임베딩 기준을 분리해 두는 것이 가장 실용적입니다.