Su un documento molto lungo il RAG classico fatica. L’articolo di Kezhan Shi su Towards Data Science parte da un caso concreto: NIST SP 800-53 Rev. 5, 492 pagine che definiscono i controlli di sicurezza, un controllo alla volta. Alla domanda “cosa richiede il controllo di account management?”, la risposta sta in cinque pagine (il controllo AC-2, pagine 46-50). Il top-k naive embedda tutte le 492 pagine e restituisce AC-2 mescolato ad altri controlli, perché parole come account, management e access compaiono su centinaia di pagine: si paga due volte, l’embedding di tutto e una risposta comunque sfocata.
Instradare attraverso l’indice
Una persona aprirebbe invece la table of contents. Ma anche questa è lunga: 358 voci su tre livelli, dai 11 capitoli alle 20 famiglie di controlli fino ai 316 controlli individuali. Non si consegnerebbero 358 righe a un collega, così come non gli si darebbero 492 pagine. L’esperto scorre prima la lista dei capitoli, sceglie “The Controls”, la apre alle 20 famiglie, sceglie “Access Control” e arriva ad AC-2: dall’alto verso il basso, una piccola decisione alla volta. È questo il loop che l’articolo costruisce, sintesi della tesi della serie: amplify the expert, non riversare tutto sul modello in una volta.
Il loop, un livello alla volta
Il retrieval percorre l’albero top-down. Passa all’LLM solo il livello corrente — prima gli 11 titoli di capitolo, ciascuno come una riga compatta con titolo, range di pagine ed eventuale conteggio di keyword — e il modello sceglie il ramo. Se il ramo è ampio e ha figli, il retrieval lo apre e ripete; si ferma su una foglia o su una sezione abbastanza piccola da leggere intera. La table of contents non entra mai per intero nel prompt: il modello legge 11 righe, poi 20, poi una ventina, mai 358. Sulla domanda di esempio il router legge 56 voci in tre chiamate, poi la generazione legge cinque pagine e gli altri 315 controlli non entrano mai nel prompt. Il loop ha tre superfici di controllo: un trigger (un ramo ampio con figli), una terminazione (foglia, sezione piccola o domanda di tipo listing) e un recovery che a ogni iterazione cambia qualcosa (scende di livello, non rilegge quello appena valutato), con profondità limitata dall’albero.
Precisione e token insieme
Il vantaggio è su entrambi gli assi, cosa rara: il router si impegna su AC-2 per nome e lo legge intero, senza interlacciarlo con i vicini, e non embedda mai il corpo del documento. Su un corpus di migliaia di documenti, questa differenza è la linea tra un sistema che regge e uno che no. E scala senza cambiare: una cartella di documenti è la stessa mappa con un livello in più.
- Instradare attraverso l’indice evita di embeddare e leggere l’intero documento a ogni query.
- Il modello decide a ogni livello se scendere: su documenti brevi il loop gira una volta e si comporta come un routing flat.
- Il pattern si estende invariato dal singolo documento a una cartella di documenti, aggiungendo solo un livello.
Fonte: Loop Engineering for Hierarchical Retrieval — https://towardsdatascience.com/loop-engineering-for-hierarchical-retrieval-reading-a-long-document-by-its-table-of-contents/
Hai qualcosa da aggiungere? Unisciti alla discussione.