Nozioni di base sugli agenti basati su flusso

Questo documento descrive le nozioni di base sull'utilizzo dei flussi di Conversational Agents (Dialogflow CX) per creare un agente. Fornisce una panoramica dei concetti più importanti.

Agenti

Un agente Conversational Agents (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. Conversational Agents (Dialogflow CX) traduce 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 Conversational Agents (Dialogflow CX) per gestire i tipi di conversazioni richiesti per il tuo sistema.

Un agente Conversational Agents (Dialogflow CX) è simile a un agente di call center umano. Li addestrini entrambi a gestire gli scenari di conversazione previsti e la formazione non deve essere eccessivamente esplicita.

Flussi

Le conversazioni complesse spesso coinvolgono più argomenti. 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 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 di conversazione associati. Ogni agente ha un flusso chiamato Flusso di inizio 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 essere responsabili della creazione e della manutenzione di questi flussi. Ad esempio, i flussi di un addetto alla consegna di pizza potrebbero essere i seguenti:

Esempio di diagramma con più flussi.

Pagine

Una conversazione (sessione) di Conversational Agents (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 combinate possono gestire una conversazione completa sui temi 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. Quando un flusso diventa inizialmente attivo, la pagina iniziale diventa la pagina corrente. Per ogni turno di conversazione, la pagina corrente rimarrà invariata o passerà a un'altra pagina.

Configura ogni pagina per raccogliere dall'utente finale informazioni pertinenti per lo stato della conversazione rappresentato dalla pagina. Ad esempio, potresti creare le pagine (in blu) nello schema seguente per un flusso di ordine di cibo di un addetto alla consegna di pizza. Il nodo Inizia del diagramma rappresenta la pagina di inizio del flusso Ordine di cibo. Al termine del flusso, viene eseguito il passaggio al flusso Conferma.

Esempio di diagramma con più flussi.

Tipi di entità

I tipi di entità vengono utilizzati per controllare il modo in cui vengono estratti i dati dall'input utente finale.

Conversational Agents (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, ore, colori, indirizzi email e così via. Puoi anche creare le tue entità personalizzate per abbinare i dati personalizzati. Ad esempio, puoi definire un'entità di verdura che può abbinare i tipi di verdure disponibili per l'acquisto con un agente del supermercato.

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 alcune operazioni logiche 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, fino a quando 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, fornisci anche prompt che l'agente utilizza per richiedere queste informazioni all'utente finale. Questa procedura è chiamata 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'intenzione contiene i seguenti dati:

Termine Definizione
Nome visualizzato Nome visualizzato nella console per l'intent.
Etichette Etichette che aiutano a classificare le intenzioni. Ad esempio: intent principale.
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, Conversational Agents (Dialogflow CX) trova una corrispondenza con l'intent. Non devi definire ogni possibile esempio, perché il machine learning integrato degli agenti conversazionali (Dialogflow CX) amplia il tuo elenco con altre frasi simili.
Parametri Definisci le frasi di addestramento in modo da utilizzare 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 aziendale o chiamano altri servizi. Durante una sessione, gli webhook ti consentono di utilizzare i dati estratti dall'elaborazione del linguaggio naturale degli agenti conversazionali (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 Conversational Agents (Dialogflow CX). Con un webhook flessibile, puoi definire 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 chiusura della sessione. L'agente potrebbe anche dover contattare il tuo servizio per generare risposte dinamiche o intraprendere azioni per una svolta. Per eseguire tutte queste operazioni viene utilizzato il fulfillment.

Un adempimento può contenere uno dei seguenti elementi:

  • Messaggi di risposta statici.
  • Le chiamate webhook richiedono risposte dinamiche e/o l'esecuzione di azioni.
  • Preimpostazioni dei parametri per impostare o ignorare i valori dei parametri.

Durante il turno di un agente, è possibile (e a volte auspicabile) chiamare più adempimenti, ciascuno dei quali può generare un messaggio di risposta. Conversational Agents (Dialogflow CX) gestisce queste risposte in una coda di risposta. Al termine del turno dell'agente, Conversational Agents (Dialogflow CX) invia le risposte ordinate all'utente finale.

Gestori di stato

Gli handler di stato, chiamati anche semplicemente handler, vengono utilizzati per controllare la conversazione creando risposte per gli utenti finali e/o passando alla pagina corrente. Per ogni turno di conversazione, gli handler vengono valutati e possono influire sulla sessione. Gli handler hanno tre tipi generali di dati:

Termine Definizione
Requisiti per i gestori Questi sono i requisiti che devono essere soddisfatti per consentire all'handler di avere un effetto sulla sessione. Si dice che un gestore viene chiamato quando soddisfa i suoi requisiti e influisce in qualche modo sulla sessione.
Fulfillment dell'handler Se viene chiamato un gestore, viene utilizzato un fulfillment facoltativo per creare risposte per gli utenti finali. Queste risposte sono o definite nei dati statici dell'agente o recuperate dinamicamente dal servizio webhook.
Destinazione della transizione dell'handler 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 di inizio del flusso o una pagina all'interno del flusso attualmente attivo.

Esistono due tipi di gestori di stato con requisiti diversi:

Termine Definizione
Route I percorsi vengono chiamati quando un input utente finale corrisponde a un intent e/o viene soddisfatta una condizione relativa allo stato della sessione. Un percorso con un requisito di intent è chiamato anche percorso di intent. Un percorso con solo un requisito di condizione è chiamato anche percorso con condizione.
Gestori di eventi I gestori di eventi vengono chiamati quando viene invocato 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 accade qualcosa al di fuori della conversazione.

Esistono tre passaggi per l'elaborazione di un gestore dello stato:

Termine Definizione
1. Ambito Un gestore deve essere in ambito per avere effetto sulla sessione. L'ambito è determinato dal fatto che un gestore sia applicato a un flusso, a una pagina o a un parametro di modulo e dal fatto che il flusso associato sia attivo, la pagina associata sia attiva o l'agente stia attualmente tentando di compilare il parametro di 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 chiamato qualsiasi adempimento associato e qualsiasi target di transizione associato viene applicato alla sessione.

Impostazioni di regionalizzazione e località

Quando crei un agente, devi specificare una regione come posizione dell'agente. Le richieste inviate all'agente vengono gestite dai servizi Google in questa regione e Conversational Agents (Dialogflow CX) mantiene 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, l'agente non può essere spostato. 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 al progetto. Nella maggior parte dei casi, non è necessario modificare queste impostazioni di geolocalizzazione, poiché quelle 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 geolocalizzazione.

Console

Conversational Agents (Dialogflow CX) fornisce un'interfaccia utente web chiamata console Dialogflow CX (visita la documentazione, apri la console). Utilizza questa console per creare, compilare e testare gli agenti. Grafica ogni flusso come un diagramma della macchina a stati conversazionale, che semplifica la progettazione e la comprensione di agenti complessi.

La console Dialogflow CX è diversa dalla Google Cloud Console (visita la documentazione, apri la console). La console Dialogflow CX viene utilizzata per gestire gli agenti Conversational Agents (Dialogflow CX), mentre la Google Cloud Console viene utilizzata per gestire le impostazioni di Conversational Agents (Dialogflow CX) specifiche di Google Cloud (ad es. la fatturazione) e altre risorse Google Cloud.

Nella maggior parte dei casi, devi utilizzare la console Dialogflow CX per creare agenti, ma puoi anche utilizzare l'API Dialogflow per creare agenti per scenari avanzati.

Integrazioni

Conversational Agents (Dialogflow CX) offre diverse integrazioni predefinite con altre piattaforme di conversazione. Queste integrazioni forniscono un'interfaccia utente all'utente finale e chiamano l'API per te. Devi solo creare l'agente e, facoltativamente, implementare un servizio di webhook. Ogni integrazione gestisce le interazioni in modo specifico per la piattaforma, quindi consulta la documentazione specifica dell'integrazione per maggiori dettagli.

Interazioni

Per ogni turno di conversazione, avviene un'interazione. Durante un'interazione, un utente finale invia un input a Conversational Agents (Dialogflow CX), che 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 tuo 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 l'input utente finale all'API.
  • A meno che le risposte dell'agente non siano puramente statiche (non comuni), devi ospitare un servizio webhook per gestire il completamento attivato tramite webhook.

Quando utilizzi un'integrazione, il tuo sistema deve gestire solo quanto segue:

  • Crea un agente.
  • Se vuoi, implementa un servizio webhook.

Il seguente diagramma mostra i passaggi che vengono eseguiti per un turno di conversazione di una sessione.

Diagramma di flusso dell'API.

  1. L'utente finale digita o dice qualcosa, noto come input dell'utente finale.
  2. L'interfaccia utente o il sistema di integrazione riceve l'input e lo inoltra all'API Dialogflow in una richiesta di rilevamento dell'intenzione.
  3. L'API Dialogflow riceve la richiesta di rilevamento dell'intento. 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'implementazione abilitata per gli webhook, invia una richiesta webhook al tuo servizio webhook, altrimenti vai al passaggio 6.
  4. Il 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.
  5. Il servizio webhook genera una risposta e la invia nuovamente a Conversational Agents (Dialogflow CX).
  6. Conversational Agents (Dialogflow CX) crea una risposta di rilevamento dell'intent. Se è stato chiamato un webhook, viene utilizzata la risposta fornita nella risposta dell'webhook. Se non è stato chiamato alcun webhook, viene utilizzata la risposta statica definita nell'agente. Conversational Agents (Dialogflow CX) invia una risposta di rilevamento dell'intenzione alla tua interfaccia utente o al tuo sistema di integrazione.
  7. L'interfaccia utente o il sistema di integrazione riceve la risposta al rilevamento dell'intenzione e inoltra la risposta di testo o audio all'utente finale.
  8. L'utente finale vede o sente la risposta.