NEWS — 27 luglio 2026
L’architettura PlanRAG trasforma le domande complesse in alberi logici simili a piani SQL
I modelli linguistici sbagliano meno quando smettono di fare i detective e iniziano a ragionare come un database. Lo dice uno studio pubblicato questo mese su arXiv che non ha fatto notizia per il modello usato, ma per l’architettura: PlanRAG, un sistema di retrieval-augmented generation che trasforma le domande complesse in strutture logiche simili ai piani di query di SQL. I risultati sul dataset WikiWeb-ERP hanno superato tutti i sistemi RAG esistenti basati su iterazione e grafi. Nessun parametro in più, nessun modello più grande. Solo un modo diverso di organizzare le informazioni prima di rispondere.
Il muro dei RAG tradizionali
Eppure, fino a ieri i RAG inciampavano proprio sulle richieste più articolate. Negli ultimi tre anni, i sistemi di retrieval-augmented generation si sono evoluti attraverso tre fasi distinte: il Naive RAG, che si limitava a cercare documenti e incollarli nel prompt; l’Advanced RAG, che aggiungeva correzioni pre- e post-recupero; infine il Modular RAG, che scomponeva il processo in moduli intercambiabili. Lo documentava già nel 2023 una revisione di Gao et al., che mappava questa progressione e i suoi limiti.
Il problema di fondo è rimasto lo stesso: quando una domanda richiede più passaggi di ragionamento — due, tre, quattro ricerche incatenate — i RAG tradizionali procedono per tentativi. Fanno una ricerca, guardano il risultato, ne fanno un’altra, e così via. È un approccio iterativo che funziona per query semplici, ma che su richieste complesse diventa lento, costoso e incline a perdersi per strada. Cosa mancava? Un modo per pianificare il recupero delle informazioni con la stessa logica con cui un query planner di un database decide l’ordine ottimale delle operazioni prima ancora di toccare i dati.
PlanRAG: l’albero logico che mette ordine al caos
La risposta arriva da un approccio che trasforma il linguaggio naturale in strutture degne di un database SQL. PlanRAG non cerca informazioni una alla volta. Prima di tutto scompone le richieste complesse (quelle che gli autori chiamano “Enterprise Resource Planning questions”) in domande atomiche, piccole unità di ricerca indipendenti. Poi le organizza in alberi di query logici — Logical Query Trees, o LQT — che assomigliano molto ai piani di esecuzione che un database come PostgreSQL costruisce quando riceve un’interrogazione complessa.
Non è una metafora. Gli LQT sono strutture gerarchiche dove ogni nodo rappresenta un’operazione precisa: una ricerca, un’aggregazione, un confronto. E per decidere come disporre questi nodi, PlanRAG usa la programmazione dinamica guidata da un modello di costo multidimensionale. Invece di provare tutte le combinazioni (cosa computazionalmente proibitiva), valuta diverse dimensioni — tempo di esecuzione stimato, rilevanza dei documenti, coerenza dei risultati intermedi — e sceglie l’albero più efficiente prima di eseguire qualsiasi ricerca. È esattamente il principio con cui un query planner decide se fare prima un join o prima un filtro: non indovina, calcola.
Il risultato è misurabile. Sul dataset WikiWeb-ERP, costruito appositamente per testare query aziendali complesse, PlanRAG ha superato i sistemi RAG state-of-the-art, sia quelli basati su iterazione sia quelli basati su grafi. Non si tratta di un miglioramento marginale: la differenza sta nel fatto che PlanRAG arriva alla risposta corretta dove gli altri sistemi falliscono o producono risultati parziali.
La sfida dei grafi e cosa cambia per le aziende
PlanRAG non è l’unico a cercare di risolvere questo problema. Già lo scorso anno, un sistema chiamato Plan*RAG aveva proposto piani di ragionamento basati su grafi aciclici diretti — i DAG — mantenendo la struttura di pianificazione separata dal contesto del modello linguistico. L’idea è simile: non affidarsi al modello per decidere cosa cercare, ma costruire esternamente uno schema logico da seguire.
Ma il vero spartiacque è l’efficienza. Un grafo aciclico diretto può rappresentare dipendenze tra operazioni, ma non ottimizza attivamente l’ordine di esecuzione basandosi su un modello di costo. PlanRAG fa un passo in più: usa la programmazione dinamica per trovare, tra tutti gli alberi possibili, quello che minimizza il costo complessivo. È la differenza che passa tra avere una mappa e avere un navigatore che calcola il percorso migliore in tempo reale. Chi riuscirà a portare questa precisione in produzione senza far lievitare i costi computazionali avrà un vantaggio competitivo significativo.
Per chi pubblica contenuti online, le implicazioni sono concrete. I sistemi RAG tradizionali premiavano la densità di parole chiave e la pertinenza superficiale: comparire tra i primi risultati di una ricerca poteva bastare. Ma se un RAG pianifica le query come un database, cercherà fonti che possono fungere da tabelle interrogabili, non solo da testi da citare. La visibilità non dipenderà più dalla capacità di rispondere a una domanda singola, ma dalla capacità di fornire dati strutturati, coerenti e completi che un albero logico possa attraversare in più punti. Diventare la fonte per una risposta complessa significa essere l’unica fonte citata per l’intera catena di ragionamento. È una partita diversa, e si gioca sulla qualità architetturale dei contenuti, non sulla loro ottimizzazione.
