Una pipeline RAG che risponde davvero dal manuale
Lezioni dal rilascio di un chatbot di supporto fondato su 1.400 pagine di manuali Extrema — con riduzione dei tempi interni del 60%.
Il RAG ingenuo restituisce risposte plausibili che non sono nel manuale. È il modo in cui il RAG muore in produzione, perché "plausibile ma sbagliato" è peggio di "non lo so". Il cliente viene dispacciato per il pezzo sbagliato e si perde un'unità di fiducia che non torna.
Il chatbot di Extrema è partito ingenuo. Chunking a 512 token, embedding ada-002, top-5 per cosine, prompt GPT-4. Demo magnifica. Prima settimana in produzione: ha detto a un cliente con sicurezza che il controller LV-450 si poteva hot-swap. Non si può. Un paragrafo su un controller diverso usava parole simili.
La correzione: tre livelli noiosi, niente modello nuovo. Primo, chunking section-aware. L'H2 sopra un paragrafo è metà del segnale. Abbiamo riscritto i chunk includendo il breadcrumb completo (Manuale → Capitolo → Sezione) come prefisso strutturale.
Secondo, retrieval ibrido. Embedding puro è bravo a parafrasare, pessimo sui codici di parte. BM25 sopra gli stessi chunk, fusion reciproco dei ranghi, poi re-rank con un cross-encoder piccolo. Il re-ranker è l'eroe non celebrato del RAG di produzione.
Terzo, un template di risposta che cita o rifiuta. Il sistema istruisce il modello a citare il numero di pagina per ogni claim fattuale, e a rispondere "non lo trovo nei manuali" se nessun chunk lo supporta. L'output è noioso: "Secondo Manuale pagina 142, passo 4: spegni l'interruttore, aspetta 60 secondi, svita il coperchio". La noia è la feature.
Impatto in Extrema: tempo di risposta interno -60%. La metrica che conta nel RAG non è la recall di retrieval. È "abbiamo rifiutato quando dovevamo rifiutare". Ottimizza per quello e tutto il resto segue.