Il RAG classico funziona bene quando la risposta sta in un singolo documento, ma inizia a soffrire con domande che attraversano più documenti o che hanno natura temporale: quali aziende abbiamo acquisito nell’ultimo decennio? Come è cambiata la nostra strategia AI dal 2018? Per rispondere serve correlare informazioni sparse su anni di report. Questo articolo mette a confronto due pattern architetturali che affrontano il problema in modo opposto, ed è utile perché la scelta ha impatti concreti su costi, latenza e manutenibilità.
LLM-Wiki: compilare la conoscenza in anticipo
LLM-Wiki sposta il reasoning al momento dell’ingestion. Ogni documento in ingresso viene processato da un LLM che estrae concetti, entità, relazioni e fatti, poi li fonde in un insieme di canonical pages persistenti (ad esempio “Acquisizioni”, “Cloud Strategy”, “Sustainability”). Un indice individua la pagina giusta per ogni query futura, e le risposte arrivano dalla conoscenza già compilata invece che dai documenti grezzi. È una forma di knowledge compilation elegante, ma pone un problema di previsione: bisogna decidere in fase di ingestion quali informazioni materializzare, anticipando ogni possibile domanda futura. Chiedere al modello decine di obiettivi di estrazione in un solo passaggio, inoltre, degrada la recall su documenti lunghi e densi.
Proxy-Pointer: sintesi semantica lazy
Proxy-Pointer costruisce all’ingestion solo una rappresentazione strutturale del documento (uno skeletal tree), con un processo puramente regex-based a costo zero, senza LLM. La compilazione semantica è rimandata al momento del retrieval: just-in-time. I chunk vengono creati entro i confini di sezione, senza overlap, e taggati con metadata su sezione e anno. Per una query come “cosa è successo alle aziende acquisite nell’ultimo decennio”, il sistema filtra i chunk per anno (metadata come Year: 2024 > Section: M&A) e recupera le top-k sezioni rilevanti da ciascun report. Con k=5 su dieci report si ottengono 50 sezioni da analizzare, invece di processare dieci documenti da 200 pagine in anticipo.
Quando conviene cosa
La differenza di fondo non è il retrieval, ma quando deve avvenire la comprensione semantica. LLM-Wiki assume che la conoscenza valga la pena di essere compilata subito, così le query future costano poco; Proxy-Pointer parte dal presupposto opposto, che gran parte del contenuto enterprise non verrà mai interrogato e quindi il reasoning va fatto solo su richiesta, con eventuale caching dei risultati per query ricorrenti. Sul fronte explainability, Proxy-Pointer ragiona direttamente sulle sezioni sorgente, mantenendo la tracciabilità naturale; LLM-Wiki cita le fonti ma ragiona su rappresentazioni compilate che vanno mantenute nel tempo. Il progetto è open-source con licenza MIT.
- Corpora stabili con query concettuali ripetitive possono trarre valore da una knowledge base compilata (LLM-Wiki).
- Repository ampi, con documenti in evoluzione e query imprevedibili, beneficiano del deferimento della compilazione al retrieval (Proxy-Pointer).
- Il trade-off chiave resta costo contro valore: compilare perché potrebbe servire, o sintetizzare solo quando qualcuno chiede.
Fonte: Proxy-Pointer RAG: Temporal Reasoning Without Semantic Precompilation — https://towardsdatascience.com/proxy-pointer-rag-temporal-reasoning-without-semantic-precompilation/
Hai qualcosa da aggiungere? Unisciti alla discussione.