Questo documento descrive le nozioni di base sull'utilizzo di Dialogflow CX. Fornisce una panoramica dei concetti più importanti.
Agenti
Un agente Dialogflow è un agente virtuale che gestisce le conversazioni simultanee con gli utenti finali. È un modulo di comprensione del linguaggio naturale che capisce le sfumature del linguaggio umano. Dialogflow converte il testo o l'audio dell'utente finale durante una conversazione in dati strutturati comprensibili dalle tue app e dai tuoi servizi. Puoi progettare e creare un agente Dialogflow per gestire i tipi di conversazioni richiesti per il sistema.
Un agente Dialogflow è simile a un agente di call center umano. Li addestri a entrambi per gestire gli scenari di conversazione previsti, senza che la tua formazione sia eccessivamente esplicita.
Flussi
I dialoghi complessi spesso coinvolgono più argomenti di conversazione. Ad esempio, un addetto alla consegna di pizza potrebbe avere ordine di cibo, informazioni sul cliente e conferma come argomenti distinti. Ogni argomento richiede più turni conversazionali per consentire all'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 denominato Flusso di avvio predefinito. Potrebbe bastare un unico flusso per un agente semplice. Gli agenti più complicati potrebbero richiedere flussi aggiuntivi e la creazione e la gestione di questi flussi possono essere gestite da diversi membri dei team di sviluppo. Ad esempio, i flussi di un addetto alla consegna di pizza potrebbero avere il seguente aspetto:
I flussi Dialogflow CX hanno uno scopo simile ai sub-agenti per i mega agenti Dialogflow ES. I flussi offrono un migliore controllo delle conversazioni e non prevedono costi aggiuntivi.
Pages
Una conversazione (sessione) di Dialogflow CX può essere descritta e visualizzata come una macchina a stato. Gli stati di una sessione CX sono rappresentati da pagine.
Per ogni flusso, devi definire molte pagine, in cui le pagine combinate possono gestire una conversazione completa sugli argomenti per i quali è progettato il flusso. In un determinato momento, esattamente una pagina è la pagina corrente, la pagina corrente è considerata attiva e il flusso associato a questa pagina è considerato attivo. Ogni flusso ha una pagina iniziale speciale. Quando un flusso diventa attivo, la pagina iniziale diventa la pagina corrente. Ad ogni svolta della conversazione, la pagina corrente rimarrà invariata o passerà a un'altra pagina.
Configuri ogni pagina in modo da raccogliere informazioni dall'utente finale pertinenti allo stato conversazionale rappresentato dalla pagina. Ad esempio, puoi creare le pagine (in blu) nel diagramma seguente per il flusso Ordine di cibo di un addetto alla consegna di pizza. Il nodo Inizio del diagramma rappresenta la pagina iniziale del flusso Ordine 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 i dati provenienti dall'input utente finale vengono estratti. I tipi di entità CX sono molto simili ai tipi di entità ES.Dialogflow fornisce entità di sistema predefinite che possono corrispondere a molti tipi di dati comuni. Ad esempio, esistono entità di sistema per date, orari, colori, indirizzi email corrispondenti e così via. Puoi anche creare le tue entità personalizzate per la corrispondenza dei dati personalizzati. Ad esempio, puoi definire un'entità vegetale che può corrispondere ai tipi di verdure disponibili per l'acquisto con l'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 logica o generare risposte.I parametri CX sono simili ai parametri ES, ma l'utilità e l'ambito sono stati ampliati e la sintassi per fare riferimento ai parametri è cambiata.
Moduli
Per ogni pagina puoi definire un modulo, ovvero un elenco di parametri che dovrebbero essere raccolti dall'utente finale della 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 di pagina. L'agente raccoglie questi parametri nell'ordine definito nella pagina. Per ogni parametro del modulo obbligatorio, devi fornire anche i messaggi utilizzati dall'agente per richiedere queste informazioni all'utente finale. Questa procedura è chiamata compilazione di moduli.
Ad esempio, puoi creare un modulo che raccolga il nome e il numero di telefono dell'utente finale per una pagina Collect Customer Info.
La compilazione di moduli CX è simile alla compilazione di slot ES.
Intent
Un intent classifica l'intenzione di un utente finale per un turno di conversazione. Rispetto agli intent ES, gli intent CX sono stati semplificati per renderli una risorsa più riutilizzabile.
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 head. |
| Frasi di addestramento | Le frasi di addestramento sono frasi di esempio per ciò che gli utenti finali potrebbero digitare o dire, note come input dell'utente finale. Quando l'input utente finale è simile a una di queste frasi, Dialogflow corrisponde all'intent. Non è necessario definire tutti gli esempi possibili, perché il machine learning integrato di Dialogflow espande l'elenco con altre frasi simili. |
| Parametri | Sei tu a definire le frasi di addestramento in modo da usare i parametri per estrarre 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 consentono di utilizzare i dati estratti dall'elaborazione del linguaggio naturale di Dialogflow per generare risposte dinamiche, convalidare i dati raccolti o attivare azioni sul backend.Un webhook può essere un hook standard o un webhook flessibile. Con un webhook standard, i campi della richiesta e della risposta sono definiti da Dialogflow. Con un webhook flessibile, puoi definire i campi della richiesta e della risposta.
Fulfillment
Per il suo turno conversazionale, l'agente deve rispondere all'utente finale con una risposta a una domanda, una query di informazioni o la fine della sessione. L'agente potrebbe anche dover contattare il servizio per generare risposte dinamiche o intraprendere azioni per un turno. L'evasione degli ordini viene utilizzata per svolgere tutte queste attività.
Un fulfillment può contenere uno dei seguenti elementi:
- Messaggi di risposta statici.
- Il webhook richiede risposte dinamiche e/o azioni.
- Preimpostazioni dei parametri per impostare o sostituire i valori dei parametri.
Durante il turno di un agente, è possibile (e a volte desiderabile) chiamare più fulfillment, ognuno dei quali può generare un messaggio di risposta. Dialogflow conserva queste risposte in una coda di risposte. Una volta terminato il turno dell'agente, Dialogflow invia le risposte ordinate all'utente finale.
Il fulfillment ES è limitato alla connessione a un servizio webhook. L'ambito del fulfillment CX è stato ampliato, quindi ora copre tutti i tipi di prompt e risposta.
Gestori di stato
I gestori di stato, chiamati semplicemente gestori, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o eseguendo la transizione della pagina corrente. Per ogni svolta conversazionale, vengono valutati i gestori, che possono influire sulla sessione. I gestori hanno tre tipi generali di dati:| Termine | Definizione |
|---|---|
| Requisiti del gestore | Questi sono i requisiti che il gestore deve soddisfare affinché abbia effetto sulla sessione. Un gestore viene definito chiamato quando soddisfa i propri requisiti e influisce in qualche modo sulla sessione. |
| Fulfillment gestore | Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte vengono definite nei dati degli agenti statici o recuperate dinamicamente dal servizio webhook. |
| Destinazione della transizione del gestore | Se viene chiamato un gestore, viene utilizzata una destinazione facoltativa della transizione per cambiare 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 gestore diversi:
| Termine | Definizione |
|---|---|
| Route | Le route vengono chiamate quando un input utente finale corrisponde a un intent e/o a una condizione sullo stato della sessione. Una route con un requisito di intent è anche chiamata route intent. Una route con un solo requisito di condizione è anche chiamata route condizionale. |
| Gestori di eventi | I gestori di eventi vengono chiamati quando viene richiamato un evento. Alcuni eventi integrati vengono attivati quando viene ricevuto un input imprevisto dell'utente finale o quando si verifica un errore del webhook. Puoi anche definire eventi personalizzati da richiamare 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 in ambito per avere effetto sulla sessione. L'ambito viene determinato dall'applicazione di un gestore a un flusso, una pagina o un parametro modulo e dall'attivazione o meno del flusso associato, della pagina associata o dell'agente sta attualmente tentando di compilare il parametro modulo associato. |
| 2. Valutazione | Ogni gestore nell'ambito viene valutato in base all'ordine. Se i requisiti di un gestore vengono soddisfatti, supera la valutazione. |
| 3. Chiamata | Se un gestore rientra nell'ambito e supera la valutazione, viene chiamato. Viene chiamato ogni fulfillment associato e qualsiasi target di transizione associato viene applicato alla sessione. |
Impostazioni di regionalizzazione e geolocalizzazione
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 mantiene i dati at-rest fisicamente all'interno dell'area geografica o della località. Per ottenere le migliori prestazioni, devi scegliere una regione vicina ai tuoi servizi e 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 un nuovo agente con una località diversa.
A ogni località sono associate impostazioni che si applicano al tuo progetto. Nella maggior parte dei casi, non è necessario modificare queste impostazioni di geolocalizzazione 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), scopri di più sulle impostazioni di geolocalizzazione.
Console
Dialogflow fornisce un'interfaccia utente web denominata console Dialogflow CX (consulta la documentazione, apri la console). Puoi utilizzare questa console per creare, creare e testare gli agenti CX. La console CX ha uno scopo simile a quello della console ES, ma l'interfaccia utente della console CX è molto più visiva. Traccia ogni flusso come diagramma di una macchina a stato conversazionale, che semplifica la progettazione e la comprensione degli agenti complessi.
La console di Dialogflow CX è diversa dalla console della Google Cloud Platform (consulta la documentazione, consulta la console aperta). La console di Dialogflow CX viene utilizzata per gestire gli agenti Dialogflow CX, mentre la console di GCP viene utilizzata per gestire le impostazioni Dialogflow CX specifiche di Google Cloud (ad esempio la fatturazione) e altre risorse di Google Cloud.
Nella maggior parte dei casi ti consigliamo di utilizzare la console di Dialogflow CX per creare gli agenti, ma puoi anche utilizzare l'API Dialogflow CX per creare agenti per scenari avanzati.
Integrazioni
Dialogflow CX attualmente fornisce diverse integrazioni integrate con altre piattaforme di conversazione. Queste integrazioni forniscono un'interfaccia utente all'utente finale e quest'ultimo chiama l'API Dialogflow. Devi solo creare l'agente e, facoltativamente, implementare un servizio webhook. Ogni integrazione gestisce le interazioni in modo specifico per piattaforma, perciò consulta la relativa documentazione per i dettagli.
Interazioni
Ad ogni svolta della conversazione, avviene un'interazione. Durante un'interazione, un utente finale invia un input a Dialogflow e Dialogflow invia una risposta. Quando implementi il sistema per gestire le interazioni, hai due opzioni: l'API o un'integrazione.
Quando utilizzi l'API, il sistema deve gestire quanto segue:
- Crea un agente.
- Offri un'interfaccia utente agli utenti finali.
- Richiama l'API Dialogflow a ogni turno della conversazione per inviare l'input utente finale.
- A meno che le risposte dell'agente non siano puramente statiche (non comuni), devi ospitare un servizio webhook per gestire il fulfillment abilitato per webhook.
Quando utilizzi un'integrazione, il sistema deve gestire solo quanto segue:
- Crea un agente.
- Facoltativamente, implementa un servizio webhook.
Il seguente diagramma mostra i passaggi che si svolgono in un turno conversazionale di una sessione.
- L'utente finale digita o pronuncia qualcosa, noto come input dell'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 all'input con un intent o parametro modulo, imposta i parametri in base alle esigenze e aggiorna lo stato della sessione. Se deve chiamare un fulfillment abilitato per webhook, invia una richiesta di webhook al servizio webhook. In caso contrario, vai al passaggio 6.
- Il tuo servizio webhook riceve la richiesta. Il servizio esegue le azioni necessarie, come chiamare le API esterne, eseguire query o aggiornare un database e così via.
- Il servizio webhook crea una risposta e invia una risposta webhook a Dialogflow.
- Dialogflow crea una risposta di rilevamento dell'intento. Se un webhook è stato chiamato, utilizza la risposta fornita nella risposta webhook. Se non è stato chiamato alcun webhook, utilizza la risposta statica definita nell'agente. Dialogflow 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'intento e inoltra la risposta audio o testuale all'utente finale.
- L'utente finale vede o sente la risposta.