Práticas recomendadas gerais de design de agentes

Neste guia, apresentamos as práticas recomendadas gerais para projetar todos os tipos de agentes.

Você também vai encontrar design de agente de voz especificamente para projetar agentes de voz, e o práticas recomendadas para usar o serviço do Dialogflow.

Recomendação geral

Criar agentes de modo iterativo

Caso seu agente seja grande ou complexo, comece criando um diálogo que atenda apenas às solicitações de nível superior. Uma vez estabelecida a estrutura básica, iterar nos caminhos de conversa para garantir que esteja cobrindo todos os caminhos possíveis que um usuário final pode seguir.

Enquanto seu agente evolui, use o recurso de casos de teste para o desenvolvimento orientado a testes.

Agentes pré-criados

O Dialogflow oferece modelos de agente para ajudar você a começar. Agentes predefinidos abordar casos de uso comuns, como serviços financeiros, telecomunicações e viagens. Eles vêm com intents e entidades que englobam as consultas de usuários mais comuns. Adicione rotas e atendimento de pedidos específicos para sua empresa. e você criará rapidamente um agente funcional.

Integrações e conexão dos serviços

Há várias maneiras de fazer a integração com os agentes do Dialogflow. Nesta seção, apresentamos as práticas recomendadas para escolher o modo de integração.

Integrações

Dialogflow integrações fornecer uma interface de usuário pronta para uso no agente. Se você usa uma integração, não é preciso chamar diretamente a API Dialogflow, já que as integrações cuidam disso para você. Essas integrações fornecem um agente de texto que pode ser incorporado ao site, conectar-se com outras plataformas de mensagens, ou fornecer uma interface de telefonia.

API Dialogflow

Se nenhuma das integrações prontas para uso for adequada, ou personalizar a interface do sistema, é possível usar a API Dialogflow diretamente. Com essa abordagem, você precisará implementar a interface do usuário para seu agente, ou usar uma interface do usuário atual.

Webhooks

A menos que seja possível definir totalmente o agente com dados estáticos, você precisa usar webhooks para conectar seu serviço e fornecer um agente capaz de lidar com cenários dinâmicos. Isso se aplica se você estiver usando integrações ou a API Dialogflow.

Recursos do agente

Os recursos do agente do Dialogflow podem ser usados de várias maneiras para alcançar o resultado desejado. Esta seção fornece conselhos para escolher os recursos certos nos cenários certos.

Fluxos e páginas

Fluxos e páginas fornecer estrutura ao agente. Pense nas páginas como nós em uma máquina de estado, e fluxos como grupos de páginas relacionadas. Você controla as transições entre nós com gerenciadores de estado; que são chamados quando uma intent é correspondida, quando uma condição é atendida ou um evento é invocado.

Um agente simples pode funcionar bem com um único fluxo, mas quase sempre é melhor projetar agentes complexos com vários fluxos. Cada fluxo deve representar um tópico de alto nível para seu agente, em que cada página associada ao fluxo ajuda a lidar com o tópico. Além disso, cada fluxo pode ter algumas configurações próprias, e pode ser pertencente por um subconjunto de membros da equipe, o que ajuda a dividir o trabalho ao projetar agentes grandes.

Ao projetar um agente grande e complexo, é preciso considerar "fluxos por agente" e "páginas por fluxo" limites de desempenho. Esses limites ajudam a manter o desempenho do agente.

Se o design do agente tiver muitos fluxos por agente, combinar temas relacionados em um único fluxo. Por exemplo: você pode combinar os seguintes tópicos em uma única página "Ver saldo" fluxo:

• Conferir saldo
• Ver saldo poupança
• Ver saldo de hipoteca
• Ver saldo de crédito

Se o design do agente tiver muitas páginas por fluxo, combinar páginas relacionadas e fazer uso de muitas rotas por página.

Se você ainda tiver dificuldade com os limites de fluxo e página, pode ser porque há muita lógica de negócios integrada ao próprio agente. Considere mover essa lógica para webhooks.

Confira a seguir a granularidade do controle de conversas dos recursos do agente em ordem de granularidade crescente:

1. Agentes (um agente lida com todas as conversas)
2. Fluxos (um fluxo lida com um ou mais temas de conversa relacionados)
3. Páginas (uma página lida com uma ou mais rodadas de conversas relacionadas)
4. Rotas (uma rota lida com uma intent do usuário ou verificação de condição)

