사내 문서가 바뀌면 RAG는 어떻게 갱신해야 할까?

RAG를 운영할 때는 문서를 처음 연결하는 과정만큼 변경을 반영하는 과정이 중요합니다. 원본 파일을 수정했다고 검색 인덱스와 답변이 즉시 바뀌는 것은 아닙니다. 변경 감지, 문서 처리, 인덱스 갱신, 검색과 답변까지 이어지는 경로를 확인해야 합니다.

수정, 삭제, 파일 이동, 권한 변경은 서로 다른 사건입니다. “동기화 지원”이라는 한 항목으로 묶기보다 각각 어떤 동작을 기대하고 언제 결과를 확인할지 정하세요.

문서 수정과 삭제를 같은 기능으로 보지 마세요

수정된 문서를 감지하는 기능과 삭제된 문서를 검색에서 제외하는 기능은 별도로 구성될 수 있습니다. 예를 들어 Azure AI Search의 변경·삭제 처리에서도 삭제 감지 정책을 따로 다룹니다. 다른 시스템도 원본 삭제 이후 검색 데이터가 어떻게 정리되는지 확인할 필요가 있습니다.

Wissly-in-a-Box의 문서 처리 흐름에는 초기 파싱·청킹·임베딩과 변경 파일의 증분 인덱싱이 포함됩니다. 실제 연결 환경에서의 변경 감지 방식, 갱신 조건, 삭제와 권한 변경 처리는 도입할 구성에 맞춰 협의하고 시험하세요.

변경 종류별로 기대 결과를 적으세요

변경	기대하는 결과	확인할 위치
본문 수정	바뀐 내용으로 답변	답변, 인용 구절, 원문
새 버전 추가	적용 기준에 맞는 버전 선택	문서 제목, 버전, 답변
원본 삭제	삭제된 내용이 새 검색에 남지 않음	검색 결과, 답변, 인용
이름·경로 변경	원문 링크가 새 위치와 연결	검색 결과와 원문 열기
권한 회수	해당 계정에 정보가 노출되지 않음	제목, 요약, 답변, 이력
연결 중단	처리 실패가 담당자에게 드러남	수집 상태와 오류 기록

이 표는 운영 요구사항을 정하는 예시입니다. 조직에서 허용할 갱신 지연과 이력 보관 조건도 함께 기록하세요.

한 번에 하나의 변경만 시험하세요

예시로 테스트용 사양 문서에 “점검 담당: A팀”이라는 항목을 넣습니다. 처음 연결한 후 담당팀을 질문하고 답변과 원문 위치를 기록합니다.

다음에는 담당팀을 B팀으로 바꾸고 수집 상태를 확인합니다. 새 질문에서 변경된 팀이 표시되는지, 인용 문구도 같은 내용을 가리키는지 확인하세요. 수정 시각과 검색 반영 시각을 따로 기록하면 갱신에 걸린 과정을 볼 수 있습니다.

이후 이름 변경, 삭제, 복원, 권한 회수를 각각 실행합니다. 여러 조건을 동시에 바꾸면 실패했을 때 어느 변경이 원인인지 알기 어렵습니다.

이전 대화와 새 검색을 구분하세요

새 검색에서 삭제된 문서가 나오지 않는 것과 과거 대화에 남은 답변이 사라지는 것은 다른 동작입니다. 대화 이력, 검색 캐시, 다운로드된 결과물, 백업은 각각의 보관·삭제 조건을 가질 수 있습니다.

사용자에게 문서를 삭제하면 어디까지 영향을 주는지 안내할 수 있어야 합니다. 특히 권한을 회수한 사용자의 이전 대화 접근과 원문 열기까지 확인하세요. “원본 파일 삭제”를 모든 파생 데이터의 즉시 삭제로 해석하지 않도록 운영 절차를 구체적으로 정합니다.

갱신 실패를 다시 처리할 담당자를 정하세요

운영 체크에는 실패한 문서, 마지막 정상 처리 시각, 재처리 담당자, 사용자가 질문할 창구가 필요합니다. 연결 계정의 권한이 바뀌거나 파일이 손상됐을 때도 대응할 수 있어야 합니다.

모델이나 문서 처리 방식을 바꿀 때는 대표 문서로 기존 질문을 다시 실행합니다. RAG PoC 평가표를 재사용하면 초기 평가와 업데이트 후 결과를 비교할 수 있습니다.

도입 전에 NAS 연결 준비에서 폴더와 대표 파일을 정리하고, 운영 조건은 보안 검토표에 연결하세요. 문서 갱신은 검색 기능 하나가 아니라 문서 관리와 운영 책임을 함께 정하는 과정입니다.