RAG 데이터 최신성 관리: 수정·삭제된 문서가 답변에 남지 않게 하려면
분명히 지웠는데 답변에는 남아 있습니다
오래된 출장 규정을 저장소에서 삭제했습니다. 담당자는 안심하고 사내 AI에게 질문합니다. 그런데 AI가 방금 지운 규정을 근거로 답합니다. 출처 링크까지 달려 있어 더 그럴듯합니다.
왜 이런 일이 생길까요?
검색 증강 생성(RAG)은 질문과 관련된 자료를 검색한 뒤 그 내용을 답변의 근거로 사용합니다. 이때 원본 문서와 검색 인덱스가 제때 맞춰지지 않으면, 이미 폐기한 정보가 계속 검색될 수 있습니다. 출처가 있다는 사실과 그 출처가 지금도 유효하다는 사실은 다릅니다.
문서를 넣는 일보다 바꾸고 지우는 일이 어렵습니다
먼저 문서마다 식별자, 버전, 원문 위치, 업무상 적용일을 관리해 보세요. 최근 업로드한 파일이 과거 규정일 수도 있고, 최신 개정본이 아직 시행 전일 수도 있습니다. 현행·예정·폐기 상태를 구분하고 누가 최종 상태를 판단할지도 정해야 합니다.
Azure AI Search 문서는 변경 감지와 삭제 처리를 별도로 설명합니다. 색인기를 초기화하고 다시 실행한다고 해서 원천에서 사라진 문서가 검색 인덱스에서도 자동으로 정리되는 것은 아닙니다. 원본을 지웠다는 사실만 보고 작업을 끝내면 안 되는 이유입니다.
등록·개정·폐기를 한 번에 시험해 보세요
테스트 문서 하나를 새로 등록하고, 내용을 바꾼 뒤, 마지막에는 폐기해 보세요. 각 단계에서 AI가 어떤 버전을 인용하는지 확인합니다. 한 문서가 여러 검색 조각으로 나뉘었다면 폐기 뒤 모든 조각이 빠졌는지도 살펴야 합니다.
원천 변경 시각과 검색 반영 시각도 기록해 보세요. 그래야 “조금 늦게 반영된다”는 표현이 실제 몇 분의 지연인지 알 수 있습니다. 답변 캐시를 사용한다면 기존 답변이 언제까지 남는지도 별도로 확인해야 합니다.
최신 근거가 없다면 모른다고 말할 수 있어야 합니다
현행본과 폐기본이 함께 검색되면 무엇을 우선할까요? 현재 적용되는 자료가 없다면 AI는 어떤 안내를 해야 할까요? 업무별로 확인 요청이나 담당 부서 연결이 필요한 조건을 미리 정해두세요. 검증 질문에도 “현재 규정”과 “특정 과거 시점의 규정”을 나눠 넣는 것이 좋습니다.
원천 시스템에서 문서 식별자와 개정 정보를 꺼내는 API 계층에는 Litis API Creator의 API 생성·데이터 변환 기능을 적용 대안으로 검토할 수 있습니다. 검색 인덱스의 삭제 정책과 답변 검증은 별도로 설계해야 합니다.
사내 AI가 더 많은 문서를 읽게 만드는 일도 중요합니다. 하지만 이제는 무엇을 더 이상 읽지 말아야 하는지 가르치는 일도 함께 시작해 보면 어떨까요?
출처 및 참고자료
RAG 개념: [Microsoft - RAG와 Azure AI Search]
초기화·재실행과 삭제의 차이: [Microsoft - 색인기 실행 및 초기화]
데이터 소스별 정책 예시: [Microsoft - Azure Storage 변경·삭제 감지]
제품 기능 범위: [Litis API Creator]