Parâmetros de intent x parâmetros de formulário

A principal maneira pela qual seu sistema recebe dados estruturados do usuário final é com parâmetros. É possível usar parâmetros para intenções (parâmetros de intent) ou páginas (parâmetros de formulário).

O objetivo principal de algumas páginas é coletar informações específicas do usuário final. Por exemplo: uma página pode ser projetada para coletar as dados de contato do usuário final. Nesse caso, use sempre parâmetros de formulário para coletar essas informações.

Em alguns casos, você pode querer capturar informações do usuário final durante a transição de uma página para outra. Por exemplo: se o usuário final solicita um produto específico no início da conversa, você quer capturar o produto desejado durante a transição para a página de pedidos adequada. Nesse caso, usar parâmetros de intent como parte rotas de intent.

Também há situações em que é ideal usar parâmetros de intent e de formulário. Por exemplo: se o usuário final solicitar uma camiseta pequena no início da conversa, você quer capturar o parâmetro de tamanho desejado (pequeno) durante a transição para a página de pedidos de camisas. A página de pedidos de camisas pode pedir informações adicionais, como a cor desejada. A página de pedidos da camisa precisa ter parâmetros de formulário para tamanho e cor. Neste exemplo, o parâmetro size já foi fornecido e é propagada, então o agente só vai solicitar a cor. No entanto, outras conversas podem seguir um caminho diferente, quando o usuário final não forneceu o tamanho desejado quando a página de pedidos de camisa fica ativa. Ao definir esse parâmetro de ambas as formas, seu agente é mais flexível na forma como extrai as informações.

Observação: quando você define parâmetros com o mesmo ID ou nome de exibição em diferentes intents ou formulários, verifique se o tipo de entidade e outras configurações são os mesmos para todas as definições. Se o tipo de entidade ou outras configurações de parâmetro forem diferentes, use ID do parâmetro exclusivo ou nome de exibição de cada definição.

Rotas e grupos de rotas

Se quiser fazer a transição para outra página, enfileirar uma mensagem de resposta, ou chamar um webhook quando intenção é correspondido ou um estado [condition] é atendida, usam rotas.

Se você usar o mesmo conjunto de trajetos em várias páginas, usam grupos de rotas. Isso evitará duplicações desnecessárias no design do seu agente.

Reutilização de intents

Se você definir várias intents com frases de treinamento semelhantes, reutilize intents em várias páginas. Idealmente, você deve definir algumas intents de uso geral usadas em muitas páginas, e algumas intents específicas que são usadas em uma única página. Isso evitará duplicações desnecessárias no design do seu agente.

Por exemplo: as intents de confirmação costumam ser mais bem definidas como reutilizáveis. Uma intent confirmation.yes pode ter frases de treinamento como:

• sim
• isso mesmo
• sim
• ok
• sim
• pode apostar
• absolutamente
• sim, por favor

Uma intent confirmation.no pode ter frases de treinamento como:

• não
• nah
• não
• de jeito nenhum
• não para mim
• de jeito nenhum
• não

Essas intents de confirmação reutilizáveis pode ser usada em vários cenários com seu agente.

Em alguns casos, considere criar intents de confirmação especializadas. Por exemplo: ao confirmar um pedido, convém ter uma intent order.confirmation.yes especializada com frases de treinamento como:

• o pedido está bom para mim
• Aceito este pedido

E uma intent order.confirmation.no especializada com frases de treinamento como:

• Não quero este pedido
• Não aceito este pedido

Quando a página de confirmação do pedido estiver ativa, as rotas de intent dessas quatro intents precisam estar no escopo. Isso garante que qualquer confirmação genérica ou específica do usuário final serão tratados adequadamente.

Intent negativa padrão

Você deve preencher o intent negativa padrão com frases que seus usuários finais podem dizer, mas não devem corresponder a nenhuma intent do seu agente.

Fulfillment

Há muitas opções para usar fulfillment de responder ao usuário final. Durante a rodada de uma conversa, o agente pode anexar várias mensagens à fila de respostas e a fila concatenada é enviada ao usuário final no final da rodada de conversa. Esta seção descreve cada opção para criar as mensagens individuais.

