Migliori strumenti, framework e librerie RAG
RAG migliora le risposte degli LLM fondandole su dati esterni invece che solo su ciò che il modello ha memorizzato durante l'addestramento. Abbiamo confrontato i componenti da cui è costruito un sistema RAG e raccolto i risultati in un unico posto, con una guida pratica alla scelta di ogni parte dello stack.
Consulta i nostri risultati dei 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 dei 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 per la qualità del recupero.
Abbiamo confrontato 15 modelli di embedding densi più una baseline lessicale BM25 in 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 l'ammiraglia di Voyage, voyage-4-large, costando la metà ($0,060 contro $0,120 per 1M token). Il modello più nuovo e grande non è automaticamente l'acquisto migliore. Per gli 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 confronto accuratezza-prezzo, guarda il grafico dei costi nel benchmark completo dei modelli di embedding, che include anche la suddivisione per dominio e la metodologia.
Oltre agli embedding densi a vettore singolo, i retriever a interazione tardiva (multi-vettore) come ColBERT (e ColPali/ColQwen per il recupero di documenti visivi e PDF) mantengono un vettore per token per una corrispondenza più fine e una generalizzazione più forte fuori dominio, a fronte di 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 del modello di embedding cambia: il nostro benchmark sugli embedding multilingue ha rilevato che un modello da 110M parametri (e5_base) guida tutte e sei le lingue e supera modelli fino a 70× più grandi, e il nostro benchmark multimodale ha messo in cima DFN5B-H di Apple con il 50.1% di Recall@1 text-to-image. 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 opzione senza restrizioni commerciali più forte.
Reranking
Un retriever bi-encoder è veloce ma approssimativo. Un reranker è un cross-encoder che rivaluta i migliori candidati restituiti dal retriever, leggendo ogni coppia query-documento insieme per portare in cima i chunk veramente rilevanti prima che arrivino all'LLM. La pipeline canonica del 2026 consiste nel recuperare un insieme ampio, ridurlo con il reranking e poi 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) dal 62.67% all'83.00%, un salto di 20.33 punti con un solo stadio aggiuntivo. Il risultato che dovrebbe cambiare una decisione d'acquisto: un modello da 149M parametri (gte-reranker-modernbert-base) ha eguagliato un modello da 1.2B al vertice, quindi il reranker più grande non è quello da scegliere. Il benchmark completo dei reranker copre la latenza e il tetto Hit@10.
Database vettoriali
Il database vettoriale memorizza i tuoi embedding e serve la ricerca del vicino più prossimo al momento della query, quindi stabilisce il limite minimo di latenza e una quota importante dei costi operativi. Abbiamo confrontato sette motori open-source self-hosted sugli stessi embedding bge-m3, ciascuno letto con un Recall@10 pari a 0.95, così che l'indice fosse l'unica variabile.
I sette motori pareggiano sull'accuratezza del recupero. nDCG@10 si colloca tra 0.803 e 0.817, una differenza di 0.014, contro una differenza di 10x nel throughput single-thread (Redis 764 QPS, LanceDB 70) e una differenza di 3.7x nella memoria di picco a 2.25M vettori (Milvus 17.0 GB, Chroma 62.4 GB). Il motore è una decisione di velocità, memoria e carico di lavoro piuttosto che di accuratezza, perché il modello di embedding definisce il tetto qualitativo in questo punto operativo.
Quale motore sia adatto dipende dal carico di lavoro. Redis ha registrato 1.7 ms di p95 con 559 MB di RAM, con persistenza disattivata. Weaviate ha raggiunto 8.330 QPS con 32 processi worker, mentre Redis si è saturato a 1.642. Milvus ha mantenuto 17.0 GB con 2.25M vettori contro i 62.4 GB di Chroma, e ha conservato il più alto recall nel caso peggiore con filtri sui metadati (0.984). Qdrant ha registrato un incremento ibrido di +0.067 nDCG con la fusione nativa. Due motori hanno limiti rigidi: Chroma non offre ricerca per parole chiave nella build self-hosted e restituisce una p99 di 13 secondi con 512 client concorrenti, mentre LanceDB assorbe 2.6 scritture di singole righe al secondo, il che lo esclude per una knowledge base aggiornata continuamente. Il benchmark completo dei database vettoriali open-source copre la ricerca filtrata, il costo di costruzione e il churn dal vivo, e il calcolatore di dimensionamento del database vettoriale trasforma quei limiti in un verdetto per singolo motore per un server specifico.
Come scegliere il tuo stack RAG
I benchmark sopra rispondono alla domanda "Quale componente è migliore isolatamente?". Questa sezione risponde a "Come li assemblo?". Percorri la pipeline in ordine e scegli ogni stadio in base a caso d'uso, scala e budget:
- Chunking: dividi i documenti in passaggi da circa 300–500 token con una sovrapposizione del 10–20%; preferisci la suddivisione semantica o consapevole della struttura rispetto a dimensioni fisse per documenti eterogenei.
- Modello di embedding: voyage-3.5 per il miglior rapporto qualità-prezzo su una API; qwen3-embedding-8b o NVIDIA Nemotron-8B se devi self-hostare; scegli un modello multilingue o multimodale se il tuo corpus lo richiede.
- Database vettoriale: Redis quando domina la latenza della singola query, Weaviate o Milvus per la concorrenza sostenuta, Milvus quando la memoria è il vincolo a scala, pgvector quando lo stack è già su Postgres; quattro dei sette (Qdrant, Milvus, Weaviate, LanceDB) fondono i risultati ibridi in modo nativo. Dimensiona prima l'indice rispetto al server, poiché una macchina da 16 GB contiene circa 1.5M vettori su Redis e 3.7M su Qdrant a 1024 dimensioni.
- Recupero ibrido: combina dense + BM25 con RRF, che ha aumentato nDCG@10 da 0.030 a 0.067 tra i motori che dispongono di una componente lessicale nel nostro benchmark dei database vettoriali; il miglioramento supera lo zero con una confidenza del 95% per Qdrant, LanceDB, Redis e Milvus, ma non per pgvector o Weaviate.
- Reranking: aggiungi un cross-encoder (un modello da 149M è sufficiente) per recuperare i circa 20 punti di accuratezza top-1 che un bi-encoder lascia sul tavolo.
- Generazione: usa un modello con supporto per citazioni ancorate alle fonti, così le risposte sono attribuibili alle fonti.
- Valutazione: integra metriche di recupero, generazione ed end-to-end prima di rilasciare.
Governance aziendale
Per le implementazioni aziendali, la qualità del recupero è necessaria ma non sufficiente; anche il livello di recupero deve essere governato. Da un RAG di produzione ci si aspetta che applichi il recupero consapevole dei permessi (i risultati rispettano i controlli di accesso del sistema di origine, così un utente non recupera mai un documento che non potrebbe aprire direttamente), che si sincronizzi con i provider di identità (Okta, Azure AD, Auth0) affinché le modifiche ai permessi si propaghino quasi in tempo reale, che registri ogni recupero per l'audit, che esegua guardrail su input/output e che rispetti i vincoli di residenza dei dati. Trattali come prerequisiti irrinunciabili, non accessori, per qualsiasi sistema RAG che tocchi dati interni. 2 Tali controlli devono valere nel livello di recupero, non solo nell'applicazione che vi sta sopra, e i motori open-source differiscono per ciò che possono imporre: dei sette che abbiamo confrontato, solo pgvector offre il ripristino point-in-time e la sicurezza a livello di riga, Qdrant, Milvus e Weaviate includono replica e RBAC nelle loro build open-source, Chroma 1.x non include alcuna autenticazione e nessuno dei sette cifra i dati a riposo in modo nativo, lasciando questo compito alla cifratura del disco o del volume.
RAG vs. contesto lungo
Con finestre di contesto che raggiungono milioni di token, una domanda legittima è se RAG sia ancora necessario. Nel 2026 la risposta non è aut-aut: RAG recupera le prove rilevanti, una finestra di contesto lunga può rifinirle e un livello di routing decide quale percorso segue ogni query.
La decisione si riduce di solito al costo. Poiché un LLM fattura ogni token di input in ogni richiesta, inserire l'intero corpus nel contesto è costoso a scala. Per knowledge base di grandi dimensioni sotto un carico costante di query, RAG può costare circa 1.250× in meno per query rispetto al riempimento del 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 dirlo onestamente: RAG vince sul costo oltre circa 500K token di corpus e qualche migliaio di query al giorno, mentre sotto i ~200K token e poche centinaia di query al giorno, il contesto lungo con prompt caching spesso vince nettamente, perché il solo costo fisso di hosting del database vettoriale può superare l'intera bolletta del contesto lungo. 4 Il nostro modello di dimensionamento esprime quel limite in termini concreti. Un corpus da 2 GB con chunk da 512 token diventa circa 1.15M vettori, che richiede 5.1 GB di RAM su Qdrant o 6.9 GB su Milvus, un server che costa lo stesso indipendentemente dall'arrivo di una query. L'accuratezza favorisce ancora il recupero per le ricerche dell'ago nel pagliaio, dove filtrare il testo irrilevante riduce la deriva di attenzione "lost in the middle" che degrada il recall del contesto lungo.
Quali sono i modelli e gli strumenti RAG disponibili?
Gli strumenti RAG si dividono in tre gruppi: LLM e API con grounding integrato, framework di orchestrazione e i componenti di recupero sottostanti (modelli di embedding, database vettoriali, reranker).
LLM e API con grounding integrato
Diversi fornitori di modelli offrono ora funzionalità di generazione ancorata alle fonti per collegare conoscenze esterne con attribuzione delle fonti:
- Anthropic Claude: una API Citations che fonda le risposte sui documenti che fornisci e restituisce riferimenti ai passaggi esatti utilizzati. 5
- Google Gemini: uno strumento File Search integrato che gestisce il RAG al posto tuo (carichi i documenti e Gemini li suddivide in chunk, li incorpora e li recupera al momento della query), oltre a Vertex IA RAG Engine per il recupero aziendale gestito. La sua funzione separata "grounding con Google Search" attinge dal web in tempo reale, non dai tuoi dati. 6
- Cohere Command: modelli ottimizzati per RAG (Command R/R+ e il più recente Command A) che restituiscono citazioni inline pronte all'uso, 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 general-purpose; LangGraph aggiunge cicli stateful e agentici di retrieve-reflect-verify.
- LlamaIndex: ingestion dei dati, indicizzazione e motori di query.
- Haystack: pipeline end-to-end per ricerca e question answering.
- DSPy: programmi dichiarativi di prompt/recupero guidati da ottimizzatore.
Per un confronto più approfondito, consulta la nostra analisi dei framework RAG.
Che cos'è la generazione aumentata dal recupero?
La generazione aumentata dal recupero è una tecnica che dà a un large language model l'accesso a una fonte di conoscenza esterna al momento della query. Invece di rispondere solo in base ai parametri fissati durante l'addestramento, il modello recupera passaggi rilevanti da un archivio documentale e condiziona la propria risposta su di essi. Questo mantiene aggiornate le risposte, le fonda su fonti citabili e riduce le allucinazioni nei compiti ad alta intensità di conoscenza, senza riaddestrare il modello.
Come funzionano i modelli RAG?
Alla base, RAG funziona in due fasi: recupero (trova i passaggi rilevanti per la query) e generazione (scrive una risposta condizionata da quei passaggi). Nei sistemi di produzione, quel ciclo centrale è racchiuso in una pipeline più completa:
- Riformulazione/scomposizione della query: riformula o dividi la domanda per recuperare meglio, soprattutto 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 conserva i primi.
- Assemblaggio del contesto: costruisci il prompt dai chunk selezionati con citazioni.
- Generazione: l'LLM risponde a partire dal contesto assemblato.
- Valutazione: misura la qualità del recupero e delle risposte, idealmente in CI.
Il ciclo a due fasi è ancora 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 affrontano specifiche modalità di errore: RAG speculativo (bozza e verifica per la velocità), Retrieval-Augmented Fine-Tuning (RAFT) (addestra il modello a usare il contesto recuperato), Self-RAG e RAG correttivo (CRAG) (il modello critica e recupera di nuovo quando le prove sono deboli). Queste si sovrappongono alle architetture avanzate qui sotto.
Architetture RAG avanzate
RAG basato su grafi (GraphRAG)
GraphRAG costruisce un knowledge graph sul corpus, spesso su un database a grafo dedicato come Neo4j o FalkorDB, affinché il sistema possa rispondere a domande multi-hop e di aggregazione globale che la ricerca vettoriale piatta non coglie. Il suo vantaggio su quelle domande deriva in gran parte dal pre-calcolo delle relazioni nell'intero corpus piuttosto che da un migliore recupero dei passaggi, quindi la ricerca vettoriale tende ancora a vincere nelle ricerche su documenti specifici. In pratica: scegli un grafo quando le query richiedono ragionamento globale su molti documenti, non come sostituto diretto del recupero vettoriale.
RAG agentico
Il RAG agentico mette un agente LLM alla guida del recupero: decide cosa recuperare, quale fonte o strumento chiamare e quando riflettere e riprovare, iterando finché la risposta non è fondata. Nel nostro benchmark sul RAG agentico, che mette alla prova 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 rispetto allo schema scelto resta il tetto più difficile, fermandosi intorno al 90%. L'instradamento è quasi risolto; l'esecuzione fondata è il punto in cui il RAG agentico si differenzia ancora.
RAG ibrido, iterativo e attivo
Il recupero ibrido (dense + sparse, trattato sopra) è ormai l'impostazione predefinita piuttosto che un'opzione avanzata. Le varianti iterative e attive (es. FLARE) consentono al modello di recuperare ripetutamente mentre genera, ottenendo nuove prove quando la sua confidenza diminuisce.
Aggiungi come fonte preferitaCome valutare i sistemi RAG
La valutazione del RAG è ora strutturata lungo il ciclo di vita su tre livelli: recupero (precisione, recall, MRR, nDCG, hit@k: abbiamo recuperato i chunk giusti?), generazione (ancoraggio alle fonti, 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 iterazioni rapide reference-free durante lo sviluppo; DeepEval come gate pass/fail in stile pytest nella CI, così una regressione blocca la build; e TruLens o Phoenix per tracing e monitoraggio in produzione. TREC-RAG e ARES sono riferimenti esterni utili per la calibrazione dei giudici. 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 vettori più vicini, il che isola 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 dei database vettoriali ha fatto scendere nDCG@10 da circa 0.81 a 0.56 mentre ogni motore ha continuato a riportare Recall@10 sopra 0.973, e l'oracolo kNN esatto è sceso allo stesso 0.572. Un benchmark solo geometrico avrebbe riportato un indice sano su 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 indicazioni del 2026 sono andate oltre un'unica dimensione fissa: preferisci un chunking semantico / consapevole della struttura (inizia un nuovo chunk dove frasi adiacenti divergono di significato), mantieni chunk di circa 300–500 token con una sovrapposizione del 10–20% e valuta il recupero contestuale: la tecnica di Anthropic che antepone a ogni chunk una frase di contesto generata da un LLM prima dell'indicizzazione con embedding e BM25. Nei test di Anthropic, gli embedding contestuali hanno ridotto il tasso di fallimento del recupero top-20 del 35%, gli embedding contestuali più BM25 contestuale del 49% e l'aggiunta di un reranker sopra 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 del database vettoriale rende esplicito il collegamento: con il suo chunk predefinito da 512 token e la 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 contenere.
Fine-Tuning vs. generazione aumentata dal recupero
RAG e fine-tuning risolvono problemi diversi e nel 2026 sono sempre più usati insieme piuttosto che come alternative.
Per la maggior parte dei team, la risposta è "prima RAG, poi fine-tuning del comportamento se necessario" e RAFT formalizza la combinazione di entrambi.
Vantaggi della generazione aumentata dal recupero
I vantaggi del RAG si concentrano in pochi fattori che guidano davvero l'adozione: accuratezza e freschezza (le risposte riflettono dati attuali e ancorati alle fonti, non un limite di addestramento congelato), trasparenza (le risposte citano i passaggi utilizzati, quindi sono verificabili), costo inferiore rispetto al contesto lungo a scala e adattabilità (aggiorna la knowledge base invece di riaddestrare il modello). Il RAG multimodale estende questi vantaggi a immagini, PDF e tabelle.
Ulteriori letture
- Benchmark dei modelli di embedding
- Benchmark dei reranker
- Benchmark dei database vettoriali open-source
- Calcolatore di dimensionamento del database vettoriale
- 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}
}Registro delle modifiche
12 aggiornamenti- 2026
Ha sostituito il benchmark dei database vettoriali con un confronto tra motori open source self-hosted.
Aggiunte sezioni di benchmark su reranker e database vettoriali con nuovi risultati dei modelli di embedding.
Rimossa la sezione 'Potenziali ragioni dietro le differenze di performance per la dimensione del chunk'.
- 2025
Espansi i dati del "database vettoriale" con le potenziali ragioni dietro le differenze di performance.
Aggiornati i dati dei modelli di embedding, sostituendo Google Gemini con mistral-embed come la più alta accuratezza media.
Rimossa la sezione sui risultati del benchmark RAG.
Rimosso il numero di LLM dall'introduzione.
Espansa la sezione "Quali sono i modelli e gli strumenti RAG disponibili?" con nuovi modelli e strumenti.
Aggiunti i risultati del benchmark per i modelli di embedding e le dimensioni dei chunk alla sezione "Quali sono i vantaggi della generazione aumentata dal recupero?".
- 2024
Rimosse le statistiche sull'IA generativa dall'introduzione.
Aggiunta la sezione "Quali sono i diversi tipi di RAG?".
- 2023
Aggiunta una sezione sui modelli e strumenti RAG disponibili.
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.