Questo documento descrive le nozioni di base sull'utilizzo dei flussi di Dialogflow CX per creare un agente. Fornisce una panoramica dei concetti più importanti.
Agenti
Un agente Dialogflow CX è un agente virtuale che gestisce conversazioni simultanee con gli utenti finali. Si tratta di un modulo di comprensione del linguaggio naturale che comprende le sfumature del linguaggio umano. Dialogflow CX converte il testo o l'audio dell'utente finale durante una conversazione in dati strutturati comprensibili dalle tue app e dai tuoi servizi. Progetta e crea un agente Dialogflow CX per gestire i tipi di conversazioni richiesti per il tuo sistema.
Un agente CX di Dialogflow CX è simile a un agente di call center umano. Addestri entrambi i modelli per gestire gli scenari di conversazione previsti e l'addestramento non deve essere eccessivamente esplicito.
Flussi
Le finestre di dialogo complesse spesso coinvolgono più argomenti di conversazione. Ad esempio, un agente di consegna di pizze potrebbe avere Ordinazione di cibo, dati del cliente e conferma come argomenti distinti. Ogni argomento richiede più turni di conversazione affinché un agente acquisisca le informazioni pertinenti dall'utente finale.
I flussi vengono utilizzati per definire questi argomenti e i percorsi conversazionali associati. Ogni agente ha un flusso chiamato Flusso di avvio predefinito. Questo singolo flusso potrebbe essere tutto ciò che ti serve per un agente semplice. Gli agenti più complessi potrebbero richiedere flussi aggiuntivi e diversi membri del team di sviluppo possono occuparsi della loro creazione e manutenzione. Ad esempio, i flussi di un agente di consegna di pizze potrebbero essere i seguenti:
Pagine
Una conversazione (sessione) di Dialogflow CX può essere descritta e visualizzata come una macchina a stati. Gli stati di una sessione sono rappresentati da pagine.
Per ogni flusso, definisci molte pagine, che insieme possono gestire una conversazione completa sugli argomenti per cui è stato progettato il flusso. In qualsiasi momento, esattamente una pagina è la pagina corrente, la pagina corrente è considerata attiva e il flusso associato a quella pagina è considerato attivo. Ogni flusso ha una pagina di inizio speciale. Quando un flusso diventa attivo, la pagina iniziale diventa la pagina corrente. Per ogni turno di conversazione, la pagina corrente rimarrà la stessa o passerà a un'altra pagina.
Puoi configurare ogni pagina in modo che raccolga dall'utente finale le informazioni pertinenti per lo stato della conversazione rappresentato dalla pagina. Ad esempio, potresti creare le pagine (in blu) nel diagramma seguente per un flusso di ordinazione di cibo di un agente di consegna di pizze. Il nodo Inizia del diagramma rappresenta la pagina iniziale del flusso Ordinazione di cibo. Al termine del flusso, si passa al flusso di conferma.
Tipi di entità
I tipi di entità vengono utilizzati per controllare il modo in cui vengono estratti i dati dall'input utente finale.Dialogflow CX fornisce entità di sistema predefinite che possono corrispondere a molti tipi di dati comuni. Ad esempio, esistono entità di sistema per la corrispondenza di date, orari, colori, indirizzi email e così via. Puoi anche creare le tue entità personalizzate per la corrispondenza dei dati dei clienti. Ad esempio, puoi definire un'entità verdura che può corrispondere ai tipi di verdure disponibili per l'acquisto con un agente di un negozio di alimentari.
Parametri
I parametri vengono utilizzati per acquisire e fare riferimento ai valori forniti dall'utente finale durante una sessione. Ogni parametro ha un nome e un tipo di entità. A differenza dell'input non elaborato dell'utente finale, i parametri sono dati strutturati che possono essere facilmente utilizzati per eseguire una logica o generare risposte.Moduli
Per ogni pagina, puoi definire un modulo, ovvero un elenco di parametri che devono essere raccolti dall'utente finale per la pagina. L'agente interagisce con l'utente finale per più turni di conversazione, finché non ha raccolto tutti i parametri del modulo richiesti, noti anche come parametri della pagina. L'agente raccoglie questi parametri nell'ordine definito nella pagina. Per ogni parametro del modulo obbligatorio, fornisci anche i prompt che l'agente utilizza per richiedere le informazioni all'utente finale. Questo processo è chiamato compilazione dei moduli.
Ad esempio, potresti creare un modulo che raccoglie il nome e il numero di telefono dell'utente finale per una pagina Collect Customer Info.
Intent
Un intent classifica l'intenzione di un utente finale per un turno di conversazione.
Un intent contiene i seguenti dati:
| Termine | Definizione |
|---|---|
| Nome visualizzato | Nome visualizzato nella console per l'intent. |
| Etichette | Etichette che aiutano a classificare gli intenti. Ad esempio: head intent. |
| Frasi di addestramento | Le frasi di addestramento sono frasi di esempio di ciò che gli utenti finali potrebbero digitare o dire, note come input dell'utente finale. Quando l'input utente finale assomiglia a una di queste frasi, Dialogflow CX trova l'intent corrispondente. Non è necessario definire ogni possibile esempio, perché il machine learning integrato di Dialogflow CX espande l'elenco con altre frasi simili. |
| Parametri | Definisci le frasi di addestramento in modo che utilizzino i parametri per estrarre i valori da parti specifiche dell'input utente finale. |
| Pattern DTMF | Consulta DTMF per le integrazioni di telefonia. |
Webhook
I webhook sono servizi che ospitano la tua logica di business o chiamano altri servizi. Durante una sessione, i webhook ti consentono di utilizzare l'estrazione dati dall'elaborazione del linguaggio naturale di Dialogflow CX per generare risposte dinamiche, convalidare i dati raccolti o attivare azioni sul backend.Un webhook può essere un webhook standard o un webhook flessibile. Con un webhook standard, i campi di richiesta e risposta sono definiti da Dialogflow CX. Con un webhook flessibile, definisci i campi di richiesta e risposta.
Fulfillment
Per il turno di conversazione di un agente, l'agente deve rispondere all'utente finale con una risposta a una domanda, una richiesta di informazioni o la chiusura della sessione. L'agente potrebbe anche dover contattare il tuo servizio per generare risposte dinamiche o intraprendere azioni per un turno. Il fulfillment viene utilizzato per eseguire tutte queste operazioni.
Un fulfillment può contenere uno dei seguenti elementi:
- Messaggi di risposta statici.
- Chiamate webhook per risposte dinamiche e/o per intraprendere azioni.
- Preset dei parametri per impostare o eseguire l'override dei valori dei parametri.
Durante il turno di un agente, è possibile (e talvolta auspicabile) chiamare più fulfillment, ognuno dei quali può generare un messaggio di risposta. Dialogflow CX conserva queste risposte in una coda di risposte. Una volta terminato il turno dell'agente, Dialogflow CX invia le risposte ordinate all'utente finale.
Gestori di stato
I gestori dello stato, chiamati anche semplicemente gestori, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o eseguendo la transizione della pagina corrente. Per ogni turno di conversazione, i gestori vengono valutati e possono influire sulla sessione. I gestori hanno tre tipi generali di dati:| Termine | Definizione |
|---|---|
| Requisiti per i gestori | Questi sono i requisiti che devono essere soddisfatti affinché il gestore abbia effetto sulla sessione. Un gestore viene chiamato quando soddisfa i suoi requisiti e influisce in qualche modo sulla sessione. |
| Fulfillment del gestore | Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte sono definite nei dati statici dell'agente o recuperate dinamicamente dal tuo servizio webhook. |
| Handler transition target | Se viene chiamato un gestore, viene utilizzata una destinazione di transizione facoltativa per modificare la pagina corrente. La pagina successiva può essere solo una pagina iniziale del flusso o una pagina all'interno del flusso attualmente attivo. |
Esistono due tipi di gestori di stato con requisiti diversi:
| Termine | Definizione |
|---|---|
| Route | Le route vengono chiamate quando un input utente finale corrisponde a un intent e/o viene soddisfatta una condizione sullo stato della sessione. Un percorso con un requisito di intent è chiamato anche percorso di intent. Un percorso con un solo requisito di condizione è chiamato anche percorso di condizione. |
| Gestori di eventi | I gestori di eventi vengono chiamati quando viene richiamato un evento. Alcuni eventi integrati vengono attivati quando viene ricevuto un input utente finale imprevisto o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati che richiami quando succede qualcosa al di fuori della conversazione. |
L'elaborazione di un gestore dello stato prevede tre passaggi:
| Termine | Definizione |
|---|---|
| 1. Ambito | Un gestore deve essere nell'ambito per avere effetto sulla sessione. L'ambito è determinato dall'applicazione di un gestore a un flusso, a una pagina o a un parametro del modulo e dall'attivazione del flusso associato, della pagina associata o dal tentativo dell'agente di compilare il parametro del modulo associato. |
| 2. Valutazione | Ogni gestore nell'ambito viene valutato in ordine. Se i requisiti di un gestore sono soddisfatti, la valutazione viene superata. |
| 3. Chiamata | Se un gestore è nell'ambito e supera la valutazione, viene chiamato. Viene richiamato qualsiasi fulfillment associato e alla sessione viene applicata qualsiasi destinazione di transizione associata. |
Impostazioni di regionalizzazione e località
Quando crei un agente, devi specificare una regione come località dell'agente. Le richieste inviate al tuo agente vengono gestite dai servizi Google in questa regione e Dialogflow CX conserva i dati at-rest fisicamente all'interno della regione o località geografica. Per ottenere le migliori prestazioni, devi scegliere una regione vicina ai tuoi servizi e agli utenti finali.
Una volta creato un agente, la sua località non può essere modificata. Per modificare la località di un agente, devi esportare e ripristinare in un nuovo agente con una località diversa.
A ogni località sono associate impostazioni che si applicano a tutto il progetto. Nella maggior parte dei casi, non è necessario modificare queste impostazioni di localizzazione e le impostazioni predefinite funzioneranno bene. Se il tuo sistema richiede chiavi di crittografia gestite dal cliente (spesso richieste da enti governativi o settori regolamentati), scopri di più sulle impostazioni di localizzazione.
Console
La console Dialogflow è un'interfaccia utente che ti consente di creare in modo intuitivo agenti interattivi che utilizzano playbook generativi, datastore generativi e flussi deterministici.
Integrazioni
Dialogflow CX fornisce diverse integrazioni integrate con altre piattaforme di conversazione. Queste integrazioni forniscono un'interfaccia utente all'utente finale e chiamano l'API per tuo conto. Tutto ciò che devi fare è creare l'agente e, facoltativamente, implementare un servizio webhook. Ogni integrazione gestisce le interazioni in modo specifico per la piattaforma, quindi consulta la documentazione dell'integrazione specifica per i dettagli.
Interazioni
Per ogni turno di conversazione, avviene un'interazione. Durante un'interazione, un utente finale invia un input a Dialogflow CX e Dialogflow CX invia una risposta. Hai due opzioni per implementare il tuo sistema per gestire le interazioni: utilizzare l'API o un'integrazione.
Quando utilizzi l'API, il tuo sistema deve gestire quanto segue:
- Crea un agente.
- Fornire un'interfaccia utente per gli utenti finali.
- Chiama l'API Dialogflow per ogni turno di conversazione per inviare l'input utente finale all'API.
- A meno che le risposte dell'agente non siano puramente statiche (un caso non comune), devi ospitare un servizio webhook per gestire il fulfillment abilitato per il webhook.
Quando utilizzi un'integrazione, il tuo sistema deve gestire solo quanto segue:
- Crea un agente.
- Facoltativamente, implementa un servizio webhook.
Il seguente diagramma mostra i passaggi che si verificano per un turno di conversazione di una sessione.
- L'utente finale digita o dice qualcosa, ovvero l'input dell'utente finale.
- La tua interfaccia utente o il tuo sistema di integrazione riceve l'input e lo inoltra all'API Dialogflow in una richiesta di rilevamento dell'intent.
- L'API Dialogflow riceve la richiesta di rilevamento dell'intent. Abbina l'input a un parametro di intent o modulo, imposta i parametri in base alle esigenze e aggiorna lo stato della sessione. Se deve chiamare un fulfillment abilitato per i webhook, invia una richiesta di webhook al tuo servizio webhook, altrimenti vai al passaggio 6.
- Il tuo servizio webhook riceve la richiesta webhook. Il servizio esegue tutte le azioni necessarie, come chiamare API esterne, eseguire query o aggiornare un database e così via.
- Il servizio webhook crea una risposta e invia una risposta webhook a Dialogflow CX.
- Dialogflow CX crea una risposta di rilevamento dell'intent. Se è stato chiamato un webhook, utilizza la risposta fornita nella risposta del webhook. Se non è stato chiamato alcun webhook, utilizza la risposta statica definita nell'agente. Dialogflow CX invia una risposta di rilevamento dell'intent alla tua interfaccia utente o al tuo sistema di integrazione.
- La tua interfaccia utente o il tuo sistema di integrazione riceve la risposta di rilevamento dell'intent e inoltra la risposta di testo o audio all'utente finale.
- L'utente finale vede o sente la risposta.