• Fulfillment da entrada de página: Esse fulfillment é chamado quando a página fica ativa inicialmente. Ele é útil quando você quer uma mensagem que descreva a finalidade da página, e só deve ser dito uma vez enquanto a página estiver ativa. Por exemplo:
  • O que você quer saber sobre sua conta corrente?
  • Que tipo de produto você quer comprar?
  • Preciso coletar algumas informações sobre a camisa que você quer pedir.
• Rotas: Esse fulfillment é chamado quando uma rota de intent ou de condição com fulfillment é chamado. Isso é útil quando você quer que uma mensagem que responda ao usuário final sobre a correspondência com a intent a condição satisfeita (que pode ser condição de preenchimento de formulário), ou a transição. Exemplo:
  • Sim, seu plano internacional inclui o Japão. (correspondência de intent)
  • Você quer mesmo comprar 300 camisas? (condição de comparação atendidas)
  • Ok, seu compromisso é para as 7h de amanhã de manhã. (preenchimento de formulário)
  • Ok, vamos falar sobre porcos-da-terra agora. (transição)
• Manipuladores de evento: Esse fulfillment é chamado quando um evento é invocado. Ele é útil quando você quer uma mensagem que responda ao evento. Por exemplo:
  • A ação que você está considerando para compra aumentou em 10%. (evento personalizado)
  • Você pode reformular isso? (evento sem correspondência)
• Comandos iniciais nos formulários: Esse fulfillment é chamado quando o agente realiza o preenchimento do formulário. Essas mensagens devem fazer uma pergunta específica ao usuário final. Cada parâmetro do formulário tem o próprio fulfillment de comando inicial. Por exemplo:
  • De que tamanho você quer?
  • De que cor você quer?
• Solicitar novo gerenciador de formulários: Esse fulfillment é chamado quando o agente está preenchendo o formulário, e não entende a seleção do usuário final para o parâmetro atual. Esse atendimento só é necessário se você quiser uma nova mensagem diferente da mensagem de comando inicial. Se não houver gerenciadores de reprompt, o agente usará apenas o prompt inicial como a mensagem de reenvio. Por exemplo:
  • Não entendi. Você poderia informar uma cor válida para a camisa?

Nomenclatura

Nesta seção, fornecemos conselhos sobre como nomear recursos do agente.

Nomeação de intents

Se o agente tiver muitos intents, considere um esquema de nomenclatura que ajude a mantê-los organizados. É comum segmentar nomes de intents com pontuação, em que a especificidade aumenta da esquerda para a direita. Além disso, o nome da intent precisa refletir a intenção do usuário final de fazer uma conversa.

Há ótimas esquemas de nomenclatura. Veja alguns exemplo a seguir:

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

Transições

Transições definidas em gerenciadores de estado fornecer controle sobre a conversa alterando a página ativa. Nesta seção, fornecemos conselhos para organizar suas transições de agente.

Transições complementares

Ao definir uma rota que aciona uma transição, considere que pode haver uma rota complementar ou inversa.

Exemplo:

• Se você tiver uma rota de intent para confirmation.yes, considere definir outra rota para confirmation.no.
• Se você definir uma rota de condição com um operador booleano =, defina outra rota que use !=.

Como processar entradas do usuário final

Nesta seção, apresentamos diretrizes para intents e frases de treinamento, para que o agente possa lidar e processar a entrada do usuário final de maneira otimizada.

Defina pelo menos 20 frases de treinamento

Você deve ter pelo menos 20 frases de treinamento para cada intent. Caso contrário, o modelo PLN pode não ter informações suficientes para corresponder à sua intent. Essa é uma diretriz mínima. O ideal é definir mais, especialmente para intents de cabeça de grandes agentes, sendo que cerca de 50 é desejável.

Esteja ciente do viés de intenção

Quando uma ou mais intents têm significativamente mais frases de treinamento do que outras, isso faz com que o modelo PLN favorece as intents maiores, devido ao dados desequilibrados. Esse viés de intent pode acontecer quando a quantidade de frases de treinamento é diferente por uma ordem de magnitude ou mais.

Em alguns casos, esse é o comportamento desejado, porque é possível definir algumas intents que devem ser correspondidos com mais frequência do que outros, porque correspondem às entradas do usuário final com mais frequência no trânsito em tempo real.

