RAG Spiegato per i Founder: Come Dare Contesto Aziendale a un LLM

Hai provato ChatGPT per il tuo business. E impressionante -- finche non gli chiedi dei TUOI clienti, dei TUOI prodotti, dei TUOI processi interni. A quel punto inizia a inventare. Nomi falsi, dati inesistenti, policy che non hai mai avuto. Hallucina perche non ha i tuoi dati.

Non e un bug. E una limitazione fondamentale. GPT-4o, Claude 3.5, Llama 3.1 -- tutti gli LLM hanno una conoscenza generale enorme ma zero conoscenza della tua azienda. Non sanno chi sono i tuoi clienti, cosa dice la tua documentazione interna ne quali sono le tue politiche di reso.

La buona notizia: c'e una soluzione che non richiede di riaddestrare nessun modello. Si chiama RAG. E probabilmente e la tecnica di IA piu rilevante per la tua startup in questo momento.

Il problema: un LLM generalista non conosce il tuo business

Pensa a un LLM come a un dipendente estremamente intelligente che sa un po' di tutto ma che e appena arrivato nella tua azienda. Sa programmare, scrivere, analizzare dati -- ma non ha accesso alla tua wiki interna, al tuo CRM, ai tuoi contratti ne alla tua knowledge base.

Se gli chiedi "qual e la nostra politica di rimborso per i clienti enterprise?", inventera una risposta che suona plausibile. Non perche sia disonesto, ma perche non ha altra scelta. Riempie i vuoti con probabilita, non con fatti.

Il fine-tuning (riaddestrare il modello con i tuoi dati) sembra la soluzione ovvia, ma ha problemi seri: e costoso, richiede competenze specializzate, i dati diventano obsoleti in fretta e devi ripetere il processo ogni volta che le tue informazioni cambiano.

Ed e qui che entra in gioco RAG.

Cos'e RAG e perche conta

RAG (Retrieval-Augmented Generation) e una tecnica che da all'LLM accesso ai tuoi documenti nel momento in cui deve rispondere a una domanda. Non riaddestri il modello. Invece, gli passi le informazioni rilevanti come contesto insieme alla domanda dell'utente.

E come dare a quel nuovo dipendente accesso all'archivio aziendale prima che risponda a ogni domanda. Il modello resta lo stesso, ma ora ha dati reali con cui lavorare.

Il concetto e semplice. L'implementazione ha le sue sfumature, ma non e scienza missilistica. Qualsiasi team di ingegneria senior puo costruire un sistema RAG funzionale in settimane.

Come funziona RAG: i 3 passi

Passo 1: Indicizza i tuoi dati

Prendi i documenti che vuoi che l'LLM possa consultare: PDF, wiki, database, email, documentazione tecnica, ticket di supporto. Tutto cio che e rilevante.

Ogni documento viene diviso in chunk (frammenti). Un chunk puo essere un paragrafo, una sezione, una pagina -- dipende dal tuo caso d'uso. Poi ogni chunk viene convertito in un embedding: una rappresentazione numerica (un vettore) che cattura il significato semantico del testo.

Non devi capire la matematica dietro gli embedding. L'importante e che due testi con significato simile avranno embedding vicini. "Politica di reso per clienti premium" e "rimborso per account enterprise" avranno vettori simili, anche se usano parole diverse.

Passo 2: Memorizza gli embedding

Quei vettori vengono salvati in un database vettoriale. Le opzioni piu comuni:

• Pinecone: managed, facile per iniziare, scala bene.
• Weaviate: open source, molto flessibile.
• Qdrant: open source, ottime prestazioni.
• pgvector: estensione di PostgreSQL. Se usi gia Postgres, puoi iniziare senza aggiungere nuova infrastruttura.

Per la maggior parte delle startup, pgvector e l'opzione piu pragmatica. Hai gia PostgreSQL. Aggiungere un'estensione e molto piu semplice che gestire un nuovo database.

Passo 3: Query in tempo reale

Quando un utente fa una domanda:

1. La domanda viene convertita in un embedding (stesso processo dei documenti).
2. Si cercano i chunk piu simili nel database vettoriale -- i frammenti dei tuoi documenti il cui significato e piu vicino alla domanda.
3. Quei chunk vengono iniettati nel prompt dell'LLM come contesto: "Basandoti sulle seguenti informazioni, rispondi alla domanda dell'utente: [chunk rilevanti]".
4. L'LLM genera una risposta usando i TUOI dati, non la sua conoscenza generale.

Il risultato: risposte fondate su informazioni reali della tua azienda. Niente allucinazioni. Niente invenzioni.

Quando ha senso implementare RAG

RAG non e la soluzione per tutto, ma e la soluzione giusta per molti casi d'uso comuni nelle startup:

• Knowledge base interne: dipendenti che consultano documentazione, processi, policy.
• Chatbot di supporto clienti: risposte basate sulla tua documentazione reale, non sulla conoscenza generale del modello.
• Ricerca su documenti: trovare informazioni rilevanti in migliaia di documenti legali, tecnici o finanziari.
• Query di compliance: rispondere a domande normative usando la tua documentazione di conformita.
• Sales enablement: dare al tuo team commerciale risposte precise su prodotti, prezzi e confronti con i competitor.

