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 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 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. 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.

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
Nome de exibição Nome exibido no console para a intent.
Rótulos Rótulos que ajudam a categorizar intents. Por exemplo: intent de head.
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.
Padrões de DTMF Consulte DTMF para integrações de telefonia.

Webhook

Webhooks são serviços que hospedam sua lógica de negócios ou chamam outros serviços. 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.

Um webhook 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 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, ele agora 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 gerenciador 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 gerenciador 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.
Destino de transição do gerenciador 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 processadas pelos Serviços do Google nesta região, e o Dialogflow mantém os dados em repouso fisicamente dentro da região ou localização geográfica. 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 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.

Integrações

Atualmente, o Dialogflow CX fornece várias integrações integradas com outras plataformas de conversa. Essas integrações fornecem uma interface para o usuário final, e ele chama a API Dialogflow para 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 uma entrada para o Dialogflow, que 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.

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 ou integração 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 a interface do usuário ou o sistema de integração.
  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.