Strategie di chunking RAG: 7 metodi classificati con i dati di retrieval (2026)

Strategie di chunking RAG: 7 metodi classificati con i dati di retrieval (2026)

Le strategie di chunking RAG decidono cosa il tuo retriever potrà trovare prima ancora che una query venga eseguita. Lo studio di Chroma del luglio 2024 ha eseguito 472 query su cinque corpus con text-embedding-3-large, e lo splitter che scegli sposta il recall di circa cinque punti: 86,7% per un semplice splitter a token, 91,7% per quello basato su GPT-4o, recuperando cinque chunk per query. La precision oscilla molto di più. Nell'intero rapporto va dall'1,5% all'8,0%, il che trasforma la scelta della dimensione dei chunk in una decisione di costo travestita da decisione di qualità, e tutte le guide in prima pagina elencano gli stessi sette metodi senza mostrare quale recupera meglio.

Punti chiave

• Il chunking suddivide i documenti prima dell'embedding; i punti di taglio decidono cosa il retriever può e non può trovare.
• Nello studio di Chroma del luglio 2024 su 472 query, il recall è andato dall'86,7% al 91,7% tra gli splitter misurati.
• La precision varia molte volte più del recall, quindi la dimensione dei chunk è soprattutto una decisione sul costo dei token.
• Parti da 512 token con il 10% di overlap, poi regola sul tuo eval set.

Quale strategia di chunking RAG conviene usare? (Classifica)

Per la maggior parte dei team che lavora su testo lineare, il chunking ricorsivo a caratteri a 512 token con il 10% di overlap è il default giusto. Rispetta i confini di paragrafo e frase, non costa nulla in più, e nel benchmark di Chroma su 472 query è arrivato a 3,2 punti di recall dallo splitter basato su LLM. Cambia solo se i tuoi documenti hanno una struttura forte o se il tuo eval set dimostra il contrario.

La nostra lettura: parti dal ricorsivo a caratteri. Nei dati di Chroma è dietro solo agli splitter cluster e LLM quanto a recall, e la precision del 3,9% dello splitter LLM significa che dai in pasto al generatore circa il doppio del rumore per ogni token rilevante. La maggior parte dei team non ha un problema di chunking; ha un problema di dimensione dei chunk che non ha mai misurato.

Cosa dicono davvero i dati sulla dimensione dei chunk?

L'unico confronto pubblico diretto tra strategie di chunking RAG è il report tecnico di Chroma "Evaluating Chunking Strategies for Retrieval" (Brandon Smith e Anton Troynikov, pubblicato il 3 luglio 2024). Hanno eseguito 472 query su 5 corpus (328.208 token), fatto l'embedding di tutto con OpenAI text-embedding-3-large e recuperato 5 chunk per query. Le righe qui sotto arrivano dalla tabella in appendice del report per tutti i corpus su text-embedding-3-large con 5 chunk recuperati, quindi sono direttamente confrontabili tra loro:

La tabella dei risultati principali di Chroma, che riporta un'impostazione di retrieval diversa, colloca la precision migliore del chunker cluster all'8,0% con un recall dell'87,3%, e estende l'intervallo di precision di tutti i suoi splitter dall'1,5% (KamradtSemanticChunker) all'8,0%. Fonte: Chroma Research, Evaluating Chunking Strategies

"Introducing Contextual Retrieval" di Anthropic (pubblicato il 19 settembre 2024) attacca il problema da un'angolazione diversa. Il loro tasso di fallimento del retrieval top-20 di base era del 5,7%; i soli contextual embedding lo hanno portato al 3,7% (riduzione del 35%), il BM25 contestuale aggiunto sopra lo ha portato al 2,9% (49%), e il reranking lo ha spinto all'1,9% (67%). Anthropic non pubblica la dimensione esatta dei chunk né l'overlap usato, quindi trattali come evidenze a livello di metodo, non di dimensione. Fonte: Anthropic, Contextual Retrieval.

