DO's e DON'Ts per la progettazione conversazionale

La creazione di un solido insieme di intenti per un'abilità di successo richiede molta attenzione. Ecco alcune best practice da tenere a mente.

Progettazione e formazione degli intenti

DO Da evitare
Pianifica di aggiungere espressioni fino a quando non ottieni i risultati che ti aspetti. In generale, i modelli funzionano bene e si aggiungono espressioni di allenamento di qualità. Il numero di espressioni di cui hai bisogno dipende dal modello, dai dati di addestramento e dal livello di precisione realistico per il tuo modello. NON addestrare eccessivamente i singoli intenti. Non aggiungere dati di formazione eccessivi ad alcuni intenti per farli funzionare "perfettamente". Se la risoluzione degli intenti non funziona come previsto, valutare la struttura degli intenti per verificare la sovrapposizione tra intenti. La risoluzione degli intenti non sarà mai accurata al 100%.
Utilizzare i dati del mondo reale. Utilizzare il linguaggio effettivo che è più probabile che la tua abilità incontri è fondamentale. Le espressioni fatte possono solo portarti fino ad ora e non prepareranno la tua abilità per l'impegno nel mondo reale. Non utilizzare parole chiave solo nei dati di formazione. Sebbene sia accettabile utilizzare parole singole/brevi frasi per la formazione, i dati di formazione dovrebbero avere la stessa struttura degli input dell'utente. Meno parole in pronuncia, meno successo sarà la classificazione.
Utilizzare intere frasi per addestrare gli intenti. Anche se è OK usare brevi espressioni di allenamento, assicurati di abbinare lo stile di conversazione dei tuoi utenti il più strettamente possibile. Non alterare inavvertitamente gli intenti. Prestare attenzione alle parole che non aggiungono alcun significato specifico (ad esempio "per favore" e "grazie") o ai valori delle entità all'interno delle espressioni in quanto possono inavvertitamente distorcere la risoluzione dell'intento se sono pesantemente utilizzati in un intento ma non in un altro.
Utilizzare numeri simili di espressioni per intento. Alcuni intenti (ad esempio, "ciao", "addio") possono avere meno espressioni nei loro set di allenamento. Tuttavia, assicurati che i tuoi intenti principali abbiano un numero simile di espressioni per evitare di influenzare il tuo modello. Non fare affidamento solo sulla risoluzione degli intenti. Utilizzare le entità per disambiguare gli intenti comuni. Se c'è sovrapposizione linguistica tra gli intenti, prendi in considerazione l'utilizzo di entità per disambiguare le intenzioni dell'utente (e il corrispondente percorso conversazionale univoco).
Fare piccoli discorsi. Gli utenti faranno richieste che non sono rilevanti per lo scopo dell'abilità, come per barzellette e rapporti meteo. Possono anche fare cose come chiedere se l'abilità è umana. Assicurati di avere una piccola strategia di conversazione e di testare in modo aggressivo come la competenza risponde a tutti i passi del tuo flusso di conversazione. NON utilizzare in modo eccessivo unresolvedIntent. Crea intenti "out-of-scope" per le cose che sai di non sapere (che potresti o meno abilitare l'abilità di fare in seguito).
Prendere in considerazione più intenti per un singolo caso d'uso. I clienti possono esprimere la stessa necessità in più modi, ad esempio in termini di soluzione che desiderano OPPURE il sintomo del loro problema. Utilizzare più intenti risolti tutti alla stessa "risposta". Non ignorare le interazioni abusive. Simile alle piccole chiacchiere, hai un piano per gli abusi. Questo piano potrebbe dover includere misure per garantire che qualsiasi input abusivo da parte dell'utente non sia rispecchiato dalla competenza, nonché disposizioni per l'escalation immediata.

User experience conversazionale

DO Da evitare
Dare indicazioni delle risposte più probabili (incluso aiuto e uscita). Ad esempio, "Ehi, sono Bob il Bot. Chiedi informazioni su X, Y o Z. Se ti imbatti in qualsiasi problema, digita semplicemente "aiuto". Non ritardare il design conversazionale fino a "più tardi nel progetto". Per tutte le competenze, tranne quelle più semplici, la progettazione conversazionale deve avere la stessa priorità e urgenza di altri lavori di sviluppo. Dovrebbe iniziare presto e procedere in parallelo con altri compiti.
Considera una personalità per il tuo bot. Dovresti considerare la personalità e il tono del tuo bot. Tuttavia, fai attenzione a esagerare nell'interazione umana (l'umorismo e la simpatia spesso non risuonano bene da un bot) e non cercare mai di ingannare i tuoi utenti nel pensare che stiano interagendo con un essere umano. Non dire che l'abilità "sta ancora imparando". Anche se ben intenzionata, questa cattiva pratica segnala all'utente (consapevolmente o inconsciamente) che l'abilità non è all'altezza del compito.
Guida l'utente su ciò che si aspetta da loro. Lo skill deve cercare di guidare l'utente verso una risposta appropriata e non lasciare aperte le domande. Le domande aperte rendono l'utente più propenso a cadere fuori dal percorso felice. NON usare risposte "carine" o "filler". Vedere "DOP guida l'utente su ciò che si aspetta da loro".
suddividere le risposte lunghe in singole bolle di chat e/o utilizzare interruzioni di riga. Grandi blocchi di testo senza interruzioni visive sono difficili da leggere e possono portare a confusione. Non dire "Mi dispiace, non capisco. Riformulare la domanda?" Questo approccio pigro di gestione degli errori è, più spesso che non, impreciso. Non importa quante volte un utente riformula una domanda fuori ambito, l'abilità non avrà mai nulla di intelligente da dire.
-- NON usare eccessivamente frasi di "conferma". Le frasi di conferma hanno il loro posto. Tuttavia, non esagerare. Prendere in considerazione i flussi di dialogo che sono in grado di prendere in considerazione i livelli di affidabilità prima di chiedere agli utenti di confermare.

