Un nuovo framework open supply chiamato IndicePagina risolve uno dei vecchi problemi della retrieval-augmented era (RAG): gestire documenti molto lunghi.
Il classico flusso di lavoro RAG (documenti in blocchi, calcolo degli incorporamenti, archiviazione in un database vettoriale e recupero delle principali corrispondenze in base alla somiglianza semantica) funziona bene per attività di base come domande e risposte su documenti di piccole dimensioni.
PageIndex abbandona completamente il metodo commonplace “chunk-and-embed” e tratta il recupero dei documenti non come un problema di ricerca, ma come un problema di navigazione.
Ma mentre le aziende cercano di spostare RAG in flussi di lavoro advert alto rischio (revisione di rendiconti finanziari, analisi di contratti legali, navigazione nei protocolli farmaceutici), stanno colpendo una barriera di precisione che l’ottimizzazione dei blocchi non può risolvere.
AlphaGo per i documenti
PageIndex affronta queste limitazioni prendendo in prestito un concetto dall’intelligenza artificiale dei videogiochi piuttosto che dai motori di ricerca: la ricerca advert albero.
Quando gli esseri umani hanno bisogno di trovare informazioni specifiche in un libro di testo denso o in un lungo rapporto annuale, non scansionano ogni paragrafo in modo lineare. Consultano l’indice per individuare il capitolo interessato, poi la sezione ed infine la pagina specifica. PageIndex costringe il LLM a replicare questo comportamento umano.
Invece di precalcolare i vettori, il framework costruisce un “indice globale” della struttura del documento, creando un albero in cui i nodi rappresentano capitoli, sezioni e sottosezioni. Quando arriva una question, LLM esegue una ricerca nell’albero, classificando esplicitamente ciascun nodo come rilevante o irrilevante in base al contesto completo della richiesta dell’utente.
“In termini informatici, un sommario è una rappresentazione strutturata advert albero di un documento e la sua navigazione corrisponde alla ricerca nell’albero”, ha affermato Zhang. “PageIndex applica la stessa thought di base – la ricerca advert albero – al recupero dei documenti e può essere pensato come un sistema in stile AlphaGo per il recupero piuttosto che per i giochi.”
Ciò sposta il paradigma architettonico dal recupero passivo, in cui il sistema recupera semplicemente il testo corrispondente, alla navigazione attiva, in cui un modello di agente resolve dove guardare.
I limiti della somiglianza semantica
C’è un difetto fondamentale nel come RAG tradizionale gestisce dati complessi. Il recupero dei vettori presuppone che il testo semanticamente più simile alla question di un utente sia anche il più rilevante. Negli ambiti professionali, questo presupposto spesso crolla.
Mingtian Zhang, co-fondatore di PageIndex, indica il reporting finanziario come un ottimo esempio di questa modalità di fallimento. Se un analista finanziario chiede a un’IA informazioni sull'”EBITDA” (utili prima di interessi, tasse, svalutazioni e ammortamenti), un database vettoriale commonplace recupererà ogni parte in cui appare quell’acronimo o un termine simile.
“Più sezioni possono menzionare l’EBITDA con una formulazione simile, ma solo una sezione definisce il calcolo preciso, gli aggiustamenti o l’ambito di reporting rilevante per la domanda”, ha detto Zhang a VentureBeat. “Un retriever basato sulla somiglianza fatica a distinguere questi casi perché i segnali semantici sono quasi indistinguibili.”
Questo è il divario “intento vs contenuto”. L’utente non vuole trovare la parola “EBITDA”; vogliono capire la “logica” che sta dietro a ciò per quel trimestre specifico.
Inoltre, gli incorporamenti tradizionali privano la question del suo contesto. Poiché i modelli di incorporamento hanno limiti rigorosi di lunghezza di enter, il sistema di recupero di solito vede solo la domanda specifica posta, ignorando i turni precedenti della conversazione. Ciò separa la fase di recupero dal processo di ragionamento dell’utente. Il sistema abbina i documenti a una question breve e decontestualizzata anziché alla cronologia completa del problema che l’utente sta cercando di risolvere.
Risolvere il problema del ragionamento multi-hop
L’impatto nel mondo reale di questo approccio strutturale è più visibile nelle question “multi-hop” che richiedono all’intelligenza artificiale di seguire una scia di breadcrumb attraverso numerous parti di un documento.
In un recente take a look at di benchmark noto come FinanceBench, un sistema basato su PageIndex chiamato “Mafin 2.5” ha ottenuto un punteggio di precisione all’avanguardia del 98,7%. Il divario prestazionale tra questo approccio e i sistemi basati su vettori diventa chiaro quando si analizza il modo in cui gestiscono i riferimenti interni.
Zhang offre l’esempio di una question riguardante il valore totale delle attività differite in un rapporto annuale della Federal Reserve. La sezione principale del rapporto descrive la “variazione” del valore ma non elenca il totale. Tuttavia, il testo contiene una nota a piè di pagina: “Vedi Appendice G del presente rapporto… per informazioni più dettagliate”.
Un sistema basato su vettori in genere fallisce qui. Il testo nell’Appendice G non assomiglia per niente alla question dell’utente sulle attività differite; probabilmente è solo una tabella di numeri. Poiché non esiste alcuna corrispondenza semantica, il database vettoriale la ignora.
Il retriever basato sul ragionamento, tuttavia, legge lo spunto nel testo principale, segue il collegamento strutturale all’Appendice G, individua la tabella corretta e restituisce la figura accurata.
Il compromesso tra latenza e il cambiamento delle infrastrutture
Per gli architetti aziendali, la preoccupazione immediata di un processo di ricerca basato su LLM è la latenza. Le ricerche dei vettori avvengono in millisecondi; avere un LLM “leggere” un sommario implica un’esperienza utente notevolmente più lenta.
Tuttavia, Zhang spiega che la latenza percepita dall’utente finale potrebbe essere trascurabile a causa del modo in cui il recupero è integrato nel processo di generazione. In una classica configurazione RAG, il recupero è un passaggio bloccante: il sistema deve eseguire la ricerca nel database prima di poter iniziare a generare una risposta. Con PageIndex, il recupero avviene in linea, durante il processo di ragionamento del modello.
“Il sistema può avviare immediatamente lo streaming e recuperarlo man mano che viene generato”, ha affermato Zhang. “Ciò significa che PageIndex non aggiunge un ‘gate di recupero’ additional prima del primo token e Time to First Token (TTFT) è paragonabile a una normale chiamata LLM.”
Questo cambiamento architetturale semplifica anche l’infrastruttura dei dati. Eliminando la dipendenza dagli incorporamenti, le aziende non hanno più bisogno di mantenere un database vettoriale dedicato. L’indice strutturato advert albero è sufficientemente leggero da poter essere inserito in un database relazionale tradizionale come PostgreSQL.
Ciò risolve un crescente punto critico nei sistemi LLM con componenti di recupero: la complessità di mantenere gli archivi vettoriali sincronizzati con i documenti viventi. PageIndex separa l’indicizzazione della struttura dall’estrazione del testo. Se un contratto viene modificato o una coverage aggiornata, il sistema può gestire piccole modifiche reindicizzando solo la sottostruttura interessata invece di rielaborare l’intero corpus del documento.
Una matrice decisionale per l’impresa
Sebbene i miglioramenti in termini di precisione siano convincenti, il recupero tramite ricerca advert albero non è un sostituto universale della ricerca vettoriale. La tecnologia è meglio vista come uno strumento specializzato per il “lavoro profondo” piuttosto che come un toccasana per ogni attività di recupero.
Per documenti brevi, come e-mail o registri di chat, l’intero contesto spesso rientra nella finestra di contesto di un moderno LLM, rendendo superfluo qualsiasi sistema di recupero. Al contrario, per attività basate esclusivamente sulla scoperta semantica, come consigliare prodotti simili o trovare contenuti con una “atmosfera” simile, gli incorporamenti di vettori rimangono la scelta superiore perché l’obiettivo è la prossimità, non il ragionamento.
PageIndex si colloca esattamente nel mezzo: documenti lunghi e altamente strutturati in cui il costo dell’errore è elevato. Ciò embrace manuali tecnici, documenti depositati presso la FDA e accordi di fusione. In questi scenari, il requisito è la verificabilità. Un sistema aziendale deve essere in grado di spiegare non solo la risposta, ma anche il percorso intrapreso per trovarla (advert esempio, confermando di aver controllato la Sezione 4.1, seguito il riferimento all’Appendice B e sintetizzato i dati ivi trovati).
Il futuro del recupero degli agenti
L’ascesa di framework come PageIndex segnala una tendenza più ampia nello stack AI: il passaggio verso “RAG agente.” Man mano che i modelli diventano più capaci di pianificare e ragionare, la responsabilità di trovare i dati si sta spostando dal livello del database al livello del modello.
Lo stiamo già vedendo nello spazio di codifica, dove agli agenti piace Codice Claudio e Cursor si stanno allontanando dalle semplici ricerche vettoriali a favore dell’esplorazione attiva della base di codice. Zhang ritiene che il recupero di documenti generici seguirà la stessa traiettoria.
“I database vettoriali hanno ancora casi d’uso adatti”, ha detto Zhang. “Ma il loro ruolo storico come database predefinito per LLM e AI diventerà meno chiaro nel tempo.”
