La tecnologia da sola non garantisce l’adozione: lezioni apprese dalla costruzione di un chatbot AI interno

Man mano che l’adozione dell’intelligenza artificiale si accelerava in tutti i settori, sembrava una decisione logica quella di distribuire un chatbot per supportare una nuova applicazione interna appena lanciata. Tuttavia, l’applicazione stessa sfidava le aspettative convenzionali degli utenti. Introduceva nuovi flussi di lavoro costruiti su tecnologie emergenti a cui la maggior parte degli utenti non era abituata.

Per ridurre l’attrito e migliorare l’adozione, il chatbot era stato progettato per rispondere a domande sull’applicazione e sulla tecnologia sottostante. L’obiettivo era aiutare gli utenti a capire non solo cosa fare, ma anche perché il sistema si comportava in un determinato modo. Credevamo che fornire spiegazioni contestuali avrebbe accelerato l’apprendimento e ridotto la confusione.

Fin dall’inizio, l’agente di intelligenza artificiale era stato concepito come una soluzione a scopo limitato. Era stato progettato esclusivamente per supportare la documentazione e fornire assistenza agli utenti. Concettualmente, il chatbot era destinato a servire come sostituto dinamico di un documento di domande frequenti tradizionale, offrendo un’interfaccia conversazionale, ricercabile e disponibile in continuazione con funzionalità estese oltre il contenuto statico.

Per integrare l’agente nell’ambiente di chat interno dell’organizzazione, dovevamo capire come venivano rappresentati i messaggi strutturati, come veniva archiviata la storia della conversazione e come il sistema identificava i partecipanti all’interno dei thread. Ciò ci ha permesso di determinare le variabili fondamentali necessarie per iniziare a elaborare le domande degli utenti.

Radicare il modello: da allucinazioni a contesto affidabile

I grandi modelli linguistici sono potenti, ma senza un’ancoraggio contestuale sono inclini alle allucinazioni. Per affrontare questo problema, abbiamo implementato una tecnica di incorporamento vettoriale.

Le guide per gli utenti, la documentazione interna e la visione del prodotto sono state trasformate in rappresentazioni vettoriali numeriche del testo. Questi incorporamenti hanno catturato il significato semantico, consentendo al sistema di abbinare concetti piuttosto che affidarsi a semplici corrispondenze di parole chiave.

Quando un utente faceva una domanda, il sistema convertiva la query in una rappresentazione vettoriale e la confrontava con gli incorporamenti archiviati. Recuperava i documenti più semanticamente rilevanti e li iniettava nel prompt del modello. Il modello generava quindi una risposta radicata in quei documenti specifici, spesso riassumendo le informazioni rilevanti.

Questo approccio ha migliorato notevolmente la precisione delle risposte. Invece di generare risposte basate esclusivamente sulla conoscenza generale, il modello rispondeva utilizzando la nostra documentazione interna come contesto.

La complessità nascosta della gestione del contesto

Era essenziale includere la storia della conversazione nel prompt in modo che il bot potesse interpretare le domande successive e mantenere la continuità. Senza storia, le interazioni diventavano frammentate e ripetitive. Gli utenti spesso raffinavano le loro domande in modo incrementale e, senza contesto, il bot non poteva interpretare riferimenti come “quell’opzione” o “il passaggio precedente”.

Tuttavia, includere troppa storia creava un altro problema: limiti di token. Questi si verificano quando i modelli linguistici troncano gli input che superano la loro finestra di contesto massima. Se una domanda o una conversazione diventava troppo lunga, le informazioni importanti potevano andare perse. Ciò non produceva un errore esplicito, ma degradava la qualità della risposta o influenzava l’accuratezza del recupero.

Per mitigare questo, abbiamo implementato strategie per controllare le dimensioni del prompt, dare priorità al contenuto rilevante e monitorare la lunghezza delle domande. Abbiamo sperimentato la sommarizzazione dei messaggi più vecchi e l’inclusione selettiva solo delle parti più rilevanti della conversazione. Il contesto era critico, ma doveva essere gestito con cura.

Estendere le capacità e creare confusione

Oltre a rispondere alle domande basate sulla documentazione, abbiamo esteso le capacità del bot aggiungendo funzioni backend che potevano estrarre determinate informazioni pubbliche direttamente dall’applicazione. Ciò ha permesso agli utenti di recuperare dati dal chat senza accedere all’applicazione stessa. L’idea era ridurre l’attrito e rafforzare il chatbot come interfaccia utile, non solo come strato di conoscenza statico.

