RAG in produzione per software B2B
Una chat RAG demo che risponde da un dump di PDF non è un prodotto B2B. Il retrieval-augmented generation in produzione deve rispettare i confini tenant, citare fonti verificabili dagli operatori, sopravvivere a indici obsoleti e fallire in modo chiuso quando la confidence del retrieval è bassa. I buyer enterprise chiedono come le risposte sono grounded, chi vede quali documenti e cosa succede se il modello inventa una policy inesistente. Questa guida copre indexing, qualità retrieval, isolamento multi-tenant, evaluation, controllo costi e audit per SaaS custom e tool interni. Si collega a workflow agentici quando il RAG è un tool dentro un grafo più ampio, e a architettura multi-tenant e audit logging quando la knowledge diventa superficie di compliance.
Quando il RAG ha senso nei prodotti B2B (e quando no)
Il RAG ha senso quando le risposte devono unire un language model a corpora privati e che cambiano: policy, manuali, ticket, contratti, cataloghi, SOP. Vince sul fine-tuning quando il contenuto si aggiorna settimanalmente e servono citazioni. Non sostituisce la verità transazionale. Stato ordine, stock e totali fattura appartengono ad API e database, non a vector search sull'export di ieri sera. Se il lavoro è multi-step (crea ticket, posta su ERP, attendi approvazione), serve un workflow agentico che può chiamare il RAG come un tool, non una sola completion di chat.
- Buon fit: Q&A su policy con citazioni per tenant
- Buon fit: search su manuali più filtri strutturati
- Cattivo fit: inventare post ERP da prosa
- Cattivo fit: risposte non supervisionate su consigli regolati senza gate di review
Indexing e chunking che reggono documenti reali
Il chunking è lavoro di prodotto. Tabelle, header e step di procedura rompono gli split a dimensione fissa. Preferisci chunk structure-aware: sezione + path heading, numero pagina, versione documento, data di efficacia. Conserva metadata utili a retrieval e UI: tenant_id, site_id, label ACL, URI sorgente, checksum, ingested_at. Re-indexa su publish o cambio ACL, non solo su cron notturno. Dual-write o ingestion event-driven dal system of record battono scrape batch che driftano in silenzio. Tratta il lag dell'indice come SLO insieme alla latenza API.
- Mantieni parent document ID così la UI mostra il contesto pieno
- Versiona gli embedding quando cambi modello o strategia chunk
- Elimina o tombstone i chunk quando i documenti sono revocati
- Separa indici sperimentali dai path di retrieval produzione
Qualità retrieval: hybrid search, rerank e filtri
Il solo vector search fallisce su part number, SKU e titoli esatti di clausole. Hybrid lessicale + dense, poi un reranker, è lo stack tipico in produzione su corpora B2B. Applica sempre filtri hard prima della similarità: tenant, ACL, lingua, tipo documento, data di efficacia. Non recuperare prima e filtrare dopo se il leakage è un rischio. Passa abbastanza contesto per il grounding, non un dump dei cinquanta chunk più vicini. Limita i token, diversifica le fonti e restituisci esplicitamente 'nessuna fonte rilevante' quando gli score sono deboli.
Tenancy e ACL sul path di retrieval
Il RAG multi-tenant fallisce in modo catastrofico se gli embedding di un cliente possono apparire nella risposta di un altro. L'isolamento deve vivere nel filtro di query e nella strategia di partizione dell'indice, non solo nella UI della chat. Mappa i ruoli come nel resto del prodotto: viewer di plant vs admin HQ vs partner. I cambi ACL documento devono invalidare o ritaggare i chunk subito. Allinea a SSO e identity così il principal di retrieval è l'utente autenticato, non un service account condiviso senza scope.
- Forza tenant_id in ogni query di retrieval
- Logga i retrieval negati per review di security
- Testa leakage cross-tenant in CI, non solo nelle demo
- Tratta i dati staging contractor come un vero confine di tenancy
Grounding, citazioni e comportamento di refusal
Gli operatori si fidano delle risposte che possono aprire. Richiedi citazioni con titolo documento, sezione e link. Preferisci quote estrattive per claim di policy critici. Istruisci il modello a rifiutare o chiedere chiarimenti quando il retrieval è vuoto o in conflitto. Una risposta sbagliata con sicurezza batte 'non ho trovato questo nella knowledge base' in peggio. Per domini regolati o ad alto rischio, aggiungi review umana prima che la risposta esca dal sistema, oppure limita il RAG a modalità draft-only.
Evaluation harness prima che il pilot si espanda
Costruisci un golden set di domande con fonti attese e risposte accettabili per persona tenant. Misura hit rate retrieval, correttezza citazioni e faithfulness della risposta in modo separato. Regredisci a ogni cambio di chunking, embedding model, prompt o reranker. Feedback da pilot senza harness diventa tuning a vibes. Abbina a strategia di testing: unit test su filtri e ACL, integration test su ingestion, eval offline sulla qualità, e limited online shadow traffic prima del cutover.
- Traccia il rate di 'claim non supportati' come metrica di prima classe
- Includi casi avversariali e corpora vuoti
- Review dei failure con esperti di dominio, non solo engineer
- Gate delle release su soglie eval come ogni altro quality bar
Costi, latenza e operations
Spend di token e embedding crescono con dimensione corpus, volume chat e prompt ingenui tipo 'metti più contesto'. Cachea gli embedding, riusa il retrieval sui follow-up con cautela e budgetta il max context per request. Misura p95 di retrieve + generate separatamente. Gli utenti biasimano il prodotto, non il vector DB, quando un lookup in plant floor richiede dodici secondi. Osserva retrieval vuoti, errori tool e refusal del modello via osservabilità. Alerta su spike improvvisi di failure citazioni dopo job di reindex.
Audit trail per le risposte AI
I security questionnaire enterprise chiedono cosa ha visto il modello. Persisti versione prompt, ID chunk recuperati, filtri applicati, model ID e risposta finale per finestre di support e dispute. Le policy di retention devono coprire le trace AI come gli altri audit log. Redigi i secret dai prompt salvati; non loggare mai API key grezze o dump PII completi 'per debug'.
Scope di un MVP RAG senza bollire l'oceano
Parti da un corpus, una persona, un workflow (es. lookup SOP per operatori). Dimostra fiducia sulle citazioni e ACL prima di aggiungere cinque connector e uno swarm di agent. Usa prioritizzazione MVP e discovery tecnica per mappare quali documenti sono autorevoli e chi ne possiede gli aggiornamenti. Budgetta tempo per data hygiene; dump SharePoint sporchi dominano il costo più della scelta del modello.
Prossimi passi
Scegli dieci domande reali degli operatori e misura se oggi il retrieval restituisce la fonte giusta. Se no, sistema indexing e ACL prima del prompt engineering. Vedi agentic AI e LangGraph, altre risorse, case study, prenota una call o contatti se ti serve una review RAG di produzione prima di un pilot enterprise.
Domande frequenti
Serve un vector database per RAG B2B?
Spesso sì a scala, ma parti da ciò che lo stack già supporta se il corpus è piccolo e i filtri sono stretti. I problemi hard sono ACL, evaluation e freschezza ingestion, non il logo sullo store vettoriale.
Il fine-tuning è meglio del RAG per la knowledge aziendale?
Per documenti privati che cambiano spesso e con citazioni, vince il RAG. Il fine-tuning aiuta stile, linguaggio di dominio o classificazione stretta. Molti prodotti combinano entrambi dopo; non partire da lì.
Come preveniamo le allucinazioni in produzione?
Grounda le risposte sulle fonti recuperate, rifiuta quando il retrieval è debole, cita evidenze, valuta faithfulness e tieni umani nel loop per output ad alto rischio. Il solo wording del prompt non basta.
Un contractor può consegnare RAG in sicurezza?
Sì se l'acceptance include test di leakage ACL, soglie eval sul golden set, audit degli ID recuperati e runbook per reindex e rollback. Vedi le pratiche di assunzione contractor per quality gate oltre la demo brillante.