La nostra lettura: tre conclusioni, pura aritmetica. Primo, la scelta dello splitter vale recall vero, e Chroma lo dice apertamente: alcune strategie superano le altre fino al 9% in recall. Nella sua tabella dei risultati principali il recall va dall'83,6% (KamradtSemanticChunker) al 91,9% (LLMSemanticChunker), e anche solo dentro le righe con 5 chunk recuperati qui sopra resta tra l'86,7% e il 91,7%. La precision si muove diverse volte di più sugli stessi dati: dall'1,5% all'8,0%, un'escursione di 5,3x contro l'1,1x del recall. Quindi il recall è dove guadagni qualche punto, mentre precision e costo dei token sono dove la scelta morde davvero. Secondo, lo splitter basato su LLM compra il recall massimo al prezzo della precision peggiore: paghi una chiamata LLM per documento e dai al generatore più rumore. Terzo, i numeri di Anthropic mostrano che arricchire i chunk con contesto (dal 5,7% al 3,7%) ha spostato il tasso di fallimento più di qualsiasi scelta di splitter nella tabella di Chroma. Arricchisci i chunk prima di rimettere mano allo splitter. Il reranking recupera i chunk rovinati dallo splitter, e la ricerca ibrida combina BM25 e retrieval vettoriale per lo stesso motivo.

Limiti onesti: entrambi gli studi usano un solo modello di embedding, corpus solo in inglese, e nessuno dei due è un test controllato sul tuo corpus. Su 472 query, il divario tra lo splitter migliore e il peggiore era di circa 5 punti di recall con 5 chunk recuperati, e un divario proporzionalmente molto più ampio sulla precision.

Perché la dimensione dei chunk decide la qualità del retrieval?

La dimensione dei chunk fissa la granularità della tua chiave di retrieval. Un chunk da 400 token produce un embedding focalizzato che corrisponde a query specifiche; un chunk da 4.000 token fa la media di molti temi e non corrisponde con precisione a nulla. Chunk piccoli recuperano il passaggio esatto ma possono frammentare una risposta su più risultati. Chunk grandi tengono insieme il contesto ma indeboliscono il segnale dell'embedding.

Anche il tetto di contesto del modello di embedding conta. Se il tuo modello si ferma a 512 token in input e gliene dai 800, la coda viene troncata in silenzio. Il tuo embedding rappresenta due terzi del chunk. Nessun errore a log.

Poi il lato del generatore. Liu e colleghi hanno mostrato in "Lost in the Middle" (arXiv 2307.03172, 2023) che l'accuratezza degli LLM cala di oltre il 20% quando il documento rilevante si trova in mezzo a un contesto lungo. Recuperare cinque chunk da 1.000 token scarica 5.000 token nel prompt, e la risposta che ti serve può finire nella posizione che il modello legge peggio. Chunk più piccoli tengono il passaggio rilevante più vicino a una posizione che il modello gestisce bene.

Pensa all'indice di una biblioteca. Una scheda che dice "Sezione 4.2, paragrafo 3: politica di rimborso" ti porta alla pagina. Una scheda che dice "tutto sul commercio nel XX secolo" ti porta all'edificio. Il tuo embedding è la scheda. Costruisci un'applicazione RAG da cima a fondo per vedere dove si colloca il chunking nella pipeline, e leggi la nostra guida al context engineering per capire come i chunk recuperati diventano token del prompt. La guida al chunking di Pinecone inquadra lo stesso trade-off dal lato del database vettoriale.

Chunking fisso e ricorsivo (parti da qui)

Il fisso è la baseline contro cui misuri tutto; il ricorsivo è quello che mandi davvero in produzione.

Chunking fisso a token

Taglia ogni N token indipendentemente dal contenuto.

def fixed_size_chunks(text: str, size: int = 512, overlap: int = 50) -> list[str]:
    tokens = text.split()  # whitespace proxy; use tiktoken for real token counts
    chunks = []
    step = size - overlap
    for i in range(0, len(tokens), step):
        chunk = " ".join(tokens[i : i + size])
        chunks.append(chunk)
        if i + size >= len(tokens):
            break
    return chunks

La risposta giusta per: testo lineare senza struttura di heading, prototipi rapidi e qualsiasi confronto di baseline. Non è stupido. È il gruppo di controllo.

Chunking ricorsivo a caratteri