Em outros casos, esse comportamento pode ser indesejável, porque você não quer um viés a favor dessas intents maiores. Se esse for o caso, reduzir o número de frases de treinamento para essas intents maiores precisam ter a mesma ordem de magnitude que outras intents. Exemplo:

Frases de treinamento da intent A	Frases de treinamento da intent B	Viés para a intent B
20	50	Não
20	200	Quase atende
20	2000	Sim

Uso de entidades e quantidade de frases de treinamento

Para todos os tipos de entidade usados em uma intent:

• Anotar todos os exemplos dos tipos de entidade.
• Para cada um dos tipos de entidade, forneça pelo menos cinco frases de treinamento contendo exemplos anotados.
• Forneça pelo menos três vezes mais frases de treinamento do que tipos de entidade. Por exemplo: se você usar 10 tipos de entidade diferentes para anotações em uma intent, é preciso ter pelo menos 30 frases de treinamento.

As frases de treinamento devem ser naturais

As frases de treinamento devem ser conversacionais e naturais. elas devem corresponder ao que as pessoas realmente dizem. Sempre que possível, usar entradas do usuário final que ocorreram na produção como dados de treinamento; prestando atenção especial aos mais comuns.

Variedade necessária de frases de treinamento

Incluir variações de perguntas, comandos, verbos e sinônimos de substantivos comuns para garantir que as frases cubram um amplo espectro de possíveis solicitações.

É melhor incluir frases mais curtas, como "pagar minha conta", bem como frases e sentenças mais longas como "Acabei de receber um item pelo correio dizendo que preciso pagar o saldo do meu extrato". Não há uma proporção recomendada de frases curtas para longas, mas você deve basear isso nas entradas reais do usuário final enviados ao seu agente em produção.

definir frases de treinamento com diferentes tamanhos, formulações e estrutura; é importante para garantir um bom treinamento para o agente. Não é necessário adicionar variedade para melhorar a variedade, mas é necessário fornecer variedade suficiente que o modelo PLN consiga detectar de uma ampla gama de entradas do usuário final. Se você não tiver variedade suficiente, existe o risco de overfitting. Em outras palavras, existe o risco de o modelo ficar muito próximo aos exemplos específicos que você fornecer e não generaliza o suficiente para outros exemplos.

Variedade de letras maiúsculas

A sensibilidade à capitalização varia de acordo com Modelo PLN que seu agente está usando.

PLN padrão

O modelo PLN padrão não diferencia maiúsculas de minúsculas. Em casos raros, pode ser necessário adicionar frases de treinamento que variam apenas em letras maiúsculas. Isso geralmente se aplica a situações em que você espera que os usuários finais forneçam entradas de texto em maiúsculas.

As abordagens alternativas podem ser:

• Reduzir o limiar de classificação de ML
• Diminuir as entradas do usuário final antes de enviá-las para o Dialogflow.

PLN avançado

Ao contrário do modelo PLN padrão, o modelo PLN avançado diferencia maiúsculas de minúsculas. Qa recomendamos testar e adicionar os dados relevantes de treinamento em maiúsculas para aumentar e as taxas de correspondência de intent.

Variedade desnecessária de frases de treinamento

Evite variações triviais nas frases de treinamento porque fornecem informações duplicadas ao modelo PLN. Por exemplo: não inclua variantes que diferem apenas por:

• Letras maiúsculas: se você estiver usando o modelo PLN padrão, evite cópias frases como "exceto "Compre um ingresso" e "comprar uma passagem" exceto em raras casos de uso diferentes. No entanto, o modelo PLN avançado diferencia maiúsculas de minúsculas e requer mais frases de treinamento para aumentar as correspondências de intent. Consulte a seção de variedade de maiúsculas e minúsculas para mais detalhes.
• Palavras de preenchimento: Por exemplo, "Ok, peça uma passagem" e "pedir um ingresso".
• Pontuação: Por exemplo, "Você pode ajudar?" e "você pode ajudar, por favor?".

Consistência de anotações

A parte da frase de treinamento selecionada para uma anotação precisa incluir todos os itens a seguir: e não mais do que o texto necessário para corresponder a uma entidade. Além disso, verifique se partes semelhantes das frases de treinamento estão anotadas para toda a intent.