Il pattern comune: hai un corpus di documenti che i tuoi utenti (interni o esterni) devono consultare, e vuoi un'interfaccia conversazionale che dia risposte precise.

Quando RAG NON basta

Ci sono limiti. E importante conoscerli prima di iniziare:

• Quando hai bisogno che il modello impari pattern nuovi. RAG da contesto, non apprendimento. Se hai bisogno che il modello classifichi ticket di supporto secondo categorie specifiche della tua azienda, potresti aver bisogno del fine-tuning.
• Quando i dati cambiano in tempo reale. RAG funziona bene con documenti che si aggiornano periodicamente (giornalmente o settimanalmente). Se ti servono dati al secondo -- quotazioni di borsa, inventario in tempo reale -- ti serve una pipeline di streaming, non solo RAG.
• Quando la precisione deve essere del 100%. RAG migliora enormemente la precisione, ma non la garantisce al 100%. Per decisioni mediche, legali vincolanti o finanziarie ad alto rischio, ti serve la validazione umana nel loop.

Errori comuni da evitare

Ho visto questi errori ripetersi in quasi tutti i team che implementano RAG per la prima volta:

Chunk troppo grandi. Se ogni chunk e un documento intero di 20 pagine, stai iniettando troppo rumore nel prompt. L'LLM riceve troppe informazioni irrilevanti e la qualita della risposta ne risente. Chunk di 200-500 token sono un buon punto di partenza.

Chunk troppo piccoli. L'estremo opposto: frammenti di una sola frase perdono contesto. Se un chunk dice "il limite e 30 giorni" ma non dice "per i rimborsi dei clienti enterprise", la risposta sara incompleta. Ti serve un equilibrio tra specificita e contesto.

Nessuna pipeline di valutazione. Implementi RAG, "funziona", e lo metti in produzione. Ma come sai se sta davvero trovando i documenti giusti? Come misuri se le risposte sono precise? Ti servono metriche: relevance score, faithfulness, answer correctness. Senza valutazione, navighi alla cieca.

Nessun filtro per rilevanza. A volte il database vettoriale restituisce i chunk "piu simili", ma nessuno e davvero rilevante. Se lo score di similarita e basso, e meglio che il sistema dica "non ho informazioni su questo" invece di forzare una risposta con dati tangenzialmente correlati.

Fidarsi che l'LLM dira "non so". Gli LLM sono estremamente scarsi nel dire "non so". Anche con contesto RAG, se la risposta non e nei documenti, molti modelli proveranno a rispondere comunque. Ti servono guardrail espliciti nel tuo sistema per gestire questi casi.

Build vs buy: la decisione pratica

Hai due percorsi:

Framework esistenti: LangChain e LlamaIndex sono i piu popolari. Ti danno componenti pre-costruiti per chunking, embedding, retrieval e generazione. Accelerano lo sviluppo iniziale, ma aggiungono dipendenze e a volte astrazione non necessaria.

Pipeline custom: costruisci ogni componente separatamente. Piu lavoro iniziale, ma controllo totale. Per casi d'uso semplici (un chatbot sulla tua documentazione), una pipeline custom con pgvector e l'API di OpenAI o Anthropic puo essere piu semplice di un framework.

La mia raccomandazione: inizia con una pipeline semplice e custom. Se la complessita cresce (multiple fonti dati, re-ranking avanzato, hybrid search), allora valuta un framework. Non partire con la soluzione piu complessa.

Chi dovrebbe costruire il tuo sistema RAG

RAG e concettualmente semplice ma i dettagli implementativi contano molto. Strategia di chunking, selezione del modello di embedding, tuning della retrieval, prompt engineering, valutazione -- ogni decisione influenza la qualita del risultato finale.

Non ti serve un team di ricercatori di IA. Ti servono ingegneri senior che abbiano costruito sistemi RAG in produzione e sappiano dove sono i gotcha. Che abbiano iterato su strategie di chunking, testato diversi modelli di embedding e costruito pipeline di valutazione reali.

In Conectia, gli ingegneri che valutiamo per progetti di IA hanno lavorato su implementazioni reali di RAG -- non su demo o tutorial. Conoscono la differenza tra un prototipo che funziona in un notebook e un sistema che funziona in produzione con dati reali, a scala e con utenti che fanno domande che non erano nel piano originale.

Se stai valutando RAG per il tuo prodotto, la differenza tra un buon risultato e una cattiva esperienza utente sta nell'esperienza del team che lo costruisce. Un ingegnere senior con esperienza in RAG puo farti risparmiare mesi di iterazione e errori che qualcuno ha gia commesso prima.

---

Vuoi implementare RAG nel tuo prodotto ma non hai il team con esperienza in produzione? Parla con un CTO -- ti colleghiamo con ingegneri senior che hanno gia costruito sistemi RAG reali, pronti a integrarsi in 72 ore.