Quando dovrebbe un'IA smettere di fidarsi della propria conoscenza? — Il grilletto del recupero

Domanda

Quando un'IA dovrebbe smettere di fare affidamento su ciò che già conosce e recuperare informazioni esterne prima di rispondere?

Questa domanda sembra semplice, ma si trova al centro di una delle decisioni progettuali più importanti nei moderni sistemi di IA.

I grandi modelli linguistici contengono una conoscenza sostanziale nei loro parametri. La Generazione Aumentata dal Recupero aggiunge informazioni esterne in fase di esecuzione. Ma nessuno dei due estremi è ideale.

Fidarsi sempre del modello può produrre risposte obsolete o non supportate. Recuperare sempre informazioni aggiunge latenza, costo, contesto irrilevante e nuove opportunità di errori di recupero.

Il vero problema quindi viene prima del RAG: quando dovrebbe avvenire il recupero?

Questo articolo utilizza il termine Trigger di Recupero per tale decisione. Il Trigger di Recupero non è presentato qui come un termine standardizzato dalla letteratura di ricerca. È un concetto pratico di sistemi che riunisce idee già visibili nella ricerca sul recupero attivo, adattivo e autoriflessivo.

Un Trigger di Recupero è una condizione che indica che un sistema di IA dovrebbe smettere di fare affidamento esclusivamente sulla conoscenza interna del modello e ottenere prove esterne prima di produrre o finalizzare una risposta.— Definizione di lavoro

Cosa Significa Davvero

Un LLM ha due modi fondamentalmente diversi di ottenere informazioni.

Il primo è la conoscenza del modello. Questa è l'informazione rappresentata nei parametri appresi del modello. Non è richiesta alcuna query al database, ricerca web o consultazione di documenti in fase di esecuzione.

Il secondo è la conoscenza in fase di esecuzione. Questa è l'informazione fornita mentre il modello è in funzione: risultati di ricerca, record di database, documenti, API, file utente, output di strumenti o altre prove recuperate.

Il RAG collega questi due mondi. Ma il RAG stesso non risponde alla domanda su quando tale connessione debba essere attivata. Questo è lo scopo del Trigger di Recupero.

Question
   ↓
Model Knowledge
   ↓
Is internal knowledge sufficient?
   ↓
Retrieval Trigger
   ↓
External Retrieval, if required
   ↓
Evidence
   ↓
Reasoning
   ↓
Answer Validity Boundary
   ↓
Answer

Il Trigger di Recupero quindi si trova prima del recupero. Il Confine di Validità della Risposta si trova dopo.

Il primo chiede: Ho bisogno di prove esterne?

Il secondo chiede: Ho ora abbastanza prove per supportare questa risposta?

Queste sono decisioni correlate, ma non sono la stessa decisione.

Esempio più semplice

Considera tre domande.

La prima domanda si basa su un fatto altamente stabile.

User
↓
"What is the capital of France?"

Model knowledge
↓
Paris

Fresh external evidence required?
↓
No

Answer
↓
Paris

Recuperare documenti prima di rispondere di solito aggiungerebbe poco valore.

Ora considera una domanda la cui risposta cambia continuamente.

User
↓
"What is the current NVIDIA stock price?"

Model knowledge
↓
Potentially outdated

Current information required?
↓
Yes

RETRIEVAL TRIGGER
↓
Market data / search / API
↓
Answer

Il modello può sapere molto su NVIDIA. Ciò non significa che conosca il prezzo attuale.

Il terzo esempio è ancora più importante.

User
↓
"Does this new scientific paper prove that X causes Y?"

Model knowledge
↓
Can reason about causality,
statistics and scientific methodology.

But:
the actual evidence is not available internally.

RETRIEVAL TRIGGER
↓
Retrieve the paper
↓
Inspect methodology
↓
Inspect results
↓
Compare claim with evidence
↓
Answer Validity Boundary
↓
Answer

La capacità di ragionamento del modello può essere perfettamente utile. Il componente mancante sono le prove.

Questa distinzione è fondamentale.

Dove l'esempio smette di funzionare

Gli esempi sopra rendono la decisione apparentemente binaria: recuperare o non recuperare.

I sistemi reali sono più complicati. Una domanda può contenere diverse affermazioni, alcune stabili e altre attuali. I documenti recuperati possono essere in disaccordo. Un sistema di recupero può restituire informazioni irrilevanti. Le informazioni rilevanti possono esistere ma non riuscire a classificarsi abbastanza in alto. Un documento può essere autorevole ma obsoleto.

Il recupero stesso può anche introdurre un contesto errato in una risposta altrimenti ragionevole.

Ecco perché il recupero non dovrebbe essere trattato come un sinonimo automatico di verità.

La ricerca sul recupero adattivo si è progressivamente allontanata dall'assunto che ogni query debba ricevere la stessa strategia di recupero.