Strategie di test

DO Da evitare
Sviluppare espressioni ciclicamente. Lo sviluppo di un solido corpus di formazione richiede più iterazioni e cicli di test e monitoraggio e ottimizzazione continui. Utilizza un approccio ciclico "build, test, deploy, monitor, update". Non trascurare la necessità di un piano di misurazione e miglioramento delle prestazioni. Senza un piano per misurare e migliorare le tue abilità, non avrai modo di sapere se funziona davvero.
Eseguire il test delle espressioni utilizzando la regola 80/20. Prova sempre la robustezza dei tuoi intenti l'uno contro l'altro eseguendo più test 80/20, dove l'80% delle espressioni appena raccolte viene utilizzato per addestrare il modello e il 20% viene aggiunto ai tuoi dati di test. Non testare solo il percorso felice. "Farlo funzionare" è il 20% del lavoro. Il restante 80% sta testando e regolando il modo in cui la skill risponde a input e azioni utente errati.
Eseguire il test del fallimento dell'abilità. Prova aggressivamente a rompere la tua abilità per vedere cosa succede. Non fare affidamento solo su test positivi. NON ignorare l'elaborazione dei messaggi fuori ordine. Gli utenti scorreranno indietro nella cronologia delle conversazioni e faranno clic sui pulsanti passati. Il test dei risultati deve far parte del tuo lavoro dell'80% (come indicato in Non testare solo il percorso felice).
-- Non dimenticare di rieseguire il test durante l'aggiornamento degli intenti. Se aggiungi più dati di formazione (ad esempio, man mano che il bot ottiene un uso più reale) e/o aggiungi nuovi intenti per nuovi casi d'uso, non dimenticare di ripetere il test del tuo modello.

Considerazioni sul progetto

DO Da evitare
DO seleziona casi d'uso migliorati dall'interfaccia utente conversazionale (CUI). Abilitare l'interfaccia utente conversazionale (tramite competenze e assistenti digitali) è un lavoro. Assicurarsi che il caso d'uso venga veramente migliorato aggiungendo CUI. Non riesco ad avere un percorso di escalation. Anche se non hai intenzione di consentire l'escalation a un essere umano, devi avere una strategia per quelle interazioni in cui l'abilità non può aiutare.
Prevedi che il primo giorno sia il giorno peggiore. Anche le competenze più collaudate e gli assistenti digitali richiedono l'ottimizzazione il giorno 1. Non sciogliere il team di progetto subito dopo il lancio. Quando pianifichi il tuo progetto di competenze, assicurati di mantenere i creatori dell'abilità (Conversational Designer, Project Manager, Tech Lead, ecc.) sul progetto abbastanza a lungo per un'adeguata messa a punto e, in ultima analisi, un trasferimento di conoscenze.