Princípios básicos do Dialogflow CX

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 administra conversas com seus usuários finais. Ele é um módulo de processamento de linguagem natural que entende as nuances da fala humana. O Dialogflow converte textos ou áudios de uma conversa com o usuário final em dados estruturados que seus aplicativos e serviços podem entender. Você projeta e cria um agente do Dialogflow para atender aos tipos de conversa solicitadas pelo seu sistema.

Um agente Dialogflow é 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:

Exemplo de diagrama com vários fluxos.

Os fluxos do Dialogflow CX têm uma finalidade semelhante à dos subagentes para mega-agentes do Dialogflow ES. Os fluxos oferecem melhor controle de conversas e não geram custos extras.

Pages

Uma conversa do Dialogflow CX (sessão) pode ser descrita e visualizada como uma máquina de estado. Os estados de uma sessão do CX são representados por 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.

Exemplo de diagrama com vários fluxos.

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. Os tipos de entidade CX são muito semelhantes aos tipos de entidade ES.

O Dialogflow fornece entidades predefinidas 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.

Os parâmetros CX são semelhantes aos parâmetros ES, mas a utilidade e o escopo foram expandidos, e a sintaxe para os parâmetros de referência foi alterada.

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. Para cada parâmetro de formulá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.

O preenchimento de formulários de CX é parecido com o preenchimento de slots de ES.

Intents

Uma intent categoriza a intenção do usuário final em cada conversa. Em comparação com as intents do ES, as intents do CX foram simplificadas para torná-las um recurso mais reutilizável.

Uma intent contém os seguintes dados:

Termo Definição
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 se assemelhar a uma dessas frases, o Dialogflow corresponderá à intent. Você não precisa definir todos os exemplos possíveis, porque o machine learning integrado do Dialogflow expande sua lista com 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.

Webhook

Webhooks são serviços que hospedam a lógica de negócios. Durante uma sessão, os webhooks permitem que você use os dados extraídos pelo processamento de idioma natural do Dialogflow para gerar respostas dinâmicas, validar dados coletados ou ativar ações no back-end.

Os webhooks do CX são semelhantes aos webhooks do ES, mas os campos de solicitação e resposta foram alterados para oferecer suporte aos recursos do CX.

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 mantém essas respostas em uma fila de respostas. Depois que a rodada do agente terminar, o Dialogflow enviará as respostas ordenadas ao usuário final.

O fulfillment de ES é limitado à conexão de um serviço de webhook. O escopo do fulfillment foi aumentado para o CX, por isso, agora ele abrange todos os tipos de prompts e respostas.

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.

Console

O Dialogflow fornece uma interface de usuário da Web chamada Console do Dialogflow CX (acesse a documentação, abra o console). Esse Console é usado para criar, desenvolver e testar agentes CX. O Console do CX tem uma finalidade semelhante ao Console do ES, mas a interface do usuário do Console do CX é muito mais visual. Ele cria um gráfico de cada fluxo como um diagrama de máquina de estado conversacional, o que facilita a criação e a compreensão de agentes complexos.

O Console do Dialogflow CX é diferente do Console do Google Cloud Platform (GCP). Acesse a documentação (em inglês) e abra o Console. Ele é usado para gerenciar agentes do Dialogflow CX, e o Console do GCP é usado para gerenciar configurações do Dialogflow CX específicas do Cloud Platform, como faturamento, e outros recursos do GCP.

Na maioria dos casos, é necessário usar o Console do Dialogflow CX para criar agentes, mas também é possível usar a API Dialogflow Cx para criar agentes de cenários avançados.

Interações do usuário com a API

O uso da API para CX é semelhante ao uso da API para ES, mas alguns caminhos e métodos de recursos foram modificados para acomodar novos tipos, métodos e campos.

Seu sistema precisa lidar com o seguinte:

  • O Dialogflow CX ainda não é compatível com integrações. Portanto, seu sistema precisa fornecer uma interface do usuário para interagir diretamente com os usuários finais.
  • Você precisa chamar a API Dialogflow em cada volta 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.

O diagrama a seguir mostra as etapas que ocorrem em uma rodada de conversa de uma sessão.

Diagrama de fluxo da API.

  1. O usuário final digita ou diz algo, conhecido como entrada do usuário final.
  2. O sistema de interface do usuário recebe a entrada e a encaminha para a API Dialogflow em uma solicitação de detecção de intent.
  3. 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.
  4. 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.
  5. Seu serviço de webhook cria uma resposta e envia uma resposta de webhook de volta para o Dialogflow.
  6. O Dialogflow 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 envia uma resposta de detecção de intent para o sistema de interface do usuário.
  7. 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.
  8. O usuário final vê ou ouve a resposta.