Perché i tuoi agenti AI hanno bisogno di un terminale, non solo di un database vettoriale

Quando un flusso di lavoro agentico fallisce, i developer tendono a dare la colpa alla capacità di ragionamento del modello sottostante. In molti casi, però, il vero collo di bottiglia è il sistema di retrieval: le informazioni che arrivano all’agente sono incomplete o mal contestualizzate.

Un team di ricercatori di più università ha proposto una tecnica chiamata direct corpus interaction (DCI) che aggira del tutto i modelli di embedding. L’agente interagisce direttamente con i file raw usando strumenti da terminale: grep, find, awk, sed. Niente database vettoriali, niente chunking preventivo, niente similarità semantica.

Il problema del retrieval classico

Nei sistemi RAG tradizionali, i documenti vengono suddivisi in chunk, convertiti in vettori (embedding) e indicizzati offline in un database vettoriale. Quando arriva una query, un retriever filtra l’intero database e restituisce una lista top-k di snippet ordinati per similarità semantica. Tutte le prove devono passare attraverso quel meccanismo di scoring prima che l’agente possa ragionare.

Ma le applicazioni agentiche moderne richiedono molto di più. “Il retrieval denso è molto utile per il richiamo semantico generico, ma quando un agente deve risolvere un compito multi-step, spesso ha bisogno di cercare stringhe esatte, numeri, versioni, codici di errore, percorsi file o combinazioni di indizi sparsi”, spiegano gli autori del paper. “Questi dettagli di coda lunga sono esattamente il punto in cui la similarità semantica diventa fragile.”

Un agente deve anche rivedere la sua strategia di ricerca dopo aver osservato prove parziali. Vincoli lessicali esatti e raffinamento di ipotesi in più passaggi sono difficili da eseguire con i retriever semantici. Il problema è strutturale: il retriever comprime l’accesso in un solo passaggio. Se una prova critica viene filtrata dalla ricerca di similarità, non può essere recuperata in un secondo momento, indipendentemente da quanto sia avanzata la capacità di ragionamento dell’agente.

Direct corpus interaction: come funziona

DCI affronta anche un problema concreto negli ambienti enterprise: la freschezza dei dati. Gli indici di embedding sono sempre un’istantanea di un momento specifico, richiedono tempo e calcolo per essere costruiti e mantenuti. “In molti contesti aziendali, i dati non sono una collezione stabile di documenti. Sono report finanziari giornalieri, log live, ticket, commit di codice, file di configurazione, cronologie di incidenti e documenti interni che cambiano continuamente”, dicono i ricercatori.

Nell’approccio DCI, l’agente opera in un ambiente simile a un terminale: le sue osservazioni sono output grezzi di strumenti — percorsi file, frammenti di testo corrispondenti, righe circostanti. I comandi a disposizione sono pochi ma espressivi: find e glob per navigare directory, grep e rg per match esatti, head, tail, cat per ispezione locale. L’agente può combinare questi strumenti in pipeline shell per eseguire logiche di ricerca complesse in un solo comando: cercare un termine in un file e passare l’output a un secondo filtro, combinare indizi deboli su più file, verificare immediatamente un’ipotesi leggendo le righe intorno a un match.

I ricercatori propongono due versioni del sistema. DCI-Agent-Lite è la versione leggera, basata su GPT-5.4 nano, limitata a interazioni raw con bash e letture di file. DCI-Agent-CC è la versione ad alte prestazioni, basata su Claude Code con Claude Sonnet 4.6, che offre strumenti di orchestrazione più robusti.

I risultati dei test

I ricercatori hanno testato DCI su benchmark come BrowseComp-Plus, QA single-hop e multi-hop, e fact-checking scientifico. Su BrowseComp-Plus, passare da un retriever semantico Qwen3 a DCI su Claude Sonnet 4.6 ha migliorato l’accuratezza dal 69% all’80%, riducendo il costo API da 1.440 a 1.016 dollari. DCI-Agent-Lite con GPT-5.4 nano ha gareggiato con il modello o3 di OpenAI (con retrieval tradizionale) tagliando i costi di oltre 600 dollari.

DCI ha una recall documentale complessiva inferiore rispetto ai modelli di embedding densi, ma quando trova un documento rilevante, ne estrae molto più valore. “Se un responsabile AI aziendale mi chiedesse dove DCI è più utile, indicherei compiti che richiedono una localizzazione esatta delle prove in un workspace dinamico: debug di incidenti di produzione, ricerca su grandi codebase, analisi di log, indagini di compliance, audit trail, analisi di causa radice multi-documento”, spiegano i ricercatori.

In un task complesso di deep research, l’agente doveva identificare una partita di calcio specifica basandosi su 12 indizi incrociati: spettatori esatti, cartellini gialli, date di nascita dei giocatori. Un retriever tradizionale avrebbe fallito restituendo snippet scollegati. L’agente DCI ha esplorato la directory, letto righe specifiche del report della partita Inghilterra-Belgio del 1990 per verificare il numero esatto di sostituzioni, estratto una citazione da un file di intervista e verificato le date di nascita di due giocatori leggendo i loro file Wikipedia.

Limiti e implementazione pratica

DCI ha un ambito operativo chiaro: scala bene in profondità di ricerca ma fatica in ampiezza. Quando il corpus sperimentale è passato da 100.000 a 400.000 documenti, l’accuratezza è calata significativamente e il numero medio di chiamate agli strumenti è aumentato. Il costo per localizzare un documento iniziale utile cresce rapidamente all’aumentare dello spazio candidato. Inoltre, DCI ha una recall documentale più bassa rispetto ai sistemi densi: trova meno documenti in totale, ma da quelli che trova estrae più informazioni utili.