RAG spiegato ai founder

Se vuole integrare una funzionalità AI in grado di rispondere a domande sui suoi dati, sulla sua documentazione, sul suo prodotto o sulla sua knowledge base, sentirà parlare di due opzioni: fare il fine-tuning di un modello oppure usare RAG. Per quasi tutti i founder, RAG è la risposta giusta al primo tentativo, e capire il perché le farà risparmiare tempo e denaro.

Cos'è davvero RAG

La retrieval-augmented generation è più semplice di quanto suggerisca l'acronimo. Anziché sperare che il modello conosca già le sue informazioni, si recuperano i contenuti più rilevanti al momento della domanda e li si fornisce al modello come contesto. Il modello risponde quindi basandosi su ciò che gli è stato passato.

Il processo si articola in tre fasi:

1. Retrieve, trovare i frammenti di contenuto più pertinenti alla domanda dell'utente.
2. Augment, inserire quei frammenti nel prompt insieme alla domanda.
3. Generate, il modello risponde, ancorato al materiale recuperato.

Il modello non memorizza i suoi dati: li legge di volta in volta, come un esame a libri aperti.

Perché batte il fine-tuning nella maggior parte dei casi

Il fine-tuning incorpora la conoscenza nei pesi del modello. Sembra allettante, finché non ci si scontra con i problemi pratici: è costoso, difficile da aggiornare e insegna molto meglio lo stile che non i fatti. Quando i suoi contenuti cambiano — e cambiano sempre — bisognerebbe riaddestrare il modello.

RAG aggira tutti questi problemi:

• Sempre aggiornato. Aggiorni un documento e la risposta successiva lo rifletterà, senza riaddestrare nulla.
• Più economico. Nessuna sessione di training: si paga solo il retrieval e una chiamata di inferenza.
• Citabile. Poiché le risposte provengono da frammenti specifici, è possibile mostrare le fonti e costruire fiducia.
• Meno allucinazioni. Ancorare il modello a testi reali riduce drasticamente le risposte inventate.

Si ricorra al fine-tuning quando si vuole cambiare come si comporta il modello: tono, formato, una competenza specifica. Si usi RAG quando si vuole che sappia ciò che sa la sua azienda.

Come funziona il retrieval

Per trovare i frammenti rilevanti, si convertono i testi in embedding, vettori numerici che ne catturano il significato, e li si archivia. Al momento della domanda, si effettua l'embedding della query e si trovano i vettori memorizzati più simili per prossimità. Non serve un'infrastruttura pesante per iniziare: pgvector, un'estensione per PostgreSQL (disponibile anche su Supabase), gestisce la ricerca per similarità all'interno del database che già utilizza. Si valuti un database vettoriale dedicato solo quando la scala lo richiede.

Come fare RAG nel modo giusto

Una demo RAG funziona; una funzionalità RAG affidabile richiede cura:

• Suddivida i contenuti con criterio. Frammenti troppo grandi seppelliscono la risposta; troppo piccoli fanno perdere il contesto. Si suddivida per unità semantiche, non per conteggi arbitrari di caratteri.
• Recuperi abbastanza candidati, poi li riordini. Estragga una manciata di risultati e li riordini in modo che il contesto migliore venga presentato per primo.
• Gestisca il caso "nessuna risposta". Quando non viene trovato nulla di rilevante, il modello deve dirlo chiaramente, non improvvisare.
• Valuti continuamente. Mantenga un insieme di domande reali con risposte note e verifichi la qualità del retrieval man mano che i contenuti crescono.

Il fallimento più comune non riguarda il modello, ma il retrieval che restituisce i frammenti sbagliati. È lì che vale la pena concentrare gli sforzi.

Se sta costruendo una funzionalità per rispondere a domande sui suoi contenuti e vuole che sia accurata, ancorata ai fatti ed economica da gestire, ci contatti.