Chatbot conversazionale su WhatsApp con RAG e orchestrazione n8n

Premessa operativa e domanda di ricerca

Il canale WhatsApp concentra una frazione crescente delle richieste informative rivolte alle organizzazioni: la messaggistica asincrona riduce i costi di attenzione dell’utente e impone, tuttavia, risposte brevi, contestuali e verificabili. Il problema centrale non è solo generare testo plausibile, ma vincolare la distribuzione delle risposte affinché resti supportata da estratti documentali effettivamente presenti nel patrimonio informativo approvato. Da questo deriva l’adozione di paradigmi di Retrieval-Augmented Generation (RAG), nei quali il modello linguistico non opera come unica fonte di verità, ma come modulo di generazione condizionato da un sottoinsieme di contesto recuperato dinamicamente.

Formalmente, si cerca una mappa che associ a ogni interrogativo dell’utente una risposta la cui massa di probabilità sia concentrata su formulazioni coerenti con un insieme finito di evidenze documentali, riducendo la massa assegnata a contenuti non attestati.

Recupero semantico e similarità in spazio embedding

Il primo stadio costruisce rappresentazioni dense della domanda e dei segmenti documentali (chunk) nello stesso spazio vettoriale. La selezione dei candidati si basa sulla similarità coseno tra vettori normalizzati: tale scelta è computazionalmente efficiente e geometricamente interpretabile come misura dell’angolo tra direzioni semantiche.

Indichiamo con $\mathbf{q}$ l’embedding della query e con $\mathbf{d}_i$ quello dell’i-esimo chunk. In pratica si mantiene un insieme $\mathcal{C} = \{c_1,\ldots,c_k\}$ ottenuto tramite ricerca approssimata nel database vettoriale; il parametro $k$ (cosiddetto "top‑k") media il compromesso tra ricchezza contestuale e latenza di inferenza.

Generazione condizionata e controllo della massa di probabilità

Il modello linguistico riceve la query e il contesto recuperato; idealmente, la risposta ottimale massimizza la probabilità condizionata rispetto ai chunk selezionati, sotto vincoli di stile e conformità codificati nel prompt di sistema.

Qui $p_\theta$ denota la famiglia parametrica del modello e $\mathcal{G}$ raccoglie vincoli soft (tono, lunghezza, presenza di citazioni). In assenza di recupero pertinente, la pipeline deve degradare in modo controllato—ad esempio rifiutando la domanda o invitando a un canale umano—anziché «inventare» fatti.

Orchestrazione su n8n e canale WhatsApp

L’integrazione del provider di messaggistica con webhook verso n8n consente di trattare ogni messaggio in ingresso come evento osservabile: normalizzazione dell’identificativo mittente, verifica delle firme, deduplicazione e code di backoff gestiscono la variabilità operativa tipica dei canali esterni. Il grafo di workflow separa nettamente le fasi di embedding della query, interrogazione del vector store, composizione del prompt e invocazione del modello, così che latenza e costo possano essere attribuiti per stadio.

Il budget tokenico totale della richiesta può essere approssimato dalla somma dei contributi di sistema, contesto recuperato e domanda utente; la pianificazione di $B_{\mathrm{tot}}$ impone trade-off espliciti tra ampiezza di $k$, dimensione dei chunk e profondità della risposta.

Governance, osservabilità e conclusioni

L’adozione in produzione richiede tracciamento dei prompt, delle fonti recuperate e delle risposte finali, con politiche di redazione del PII e ambiti di retrieval ristretti per ruolo. Le metriche di servizio (percentile di latenza end-to-end, tasso di fallback, frequenza di citazioni effettive) consentono iterazioni guidate dai dati più che da impressioni qualitative isolate.

• Obiettivo primario: assistenza continua su WhatsApp senza erodere la fiducia attraverso allucinazioni non attestate.
• Obiettivo secondario: modularità (scambiare LLM o strategie di chunking) senza riscrivere l’intera integrazione canale.

Schema del flusso informativo (semplificato):