문서 버전 관리는 어떻게 RAG 답변이 최신 파일을 기반으로 하도록 유지하나요?

문서 버전 관리는 색인된 모든 청크를 안정적인 문서 식별자 및 명시적인 개정 상태와 연결하여 RAG 답변을 최신 상태로 유지합니다.

가정용 지식 베이스에는 오래된 임대 계약서, 개정된 보험 약관, 업데이트된 라우터 안내서, 수정된 프로젝트 계획, 보관된 가정 절차서가 동시에 저장될 수 있습니다. 의미적 유사성만으로는 현재 어떤 문서가 기준이 되는지 판단할 수 없습니다. 이전 개정본도 새 파일만큼 질의와 잘 일치할 수 있기 때문입니다. 버전 관리는 검색 결과를 답변 모델에 전달하기 전에 검색 과정에서 적용할 수 있는 수명 주기 정보를 추가합니다.

안정적인 문서 식별자는 파일 이름 변경과 개정 이후에도 유지되어야 합니다

첫 번째 요구 사항은 “이 문서는 무엇인가?”와 “이 문서의 어떤 개정본인가?”를 분리하는 것입니다. 사용자는 파일을 이름 변경, 이동, 복사, 교체할 수 있으므로 경로나 파일 이름만으로는 불안정합니다.

안정적인 포인트 식별자와 페이로드에는 상위 문서 ID, 개정 ID, 청크 위치, 현재 상태 필드를 저장할 수 있으므로 파일 경로 자체를 유일한 식별 키로 사용하지 않아도 됩니다.

파일이 편집되면 파이프라인은 해당 파일을 서로 무관한 새 소스로 처리하는 대신, 동일한 문서 계열 아래에서 새 개정본을 생성하거나 식별해야 합니다.

이 식별 계층은 복사된 보관 파일의 경로명이 바뀌었다는 이유만으로 해당 파일이 두 번째 “현재” 문서가 되는 문제도 방지합니다.

개정 메타데이터는 검색에 현재 상태 필터를 제공합니다

각 청크에는 개정 번호, 콘텐츠 해시, 수집 시간, 적용일, 소스 경로, 상위 문서 ID, active(활성), superseded(대체됨), draft(초안), archived(보관됨)와 같은 상태 정보가 포함될 수 있습니다.

소스 최신성과 대체 상태를 추적하는 것은 중요합니다. 새 개정본이 기준 문서가 된 이후에도 이전 문장은 현재 상태에 관한 질의와 매우 유사할 수 있기 때문입니다.

현재 상태에 관한 질의는 벡터 유사도를 계산하기 전이나 최종 후보를 승인하기 전에 활성 개정본으로 필터링할 수 있습니다. 과거 기록에 관한 질의라면 요청된 날짜나 개정본까지 의도적으로 필터 범위를 넓힐 수 있습니다.

새 청크는 하나의 일관된 개정본으로 함께 활성화되어야 합니다

대용량 파일은 일반적으로 여러 청크로 분할되므로 업데이트 시 벡터 하나가 아니라 여러 레코드로 구성된 계열이 생성됩니다. 이러한 청크를 하나씩 게시하면 일부 문장은 새 버전이고 다른 문장은 이전 버전인 혼합 상태가 노출될 수 있습니다.

점진적 임베딩 업데이트는 변경되지 않은 레코드를 유지하면서 변경된 소스 콘텐츠에 연결된 파생 청크를 교체하거나 제거할 수 있습니다. 이를 통해 개정본 전환 범위를 하나의 문서 계열로 제한할 수 있습니다.

더 안전한 버전 전환 방식은 새 계열을 생성하고, 예상 청크와 메타데이터를 검증한 다음, 수집이 성공한 후에만 활성 개정본을 전환하는 것입니다.

OCR, 청킹, 임베딩 또는 벡터 삽입 처리 중간에 오류가 발생하면 이전의 완전한 개정본을 활성 상태로 유지하여 혼합 문서가 노출되는 것을 방지할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

대체된 청크는 기본 검색에서 제외하되 반드시 삭제할 필요는 없습니다

