Come mantenere aggiornato un corpus RAG e verificare che i documenti obsoleti non compaiano più

Mantenere il corpus non significa valutare le risposte

Un corpus RAG è mantenuto correttamente quando i contenuti disponibili per il recupero corrispondono ancora alle fonti che il team considera valide. Il lavoro consiste nell’identificare documenti e versioni, elaborare le modifiche, aggiornare le unità indicizzate e verificarne il risultato. È un’attività diversa dal valutare se il modello formula una risposta corretta o la fonda adeguatamente sui frammenti recuperati. Le due valutazioni possono essere collegate, ma non sono intercambiabili: una prova di recupero può rivelare che continua a comparire un documento ritirato, anche se la risposta generata sembra ragionevole.

La documentazione Microsoft fornita descrive la creazione di una pipeline di dati non strutturati per applicazioni di IA. La documentazione di Google Cloud riguarda la gestione di un corpus RAG e, in base alle informazioni disponibili, include la creazione di un corpus e l’importazione o il caricamento di documenti. Questi riferimenti offrono un contesto utile sul trattamento e sull’acquisizione dei dati, ma le informazioni disponibili non confermano una procedura universale per aggiornare o eliminare documenti. I passaggi che seguono sono quindi un modello operativo adattabile, non la garanzia che una determinata funzione sia disponibile in ogni prodotto.

L’obiettivo pratico è saper rispondere a domande sullo stato dei contenuti: quale fonte ha originato un frammento, quale versione è stata elaborata, se si è verificato un errore parziale e quale prova dimostra che una rimozione ha avuto effetto. Se il team non è in grado di rispondere, non dovrebbe considerare aggiornato il corpus soltanto perché un’esecuzione di elaborazione è terminata.

Fare l’inventario delle fonti prima di automatizzare

Inizia elencando le fonti che possono alimentare il corpus e assegnando un responsabile a ciascuna. Una fonte può essere un repository di documentazione interna, un catalogo, un insieme di norme o una raccolta di file. L’inventario non deve dipendere da un prodotto specifico, ma deve consentire di distinguere ogni origine e di sapere chi decide se il contenuto va acquisito, modificato o ritirato.

Per ogni documento, conserva un identificativo stabile, se il sistema di origine ne fornisce uno. Registra anche la posizione o la raccolta di origine, il proprietario, una data o versione verificabile e lo stato del documento, per esempio attivo, in attesa di elaborazione o ritirato. Se non esiste una versione formale, puoi registrare un segnale di modifica disponibile nella fonte, purché il team documenti che cosa significa e quali sono i suoi limiti. Non dare per scontato che una data di modifica basti a distinguere due contenuti identici o due revisioni diverse.

Collega queste proprietà a ogni unità derivata che viene indicizzata, come un frammento o un record. Lo scopo è poter individuare tutte le unità provenienti da una fonte quando questa cambia o viene ritirata. Se il meccanismo di indicizzazione non permette di memorizzare metadati, o non documenta come filtrare e rimuovere i record, annotalo come limite da verificare; non presumere che cancellare il file di origine elimini automaticamente i suoi derivati.

Definisci anche le regole di acquisizione e rimozione. Per esempio, specifica chi autorizza il passaggio di un documento allo stato attivo, che cosa si intende per sostituzione e come si gestiscono fonti in conflitto. Sono decisioni di governance del team, non caratteristiche intrinseche di RAG. Metterle per iscritto evita che un aggiornamento tecnico determini per errore quale versione debba essere considerata valida.

Decidere quali modifiche richiedono una nuova elaborazione

Non tutte le modifiche devono comportare lo stesso lavoro. Una correzione circoscritta potrebbe richiedere l’elaborazione di un singolo documento; una modifica alle regole di estrazione o al modo in cui il testo viene suddiviso potrebbe riguardare un’intera raccolta. Una modifica della configurazione che trasformi la rappresentazione memorizzata potrebbe giustificare una ricostruzione più ampia. Si tratta di categorie decisionali: prima di applicarle, occorre verificare quali componenti utilizza la propria architettura e quali operazioni supporta.

Scrivi una policy che colleghi i segnali di modifica all’ambito della nuova elaborazione. Per esempio: una nuova versione identificata nella fonte attiva la rielaborazione di quel documento; una modifica generale delle regole di estrazione attiva una revisione della raccolta interessata; un dubbio sulla coerenza dell’insieme può portare a una ricostruzione di prova. Non trasformare questi esempi in automatismi senza aver prima verificato l’identità dei documenti, la possibilità di eliminarli e il comportamento dello strumento.

La pipeline descritta da Microsoft può essere un riferimento generale per ragionare sull’elaborazione di dati non strutturati, ma le informazioni disponibili non specificano quali operazioni di aggiornamento incrementale, sincronizzazione o eliminazione implementi. Allo stesso modo, il riferimento di Google Cloud alla gestione del corpus conferma il tema della creazione e dell’importazione, ma non permette di dedurre quali condizioni si applichino alla modifica o all’eliminazione dei record. Il comportamento effettivo va verificato nella documentazione dello stack scelto e con prove controllate.

