Documentazione di Oracle Cloud Infrastructure

DO e DON'T per il design conversazionale

La creazione di un solido set di intenti per una competenza di successo richiede molta attenzione. Ecco alcune best practice da tenere a mente.

Intent Design e Formazione

Azione Da evitare
Pianifica di aggiungere espressioni fino a ottenere risultati che ti aspetti. In generale, i modelli funzionano bene e si aggiungono espressioni di formazione di qualità. Il numero di espressioni necessarie dipende dal modello, dai dati di addestramento e dal livello di precisione realistico per il modello. NON addestrare eccessivamente i singoli intenti. Non aggiungere dati di formazione eccessivi ad alcuni intenti per farli funzionare "perfettamente". Se la risoluzione dell'intento non funziona come previsto, valutare la struttura dell'intento per verificare la sovrapposizione tra gli intenti. La risoluzione degli intenti non sarà MAI accurata al 100%.
Utilizza i dati del mondo reale. L'uso del linguaggio reale che la tua abilità ha più probabilità di incontrare è fondamentale. Le espressioni fabbricate possono solo portarti fino ad ora e non prepareranno la tua abilità per il coinvolgimento del mondo reale. Non utilizzare solo parole chiave nei dati di formazione. Sebbene sia accettabile utilizzare parole singole/frasi brevi per l'addestramento, i dati di addestramento devono avere la stessa struttura degli input dell'utente. Quanto meno le parole nelle espressioni, tanto meno la classificazione avrà successo.
Utilizzare frasi intere per addestrare gli intenti. Mentre è OK usare brevi espressioni di allenamento, assicurati di abbinare lo stile di conversazione dei tuoi utenti il più vicino possibile. Non alterare inavvertitamente gli intenti. Fai attenzione a parole che non aggiungono alcun significato specifico (ad esempio "per favore" e "grazie") o valori di 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 distorcere il tuo modello. Non fare affidamento solo sulla risoluzione intenzionale. Utilizzare le entità per disambiguare gli intenti comuni. In caso di sovrapposizione linguistica tra gli intenti, considerare l'utilizzo di entità per disambiguare le intenzioni dell'utente (e il corrispondente percorso di conversazione univoco).
Fai una piccola chiacchierata. Gli utenti faranno richieste che non sono rilevanti per lo scopo dello skill, ad esempio per scherzi 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 tutte le fasi del tuo flusso di conversazione. NON utilizzare eccessivamente unresolvedIntent. Crea intenti "fuori campo di applicazione" per le cose che sai di non sapere (che puoi o meno abilitare l'abilità di fare in seguito).
Considerare 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 di sintomo del loro problema. Utilizzare più intenti che risolvono tutti nella stessa "risposta". Non ignorare le interazioni abusive. Simile a piccole chiacchiere, hanno un piano per l'abuso. Questo piano potrebbe dover includere misure per garantire che qualsiasi input abusivo da parte dell'utente non venga rispecchiato dalla competenza, nonché disposizioni per l'escalation immediata.

Esperienza utente conversazionale

Azione Da evitare
Dare indicazioni delle risposte più probabili (incluso l'aiuto e l'uscita). Ad esempio, "Ehi, sono Bob il Bot. Chiedi informazioni su X, Y o Z. Se si verificano problemi, basta digitare 'aiuto'. Non ritardare il design conversazionale fino a "più tardi nel progetto". Per tutte le abilità, tranne quelle più semplici, il design conversazionale deve avere la stessa priorità e urgenza di altri lavori di sviluppo. Dovrebbe iniziare presto e procedere in parallelo con altre attività.
Prendi in considerazione una personalità per il tuo bot. Dovresti considerare la personalità e il tono del tuo bot. Tuttavia, fai attenzione a superare l'interazione umana (umorismo e 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 intenzionato, questa cattiva pratica segnala all'utente (consciamente o inconsciamente) che l'abilità non è all'altezza del compito.
Guida l'utente su ciò che ci si aspetta da loro. L'abilità 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 dal percorso felice. NON usare risposte "carine" o "filler". Vedere "DO guida l'utente su ciò che ci si aspetta da loro".
Rompere 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 è, il più delle volte, impreciso. Non importa quante volte un utente riformula una domanda fuori campo, l'abilità non avrà mai nulla di intelligente da dire.
-- Non abusare di frasi di "conferma". Le frasi di conferma hanno il loro posto. Tuttavia, non abusare di loro. Considera 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

Azione Da evitare
Sviluppare le espressioni ciclicamente. Lo sviluppo di un solido corpus di formazione richiede più iterazioni e cicli di test e monitoraggio e tuning continui. Utilizza un approccio ciclico "build, test, deploy, monitor, update". Non trascurare la necessità di un piano di misurazione e miglioramento delle prestazioni. Non avendo un piano per misurare e migliorare le tue abilità, non avrai modo di sapere se funziona davvero.
Eseguire test utilizzando la regola 80/20. Prova sempre la robustezza dei tuoi intenti l'uno contro l'altro conducendo 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 l'abilità risponde a input e azioni utente errati.
Eseguire il test dell'abilità non riuscita. Cerca di rompere la tua abilità per vedere cosa succede. Non fare affidamento solo su test positivi. NON ignorare l'elaborazione dei messaggi out of order. 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 eseguire nuovamente il test durante l'aggiornamento degli intenti. Se aggiungi altri dati di addestramento (ad esempio, man mano che il bot diventa più utilizzato nel mondo reale) e/o aggiungi nuovi intenti per nuovi casi d'uso, non dimenticare di testare di nuovo il tuo modello.

Considerazioni sul progetto

Azione Da evitare
Selezionare i casi d'uso migliorati dall'interfaccia utente conversazionale (CUI). Abilitare l'interfaccia utente conversazionale (tramite competenze e assistenti digitali) è un lavoro. Assicurati che il caso d'uso sia davvero migliorato aggiungendo CUI. Non avere un percorso di escalation. Anche se non si prevede di consentire l'escalation a un essere umano, è necessario disporre di una strategia per le interazioni in cui l'abilità non può aiutare.
Il primo giorno è il giorno peggiore. Anche le competenze e gli assistenti digitali più collaudati richiedono l'ottimizzazione il giorno 1. Non sciogliere il team di progetto subito dopo il lancio. Durante la programmazione del progetto di skill, assicurarsi di mantenere i creatori dello skill (Conversational Designer, Project Manager, Tech Lead e così via) nel progetto per un tempo sufficiente per un tuning adeguato e, in ultima analisi, per il trasferimento delle conoscenze.