Scomposizione delle query e la cassetta degli attrezzi dell'advanced RAG: adattate il metodo al tipo di errore
Scomposizione delle query, HyDE, RAG-fusion e GraphRAG risolvono ciascuno un errore diverso. Il RAG raffinato del 2026 sa quando non usarne nessuno.
Traduzione generata automaticamente con IA. La versione tedesca è l'originale verificato dalla redazione.
Le tecniche di advanced RAG non sono una scala di maturità da scalare. Sono una cassetta degli attrezzi diagnostica, indicizzata in base all'errore che osservate realmente. La scomposizione delle query risolve le domande multi-hop. HyDE risolve il disallineamento di vocabolario. GraphRAG risponde a domande sull'intero corpus che in realtà non sono affatto retrieval. Impilare tutto questo su ogni richiesta moltiplica i vostri costi e la latenza per richieste che non hanno mai avuto bisogno di quell'aiuto. Il sistema raffinato del 2026 non è quello con più tecniche; è quello che sa quando non usarne nessuna.
01. Iniziate dal basso, non dal soffitto
Prima di ogni metodo ingegnoso, mettete a posto le basi, perché risolvono la maggior parte dei problemi lamentati. Lo standard di produzione del 2026 è la ricerca ibrida (embedding densi più keyword BM25), seguita da un reranker cross-encoder. La ricerca ibrida cattura sia i risultati semantici sia le corrispondenze esatte dei termini; il reranker riduce un ampio insieme di candidati ai pochi passaggi che sono davvero rilevanti, non solo vicini per argomento. Le guide pratiche riferiscono che questa combinazione aumenta la qualità del retrieval del 15-30 percento sui set di valutazione standard.
Questo conta perché la maggior parte degli errori reali è del tipo semplice: la risposta era nei documenti, ma il sistema non è riuscito a farla emergere. È un problema di recall e di ranking, e la base descritta sopra lo risolve. Dimostrate di avere bisogno di più prima di costruire di più. Ogni tecnica oltre questo punto aggiunge chiamate all'LLM, latenza e costi; ognuna dovrebbe guadagnarsi il proprio posto contro un errore misurato, non contro una sensazione di pancia.
02. La cassetta degli attrezzi, indicizzata per l'errore che risolve
Il modo utile di tenere in ordine l'intero zoo di metodi è mappare ciascuno sul singolo pattern di errore che affronta. Ricorrete a un metodo quando ne vedete l'errore, non prima.
| L'errore che osservate | Il metodo che lo risolve |
|---|---|
| Domanda multi-parte o multi-hop, fatti distribuiti tra più documenti | Scomposizione della query in sottodomande |
| Richiesta scarna o ambigua che si presta male all'embedding | HyDE, riscrittura della richiesta |
| Una singola formulazione manca i passaggi rilevanti | RAG-Fusion (più varianti della richiesta, fuse insieme) |
| La domanda richiede prima un principio generale | Step-Back Prompting |
| Corpora e tipi di richiesta eterogenei | Routing verso l'indice o la pipeline corretti |
| Vincoli strutturati rigidi (date, tipi) | Self-querying (filtri sui metadati) |
| Il retrieval restituisce silenziosamente documenti sbagliati | Corrective RAG (un grader più un fallback) |
| Domanda globale sull'intero corpus | GraphRAG (grafo delle entità più riepiloghi) |
Ogni riga ha un'origine reale: HyDE proviene da un paper CMU del 2022 sul dense retrieval zero-shot; Step-Back Prompting da Google DeepMind, 2023; GraphRAG da Microsoft, 2024. È la stessa disciplina di decisione-in-base-all'errore dietro il nostro sguardo su RAG-Fusion e come si differenzia dal RAG semplice.
03. La scomposizione delle query, nello specifico
La scomposizione delle query divide una richiesta complessa in sottodomande indipendenti, esegue il retrieval per ciascuna e poi sintetizza una risposta. È lo strumento giusto quando un singolo passaggio di retrieval non può funzionare, perché i fatti vivono in documenti diversi o un fatto dipende da un altro (chi ha diretto il film che ha vinto un certo premio). La linea evolutiva va dal least-to-most prompting del 2022 alle sub-question query engine dei framework odierni.
La parte onesta è che non è gratis e può fare danni. Uno studio della HU Berlin del luglio 2025 ha misurato che scomposizione più reranking ha portato il recall multi-hop (Hits@10) dal 74,7 all'87,2 percento, un guadagno reale. Lo stesso studio ha misurato i costi: circa 16,7 secondi per richiesta contro 0,03 secondi per il retrieval naive, e ha scoperto che scomporre una richiesta già specifica introduce rumore e peggiora la risposta. La scomposizione va quindi riservata alle domande davvero multi-hop, non applicata di default a ogni richiesta. L'arte sta nel distinguere le due cose.
04. La leva che si ripaga da sola è il routing
Se dovete portare a casa un'unica idea operativa da tutto questo, che sia il routing. Classificate prima la richiesta, poi spendete complessità solo dove è meritata. Un'analisi del 2026 sul routing consapevole dei costi ha ridotto i token fatturati del 26 percento e la latenza mediana del 34 percento a parità di qualità della risposta, instradando solo circa il 18 percento delle richieste verso il retrieval pesante e il 14 percento verso nessun retrieval. I metodi costosi sono rimasti riservati alle richieste che ne avevano davvero bisogno.
Per un team delle PMI tedesche, questa è tanto una storia di governance e di costi quanto una storia di qualità. Meno chiamate all'LLM, ma giustificate, significano spesa pianificabile, latenza più bassa e un sistema che potete spiegare a uno stakeholder orientato alla compliance: ecco perché questa richiesta ha preso la strada costosa, ed ecco perché quell'altra non l'ha presa. Il retrieval sovra-ingegnerizzato non è solo lento, è una spesa inspiegabile. Il sistema RAG raffinato del 2026 è quello che sa quando non usare nessuno dei suoi trucchi.
