In che modo il controllo delle versioni dei documenti mantiene le risposte RAG legate ai file attuali?

Il controllo delle versioni dei documenti mantiene aggiornate le risposte RAG collegando ogni segmento indicizzato a un’identità documentale stabile e a uno stato di revisione esplicito.

Una knowledge base domestica può conservare contemporaneamente un vecchio contratto di locazione, una polizza assicurativa revisionata, una guida aggiornata del router, un piano di progetto modificato e una procedura domestica archiviata. La sola somiglianza semantica non può stabilire quale documento sia oggi autorevole, perché una revisione precedente potrebbe corrispondere alla query altrettanto bene del file nuovo. Il controllo delle versioni aggiunge informazioni sul ciclo di vita che il sistema di recupero può applicare prima che il modello di risposta visualizzi le prove.

Un’identità documentale stabile deve sopravvivere a rinomini e revisioni dei file

Il primo requisito consiste nel separare “quale documento è?” da “quale revisione di quel documento è?”. Un percorso o un nome file da soli sono fragili, perché gli utenti rinominano, spostano, copiano e sostituiscono i file.

Gli identificatori e i payload stabili dei point possono contenere l’ID del documento principale, l’ID della revisione, la posizione del segmento e i campi relativi allo stato corrente, senza rendere il percorso del file l’unica chiave identificativa.

Quando un file viene modificato, la pipeline dovrebbe creare o riconoscere una nuova revisione all’interno della stessa famiglia documentale, invece di trattarlo come una fonte non correlata.

Questo livello di identità impedisce inoltre che un file d’archivio copiato diventi silenziosamente un secondo documento “corrente” solo perché il suo percorso è cambiato.

I metadati della revisione forniscono un filtro sullo stato corrente per il recupero

Ogni segmento può ereditare metadati come numero di revisione, hash del contenuto, ora di acquisizione, data di entrata in vigore, percorso della fonte, ID del documento principale e uno stato come attivo, sostituito, bozza o archiviato.

Il monitoraggio della freschezza e della sostituzione delle fonti è importante, perché un passaggio precedente può rimanere molto simile a una query sullo stato corrente anche dopo che una revisione più recente è diventata autorevole.

Una query sullo stato corrente può filtrare la revisione attiva prima del calcolo della somiglianza vettoriale o prima dell’accettazione dei candidati finali. Una query storica può ampliare intenzionalmente questo filtro a una data o a una revisione specifica.

I nuovi segmenti devono diventare attivi come un’unica revisione coerente

I file di grandi dimensioni vengono solitamente suddivisi in molti segmenti, quindi un aggiornamento crea una famiglia di record anziché un solo vettore. Pubblicare questi segmenti uno alla volta può esporre uno stato misto in cui alcuni passaggi sono nuovi e altri vecchi.

Gli aggiornamenti incrementali degli embedding possono conservare i record invariati sostituendo o rimuovendo i segmenti derivati associati ai contenuti modificati della fonte e mantenendo la transizione di revisione circoscritta a una sola famiglia documentale.

Una transizione di versione più sicura crea la nuova famiglia, verifica i segmenti e i metadati previsti, quindi attiva la nuova revisione solo dopo il completamento dell’acquisizione.

Se l’elaborazione si interrompe durante l’OCR, la suddivisione, la creazione degli embedding o l’inserimento dei vettori, la revisione completa precedente può rimanere attiva invece di esporre un documento ibrido.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

I segmenti sostituiti dovrebbero essere esclusi dal recupero predefinito, non necessariamente eliminati

Conservare la cronologia è utile per gli audit, il confronto delle modifiche e le domande su ciò che una policy stabiliva l’anno scorso. Il problema non è l’esistenza dei vecchi segmenti, ma consentire loro di competere alla pari con le prove correnti.

I record RAG consapevoli della fonte mantengono i vettori associati ai metadati a livello documentale, così le revisioni possono essere gestite senza perdere il legame con la fonte originale.

Una revisione sostituita può rimanere interrogabile tramite un filtro d’archivio, pur venendo esclusa dalle normali domande sullo stato corrente. Questa separazione preserva la tracciabilità senza costringere il modello di risposta a decidere quale di diversi passaggi quasi identici debba essere considerato attendibile.

Le citazioni devono usare la stessa identità di versione impiegata dal recupero

Il controllo delle versioni è incompleto quando il recupero seleziona il segmento corrente, ma la visualizzazione della citazione ricostruisce un collegamento usando solo il nome file, il percorso o la famiglia documentale.

Anche quando il recupero trova un segmento corrente, i metadati della citazione possono non riflettere lo stato del recupero se il livello delle citazioni ricostruisce i riferimenti usando identificatori meno affidabili, come il solo nome file o percorso.

Il record della citazione dovrebbe contenere l’ID della revisione, il percorso della fonte o un riferimento immutabile all’oggetto, la pagina o la posizione del segmento e lo stesso stato attivo/storico utilizzato durante la ricerca.

In questo modo l’utente può verificare la revisione esatta che ha supportato la risposta, invece di aprire un file più recente il cui testo non corrisponde più alle prove citate.

Il controllo delle versioni dipende comunque da un rilevamento affidabile delle modifiche

Uno schema consapevole delle versioni non può essere utile se la pipeline di acquisizione non rileva mai la modifica di una fonte o se un aggiornamento non riuscito lascia indefinitamente attivi i vecchi record.

La coerenza affidabile dell’acquisizione è un prerequisito per il recupero consapevole delle versioni, perché l’indice non può selezionare una revisione che non è mai stata acquisita completamente o correttamente.

I monitor dei file, le riconciliazioni pianificate, gli hash dei contenuti, i flussi di modifica del database e gli eventi espliciti di caricamento possono alimentare il ciclo di vita delle versioni. Il livello di controllo delle versioni decide quindi quale revisione diventa corrente.

Le risposte correnti rimangono affidabili solo quando rilevamento, acquisizione, attivazione, recupero e citazione utilizzano tutti lo stesso contratto di identità documentale e revisione.

Domande frequenti

È sufficiente il timestamp di modifica di un file per definire una versione RAG?

No. I timestamp possono cambiare durante operazioni di copia o ripristino e non identificano quale contenuto o famiglia di segmenti sia diventata autorevole. Un ID documentale stabile associato a metadati espliciti della revisione è più sicuro.

Le vecchie versioni dei documenti dovrebbero essere eliminate dal database vettoriale?

Non necessariamente. Possono rimanere disponibili per la cronologia o gli audit, purché il recupero predefinito le escluda e le citazioni conservino chiaramente la loro identità di revisione.

Il controllo delle versioni può impedire risposte obsolete quando gli aggiornamenti non vengono mai rilevati?

No. Il controllo delle versioni gestisce le revisioni note. È comunque necessario un percorso separato di rilevamento delle modifiche e riconciliazione per individuare modifiche, eliminazioni o processi di acquisizione non riusciti.