Best practice generali per la progettazione degli agenti

Questa guida fornisce best practice generali per la progettazione di tutti i tipi di agenti.

Consulta anche la guida alla progettazione degli agenti vocali specifica per la progettazione degli agenti vocali e la guida alle best practice per l'utilizzo del servizio Dialogflow.

Consigli generali

Creare gli agenti in modo iterativo

Se l'agente è di grandi dimensioni o complesso, crea una finestra di dialogo che risponda solo alle richieste di primo livello. Una volta stabilita la struttura di base, ripeti i percorsi di conversazione per assicurarti di coprire tutti i percorsi possibili che un utente finale può intraprendere.

Mentre l'agente si evolve, valuta la possibilità di utilizzare la funzionalità degli scenari di test per lo sviluppo basato su test.

Agenti predefiniti

Dialogflow offre modelli di agente per aiutarti a iniziare. Gli agenti predefiniti si occupano di casi d'uso comuni come servizi finanziari, telecomunicazioni e viaggi. Questi agenti dispongono di intent ed entità per coprire le query più comuni degli utenti. Aggiungi percorsi e evasione degli ordini specifici per la tua attività e creerai rapidamente un agente funzionante.

Integrazioni e connessione dei servizi

Esistono diversi modi per eseguire l'integrazione con gli agenti Dialogflow. Questa sezione fornisce le best practice per scegliere la modalità di integrazione.

Integrazioni

Le integrazioni di Dialogflow forniscono un'interfaccia utente pronta all'uso per il tuo agente. Se utilizzi un'integrazione, non è necessario chiamare direttamente l'API Dialogflow, perché le integrazioni gestiscono questo aspetto per te. Queste integrazioni possono fornire un agente di testo che puoi incorporare nel tuo sito web, connetterti con altre piattaforme di messaggistica o fornire un'interfaccia di telefonia.

API Dialogflow

Se nessuna delle integrazioni pronte all'uso è adatta o se vuoi personalizzare l'interfaccia per il tuo sistema, puoi utilizzare direttamente l'API Dialogflow. Con questo approccio, dovrai implementare l'interfaccia utente per l'agente o utilizzare un'interfaccia utente esistente.

Webhook

A meno che il tuo agente non sia completamente definito con dati statici, devi utilizzare i webhook per connettere il servizio e fornire un agente in grado di gestire scenari dinamici. Questo si applica sia che utilizzi le integrazioni sia l'API Dialogflow.

Risorse agente

Le risorse dell'agente Dialogflow possono essere utilizzate in molti modi per ottenere i risultati desiderati. Questa sezione offre consigli per scegliere le risorse giuste per gli scenari giusti.

Flussi e pagine

I flussi e le pagine forniscono la struttura all'agente. Le pagine possono essere considerate nodi in una macchina a stati e flussi come gruppi di pagine correlate. Puoi controllare le transizioni tra i nodi con gestori di stato, che vengono chiamati quando viene soddisfatto un intent, quando viene soddisfatta una condizione o richiamato un evento.

Un agente semplice può funzionare bene con un singolo flusso, ma gli agenti complessi sono quasi sempre progettati meglio con più flussi. Ogni flusso dovrebbe rappresentare un argomento generale per l'agente, in cui ogni pagina associata al flusso aiuta a gestire l'argomento. Inoltre, ogni flusso può avere alcune impostazioni e può essere di proprietà di un sottoinsieme di membri del team, il che consente di suddividere il lavoro durante la progettazione di agenti di grandi dimensioni.

Quando progetti un agente complesso e di grandi dimensioni, devi considerare i limiti"flussi per agente" e "pagine per flusso". Questi limiti aiutano a mantenere le prestazioni dell'agente.

Se la progettazione dell'agente ha troppi flussi per agente, combina gli argomenti correlati in un unico flusso. Ad esempio, puoi combinare i seguenti argomenti in un unico flusso "Trova equilibrio":