Progettare il ciclo di aggiunta e modifica

Un ciclo di aggiornamento può essere organizzato in fasi esplicite. Per prima cosa si rileva una nuova fonte o una modifica mediante un segnale disponibile nel sistema di origine. Poi si registra la versione osservata e si verifica che il documento sia ammissibile secondo le regole del team. In seguito si estrae il contenuto, lo si elabora con la configurazione concordata e si conservano metadati che consentano di risalire alla fonte.

Prima di pubblicare il risultato, decidi come gestire la transizione tra versioni. Una strategia possibile è preparare e verificare la nuova versione prima di renderla disponibile, se la piattaforma permette di mantenerla separata. Un’altra possibilità è sostituire direttamente il contenuto e verificarlo in seguito. Non si deve affermare che una strategia sia sempre migliore: la scelta dipende dalle funzionalità documentate, dalla tolleranza del sistema a un’interruzione e dalla gestione dello stato parziale.

Il registro dell’esecuzione dovrebbe riportare almeno la fonte e la versione obiettivo, la data di rilevamento, l’ambito previsto, lo stato di ogni fase e l’esito delle verifiche. Se il processo si interrompe, queste informazioni aiutano a distinguere tra una fonte non rilevata, un’estrazione non riuscita e un aggiornamento applicato solo in parte. Evita di contrassegnare una versione come corrente solo perché la sua elaborazione è iniziata.

Includi un criterio di completamento osservabile. Per esempio, l’operazione non viene contrassegnata come completata finché non si verifica che le unità previste siano recuperabili e che la versione precedente non compaia più quando dovrebbe essere stata sostituita. Il criterio deve essere applicabile con lo strumento specifico. Se questo non offre un modo per verificarlo, registra il limite e progetta una prova esterna di recupero.

Gestire rimozioni e sostituzioni senza lasciare residui

Rimuovere un file dalla fonte e rimuoverne le rappresentazioni dall’indice sono azioni diverse, a meno che l’integrazione specifica non documenti e dimostri il contrario. Una rimozione può lasciare frammenti, copie derivate o record duplicati se non si individuano tutti gli elementi provenienti dalla fonte. Per questo il collegamento tra identificativo della fonte e unità indicizzate dovrebbe essere progettato prima della prima rimozione.

In caso di sostituzione, registra quale versione non è più valida e quale deve prendere il suo posto. Verifica che la nuova versione venga elaborata correttamente e che quella precedente non compaia più nelle ricerche in cui prima era pertinente. Se le due versioni devono coesistere per una ragione legittima, stabilisci come distinguerle e quale stato assegnare a ciascuna. Non presentarle come equivalenti se la policy della fonte le considera incompatibili.

La rimozione dovrebbe lasciare una traccia: fonte ritirata, momento della richiesta, responsabile, unità interessate o ambito dell’operazione, esito e query di prova. Se l’operazione non riesce, conserva lo stato in attesa o non riuscito ed evita di presentare il corpus come pienamente aggiornato. Il recupero può consistere in un nuovo tentativo, nella ricostruzione di una parte o nell’escalation del problema; la scelta dipende dalle funzionalità disponibili e dovrebbe essere registrata.

Le fonti fornite non confermano in misura sufficiente che una piattaforma specifica elimini automaticamente tutti i frammenti derivati quando viene cancellato un documento. La discussione Reddit inclusa tra le fonti è aneddotica e non consente di stabilire un comportamento garantito. Verifica le funzioni di eliminazione nella documentazione ufficiale del prodotto specifico e, soprattutto, controlla il risultato con una prova riproducibile.

Controllare aggiornamenti parziali ed errori

Un processo di aggiornamento può interrompersi dopo aver rilevato una modifica, durante l’estrazione o dopo aver modificato soltanto una parte dell’indice. Il modello operativo deve rendere visibile questa differenza. Definisci stati semplici, come in attesa, in elaborazione, completato e non riuscito, e specifica il significato di ciascuno. Se il team deve registrare fasi più dettagliate, può aggiungerle, purché gli operatori capiscano come si collegano tra loro.

Decidi quali contenuti sono da considerare disponibili mentre un aggiornamento è incompleto. In alcuni sistemi potrebbe essere possibile conservare la versione precedente fino alla convalida di quella nuova; in altri, l’aggiornamento potrebbe causare un’interruzione temporanea o risultati che mescolano più versioni. Non promettere atomicità o sostituzioni senza interruzioni, a meno che la documentazione della piattaforma non lo confermi e una prova non lo verifichi.

Definisci una policy per i nuovi tentativi che non produca duplicati. Prima di rieseguire un processo, controlla se l’operazione precedente ha lasciato unità parziali e come individuarle. Se non riesci a determinarlo, considera incerto il risultato ed evita una seconda scrittura alla cieca. Registra l’ambito, la decisione presa e la prova successiva, in modo che un altro operatore possa ricostruire quale versione fosse disponibile.