Il RecursiveCharacterTextSplitter di LangChain suddivide su una gerarchia di separatori: prima \n\n (paragrafi), poi \n (righe), poi . (frasi), poi (parole). Ogni chunk resta sotto chunk_size rispettando il confine naturale più grande che ci sta.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""],
    length_function=len,  # swap for tiktoken len for true token counts
)
chunks = splitter.split_text(document)

La lista dei separatori è la parte che ogni concorrente omette. Lo splitter prova prima \n\n e passa a . solo quando un paragrafo supera chunk_size. Se il tuo Markdown ha degli header, aggiungi "## " prima di "\n\n" così le sezioni restano intatte.

Aritmetica dell'overlap: a 512 token con overlap di 50 token, il passo è 462. Un documento da 10.000 token produce ceil(10000 / 462) = 22 chunk. Totale token embeddati: 22 x 512 = 11.264, cioè stai ri-embeddando circa il 12,6% del corpus come overlap. È il costo di storage e API per evitare che le frasi al confine restino orfane.

Come funziona il chunking semantico, e vale il costo?

Il chunking semantico fa l'embedding di ogni frase, misura la distanza coseno tra gli embedding di frasi vicine e taglia dove quella distanza supera una soglia percentile (di solito il 95°). I chunk si spezzano sui cambi di argomento invece che su conteggi arbitrari di token. Il notebook "5 Levels of Text Splitting" di Greg Kamradt ha originato questo approccio a breakpoint percentile, e lo studio di Chroma mette alla prova i suoi chunker per nome.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
splitter = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)
chunks = splitter.split_text(document)

La matematica dei costi è la parte che nessuno mette in chiaro subito. Il chunking semantico embedda il corpus due volte: una per calcolare le distanze tra frasi e trovare i breakpoint, una per embeddare i chunk risultanti per l'indicizzazione. Al prezzo di text-embedding-3-large di OpenAI, 0,13 $ per 1M token, un corpus da 10M token costa 1,30 $ da indicizzare normalmente e 2,60 $ con il chunking semantico. Paghi il doppio prima ancora che una query venga eseguita.

Cosa ci compri? Nelle righe con 5 chunk recuperati di Chroma, il chunker semantico cluster ha raggiunto l'89,0% di recall e il 6,7% di precision contro l'88,5% e il 7,0% del ricorsivo alla stessa dimensione di 200 token. Nella tabella dei risultati principali lo stesso chunker segna la precision migliore dello studio, 8,0%, con un recall dell'87,3%. Mezzo punto di recall in un senso o nell'altro, e un risultato di precision che cambia segno a seconda dell'impostazione di retrieval che leggi, per il doppio della fattura di embedding. Il nostro verdetto: il chunking semantico ripaga su corpus con temi vari (archivi di notizie, raccolte di paper) dove i confini fissi tagliano in mezzo a un argomento di routine. Per corpus omogenei (documentazione di prodotto, una knowledge base), il ricorsivo ti dà il 95% della qualità a metà costo. Se esegui i modelli di embedding in locale con Ollama, il costo del doppio embedding si riduce a tempo di calcolo.

Chunking consapevole del documento: Markdown, HTML e codice

La suddivisione che rispetta la struttura usa i confini propri del documento (heading, voci di lista, definizioni di funzione) invece dei conteggi di caratteri. Un H2 in Markdown è un confine semantico che un umano ha posizionato di proposito; uno splitter a caratteri lo fa a pezzettini.

from langchain_text_splitters import MarkdownHeaderTextSplitter

headers = [("#", "h1"), ("##", "h2"), ("###", "h3")]
splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers)
splits = splitter.split_text(markdown_doc)
# Each split carries metadata: {"h1": "...", "h2": "...", "h3": "..."}

Per il codice, i confini sono i nodi dell'AST. I NodeParsers di LlamaIndex includono splitter che riconoscono il linguaggio e spezzano su definizioni di funzione e classe. Il dettaglio critico: tieni il blocco di import e la firma della classe contenente attaccati a ogni chunk di funzione. Il corpo di una funzione senza i suoi import è rumore non embeddabile, quindi anteporli entrambi a ogni chunk permette all'embedding di catturare cosa fa la funzione e da cosa dipende.

Per il RAG sul codice in particolare: suddivisione sui confini dell'AST, import anteposti, 256-512 token per funzione, overlap zero.

