RAG spiegato a chi non è un data scientist (con Supabase pgvector)

Tempo di lettura: 8 minuti — Livello: intermedio

Partiamo dal problema, come sempre

Ho una knowledge base di lavoro con centinaia di voci: FAQ operative, procedure, risposte a domande ricorrenti. Il sogno: un assistente a cui il team chiede in linguaggio naturale ("come si gestisce il caso X?") e che risponde usando quella base di conoscenza — non le sue nozioni generiche.

Il problema: non puoi incollare centinaia di documenti in ogni conversazione con un'IA. Serve un meccanismo che, per ogni domanda, peschi solo i pezzi rilevanti e li passi al modello. Quel meccanismo si chiama RAG: Retrieval-Augmented Generation. Recupero, poi generazione.

L'idea in tre passaggi

1. Prepara: spezza la knowledge base in frammenti e trasforma ogni frammento in un "embedding"
2. Recupera: quando arriva una domanda, trasformala allo stesso modo e trova i frammenti più simili
3. Genera: passa domanda + frammenti trovati al modello, che risponde basandosi su quelli Tutto il trucco sta nella parola "simili". E per capirla serve capire cos'è un embedding.

Gli embedding, senza matematica

Un embedding è la traduzione di un testo in una lunga lista di numeri (un vettore) che ne cattura il significato. La proprietà magica: testi con significato simile producono vettori vicini tra loro, anche se non condividono nemmeno una parola.

"Come disdico il contratto?" e "procedura di recesso del cliente" sono lontanissimi come parole, vicinissimi come vettori. Ed è per questo che il RAG batte la vecchia ricerca per parole chiave: cerca per senso, non per lettere.

Gli embedding non li calcoli tu: li chiedi a un modello apposito via API (io uso quelli di OpenAI). Mandi il testo, ricevi il vettore.

Dove metto i vettori: Supabase + pgvector

I vettori vanno salvati in un posto che sappia rispondere alla domanda "dammi i 5 più vicini a questo". Esistono database nati apposta, ma la mia scelta è più prosaica: Supabase, cioè un normale PostgreSQL gestito, con l'estensione pgvector.

Perché mi piace questa strada:

• È Postgres. Un database normale, con tabelle normali: i frammenti di testo, i loro metadati (categoria, fonte, data) e i vettori vivono nella stessa riga. Query SQL classiche e ricerca semantica insieme, senza sincronizzare due sistemi.
• Piano gratuito generoso per iniziare, e n8n ci parla senza attriti.
• Un pezzo in meno da imparare. Il RAG ha già abbastanza parti in movimento; il database è l'ultimo posto dove voglio esotismo. La tabella, concettualmente:

create table documenti (
  id bigserial primary key,
  contenuto text,          -- il frammento di testo
  categoria text,          -- metadato per filtrare
  embedding vector(1536)   -- il vettore
);

E la ricerca dei frammenti più simili è una query con l'operatore di distanza di pgvector, ordinata per vicinanza, con un limit 5.

La pipeline completa (orchestrata da n8n)

Ingestione (quando la knowledge base cambia): n8n legge le voci nuove o modificate dalla fonte → chiama l'API di embedding per ciascuna → scrive testo + vettore + metadati su Supabase.

Interrogazione (quando arriva una domanda): n8n riceve la domanda → embedding della domanda → query pgvector per i frammenti più vicini → costruisce il prompt "rispondi usando SOLO queste informazioni: [frammenti]" → il modello genera la risposta.

I tre errori che ho fatto (così li eviti)

1. Frammenti troppo grandi. All'inizio embeddavo documenti interi. Risultato: la ricerca trovava il documento giusto ma il modello riceveva pagine di contesto inutile intorno alla risposta. La dimensione giusta del frammento è quella che contiene una unità di senso — nel mio caso una coppia domanda/risposta, o una singola procedura.

2. Niente metadati. La prima versione salvava solo testo e vettore. Poi è arrivata l'esigenza ovvia: "cerca solo tra le FAQ dell'area commerciale". Senza una colonna categoria, impossibile. Metti i metadati da subito: costano zero all'inizio, costano una re-ingestione completa dopo.

3. Fidarsi ciecamente del recupero. A volte i frammenti più "vicini" non contengono comunque la risposta. Se non lo gestisci, il modello improvvisa — con sicurezza. Nel prompt va scritto esplicitamente: "se le informazioni fornite non bastano, dì che non lo sai". È una riga. Cambia tutto.

Vale la pena?

Se hai una base di conoscenza che il team consulta di continuo, sì, ed è uno dei progetti col miglior rapporto impatto/sforzo che abbia fatto. Ma il valore non sta nella tecnologia: sta nella qualità della knowledge base. Il RAG è un amplificatore — amplifica contenuti buoni e amplifica il disordine con la stessa efficienza. Prima sistemi i contenuti, poi li vettorizzi. Nell'ordine inverso, ottieni solo risposte sbagliate più velocemente.

---

Questo articolo fa parte della serie "Sviluppare con l'IA" su perfetti.tech — dove racconto quello che costruisco davvero, errori compresi.