Sviluppo RAG: risposte AI accurate a partire dalla conoscenza della vostra azienda

Cos'è lo sviluppo RAG e quando serve alla vostra azienda?

Lo sviluppo RAG è il lavoro di ingegneria che collega un large language model alla vostra conoscenza, così che le risposte provengano dai vostri documenti e non da ciò che il modello ha memorizzato durante l'addestramento. Un'azienda ha bisogno del RAG quando le persone continuano a porre domande le cui risposte esistono già da qualche parte all'interno: macro dell'assistenza, manuali di prodotto, contratti, policy, ticket passati, un wiki in cui nessuno riesce a cercare. Invece di riaddestrare un modello, un sistema RAG recupera i pochi passaggi che contano per ogni domanda e li passa al modello con l'istruzione di rispondere sulla base di quelli e di citarli.

Implementazioni RAG tipiche che ci vengono richieste:

• Un assistente interno che risponde alle domande del personale a partire da policy, procedure operative e wiki.
• Un assistente per l'assistenza clienti basato su articoli dell'help center e ticket risolti (vedete sviluppo chatbot AI).
• Ricerca e risposte su contratti, specifiche o documentazione tecnica.
• Un livello di "memoria" per un prodotto AI, così che l'assistente ricordi fatti su un utente o un account specifico.

Come funziona una pipeline RAG in produzione?

Una pipeline RAG in produzione ha due metà: un lato offline di ingestione che prepara la vostra conoscenza e un lato online di interrogazione che risponde alle domande. La maggior parte dei problemi di accuratezza nasce dal lato di ingestione, ed è per questo che vi dedichiamo vero tempo di ingegneria invece di trattarlo come uno script da eseguire una volta.

Come vanno suddivisi i documenti per il RAG?

Il chunking deve seguire la struttura dei vostri documenti, non un numero fisso di caratteri. Un buon default è dividere per intestazioni e paragrafi in passaggi di qualche centinaio di token, mantenere una piccola sovrapposizione e associare metadati a ogni chunk: titolo del documento, percorso della sezione, data, lingua e chi è autorizzato a vederlo. Il percorso delle intestazioni conta, perché un chunk che dice "il limite è di 30 giorni" è inutile se non si sa che proviene da "Rimborsi > Clienti UE".

Tipi di contenuto specifici richiedono una gestione specifica. Le tabelle vengono mantenute intere o convertite in affermazioni riga per riga. Le FAQ vengono divise con una domanda per chunk. I contratti lunghi vengono suddivisi per clausola mantenendo il numero della clausola. Chat e ticket vengono raggruppati per conversazione, non per riga. Testiamo due o tre strategie di chunking sullo stesso set di valutazione e teniamo quella che recupera più spesso il passaggio giusto, invece di andare a intuito.

Quali embedding e quale database vettoriale usare?

Il modello di embedding e il database vettoriale vanno scelti in base al volume dei dati, alle lingue e alle regole di hosting, ed entrambi devono poter essere sostituiti in seguito. Li teniamo dietro una piccola interfaccia nel codice, così cambiare provider è un lavoro di reindicizzazione, non una riscrittura.

Per gli embedding, i modelli ospitati di OpenAI e provider simili sono il modo più rapido per partire. I modelli di embedding open girano sui vostri server quando i dati non possono lasciare il vostro ambiente. I contenuti multilingue (ad esempio inglese più francese o ucraino) richiedono un modello testato su quelle lingue, cosa che verifichiamo durante la valutazione invece di darla per scontata.

Come si misura l'accuratezza del RAG?

L'accuratezza del RAG si misura con un set di valutazione fisso: da 50 a 200 domande reali dei vostri utenti, ciascuna con la risposta attesa e la fonte da cui dovrebbe provenire. Senza quel set, ogni discussione sulla qualità è un'opinione. Con quel set, ogni modifica a chunking, prompt, modelli o dati riceve un punteggio confrontabile.

Monitoriamo quattro numeri:

1. Retrieval hit rate: il passaggio corretto è comparso tra i primi risultati?
2. Fedeltà: la risposta afferma solo ciò che dicono i passaggi recuperati?
3. Correttezza della risposta: la risposta corrisponde a quella attesa, secondo un revisore o un valutatore LLM verificato su campioni umani?
4. Qualità del rifiuto: quando la risposta non è nella base di conoscenza, il sistema lo dice invece di inventarne una?

In produzione aggiungiamo il feedback degli utenti (pollice su o giù con un motivo), il log delle fonti recuperate per ogni risposta, il costo per richiesta e la latenza. Il set di valutazione viene eseguito automaticamente prima di ogni rilascio, come i test unitari.

E la privacy dei dati, i permessi e la scelta del modello?

Un sistema RAG non deve mai mostrare a un utente un passaggio che non potrebbe aprire nella fonte originale. Salviamo le regole di accesso come metadati dei chunk e filtriamo al momento del retrieval, così i permessi vengono applicati prima che il modello veda qualsiasi cosa. I dati sensibili possono essere cifrati in fase di ingestione; nel nostro progetto AI Grief Companion ogni messaggio è cifrato con AES-256-GCM per messaggio sotto una chiave envelope KMS, e un utente può cancellare tutto con un clic.

Per la fase di generazione lavoriamo con le API di OpenAI e Anthropic Claude e con modelli open serviti sulla vostra infrastruttura (lo stesso progetto esegue adapter Qwen2.5-7B tramite vLLM). La scelta dipende da regole sui dati, lingue, latenza e costo per risposta. Dove serve, i prompt vivono nel database con una cronologia delle versioni, così tono e istruzioni possono essere regolati senza un rilascio di codice.

Quanto costa lo sviluppo RAG?

Il costo dello sviluppo RAG dipende soprattutto da quante fonti collegate, da quanto sono disordinate e da quanto sono rigorosi i requisiti di accuratezza e di permessi. Un proof of concept su una fonte con un set di valutazione richiede tipicamente 3-6 settimane; un assistente in produzione con più fonti, permessi e interfaccia richiede 2-4 mesi; un RAG a livello di piattaforma su più prodotti con modelli su misura richiede di più.

I costi di esercizio sono separati: token del modello per risposta, costi di embedding a ogni reindicizzazione e hosting del database vettoriale. Durante il proof of concept stimiamo il costo per 1.000 domande, così non ci sono sorprese, e dopo una breve call di scoping forniamo un preventivo fisso per le milestone concordate. Con noi un assistente RAG sulla vostra conoscenza parte da 5.000 USD; la nostra guida al costo di sviluppo di un chatbot AI copre i perimetri più ampi.

Dove abbiamo costruito sistemi RAG e LLM?

Il nostro lavoro di retrieval più completo è AI Grief Companion per una startup statunitense: un gateway di ingestione in Python analizza dieci formati di esportazione chat in un'unica tabella di messaggi normalizzata, e una pipeline ML costruisce un profilo di personalità, un grafo di fatti in Neo4j, una memoria RAG e adapter LoRA. La chat usa sempre la fase che è pronta, così gli utenti possono parlare con il sistema prima che l'addestramento sia finito.

Sul lato prodotto, AI Resume Master, il nostro resume builder, usa gli LLM per generare, riscrivere e migliorare contenuti di curriculum e lettere di presentazione, e ha raggiunto 50.000 utenti attivi mensili. Per un quadro più ampio su come aggiungere funzionalità LLM a un prodotto esistente, vedete integrazione AI e la nostra guida all'implementazione RAG.

Come lavoriamo sui progetti RAG

Partiamo da una breve call di scoping e da una discovery: esaminiamo le vostre fonti, raccogliamo domande reali e costruiamo il set di valutazione insieme al vostro team. Poi consegniamo un proof of concept su una fonte con accuratezza misurata, e solo dopo estendiamo a più fonti, permessi e un'interfaccia di produzione. Gli ingegneri senior sono responsabili dell'architettura; internamente usiamo agenti di coding AI per procedere più rapidamente sulla parte infrastrutturale.

Se avete una base di conoscenza su cui le persone continuano a fare le stesse domande, prenotate una call di scoping e portate cinque domande di esempio. Vi diremo con onestà se il RAG è lo strumento giusto.