• Ricevi il saldo del conto corrente
• Ricevi il saldo di risparmio
• Ottieni saldo mutuo
• Ottieni saldo del credito

Se il design dell'agente ha troppe pagine per flusso, combina le pagine correlate e utilizza più percorsi per pagina.

Se continui ad avere problemi con i limiti di flusso e di pagine, è possibile che tu abbia integrato troppa logica di business nell'agente stesso. Valuta la possibilità di spostare questa logica nei webhook.

Di seguito è riportata la granularità del controllo della conversazione delle risorse dell'agente in ordine di granularità crescente:

1. Agenti (un agente gestisce tutte le conversazioni)
2. Flussi (un flusso gestisce uno o più argomenti di conversazione correlati)
3. Pagine (una pagina gestisce uno o più turni di conversazioni correlate)
4. Route (una route gestisce un controllo dell'intent o della condizione dell'utente)

Confronto tra parametri di intent e parametri del modulo

Il modo principale in cui il tuo sistema riceve i dati strutturati dall'utente finale è tramite i parametri. Puoi utilizzare i parametri per intent (parametri intent) o pagine (parametri modulo).

Lo scopo principale di alcune pagine è raccogliere informazioni specifiche dall'utente finale. Ad esempio, una pagina potrebbe essere progettata per raccogliere i dati di contatto dell'utente finale. In questo caso, devi sempre utilizzare i parametri del modulo per raccogliere queste informazioni.

In alcuni casi, potresti voler acquisire informazioni dell'utente finale durante il passaggio da una pagina all'altra. Ad esempio, se l'utente finale richiede un determinato prodotto all'inizio della conversazione, vorrai acquisire il prodotto desiderato mentre si passa alla pagina dell'ordine appropriata. In questo caso, utilizza i parametri di intent come parte delle route di intent.

Esistono anche situazioni in cui utilizzare sia parametri di intent che parametri di modulo è l'ideale. Ad esempio, se l'utente finale richiede una camicia di taglia S all'inizio della conversazione, vorrai acquisire il parametro della taglia desiderato (small) durante la transizione alla pagina dell'ordine delle magliette. Nella pagina di ordinazione delle magliette potrebbero essere richieste informazioni aggiuntive, come il colore desiderato. Nella pagina dell'ordine delle magliette devono essere presenti parametri di modulo per taglia e colore. In questo esempio, il parametro di dimensione è già stato fornito ed è propagato, quindi l'agente richiederà solo il colore. Tuttavia, altre conversazioni potrebbero seguire un percorso diverso, in cui l'utente finale non ha fornito la taglia desiderata quando la pagina dell'ordine delle magliette diventa attiva. Se definisci questo parametro in entrambi i modi, l'agente ottiene maggiore flessibilità nel modo in cui estrae le informazioni.

Route e gruppi di route

Se vuoi passare a un'altra pagina, mettere in coda un messaggio di risposta o chiamare un webhook quando viene soddisfatta un intent o se viene soddisfatta una condizione, utilizza le route.

Se ti ritrovi a utilizzare lo stesso insieme di percorsi su più pagine, utilizza i gruppi di percorsi. In questo modo eviterai duplicati inutili nella progettazione dell'agente.

Riutilizzo dell'intenzione

Se ti ritrovi a definire più intent con frasi di addestramento simili, valuta la possibilità di riutilizzare gli intent su più pagine. Idealmente, dovresti definire alcuni intent generici utilizzati in molte pagine e alcuni intent specifici utilizzati solo in una singola pagina. In questo modo eviterai duplicati inutili nella progettazione dell'agente.

Ad esempio, gli intent di conferma sono in genere definiti meglio come intent riutilizzabili. Un intent confirmation.yes potrebbe includere frasi di addestramento come:

• sì
• sì
• sì
• OK
• sì
• ci puoi scommettere
• assolutamente
• sì per favore

Un intent confirmation.no potrebbe includere frasi di addestramento come:

