La discussione tra "grep versus embeddings" ha diviso gli ingegneri dell'intelligenza artificiale per l'ultimo anno. Un campo sostiene di lasciare che l'agente legga i file direttamente. L'altro sostiene di pre-indicizzare tutto in un database vettoriale. Secondo George He, head of engineering di LlamaIndex, tutta la lite si basa su una premessa falsa.
«Dai al tuo agente gli strumenti necessari per cercare attraverso file specifici usando il tuo vecchio grep, cat, filtro per nome del file o filtro per metadati, oltre al filtro semantico», ha detto He, parlando nel podcast AI Engineer. «E in quel modo puoi ottenere il meglio di entrambi i mondi».
Il fattore decisivo: la scala
La variabile decisiva non è l'ideologia. È la scala — specificamente, quanti dati stai gestendo e quanta cura sei disposto a spendere per mantenere un sistema di recupero vivo.
Claude Code di Anthropic è spesso citato come prova che gli agenti non hanno bisogno affatto di embeddings. Il team ha scelto l'attraversamento del file system locale — grep, lettura, gestione glob — al posto di un database vettoriale. He cita un tweet di Boris, creatore di Claude Code, che conferma che il team ha sperimentato con un database vettoriale e lo ha scartato, non per motivi di prestazioni ma per problemi pratici di scalabilità e manutenzione. Mantenere sincronizzato un indice vettoriale pre-indicizzato è difficile quando il codice continua a cambiare.
Ma He è cauto su ciò che questo prova davvero. Funziona grazie alle caratteristiche specifiche del codice: i repository sono di solito piccoli, semi-strutturati e pieni di traccianti — import, test, gerarchia naturale — e il codice è già sul disco, in locale. «Allora perché complicare tutto con un sistema di pre-recupero?», chiede.
Dati aziendali vs codice
I dati aziendali sono diversi. I set di dati aziendali mischiano immagini, PDF e PowerPoint. Non c'è una cartella da grep perché i dati non sono organizzati come il codice. Il codice è curato — sintatticamente corretto, correttamente referenziato — mentre un data lake aziendale è difficile da mantenere sincronizzato, opera a una scala completamente diversa e porta con sé domande di sicurezza e accesso. Aggiungi formati non standardizzati come PDF complessi, schemi e diagrammi di fabbricazione, e l'esecuzione locale diventa impossibile.
Esistono soluzioni di emergenza per imporre gerarchia a questo caos — server MCP, Claude MD di Anthropic, skill MCP, file agente, file di istruzioni — ma sono cerotti, non architetture.
Finestre di contesto e costi
Il controargomento è ovvio: se le finestre di contesto continuano a crescere, perché preoccuparsi di un'infrastruttura di recupero? Le lunghezze del contesto sono salite da ben sotto i 100k a 200k a 1 milione di token. Ma la domanda reale, sostiene He, è quanto sei disposto a pagare. Inserire token nel flusso di elaborazione del modello — o inviare dati binari al modello per renderizzarli ed estrarre — diventa estremamente costoso a quella scala.
Sub-agenti sono una soluzione parziale. Un agente più grande emette sotto-comandi in modo che un agente più piccolo assorba il gonfiore della memoria e restituisca una risposta. Claude Code lo fa — la sessione principale emette a volte comandi a sessioni secondarie di modelli più deboli. Ma ogni sub-agente ha comunque bisogno del contesto completo, quindi anche con modelli più economici, gli ambienti sono pesanti per i token e per la latenza. La conclusione è secca: se vuoi evitare di riprocessare documenti ogni singola volta, costruisci un sistema di pre-indicizzazione.
«Ma quando esci a scala di migliaia o milioni di file, non è possibile», ha detto He. «Non vuoi bruciare quei token. Non vuoi leggere i file ogni singola volta».
Architettura ibrida e strumenti
L'architettura proposta da He rimuove la decisione architettonica dal progettista del sistema e la consegna all'agente. Invece di codificare a hard se utilizzare RAG ibrido o attraversamento grezzo dei file, dai all'agente entrambe le famiglie di strumenti e lascialo scegliere per query. Il sistema ha cinque componenti:
- Strumenti di indicizzazione e pre-elaborazione
- Strumenti di recupero ibrido (ricerca semantica e parole chiave)
- Strumenti di parsing strutturato e markdown
- Strumenti di valutazione e monitoraggio
- Strumenti di gestione dell'autenticazione e dei permessi
Gli strumenti 2 attraverso 4 possono essere eseguiti in un flusso pre-emptivo o in un flusso live. L'agente inizia senza conoscere i metadati o il contenuto estratto del sistema. Attraversa la gerarchia dei file, cerca file simili all'interno del corpus che non sono stati restituiti nella ricerca iniziale per espandersi verso l'esterno, poi restringe.
Questo è importante in particolare in un file system distribuito condiviso che non vuoi scaricare nel contesto dell'agente ogni volta, il che costa caro. Con primitive stile grep, l'agente può estrarre una finestra di testo mirata — diciamo, un offset di 500 caratteri e i successivi 1.000 caratteri — invece di caricare l'intero documento.
«Puoi interagire con un effettivo archivio file remoto senza dover avviare o scaricare tutti i dati che devono essere streamizzati nel tuo sistema», ha notato He.
Ricerca ibrida e riordinamento
Sul lato del recupero, He esplora il panorama — graph RAG, RAG tradizionale e vecchia scuola ricerca basata su parole chiave BM25 — e si ferma su ibrido per i casi d'uso aziendali. La ricerca per parole chiave ha un posto per gli sviluppatori e per gli agenti AI che cercano parole chiave specifiche pre-indicizzate in un corpus. Ha senso anche il significato semantico e la similarità. Combinare e pesare entrambi attraverso la fusione produce risultati migliori sui set di benchmark perché non sei cieco rispetto alle specificità di un metodo di ricerca.
Il riordinamento dei risultati finali è dove si ottengono i veri guadagni. He consiglia di prendere i primi 100 risultati di recupero e riordinarli con un LLM o un processo più profondo. Il passo di recupero ti porta nel vicinato; il riordinamento lo trasforma in un indirizzo.
Ma He è esplicito nel dire che il recupero è solo una parte del flusso di lavoro: «Quello è la ricerca dei documenti. Ci preoccupiamo dei risultati».
Documenti complessi e parsing strutturato
I documenti complessi rompono l'indicizzazione tradizionale e il chunking perché grafici, pagine scansionate e schemi non sono linee di testo leggibili dall'uomo — sono rappresentazioni separate. Non vuoi bruciare token codificati in binario rileggendo documenti ogni volta.
LlamaIndex raccomanda la pre-indicizzazione o il pre-parsing con un flusso di parsing strutturato. Il prodotto commerciale è LlamaParse; l'opzione open source è LiteParse per l'estrazione di contenuto strutturato. Tabelle, grafici e informazioni segmentate dovrebbero essere codificati come markdown o qualcosa che l'agente può ragionare spazialmente, perché il ragionamento spaziale è importante per i dati multimodal. Nel flusso di pre-parsing, dovresti anche generare e persistere gli screenshot mentre le pagine vengono renderizzate — non è sempre chiaro se qualcosa è testo o trasporta metadati, quindi combini entrambi.
He promuove la distribuzione e la scalatura del flusso di parsing con metriche di valutazione concrete. Se getti dati in un pipeline OCR tradizionale come Amazon Textract o usi un motore come Tesseract, cattura la rappresentazione della tabella? Quanto è fedele al layout del contenuto reale? Ottenerli sbagliati significa che la lettura semantica dell'LLM paga più tardi. Potrebbe funzionare bene all'inizio, ma se l'LLM non comprende la posizione e il ragionamento spaziale, crolla in un punto.
Caveat: Molti-tenant e Freschezza
I caveat che He nomina per i clienti reali sono raramente glamour ma costantemente letali. Il multi-tenant viene per primo: una persona può vedere i dati di un'altra persona e come i metadati di autorizzazione vengono estratti? Se usi Google Drive o SharePoint, come sincronizzi quei metadati di autorizzazione senza mandare il sistema al macero o ri-indicizzando e riprocessando ogni volta?
La freschezza è il problema correlato. He è inusualmente candidato su questo: «Questo è il motivo per cui Anthropic, molte altre aziende, hanno quasi rinunciato a provare a pre-indicizzare i dati perché la freschezza dei dati è davvero difficile da raggiungere se i tuoi dati sono complessi».
Architettura di archiviazione
Sull'archiviazione, He raccomanda un sistema a strati. Molti servizi di archiviazione vettoriale mantengono tutto in memoria, costringendo a un compromesso tra disco-plus-ricarica-in-memoria-veloce e tutto-in-memoria. LlamaIndex ha affrontato questo a livello di multi-tenant tra milioni e decine di milioni di documenti.
«La nostra raccomandazione qui è provare a persistere i dati su disco e poi avere uno strato di memoria protetta al fine di recuperare i dati in modo più efficiente», ha detto He.
Per la demo, LlamaIndex usa Turbopuffer, che — come la maggior parte dei database vettoriali — gestisce anche l'autenticazione. Il filtro per metadati viene spinto nel livello di archiviazione vettoriale e etichettato mentre i dati vengono ingeriti. Con troppi documenti, filtrare per metadati non è opzionale; è l'unico modo per rendere il recupero funzionante.
La prova di concetto gira su un set di 135 file pre-indicizzati derivato da un set di dati di ricerca di Yahoo News. Il sistema esegue una ricerca ibrida con una query semantica di "top 5 news stories about the economy" e filtra per metadati per la fonte. Il sistema recupera e riordina i risultati, estrae le parti pertinenti dal testo e le invia al modello per una risposta sintetica. He ha mostrato che il sistema può filtrare per metadati su oltre 2 milioni di documenti in meno di un secondo.