Migliori strumenti, framework e librerie RAG
RAG migliora le risposte degli LLM ancorandole a dati esterni anziché basarsi solo su ciò che il modello ha memorizzato durante l'addestramento. Abbiamo confrontato i componenti di cui è composto un sistema RAG e raccolto i risultati in un unico posto, con una guida pratica per scegliere ogni parte dello stack.
Consulta i nostri risultati benchmark per ciascun componente RAG, la nostra guida alla scelta di uno stack RAG, oppure i fondamenti di RAG: cos'è, come funziona e dove si inserisce.
Risultati benchmark RAG
Modelli di embedding
Il modello di embedding converte sia i tuoi documenti sia la query dell'utente in vettori, quindi stabilisce il limite massimo della qualità di recupero.
Abbiamo confrontato 15 modelli di embedding densi più una baseline lessicale BM25 su tre domini (contratti legali/CUAD, assistenza clienti/TechQA e sanità/MedRAG), valutando ciascuno con nDCG@3.
voyage-3.5 è al primo posto con 0.9429 e supera il modello di punta di Voyage, voyage-4-large, costando la metà ($0.060 contro $0.120 per 1M token). Il modello più nuovo e più grande non è automaticamente il miglior acquisto. Per stack orientati al costo, pplx-embed-v1-0.6b di perplexity offre circa il 92% della qualità di voyage-3.5 (0.8604) a circa un quindicesimo del prezzo ($0.004/1M). Per il grafico del rapporto accuratezza-prezzo, consulta il grafico dei costi nel benchmark completo dei modelli di embedding, che include anche la suddivisione per dominio e la metodologia.
Oltre ai vettori densi a vettore singolo, i recuperatori a interazione tardiva (multi-vettore) come ColBERT (e ColPali/ColQwen per il recupero di documenti visivi e PDF) mantengono un vettore per token per un matching più fine e una migliore generalizzazione fuori dominio, con un indice molto più grande (ColPali memorizza circa 1.000× più vettori per elemento; vedi il nostro benchmark sugli embedding multimodali).
Se il tuo corpus è multilingue o visivo, la scelta dell'embedding cambia: il nostro benchmark sugli embedding multilingue ha rilevato che un modello da 110M parametri (e5_base) domina in tutte le sei lingue e batte modelli fino a 70× più grandi, e il nostro benchmark multimodale ha posto DFN5B-H di Apple in cima con un Recall@1 testo-immagine del 50,1%. Per i team che non possono inviare dati a una API, il nostro benchmark sugli embedding open-source classifica Nemotron-8B di NVIDIA al primo posto (0.9249 nDCG@3), con Harrier-oss da 0.6B con licenza MIT di Microsoft come migliore opzione commerciale senza restrizioni.
Reranking
Un recuperatore bi-encoder è veloce ma approssimativo. Un reranker è un cross-encoder che rivaluta i migliori candidati restituiti dal recuperatore, leggendo ogni coppia query–documento insieme per portare i chunk veramente rilevanti in cima prima che raggiungano l'LLM. La pipeline canonica del 2026 consiste nel recuperare un insieme ampio, rerankarlo per ridurlo, quindi inviare 3–5 chunk al modello. 1
Abbiamo confrontato 8 reranker sul recupero in inglese (top-100 candidati, 300 query):
L'aggiunta di un reranker ha portato l'accuratezza top-1 (Hit@1) da 62,67% a 83,00%, un balzo di 20,33 punti con un solo stadio in più. Il risultato che dovrebbe orientare una decisione d'acquisto: un modello da 149M parametri (gte-reranker-modernbert-base) ha eguagliato un modello da 1.2B in cima, quindi il reranker più grande non è quello da scegliere. Il benchmark completo sui reranker copre latenza e il tetto Hit@10.
Database vettoriali
Il database vettoriale memorizza i tuoi embedding e serve la ricerca dei vicini più prossimi al momento della query, quindi definisce il limite minimo di latenza e una quota importante del costo operativo. Abbiamo confrontato sette motori open-source e self-hosted sugli stessi embedding bge-m3, ciascuno letto con un Recall@10 di 0.95 in modo che l'indice fosse l'unica variabile.
I sette sono alla pari per accuratezza di recupero. nDCG@10 è compreso tra 0.803 e 0.817, uno scarto di 0.014, a fronte di una differenza di 10x nel throughput a thread singolo (Redis 764 QPS, LanceDB 70) e di una differenza di 3.7x nella memoria di picco con 2.25M vettori (Milvus 17.0 GB, Chroma 62.4 GB). Il motore è una scelta di velocità, memoria e carico di lavoro, non di accuratezza, perché il modello di embedding stabilisce il limite massimo di qualità a questo punto operativo.
La scelta del motore dipende dal carico di lavoro. Redis ha registrato 1.7 ms p95 con 559 MB di RAM, con persistenza disattivata. Weaviate ha raggiunto 8.330 QPS con 32 processi worker, mentre Redis saturava a 1.642. Milvus occupava 17.0 GB con 2.25M vettori contro i 62.4 GB di Chroma, e manteneva il più alto recall peggiore sotto filtri di metadati (0.984). Qdrant ha registrato un miglioramento ibrido di +0.067 nDCG con fusione nativa fusion. Due motori hanno limiti rigidi: Chroma non offre ricerca per parole chiave nella sua build self-hosted e restituisce un p99 di 13 secondi con 512 client concorrenti, e LanceDB assorbe 2.6 scritture a riga singola al secondo, il che lo esclude per una knowledge base continuamente aggiornata. Il benchmark completo sui database vettoriali open-source copre ricerca filtrata, costo di costruzione e ricambio in tempo reale, e il calcolatore di dimensionamento dei database vettoriali traduce questi limiti in un verdetto per motore per un server specifico.
Come scegliere il tuo stack RAG
I benchmark precedenti rispondono a “Quale componente è migliore isolatamente?” Questa sezione risponde a “Come li assemblo?” Percorri la pipeline in ordine e scegli ogni stadio in base al caso d'uso, alla scala e al budget:
- Chunking: dividi i documenti in passaggi da ~300–500 token con una sovrapposizione del 10–20%; preferisci divisioni semantiche/strutturali rispetto a dimensioni fisse per documenti eterogenei.
- Modello di embedding: voyage-3.5 per il miglior rapporto qualità-prezzo su API; qwen3-embedding-8b o NVIDIA Nemotron-8B se devi self-hostarlo; scegli un modello multilingue o multimodale se il tuo corpus lo richiede.
- Database vettoriale: Redis quando domina la latenza di singola query, Weaviate o Milvus per concorrenza sostenuta, Milvus quando la memoria è il vincolo su larga scala, pgvector quando lo stack è già su Postgres; quattro dei sette (Qdrant, Milvus, Weaviate, LanceDB) fondono risultati ibridi nativamente. Prima dimensiona l'indice sul server, poiché un box da 16 GB contiene circa 1,5M vettori su Redis e 3,7M su Qdrant a 1024 dimensioni.
- Recupero ibrido: combina denso + BM25 con RRF, che ha migliorato nDCG@10 da 0.030 a 0.067 tra i motori che dispongono di un braccio per parole chiave nel nostro benchmark sui database vettoriali; il miglioramento è chiaramente superiore a zero con confidenza del 95% per Qdrant, LanceDB, Redis e Milvus, e non per pgvector o Weaviate.
- Reranking: aggiungi un cross-encoder (è sufficiente un modello da 149M) per recuperare i circa 20 punti di accuratezza top-1 che un bi-encoder lascia sul tavolo.
- Generazione: utilizza un modello con supporto per citazioni anellate, in modo che le risposte siano attribuibili alle fonti.
- Valutazione: integra metriche di recupero, generazione e end-to-end prima di rilasciare.
Governance aziendale
Per implementazioni aziendali, la qualità del recupero è necessaria ma non sufficiente; anche il livello di recupero deve essere governato. Ci si aspetta che un sistema RAG in produzione applichi recupero consapevole dei permessi (i risultati rispettano i controlli di accesso del sistema sorgente, così che un utente non recuperi mai un documento che non potrebbe aprire direttamente), si sincronizzi con i provider di identità (Okta, Azure AD, Auth0) in modo che le modifiche ai permessi si propaghino quasi in tempo reale, registri ogni recupero per audit, esegua guardrail di input/output e rispetti i vincoli di residenza dei dati. Considera questi aspetti come prerequisiti, non come componenti aggiuntivi, per qualsiasi sistema RAG che tocchi dati interni. 2 Questi controlli devono essere garantiti nel livello di recupero, non solo nell'applicazione sovrastante, e i motori open-source differiscono per ciò che possono applicare: dei sette che abbiamo confrontato, solo pgvector offre recupero point-in-time e sicurezza a livello di riga, mentre Qdrant, Milvus e Weaviate includono replica e RBAC nelle loro build open-source, Chroma 1.x non offre alcuna autenticazione, e nessuno dei sette crittografa i dati a riposo in modo nativo, delegando ciò alla crittografia del disco o del volume.
RAG vs. contesto lungo
Con finestre di contesto che raggiungono milioni di token, è lecito chiedersi se RAG sia ancora necessario. Nel 2026, la risposta non è aut: RAG recupera le evidenze rilevanti, una finestra di contesto lunga può affinarle, e un livello di instradamento decide quale percorso segue ogni query.
La decisione di solito si riduce al costo. Poiché un LLM fattura ogni token in input per ogni richiesta, inserire un intero corpus nel contesto è costoso su larga scala. Per knowledge base di grandi dimensioni con un carico di query costante, RAG può operare nell'ordine di 1.250× in meno per query rispetto all'inserimento nel contesto lungo, poiché paga per poche migliaia di token recuperati invece che per l'intero archivio ogni volta. 3
Questo vantaggio è condizionato, e vale la pena dichiararlo onestamente: RAG vince sui costi sopra i circa 500K token di corpus e qualche migliaio di query al giorno, mentre sotto i ~200K token e qualche centinaio di query al giorno, il contesto lungo con caching dei prompt spesso vince a mani basse, perché il costo fisso di hosting del database vettoriale da solo supera l'intera spesa per il contesto lungo. 4 Il nostro modello di dimensionamento esprime questa soglia in termini concreti. Un corpus di 2 GB con chunk da 512 token diventa circa 1,15M vettori, che richiedono 5,1 GB di RAM su Qdrant o 6,9 GB su Milvus, un server che costa lo stesso sia che arrivi una query sia che non ne arrivi. L'accuratezza favorisce comunque il recupero per ricerche “ago nel pagliaio”, dove filtrare il testo irrilevante riduce la deriva dell'attenzione “perso nel mezzo” che degrada il recall del contesto lungo.
Quali sono i modelli e gli strumenti RAG disponibili?
Gli strumenti per RAG si dividono in tre gruppi: LLM e API con ancoraggio integrato, framework di orchestrazione e i componenti di recupero sottostanti (modelli di embedding, database vettoriali, reranker).
LLM e API con ancoraggio integrato
Diversi fornitori di modelli offrono ora funzionalità di generazione ancorata in modo da poter allegare conoscenze esterne con attribuzione delle fonti:
- Anthropic Claude: un'API Citations che ancora le risposte nei documenti forniti e restituisce riferimenti ai passaggi esatti utilizzati. 5
- Google Gemini: uno strumento File Search integrato che gestisce RAG per te (carica documenti e Gemini li divide in chunk, li incorpora e li recupera al momento della query), oltre al motore Vertex IA RAG per il recupero aziendale gestito. La sua funzione separata “grounding con Google Search” attinge dal web live, non dai tuoi dati. 6
- Cohere Command: modelli ottimizzati per RAG (Command R/R+ e il più recente Command A) che restituiscono citazioni in linea fin da subito, abbinati a un endpoint Rerank dedicato. 7
- OpenAI: uno strumento di recupero file-search nelle API Assistants e Responses. 8
Librerie e framework RAG
Questi collegano recupero e generazione in una pipeline:
- LangChain / LangGraph: orchestrazione generica; LangGraph aggiunge cicli stateful e agentici di recupero-riflessione-verifica.
- LlamaIndex: ingestione dati, indicizzazione e motori di query.
- Haystack: pipeline end-to-end per ricerca e risposta a domande.
- DSPy: programmi dichiarativi e guidati da ottimizzatori di prompt/recupero.
Per un confronto più approfondito, consulta la nostra analisi dei framework RAG.
Cos'è la generazione aumentata da recupero?
La generazione aumentata da recupero è una tecnica che dà a un grande modello linguistico accesso a una fonte di conoscenza esterna al momento della query. Invece di rispondere basandosi solo sui parametri fissati durante l'addestramento, il modello recupera passaggi rilevanti da un archivio documentale e condiziona la sua risposta su di essi. Ciò mantiene le risposte aggiornate, le ancora a fonti citabili e riduce le allucinazioni in compiti ad alta intensità di conoscenza, senza riaddestrare il modello.
Come funzionano i modelli RAG?
Al suo nucleo, RAG opera in due fasi: recupero (trova i passaggi rilevanti per la query) e generazione (scrivi una risposta condizionata da quei passaggi). Nei sistemi di produzione, quel ciclo fondamentale è racchiuso in una pipeline più ampia:
- Riscrittura/scomposizione della query: riformula o suddividi la domanda per recuperare meglio, specialmente per query multi-turno o multi-hop.
- Recupero ibrido: esegui ricerche dense (vettoriali) e sparse (BM25) e fondi i risultati con RRF.
- Reranking: un cross-encoder rivaluta i candidati e tiene i primi pochi.
- Assemblaggio del contesto: costruisci il prompt dai chunk selezionati con citazioni.
- Generazione: l'LLM risponde a partire dal contesto assemblato.
- Valutazione: valuta la qualità del recupero e della risposta, idealmente in CI.
Il ciclo a due fasi resta il modello mentale; gli stadi aggiuntivi sono ciò che separa una demo da un sistema di produzione.
Quali sono i diversi tipi di RAG?
Oltre alla pipeline lineare, diverse varianti di RAG mirano a specifiche modalità di errore: RAG speculativo (bozza-e-verifica per velocità), Retrieval-Augmented Fine-Tuning (RAFT) (addestra il modello a usare il contesto recuperato), Self-RAG e RAG correttivo (CRAG) (il modello critica e ri-recupera quando le evidenze sono deboli). Queste si sovrappongono con le architetture avanzate seguenti.
Architetture RAG avanzate
RAG basato su grafi (GraphRAG)
GraphRAG costruisce un knowledge graph sul corpus, spesso su un database a grafi dedicato come Neo4j o FalkorDB, in modo che il sistema possa rispondere a domande multi-hop e di aggregazione globale che la ricerca vettoriale piatta non coglie. Il suo vantaggio su queste domande deriva in gran parte dal pre-calcolo delle relazioni sull'intero corpus piuttosto che da un miglior recupero di passaggi, quindi la ricerca vettoriale tende ancora a vincere nelle ricerche su documenti specifici. Il consiglio pratico: ricorri a un grafo quando le query richiedono ragionamento globale su molti documenti, non come sostituto immediato del recupero vettoriale.
RAG agentico
Il RAG agentico mette un agente LLM al comando del recupero: decide cosa recuperare, quale fonte o strumento chiamare, e quando riflettere e riprovare, iterando finché la risposta non è ancorata. Nel nostro benchmark sul RAG agentico, che testa un agente che deve instradare ogni domanda al database giusto e poi scrivere SQL su di esso, i modelli più forti ora instradano quasi perfettamente (Claude Opus 4.8 al 100%, Fable 5 al 98%), mentre scrivere SQL corretto sullo schema scelto rimane il limite più difficile, raggiungendo al massimo circa il 90%. L'instradamento è quasi risolto; l'esecuzione fondata è dove il RAG agentico si differenzia ancora.
RAG ibrido, iterativo e attivo
Il recupero ibrido (denso + sparso, trattato sopra) è ora l'impostazione predefinita, non un'opzione avanzata. Le varianti iterative e attive (es. FLARE) consentono al modello di recuperare ripetutamente durante la generazione, prelevando nuove evidenze quando la sua confidenza cala.
Aggiungi come fonte preferitaCome valutare i sistemi RAG
La valutazione di RAG è ora strutturata in tre livelli di ciclo di vita: recupero (precisione, recall, MRR, nDCG, hit@k: abbiamo recuperato i chunk giusti?), generazione (ancoraggio, fedeltà: la risposta è supportata dal contesto recuperato?) e end-to-end (la risposta finale è corretta?).
Gli strumenti si dividono lungo le stesse linee: RAGAS per un'iterazione rapida e senza riferimenti gratuito durante lo sviluppo; DeepEval come gate pass/fail in stile pytest in CI, così che una regressione blocchi la build; e TruLens o Phoenix per il tracciamento e il monitoraggio in produzione. TREC-RAG e ARES sono utili riferimenti esterni per la calibrazione del giudice. 9
Le metriche di recupero si dividono in due una volta che un database vettoriale è nel circuito, e le due metà possono muoversi in direzioni opposte. Il recall ANN chiede se l'indice ha restituito i veri vicini più prossimi, isolando il database; nDCG e MRR rispetto a etichette umane chiedono se quei documenti sono rilevanti, il che è per lo più una proprietà del modello di embedding. Scalare un corpus da 50k a 2.25M vettori nel nostro benchmark sui database vettoriali ha fatto scendere nDCG@10 da circa 0.81 a 0.56, mentre ogni motore riportava ancora Recall@10 sopra 0.973, e l'oracolo kNN esatto scendeva allo stesso 0.572. Un benchmark solo geometrico avrebbe riportato un indice sano per un corpus che aveva perso un terzo della qualità delle risposte.
Dimensione dei chunk
La dimensione dei chunk controlla come i documenti vengono suddivisi prima dell'embedding.
Le linee guida del 2026 hanno superato una singola dimensione fissa: preferisci chunking semantico / strutturale (inizia un nuovo chunk quando frasi adiacenti divergono nel significato), mantieni i chunk intorno ai 300–500 token con una sovrapposizione del 10–20%, e considera il recupero contestuale: la tecnica di Anthropic di anteporre una frase di contesto generata dall'LLM a ogni chunk prima dell'embedding e dell'indicizzazione BM25. Nei test di Anthropic, gli embedding contestuali hanno ridotto il tasso di fallimento del recupero dei primi 20 del 35%, embedding contestuali più BM25 contestuale del 49%, e l'aggiunta di un reranker in cima del 67%. 10 La dimensione dei chunk determina anche quanto diventa grande l'indice, poiché decide in quanti vettori si trasforma il corpus. Il nostro calcolatore di dimensionamento dei database vettoriali rende esplicito il collegamento: con le sue impostazioni predefinite di chunk da 512 token e sovrapposizione del 15%, il corpus avanza di 435 token per chunk, quindi dimezzare il chunk raddoppia all'incirca sia il numero di vettori sia la memoria che il database deve mantenere.
Fine-tuning vs. generazione aumentata da recupero
RAG e fine-tuning risolvono problemi diversi, e nel 2026 vengono sempre più utilizzati insieme piuttosto che come alternative.
Per la maggior parte dei team, la risposta è “RAG prima, ottimizza il comportamento con fine-tuning se necessario”, e RAFT formalizza il fare entrambe le cose.
Vantaggi della generazione aumentata da recupero
I vantaggi di RAG si raggruppano in pochi che guidano realmente l'adozione: accuratezza e freschezza (le risposte riflettono dati attuali e ancorati alle fonti, non una data di interruzione dell'addestramento congelata), trasparenza (le risposte citano i passaggi utilizzati, quindi sono verificabili), costo inferiore rispetto al contesto lungo su larga scala e adattabilità (aggiorna la knowledge base invece di riaddestrare il modello). Il RAG multimodale estende tutto ciò a immagini, PDF e tabelle.
Ulteriori letture
- Benchmark dei modelli di embedding
- Benchmark dei reranker
- Benchmark dei database vettoriali open-source
- Calcolatore di dimensionamento dei database vettoriali
- Modelli di embedding open-source
- Modelli di embedding multilingue
- Embedding multimodali
- Framework RAG agentici
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Migliori strumenti, framework e librerie RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/retrieval-augmented-generation}},
note = {AIMultiple. Consultato il 18 Luglio 2026}
}Collegamenti di riferimento
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.