• no
• no
• no
• Neanche per sogno
• non fa per me
• assolutamente no
• no grazie

Questi intent di conferma riutilizzabili possono essere utilizzati in molti scenari per il tuo agente.

In alcuni casi, dovresti anche considerare la creazione di intent di conferma specializzati. Ad esempio, quando confermi un ordine, potresti voler avere un intent order.confirmation.yes specializzato con frasi di addestramento come:

• l'ordine mi sembra a posto
• Accetto questo ordine

Infine, un intent order.confirmation.no specializzato con frasi di addestramento come

• Non voglio questo ordine
• Non accetto questo ordine

Quando la pagina di conferma dell'ordine è attiva, devono rientrare nell'ambito le route di intent per tutti e quattro questi intent. Ciò garantisce che qualsiasi conferma generica o specifica da parte dell'utente finale venga gestita in modo appropriato.

Intento escluso predefinito

Devi completare l'intent negativo predefinito con le frasi che potrebbero essere pronunciate dagli utenti finali, ma non corrispondenti ad alcun intent dell'agente.

Fulfillment

Esistono molte opzioni per l'utilizzo di fulfillment per rispondere all'utente finale. Durante il turno di una conversazione, l'agente può aggiungere più messaggi alla coda di risposta e la coda concatenata viene inviata all'utente finale al termine del turno della conversazione. In questa sezione vengono descritte le opzioni disponibili per la creazione dei singoli messaggi.

• Fulfillment voci di pagina: questo fulfillment viene richiamato quando la pagina diventa inizialmente attiva. È utile quando vuoi un messaggio che descriva lo scopo della pagina e deve essere pronunciato una sola volta mentre la pagina è attiva. Ad esempio:
  • Che cosa vuoi sapere sul tuo conto corrente?
  • Che tipo di prodotto vuoi acquistare?
  • Devo raccogliere alcune informazioni sulla maglietta che vuoi ordinare.
• Route: questo fulfillment viene chiamato quando viene chiamata una route di intent o di condizione con fulfillment. Questo è utile quando vuoi un messaggio che risponda all'utente finale in merito alla corrispondenza dell'intent, alla condizione soddisfatta (che può essere una condizione di completamento del modulo) o alla transizione. Ad esempio:
  • Sì, il tuo piano internazionale include il Giappone. (corrispondenza intento)
  • Vuoi acquistare 300 magliette? (condizione di confronto soddisfatta)
  • Ok, il tuo appuntamento è per le 07:00 di domani mattina. (compilazione modulo)
  • Ok, ora parliamo di aardvark. (transizione)
• Gestori di eventi: questo fulfillment viene richiamato quando viene richiamato un evento. È utile quando vuoi un messaggio che risponda all'evento. Ad esempio:
  • L'azione che stai prendendo in considerazione per l'acquisto è appena aumentato del 10%. (evento personalizzato)
  • Puoi riformulare la frase? (evento senza corrispondenza)
• Prompt iniziali per i moduli: questo evasione viene chiamato quando l'agente esegue la compilazione dei moduli. Questi messaggi dovrebbero porre una domanda specifica all'utente finale. Ogni parametro del modulo ha il proprio completamento del prompt iniziale. Ad esempio:
  • Che taglia di maglietta vorresti?
  • Di che colore maglietta vorresti?
• Gestori di richieste di risposta per i moduli: questo fulfillment viene chiamato quando l'agente sta eseguendo la compilazione dei moduli e non comprende la selezione del parametro corrente da parte dell'utente finale. Questo fulfillment è necessario solo se vuoi che un messaggio di ripetizione sia diverso dal messaggio di richiesta iniziale. Se non esistono gestori di richieste, l'agente userà solo il prompt iniziale come messaggio di ripetizione. Ad esempio:
  • Non ho capito. Potresti fornire un colore valido per la camicia?

Denominazione

Questa sezione fornisce consigli per denominare le risorse degli agenti.

Denominazione intent

