Quando porti sistemi RAG in production, la prima domanda è solitamente "quale modello di embedding, perché il costo dei token?" La domanda sbagliata. La domanda giusta: "se la precision del retrieval scende sotto 0.85, in quale percentuale la query dell'utente si trasforma in hallucination?" La struttura dei costi di RAG non è come l'inference batch — un retrieval scadente crea spreco esponenziale di token downstream e perdita di fiducia dell'utente. La scelta del modello di embedding, lo chunking e il setup di valutazione devono essere affrontati in questo contesto.
Modello di embedding: la granularità dello spazio latente prima del rapporto costo/token
Quando scegli il modello di embedding, l'ordine delle metriche da controllare è: retrieval precision → semantic drift → latency → costo/token. OpenAI text-embedding-3-large ha 3072 dimensioni, Cohere embed-v3 ha 1024, Voyage AI voyage-2 ha 1536 — questi numeri determinano la granularità dello spazio latente. Ma la vera differenza non sta nei benchmark, bensì nel comportamento su query domain-specifiche. Su una piattaforma di e-commerce, la query "giacca di pelle nera taglia M" produceva il 12% in più di falsi positivi con text-embedding-3-large, perché la parola "pelle" veniva codificata più come stile che come materiale. L'opzione di fine-tuning specifico del dominio di Voyage AI entra in gioco qui — un fine-tune di 2 settimane con 5000 coppie query-documento ha aumentato la precision rispetto al baseline del 18%.
Il calcolo dei costi funziona così: text-embedding-3-large costa $0.13 per 1M token, Cohere $0.10. Ma se la precision è bassa, il contesto sbagliato va al modello LLM — GPT-4o 10K token costano $0.30, quindi il retrieval errato significa 3K token in più = $0.09 in più per query. Con 100K query al mese, questo è uno spreco di $9.000. Risparmiare $30 sull'embedding per perdere $9.000 downstream è irrazionale. La latency funziona allo stesso modo: Cohere 45ms, Voyage 62ms — ma la qualità del retrieval di Voyage riduce la necessità di reranking del 40%, portando la latency totale della pipeline da 180ms a 140ms.
Per tracciare lo semantic drift, devi aggiungere query temporali al tuo eval set. Esegui la stessa query dell'utente a distanza di 3 mesi e confronta il set di documenti recuperati. Se il drift è superiore al 15%, il modello di embedding è esposto al concept drift in production — è necessario un retraining o un cambio di modello. Senza questo tracking, la scelta dell'embedding è una decisione al buio.
Strategia di chunking: l'illusione della dimensione fissa e il trade-off dell'overlap
L'errore più comune: chunk di dimensione fissa 512 token + 50 token di overlap. Questo approccio ingenuo ignora i confini semantici. Divide intestazioni Markdown, blocchi di codice, tabelle da metà, creando perdita di contesto nel retrieval. Alternativa: semantic chunking — usare gli embedding delle frasi per determinare dinamicamente i confini dei chunk in base a una soglia di somiglianza del coseno (ad esempio 0.75). SemanticChunker di LangChain fa questo, ma ha un overhead di latency del 30% — se la latency è critica, un approccio ibrido di character splitting ricorsivo + parsing consapevole delle intestazioni è più pragmatico.
Il trade-off dell'overlap: 0% overlap = perdita di informazioni al confine del chunk, 50% overlap = dimensione dell'indice 1.5x + aumento della latency della query del 25%. Il punto ottimale varia a seconda del dominio. Per la documentazione tecnica, il 25% di overlap (128 token @ 512 chunk) è più adatto, per i dati conversazionali il 10% (50 token). Test: crea un sottoinsieme di eval set chiamato "chunk boundary query" — query la cui risposta si trova tra due chunk. Come influisce l'aumento dell'overlap sulla retrieval precision per queste query? Nei nostri test, il 25% di overlap ha aumentato la precision da 0.68 a 0.81 sulle boundary query. È salita a 0.83 con il 50%, ma il costo di latency non giustifica un guadagno del 2%.
La scelta della dimensione del chunk non è binaria. I chunk da 256 token offrono retrieval più granulare, quelli da 1024 token più contesto per chunk. Ma quando la context window dell'LLM si riempie, 4 chunk da 1024 token = 4K token, mentre 16 chunk da 256 token = 4K token — lo stesso contesto, ma il chunking da 256 offre 4 volte più opzioni semantiche. Trade-off: costo di embedding 4x, ma diversità del retrieval più elevata. In production, un approccio ibrido funziona: 256 per FAQ/contenuti brevi, 768 per articoli lunghi. In questa architettura di analisi dei dati, il tracciamento della performance del chunking basato su log richiede identificazione — quale dimensione di chunk si comporta meglio per quale tipo di query?
Metadati del chunk: injection di campi JSON
Iniettare metadati in ogni chunk è critico per il filtraggio del retrieval. Campi come {category, created_at, author, content_type} forniscono filtraggio di metadati oltre la ricerca vettoriale. Esempio: la query "tutorial Python del 2025" abbina sia il match semantico che il filtro created_at > 2025-01-01. Questo approccio ibrido ha aumentato la retrieval precision del 22%. Pinecone, Weaviate e Qdrant supportano tutti il filtraggio dei metadati, ma la sintassi di query è diversa — usare LlamaIndex come livello di astrazione fornisce flessibilità.
Setup di valutazione: le metriche offline non possono prevedere hallucination in production
Per la valutazione RAG, le metriche offline sono: retrieval precision, recall, MRR (mean reciprocal rank), NDCG. Sono necessarie ma non sufficienti. Il vero problema in production: il contesto recuperato è corretto, ma l'LLM allucina comunque. Per questo serve valutazione end-to-end — confronto tra chunk recuperati + risposta LLM + risposta di ground truth. Il framework Ragas fa proprio questo: metriche come faithfulness, answer relevance e context precision tramite LLM-as-judge. Usiamo GPT-4o come judge e facciamo girare valutazioni batch — 1000 query eval set, completate in 24 ore.
La composizione dell'eval set: 60% query reali degli utenti (dal log di production), 20% edge case (intenzionalmente ambigui), 20% avversariali (informazioni obsolete, doc deprecati). Le query utente reali riflettono la distribuzione di production. I casi limite testano la gestione dell'incertezza del modello. L'insieme avversariale simula il temporal drift — una query 2026 basata su documentazione del 2023 dovrebbe includere un avviso "non aggiornato".
Per valutazione continua, ogni sprint (2 settimane) aggiungiamo 200 nuove query al set di eval. Campione casuale dal log di production + curation di edge case. Testiamo modifiche a modello/chunking/config di retrieval su questo set. Drop di precision superiore al 5% = rollback. La pipeline di eval gira su AWS Step Functions — embedding, retrieval, LLM inference, scoring, alert Slack. Runtime totale 45 minuti, costo $12 per eval run. Spingere in production modifiche RAG senza questo è blind deployment.
Reranking e query expansion: i livelli trascurati della pipeline di retrieval
La ricerca vettoriale da sola non basta. Dopo il retrieval top-K (ad esempio K=20), un modello di reranking (Cohere Rerank, bge-reranker) riordina in base alla rilevanza semantica e passa gli ultimi K=5 all'LLM — questo aumenta la retrieval precision del 30%. L'overhead di latency del reranking è 80ms, ma poiché il contesto errato non arriva all'LLM, l'affidabilità totale della pipeline migliora. Costo: Cohere Rerank $1 per 1K query — per 100K query al mese sono $100, ma ha ridotto lo spreco LLM da $9.000 a $3.000.
Query expansion: la query utente "come configurare RAG" è semplice, ma dovrebbe corrispondere anche a "retrieval-augmented generation implementation" nello spazio semantico. L'approccio HyDE (hypothetical document embedding): chiedi all'LLM di scrivere la risposta ideale per questa query, fai l'embedding della risposta, cerca con esso. Questo fornisce implicit query expansion. In production abbiamo visto un guadagno di precision del 15%, ma latency +120ms. Trade-off: se la latency è critica, la query expansion classica (injection di sinonimi) fornisce un guadagno simile in 40ms.
Monitoraggio in production: la qualità del retrieval non può essere ottimizzata se non è osservabile
In un sistema RAG devi monitorare: retrieval latency p50/p95/p99, retrieval cache hit rate, distribuzione dei score di rilevanza dei chunk recuperati, LLM faithfulness score (calcolato con LLM-as-judge), feedback utente (thumbs up/down). Spingiamo questi dati a Datadog come metriche personalizzate. Se il retrieval latency p95 supera 200ms, scatta un avviso — perché la latency totale rivolta all'utente ha SLA di 500ms, e se il retrieval supera 200ms, insieme all'LLM inference viola l'SLA.
Score di rilevanza del chunk recuperato: registra i score di somiglianza del coseno dei top-5 chunk per ogni retrieval. Se la distribuzione cambia (ad esempio, la media scende da 0.78 a 0.65), segnala drift nel modello di embedding o problemi di qualità del corpus. Tracciare questo all'interno della architettura dei dati first-party ti dà la possibilità di gestire proattivamente la qualità del retrieval.
Quando il costo diventa veramente importante, cosa fare?
Una volta stabilizzata la qualità del retrieval, se vuoi ottimizzare il costo: (1) Embedding cache — se la stessa query arriva di nuovo, servi dalla cache, TTL 6 ore. La hit rate è del 40%, cost dell'embedding ridotto del 40%. (2) Embedding quantizzati — invece di float32, usa int8, la dimensione dell'indice si riduce del 75%, la perdita di retrieval precision è del 2% — accettabile. (3) Hybrid search — sparse (BM25) + dense (vettore), sparse è il 70% più economico, le query semplici non richiedono ricerca vettoriale. Con routing basato su classificatore, il 30% delle query va a sparse, il 70% a vettore — costo ridotto del 20%.
Queste ottimizzazioni di costo devono avvenire solo dopo che la baseline di qualità del retrieval è stabilizzata. Altrimenti il taglio di costo cieco aumenta lo spreco LLM e il costo netto sale. Economia di RAG: embedding $500/mese, infra di retrieval $1.200/mese, LLM inference $8.000/mese. Risparmiare $100 sull'embedding riducendo la qualità del retrieval e aggiungendo $2.000 di spreco LLM è irrazionale. Ma quantizzare l'embedding con la qualità del retrieval fissata al 90% di precision, risparmiare $125 e aggiungere $50 di spreco LLM è razionale.
I sistemi RAG in production stanno diventando critici in automazione di marketing, supporto clienti e generazione di contenuti. Ma sono tutti costruiti sulla qualità del retrieval — un retrieval scadente riduce l'affidabilità dell'output AI a zero. Focalizzarsi sul costo senza mettere a posto il setup di modello di embedding, chunking, eval e monitoring è tentare di ottimizzare senza fondamenta. Ecco cosa devi fare adesso: se hai una metrica di retrieval precision nella tua pipeline RAG attuale, misurala; se non la hai, aggiungila. Poi guarda i costi.