Corpus dinamico per RAG: versionare le fonti, ritirare contenuti obsoleti e dimostrare l’evidenza di ogni risposta

Il problema: una citazione può essere esatta e, comunque, non essere utile

Un sistema di generazione aumentata dal recupero, o RAG, viene spesso valutato chiedendosi se recuperi un testo pertinente e se la risposta si basi su di esso. Questo controllo è necessario, ma non è sufficiente quando il corpus cambia. Una risposta può riprodurre con precisione un frammento di una policy annullata, di un manuale sostituito o di un contratto che non si applica più alla persona che effettua la richiesta. In questo caso, il guasto non risiede necessariamente nella generazione: risiede nel ciclo di vita dell’evidenza.

È opportuno separare due domande. La prima è semantica: il frammento recuperato risponde alla richiesta? La seconda riguarda la governance: era una fonte autorizzata, accessibile e vigente per questa richiesta e in questo momento? La sola similarità vettoriale non risolve la seconda domanda. Un testo precedente può sembrare più simile alla domanda rispetto a una revisione recente; una copia locale può contenere istruzioni diverse da una policy centrale; e un frammento indicizzato quando una persona disponeva dell’accesso può continuare a comparire dopo la revoca di quel permesso.

La tesi operativa è semplice: aggiungere file a un indice non crea una base di conoscenza manutenibile. Per ottenerla servono un’identità stabile del documento, una revisione identificabile, un intervallo di validità, una regola di autorità, controlli di accesso applicati durante il recupero e una registrazione che colleghi ogni risposta alle evidenze realmente consultate. Serve inoltre un ritiro esplicito: smettere di pubblicare un file nella fonte di origine non garantisce che scompaia da indici, repliche, cache o registrazioni derivate.

Questa guida considera il corpus come un sistema di registrazioni sottoposto a modifiche, non come una cartella di file. L’obiettivo non è promettere risposte infallibili. È poter dimostrare perché un’evidenza fosse idonea, rilevare quando ha smesso di esserlo e astenersi quando le regole disponibili non permettono di stabilire quale di più fonti attive debba prevalere.

Separare identità, revisione, validità, autorità e accesso

L’identità risponde alla domanda su quale oggetto documentale venga gestito. Deve restare stabile anche se cambiano titolo, posizione o formato. Per esempio, una policy aziendale può mantenere il proprio identificatore canonico nel passaggio da un documento da ufficio a una pagina web. La revisione risponde invece alla domanda su quale edizione concreta contenga il testo. Una correzione redazionale e una sostituzione normativa possono creare revisioni distinte, anche quando la modifica sembra piccola.

La validità esprime quando una revisione può essere usata come evidenza. Non va confusa con la data di indicizzazione né con la data di modifica tecnica del file. Una policy pubblicata oggi può entrare in vigore il mese prossimo; un’altra può essere mantenuta soltanto per consultazioni storiche. È quindi utile conservare almeno un inizio di validità, una fine di validità quando esiste e uno stato operativo, come bozza, approvato, attivo, ritirato o ripristinato in via eccezionale.

L’autorità ordina fonti che possono trattare lo stesso argomento. Una policy globale approvata può prevalere su una guida locale, salvo l’esistenza di un’eccezione valida per una giurisdizione, un’unità o un prodotto. Questa regola non può essere dedotta in modo affidabile dalla formulazione del testo né dalla similarità. Deve essere un attributo governato, con un proprietario e una regola esplicita di precedenza. Se due fonti attive si contraddicono e non esiste una regola applicabile, il comportamento prudente è non sceglierne una in base alla popolarità o alla vicinanza semantica.

Il permesso di accesso è un’altra dimensione indipendente. Un frammento non smette di contenere informazioni protette perché è stato suddiviso, vettorizzato o memorizzato in un indice. I filtri di autorizzazione devono essere applicati prima di ordinare i risultati per rilevanza e devono essere aggiornati quando cambiano le liste di controllo degli accessi. La documentazione dei servizi di ricerca conferma che la sicurezza a livello di documento può limitare i documenti di un indice visibili a una persona e che le modifiche ai permessi richiedono di mantenere sincronizzati i documenti interessati.