Se l'agente ha molti intent, dovresti considerare uno schema di denominazione che ti aiuti a organizzarli. È pratica comune segmentare i nomi di intent con la punteggiatura, dove la specificità aumenta da sinistra a destra. Inoltre, il nome dell'intent dovrebbe riflettere l'intenzione dell'utente finale di passare alla conversazione.

Esistono molti schemi di denominazione validi, ma ecco un esempio:

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

Transizioni

Le transizioni definite nei gestori di stato forniscono il controllo sulla conversazione modificando la pagina attiva. Questa sezione fornisce consigli per organizzare le transizioni degli agenti.

Transizioni gratuite

Quando definisci una route che attiva una transizione, considera che può esistere una route complementare o inversa.

Ad esempio:

• Se hai un intent per confirmation.yes, valuta la possibilità di definire un altro percorso per confirmation.no.
• Se definisci una route di condizione con un operatore booleano =, valuta la possibilità di definire un'altra route che utilizzi !=.

Gestione dell'input utente finale

Questa sezione fornisce linee guida per intent e frasi di addestramento, in modo che l'agente possa gestire ed elaborare in modo ottimale l'input utente finale.

Definisci almeno 20 frasi di addestramento

Dovresti avere almeno 20 frasi di addestramento per ogni intento. In caso contrario, il modello NLU potrebbe non avere informazioni sufficienti per soddisfare adeguatamente il tuo intento. Questa è una linea guida minima. Idealmente, dovresti definirne di più, soprattutto per gli intent head degli agenti di grandi dimensioni, dove ne sono desiderabili circa 50.

Sii consapevole del bias di intenzione

Quando uno o più intent hanno un numero notevolmente maggiore di frasi di addestramento rispetto ad altri, il modello NLU fa un bias per gli intent più ampi a causa di dati non bilanciati. Questo bias di intent può verificarsi quando la quantità di frasi di addestramento varia di un ordine di grandezza o superiore.

In alcuni casi, questo è il comportamento desiderato, perché potresti definire alcuni intent che dovrebbero essere abbinati più spesso di altri, perché corrispondono agli input dell'utente finale osservati più spesso nel traffico in tempo reale.

In altri casi, questo comportamento potrebbe essere indesiderato, perché non si vuole un pregiudizio a favore di questi intenti più ampi. In questo caso, riduci il numero di frasi di addestramento per questi intent più ampi in modo che siano dello stesso ordine di grandezza di altri intent. Ad esempio:

Frasi di addestramento Intent A	Frasi di addestramento Intent B	Pregiudizi per l'intenzione B
20	50	No
20	200	Al limite
20	2000	Sì

Utilizzo dell'entità e quantità della frase di addestramento

Per tutti i tipi di entità utilizzati in un intent:

• Annota ogni esempio dei tipi di entità.
• Per ciascuno dei tipi di entità, fornisci almeno cinque frasi di addestramento contenenti esempi annotati.
• Fornisci almeno il triplo di frasi di addestramento rispetto ai tipi di entità. Ad esempio, se utilizzi 10 diversi tipi di entità per le annotazioni in un intent, dovresti avere almeno 30 frasi di addestramento.

Le frasi di addestramento devono essere naturali

Le frasi di addestramento devono essere naturali e conversazionali; devono corrispondere a ciò che le persone dicono. Quando possibile, utilizza come dati di addestramento gli input degli utenti finali che si sono verificati in produzione, prestando particolare attenzione a quelli più comuni.

Varietà necessaria della frase di addestramento

Includi varianti di domande, comandi, verbi e sinonimi di sostantivi comuni per assicurarti che le tue frasi coprano un ampio spettro di richieste possibili.

È meglio includere frasi più brevi come "paga il conto", nonché frasi e frasi più lunghe come "Ho appena ricevuto per posta una cosa che mi comunica che devo pagare il saldo dell'estratto conto". Non è consigliata la proporzione di frasi brevi e lunghe, ma è consigliabile basarsi sugli input effettivi dell'utente finale inviati al tuo agente in produzione.

