Mappature tra affermazioni e fonti

In un sistema di ricerca multi-agente, il coordinatore aggrega i risultati dei subagenti, ciascuno dei quali ha ricavato fatti da documenti diversi. La risposta aggregata è affidabile solo se ogni affermazione può essere ricondotta alla sua origine.

Una mappatura tra affermazione e fonte collega ogni dichiarazione fattuale alla propria origine: l'URL, il nome del documento, la citazione esatta e la data di pubblicazione. Senza questo collegamento, si dispone di un'affermazione che nessun revisore umano può verificare e nessun agente a valle può sottoporre ad audit.

Per l'esame Architect, la provenienza rientra nel Domain 4 (Prompt Engineering & Structured Output) e ricorre nello Scenario 3 (Multi-Agent Research) e nello Scenario 6 (Structured Data Extraction).

Una mappatura della fonte dovrebbe sempre contenere quattro elementi di ancoraggio, così che una persona o un altro agente possano ritrovare e verificare nuovamente le prove:

• URL — dove si trova il documento (oppure un identificatore stabile).
• Nome del documento — un titolo comprensibile per una persona.
• Citazione — il testo parola per parola che supporta l'affermazione, non una parafrasi.
• Data di pubblicazione — quando la fonte è stata pubblicata o aggiornata l'ultima volta.

La citazione parola per parola consente al revisore di verificare che il modello non abbia inventato informazioni o esagerato il contenuto. La data consente di risolvere successivamente eventuali conflitti, come vedremo.

Non chieda al modello di inserire le citazioni nel testo discorsivo, dove è facile ometterle. Imponga invece una struttura definita con un JSON Schema tramite uno strumento. L'associazione di tool_use a uno schema elimina gli errori di sintassi e garantisce la presenza dei campi obbligatori.

Ogni affermazione diventa un oggetto che contiene i propri elementi di ancoraggio della fonte. Questa è la base di un record di provenienza verificabile.

Una regola sottile ma fondamentale per l'esame: contrassegni un campo come obbligatorio solo se è sempre presente nella fonte. Se rende obbligatorio un campo che potrebbe mancare, il modello inventa un valore per soddisfare lo schema.

Un post di un blog potrebbe non avere una publication_date formale; un PDF interno potrebbe non avere un source_url. Pertanto claim, quote e document_name sono obbligatori (sono sempre disponibili), mentre source_url e publication_date restano facoltativi. Una data vuota è onesta; una data inventata è un errore di provenienza.

Per garantire di ricevere l'oggetto di provenienza invece di testo discorsivo libero, vincoli il modello con tool_choice. Impostando {"type": "tool", "name": "record_claims"} si forza l'uso di quello specifico strumento, così ogni risposta arriva come JSON convalidato dallo schema.

Usare "any" garantirebbe che venga chiamato un qualsiasi strumento; forzare lo strumento indicato per nome offre la garanzia più stringente quando si dispone di un solo strumento di estrazione.

Richiedere una citazione parola per parola (non una parafrasi) è un fattore di affidabilità, non solo un adempimento documentale. Quando il modello deve copiare il testo esatto che fornisce il supporto, diventa molto più difficile affermare qualcosa che la fonte non ha mai detto.

Rafforzi questo requisito con criteri espliciti nel prompt e con 2-4 esempi few-shot. Gli esempi few-shot sono particolarmente efficaci per il formato dell'output, i casi limite e la riduzione delle allucinazioni: il modello generalizza lo schema invece di limitarsi a ripetere gli esempi forniti.

In un sistema di ricerca hub-and-spoke, i subagenti non ereditano la cronologia della conversazione del coordinatore. Ogni subagente deve restituire i propri risultati insieme alle mappature delle fonti, perché il coordinatore non ha altro modo per sapere da dove provenga un fatto.

Il coordinatore aggrega quindi questi oggetti di affermazione autonomi. Se un subagente restituisce una frase isolata senza citazione o nome del documento, quel fatto diventa non verificabile nel momento in cui esce dal contesto del subagente: lo consideri privo di provenienza, non un risultato valido.

Quando due fonti non concordano su una statistica, la scelta sbagliata è selezionarne una in silenzio. La scelta corretta è annotare il conflitto e presentare entrambe le affermazioni con le rispettive fonti.

Spesso la data di pubblicazione risolve l'apparente contraddizione: un dato del 2021 e uno del 2024 non sono contraddittori, ma costituiscono una serie temporale. È proprio per questo che l'elemento data merita di comparire in ogni mappatura. Conservi entrambi i dati, li etichetti e lasci che sia una persona (o una regola consapevole della data) a decidere.

L'autocorrezione funziona estraendo due valori che è possibile confrontare. Per la provenienza, chieda al modello di produrre ogni affermazione insieme a un indicatore che specifichi se è stata effettivamente trovata una citazione di supporto, quindi convalidi programmaticamente che ogni affermazione ne contenga una.

Questo rileva il fallimento silenzioso in cui una frase sicura di sé viene fornita senza alcuna prova a sostegno. In questo caso la convalida è strutturale, quindi perfetta per un ciclo di retry.

Se la convalida rileva una lacuna strutturale (citazione mancante, data malformata), utilizzi il retry-with-feedback: invii al modello il documento originale, il suo output errato e l'errore di convalida esatto. Questo corregge in modo affidabile gli errori di formato e di struttura.

Limite fondamentale: il retry non aiuta quando l'informazione è semplicemente assente dalla fonte. Se il documento non contiene realmente alcuna data di pubblicazione, nessun numero di retry potrà farla comparire e non deve consentirlo. Lasci il campo vuoto e proceda, invece di entrare in un ciclo infinito.

Una volta mappate le affermazioni, le presenti nel formato più adatto al contenuto. Visualizzi i dati finanziari come tabelle, le notizie come testo discorsivo e i risultati tecnici come elenchi, mostrando in ogni caso i relativi elementi di ancoraggio della fonte.

Per la supervisione umana, una nota a piè di pagina o una colonna finale contenente il nome del documento, la data e un link rende la verifica immediata anziché trasformarla in un'indagine. Una provenienza che non si vede è una provenienza che nessuno controllerà.

Punti chiave per l'esame e per i sistemi in produzione:

• Colleghi ogni affermazione a quattro elementi di ancoraggio: URL, nome del documento, citazione parola per parola, data di pubblicazione.
• Imponga la struttura con tool_use + JSON Schema e la renda obbligatoria tramite tool_choice.
• Contrassegni un campo come obbligatorio solo se è sempre presente: non renda mai obbligatorio un campo che potrebbe mancare, altrimenti il modello lo inventerà.
• I subagenti non ereditano la cronologia, quindi ciascuno deve restituire affermazioni autonome e tracciabili.
• Annoti i conflitti; lasci che siano le date a risolvere le apparenti contraddizioni, invece di scegliere arbitrariamente.
• Utilizzi il retry-with-feedback per le lacune strutturali, ma accetti che il retry non possa fornire informazioni assenti dalla fonte.
• Visualizzi i contenuti in base al tipo (tabelle/testo discorsivo/elenchi), con le fonti visibili per la supervisione umana.