E il chunking late, gerarchico e agentico?

Queste sono le strategie di chunking RAG avanzate dietro il chiacchiericcio sul "RAG 2.0", e tutte e tre hanno una copertura in SERP di 1/10.

Late chunking

Il late chunking, introdotto da Günther e colleghi in "Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models" (arXiv 2409.04701, settembre 2024), prima fa l'embedding dell'intero documento con un modello long-context, poi aggrega gli embedding a livello di token in vettori di chunk, così ogni chunk porta con sé il contesto dell'intero documento e "costa 40 $/mese" sa a cosa si riferisce "costa". L'abstract rivendica un retrieval superiore su più task ma non pubblica un numero di punta che siamo riusciti a verificare. L'articolo di Weaviate spiega la meccanica e anche quello si ferma prima di un confronto controllato. Stato delle evidenze: promettente, non quantificato.

Chunking gerarchico (parent-child)

Indicizza chunk piccoli (256 token) per il retrieval; restituisci al generatore il padre (1.024 token). Il retriever trova l'ago; il generatore riceve il pagliaio intorno. Mantieni due livelli di indice e una mappatura padre-figlio. Nessun benchmark pubblico isola l'effetto.

Chunking basato su LLM / agentico

Il LLMSemanticChunker dello studio di Chroma usa GPT-4o per decidere i punti di taglio per documento: 91,7% di recall (il più alto) e 3,9% di precision (la più bassa). Paghi una chiamata LLM per documento al momento dell'indicizzazione (circa 100 $ per un corpus di 10.000 documenti) e dai al generatore più rumore. Riservalo ai corpus davvero irregolari: atti legali, PDF scansionati senza heading estraibili.

Quale dimensione di chunk si adatta al tuo modello di embedding?

Il massimo di token in input del tuo modello di embedding è un tetto di troncamento, non una raccomandazione. Un modello che accetta 8.192 token non embedda meglio a 8.192 che a 512. La qualità degrada per diluizione molto prima del tetto: il modello fa la media del significato su più token e il vettore deriva verso il centroide del corpus. La colonna delle raccomandazioni qui sotto è l'interpretazione di Techsy, non la guidance dei vendor.

Fonti: guida agli embedding di OpenAI, documentazione di Cohere embed, documentazione degli embedding di Voyage, model card di BGE.

Lo schema: i modelli con un tetto rigido di 512 token (Cohere v3, BGE) chiedono chunk ben sotto i 512, perché il troncamento è silenzioso. Daghene 600 e gli ultimi 88 spariscono dall'embedding senza alcun errore a log. I modelli con tetti ampi (OpenAI, Voyage, Cohere v4) tollerano chunk più grandi ma non li premiano. La lunghezza massima in input di un modello è un limite di troncamento, non una raccomandazione.

Abbina tutto questo alla nostra rassegna sui migliori modelli di embedding per RAG, a cosa misura davvero un punteggio MTEB e a Voyage, OpenAI e Cohere a confronto prima di impegnarti su un modello.

Come si fa il chunking di documenti non in inglese?

I tokenizer non sono neutrali rispetto alla lingua. Petrov e colleghi hanno mostrato in "Language Model Tokenizers Introduce Unfairness Between Languages" (arXiv 2305.15425, 2023) che lo stesso testo tradotto tra lingue può differire in lunghezza tokenizzata fino a 15x. Anche i modelli a livello di carattere e di byte mostrano differenze oltre 4x per alcune coppie di lingue. Un chunk da 512 token contiene molto meno significato in turco, arabo o giapponese che in inglese.

Ecco la stessa frase tokenizzata con la codifica cl100k_base di tiktoken (il tokenizer di GPT-4):

import tiktoken
enc = tiktoken.get_encoding("cl100k_base")
en = "The retrieval system returns relevant documents."
tr = "Erişim sistemi ilgili belgeleri döndürür."
ja = "検索システムは関連文書を返します。"
print(len(enc.encode(en)), len(enc.encode(tr)), len(enc.encode(ja)))
# 7 tokens, 19 tokens, 19 tokens: same meaning, 2.7x token spread

Conteggi generati con tiktoken cl100k_base, 30 luglio 2026.