La definizione di frasi di addestramento che variano in lunghezza, formulazione e struttura della frase è importante per garantire un buon addestramento per il tuo agente. Non è necessario aggiungere varietà per vari scopi, ma è necessario fornire varietà sufficiente per consentire al modello NLU di rilevare correttamente l'intent dell'utente finale da una vasta gamma di input dell'utente finale. Se la varietà è insufficiente, c'è il pericolo di un overfitting. In altre parole, c'è il pericolo che il modello sia troppo strettamente collegato agli esempi specifici che fornisci e non si generalizzi a sufficienza ad altri esempi.

Varietà di lettere maiuscole

In rari casi, potrebbe essere necessario aggiungere frasi di addestramento che variano solo per quanto riguarda l'uso delle lettere maiuscole. Ciò di solito si applica a situazioni in cui prevedi che gli utenti finali forniscono input di testo in lettere maiuscole.

Gli approcci alternativi potrebbero essere:

• Abbassare la soglia di classificazione ML
• Ridurre le lettere maiuscole degli input degli utenti finali prima di inviarli a Dialogflow

Varietà di frasi di addestramento non necessaria

Evita variazioni banali nelle frasi di addestramento, in quanto forniscono informazioni duplicate al modello NLU. Ad esempio, non includere varianti che differiscono solo per:

• Maiuscole (tranne casi rari): ad esempio, "Ordina un biglietto" e "Ordina un biglietto".
• Parole di riepilogo: Ad esempio, "ok, ordina un biglietto" e "ordina un biglietto".
• Punteggiatura: ad esempio, "puoi aiutarmi?" e "puoi aiutarmi?".

Coerenza dell'annotazione

La parte della frase di addestramento selezionata per un'annotazione deve includere tutto il testo necessario per creare una corrispondenza con un'entità, e non oltre. Inoltre, assicurati che parti simili delle frasi di addestramento siano annotate per l'intero intent.

Ad esempio, la seguente tabella mostra i modi corretti e non validi per annotare con l'entità di sistema @sys.date:

Buono	Pessima
Partenza del 7 settembre	Partenza del 7 settembre
Partenza il 4 luglio	Partenza il 4 luglio

Utilizzare annotazioni semanticamente significative per le entità di sistema

Il significato semantico di una parte di una frase di addestramento selezionata per un'annotazione può essere influenzato dal resto del testo in una frase di addestramento. Ad esempio:

Frase di addestramento annotata	Significato semantico del testo annotato
Ho 7 anni	Età di una persona
Il contratto è valido per 7 anni.	Una durata

I modelli di machine learning di Dialogflow tengono in considerazione il significato semantico quando corrispondono alle entità di sistema. Il significato semantico della parte della frase di addestramento deve corrispondere al significato semantico previsto dell'entità di sistema.

Ad esempio, non utilizzare l'entità di sistema @sys.duration per l'annotazione del primo esempio "7 anni" riportato sopra. Il significato semantico di "7 anni" non corrisponde a una durata di tempo semplice. Seleziona invece "7" per l'annotazione e utilizzare l'entità di sistema @sys.number.

Definire gli intenti per gestire le risposte della compilazione di moduli non conformi

Valuta la possibilità di definire degli intenti per gestire le risposte della compilazione di moduli non conformi. Ad esempio, l'agente potrebbe chiedere "Quali sono le date del tuo viaggio?", seguita dalla risposta dell'utente finale: "Non lo so ancora". Questa risposta non soddisfa la richiesta del parametro del modulo, ma se l'agente ha una route di intent nell'ambito che può corrispondere a questa risposta, l'agente può gestire bene la situazione.

Evita @sys.any

Evita di utilizzare il tipo di entità di sistema @sys.any. Deve essere utilizzato solo se hai esaurito tutte le opportunità, inclusa la creazione di entità personalizzate. Questo tipo di entità è molto ampio e può causare comportamenti indesiderati.