Self-RAG, ad esempio, esplora esplicitamente il recupero su richiesta anziché recuperare indiscriminatamente un numero fisso di passaggi per ogni input. Gli autori discutono di come un recupero non necessario o irrilevante possa ridurre la qualità delle risposte.

Adaptive-RAG seleziona analogamente tra nessun recupero, recupero a singolo passaggio e strategie di recupero più complesse in base alla complessità della domanda.

Quindi la domanda importante non è: questo sistema ha il RAG?

È: questo sistema è in grado di riconoscere quando il recupero è necessario e quale tipo di recupero è appropriato?

Risposta diretta

Un'IA dovrebbe attivare il recupero quando la risposta richiede informazioni che la conoscenza interna del suo modello non può fornire in modo sicuro con l'aggiornamento, la specificità, la provenienza o il supporto probatorio richiesti.

Nei sistemi pratici, un Trigger di Recupero può emergere da diverse condizioni:

Need for current information
        OR
Need for exact source-specific information
        OR
Need for evidence or provenance
        OR
Need for private/user-specific information
        OR
Insufficient knowledge coverage
        OR
Conflicting evidence
        OR
High consequence of factual error

Se nessuna di queste condizioni è materialmente presente, il recupero potrebbe essere non necessario. Se una o più sono presenti, le prove esterne diventano parte del processo di generazione della risposta.

Perché è così

La conoscenza interna di un modello linguistico è spesso descritta come conoscenza parametrica. È stata appresa durante l'addestramento e codificata nei parametri del modello.

Il lavoro originale di Lewis et al. sul RAG ha inquadrato il recupero come una combinazione di questa memoria parametrica con una memoria esterna non parametrica. La memoria esterna può essere cercata e aggiornata senza riaddestrare l'intero modello linguistico.

Questa distinzione crea un problema di sistema inevitabile.

Il modello può sapere delle cose. Ma il modello non può presumere che tutto ciò che sa sia attuale, completo, sufficientemente specifico e supportato dalle prove richieste.

Un modello può quindi produrre una risposta linguisticamente convincente pur operando oltre il punto in cui la sua conoscenza interna è sufficiente.

Quel punto è dove un Trigger di Recupero diventa utile.

Contesto

Il RAG tradizionale spesso si presenta così:

Question
↓
Retrieve documents
↓
Add documents to context
↓
Generate answer

Questa architettura presuppone il recupero prima della generazione. Funziona bene per molte applicazioni ad alta intensità di conoscenza, ma può anche eseguire recuperi non necessari.

Approcci più avanzati introducono un passaggio adattivo:

Question
↓
Evaluate information requirement
↓
        ┌───────────────┐
        │               │
   no retrieval      retrieval
        │               │
        ↓               ↓
 model knowledge    external evidence
        │               │
        └───────┬───────┘
                ↓
              answer

FLARE va oltre considerando il recupero durante la generazione stessa. Utilizza la generazione imminente e i token a bassa confidenza come segnali per recuperare informazioni aggiuntive.

Self-RAG introduce analogamente meccanismi che consentono a recupero, generazione e critica di interagire invece di trattare il recupero come un passaggio di preelaborazione incondizionato.

Adaptive-RAG affronta lo stesso problema più ampio dal punto di vista della complessità della query: domande diverse possono richiedere strategie di recupero diverse.

Questi approcci differiscono tecnicamente. Ma espongono la stessa intuizione architetturale: il recupero dovrebbe essere una decisione, non semplicemente un interruttore permanente.

Presupposti

Il framework Retrieval Trigger presuppone che un sistema abbia accesso ad almeno una fonte di informazioni esterna quando è richiesto il recupero.

Tale fonte potrebbe essere una ricerca web, un archivio di documenti, un database vettoriale, un database SQL, un grafo di conoscenza, un'API, un sistema aziendale, un documento caricato dall'utente o l'output di uno strumento.

Presuppone inoltre che il recupero abbia un costo. Tale costo non deve essere necessariamente finanziario.

Il recupero introduce latenza, consumo di token, utilizzo del contesto, complessità infrastrutturale e la possibilità di recuperare informazioni fuorvianti.

Il sistema ottimale quindi non massimizza il recupero. Massimizza il recupero appropriato.

Variabili

Un Retrieval Trigger pratico può considerare cinque variabili principali.

Freschezza

Quanto è probabile che le informazioni richieste siano cambiate? La capitale della Francia ha una volatilità molto bassa. Il prezzo di un'azione ha una volatilità estremamente alta.

Specificità

La domanda richiede informazioni da una particolare fonte, documento, organizzazione, account o dataset? Se l'utente chiede cosa dice un contratto specifico, la conoscenza generale del modello è irrilevante. Il contratto deve essere recuperato.

Requisito di prova

