Sintesi Tecnica: Dal RAG Naïve al Deep Agentic Retrieval per la Conformità Regolatoria

1. Dominio del Problema e Motivazione

Il documento affronta l'implementazione di Modelli di Linguaggio di Grandi Dimensioni (LLM) all'interno di settori altamente regolamentati, concentrandosi specificamente sulla necessità di Ontario Power Generation (OPG) di analizzare migliaia di pagine di documenti regolatori per l'Ontario Energy Board (OEB). La sfida principale non è semplicemente rispondere a domande, ma progettare un sistema in grado di recuperare in modo affidabile, efficiente e verificabile il contesto autorevole da un corpus vasto, proprietario e in continua evoluzione.

Gli autori identificano una modalità di fallimento critica nelle implementazioni standard: la Context Rot (decomposizione del contesto). Essi sostengono che la lunghezza del contesto non sia una risorsa gratuita. Man mano che le finestre di contesto si espandono con token irrilevanti, la competizione dell'attenzione degrada la qualità della risposta e i segnali di recupero si indeboliscono. Di conseguenza, l'obiettivo si sposta dal massimizzare il volume grezzo del contesto al massimizzare la densità di evidenza rilevante.

Il documento rifiuta esplicitamente il fine-tuning specifico per il dominio come soluzione primaria per questo caso d'uso. Il fine-tuning è considerato economicamente inadatto per corpora in evoluzione dove la conoscenza si congela al momento dell'addestramento, mentre i documenti regolatori vengono aggiornati frequentemente. Inveve, gli autori sostengono la Context Engineering (ingegneria del contesto): la costruzione deliberata di un contesto di inferenza ad alto segnale attraverso il recupero, il filtraggio e la compressione.

2. Evoluzione Metodologica

Il documento traccia l'evoluzione della pipeline di recupero attraverso tre fasi distinte, ciascuna motivata dalle modalità di fallimento della iterazione precedente.

Stadio I: Baseline RAG Naïve

• Architettura: Una pipeline standard che prevede OCR/estrazione strutturata, chunking (500–800 token), embedding e recupero ibrido (vettore denso + parola chiave) con re-ranking tramite cross-encoder.
• Limitazioni: Il sistema è deterministico e stateless. Se il recupero iniziale non riesce a far emergere i chunk rilevanti a causa di un disallineamento del vocabolario o di dipendenze multi-hop, l'LLM non può autocorreggersi. L'unica mitigazione è aumentare il numero di chunk recuperati ($k$), il che aumenta linearmente costo e latenza, esacerbando la context rot.
• Risultato: Sebbene funzionale per ricerche semplici, manca della flessibilità necessaria per gestire query regolatorie complesse e multi-hop.

Stadio II: Agentic Retrieval tramite Function Calling

• Architettura: L'LLM transita da consumatore passivo a recuperatore attivo. È dotato di uno strumento di ricerca e riformula iterativamente le query in base ai risultati intermedi (pseudo-relevance feedback).
• Meccanismi Chiave:
  • Scoperta Progressiva: L'agente emette molteplici chiamate a strumenti con query raffinate, restringendo lo spazio di ricerca utilizzando filtri di metadati (es. ID specifici di allegati o anni di casi tariffari).
  • Escalation Chunk-to-Document: Viene introdotta una regola decisionale per scalare dal recupero a livello di chunk alla lettura del documento completo solo quando il guadagno di evidenza atteso ($\Delta U$) giustifica la latenza aggiuntiva ($\Delta T$) e il costo ($\Delta C$).
  • Partizionamento delle Capacità: Per soddisfare i vincoli di residenza dei dati canadesi, i contenuti visivi (grafici/diagrammi) che richiedono l'inferenza visiva vengono delegati a un modello ospitato in Canada, mentre l'agente di ragionamento principale rimane separato.
• Limitazioni: Il function calling introduce un overhead dello schema JSON. Nei casi peggiori, con molte query di bassa qualità, il consumo di token può superare la baseline dello Stadio I.

Stadio III: Deep Agentic Retrieval (PEA-CAE)