Se utilizzi questo tipo di entità, evita di annotare più parti di una singola frase di addestramento con questo tipo di entità, poiché ciò crea ambiguità e il comportamento dell'agente non sarà definito.

È meno pericoloso utilizzare @sys.any con i parametri del modulo, perché l'agente si aspetta informazioni specifiche quando richiede i parametri del modulo.

Nota: alcune entità di sistema non sono disponibili quando esegui la regionalizzazione del deployment dell'agente e a volte @sys.any è consigliata una soluzione alternativa.

Le annotazioni devono includere una varietà di valori delle entità

Quando definisci frasi di addestramento annotate, devi usare vari esempi di valori delle entità. Non dovresti usare sempre lo stesso esempio di entità per le annotazioni. L'esempio seguente mostra annotazioni corrette e non valide per un tipo di entità di prodotto:

Buono	Pessima
voglio acquistare una camicia	voglio acquistare una camicia
Ordina un nuovo cappello	Ordinare una nuova camicia
Aggiungi un orologio al carrello	Aggiungi una camicia al carrello

Le entità personalizzate devono includere vari

Le entità personalizzate devono coprire una vasta gamma di esempi. Il modello NLU offre varietà per le forme grammaticali, ma devi includere tutti gli elementi possibili.

Evita entità con corrispondenze in modo aggressivo

Non definire entità che corrispondono praticamente a qualsiasi cosa. Questo riduce le prestazioni e la qualità del machine learning. Quasi tutto in ogni frase di addestramento viene valutato come possibile abbinamento.

Le entità Mappa ed elenca devono concentrarsi su valori distinti

I tipi di entità di mappatura ed elenchi devono avere un ambito limitato che acquisisce valori distinti di un tipo di informazione. Mantieni le entità mirate, brevi e semplici.

Se i valori dell'entità sono complicati, potrebbe essere dovuto al fatto che le frasi di addestramento dell'intenzione sono più adatte alla tua situazione. Ad esempio, considera l'input utente finale come:

• "Come faccio a effettuare una chiamata internazionale con Piano A?"
• "Utilizzare il roaming dei dati internazionale con Plan B."

Non creare tipi di entità sia per le azioni che per i piani, come segue:

Tipo di entità delle azioni	Tipo di entità Piani
"Come faccio a effettuare una chiamata internazionale"	"Piano A"
"Utilizzo del roaming dei dati internazionale"	"Piano B"

Invece, usa frasi di addestramento e corrispondenze di intent per individuare le azioni e le entità al fine di inquadrare i piani.

Utilizzare entità regexp per acquisire identificatori non basati sulle parole

Quando acquisisci l'input utente finale che riguarda identificatori non basati su parole, devi utilizzare le entità regexp. Ad esempio, per acquisire ID prodotto come "AA-256" o "AC-436", utilizza un'entità regexp come "[A-Z]{2}-\d{3}".

Evita di nidificare entità composite

Non utilizzare più di un livello di nidificazione in entità composite. Ogni livello di nidificazione riduce la qualità in modo significativo.

Evitare intent simili

Ogni intent dovrebbe acquisire le intenzioni dell'utente finale. Se definisci intent diversi con frasi di addestramento simili, la corrispondenza potrebbe non essere affidabile, perché il modello NLU non è in grado di determinare con affidabilità sufficiente, a quale intento trovare una corrispondenza.

Se due frasi di addestramento rappresentano la stessa intenzione, dovrebbero appartenere allo stesso intento. Ad esempio, "Modifica la data di scadenza della fattura corrente" e "più tempo per pagare" devono avere entrambi lo stesso intent, in quanto richiedono entrambe una modifica della data di scadenza. Tuttavia, le frasi "Posso effettuare una chiamata internazionale con il Piano A?" e "Posso utilizzare il roaming dei dati internazionali con il Piano A?" potrebbero appartenere a intent diversi, perché l'utente finale vuole una cosa diversa in ogni caso.

