Práticas recomendadas gerais de design de agentes

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

Consulte também o guia de design de agentes de voz especificamente para projetar agentes de voz e o guia de práticas recomendadas para usar o serviço do Dialogflow.

Recomendações gerais

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. Depois que a estrutura básica for estabelecida, itere os caminhos de conversa para garantir que todas as rotas possíveis que um usuário final pode seguir.

Enquanto seu agente evolui, use o recurso de casos de teste para o desenvolvimento conduzido por testes.

Agentes pré-criados

O Dialogflow oferece modelos de agentes para ajudar você a começar. Os agentes pré-criados abrangem 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 fulfillment específicos para sua empresa, e você vai criar rapidamente um agente funcional.

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

Há várias maneiras de fazer a integração com os agentes do Dialogflow. Esta seção fornece práticas recomendadas para escolher como fazer a integração.

Integrações

As integrações do Dialogflow fornecem uma interface de usuário pronta para uso para o agente. Se você usar uma integração, não precisará chamar diretamente a API Dialogflow, porque as integrações fazem isso para você. Essas integrações podem fornecer um agente de texto que pode ser incorporado ao seu site, conectado a outras plataformas de mensagens ou uma interface de telefonia.

API Dialogflow

Se nenhuma das integrações prontas para uso for adequada ou se você quiser personalizar a interface do seu sistema, use a API Dialogflow diretamente. Com essa abordagem, você precisará implementar a interface do usuário do seu agente ou usar uma interface de usuário existente.

Webhooks

A menos que seu agente possa ser completamente definido com dados estáticos, você precisa usar webhooks para conectar seu serviço e fornecer um agente que possa 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 pretendido. Esta seção fornece conselhos para escolher os recursos certos para os cenários certos.

Fluxos e páginas

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

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

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

Se o design do agente tiver muitos fluxos por agente, combine tópicos relacionados em um único fluxo. Por exemplo, é possível combinar os seguintes tópicos em um único fluxo "Receber saldo":

• Conferir saldo corrente
• Conseguir o saldo de poupança
• Conseguir o saldo da hipoteca
• Acessar saldo de crédito

Se o design do agente tiver muitas páginas por fluxo, combine páginas relacionadas e use muitas rotas por página.

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

Veja a seguir a granularidade do controle de conversa dos recursos do agente em ordem crescente de granularidade:

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

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

A principal maneira de o sistema receber dados estruturados do usuário final é por meio de parâmetros. É possível usar parâmetros para intents (parâmetros de intent) ou páginas (parâmetros de formulário).

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

Em alguns casos, é recomendável capturar informações do usuário final durante a transição de uma página para outra. Por exemplo, se o usuário final solicitar um produto específico no início da conversa, capture o produto desejado durante a transição para a página de pedido apropriada. Nesse caso, use parâmetros de intent como parte das rotas de intent.

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

Rotas e grupos de rotas

Se você quiser fazer a transição para outra página, enfileirar uma mensagem de resposta ou chamar um webhook quando uma intent for correspondida ou uma condição for atendida, use rotas.

Se você perceber que está usando o mesmo conjunto de trajetos em várias páginas, use os grupos de rotas. Isso vai evitar duplicações desnecessárias no design do agente.

Reutilização da intent

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

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

• sim
• isso aí
• isso
• ok
• sim
• pode apostar
• absolutamente
• sim, por favor

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

• custos
• nah
• não
• de jeito nenhum
• não é para mim
• de jeito nenhum
• não, obrigado

Essas intents de confirmação reutilizáveis podem ser usadas em muitos cenários no seu agente.

Em alguns casos, você também precisa criar intents de confirmação especializadas. Por exemplo, ao confirmar um pedido, é possível 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 está ativa, as rotas de intent para as quatro intents precisam estar no escopo. Isso garante que qualquer confirmação genérica ou específica do usuário final seja tratada adequadamente.

Intent negativa padrão

Preencha a intent negativa padrão com frases que seus usuários finais podem dizer, mas que não devem corresponder a nenhuma intent no seu agente.

Fulfillment

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