• Architettura: Un sistema maturo caratterizzato da pianificazione esplicita, delega a sub-agenti gerarchici e sintesi di strumenti basata su codice.
• Meccanismi Chiave:
  • Pianificazione Esplicita: L'agente decompone query complesse in una sequenza di sotto-domande prima che inizi il recupero, memorizzando le scoperte intermedie in una memoria di lavoro.
  • Sub-agenti Gerarchici: Per prevenire la context rot nelle lunghe catene di ragionamento, l'agente principale genera sub-agenti per compiti subordinati delimitati. I sub-agenti eseguono una ricerca approfondita e restituiscono solo riassunti compressi, impedendo agli artefatti di recupero intermedi di consumare la finestra di contesto dell'agente principale.
  • Sintesi di Strumenti Basata su Codice: Invece di funzioni JSON predefinite, l'agente scrive codice Python/Bash a runtime per interagire con le API ed elaborare i dati. Questo ammortizza l'overhead degli strumenti e permette l'espressività combinatoria senza un limite fisso di strumenti.
  • Framework PEA-CAE: Il sistema è formalizzato come Progressive Evidence Acquisition with Cost-Aware Escalation (Acquisizione Progressiva di Evidenze con Escalation Consapevole dei Costi). Esso impone regole per filtrare prima, comprimere precocemente, scalare tardivamente e comprimere la portata.

3. Contributi Principali

Il documento presenta cinque contributi primari:

1. Caratterizzazione Algoritmica: Un'analisi stadio per stadio di tre architetture di recupero implementate in produzione, collegando specifiche modalità di fallimento alle transizioni architettoniche.
2. Framework Formale (PEA-CAE): Una formalizzazione della politica di recupero matura che bilancia l'acquisizione di evidenze con i vincoli di costo e latenza.
3. Analisi Empirica: Dati di traccia operativa che dimostrano i compromessi tra l'utilizzo della finestra di contesto, la precisione del recupero e la frequenza di escalation.
4. Pattern di Sovranità dei Dati: Una strategia di partizionamento delle capacità per implementazioni multi-giurisdizione, separando l'elaborazione visiva (ospitata localmente) dal ragionamento generale.
5. Connessione Teorica: Un'analisi comparativa che collega il design pratico del sistema (riformulazione adattiva delle query, scoperta progressiva dei documenti) alle teorie classiche del recupero dell'informazione e del information foraging.

4. Risultati e Osservazioni

In base alle tracce operative del sistema Stage III (Deep Agent):

• Tasso di Successo: In un campione di 14 esecuzioni, tutte le 6 esecuzioni agentiche dell'OEB sono state completate con successo.
• Latenza: La durata dei task variava da 24,8 secondi a 223 secondi (mediana 92,1s), riflettendo un ciclo di ricerca sostenuto piuttosto che una singola ricerca rapida.
• Efficienza di Escalation: Il sistema ha dimostrato un rapporto ricerca-escalation di circa 9,6:1. L'estrazione del documento completo è avvenuta solo in circa il 10% degli eventi di recupero, confermando l'intento di design della "selezione dell'escalation".
• Varianza della Latenza: L'estrazione del documento completo ha mostrato un'alta latenza nella coda (tail latency) fino a 12,14s, rafforzando la necessità di mantenere l'escalation selettiva per evitare il degrado delle prestazioni.

5. Significatività e Rivendicazioni

Il documento sostiene che, per grandi corpora regolatori in evoluzione, la context engineering è un percorso più trattabile ed economicamente sostenibile rispetto al fine-tuning specifico per il dominio. L' "intelligenza" del sistema non risiede nei pesi del modello, ma negli algoritmi che costruiscono finestre di contesto ad alto segnale.

Gli autori argomentano che la progressione dal RAG naïve al deep agentic retrieval rispecchia le idee classiche del recupero dell'informazione, introducendo primitive pratiche di sistema quali:

• Riformulazione adattiva delle query.
• Scoperta progressiva dei documenti.
• Riassunto gerarchico dei sub-agenti.

La tesi centrale è che il contesto rimane una risorsa scarsa anche all'aumentare delle dimensioni nominali delle finestre. Pertanto, la strategia ottimale è di recuperare progressivamente, scalare selettivamente e comprimere aggressivamente. Il documento conclude che il successo operativo nell'IA regolata dipende meno dall'adattamento del modello e più dalla gestione congiunta della qualità del recupero, dell'overhead degli strumenti, della latenza e della crescita del contesto.