Questa estensione ha creato confusione per alcuni utenti. Una volta che il bot ha iniziato a recuperare dati live, gli utenti hanno iniziato a chiedergli di eseguire azioni che richiedevano interazione diretta all’interno della piattaforma. Hanno assunto che il chatbot potesse sostituire i passaggi operativi, compresi quelli che richiedevano autenticazione o esecuzione deliberata all’interno della piattaforma.

Il bot non era stato progettato per eseguire quelle azioni, ma la distinzione tra assistenza informativa e esecuzione operativa non era sempre chiara.

L’integrazione dei dati live ha anche introdotto nuove considerazioni tecniche. Dovevamo definire quando una domanda doveva essere gestita attraverso il recupero basato su incorporamenti e quando doveva attivare una chiamata backend. La logica di decisione richiedeva una progettazione accurata. Inoltre, dovevamo regolare le risposte per gestire in modo elegante le eccezioni tecniche e evitare di esporre gli utenti a errori di sistema grezzi.

La capacità multilingue non è automatica

Durante i test, ci siamo resi conto che il bot si comportava costantemente meglio in inglese rispetto ad altre lingue utilizzate all’interno di Jalasoft. Il motivo principale era strutturale: la maggior parte della documentazione utilizzata per generare gli incorporamenti era scritta in inglese, e il modello di incorporamento che avevamo selezionato era ottimizzato per la somiglianza semantica inglese.

Non supportava il recupero cross-linguistico o il confronto semantico tra lingue. Di conseguenza, le query non in inglese spesso recuperavano documentazione meno rilevante, portando a risposte più deboli.

Questo ha messo in evidenza un’importante intuizione: la capacità multilingue non è automatica.

Quando le aspettative superano l’ambito

Per controllare i costi di utilizzo, abbiamo implementato un limite giornaliero sul numero di domande che gli utenti potevano porre. Tuttavia, non abbiamo esplicitamente limitato l’ambito di quelle domande. Gli utenti erano liberi di chiedere qualsiasi cosa.

Questa apertura ha portato a modelli di utilizzo inaspettati. Alcuni utenti hanno iniziato a interagire con il bot per scopi personali o esplorativi non correlati all’applicazione. Nel tempo, le aspettative sono cresciute oltre il ruolo previsto del bot, creando un divario tra ciò che gli utenti speravano potesse fare e ciò per cui era stato progettato.

Questo disallineamento ha gradualmente ridotto la sua utilità percepita. L’utilizzo è diminuito e il chatbot è stato infine deprecato, con gli sforzi ridiretti verso la ridisegnazione dell’applicazione stessa per renderla più intuitiva e facile da usare.

La lezione reale: progettazione dell’interazione

Da un punto di vista ingegneristico, il sistema funzionava ragionevolmente bene. Recuperava la documentazione, incorporava la storia della conversazione, riduceva le allucinazioni attraverso gli incorporamenti, gestiva le chiamate backend e controllava le dimensioni del prompt. L’architettura funzionava come previsto.

Ma mancava di una progettazione intenzionale dell’interazione.

Il bot non ha mai chiarito le conversazioni. Non ha mai rafforzato costantemente il suo ambito. Non ha mai guidato gli utenti con esempi strutturati di ciò che poteva e non poteva fare. Rispondeva alle domande, ma non stabiliva aspettative.

Abbiamo imparato che i sistemi di intelligenza artificiale conversazionale richiedono più di modelli solidi e dati strutturati. Richiedono aspettative progettate con cura. Gli utenti hanno bisogno di chiarezza sul ruolo dell’agente, sui suoi limiti e sulle sue forze. Il sistema deve fornire in modo proattivo esempi di prompt, chiarire i limiti e reindirizzare le domande fuori dall’ambito in modo coerente.

Senza questo inquadramento intenzionale, anche un’implementazione tecnicamente solida può lottare per sostenere il valore. Gli utenti possono sovrastimare le capacità o disimpegnarsi quando le aspettative non dichiarate non vengono soddisfatte.

La conoscenza fondamentale è semplice ma potente.

Costruire un’intelligenza artificiale conversazionale non è solo una sfida tecnica. È anche una sfida di progettazione dell’interazione.

Un contesto solido, un recupero accurato e un’architettura robusta sono necessari, ma non sufficienti. L’efficacia del sistema dipende ugualmente da come definisce il suo ruolo, comunica i suoi limiti e plasma le aspettative degli utenti.

La tecnologia da sola non garantisce l’adozione. Una progettazione dell’interazione chiara lo fa.