Por exemplo: a tabela a seguir mostra maneiras boas e ruins para anotar com a entidade do sistema @sys.date:

Bom	Ruim
Partida em 7 de setembro	7a partida de setembro
Partida em 4 de julho	Partida em 4 de julho

Usar anotações semanticamente significativas para entidades do sistema

O significado semântico de uma parte da frase de treinamento selecionada para uma anotação podem ser afetadas pelo resto do texto de uma frase de treinamento. Exemplo:

Frase de treinamento com anotação	Significado semântico do texto anotado
Tenho 7 anos	Idade de uma pessoa
O contrato é válido por sete anos.	Uma duração de tempo

Os modelos de machine learning do Dialogflow consideram o significado semântico ao fazer a correspondência de entidades do sistema. O significado semântico da parte da frase de treinamento precisa corresponder ao significado semântico pretendido da entidade do sistema.

Por exemplo, não use a entidade do sistema @sys.duration para anotação dos primeiros "7 anos" exemplo acima. O significado semântico de "7 anos" não corresponde a uma duração simples. Em vez disso, você deve selecionar "7" para a anotação e use a entidade do sistema @sys.number.

Definir intents para processar respostas de preenchimento de formulário não compatíveis

Defina intents para lidar com respostas de preenchimento de formulário não compatíveis. Por exemplo: seu agente pode perguntar "quais são as datas da sua viagem?", seguida pela resposta do usuário final "Ainda não sei". Essa resposta não atende ao comando do parâmetro do formulário, mas, se o agente tiver uma rota de intent no escopo que possa corresponder a essa resposta, seu agente pode lidar bem com a situação.

Evitar @sys.any

Evite usar o tipo de entidade do sistema @sys.any. Ela só deve ser usada se você tiver esgotado todos os caminhos, incluindo a criação de entidades personalizadas. Esse tipo de entidade é muito amplo e pode causar comportamentos indesejados.

Se você usar esse tipo de entidade, evite anotar várias partes de uma única frase de treinamento com esse tipo de entidade, porque isso cria uma ambiguidade, e o comportamento do agente será indefinido.

É menos perigoso usar @sys.any com parâmetros de formulário, porque o agente espera informações específicas ao solicitar parâmetros de formulário.

Observação: algumas entidades do sistema não estão disponíveis quando você regionaliza a implantação do agente, e @sys.any é recomendado como solução alternativa.

Anotações devem incluir uma variedade de valores de entidade

Ao definir frases de treinamento anotadas, use vários exemplos de valor de entidade nas frases. Não use consistentemente o mesmo exemplo de entidade para as anotações. O exemplo a seguir mostra anotações boas e ruins para um tipo de entidade de produto:

Bom	Ruim
Quero comprar uma camiseta	Quero comprar uma camiseta
Pedir um novo chapéu	Peça uma nova camiseta
Adicionar um relógio ao meu carrinho	Adicionar uma camiseta ao meu carrinho

As entidades personalizadas precisam incluir variedade

As entidades personalizadas devem abranger uma grande diversidade de exemplos. O modelo PLN vai fornecer variedade de formas gramaticais, mas você deve incluir todos os itens possíveis.

Evite entidades com correspondência forte

Não defina entidades que correspondam a praticamente tudo. Isso degrada o desempenho e a qualidade do ML. Quase tudo em cada frase de treinamento serão avaliadas como possíveis correspondências.

As entidades Map e List devem se concentrar em valores distintos

Os tipos de entidade "map" e "list" precisam ter um escopo limitado que captura valores distintos de um tipo de informação. Mantenha suas entidades focadas, curtas e simples.

Se os valores de entidade forem complicados, seja porque as frases de treinamento de intent são mais adequadas para sua situação. Por exemplo, considere a entrada do usuário final como:

• "Como posso fazer uma ligação internacional com o Plano A?"
• "Usar o roaming de dados internacional com o Plano B."

Não crie tipos de entidade para as ações e os planos. como o seguinte:

Tipo de entidade "Ações"	Tipo de entidade "Planos"
"Como fazer uma chamada internacional?"	"Plano A"
"Usar roaming de dados internacional"	"Plano B"

Em vez disso, use frases de treinamento e correspondência de intent para capturar as ações e entidades e os planos.