Questa progettazione è coerente con un principio fondamentale della provenienza: distinguere entità, attività e agenti. Il documento canonico, la sua revisione e ciascun frammento sono entità; l’estrazione, la suddivisione, la creazione degli embedding e l’indicizzazione sono attività; il proprietario, l’approvatore e il servizio che esegue un processo sono agenti. Modellare queste relazioni non impone una tecnologia specifica, ma evita di trasformare la tracciabilità in note libere difficili da interrogare.

Modello dati minimo per un corpus governato

Un modello minimo non deve acquisire tutti i metadati possibili, ma quelli che consentono di decidere l’idoneità e ricostruire i fatti. L’entità documento canonico può includere un identificatore immutabile, il tipo documentale, l’ambito, il proprietario responsabile, la fonte di origine e la classificazione. L’entità revisione deve avere un proprio identificatore, un’impronta del contenuto ricevuto, lo stato di approvazione, l’inizio e la fine della validità, la data di pubblicazione nota e la relazione con la revisione precedente o sostituita.

Ogni frammento recuperabile deve riportare l’identificatore del documento canonico e della revisione, una posizione o un intervallo stabile all’interno della revisione, l’impronta del testo normalizzato e gli attributi necessari per il filtro. L’embedding non è il frammento: è una rappresentazione derivata. Perciò richiede il proprio identificatore del modello, la versione della configurazione, la data di calcolo e il riferimento al frammento esatto che lo ha originato. Anche l’indice è un’entità operativa: registratene la versione, la partizione o replica, la configurazione di ricerca, l’istante di pubblicazione e l’insieme di revisioni incluso.

Aggiungete relazioni esplicite per sostituisce, deriva da, fonde e ritira. Una fusione documentale non equivale necessariamente a una sostituzione uno a uno: più documenti possono essere assorbiti da una nuova fonte, mentre una parte delle informazioni può restare senza successore. Questa distinzione permette di rispondere se un documento è stato ritirato, quale sia il suo successore quando esiste e se una consultazione storica debba poterlo ancora trovare con controlli specifici.

I campi temporali meritano una disciplina speciale. Conservate il tempo osservato nella fonte, il tempo di approvazione, l’intervallo di validità di business, il tempo di estrazione e il tempo di pubblicazione nell’indice. Non supponete che siano intercambiabili. Per ricostruire una risposta è importante sapere che cosa fosse noto e che cosa fosse operativamente disponibile, oltre a quale testo dichiarasse di essere vigente. Quando gli orologi di più sistemi non sono sincronizzati o una data proviene da metadati poco affidabili, registrate tale incertezza invece di convertirla in una certezza artificiale.

Flussi di modifica: aggiornare non è una sola operazione

L’inserimento iniziale comincia con la convalida dell’origine, dell’identità, del proprietario, della classificazione e delle regole di accesso. Successivamente si estrae il contenuto, si crea una revisione, si suddivide il testo in frammenti, si calcolano le rappresentazioni e si pubblica una versione dell’indice. La pubblicazione deve essere atomica dal punto di vista della richiesta o, almeno, deve evitare stati nei quali sia visibile una parte di una revisione e non un’altra. Se sono richieste approvazioni, una bozza può essere elaborata tecnicamente senza essere idonea a fornire risposte.

Una correzione minore richiede di confrontare la nuova impronta con la revisione precedente e localizzare i segmenti modificati. Ricalcolare soltanto i frammenti coinvolti può ridurre il lavoro, ma solo se l’algoritmo di suddivisione conserva riferimenti corretti. Se una modifica sposta titoli, numerazione o sezioni, può interessare più frammenti di quanti ne indichi un confronto letterale. L’ottimizzazione deve essere subordinata alla tracciabilità: è preferibile reindicizzare più contenuto piuttosto che conservare collegamenti ambigui tra un embedding e un testo.

