La scorsa settimana stavo leggendo l'articolo fondativo sul RAG di Lewis et al. — recupera una volta, anteponi il risultato, genera. Funziona, ma presuppone che tu sappia in anticipo cosa ti servirà. FLARE (EMNLP 2023) attacca direttamente questa ipotesi: e se il momento giusto per recuperare fosse a metà frase, proprio quando il modello inizia a essere incerto? Questa domanda vale la pena di essere approfondita attentamente per qualsiasi sistema — come un agente Beancount — che debba ragionare su una cronologia di contabilità che non può rientrare in un'unica finestra di contesto.
L'articolo
"Active Retrieval Augmented Generation" di Zhengbao Jiang, Frank F. Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan e Graham Neubig propone FLARE: Forward-Looking Active REtrieval augmented generation. Il problema che risolvono è l'allucinazione durante la generazione di testi lunghi, dove un modello deve attingere a più conoscenze attraverso un output esteso. Il RAG standard recupera una volta al momento della query e spera che il passaggio recuperato copra tutto ciò di cui la generazione avrà bisogno — va bene per risposte brevi, ma è fragile per risposte multi-paragrafo.
FLARE suddivide la generazione in passaggi a livello di frase. A ogni passaggio genera una frase candidata successiva. Se un qualsiasi token in quel candidato ha una probabilità prevista inferiore a una soglia θ, FLARE tratta questi intervalli a bassa confidenza come segnali di recupero, li utilizza (mascherati o completati) per formare una query, recupera da Wikipedia e rigenera la frase con il contesto recuperato. Il risultato è un sistema che recupera solo quando e approssimativamente dove è incerto — non recupera anticipatamente contenuti che non utilizzerà mai. Tutti gli esperimenti vengono eseguiti su GPT-3.5 (text-davinci-003) senza alcun fine-tuning.
Idee chiave
- Confidenza come trigger di recupero: una probabilità del token inferiore a θ segnala che il modello probabilmente sta allucinando; il recupero viene attivato solo in quel momento, non per impostazione predefinita. Gli autori scoprono che attivarlo per il 40–80% delle frasi funziona solitamente meglio.
- Query forward-looking: invece di utilizzare solo ciò che è già stato generato come query (l'approccio "finestra precedente"), FLARE utilizza la frase successiva prevista — ciò che il modello pensa di dire — come query di recupero molto più mirata.
- Due varianti: FLARE-instruct maschera i token a bassa confidenza e utilizza l'intervallo mascherato come query; FLARE-direct utilizza l'intera frase prevista. Su 2WikiMultihopQA, la variante diretta raggiunge 51.0 EM contro 42.4 della variante instruct.
- I guadagni rispetto al recupero singolo sono reali ma disomogenei: su 2WikiMultihopQA, FLARE-direct raggiunge 51.0 EM contro 39.4 del recupero singolo e 28.2 senza recupero — un miglioramento deciso. Su ASQA il divario è molto più piccolo (41.3 contro 40.0) e WikiAsp (UniEval 53.4 contro 52.4) è quasi un pareggio.
- Casi di fallimento espliciti: gli autori riferiscono che FLARE non offre alcun miglioramento su Wizard of Wikipedia ed ELI5, dove output brevi significano che il recupero multi-passaggio aggiunge overhead senza benefici.
- Costo: poiché generazione e recupero si alternano, ogni esempio può attivare più completamenti LM e chiamate di recupero. La memorizzazione nella cache non è semplice.
Cosa regge — e cosa no
La formulazione forward-looking è la parte veramente intelligente. Utilizzare il contenuto previsto come query di recupero è più informativo del solo prefisso, specialmente per compiti multi-hop dove le conclusioni intermedie determinano quale fatto ti serve successivamente. Il divario di 51.0 contro 39.4 EM su 2WikiMultihopQA lo supporta.
Ma il segnale di confidenza di FLARE dipende interamente da quanto bene è calibrato il modello. Le probabilità dei token di un modello di completamento di base come text-davinci-003 sono correlate in modo ragionevole con l'incertezza. Lo stesso non vale per i modelli chat ottimizzati tramite istruzioni o RLHF, che sono spesso eccessivamente fiduciosi — emettono token ad alta probabilità anche quando allucinano. Un follow-up del 2024, Unified Active Retrieval (UAR, arXiv:2406.12534), valuta FLARE su una suite più ampia di decisioni di recupero e scopre che raggiunge solo il 56,50% di accuratezza in diversi scenari, rispetto all'85,32% dell'approccio basato su classificatore di UAR. Il problema della calibrazione non è un caso limite; è l'ipotesi centrale su cui si basa il metodo.
C'è anche una questione di granularità del recupero che l'articolo non affronta completamente. L'attivazione a livello di frase è un'euristica ragionevole, ma alcuni fatti si estendono oltre i confini delle clausole, e altri sono localizzati in un singolo nome di entità. Una bassa probabilità su un token numerico (un importo in dollari, una data) dovrebbe probabilmente attivare il recupero in modo diverso rispetto a una bassa probabilità su una parola di collegamento. L'articolo tratta tutti i token a bassa confidenza in modo simmetrico.
Infine, il ciclo "rigenera se incerto" introduce latenza. Gli autori lo riconoscono ma non lo quantificano in relazione a un budget di latenza, il che è importante per applicazioni interattive o quasi in tempo reale.
Perché questo è importante per l'AI finanziaria
Un agente Beancount che riassume una contabilità pluriennale non può recuperare tutte le voci storiche in anticipo — il contesto andrebbe in overflow e la maggior parte sarebbe irrilevante per la risposta in questione. Il design di FLARE si adatta bene a questo problema: genera una prima bozza del commento di riconciliazione, nota una bassa confidenza sul saldo corrente di un fornitore specifico, recupera solo le transazioni rilevanti, quindi rigenera quella frase. Lo schema è valido.
Il problema della calibrazione, tuttavia, è una preoccupazione seria. Gli agenti finanziari in produzione utilizzano quasi universalmente modelli chat ottimizzati tramite istruzioni (GPT-4, Claude, Gemini), non modelli di completamento di base. Se questi modelli sono eccessivamente fiduciosi — come spesso accade per le affermazioni numeriche — salteranno il recupero proprio quando dovrebbero attivarlo. Un agente Beancount di back-write che allucina una data di transazione con alta confidenza e non recupera mai per verificare è peggio che inutile.
La lezione pratica è abbinare la costruzione di query forward-looking di FLARE con un trigger di recupero che non si basi esclusivamente sulla probabilità dei token. Marcatori espliciti di incertezza (frasi di attenuazione, numeri arrotondati, entità nominate che il modello non ha visto di recente) potrebbero integrare il segnale di confidenza. Oppure adottare l'approccio UAR: addestrare un classificatore leggero sugli stati nascosti del modello che sia più robusto alla calibrazione errata rispetto ai logit grezzi.
Cosa leggere dopo
- IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) — accoppia il recupero con passaggi CoT piuttosto che con la confidenza dei token; vale la pena confrontarlo direttamente con FLARE su compiti multi-hop.
- Unified Active Retrieval (UAR, arXiv:2406.12534) — il follow-up diretto che espone il divario di calibrazione di FLARE e propone decisioni di recupero basate su classificatore in quattro scenari di recupero.
- "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) — un articolo del 2025 che riesamina se i trigger basati sulla probabilità dei token possono essere riabilitati con tecniche di calibrazione migliori.