• Fulfillment de entrada de página: esse fulfillment é chamado quando a página fica ativa pela primeira vez. Ele é útil quando você quer uma mensagem que descreva o objetivo da página e só pode ser dita uma vez enquanto a página estiver ativa. Por exemplo:
  • O que você quer saber sobre sua conta corrente?
  • Que tipo de produto você gostaria de comprar?
  • Preciso de algumas informações sobre a camisa que você quer encomendar.
• Rotas: esse fulfillment é chamado quando uma rota de intent ou uma rota de condição com fulfillment é chamada. Isso é útil quando você quer uma mensagem que responda ao usuário final sobre a correspondência da intent, a condição satisfeita (que pode ser uma condição de conclusão de preenchimento de formulário) ou a transição. Exemplo:
  • Sim, seu plano internacional inclui o Japão. (correspondência de intenção)
  • Você quer mesmo comprar 300 camisas? (condição de comparação atendida)
  • Certo, seu compromisso é para as 7h amanhã de manhã. (preenchimento do formulário)
  • Certo, vamos falar sobre porcos-da-terra agora. (transição)
• Gerenciadores de eventos: esse fulfillment é chamado quando um evento é invocado. Ele é útil quando você quer uma mensagem que responda ao evento. Por exemplo:
  • O valor da ação que você está considerando para compra aumentou 10%. (evento personalizado)
  • Você pode reformular isso? (evento sem correspondência)
• Prompts iniciais para formulários: esse fulfillment é chamado quando o agente executa o preenchimento de formulários. Essas mensagens devem fazer ao usuário final uma pergunta específica. Cada parâmetro de formulário tem o próprio fulfillment de comando inicial. Por exemplo:
  • Que tamanho de camisa você quer?
  • De que cor de camisa você gostaria?
• Solicitar novamente gerenciadores 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 do parâmetro atual. Esse fulfillment só será necessário se você quiser que uma nova mensagem seja diferente da inicial. Se não houver gerenciadores de nova solicitação, o agente usará apenas o prompt inicial como a mensagem de nova solicitação. Por exemplo:
  • Não entendi. Você poderia informar uma cor válida para a camisa?

Nomenclatura

Nesta seção, você encontra dicas para nomear recursos do agente.

Nomeação de intents

Caso seu agente tenha muitas intents, considere um esquema de nomenclatura que ajude a mantê-las organizadas. É 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

As transições definidas em gerenciadores de estado fornecem controle sobre a conversa alterando a página ativa. Nesta seção, você encontra dicas para organizar as transições do 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 =, considere definir outra rota que use !=.

Como processar entradas do usuário final

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

Definir pelo menos 20 frases de treinamento

É necessário 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 adequadamente à intent. Essa é apenas uma diretriz mínima. O ideal é definir mais, principalmente para intents principais de agentes grandes, em que cerca de 50 é desejável.

Conhecer o viés da intenção

Quando uma ou mais intents têm muito mais frases de treinamento do que outras, isso faz com que o modelo de PLN seja direcionado a favor das intents maiores devido a dados desequilibrados. Esse viés pode acontecer quando a quantidade de frases de treinamento é diferente em uma ordem de magnitude ou mais.

Em alguns casos, esse é o comportamento esperado, porque você pode definir algumas intents que precisam ser correspondidas com mais frequência do que outras porque correspondem a entradas do usuário final observadas com mais frequência no tráfego 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, reduza o número de frases de treinamento para que essas intents maiores tenham a mesma ordem de magnitude que as outras. 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:

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

As frases de treinamento precisam ser naturais

As frases de treinamento devem ser coloquiais e naturais. Elas devem corresponder ao que as pessoas realmente dizem. Sempre que possível, use entradas de usuários finais que ocorreram na produção como dados de treinamento, prestando atenção especial às mais comuns.

Variedade de frases de treinamento necessárias

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

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