기록을 보존하면 감사, 변경 사항 비교, 작년에 정책이 어떻게 명시되어 있었는지에 관한 질문에 유용합니다. 문제는 오래된 청크의 존재가 아니라, 오래된 청크가 현재 근거와 동등하게 경쟁하도록 허용하는 것입니다.

소스를 인식하는 RAG 레코드는 벡터를 문서 수준의 메타데이터와 연결하여 원본 소스와의 관계를 잃지 않고 개정본을 관리할 수 있게 합니다.

대체된 개정본은 보관용 필터를 적용했을 때 검색 가능하도록 유지하면서 일반적인 현재 상태 질의에서는 제외할 수 있습니다. 이렇게 분리하면 추적 가능성을 유지하면서도 답변 모델이 거의 동일한 여러 문장 중 어느 것을 신뢰해야 할지 판단하도록 강요하지 않을 수 있습니다.

인용에는 검색에 사용된 것과 동일한 버전 식별자가 필요합니다

검색에서 현재 청크를 선택했더라도 인용 표시가 파일 이름, 경로 또는 문서 계열만으로 링크를 재구성한다면 버전 관리는 완전하지 않습니다.

검색에서 현재 청크를 찾았더라도 인용 계층이 파일 이름이나 경로만큼 취약한 식별자로 참조를 재구성하면 인용 메타데이터가 검색 상태와 어긋날 수 있습니다.

인용 레코드에는 개정 ID, 소스 경로 또는 변경 불가능한 객체 참조, 페이지 또는 청크 위치, 검색 중 사용한 것과 동일한 활성/과거 상태를 저장해야 합니다.

이를 통해 사용자는 답변을 뒷받침한 정확한 개정본을 확인할 수 있으며, 인용된 근거와 내용이 더 이상 일치하지 않는 최신 파일을 열게 되는 일을 피할 수 있습니다.

버전 관리는 신뢰할 수 있는 변경 감지에 달려 있습니다

수집 파이프라인이 소스 변경을 감지하지 못하거나, 업데이트 실패 후에도 이전 레코드를 무기한 활성 상태로 유지한다면 버전 인식 스키마는 도움이 되지 않습니다.

신뢰할 수 있는 수집 일관성은 버전 인식 검색의 전제 조건입니다. 완전하고 정확하게 수집되지 않은 개정본은 색인에서 선택할 수 없기 때문입니다.

파일 감시자, 예약된 조정 작업, 콘텐츠 해시, 데이터베이스 변경 스트림, 명시적 업로드 이벤트는 모두 버전 수명 주기에 정보를 제공할 수 있습니다. 그러면 버전 관리 계층이 어떤 개정본을 현재 버전으로 설정할지 결정합니다.

현재 상태에 관한 답변이 계속 신뢰성을 유지하려면 변경 감지, 수집, 활성화, 검색, 인용이 모두 동일한 문서 식별자와 개정 계약을 사용해야 합니다.

FAQ

파일 수정 시간만으로 RAG 버전을 정의할 수 있나요?

아니요. 복사 또는 복원 작업 중에도 타임스탬프가 변경될 수 있으며, 어떤 콘텐츠나 청크 계열이 기준이 되었는지 식별하지 못합니다. 안정적인 문서 ID와 명시적인 개정 메타데이터를 함께 사용하는 편이 안전합니다.

이전 문서 버전은 벡터 데이터베이스에서 삭제해야 하나요?

반드시 그럴 필요는 없습니다. 기본 검색에서 이전 버전을 제외하고 인용에 해당 버전의 식별자를 명확히 보존한다면, 기록이나 감사 목적으로 계속 사용할 수 있습니다.

업데이트가 전혀 감지되지 않을 때도 버전 관리로 오래된 답변을 방지할 수 있나요?

아니요. 버전 관리는 알려진 개정본을 관리합니다. 감지하지 못한 편집, 삭제 또는 수집 작업 실패를 발견하려면 별도의 변경 감지 및 조정 경로가 여전히 필요합니다.