La risposta necessita di provenienza? Un modello può sapere che un'affermazione è generalmente accettata ma necessita comunque di una fonte quando il compito richiede verifica.

Copertura della conoscenza

È probabile che l'argomento sia rappresentato adeguatamente nella conoscenza interna del modello? Informazioni rare, proprietarie, altamente locali o appena pubblicate creano una maggiore pressione al recupero.

Conseguenza dell'errore

Non ogni risposta errata ha lo stesso impatto. Dove l'accuratezza fattuale influisce materialmente su una decisione, la soglia di prova accettabile può essere più alta.

Queste variabili non devono essere implementate come punteggi numerici letterali. Descrivono la superficie decisionale.

Metodo diagnostico / decisionale

Un Trigger di recupero molto semplice può essere implementato senza machine learning.

def should_retrieve(
    time_sensitive=False,
    source_specific=False,
    evidence_required=False,
    private_context=False,
    knowledge_uncertain=False,
    conflicting_information=False
):
    return any([
        time_sensitive,
        source_specific,
        evidence_required,
        private_context,
        knowledge_uncertain,
        conflicting_information,
    ])

Per una domanda fattuale stabile:

should_retrieve()
# False

Per un prezzo azionario corrente:

should_retrieve(
    time_sensitive=True
)
# True

Per un'affermazione scientifica:

should_retrieve(
    source_specific=True,
    evidence_required=True
)
# True

I sistemi di produzione possono rendere questa decisione molto più sofisticata. Un classificatore potrebbe prevedere i requisiti di recupero. Un modello potrebbe emettere token di controllo speciali. Un router potrebbe classificare la complessità della query. Il recupero potrebbe anche essere attivato ripetutamente durante la generazione.

L'implementazione può cambiare. La questione architetturale rimane la stessa:

Le prove attualmente disponibili al modello sono sufficienti per la risposta che sta per produrre?

Prove

Il concetto qui proposto è coerente con diverse linee di ricerca sul recupero.

L'originale architettura RAG ha dimostrato l'utilità di combinare la conoscenza parametrica del modello con la conoscenza esterna non parametrica, in particolare per compiti ad alta intensità di conoscenza.

FLARE esplora esplicitamente il recupero attivo durante la generazione, incluso il recupero sollecitato da contenuti imminenti a bassa confidenza.

Self-RAG dimostra un'architettura in cui il recupero può avvenire su richiesta ed è seguito da una riflessione sui passaggi recuperati e sul contenuto generato.

Adaptive-RAG sceglie dinamicamente tra diverse strategie in base alla complessità della domanda, incluse situazioni in cui non è richiesto alcun recupero.

Il termine Retrieval Trigger è qui utilizzato come un'astrazione a livello di sistema su questa più ampia famiglia di decisioni.

Non si sostiene che questi articoli utilizzino la stessa terminologia. Invece, identifica il problema architetturale condiviso: cosa causa il passaggio di un sistema di IA dalla conoscenza interna alle prove esterne?

Esempi reali

Considera un assistente di supporto collegato alla documentazione di un'azienda.

"How do I reset my password?"

Se la procedura è stabile e rappresentata in modo affidabile nelle istruzioni attuali dell'assistente, una risposta diretta potrebbe essere appropriata.

"What permissions does my account currently have?"

Quell'informazione è specifica dell'utente e dinamica. Il Trigger di Recupero si attiva. Il sistema deve ispezionare i dati effettivi dell'account o dell'autorizzazione.

"Why was my production deployment rejected yesterday?"

Il modello può comprendere i sistemi di deployment e spiegare le ragioni comuni. Ma la domanda riguarda un evento particolare. Sono richiesti log, output CI/CD o registri di incidenti.

La stessa logica vale per la ricerca web.

"What is RAG?"

Una spiegazione generale potrebbe non richiedere il recupero.

"What did the authors of Self-RAG specifically conclude about unnecessary retrieval?"

Ora è richiesta una prova specifica della fonte.

"What is the latest research on adaptive retrieval?"

Questo introduce anche un requisito di aggiornamento. Il soggetto sottostante non è cambiato. Il requisito informativo sì.

Equivoci comuni e modalità di errore

Più recupero produce automaticamente una risposta migliore. Non è così. I documenti irrilevanti consumano contesto e possono distrarre la generazione.

Un'elevata fiducia del modello significa che il recupero non è necessario. Un modello può produrre una risposta errata con sicurezza. La fiducia auto-riportata non dovrebbe quindi essere trattata come l'unico trigger.

Un recupero riuscito significa che la risposta è verificata. Il recupero fornisce solo prove candidate. Le prove devono comunque essere pertinenti, sufficientemente autorevoli e interpretate correttamente.

Il RAG risolve automaticamente la conoscenza obsoleta. Lo fa solo se il corpus di recupero stesso contiene informazioni aggiornate. Recuperare un documento obsoleto non crea una risposta attuale.

