RAG e knowledge base interna per team B2B: pgvector + hybrid search in Lovable

“Possiamo fare un chatbot che risponda alle domande sulla nostra documentazione?” è probabilmente la richiesta più frequente del 2025-2026. La risposta corretta è: dipende. Dipende da quanta documentazione hai, da quanto cambia, da quanti utenti la consultano davvero, e — soprattutto — da cosa fanno oggi quando non trovano la risposta in Notion.

In questo articolo racconto come abbiamo implementato un sistema RAG interno per un team B2B usando Supabase pgvector e hybrid search, e quando questa scelta ha senso rispetto a un semplice “search potenziato” sulla wiki esistente. L’esempio viene da un progetto nel settore resale, ma i pattern valgono per qualunque team B2B con documentazione operativa stratificata.

Cosa intendiamo davvero per RAG

RAG — retrieval-augmented generation — vuol dire: prima di chiedere all’LLM di rispondere, recupero i pezzi di documentazione più rilevanti per la domanda e glieli passo nel contesto. Il modello non “sa” la tua documentazione; la legge al volo a ogni richiesta.

Sembra banale, ma il punto critico è il “recupero i pezzi più rilevanti”. Se il retrieval è scadente, il modello allucina o risponde generico. Se il retrieval è preciso, il chatbot è utile come un collega senior che ha letto tutto.

Perché pgvector e non un vector database dedicato

Per un team B2B con knowledge base sotto il milione di chunk, un vector database dedicato (Pinecone, Weaviate, Qdrant) è quasi sempre overkill. Aggiungi un servizio in più, un’altra fonte di verità, un’altra latenza di rete. Pgvector dentro Postgres è “abbastanza” performante fino a volumi che la maggior parte dei team B2B non vedrà mai, e ti permette di fare join con il resto del database in un’unica query.

Nel progetto reference, abbiamo circa 12.000 chunk (PDF e Word ingestiti) e le query restano sotto i 50ms al P95 su un’istanza Supabase standard. Non c’è bisogno di altro.

Il pattern: hybrid search batte il pure-semantic

Errore numero uno che vediamo in produzione: usare solo similarity semantica via embeddings. Funziona benissimo nei demo e male in produzione quando l’utente cerca un nome proprio, un codice SKU, una sigla interna o un acronimo. Il vettore “AB-1247-PRO” e il vettore “AB-1248-PRO” sono semanticamente identici, ma sono SKU diversi.

La soluzione è hybrid search: combini retrieval semantico (cosine similarity sugli embeddings) con full-text search (in Postgres tsvector con ts_rank). Ogni chunk recuperato riceve uno score combinato — nel nostro caso, una weighted sum con pesi 0.6 semantic / 0.4 keyword, che abbiamo tarato su un test set di domande reali.

Il risultato pratico: su 200 domande di test rappresentative del traffico reale, il pure-semantic dava una answer relevance del 71%; hybrid search è salito all’87% sullo stesso test set. Non è una rivoluzione algoritmica, è la differenza tra un chatbot “carino” e uno che il team usa davvero.

Chunking: l’altra metà del lavoro

L’altro punto cieco è il chunking. La maggior parte dei tutorial dice “spezza ogni 500 token”. In produzione fa schifo, perché taglia frasi a metà, rompe tabelle, separa una domanda dalla sua risposta.

Il pattern che funziona:

1. Segmentazione strutturale prima. Se il documento ha sezioni, paragrafi, tabelle, usali come confini naturali. Un PDF tecnico segmentato per H2 + H3 produce chunk molto migliori di una sliding window cieca.
2. Overlap controllato. 10-15% di overlap tra chunk consecutivi per non perdere contesto al taglio.
3. Metadata strutturati. Ogni chunk porta con sé documento_id, sezione, tipo (procedura/policy/glossario), data_aggiornamento. Sui metadata fai filter pre-search per ridurre il pool.
4. Re-chunk quando cambia la fonte. Trigger automatico: quando un PDF viene aggiornato, il chunking riparte e i vecchi embeddings vengono soppiantati.

L’AI Assistant con tool-use SQL

Su un altro progetto (ecommerce fashion) abbiamo costruito una variante interessante: un AI assistant streaming con Gemini 2.5 Pro che, oltre a fare RAG sulla documentazione, ha accesso a “tools” SQL safe per interrogare i dati live del catalogo e degli ordini.

“Safe” significa: il modello non scrive SQL liberamente. Ha a disposizione un set di tool predefiniti — get_orders_by_status, check_inventory(sku), customer_summary(email) — ciascuno con parametri tipizzati e RLS attiva sul ruolo del chiamante. L’LLM decide quale tool chiamare; il database si fida solo dei parametri, non del testo libero.

Questa è la differenza tra “AI fa domande in linguaggio naturale al DB” (rischio iniezione, query disastrose) e “AI orchestra strumenti che il backend già sa eseguire”. La prima è un demo, la seconda è una feature di prodotto.

Versionare i prompt: l’AI Library

Una cosa che si sottovaluta sempre: i prompt sono codice. Se il “master prompt” che orchestra il tuo RAG cambia, il comportamento del chatbot cambia. Senza versioning, dopo tre mesi nessuno sa più perché il bot dà risposte diverse rispetto al lancio.

Abbiamo costruito una “AI Library” interna: una UI dove i prompt sono versionati, ciascuno con metadata (autore, data, note di rilascio) e con un’area di test integrata. Quando si modifica un prompt, si fa pre-flight su un test set prima di promuoverlo in production. È esattamente lo stesso pattern di un feature flag su codice, applicato ai prompt.

Il voice gate: eval prima di mandare in produzione

Sopra l’AI Library c’è uno strato di eval: un set di domande standard a cui il chatbot deve rispondere correttamente, con criteri di valutazione (relevance, faithfulness al contesto recuperato, brand voice). Ogni nuovo prompt o cambio di modello passa per il gate. Se la regressione supera una soglia (per esempio, perde su più di 2 domande critiche), il rilascio si ferma.

Su un test set di 50 domande critiche, abbiamo bloccato 3 rilasci nell’ultimo trimestre per regressioni che sarebbero state invisibili in test manuali. È poco glamour ma è quello che separa un sistema RAG sperimentale da uno che il team usa per il proprio lavoro quotidiano.

Quando RAG conviene davvero (e quando no)

Questa è la domanda più importante e quella su cui vediamo i clienti incepparsi.

RAG ha senso quando:

• La documentazione è oltre i 100 documenti e cresce.
• Le risposte richiedono di pescare da più fonti per essere complete.
• Il team consulta i documenti più volte al giorno e perde tempo a cercare.
• C’è un’esigenza di disambiguazione (sigle, codici, varianti di prodotto).

RAG non conviene quando:

• La documentazione è statica e Notion search basta. In quel caso, migliora la struttura della wiki prima di pensare a RAG.
• I documenti cambiano ogni giorno e non hai pipeline di re-ingestion automatica.
• L’audience è una persona sola, che già sa dove cercare.

Una metrica realistica: nel progetto reference, su circa 40 utenti interni attivi, il chatbot RAG riceve circa 600 query/settimana e ha ridotto del 35% le richieste di supporto interno verso il team senior. Il ROI è arrivato in tre mesi, ma il payoff è arrivato perché il pre-lavoro su chunking e hybrid search era fatto bene — non per “magia AI”.

Se stai valutando se il tuo team B2B è pronto per un sistema RAG, la prima cosa da guardare non è la tecnologia. È quante volte al giorno qualcuno chiede a un collega “dov’è quella cosa, non la trovo”. Se la risposta è “tante”, parliamone.