Evita tipi di entità simili

Dovresti evitare di definire più tipi di entità con voci di entità simili, perché questo può creare ambiguità per il modello NLU.

Utilizza gli eventi senza corrispondenza in produzione per migliorare le tue intenzioni

Durante l'esecuzione dell'agente in produzione, è inevitabile che alcuni input dell'utente finale generino eventi senza corrispondenza. Puoi sfruttare queste opportunità per migliorare l'agente in uno dei tre modi seguenti:

• Aggiungi l'input utente finale come frase di addestramento all'intent desiderato. Tuttavia, questa non è sempre l'opzione migliore. Se lo fai più volte per cercare di capire l'intenzione, potresti avere un pregiudizi di intenzione.
• Ripulisci le frasi di addestramento per l'intento desiderato, in modo che riflettano tutte con precisione l'intenzione. In alcuni casi, gli intent con frasi di addestramento divergenti possono impedire la corrispondenza per l'intent.
• Se agli intent che non devono essere abbinati all'input utente finale sono presenti frasi di addestramento che potrebbero corrispondere all'input utente finale, elimina queste frasi di addestramento.

Evita caratteri speciali

I caratteri speciali nelle frasi di addestramento ({, _, #, [ e così via) vengono ignorati. Fanno eccezione le emoticon, che funzionano come previsto.

Evita intercalari

I intercalari sono parole che puoi ignorare e comunque in grado di comprendere il testo. Ad esempio:

• per favore
• per favore
• mmmh
• che ne dici

Non è necessario, ma innocuo, usare intercalari nelle frasi di addestramento, perché vengono ignorati dal modello NLU. Tuttavia, non devi definire frasi di addestramento che variano solo per intercalari.

Non definire mai entità composte da intercalari.

Sperimenta con le impostazioni ML

Le impostazioni ML possono essere utilizzate per regolare il modo in cui viene elaborato l'input utente finale. Nella maggior parte dei casi, le impostazioni predefinite funzionano bene. Tuttavia, ti consigliamo di perfezionare le impostazioni per migliorare le prestazioni degli agenti.

Rispondere all'utente finale

Questa sezione fornisce linee guida per l'utilizzo di fulfillment per rispondere all'utente finale.

Dai il benvenuto all'utente finale

Un agente appena creato ha una route di intent creata automaticamente per l'intent di benvenuto. Devi modificare questa route in modo da includere un messaggio di evasione degli ordini che accetti l'utente finale. Questo messaggio deve descrivere l'agente e dare all'utente finale un'idea delle sue capacità.

Conferma le informazioni dell'utente finale

Spesso è meglio ripetere le informazioni fornite dall'utente finale nelle risposte. Ciò consente all'utente finale di sapere che l'agente sta comprendendo la sua richiesta.

Quando viene trovata una corrispondenza con un intent e avviene una transizione, comunica all'utente finale che la conversazione è in corso in base alla sua richiesta. Ad esempio:

Dialogo	Descrizione
Utente finale: Ho delle domande sul mio conto corrente. Agente: Ok, cosa vuoi sapere sul tuo conto corrente?	L'input utente finale ha generato una corrispondenza dell'intent ed è stata seguita una route che includeva un messaggio di fulfillment e la transizione a una pagina che gestisce le domande relative all'account di verifica. Tieni presente che l'agente conferma che l'utente finale vuole informazioni sul suo conto corrente.

Una volta completata la compilazione del modulo, ripeti i dati forniti dall'utente finale. Ad esempio:

Dialogo	Descrizione
Utente finale: Domani Agente: Ok, il taglio di capelli è programmato per domani alle 19:00. Posso esserti d'aiuto in altro modo?	L'utente finale ha fornito il parametro del modulo della data, che è stato l'ultimo parametro del modulo nella pagina attiva. L'agente ha confermato data e ora di un taglio di capelli programmato.

Guida la conversazione

L'agente deve sempre guidare la conversazione con l'utente finale. Puoi farlo facilmente terminando ogni risposta con una domanda come:

• Posso esserti d'aiuto in altro modo?
• Cosa vuoi sapere sui beagle?
• Vuoi annullare o inviare l'ordine?
• Come posso aiutarti oggi?
• Viaggi da solo o con qualcuno?

Quando definisci queste domande, evita di porre più domande come:

• Sei ancora qui? Per quale servizio vuoi avere informazioni?
• Vuoi ancora questo ordine? Vuoi aggiungere qualcosa?

L'utente finale potrebbe rispondere solo a una delle domande e il tuo agente potrebbe non gestire correttamente questa situazione.

Gestione degli errori e dell'input imprevisto dell'utente finale

Questa sezione fornisce consigli sulla gestione degli errori e degli input imprevisti degli utenti finali.

Creazione di gestori di eventi per gli eventi integrati

Devi creare gestori di eventi per gli eventi integrati, a seconda dei casi. La gestione di questi eventi è simile all'individuazione delle eccezioni nella programmazione software. A seconda della situazione, potresti voler gestire gli eventi con gestori di eventi specifici per parametro, gestori di eventi specifici della pagina o gestori di eventi specifici del flusso.

Gestire gli errori del webhook

In caso di errore del servizio webhook, è importante che l'agente possa gestire correttamente l'errore. A questo scopo, definisci i gestori di eventi per gli eventi integrati specifici per i webhook. Ecco un approccio consigliato alla gestione degli errori del webhook:

• Non fornire una destinazione di transizione dal gestore dello stato che attiva la chiamata webhook. In caso contrario, il gestore di eventi di errore webhook non verrà richiamato. Imposta invece la destinazione della transizione nella risposta webhook dal servizio webhook.

• Scegli una pagina in cui un contatore di errori possa essere inizializzato a zero. Questa pagina deve essere attiva prima della pagina che attiva una chiamata webhook. Il fulfillment della voce per questa pagina deve inizializzare il contatore degli errori in 0 utilizzando un valore preimpostato di parametro di fulfillment. Ad esempio:

  Parametro	Valore
  webhook-error-count	0

• Crea una pagina di errore webhook che gestisca gli eventi di errore webhook:

  • Il fulfillment della voce deve confermare l'errore per l'utente finale e deve incrementare un parametro della sessione del contatore di errori utilizzando un valore preimpostato di fulfillment. Ad esempio:

    Parametro	Valore
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Definisci una route condizione il cui numero di errori sia inferiore al numero massimo consentito. (ad esempio, $session.params.webhook-error-count <= 3). Questa route deve avere un fulfillment che comunichi all'utente finale che l'agente proverà a ritentare. Questa route deve avere una destinazione di transizione impostata su PREVIOUS_PAGE o su qualsiasi pagina che possa fare un altro tentativo di chiamare il webhook.

  • Definisci una route di condizione con una condizione in cui il numero di errori superi il massimo consentito (ad esempio $session.params.webhook-error-count > 3). Questa route deve avere un fulfillment che comunichi all'utente finale che l'agente non farà più nuovi tentativi. Questa route deve avere una pagina di destinazione della transizione impostata su una pagina che non attiverà nuovi tentativi di webhook.

• Il gestore di eventi webhook deve avere una destinazione di transizione che passa alla pagina di errore del webhook.

Strumenti

Questa sezione fornisce consigli su come utilizzare gli strumenti per migliorare la progettazione degli agenti.

Utilizzare lo strumento di convalida

Devi utilizzare sempre lo strumento di convalida per controllare l'agente. Questo strumento individua alcuni dei problemi descritti in questa guida.

Utilizzare la funzionalità degli scenari di test

Devi sempre definire gli casi di test per il tuo agente. Questi scenari di test possono aiutare a prevenire le regressioni durante l'evoluzione dell'agente per gestire più scenari.