Retrieval, embedding e vector search quando vuoi risposte piu affidabili e meno fumo

RAG: perché il modello da solo non basta in contesti enterprise

Un modello linguistico, per quanto potente, ha due limiti strutturali che lo rendono inutilizzabile in molti contesti aziendali: la conoscenza si ferma alla data di addestramento, e non sa nulla dei tuoi dati.

RAG, Retrieval Augmented Generation, risolve entrambi i problemi.

Invece di affidarsi solo alla memoria del modello, il sistema recupera i documenti più rilevanti al momento della query e li fornisce come contesto.

Il modello risponde basandosi su queste informazioni specifiche, non su generalizzazioni statistiche.

Il risultato è una risposta che può citare le fonti, che rimane aggiornata senza riaddestrare niente, e che non inventa dati perché li ha davanti.

Questo è il motivo per cui RAG è diventato il pattern di riferimento per applicazioni enterprise che devono rispondere su documentazione tecnica, procedure interne, normative o knowledge base aziendali.

Ma RAG non è un plugin che si installa: è un'architettura che va progettata.

La qualità del retrieval determina la qualità della risposta molto più del modello scelto.

E il retrieval dipende da come i documenti sono stati indicizzati, chunkati, e da quanto il sistema di ricerca capisce la query dell'utente.

Chunking, embedding e retrieval: le scelte che determinano la qualità

I tre passi fondamentali di una pipeline RAG sono il chunking dei documenti, la generazione degli embedding e il retrieval.

Ognuno introduce compromessi che impattano direttamente sulla qualità finale.

Chunking: come si suddivide un documento determina cosa entra nel contesto. Chunk troppo corti perdono il contesto della frase; chunk troppo lunghi consumano token e diluiscono la rilevanza. Il chunking semantico, che rispetta i confini di paragrafo o sezione, produce risultati migliori del chunking a finestra fissa ma richiede più lavoro di preprocessing.

Embedding: la scelta del modello di embedding influisce sulla qualità della ricerca semantica. I modelli OpenAI come text-embedding-3-small e text-embedding-3-large sono buoni default per l'italiano e l'inglese; per domini molto specializzati può valere la pena valutare modelli fine-tuned sul proprio corpus.

Retrieval: la ricerca vettoriale pura trova i chunk semanticamente simili alla query, ma può mancare documenti rilevanti su keyword specifiche. L'hybrid search, che combina ricerca vettoriale e full-text BM25, produce risultati più robusti e viene usato di default in Azure AI Search. Il reranking aggiunge un ulteriore passo di classificazione per migliorare la precisione.

RAG con Semantic Kernel in .NET: l'architettura pratica

Semantic Kernel in .NET offre le astrazioni necessarie per costruire una pipeline RAG senza accoppiare il codice a un provider specifico.

Il design permette di passare da Qdrant ad Azure AI Search cambiando la configurazione, non il codice applicativo.

La pipeline tipica si struttura in quattro fasi: indicizzazione (preprocessing + chunking + embedding + storage nel vector store), retrieval (query embedding + ricerca per similarità + filtri opzionali), augmentation (iniezione dei chunk rilevanti nel prompt) e generazione (chiamata al modello con il prompt arricchito).

In .NET il punto critico è la gestione asincrona di tutto il flusso: le chiamate agli embedding, al vector store e al modello sono tutte operazioni I/O-bound che beneficiano di async/await corretto e, dove possibile, di parallelizzazione.

Un errore comune è aspettare sequenzialmente operazioni che potrebbero girare in parallelo, moltiplicando la latenza.

L'altro punto critico è la testabilità: le interfacce di Semantic Kernel permettono di sostituire i componenti reali con mock per i test, ma richiede una progettazione consapevole del composition root per non trovarsi con dipendenze non iniettabili.

Quando RAG non basta e quali alternative considerare

RAG è potente ma non universale.

Ci sono scenari dove il pattern non è la risposta giusta.

Quando le domande richiedono ragionamento su dati strutturati, un LLM che genera SQL o chiama tool che interrogano direttamente il database produce risultati migliori.

RAG su un dump testuale di dati strutturati è una soluzione che funziona nei prototipi e degrada in produzione.

Quando la base documentale è molto grande e disomogenea, la qualità del retrieval tende a degradare perché i documenti rilevanti si perdono nella massa.

In questi casi Graph RAG, che costruisce un grafo di relazioni tra concetti invece di indicizzare testo flat, può migliorare significativamente il recall su query complesse.

Quando la latenza è un vincolo stringente, una pipeline RAG con retrieval, reranking e generazione può essere troppo lenta per certi contesti d'uso.

Si valuta allora il pre-caching delle risposte su query frequenti, la riduzione dei passi di retrieval o l'uso di modelli più veloci anche a scapito della qualità.

La scelta dell'architettura AI non è mai definitiva: va rivalutata man mano che si capiscono i pattern d'uso reali e i limiti che emergono in produzione.