La sostituzione di una policy è un evento di governance. Deve creare una revisione o un documento successore, fissarne la data di entrata in vigore, chiudere la validità del precedente quando opportuno e propagare il ritiro a tutti gli artefatti derivati. In alcuni sistemi di indicizzazione, i documenti non più presenti nella fonte di origine possono richiedere un’azione di eliminazione esplicita; pertanto, una nuova esecuzione non deve essere considerata prova di un ritiro completo. La verifica deve interrogare lo stato degli indici e delle repliche, non soltanto il registro della fonte.

Un ritiro totale conserva, se la policy di conservazione lo consente, uno storico non idoneo alle risposte ordinarie. Lo storico può essere necessario per audit, indagine sugli incidenti o ricostruzione di una risposta precedente. Deve rimanere separato dagli indici attivi, con controlli di accesso e una finalità definita. Il ripristino di una fonte ritirata è eccezionale: deve produrre un nuovo evento, giustificare il cambiamento di stato e attivare una nuova pubblicazione verificabile, anziché cancellare la traccia del ritiro precedente.

Reindicizzazione, cache e duplicati: mantenere la coerenza tra rappresentazioni

La reindicizzazione selettiva è utile quando è possibile dimostrare la relazione tra ogni rappresentazione e il suo input. Calcolate le differenze di testo e di metadati. Una modifica nel contenuto impone di riesaminare i frammenti e gli embedding interessati. Una modifica di validità, autorità, giurisdizione o permesso può non alterare il testo, ma modifica l’idoneità al recupero; per questo deve aggiornare filtri, indici di metadati e cache. Trattare soltanto le modifiche testuali lascia una strada aperta a risposte errate con contenuto letteralmente invariato.

Non tutte le cache memorizzano lo stesso elemento. Possono esistere cache di scaricamento della fonte, di frammenti elaborati, di embedding, di risultati di recupero e di risposte finali. Ciascuna richiede una chiave che incorpori le dipendenze pertinenti, quali la versione dell’indice, la revisione delle fonti, l’identità della persona o il suo gruppo di accesso, la giurisdizione e la data della richiesta quando si risponde sulla validità. Riutilizzare una risposta senza queste dimensioni può rivelare contenuto o riportare in vita una policy ritirata.

I principi delle cache web distinguono freschezza, convalida e invalidazione, e stabiliscono che le richieste che modificano lo stato della risorsa debbano invalidare le rappresentazioni memorizzate applicabili. In un corpus RAG, il meccanismo concreto può essere diverso, ma il principio è trasferibile: quando cambia una fonte o la sua idoneità, occorre localizzare e rimuovere o invalidare le rappresentazioni derivate che potrebbero continuare a servire la versione precedente.

I duplicati semantici richiedono una policy esplicita. Due frammenti possono esprimere la stessa regola e appartenere a revisioni diverse; restituirli entrambi può aumentare artificialmente la fiducia del modello. Raggruppate i candidati per documento canonico o per relazione di revisione prima di generare la risposta. Il raggruppamento non deve nascondere i conflitti: se due fonti attive e ugualmente autorizzate discordano, mantenete il conflitto come segnale per astenersi o richiedere una revisione umana.

Recuperare con tempo, autorità e permessi prima di ordinare per similarità

La richiesta di recupero deve essere costruita come una sequenza di restrizioni e ordinamento, non come una ricerca vettoriale seguita da una verifica facoltativa. Prima determinate il contesto: identità di chi effettua la richiesta, permessi effettivi, prodotto, giurisdizione, pubblico destinatario, data pertinente ed eventuale necessità di consultare lo storico. Filtrate poi revisioni e frammenti che non soddisfano tale contesto. Soltanto i candidati idonei devono passare al calcolo della similarità, alla ricerca lessicale o a una combinazione di entrambe.

