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. È 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. Progetti e crei un agente Dialogflow CX per gestire i tipi di conversazioni richiesti per il tuo sistema.
Un agente Dialogflow CX è simile a un agente umano del call center. Li addestri entrambi a gestire gli scenari di conversazione previsti e l'addestramento non deve essere eccessivamente esplicito.
Flussi
I dialoghi complessi spesso coinvolgono più argomenti di conversazione. Ad esempio, un agente di consegna di pizza potrebbe avere ordine di cibo, dati del cliente e conferma come argomenti distinti. Ogni argomento richiede più turni di conversazione per consentire a un agente di acquisire 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 il 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 pizza potrebbero essere simili ai 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, in cui le pagine combinate possono gestire una conversazione completa sugli argomenti per cui è progettato il flusso. In un determinato 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 iniziale speciale start page. Quando un flusso diventa attivo inizialmente, la pagina iniziale diventa la pagina corrente. Per ogni turno di conversazione, la pagina corrente rimane invariata o passa a un'altra pagina.
Configura ogni pagina per raccogliere le informazioni dell'utente finale pertinenti allo stato della conversazione rappresentato dalla pagina. Ad esempio, potresti creare le pagine (in blu) nel diagramma riportato di seguito per un flusso Ordine di cibo di un agente di consegna di pizza. Il nodo Avvio del diagramma rappresenta la pagina iniziale del flusso Ordine di cibo. Al termine del flusso, viene eseguita la transizione al flusso Conferma.
Tipi di entità
I tipi di entità vengono utilizzati per controllare la modalità di estrazione dei dati dall'input utente finale.Dialogflow CX fornisce entità di sistema predefinite che possono corrispondere a molti tipi comuni di dati. 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 personalizzati. Ad esempio, potresti definire un'entità di 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 utente finale non elaborato, 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 prompt che l'agente utilizza per richiedere queste informazioni all'utente finale. Questo processo è chiamato compilazione del modulo.
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 intent. Ad esempio: intent principale. |
| Frasi di addestramento | Le frasi di addestramento sono frasi di esempio per ciò che gli utenti finali potrebbero digitare o dire, note come input utente finale. Quando input utente finale assomiglia a una di queste frasi, Dialogflow CX corrisponde all'intent. Non devi 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 logica di business o chiamano altri servizi. Durante una sessione, i webhook ti consentono di utilizzare i dati estratti 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 query per informazioni o la terminazione 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.
- Preimpostazioni dei parametri per impostare o sostituire i valori dei parametri.
Durante il turno di un agente, è possibile (e a volte consigliabile) chiamare più fulfillment, ognuno dei quali può generare un messaggio di risposta. Dialogflow CX mantiene queste risposte in una coda di risposte. Al termine del turno dell'agente, Dialogflow CX invia le risposte ordinate all'utente finale.
Gestori di stato
I gestori di 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 del gestore | Questi sono i requisiti che devono essere soddisfatti affinché il gestore abbia un effetto sulla sessione. Si dice che 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 vengono definite nei dati statici dell'agente o recuperate dinamicamente dal servizio webhook. |
| Target di transizione del gestore | Se viene chiamato un gestore, viene utilizzato un target di transizione facoltativo 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 di gestione 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. Una route con un requisito di intent viene chiamata anche route di intent. Una route con solo un requisito di condizione viene chiamata anche route 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 vengono richiamati quando si verifica qualcosa al di fuori della conversazione. |
L'elaborazione di un gestore di stato prevede tre passaggi:
| Termine | Definizione |
|---|---|
| 1. Ambito | Un gestore deve essere nell'ambito per avere un effetto sulla sessione. L'ambito è determinato dal fatto che un gestore venga applicato a un flusso, a una pagina o a un parametro del modulo e dal fatto che il flusso associato sia attivo, la pagina associata sia attiva o l'agente stia tentando di compilare il parametro del modulo associato. |
| 2. Valutazione | Ogni gestore nell'ambito viene valutato in ordine. Se i requisiti di un gestore vengono soddisfatti, la valutazione viene superata. |
| 3. Chiamata | Se un gestore è nell'ambito e supera la valutazione, viene chiamato. Viene chiamato qualsiasi fulfillment associato e viene applicato alla sessione qualsiasi target di transizione associato. |
Impostazioni relative a regioni 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 mantiene i dati at-rest fisicamente all'interno della regione o località geografica. Per ottenere prestazioni ottimali, 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 esportarlo e ripristinarlo in un nuovo agente con una località diversa.
Ogni località ha impostazioni associate che si applicano a tutto il progetto. Nella maggior parte dei casi, non è necessario modificare queste impostazioni di localizzazione e le impostazioni predefinite funzioneranno correttamente. Se il tuo sistema richiede chiavi di crittografia gestite dal cliente (spesso richieste da enti governativi o settori regolamentati), leggi ulteriori informazioni sulle impostazioni di localizzazione.
Console
Dialogflow CX fornisce un'interfaccia utente web chiamata la console di Dialogflow CX (consulta la documentazione, apri la console). Utilizza questa console per creare, sviluppare e testare gli agenti. Ogni flusso viene rappresentato graficamente come un diagramma di macchina a stati conversazionale, il che semplifica la progettazione e la comprensione degli agenti complessi.
La console di Dialogflow CX è diversa dalla Google Cloud Console (consulta la documentazione, apri la console). La console di Dialogflow CX viene utilizzata per gestire gli agenti Dialogflow CX, mentre la Google Cloud Console viene utilizzata per gestire Google Cloud-specifiche impostazioni di Dialogflow CX (ad esempio, la fatturazione) e altre Google Cloud risorse.
Nella maggior parte dei casi, devi utilizzare la console di Dialogflow CX per creare gli agenti, ma puoi anche utilizzare l'API Dialogflow per creare agenti per scenari avanzati.
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 te. Non devi fare altro che creare l'agente e, facoltativamente, implementare un servizio webhook. Ogni integrazione gestisce le interazioni in modo specifico per la piattaforma, quindi consulta la documentazione specifica dell'integrazione per i dettagli.
Interazioni
Per ogni turno di conversazione, si verifica un'interazione. Durante un'interazione, un utente finale invia input a Dialogflow CX e Dialogflow CX invia una risposta. Quando implementi il sistema per gestire le interazioni, hai due opzioni: utilizzare l'API o un'integrazione.
Quando utilizzi l'API, il sistema deve gestire quanto segue:
- Crea un agente.
- Fornisci un'interfaccia utente per gli utenti finali.
- Chiama l'API Dialogflow per ogni turno di conversazione per inviare input utente finale all'API.
- A meno che le risposte dell'agente non siano puramente statiche (cosa rara), devi ospitare un servizio webhook per gestire il fulfillment abilitato per il webhook .
Quando utilizzi un' integrazione, il sistema deve gestire solo quanto segue:
- Crea un agente.
- Implementa facoltativamente 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, noto come input utente finale.
- L'interfaccia utente o il 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. Corrisponde l'input a un intent o a un parametro del modulo, imposta i parametri in base alle esigenze e aggiorna lo stato della sessione. Se deve chiamare un fulfillment abilitato per il webhook, invia una richiesta webhook al servizio webhook, altrimenti vai al passaggio 6.
- Il servizio webhook riceve la richiesta webhook. Il servizio esegue le azioni necessarie, ad esempio 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 webhook. Se non è stato chiamato alcun webhook, utilizza la risposta statica definita nell'agente. Dialogflow CX invia una risposta di rilevamento dell'intent all'interfaccia utente o al sistema di integrazione.
- L'interfaccia utente o il 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.