Este documento descreve os princípios básicos do uso do Dialogflow CX. Ele fornece uma visão geral dos conceitos mais importantes.
Agentes
Um agente do Dialogflow CX é um agente virtual que processa as conversas simultâneas com seus usuários finais. Ele é um módulo de processamento de linguagem natural que entende as nuances da fala humana. O Dialogflow CX traduz texto ou áudio do usuário final durante uma conversa a dados estruturados que seus apps e serviços podem entender. Você projeta e cria um agente do Dialogflow CX para lidar com os tipos de conversa necessários para seu sistema.
O agente do Dialogflow CX é semelhante a um agente humano de call center. O agente pode ser treinado para lidar com os cenários comuns de conversas, e o treinamento não precisa ser muito detalhado.
Fluxos
Caixas de diálogo complexas geralmente envolvem vários tópicos de conversa. Por exemplo, um agente de entrega de pizza pode ter pedido, informações do cliente e confirmação como os diferentes tópicos. Cada tópico requer várias rodadas de conversa para que um agente consiga as informações relevantes do usuário final.
Os fluxos são usados para definir esses tópicos e os caminhos de conversa associados. Cada agente tem um fluxo chamado fluxo inicial padrão. Esse fluxo único pode ser tudo o que você precisa para um agente simples. Agentes mais complexos podem exigir fluxos adicionais, e diferentes membros da equipe de desenvolvimento podem ser responsáveis por criar e manter esses fluxos. Por exemplo, os fluxos de um agente de entrega de pizza podem ser semelhantes a:
Páginas
Uma conversa do Dialogflow CX (sessão) pode ser descrita e visualizada como uma máquina de estado. Os estados de uma sessão são representados páginas.
Para cada fluxo, você define muitas páginas. As páginas combinadas podem processar uma conversa completa sobre os tópicos para os quais o fluxo foi projetado. A qualquer momento, exatamente uma página é a página atual, a página atual é considerada ativa e o fluxo associado a essa página é considerado ativo. Todos os fluxos têm uma página inicial especial. Quando um fluxo se torna ativo inicialmente, a página inicial se torna a página atual. Para cada turno de conversa, a página atual permanecerá a mesma ou fará a transição para outra.
Cada página é configurada para coletar informações do usuário final relevantes para o estado de conversa representado pela página. Por exemplo, é possível criar as páginas (em azul) no diagrama abaixo para um fluxo de Pedido de comida de um agente que entrega pizzas. O nó Start do diagrama representa a página inicial do fluxo Food Order. Quando o fluxo for concluído, ele faz a transição para o fluxo de Confirmação.
Tipos de entidade
Os tipos de entidade são usados para controlar como os dados da entrada do usuário final são extraídos.O Dialogflow CX oferece entidades do sistema que podem corresponder a muitos tipos comuns de dados. Por exemplo, há entidades do sistema que correspondem a datas, horários, cores, endereços de e-mail e assim por diante. Também é possível criar suas próprias entidades personalizadas para corresponder a dados personalizados. Por exemplo, defina uma entidade como "vegetal", que corresponda aos tipos de vegetais disponíveis para compra com um agente de mercearia.
Parâmetros
Parâmetros são usados para capturar e fazer referência a valores fornecidos pelo usuário final durante uma sessão. Cada parâmetro tem um nome e um tipo de entidade. Ao contrário da entrada bruta do usuário final, os parâmetros são dados estruturados que podem ser facilmente usados para executar uma lógica ou gerar respostas.Formulários
Para cada página, é possível definir um formulário, que é uma lista de parâmetros que precisam ser coletados do usuário final para a página. O agente interage com o usuário final em várias rodadas de conversas até que ele tenha coletado todos os parâmetros de formulário obrigatórios, também conhecidos como parâmetros de página. O agente coleta esses parâmetros na ordem definida na página. Para cada parâmetro de formulário obrigatório, você também fornece prompts que o agente usa para solicitar essas informações do usuário final. Esse processo é chamado de preenchimento de formulário.
Por exemplo, é possível criar um formulário
que coleta o nome e o número de telefone
do usuário final de uma página Collect Customer Info.
Intents
Uma intent categoriza a intenção do usuário final em cada conversa.
Uma intent contém os seguintes dados:
| Termo | Definição |
|---|---|
| Nome de exibição | Nome exibido no console para a intent. |
| Rótulos | Rótulos que ajudam a categorizar intents. Por exemplo: intent de cabeçalho. |
| Frases de treinamento | As frases de treinamento são exemplos de frases que o usuário final pode digitar ou dizer, conhecidas como entradas do usuário final. Quando a entrada do usuário final for parecida com uma dessas frases, O Dialogflow CX faz a correspondência com a intent. Você não precisa definir todos os exemplos possíveis, porque o machine learning integrado do Dialogflow CX aumenta da lista por outras frases semelhantes. |
| Parâmetros | Você define as frases de treinamento para usar parâmetros que extraem valores de partes específicas da entrada do usuário final. |
| Padrões DTMF | Consulte DTMF para integrações de telefonia. |
Webhook
Webhooks são serviços que hospedam sua lógica de negócios ou chamar outros serviços. Durante uma sessão, os webhooks permitem usar os dados extraídos pelo processamento de linguagem natural do Dialogflow CX para gerar respostas dinâmicas, validar os dados coletados, ou acionar ações no back-end.Ele pode ser padrão ou flexível. Com um webhook padrão, os campos de solicitação e resposta são definidos pelo Dialogflow. Com um webhook flexível, você define os campos de solicitação e resposta.
Fulfillment
No turno de conversas do agente, ele precisa responder ao usuário final com uma resposta a uma pergunta, uma consulta de informações ou o encerramento da sessão. O agente também pode precisar entrar em contato com seu serviço para gerar respostas dinâmicas ou realizar ações por uma volta. O fulfillment é usado para fazer tudo isso.
Um fulfillment pode conter:
- Mensagens de resposta estática.
- Chamadas de webhook para respostas dinâmicas e/ou para realizar ações.
- Predefinições de parâmetros para definir ou substituir valores de parâmetros.
Durante a rodada de um agente, é possível (e às vezes desejável) chamar vários fulfillments, e cada um deles pode gerar uma mensagem de resposta. O Dialogflow CX mantém essas respostas em uma fila de respostas. Quando o turno do agente terminar, O Dialogflow CX envia as respostas ordenadas para o usuário final.
Manipuladores de estado
Manipuladores de estado, também chamados simplesmente de manipuladores, são usados para controlar a conversa criando respostas para usuários finais e/ou fazendo a transição da página atual. Para cada fala na conversa, os manipuladores são avaliados e podem afetar a sessão. Os manipuladores têm três tipos gerais de dados:| Termo | Definição |
|---|---|
| Requisitos do manipulador | Estes são os requisitos que precisam ser atendidos para que o manipulador tenha efeito na sessão. Um manipulador é chamado de chamado quando atende aos requisitos e afeta a sessão de alguma forma. |
| Fulfillment do manipulador | Se um manipulador for chamado, um fulfillment opcional será usado para criar respostas para os usuários finais. Essas respostas são definidas nos dados do agente estático ou recuperadas dinamicamente do serviço de webhook. |
| Meta de transição do manipulador | Se um manipulador for chamado, um destino de transição opcional será usado para alterar a página atual. A próxima página só pode ser uma página inicial de fluxo ou uma página dentro do fluxo ativo no momento. |
Há dois tipos de manipuladores de estado com requisitos de gerenciador diferentes:
| Termo | Definição |
|---|---|
| Rotas | Rotas são chamadas quando uma entrada de usuário final corresponde a uma intent e/ou quando alguma condição no status da sessão é atendida. Uma rota com um requisito de intent também é chamada de rota de intent. Uma rota com apenas um requisito de condição também é chamada de rota de condição. |
| Manipuladores de eventos | Os manipuladores de eventos são chamados quando um evento é invocado. Alguns eventos integrados são acionados quando a entrada inesperada do usuário final é recebida ou quando ocorre um erro do webhook. Também é possível definir eventos personalizados que são invocados quando algo acontece fora da conversa. |
Há três etapas para processar um manipulador de estado:
| Termo | Definição |
|---|---|
| 1. Escopo | O manipulador precisa estar no escopo para ter efeito na sessão. O escopo é determinado pela aplicação de um gerenciador a um fluxo, a uma página ou a um parâmetro de formulário, e se o fluxo associado estiver ativo, a página associada estiver ativa ou se o agente estiver tentando preencher o parâmetro do formulário associado. |
| 2. Avaliação | Cada manipulador no escopo é avaliado em ordem. Se os requisitos de um manipulador forem atendidos, ele será aprovado na avaliação. |
| 3. Chamada | Se um manipulador estiver no escopo e passar na avaliação, ele será chamado. Qualquer fulfillment associado será chamado, e qualquer meta de transição associada será aplicada à sessão. |
Configurações de regionalização e localização
Ao criar um agente, é preciso especificar uma região como local do agente. As solicitações enviadas ao seu agente são tratadas pelos Serviços do Google nesta região e O Dialogflow CX mantém dados em repouso fisicamente na região ou no local geográfico Para ter o melhor desempenho, escolha uma região próxima aos serviços e usuários finais.
Após a criação de um agente, o local não pode ser alterado. Para alterar o local de um agente, exporte e restaure para um novo agente com outro local.
Cada local tem configurações associadas que se aplicam ao seu projeto. Na maioria dos casos, você não precisa editar essas configurações de localização, e as configurações padrão funcionarão bem. Se o sistema exigir chaves de criptografia gerenciadas pelo cliente (geralmente exigidas por entidades governamentais ou setores regulamentados), leia mais sobre configurações de localização.
Console
O Dialogflow CX oferece uma interface do usuário da Web chamada Console do Dialogflow CX (acesse a documentação e abra o console). Esse Console é usado para criar, desenvolver e testar agentes. Cada fluxo é grafado como um diagrama de máquina de estado conversacional, o que torna agentes complexos fáceis de projetar e entender.
O console do Dialogflow CX é diferente no console do Google Cloud (acesse a documentação, abra o console). O console do Dialogflow CX é usado para gerenciar agentes do Dialogflow CX, O console do Google Cloud é usado para gerenciar configurações do Dialogflow CX específicas do Google Cloud (por exemplo, faturamento) e outros recursos do Google Cloud.
Na maioria dos casos, você precisa usar o console do Dialogflow CX para criar agentes, mas também é possível usar a API Dialogflow para criar agentes em cenários avançados.
Integrações
O Dialogflow CX oferece várias ferramentas integrações com outras plataformas de conversação. Essas integrações fornecem uma interface para o usuário final, e chamarem a API por você. Tudo o que você precisa fazer é criar seu agente e, opcionalmente, implementar um serviço de webhook. Cada integração lida com interações de maneira específica da plataforma. Por isso, consulte a documentação específica da integração para mais detalhes.
Interactions
Para cada conversa, ocorre uma interação. Durante uma interação, um usuário final envia entradas para o Dialogflow CX, e o Dialogflow CX envia uma resposta. Você tem duas opções ao implementar seu sistema para lidar com interações: usando a API ou uma integração.
Ao usar a API, o sistema precisa processar o seguinte:
- Crie um agente.
- Forneça uma interface do usuário para usuários finais.
- Chame a API Dialogflow para cada turno de conversa para enviar a entrada do usuário final para a API.
- A menos que as respostas do agente sejam puramente estáticas (incomum), é necessário hospedar um serviço de webhook para processar o fulfillment ativado para webhook.
Ao usar uma integração, seu sistema só precisa processar o seguinte:
- Crie um agente.
- Como alternativa, implemente um serviço de webhook.
O diagrama a seguir mostra as etapas que ocorrem em uma rodada de conversa de uma sessão.
- O usuário final digita ou diz algo, conhecido como entrada do usuário final.
- O sistema de interface do usuário ou integração recebe a entrada e a encaminha para a API Dialogflow em uma solicitação de detecção de intent.
- A API Dialogflow recebe a solicitação de detecção de intent. Ele corresponde a entrada a um parâmetro de intent ou formulário, define parâmetros conforme necessário e atualiza o estado da sessão. Se ele precisar chamar um fulfillment ativado para webhook, ele enviará uma solicitação de webhook para seu serviço de webhook. Caso contrário, vá para a etapa 6.
- O serviço de webhook recebe a solicitação de webhook. Seu serviço realiza todas as ações necessárias, como chamar APIs externas, consultar ou atualizar um banco de dados etc.
- Seu serviço de webhook cria uma resposta e envia uma resposta do webhook de volta para o Dialogflow CX.
- O Dialogflow CX cria uma resposta de intent de detecção. Se um webhook foi chamado, ele usará a resposta fornecida na resposta do webhook. Se nenhum webhook foi chamado, ele usa a resposta estática definida no agente. O Dialogflow CX envia uma resposta de intent de detecção na sua interface do usuário ou sistema de integração.
- O sistema da interface do usuário recebe a resposta de intent de detecção e encaminha o texto ou a áudio para o usuário final.
- O usuário final vê ou ouve a resposta.