Para garantir um bom treinamento do seu agente, é importante definir frases de treinamento com diferentes comprimentos, formulações e estrutura de sentenças. Não é necessário adicionar variedade em nome da variedade, mas é necessário fornecer variedade suficiente para que o modelo de PLN possa detectar com êxito a intent do usuário final a partir de uma ampla gama de entradas do usuário final. Se você não tiver variedade suficiente, há o perigo de overfitting. Em outras palavras, há o perigo de que o modelo esteja muito intimamente ligado aos exemplos específicos que você fornecer e não se generalize o suficiente para outros exemplos.

Variedade de letras maiúsculas

Em casos raros, pode ser necessário adicionar frases de treinamento que variam apenas no uso de letras maiúsculas. Isso geralmente se aplica a situações em que é esperado que os usuários finais forneçam entradas de texto em letras maiúsculas.

As abordagens alternativas podem ser:

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

Variedade desnecessária de frases de treinamento

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

• Letras maiúsculas (exceto casos raros): por exemplo, "pedir um ingresso" e "pedir um ingresso".
• Palavras de preenchimento: por exemplo, "Ok, comprar um ingresso" e "pedir um ingresso".
• Pontuação: por exemplo, "você pode ajudar?" e "você pode me ajudar?".

Consistência de anotações

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

Por exemplo, a tabela a seguir mostra maneiras boas e ruins de fazer anotações na entidade do sistema @sys.date:

Bom	Ruins
Partida em 7 de setembro	Partida de 7 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 pode ser afetado pelo restante do texto em uma frase de treinamento. Exemplo:

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

Os modelos de machine learning do Dialogflow consideram o significado semântico ao combinar 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 a anotação do primeiro exemplo de "7 anos" acima. O significado semântico de "7 anos" não corresponde a uma duração de tempo simples. Em vez disso, selecione "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

Considere definir intents para processar respostas de preenchimento de formulário não compatíveis. Por exemplo, o agente pode perguntar "Quais são as datas da sua viagem?", seguido pela resposta do usuário final "Ainda não sei". Essa resposta não satisfaz a solicitação do parâmetro de formulário, mas, se o agente tiver uma rota de intent no escopo que possa corresponder a essa resposta, ele poderá lidar bem a situação.

Evitar @sys.any

Evite usar o tipo de entidade do sistema @sys.any. Use essa opção apenas 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 está esperando informações específicas ao solicitar parâmetros de formulário.

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

As anotações precisam incluir uma variedade de valores de entidade

Ao definir frases de treinamento com anotações, use uma variedade de exemplos de valores 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	Ruins
Quero comprar uma camisa	Quero comprar uma camisa
Comprar um chapéu novo	Comprar uma camisa nova
Adicionar um relógio ao meu carrinho	Adicionar uma camisa ao meu carrinho

As entidades personalizadas devem incluir uma variedade

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

Evitar entidades que correspondam de forma agressiva

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á avaliado como uma correspondência possível.

As entidades de mapa e lista precisam se concentrar em valores distintos.

Os tipos de entidade de mapa e lista precisam ter um escopo limitado que capture valores distintos de um tipo de informação. Mantenha suas entidades focadas, curtas e simples.

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

• "Como posso fazer uma chamada internacional com o Plano A?"
• "Usar 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 de ações	Tipo de entidade dos 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 que não sejam palavras

Ao capturar entradas do usuário final que envolvam identificadores não palavras, use entidades regexp. Por exemplo, para capturar IDs de produtos como "AA-256" ou "AC-436", use 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 captar a intenção do usuário final. Se você definir intents diferentes com frases de treinamento semelhantes, a correspondência poderá não ser confiável, porque o modelo de PLN não pode determinar com confiança suficiente qual intent corresponder.

Se duas frases de treinamento representarem a mesma intenção, elas precisarão pertencer à mesma intent. Por exemplo, "mudar a data de vencimento da fatura atual" e "mais tempo para pagar" precisam pertencer à mesma intent, porque ambos solicitam uma mudança na data de vencimento. No entanto, as perguntas "Posso fazer uma chamada internacional com o plano A?" e "Posso usar o roaming de dados internacional com o plano A?" podem pertencer a intents diferentes, porque o usuário final quer uma opção 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 o agente na produção, é inevitável que algumas entradas do usuário final resultem em eventos sem correspondência. É possível usar essas oportunidades para melhorar seu agente de uma destas três maneiras:

• Adicione 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á haver um viés de intent.
• Limpe as frases de treinamento da intent desejada para que todas reflitam a intenção com precisão. Em alguns casos, intents com frases de treinamento divergentes podem impedir a correspondência com a intent.
• Se as intents que não devem corresponder à entrada do usuário final tiverem frases de treinamento que possam corresponder à entrada, exclua-as.

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 desnecessárias

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

• por favor
• você pode, por favor?
• hummm
• que tal

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

Nunca defina entidades compostas de palavras de preenchimento.

Testar configurações de ML

As configurações de ML podem ser usadas para ajustar como a entrada do usuário final é processada. Na maioria dos casos, as configurações padrão funcionam bem. No entanto, é possível ajustar as configurações para melhorar o desempenho do agente.

Resposta ao usuário final

Nesta seção, fornecemos diretrizes sobre o uso do fulfillment para responder ao usuário final.

Dar as boas-vindas ao usuário final

Um agente recém-criado tem uma rota de intent criada automaticamente para a intent de boas-vindas. Edite essa rota para incluir uma mensagem de fulfillment que dê as boas-vindas ao usuário final. É necessário que a mensagem descreva o agente e dê 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 as informações fornecidas pelo usuário final nas respostas. Assim o usuário final sabe que o agente está entendendo a solicitação.

Quando houver uma correspondência com uma intent e uma transição ocorrer, informe ao usuário final que a conversa está progredindo com base na solicitação dele. Exemplo:

Diálogo	Descrição
Usuário final: tenho dúvidas sobre minha conta corrente. Agente: Tudo bem, o que você quer saber sobre essa conta?	A entrada do usuário final resultou em uma correspondência de intent, e foi seguida uma rota que incluía uma mensagem de fulfillment e uma transição para uma página que processa perguntas de verificação da conta. O agente confirma que o usuário final quer informações sobre a conta corrente.

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

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

Orientar a conversa

O agente deve sempre orientar a conversa com o usuário final. Para isso, basta 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 o pedido?
• Em que posso ajudar?
• Você está viajando sozinho ou com alguém?

Ao definir essas perguntas, evite fazer várias perguntas como:

• Você ainda está aqui? Sobre qual serviço você quer saber?
• Você ainda quer este pedido? Você quer adicionar algo?

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

Tratamento de erros e entradas inesperadas do usuário final

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

Criar manipuladores de eventos para eventos integrados

Crie manipuladores de eventos para os eventos integrados, conforme aplicável. O tratamento desses eventos é semelhante a capturar exceções na programação de software. Dependendo da situação, processe os eventos com manipuladores de eventos de parâmetro, de página ou de fluxo.

Processar erros do webhook

Quando o serviço de webhook falha, é importante que seu agente possa lidar com a falha adequadamente. Para isso, defina manipuladores de eventos para os eventos integrados específicos do webhook. Confira uma abordagem recomendada para lidar com erros de webhook:

• Não forneça um destino de transição do gerenciador de estado que acione a chamada de webhook. Caso contrário, o manipulador de eventos de erro do 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 dessa página precisa inicializar o contador de erros como 0 usando uma predefinição de parâmetro de fulfillment. Exemplo:

  Parâmetro	Valor
  webhook-error-count	0

• Crie uma página de erro que processe eventos desse tipo:

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

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

  • Defina uma rota de condição que tenha uma 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 de que o agente tentará novamente. Essa rota precisa ter um destino de transição definido como PREVIOUS_PAGE ou para qualquer página que possa tentar chamar o webhook de novo.

  • Defina uma rota de condição que tenha uma condição de que a contagem de erros seja 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 de que o agente não tentará mais tentar novamente. Essa rota precisa ter um destino de transição definido como uma página que não acionará novas tentativas de webhook.

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

Ferramentas

Nesta seção, você encontra dicas sobre como usar ferramentas para melhorar o design do agente.

Usar a ferramenta de validação

Sempre use a 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 ajudam a evitar regressões enquanto o agente evolui para lidar com mais cenários.