Scegliere tra aggiornamento incrementale e ricostruzione

L’aggiornamento incrementale limita il lavoro ai documenti o alle raccolte interessati; può essere adatto quando il sistema permette di identificare con precisione ogni fonte e di rimuoverne o sostituirne i derivati. La ricostruzione elabora nuovamente un insieme più ampio e può facilitare una verifica complessiva, ma può anche richiedere più tempo e risorse. Sono considerazioni operative generali, non garanzie di prestazioni né descrizioni di uno strumento specifico.

Confronta le due opzioni usando dati del tuo ambiente: volume delle fonti, frequenza delle modifiche, durata osservata, costo di elaborazione, facilità di individuazione degli elementi interessati e conseguenze di un aggiornamento incompleto. Considera anche le funzionalità documentate dello stack per aggiornare, eliminare, consultare gli stati e ripristinare una versione precedente. Se una funzione essenziale non è confermata, registrala come incertezza da risolvere prima di automatizzare.

Non scegliere la modalità incrementale solo perché sembra meno costosa, né ricostruire automaticamente a ogni modifica. La decisione dipende dalla possibilità di circoscrivere l’impatto e dimostrare la coerenza del risultato. Una prova di ricostruzione in un ambiente controllato può aiutare a stimare i tempi e individuare differenze; da sola, però, non dimostra che una ricostruzione in produzione sia sicura.

Verificare che il corpus rifletta lo stato previsto

Le prove di accettazione dovrebbero controllare il comportamento del corpus, non soltanto che un’attività tecnica sia terminata senza errori. Le informazioni fornite sulla creazione di corpus orientati a RAG e sul loro uso nella valutazione confermano l’importanza di predisporre verifiche per i sistemi RAG, ma non prescrivono una batteria specifica o una soglia universale. Le query e i criteri vanno definiti in base alle fonti e ai rischi di ciascuna applicazione.

Crea un insieme piccolo e stabile di query. Includi query che dovrebbero recuperare una versione corrente, query distintive di una fonte ritirata e query su documenti non correlati che dovrebbero restare disponibili. Registra la fonte e la versione attese, il risultato osservato e il momento in cui è stata eseguita la prova. Se il recupero dipende dall’ordinamento, da soglie o da altre impostazioni, annota la configurazione pertinente per poter interpretare le differenze tra un’esecuzione e l’altra.

Aggiungi prove per individuare duplicati e conflitti. Una ricerca può restituire la versione vecchia e quella nuova, due copie dello stesso documento o frammenti che non conservano metadati sufficienti a distinguerle. Definisci quali risultati sono accettabili: per esempio, una sola versione attiva quando la policy richiede l’esclusività, oppure entrambe le versioni chiaramente identificate quando la coesistenza è autorizzata.

Una prova negativa — non recuperare una fonte ritirata — richiede attenzione: il fatto che non compaia in una singola query non dimostra che sia scomparsa dall’intero indice. Usa più query rappresentative e, se lo strumento lo consente, ispeziona i record associati all’identificativo della fonte. Descrivi l’effettiva portata della verifica ed evita di trasformare un campione in una garanzia assoluta.

La valutazione del recupero, da sola, non determina nemmeno se il modello formula una risposta corretta. Se il team deve valutare anche la risposta finale, dovrebbe mantenere un insieme di prove separato, con criteri adeguati a tale compito. In questo modo è possibile distinguere un problema di validità del corpus da un problema di generazione o di uso del contesto.

Routine periodica e limiti delle evidenze

Una routine periodica dovrebbe verificare le modifiche in sospeso, le esecuzioni non riuscite, le fonti senza responsabile, le versioni di cui non è stata confermata la validità e le prove di accettazione non ancora eseguite. La frequenza dipende dal ritmo delle modifiche e dal rischio: una raccolta normativa può richiedere controlli più frequenti rispetto a un archivio consultato occasionalmente. Le fonti fornite non indicano una periodicità universale; ogni team dovrebbe motivare la propria.

Verifica anche se le regole di estrazione o di elaborazione sono cambiate dall’ultimo aggiornamento e se tale cambiamento richiede una nuova elaborazione dei documenti precedenti. Controlla che gli identificativi e i metadati continuino a essere associati alle unità recuperate. Se non è possibile ricostruire quali fonti e versioni abbiano contribuito a una prova, dai priorità alla correzione di questa carenza di tracciabilità prima di ampliare l’automazione.

Le fonti disponibili hanno una portata limitata. La documentazione Microsoft conferma il tema delle pipeline di dati non strutturati per l’IA; quella di Google Cloud riguarda la gestione e l’importazione di documenti in un corpus RAG; l’articolo dell’Istituto di Ingegneria della Conoscenza tratta la creazione di corpus per RAG e il loro uso nella valutazione. Nessuno degli estratti forniti conferma il comportamento esatto di una piattaforma per rimozioni, sostituzioni, transazioni, ricostruzioni o aggiornamenti incrementali. Queste funzionalità vanno verificate nella documentazione aggiornata del prodotto e con prove nell’ambiente reale.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.