Avete presente quando cercate un dettaglio sepolto in anni di chat: la data in cui un amico aveva detto che avrebbe traslocato, il nome del ristorante nominato una volta sola. Ci sono due modi. Il primo: vi ricordate una parola esatta che era stata scritta e la cercate con il «trova nella pagina», lo strumento più stupido e più letterale che esista. Il secondo: descrivete il senso di quello che cercate a qualcuno che capisce cosa intendete e lo lasciate rovistare per significato. Per anni il campo dell’AI ha trattato il secondo metodo — la ricerca semantica per vettori — come la scelta ovvia, quella sofisticata. Un gruppo di ricercatori di PricewaterhouseCoopers, con un titolo che strizza l’occhio a Attention Is All You Need, ha fatto la domanda scomoda: e se il metodo stupido, il vecchio grep dei terminali Unix, fosse tutto quello che serve?
Cosa mette in discussione
Nei sistemi RAG — quelli che danno a un modello linguistico una memoria esterna da consultare — la ricerca vettoriale è diventata l’impostazione di default. Il paper non si limita a rimettere grep contro i vettori. La sua mossa vera è un’altra: sostenere che un metodo di ricerca non si può giudicare in provetta. In un agente reale la ricerca non è un componente isolato. Vive dentro un harness, l’impalcatura che costruisce il prompt, chiama gli strumenti, riceve i risultati e decide quando smettere di cercare. E i risultati vengono restituiti al modello in modi diversi: versati direttamente nel contesto, oppure scritti in un file che l’agente deve aprire da solo. La tesi degli autori è che metodo di ricerca, harness e modo di consegna non sono tre scelte indipendenti: sono un’unica macchina, e vanno valutati insieme.
Grep, vettori e il banco che li ospita
Le due famiglie di ricerca partono da filosofie opposte. La ricerca lessicale — grep, le espressioni regolari, l’algoritmo BM25 — cerca corrispondenze esatte o di pattern nel testo grezzo. Non serve nessun modello di embedding, nessun indice vettoriale: si scansiona il testo e si contano le occorrenze. È l’etichetta sul dorso del libro: o la parola c’è, o non c’è. La ricerca semantica, o densa, trasforma invece query e documenti in vettori in uno spazio condiviso e recupera i più vicini per significato. È il bibliotecario che coglie il senso della richiesta anche se non avete usato le parole esatte.
Il paper è uno studio empirico e non scrive le formule, ma le due famiglie che confronta si riducono a due regole di selezione ben note. La ricerca densa sceglie il documento il cui vettore è più vicino a quello della query, tipicamente per similarità del coseno:
$$\hat{d} \;=\; \arg\max_{d \in \mathcal{C}} \; \cos\!\big(\mathbf{e}_q,\, \mathbf{e}_d\big)$$
La ricerca lessicale, nella sua versione con punteggio BM25, pesa invece la frequenza dei termini della query nel documento, corretta per la loro rarità nel corpus e per la lunghezza del testo:
$$\text{BM25}(q,d)=\sum_{t\in q}\text{IDF}(t)\cdot\frac{f(t,d)\,(k_1+1)}{f(t,d)+k_1\!\left(1-b+b\,\dfrac{|d|}{\overline{|d|}}\right)}$$
Grep, nella sua forma più cruda, è ancora più semplice: la corrispondenza c’è o non c’è. La prima regola premia il significato ma ammette «falsi amici» che condividono l’argomento; la seconda premia la precisione letterale ma è fragile davanti a un sinonimo mai indovinato.
Sopra queste due regole sta l’harness. Gli autori distinguono due classi. Da un lato l’harness personalizzato: il loro si chiama Chronos, è costruito su LangChain, usa un prompt che si adatta alla categoria della domanda e controlla ogni dettaglio del ciclo. Dall’altro gli harness CLI nativi dei provider — Claude Code di Anthropic, Codex di OpenAI, Gemini CLI di Google — dove il modello ha accesso diretto a una shell e può invocare grep come un normale comando di sistema, ma dove la costruzione del contesto è in gran parte opaca. Infine il modo di consegna: inline, con i risultati riversati nel contesto (comodi ma capaci di intasare la finestra, il fenomeno che gli autori chiamano context rot), oppure programmatico, con i risultati scritti su file che l’agente deve aprire con un’azione in più. Quest’ultima modalità libera spazio nel contesto, ma trasforma ogni risultato in un mini-workflow che il modello deve saper portare a termine.
Le tre leve non sono indipendenti. Il metodo di ricerca conta, ma l’harness e il modo di consegna possono spostare il risultato di quanto lo sposta il cambio di metodo. Numeri reali dalla Tabella 1 del paper.
Cosa dicono i numeri
Il banco di prova è un sottoinsieme di 116 domande di LongMemEval, un benchmark che misura la capacità di rispondere su conversazioni lunghe distribuite su molte sessioni, con sei categorie di compito (aggiornamento di uno stato nel tempo, aggregazione tra sessioni, preferenze dell’utente, fatti dichiarati, ragionamento temporale, e richiamo di contenuti generati dall’assistente). A giudicare le risposte è un modello ausiliario, GPT-4o. I modelli valutati sono cinque: Claude Opus 4.6, Claude Haiku 4.5, GPT-5.4, Gemini 3.1 Pro e Gemini 3.1 Flash-Lite.
Il primo esperimento incrocia strategia, harness e consegna. Con la consegna inline il risultato è netto: grep batte i vettori per ogni coppia di harness e modello. Il margine più ampio è su Chronos con Gemini 3.1 Flash-Lite (86,2% contro 62,9%), il più stretto su Claude Code con Claude Opus 4.6 (76,7% contro 75,0%). Ma il dato più eloquente non riguarda il metodo: lo stesso Claude Opus 4.6, con la stessa strategia grep inline, ottiene 93,1% sotto Chronos e 76,7% sotto Claude Code. Cambiare harness sposta il tetto di prestazione più o meno quanto lo sposta cambiare metodo di ricerca a parità di harness. Codex con GPT-5.4 eguaglia il miglior grep inline di Chronos (93,1%), mentre lo stesso Codex sui vettori si ferma al 75,9%.
Poi arriva il colpo di scena. Quando i risultati non vengono più versati inline ma scritti su file, la classifica si scompiglia: i vettori superano grep in cinque coppie su dieci. La regressione più violenta è Codex con GPT-5.4, che precipita dal 93,1% del grep inline al 55,2% del grep su file. Non è cambiato l’indice né il testo: è cambiato solo il percorso di consegna. La lezione degli autori è asciutta: la ricerca a basso costo — un’espressione regolare su un file JSON locale — non è «facile» da un capo all’altro se l’harness la trasforma in un workflow a più passi che lo stack esegue in modo inaffidabile. Il modello più debole del lotto, Claude Haiku 4.5 su Claude Code, mostra un divario particolarmente marcato tra grep e vettori (55,2% contro 44,0% inline), coerente con l’idea che i modelli meno capaci fatichino di più nel raffinamento iterativo delle query.
Il rumore, e perché non rompe
Il secondo esperimento aggiunge disturbo. A ogni domanda si affiancano sessioni-distrattore irrilevanti, in quantità crescente: cinque, dieci, venti, trenta, fino all’intero pagliaio (da 39 a 66 sessioni per domanda). L’intuizione diffusa tra i praticanti dice che la ricerca lessicale regge sui corpus piccoli ma crolla su scala, dove servirebbe la semantica. I dati la confermano solo a metà. Entrambi i metodi degradano poco all’aumentare del rumore, e in media grep resta davanti. Ma il punto di sorpasso tra i due dipende dall’harness e dal modello, non dalla dimensione del corpus. Le curve non sono nemmeno monotone: Claude Code con Opus tocca il picco a venti sessioni (95,7%) e chiude al 94,0% sull’intero pagliaio. E si vedono pregiudizi stabili introdotti dagli strumenti del provider: Claude Code preferisce grep per Opus e Haiku in ogni configurazione, mentre Gemini CLI preferisce i vettori per Gemini 3.1 Pro dappertutto, con il divario che si allarga fino a 89,7% contro 78,5% sull’intero pagliaio.
Migrare tra due CLI non è «intercambiabile per il recupero» anche quando il corpus su disco è identico byte per byte. Il grep di produzione non è mai un solo primitivo: è grep più shell più prompting.
I limiti, dichiarati
Gli autori sono onesti sul perimetro. Le loro conclusioni sono legate a un compito preciso: domande su conversazioni multi-sessione, dove la risposta corretta poggia quasi sempre su frammenti letterali — date esatte, conteggi, preferenze, nomi. Grep vince perché su questo terreno la precisione letterale è un vantaggio. In domini dove l’evidenza è raramente letterale — la sintesi scientifica su abstract parafrasati, i documenti ricchi di immagini, la semantica del codice — il recupero denso o ibrido potrebbe raccontare tutt’altra storia. Il paper lo scrive a chiare lettere: non si sostiene che grep «batta» i vettori in generale, solo che può vincere da un capo all’altro sotto la distribuzione di compiti studiata. Restano poi buchi nella griglia sperimentale — le righe intermedie di Codex sui vettori e la scalatura del grep di Codex sono incomplete — e il giudice stesso è un modello linguistico, con i limiti che questo comporta.
Perché conta
La tentazione è leggerlo come «grep buono, vettori cattivi». Sarebbe il messaggio sbagliato. Il contributo del paper è metodologico: in un sistema agentico il recupero non è un componente che si possa mettere alla prova da solo su un banco. Il metodo di ricerca, l’harness che lo orchestra e il modo in cui i risultati tornano al modello formano un’unica macchina, e sullo stesso corpus l’accuratezza può oscillare dal 33% al 93% a seconda di come la si assembla. Per chi costruisce agenti, la conseguenza pratica è netta: misurare l’intero ciclo, non il solo retriever, e diffidare dei confronti da classifica che mettono BM25 contro i vettori in una pipeline statica, perché sottostimano la varianza che l’impalcatura introduce. E c’è una lezione più modesta, quasi controcorrente in un settore che promette sempre qualcosa di più elaborato: a volte lo strumento noioso, quello che c’era già nei terminali degli anni Settanta, è quello che serve. Ma solo nel telaio giusto.
Il paper
Sahil Sen, Akhil Kasturi, Elias Lumer, Anmol Gulati, Vamse Kumar Subbiah (PricewaterhouseCoopers, U.S.), Is Grep All You Need? How Agent Harnesses Reshape Agentic Search, arXiv:2605.15184, maggio 2026. Disponibile su arXiv: arxiv.org/abs/2605.15184.
I commenti sono riservati agli iscritti.
Accedi per commentare