Usar entidades regexp para capturar identificadores não palavras

Ao capturar entradas do usuário final que envolvem identificadores não palavras, você deve usar entidades regexp. Por exemplo: para capturar IDs de produtos, como AA-256 ou "AC-436", usar uma entidade regexp, como "[A-Z]{2}-\d{3}".

Evitar o aninhamento de entidades compostas

Não use mais de um nível de aninhamento em entidades compostas. Cada nível de aninhamento degrada a qualidade de modo significativo.

Evitar intents semelhantes

Cada intent precisa capturar a intenção do usuário final. Se você definir intents diferentes com frases de treinamento semelhantes, a correspondência pode não ser confiável, porque o modelo PLN não consegue determinar com confiança suficiente, qual intent corresponder.

Se duas frases de treinamento representam a mesma intenção, eles devem pertencer à mesma intent. Por exemplo: "alterar a data de vencimento da fatura atual" e "mais tempo para pagar" devem pertencer à mesma intenção, porque ambas estão solicitando uma mudança na data de conclusão. No entanto, "Posso fazer uma ligação internacional com o plano A?" e "Posso usar o roaming de dados internacional com o Plano A?" podem pertencer a diferentes intents, porque o usuário final quer uma coisa diferente em cada caso.

Evitar tipos de entidade semelhantes

Evite definir vários tipos de entidade com entradas de entidade semelhantes, porque isso pode gerar ambiguidade no modelo PLN.

Usar eventos sem correspondência na produção para melhorar as intents

Ao executar seu agente na produção, é inevitável que algumas entradas do usuário final resultem eventos sem correspondência. Use estas oportunidades para melhorar seu agente de uma destas três maneiras:

• Adicionar a entrada do usuário final como uma frase de treinamento à intent desejada. No entanto, essa nem sempre é a melhor opção. Se você fizer isso muitas vezes para a intent, poderá levar a viés de intenção.
• Limpe as frases de treinamento da intent desejada para que todos reflitam com precisão a intenção. Em alguns casos, intents com frases de treinamento divergentes pode impedir a correspondência com a intent.
• Se as intents que não devem corresponder à entrada do usuário final têm frases de treinamento que correspondem à entrada do usuário final, e excluir essas frases de treinamento.

Evite caracteres especiais

