Aggiungere un chatbot AI a Discourse è semplice (grazie a due ottimi plugin). Aggiungere un chatbot in grado di fornire assistenza tecnica è molto più difficile! Questo post condivide la nostra esperienza nella configurazione di un chatbot per l’assistenza tecnica per support.suretyhome.com - cosa volevamo, i problemi che abbiamo incontrato, come li abbiamo risolti e dove intendiamo andare da qui.
Il nostro team di supporto è disponibile solo durante gli orari di ufficio, ma i clienti desiderano assistenza 24 ore su 24, 7 giorni su 7. Non stiamo cercando di sostituire il team di supporto. Il nostro obiettivo è potenziare il team di supporto con un bot che sia:
- Disponibile 24/7, incluse notti e fine settimana, proprio come il nostro forum
- Risponda immediatamente, mentre il nostro team di supporto umano impiega un po’ più di tempo
- Possa rispondere a domande che gli utenti non sono riusciti a risolvere con una ricerca sul forum
Ecco la nostra esperienza.
Scelta di un Plugin
Esistono due ottimi plugin che offrono un Chatbot AI.
Il plugin Discourse AI è il plugin AI ufficiale del team di sviluppo di Discourse. Include un chatbot oltre ad altre funzionalità AI. Il plugin Discourse Chatbot è esclusivamente un chatbot. È stato creato prima di Discourse AI e si concentra sull’eseguire bene quella singola funzione.
Inizialmente non avevamo idea di quale usare, quindi ho posto la domanda qui per ottenere dei consigli.
Abbiamo ricevuto molti ottimi aiuti. Alla fine abbiamo scelto Discourse Chatbot perché è più flessibile come chatbot, con più opzioni e funzionalità (opzioni) per la personalizzazione. Il nostro caso d’uso aveva alcune esigenze specifiche che non sembravano ancora fattibili con Discourse AI. Entrambi possono essere un’ottima scelta. Quale sia quello giusto per voi dipende dalle esigenze specifiche del vostro forum.
Configurazione Iniziale
La configurazione iniziale di Discourse Chatbot può essere un progetto piuttosto impegnativo perché ci sono molte opzioni tra cui scegliere e personalizzazioni da apportare. Seguite attentamente le istruzioni per la configurazione e assicuratevi di esaminare tutte le impostazioni.
Il nostro obiettivo era fornire un’esperienza simile a quella di una chat, quindi volevamo che il bot funzionasse solo in Discourse Chat, non nei topic pubblici o nei messaggi privati (PM). I primi passi che abbiamo dovuto compiere sono stati:
- Configurare Discourse Chat (Discourse Chatbot ne dipende)
- Nelle impostazioni di Discourse Chatbot, abilitare chatbot permitted in chat (chatbot consentito nella chat)
Ingegneria dei Prompt
Discourse Chatbot è incredibilmente personalizzabile. Tutto ciò che non è un’impostazione viene personalizzato in Discourse > Personalizza > Testo. È qui che si effettua tutta l’ingegneria dei prompt. In Personalizza > Testo, cercate chatbot.prompt per filtrare tutti i testi dei prompt personalizzabili.
Per far sì che il bot si comporti come vogliamo, dovremo modificare il prompt di sistema. Ma ce ne sono due, uno per le discussioni pubbliche e uno per quelle private. Poiché stiamo utilizzando il bot solo nei canali di chat privati, abbiamo dovuto modificare chatbot.prompt.system.rag.private.
Come bot per l’assistenza tecnica, deve essere più conservativo e accurato di quanto tendono a essere gli LLM «out of the box». Il nostro prompt di sistema doveva essere relativamente lungo per raggiungere questo obiettivo. Nel prompt di sistema, fornite all’LML istruzioni e contesto che rispondano a domande come:
- Chi è il tuo bot? Quale ruolo dovrebbe ricoprire?
- Quali informazioni di base o contesto deve conoscere?
- Quali argomenti è tenuto a discutere? Quali argomenti non dovrebbe mai discutere?
- Quale stile di scrittura o tono dovrebbe utilizzare?
- Cosa dovrebbe fare quando l’utente è frustrato?
Oltre a questa ingegneria generale dei prompt, il prompt di sistema è anche un luogo dove potete provare a risolvere i problemi che scoprite durante i test. Se notate che il vostro bot commette un errore grave, potreste essere in grado di risolverlo aggiungendo istruzioni al prompt di sistema. Ma fate attenzione: il prompting è solo un suggerimento per l’LML. Non lo state programmando. Gli state solo chiedendo di comportarsi in un certo modo. Potrebbe non ascoltarvi.
Temperatura e Top P
Un altro strumento per rendere il bot più conservativo e meno propenso a inventare cose è l’impostazione della temperatura. Di default, l’impostazione della temperatura è 100, che corrisponde al 50% della temperatura massima. Potete ridurla ulteriormente per rendere il bot più conservativo o deterministico e meno propenso a commettere errori. Ma quando la temperatura è impostata molto bassa (come 0), l’LML non suona affatto così impressionante. È una decisione di compromesso che dovrete prendere.
Oltre alla temperatura, c’è l’impostazione Top P. Probabilmente non ne avrete bisogno, ma è lì se serve. Consultate la documentazione OpenAI per ulteriori informazioni.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot request temperature
- chatbot request top p
Problema: LML Inaccurato e Obsoleto
L’LML è stato addestrato su una vasta quantità di dati generali, qualche tempo fa. Abbiamo bisogno che abbia le informazioni più aggiornate e specifiche sul nostro forum e sia il più accurato possibile. La soluzione è la Generazione Aumentata dal Recupero (RAG).
RAG cercherà informazioni aggiuntive sul forum prima di rispondere all’utente. Come bot per l’assistenza tecnica, non possiamo basarci solo sulle conoscenze addestrate dell’LML; abbiamo bisogno che il bot cerchi informazioni tecniche sul nostro forum prima di rispondere.
Per eseguire RAG, Discourse Chatbot deve creare un database di «embeddings» che rappresentano ciascuno dei nostri post del forum come un vettore di «caratteristiche» semantiche. Questo deve essere abilitato, ma vi consiglio di attendere di abilitarlo dopo aver impostato la vostra strategia di embeddings, che tratteremo nella prossima sezione.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot bot type high trust: RAG
- chatbot bot type medium trust: RAG
- chatbot bot type low trust: RAG
- chatbot embeddings enabled: abilitato (dopo aver impostato la strategia di embeddings)
Problema: Molti Post del Forum Non Sono Utili
Avere il bot che cerca sul vostro forum prima di rispondere (RAG) è ottimo, ma introduce un nuovo problema. Molti dei post su un forum non sono molto utili. Alcuni post sono utili, e sono quelli che volete che il bot trovi, ma molti sono solo conversazionali, confusi o semplicemente sbagliati. La nostra soluzione è curare una knowledge base (KB) contenente solo i post che vogliamo che il bot trovi.
Per fare questo in Discourse Chatbot, usiamo la categories embeddings strategy. La strategia di embeddings determina quali post sono disponibili per il chatbot quando cerca sul forum. Il nostro approccio è quello di avere una singola categoria non pubblica che funga da knowledge base per il chatbot, quindi scegliamo categories come strategia di embeddings. La categoria della knowledge base deve essere identificata anche nell’impostazione embeddings categories.
Usiamo una categoria non pubblica (visibile solo allo staff) perché stiamo duplicando molti topic pubblici in questa categoria e non vogliamo che gli utenti vedano i duplicati. Duplicare i topic in una categoria privata introduce un paio di altri problemi.
- È molto faticoso copiarli e ancora peggio mantenerli aggiornati quando i topic vengono modificati o ricevono risposte.
- I topic che il bot trova quando cerca sul forum non sono topic pubblici a cui gli utenti dovrebbero ricevere link come riferimento. Dobbiamo inviare all’LML link ai topic pubblici.
Per risolvere questi due problemi, abbiamo creato strumenti minimali per aiutarci a copiare i topic dalle categorie pubbliche nella nostra categoria KB privata per il chatbot e mantenere aggiornate le copie KB quando i topic pubblici vengono modificati. Sono disponibili qui se desiderate utilizzare lo stesso approccio che stiamo usando.
Gli strumenti KB importano un intero topic pubblico nella categoria KB privata come un nuovo topic con un solo post, concatenando tutti i post del topic pubblico e aggiungendo un link a ciascun post pubblico prima del suo contenuto. In questo modo, quando il bot trova il post KB privato in una ricerca RAG, ottiene il contenuto dell’intero topic pubblico e gli URL dei post pubblici che può includere nella risposta come riferimenti.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot embeddings strategy: categories
- chatbot embeddings categories: (la vostra categoria KB privata)
- chatbot forum search function include topic titles: disabilitato (predefinito)
Inoltre, è necessario rimuovere alcune chiavi di interpolazione dal prompt di ricerca del forum perché non sono rilevanti quando i post sono in una categoria privata.
- chatbot.prompt.function.forum_search.answer.topic.each.post: Rimuovere %{username} e %{date}
- chatbot.prompt.function.forum_search.answer.topic.each.topic: Rimuovere %{title} e %{url}
Problema: LML Non Esegue Abbastanza la Ricerca RAG
Ora che abbiamo una categoria privata con post curati contenenti solo buone informazioni da servire come knowledge base per il nostro chatbot, tutto dovrebbe essere a posto, vero? Falso. Il prossimo problema che abbiamo incontrato è stato che la funzione di ricerca RAG non veniva utilizzata quasi per nulla dall’LML.
Gli LML come GPT-4 sono abbastanza intelligenti da essere pericolosi. Spesso «pensano» di conoscere già la risposta e non hanno bisogno di chiedere aiuto, quando in realtà dovrebbero eseguire una ricerca RAG e cercare la risposta nella knowledge base. Per risolvere questo problema, usiamo l’opzione tool choice e costringiamo l’LML a chiamare una funzione.
Avremmo potuto forzare una ricerca locale sul forum, ma abbiamo scoperto che forzare semplicemente una chiamata a una funzione è sufficiente, e vogliamo dare all’LML la libertà di chiamare talvolta un’altra funzione invece di eseguire una ricerca sul forum.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot tool choice first iteration: force_a_function
Problema: Prestazioni della Ricerca sul Forum
Forzando una chiamata a una funzione, l’LML esegue in modo affidabile una ricerca RAG per quasi ogni risposta. Ma stavamo ancora ottenendo risultati scadenti. Il bot non trovava i post giusti nella knowledge base. Con così tante informazioni nei nostri post, c’era molto «rumore» che interferiva con la capacità della funzione di ricerca di trovare il post migliore.
Ad esempio, immaginate che l’utente stia chiedendo al bot come far smettere di emettere beep la sua stampante HP Laser Jet. L’LML potrebbe eseguire una ricerca sul forum con la query «HP LaserJet stop beeping». Potrebbe esserci un post nella knowledge base che affronta perfettamente quel problema, ma la parte «domanda» di esso (che corrisponderebbe da vicino alla query) è solo il 2% del testo nel post. Il restante 98% del testo sono i passaggi di risoluzione dei problemi e le risposte.
La ricerca locale sul forum di Discourse Chatbot è una ricerca semantica che utilizza gli embeddings vettoriali per trovare il post (o i pochi post) più simile alla query. La parte domanda del post migliore è molto simile alla query, ma è solo il 2% dell’intero testo. Il restante 98% del testo rende il post non così simile alla query, quindi il post non si posiziona in alto in una ricerca per quella query.
La nostra soluzione a questo problema è aggiungere «post esca» ai nostri topic della knowledge base che contengono solo testo simile alla query di ricerca. Nel nostro esempio sopra, potremmo aggiungere un post esca con solo «HP Laser Jet beeping». La funzione di ricerca locale sul forum troverà facilmente il post esca perché è molto simile alla query. Quindi facciamo sì che Discourse Chatbot invii all’LML il contenuto del post reale, che include la risposta, invece del post esca.
Poiché i nostri topic KB hanno tutto il loro contenuto nel primo post, possiamo usare le risposte nei topic KB come post esca. Dopo aver usato i nostri strumenti KB per importare i topic nella knowledge base, possiamo semplicemente rispondere ai topic KB per creare post esca.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot forum search function results content type: topic
- chatbot forum search function results topic max posts count strategy: just_enough
- chatbot forum search function results topic max posts count: 1
I post esca forniscono un meccanismo potente per ottimizzare la knowledge base per la ricerca, ma siete costretti a farlo alla cieca. Non potete vedere le ricerche mentre avvengono, quindi è difficile capire esattamente come i vostri post esca influenzino il ranking delle ricerche. Per aiutare a risolvere questo problema, abbiamo creato un piccolo programma che esegue la stessa ricerca semantica utilizzata da Discourse Chatbot, ma lo fa localmente sul vostro computer e mostra tutti i dettagli, come i punteggi di similarità e il ranking. Questo rende molto più facile creare post esca che migliorano effettivamente le prestazioni di ricerca e ottimizzano la knowledge base.
La combinazione di RAG, una knowledge base curata, il forcing dell’LML a chiamare una funzione e i post esca ha finalmente portato a un chatbot per l’assistenza tecnica piuttosto buono! 
LML Allucina URL
Sebbene il bot stesse andando bene nel rispondere a domande tecniche, aveva ancora un fastidioso problema di allucinazioni. Spesso allucinava URL nelle risposte all’utente. Questo è un problema noto con gli LML e il consenso generale è che ci si deve semplicemente rassegnare. Noi non volevamo che i nostri utenti dovessero rassegnarsi.
Poiché il nostro bot fornisce assistenza tecnica, facciamo molto affidamento su RAG per fornire all’LML informazioni accurate e aggiornate. Lo costringiamo a eseguire una ricerca RAG prima di ogni risposta. Facciamo affidamento sull’LML per «capire» e comunicare con l’utente, ma facciamo affidamento quasi interamente sulla nostra knowledge base per le informazioni tecniche utilizzate per rispondere alle loro domande. Possiamo sfruttare questo fatto per impedire al bot di allucinare URL.
La nostra soluzione è aggiungere un vincolo al bot in modo che possa includere un URL nella sua risposta solo se quell’URL proviene da un risultato della ricerca sul forum. Se l’LML tenta di includere un URL che non era già presente in un risultato della ricerca sul forum, allora Discourse Chatbot informerà l’LML del problema e gli chiederà di riprovare. Questo semplice workaround ha efficacemente eliminato le allucinazioni di URL.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot url integrity check: abilitato
Problema: Il Chatbot Non Può Gestire Tutto
Alcune domande di supporto non possono assolutamente essere gestite dal chatbot perché richiedono un’azione da intraprendere. Ad esempio, se è necessario apportare una modifica all’account o restituire un prodotto (che richiede un rimborso e/o un’autorizzazione), il bot non può farlo.
Dipende anche dalla complessità. Molte domande sono semplici: se l’utente avesse cercato il forum con la query giusta, avrebbe trovato la risposta. In tal caso, il bot è piuttosto bravo a cercare sul forum, trovare la risposta e presentarla. Ma quando il problema richiede un’indagine o un’analisi complessa, il bot spesso fornisce una risposta generica che non aggiunge molto valore.
In entrambe queste situazioni in cui il bot non può gestire il problema, abbiamo bisogno che elevi la chat al nostro team di supporto umano. Discourse Chatbot ha una funzione per l’LML per fare esattamente questo, chiamata escalate to staff.
Le impostazioni di Discourse Chatbot per questa sezione sono:
- chatbot escalate to staff function: abilitato
- chatbot escalate to staff groups: (il gruppo a cui si desidera elevare)
Stiamo già costringendo l’LML a chiamare una funzione prima di rispondere, ma ora sorge la questione di quale funzione chiamare. L’LML dovrebbe chiamare la funzione local forum search (RAG) o la funzione escalate to staff? Deve prendere questa decisione ogni volta che un utente gli invia un messaggio. La maggior parte delle volte vogliamo che chiami local forum search. Vogliamo che escalate to staff solo quando non può gestire il problema, nota che l’utente è frustrato o l’utente lo richiede esplicitamente.
Usiamo il prompting per guidare l’LML su come decidere quale funzione chiamare. I testi dei prompt che potete modificare per questo in Personalizza > Testo sono:
- chatbot.prompt.system.rag.private
- chatbot.prompt.function.forum_search.description
- chatbot.prompt.function.escalate_to_staff.description
Problema: Impossibile Monitorare le Chat
Quando gli utenti stanno effettivamente utilizzando il chatbot, è utile vedere le conversazioni e monitorare le risposte errate o le opportunità di miglioramento. Ma Discourse non fornisce un modo per gli amministratori di leggere le chat, il che ha senso perché le chat sono tipicamente conversazioni private tra persone. Le chat con il bot di supporto, tuttavia, non sono conversazioni private e se non possiamo rivederle, non possiamo migliorare continuamente il bot.
La buona notizia è che Discourse offre agli amministratori un modo per esportare l’intera cronologia delle chat del forum come file CSV.
Per risolvere questo problema, abbiamo creato un piccolo programma che converte il file CSV della cronologia delle chat in una serie di file HTML, uno per ogni utente che ha chattato con il bot. Non possiamo monitorare l’uso del bot in tempo reale, ma con questa soluzione possiamo esportare periodicamente la cronologia delle chat, convertirla in file HTML e rivederli per lavorare al miglioramento del nostro bot.
Conclusione
Dopo aver affrontato ciascuno di questi problemi e curato adeguatamente la knowledge base, siamo finalmente riusciti a permettere agli utenti di iniziare a utilizzare il chatbot.
Finora i risultati sono stati misti. È entusiasmante vedere le persone che utilizzano il chatbot durante le notti e i fine settimana, ottenendo risposte alle loro domande e risolvendo i problemi. È illuminante vedere le persone che cercano di utilizzare il chatbot senza avere un’ottima esperienza. Di solito significa che manca qualcosa o che non è chiaro nella nostra knowledge base. Di tanto in tanto vediamo un problema che richiede un miglioramento del prompt di sistema. E a volte è chiaro che c’è confusione e dobbiamo migliorare il modo in cui presentiamo il chatbot all’utente.
Abbiamo visto che circa la metà delle chat richiede un’elevazione allo staff. Circa la metà di quelle elevate sono casi in cui il bot non avrebbe assolutamente potuto gestire la situazione. L’altra metà (circa il 25% delle chat) sono casi in cui il bot avrebbe potuto risolvere il problema ma non ci è riuscito, il che rappresenta opportunità di miglioramento.
Tra le chat che non si traducono in un’elevazione allo staff, può essere difficile dire se l’utente ha effettivamente risolto il proprio problema o se ha semplicemente rinunciato e se ne è andato. È ovvio quando il bot dà una risposta sbagliata cosa deve essere migliorato. Non è sempre ovvio quando sta dando risposte ragionevoli e buone se l’utente ha compreso appieno e se il suo problema è stato risolto, a meno che non ce lo dica.
Nel complesso, siamo soddisfatti di questa prima iterazione del chatbot di supporto Surety e non vediamo l’ora che l’LML migliori e che la nostra knowledge base diventi migliore nel tempo. Lavorare sulla knowledge base è il nostro compito principale ora.
Discourse Chatbot ha aggiunto il supporto per la ricerca ibrida (sia semantica che testuale) da quando abbiamo iniziato a lavorare su questo progetto, quindi probabilmente proveremo a sperimentare con essa a breve.
Grazie a @merefield per tutto il suo duro lavoro sul plugin Discourse Chatbot! È stato molto divertente lavorare con esso e si è dimostrato all’altezza del compito.
Se qualcun altro decide di costruire un chatbot per l’assistenza tecnica per il proprio forum, vi prego di contattarmi e farmelo sapere! Sarebbe fantastico avere altri con cui collaborare e scambiare idee. Aggiungerò nuovamente quando accadranno cose interessanti, verranno apportate modifiche o impareremo qualcosa di nuovo.