La data pertinente richiede una decisione di prodotto visibile. Per domande sulla regola attuale, usate l’istante della richiesta. Per domande quali «quale policy si applicava quando ho firmato?», richiedete o inferite con cautela una data di riferimento e cercate nello storico autorizzato. Se la data non è nota, non presentate una ricostruzione storica come se fosse attuale. È preferibile chiedere il dato, mostrare l’ambito temporale dell’evidenza o limitare la risposta a quanto può essere giustificato.

L’autorità può essere implementata come punteggio, ma non dovrebbe essere sempre ridotta a un numero. Alcune regole sono rigide: una norma obbligatoria per una giurisdizione può escludere una guida generale. Altre possono essere preferenziali e ammettere coesistenza. Documentate le regole, il loro proprietario e le eccezioni. Il sistema generativo non dovrebbe inventare una gerarchia a partire dal tono dei documenti.

Prima di redigere, conservate l’elenco dei candidati filtrati, i motivi di esclusione, la configurazione dell’indice e i frammenti infine utilizzati. La registrazione deve distinguere tra evidenza recuperata ed evidenza citata nella risposta. Deve inoltre registrare l’ora della richiesta e la versione delle regole di filtro. Senza questi dati, un’indagine successiva potrebbe trovare il documento attuale, ma non dimostrare quale corpus abbia prodotto il risultato originale.

Test di regressione, criteri di arresto e responsabilità

I test devono valutare il comportamento del sistema davanti alle modifiche, non soltanto la qualità del recupero su un insieme stabile. Costruite casi con una policy ritirata che conserva una similarità maggiore del suo sostituto, un frammento eliminato da una revisione, una policy approvata con data di validità futura, una copia locale che contraddice una fonte centrale e un permesso revocato dopo l’indicizzazione. Ogni caso deve dichiarare quali documenti sono idonei, quale debba prevalere se esiste una regola di autorità e quando l’output corretto sia l’astensione.

Testate anche la propagazione temporale. Misurate l’intervallo tra l’approvazione di un ritiro e la sua esclusione effettiva da indici, repliche e cache pertinenti. Non basta testare l’indice principale: una risposta generata in precedenza può essere memorizzata in un altro livello. Definite obiettivi temporali diversi in base al rischio della fonte. Una policy di sicurezza o un documento con dati sensibili può richiedere un’invalidazione più rapida di una guida editoriale interna.

Stabilite criteri di arresto chiari. Bloccate una risposta quando manca il collegamento tra frammento e revisione, quando i permessi non possono essere valutati, quando la fonte non ha un proprietario o quando esiste un conflitto attivo senza regola di precedenza. Mostrate la data di aggiornamento quando contribuisce a interpretare la risposta, ma non usatela per nascondere l’incertezza. Escalate a una revisione umana se esiste evidenza potenzialmente pertinente che il sistema non riesce a ordinare mediante regole esplicite.

Le responsabilità devono restare separate, sebbene la stessa persona possa coprire più ruoli nei team piccoli. Il proprietario della fonte risponde del contenuto e del suo ciclo di validità. Il responsabile dell’indicizzazione risponde dell’estrazione, della pubblicazione e dell’invalidazione tecnica. L’approvatore della validità decide quando una revisione è utilizzabile. Il responsabile degli incidenti coordina il ritiro urgente, la valutazione dell’esposizione e la comunicazione. Il team di prodotto definisce come esprimere l’astensione e come richiedere contesto aggiuntivo alla persona utente.

Come passo successivo, trasformate questo modello in una lista di controlli verificabili e collegatelo alle guide del centro di apprendimento sulla valutazione degli assistenti, sul confronto tra approcci di recupero e sulla scoperta delle fonti. L’implementazione dipenderà dall’architettura, ma il criterio di successo resta invariato: per ogni risposta rilevante, il team deve poter spiegare quale evidenza potesse essere usata, quale sia stata usata, perché fosse autorizzata e cosa avrebbe impedito di rispondere.

Continua a esplorare

Correzioni e trasparenza

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