Guida pratica: a una dimensione fissa di 512 token, i tuoi chunk in turco e giapponese contengono circa il 37% del significato dei tuoi chunk in inglese, e i tuoi chunk in arabo circa il 26%. Fai chunking per conteggio di caratteri o di frasi per lingua, oppure alza il budget di token in proporzione (circa 1.400 per il turco, 2.000 per l'arabo). Le lingue CJK non hanno confini di parola con spazi, quindi gli splitter a caratteri si comportano diversamente. La morfologia dell'arabo impacchetta più marcatori grammaticali in singoli token, gonfiando ulteriormente i conteggi.

Un albero di decisione per scegliere la strategia di chunking

What kind of document?
├── Structured (Markdown / HTML / code)
│   └── Document-aware splitting on headers or AST boundaries
│       ├── Docs site → MarkdownHeaderTextSplitter, 512 tokens, 0 overlap
│       └── Codebase → AST/function splitter, 256-512 tokens, imports prepended
├── Flat prose (articles, reports, books)
│   └── RecursiveCharacterTextSplitter, 512 tokens, 50 overlap
│       └── Topic-diverse? → try SemanticChunker at 95th percentile
├── Conversational logs (chat, support tickets)
│   └── Split on turn boundaries, group 3-5 turns per chunk, 256 tokens
└── Mixed corpus
    └── Route by MIME type → apply per-type strategy above
        └── Then: how long are expected answers?
            ├── Short (1-2 sentences) → child 256, no parent
            └── Long (multi-paragraph) → hierarchical: child 256, parent 1,024

Tre prescrizioni rapide. Chatbot su documentazione: MarkdownHeaderTextSplitter a 512 token, overlap zero, percorso degli heading nei metadati. Assistente per la ricerca nel codice: suddivisione sui confini dell'AST a 256-512 token per funzione, import anteposti. Corpus aziendale misto: instrada per tipo di documento all'ingestione e salva nel database vettoriale in cui salvi i chunk con metadati di tipo per la taratura per tipo più avanti. Questo instradamento per documento è l'intero chunking adattivo per applicazioni RAG.

Strumenti: LangChain vs LlamaIndex vs Chonkie

Non vendiamo nessuno di questi; le prime tre pagine in classifica per questa keyword sono blog di vendor con CTA di prodotto.

Fonti: documentazione di LangChain, NodeParsers di LlamaIndex, documentazione di Chonkie.

Tutti e tre implementano gli stessi algoritmi di base, quindi scegli in base a quello che la tua pipeline usa già. Per lo stack di strumenti RAG oltre agli splitter e il confronto tra Qdrant, Chroma e pgvector per lo storage, vedi le guide del nostro cluster.

Come Techsy affronta il chunking

Sulle build RAG per i clienti, il team di Techsy parte da 512 token con il 10% di overlap e non tocca lo splitter finché non abbiamo costruito un eval set di 20-50 domande dai ticket di supporto reali del cliente. Prima viene l'eval set; poi cambiamo una variabile alla volta: dimensione, overlap, strategia. Niente cambio di splitter senza un numero prima-e-dopo sulle stesse domande. Richiedi una consulenza gratuita per un secondo paio di occhi sulla tua pipeline di retrieval.

Domande frequenti

Cos'è il chunking nel RAG?

Il chunking è la fase di preprocessing che suddivide i documenti in segmenti più piccoli prima dell'embedding, così il retriever può confrontare le query con passaggi focalizzati invece che con file interi. I punti di taglio determinano cosa il tuo sistema può e non può trovare al momento della query.

Qual è la migliore strategia di chunking per il RAG?

Per la maggior parte dei sistemi in produzione su documenti generici, il chunking ricorsivo a caratteri a 512 token con il 10% di overlap è il default più solido. Nello studio di Chroma su 472 query (luglio 2024) ha segnato l'88,5% di recall, entro 3,2 punti dal metodo basato su LLM più costoso, a costo aggiuntivo zero.

Qual è la dimensione ottimale dei chunk per il RAG?

Parti da 512 token. Scendi a 256 se il tuo modello di embedding ha un tetto di 512 token in input (Cohere v3, BGE) o se le tue query si aspettano risposte di una sola frase. Sali a 1.024 solo se il tuo eval set mostra risposte multi-paragrafo che vengono frammentate. Misura sempre sulle tue domande.

Quanto overlap tra chunk dovrei usare?

Il 10-20% della dimensione del chunk (50-100 token a 512). L'overlap evita che le frasi al confine restino orfane: un fatto diviso tra due chunk compare completo in almeno uno. Oltre il 20%, ri-embeddi troppo del corpus per ritorni decrescenti. La maggior parte dei team si assesta sul 10% e non ci torna più.

Il chunking semantico è meglio del chunking a dimensione fissa?

Di poco, e al doppio del costo di embedding. Il benchmark di Chroma del luglio 2024 ha mostrato il chunker semantico cluster all'89,0% di recall e 6,7% di precision contro l'88,5% di recall e il 7,0% di precision del ricorsivo alla stessa dimensione di token, con il suo risultato migliore di precision all'8,0% che arriva da un'impostazione di retrieval diversa. Vale la pena per corpus con temi vari; difficile da giustificare per insiemi di documenti omogenei.

La dimensione dei chunk dipende dal modello di embedding?

Sì. I modelli con un tetto di 512 token in input (BGE, Cohere v3) richiedono chunk ben sotto i 512 perché il troncamento è silenzioso. I modelli con tetti di 8.192+ tollerano chunk più grandi ma non li premiano; la qualità dell'embedding degrada per diluizione prima del tetto. Vedi la tabella di abbinamento qui sopra per i punti di partenza per modello.

Come faccio il chunking del codice per un sistema RAG?

Spezza sui confini dell'AST (definizioni di funzione e classe) invece che sui conteggi di token. Tieni ogni chunk tra 256 e 512 token per funzione, anteponi il blocco di import del file e la firma della classe contenente, e usa overlap zero perché le funzioni sono unità autonome. Il CodeSplitter di LlamaIndex e gli splitter language-aware di LangChain gestiscono entrambi la cosa.

Cos'è il late chunking?

Il late chunking prima fa l'embedding dell'intero documento con un modello long-context, poi aggrega gli embedding a livello di token in vettori di chunk. L'embedding di ogni chunk porta con sé il contesto dell'intero documento, risolvendo il problema "a cosa si riferisce 'ci'?". Introdotto da Günther e colleghi (arXiv 2409.04701, settembre 2024). Nessun benchmark pubblico diretto quantifica ancora il guadagno.

Come faccio il chunking di documenti in lingue diverse dall'inglese?

I conteggi di token non sono neutrali rispetto alla lingua. La stessa frase ha richiesto 2,7x più token in turco e giapponese che in inglese, e 3,9x in arabo (tiktoken cl100k_base). Un budget fisso di 512 token dà in silenzio meno significato ai chunk non in inglese. Fai chunking per conteggio di caratteri o frasi per lingua, oppure alza il budget in proporzione.

Come capisco se il mio chunking sta davvero funzionando?

Costruisci un eval set di 20-50 domande dalle query reali degli utenti prima di toccare lo splitter. Calcola hit@5 e MRR sui tuoi chunk attuali. Cambia una variabile (dimensione, overlap, strategia), riesegui, confronta. Senza un eval set, stai regolando a sensazione. Venti domande bastano per partire.

In sintesi

• Parti dal chunking ricorsivo a caratteri a 512 token, 10% di overlap. Default giusto per il testo lineare.
• Tra le quattro famiglie di splitter che qualcuno abbia misurato, le 472 query di Chroma spostano il recall di circa 5 punti e la precision diverse volte di più. Taratura prima su precision e costo.
• Abbina la dimensione dei chunk al tetto di input del tuo modello di embedding. Un modello con tetto di 512 token chiede chunk sotto i 512.
• Arricchisci i chunk con contesto (il calo del tasso di fallimento di Anthropic dal 5,7% al 3,7%) prima di rimettere mano allo splitter.
• Costruisci prima l'eval set. Ogni decisione sullo splitter senza un numero prima-e-dopo è un'ipotesi.

Per la pipeline completa intorno alla tua scelta di chunking, vedi costruire un'applicazione RAG da cima a fondo. Stai ancora decidendo tra retrieval e fine-tuning? RAG o fine-tuning spiega quando vince ciascuno dei due.