Un singolo passaggio di recupero è sempre sufficiente. Le domande complesse possono richiedere diverse prove o un recupero iterativo.

Casi limite

Alcune domande contengono sia informazioni stabili che instabili.

"Who founded NVIDIA, and what is its market capitalization today?"

La prima parte potrebbe essere risolvibile dalla conoscenza stabile del modello. La seconda parte richiede informazioni attuali.

Un sistema sufficientemente capace non dovrebbe necessariamente trattare l'intera query come un'unica decisione di recupero. Può attivare il recupero solo dove necessario.

Un altro caso limite è il disaccordo tra le fonti. Supponiamo che il recupero restituisca tre documenti che fanno affermazioni incompatibili.

Il Trigger di Recupero ha già avuto successo: il sistema ha riconosciuto che era necessaria un'evidenza esterna. Ma il compito non è finito.

Il sistema ha ora raggiunto un problema di valutazione delle prove. È qui che il Confine di Validità della Risposta diventa importante.

Il sistema potrebbe aver recuperato informazioni e tuttavia non possedere prove sufficienti per giungere a una conclusione solida.

Retrieval Trigger
≠
permission to answer

Il trigger ottiene prove. Il confine di validità determina se tali prove sono sufficienti.

Limitazioni

Il Trigger di Recupero è un quadro concettuale, non un algoritmo universale.

Sistemi diversi richiederanno regole di attivazione diverse. Un bot di assistenza clienti, un assistente di ricerca scientifica, un motore di ricerca e un agente software autonomo non hanno requisiti di evidenza identici.

Le soglie di attivazione possono anche creare le proprie modalità di fallimento. Una soglia troppo bassa causa un recupero eccessivo. Una soglia troppo alta causa risposte non supportate.

Anche l'infrastruttura di recupero stessa è importante. Un trigger perfetto collegato a una scarsa raccolta di fonti produce comunque prove scadenti.

Allo stesso modo, un'eccellente base di conoscenza fornisce poco valore se il trigger non si attiva mai quando è necessario.

Il Trigger di Recupero risolve quindi solo una parte di un'architettura più ampia.

Cosa Cambierebbe Questa Risposta?

I modelli futuri potrebbero contenere meccanismi migliori per identificare i propri limiti di conoscenza. I retriever potrebbero diventare più economici e veloci. I sistemi a contesto lungo potrebbero trasportare continuamente molto più materiale di origine.

I modelli potrebbero anche combinare sempre più spesso ricerca, database, strumenti e conoscenza strutturata senza esporre una fase RAG distinta allo sviluppatore dell'applicazione.

Questi cambiamenti potrebbero alterare il modo in cui il trigger viene implementato. Non eliminano necessariamente la decisione sottostante.

Finché esiste una differenza tra le informazioni già disponibili al modello e le informazioni che devono essere ottenute esternamente, un sistema necessita comunque di un meccanismo per determinare quando superare quel confine.

L'implementazione potrebbe scomparire dalla vista. La questione architetturale rimane.

Conclusione

Il RAG inizia troppo tardi per spiegare l'intero problema.

Prima che il recupero possa avvenire, un sistema di IA deve determinare se il recupero è necessario. Questa decisione è il Trigger di Recupero.

Stable known fact
→ answer from model knowledge

Current fact
→ retrieve

Source-specific or evidence-dependent claim
→ retrieve and verify

Ma l'implicazione più ampia è più importante. Un'IA affidabile non ha semplicemente bisogno di accesso alla conoscenza. Ha bisogno di un metodo per determinare quando la sua conoscenza attuale è insufficiente.

Model Knowledge
        ↓
Retrieval Trigger
        ↓
Runtime Knowledge / RAG
        ↓
Evidence
        ↓
Reasoning
        ↓
Answer Validity Boundary
        ↓
Answer

Il Trigger di Recupero determina quando il sistema dovrebbe cercare prove. Il Confine di Validità della Risposta determina se tali prove sono sufficienti.

Insieme descrivono qualcosa di più utile del solo RAG: un processo decisionale per passare da ciò che un'IA sembra sapere a ciò che può effettivamente supportare.

Fonti Primarie

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). Lavoro fondamentale sul RAG che descrive la combinazione della memoria parametrica del modello con la memoria esterna non parametrica.

Zhengbao Jiang et al., Active Retrieval Augmented Generation (2023). Introduce FLARE e il recupero attivo durante la generazione, incluso il recupero basato su contenuti previsti a bassa confidenza.

Akari Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023). Esplora il recupero adattivo su richiesta e l'autoriflessione invece del recupero fisso incondizionato.

Soyeong Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024). Seleziona dinamicamente tra nessun recupero, recupero a singolo passaggio e strategie di recupero più complesse in base alla domanda in arrivo.