Caracteres especiais em frases de treinamento ({, _, #, [ e assim por diante) são ignorados. Uma exceção é para os emoticons, onde eles funcionam como esperado.

Evite palavras de preenchimento

As palavras de preenchimento são palavras que você pode ignorar e ainda conseguir entender o texto. Exemplo:

• por favor
• você pode, por favor?
• hmmm
• e

É desnecessário, mas inofensivo, usar palavras desnecessárias em frases de treinamento, porque elas são ignoradas pelo modelo PLN. No entanto, não defina frases de treinamento que variam somente pelas palavras de preenchimento.

Nunca defina entidades compostas de palavras de preenchimento.

Teste as configurações de ML

A Configurações de ML pode ser usada para ajustar como a entrada do usuário final é processada. Na maioria dos casos, as configurações padrão funcionam bem. No entanto, ajuste as configurações para melhorar o desempenho do agente.

Responder ao usuário final

Nesta seção, apresentamos diretrizes para usar o fulfillment de responder ao usuário final.

Dê as boas-vindas ao usuário final

Um agente recém-criado tem uma rota de intent criada automaticamente para o intenção de boas-vindas. Edite essa rota para incluir uma mensagem de fulfillment que dá as boas-vindas ao usuário final. Esta mensagem deve descrever o agente e dar ao usuário final uma noção do que ele é capaz de fazer.

Confirmar as informações do usuário final

Muitas vezes, é melhor repetir nas respostas as informações fornecidas pelo usuário final. Isso permite que o usuário final saiba que o agente está entendendo a solicitação.

Quando uma intent é correspondida e ocorre uma transição, informe o usuário final que a conversa está progredindo com base na solicitação. Exemplo:

Diálogo	Descrição
Usuário final: Tenho dúvidas sobre minha conta corrente. Agente: Certo, o que você quer saber sobre sua conta corrente?	A entrada do usuário final resultou em uma correspondência de intent, e uma rota foi seguida, incluindo uma mensagem de fulfillment e uma transição para uma página com perguntas sobre contas correntes. Observe que o agente confirma que o usuário final quer saber mais sobre a conta corrente dele.

Quando o preenchimento do formulário for concluído, repetir os dados fornecidos pelo usuário final. Exemplo:

Diálogo	Descrição
Usuário final: Amanhã Agente: Certo, seu corte de cabelo está agendado para amanhã às 19h. Posso ajudar com mais alguma coisa?	O usuário final forneceu o parâmetro do formulário de data, que era o último parâmetro do formulário na página ativa. O agente confirmou a hora e a data do corte de cabelo agendado.

Oriente a conversa

O agente deve sempre orientar a conversa com o usuário final. Isso é fácil de fazer ao encerrar cada resposta com uma pergunta como:

• Posso ajudar com mais alguma coisa?
• O que você quer saber sobre os beagles?
• Quer cancelar ou enviar esse pedido?
• Como posso ajudar?
• Você está viajando sozinho ou com alguém?

Ao definir essas questões, tenha cuidado para evitar fazer várias perguntas como:

• Você ainda está aqui? Sobre qual serviço você quer saber?
• Você ainda quer esse pedido? Você quer adicionar alguma coisa?

O usuário final pode responder a apenas uma das perguntas, e seu agente pode não lidar com essa situação corretamente.

Como lidar com erros e entradas inesperadas do usuário final

Nesta seção, você encontra orientações sobre como lidar com erros e entradas inesperadas do usuário final.

Criar manipuladores de eventos integrados

Você deve criar manipuladores de eventos para o eventos integrados conforme aplicável. O tratamento desses eventos é semelhante à captura de exceções na programação de software. Dependendo da situação, você pode querer processar os eventos com manipuladores de eventos específicos de parâmetros, manipuladores de eventos específicos da página, ou manipuladores de eventos de fluxo.

Processar erros de webhook

Quando o serviço de webhook falha, é importante que o agente lide com a falha de modo prático. Para isso, defina manipuladores de eventos para o tipo eventos integrados. Veja uma abordagem recomendada para lidar com erros de webhook:

• Não forneça um destino de transição do gerenciador de estado que aciona chamada de webhook, caso contrário, o manipulador de eventos de erro de webhook não será invocado. Em vez disso, defina o destino da transição na resposta do webhook do serviço de webhook.

• Escolha uma página em que um contador de erros possa ser inicializado como zero. Essa página precisa estar ativa antes da página que aciona uma chamada de webhook. O fulfillment de entrada desta página precisa inicializar o contador de erros para 0 usando um predefinição do parâmetro de fulfillment. Exemplo:

  Parâmetro	Valor
  webhook-error-count	0

• Crie uma página de erro de webhook que gerencie eventos de erro de webhook:

  • O fulfillment de entrada precisa confirmar a falha para o usuário final. e incrementa um parâmetro de sessão de contador de erros usando uma predefinição do parâmetro de fulfillment. Exemplo:

    Parâmetro	Valor
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Defina um rota de condição com a condição de que a contagem de erros seja menor que o máximo permitido. Por exemplo, $session.params.webhook-error-count <= 3. Essa rota precisa ter um fulfillment que notifique o usuário final que o agente vai tentar novamente. Essa rota deve ter um destino de transição definido como PREVIOUS_PAGE, ou a qualquer página que possa tentar chamar o webhook outra vez.

  • Definir uma rota de condição que tenha a condição de que a contagem de erros é maior que o máximo permitido Por exemplo, $session.params.webhook-error-count > 3. Essa rota precisa ter um fulfillment que notifique o usuário final que o agente não vai mais tentar novamente. Essa rota deve ter um destino de transição definido como uma página que não acionará novas tentativas do webhook.

• O manipulador de eventos do webhook precisa ter um destino de transição que faz a transição para a página de erro do webhook.

Ferramentas

Nesta seção, fornecemos conselhos sobre o uso de ferramentas para melhorar o design do agente.

Usar a ferramenta de validação

Use sempre ferramenta de validação para verificar seu agente. Essa ferramenta encontra alguns dos problemas descritos neste guia.

Usar o recurso de casos de teste

Sempre defina casos de teste para seu agente. Esses casos de teste podem ajudar a evitar regressões enquanto seu agente evolui para lidar com mais cenários.