Este guia apresenta práticas recomendadas gerais para projetar todos os tipos de agentes.
Consulte também o guia de design de agentes de voz e as práticas recomendadas para usar o serviço de agentes de conversação (Dialogflow CX).
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 de estabelecer a estrutura básica, itere os caminhos de conversa para garantir que todas as rotas possíveis que um usuário final pode seguir foram incluídas.
Enquanto o agente evolui, use o recurso de casos de teste para o desenvolvimento orientado a testes.
Agentes pré-criados
Os agentes de conversação (Dialogflow CX) oferecem 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 crie um agente funcional rapidamente.
Integrações e conexão dos seus serviços
Há várias maneiras de fazer a integração com os agentes de agentes de conversação (Dialogflow CX). Esta seção apresenta as práticas recomendadas para escolher como fazer a integração.
Integrações
As integrações de agentes de conversação (Dialogflow CX) fornecem uma interface do usuário pronta para uso para seu agente. Se você usar uma integração, não será necessário chamar diretamente a API de agentes de conversação (Dialogflow CX), já que as integrações fazem isso por você. Essas integrações podem fornecer um agente de texto que pode ser incorporado ao seu site, conectado a outras plataformas de mensagens ou fornecer uma interface de telefonia.
API Conversational Agents (Dialogflow CX)
Se nenhuma das integrações prontas para uso for adequada ou se você quiser personalizar a interface do seu sistema, use diretamente a API de agentes de conversação (Dialogflow CX). Com essa abordagem, você vai precisar implementar a interface do usuário para seu agente ou usar uma interface do usuário existente.
Webhooks
A menos que o agente possa ser completamente definido com dados estáticos, é necessário usar webhooks para conectar o serviço e fornecer um agente que possa processar cenários dinâmicos. Isso se aplica se você estiver usando integrações ou a API de agentes de conversação (Dialogflow CX).
Recursos do agente
Os recursos de agentes de conversação (Dialogflow CX) podem ser usados de várias maneiras para alcançar o resultado desejado. Esta seção fornece conselhos para escolher os recursos certos para os cenários certos.
Fluxos e páginas
Os fluxos e as páginas estruturam o agente. Pense nas páginas como nós em uma máquina de estados e nos fluxos como grupos de páginas relacionadas. Você controla as transições entre nós com manipuladores 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 projetados melhor com vários fluxos. Cada fluxo precisa representar um tópico de alto nível para o agente, em que cada página associada ao fluxo ajuda a processar o tópico. Além disso, cada fluxo pode ter algumas configurações próprias e pode ser pertencente a 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 a performance do seu agente.
Se o design do agente tiver muitos fluxos por agente, combine os tópicos relacionados em um único fluxo. Por exemplo, você pode combinar os seguintes tópicos em um único fluxo "Receber saldo":
- Conferir o saldo da conta corrente
- Conferir o saldo de economias
- Consultar saldo da hipoteca
- Conferir 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 o fluxo e os limites de página, talvez seja porque há muita lógica de negócios integrada ao agente. Considere mover essa lógica para webhooks.
Confira a seguir a granularidade do controle de conversa dos recursos do agente em ordem crescente:
- Agentes (um agente lida com todas as conversas)
- Fluxos (um fluxo processa um ou mais tópicos de conversa relacionados)
- Páginas (uma página processa uma ou mais rodadas de conversa relacionadas)
- Rotas (uma rota processa uma intent do usuário ou uma verificação de condição)
Parâmetros de intent x parâmetros de formulário
A principal maneira de o sistema receber dados estruturados do usuário final é com parâmetros. É possível usar parâmetros para intents (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, 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, você vai querer capturar o produto desejado durante a transição para a página de pedidos adequada. Nesse caso, use parâmetros de intent como parte de rotas de intent.
Há também situações em que o ideal é usar parâmetros de intent e de formulário. 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 de camisa. A página de pedido de camisas pode solicitar mais informações, como a cor desejada. A página de pedido de camisa 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 só vai solicitar a cor. No entanto, outras conversas podem seguir um caminho diferente, em que o usuário final não forneceu o tamanho desejado quando a página de pedido de camisas fica ativa. Ao definir esse parâmetro de duas maneiras, seu agente fica mais flexível na extração das informações.
Rotas e grupos de rotas
Se você quiser fazer a transição para outra página, colocar uma mensagem de resposta em fila ou chamar um webhook quando uma intent for correspondida ou uma condição for atendida, use rotas.
Se você estiver usando o mesmo conjunto de rotas em várias páginas, use grupos de rotas. Isso evita a duplicação desnecessária no design do agente.
Reutilização de intents
Se você definir várias intents com frases de treinamento semelhantes, reutilize as intents em várias páginas. O ideal é definir algumas intents de finalidade geral que são usadas em muitas páginas e algumas específicas que são usadas apenas em uma única página. Isso evita a duplicação desnecessária no design do agente.
Por exemplo,
as intents de confirmação geralmente são definidas como reutilizáveis.
Uma intent confirmation.yes pode ter frases de treinamento como:
- sim
- sim
- 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 forma alguma
- Agora não
Essas intents de confirmação reutilizáveis podem ser usadas em vários cenários para seu agente.
Em alguns casos,
também é recomendável criar intents de confirmação especializadas.
Por exemplo,
ao confirmar um pedido,
você pode ter uma intent order.confirmation.yes especializada
com frases de treinamento como:
- A ordem parece correta
- Aceito este pedido
E uma intent order.confirmation.no especializada
com frases de treinamento como:
- Não quero este pedido
- Não aceito esse pedido
Quando a página de confirmação do pedido estiver ativa, as rotas de intent para todas essas intents precisam estar no escopo. Isso garante que qualquer confirmação genérica ou específica do usuário final seja processada adequadamente.
Intent negativa padrão
Preencha a intent negativa padrão com frases que os usuários finais podem dizer, mas que não devem corresponder a nenhuma intent no agente.
Fulfillment
Há muitas opções para usar o fulfillment para responder ao usuário final. Durante uma rodada de 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 de entrada de página:
é chamado quando a página se torna ativa inicialmente.
Ele é útil quando você quer uma mensagem que descreve o propósito da página
e só precisa ser dita uma vez enquanto a página está ativa.
Por exemplo:
- O que você quer saber sobre sua conta corrente?
- Que tipo de produto você quer comprar?
- Preciso de 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 é chamada.
Isso é útil quando você quer uma mensagem que responda ao usuário final sobre
a correspondência de intent,
a condição satisfeita (que pode ser uma
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ê tem certeza de que quer comprar 300 camisetas? (condição de comparação atendida)
- Certo, seu horário é amanhã às 7h da manhã. (form filling completion)
- Vamos falar sobre os tatus-tigres. (transição)
- Gerenciadores de eventos:
esse fulfillment é chamado quando um evento é invocado.
Isso é útil quando você quer uma mensagem que responda ao evento.
Por exemplo:
- O valor das ações que você está considerando comprar acaba de aumentar 10%. (evento personalizado)
- Pode reformular? (evento sem correspondência)
- Solicitações iniciais para formulários:
esse fulfillment é chamado quando o agente realiza o preenchimento de formulários.
Essas mensagens devem fazer uma pergunta específica ao usuário final.
Cada parâmetro de formulário tem o próprio fulfillment inicial.
Por exemplo:
- Que tamanho de camisa você quer?
- Qual cor de camisa você quer?
- Gerenciadores de reprompt para formulários:
esse fulfillment é chamado quando o agente está preenchendo um formulário
e não entende a seleção do usuário final para o parâmetro atual.
Essa realização só é necessária se você quiser que uma mensagem de nova solicitação
seja diferente da mensagem de solicitação inicial.
Se não houver gerenciadores de nova solicitação,
o agente vai usar a solicitação inicial como a mensagem de nova solicitação.
Por exemplo:
- Não entendi. Você pode informar uma cor válida para a camisa?
Nomenclatura
Esta seção fornece conselhos para nomear recursos de agentes.
Nomeação de intents
Se o agente tiver muitas intents, considere um esquema de nomenclatura que ajude você 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 manipuladores de estado controlam a conversa mudando a página ativa. Esta seção fornece conselhos para organizar as transições de agentes.
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, defina outra rota para confirmation.no.
- Se você definir uma rota de condição com um operador booleano
=, defina outra rota que use!=.
Como processar a entrada do usuário final
Esta seção fornece diretrizes para intents e frases de treinamento, para que seu agente possa processar e processar de maneira otimizada a entrada do usuário final.
Definir pelo menos 20 frases de treinamento
É preciso ter pelo menos 20 frases de treinamento para cada intent. Caso contrário, o modelo de NLU pode não ter informações suficientes para corresponder adequadamente à sua intenção. Essa é uma diretriz mínima. O ideal é definir mais, principalmente para intenções principais de agentes grandes, em que cerca de 50 é desejável.
Estar ciente do viés de intenção
Quando uma ou mais intents têm muito mais frases de treinamento do que outras, o modelo de NLU é enviesado em favor das intents maiores devido a dados desequilibrados. Esse viés de intenção pode acontecer quando a quantidade de frases de treinamento difere em uma ordem de magnitude ou mais.
Em alguns casos, esse é o comportamento desejado, porque você pode definir algumas intents que precisam ser correspondidas com mais frequência do que outras, porque elas correspondem às 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 uma tendência em favor dessas intenções maiores. Nesse caso, reduz o número de frases de treinamento para essas intents maiores para que elas tenham a mesma ordem de magnitude que outras intents. Exemplo:
| Frases de treinamento da intent A | Frases de treinamento da intent B | Viés da intent B |
|---|---|---|
| 20 | 50 | Não |
| 20 | 200 | Quase atende |
| 20 | 2000 | Sim |
Uso da entidade 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 com 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, terá pelo menos 30 frases de treinamento.
As frases de treinamento precisam ser naturais
As frases de treinamento precisam ser coloquiais e naturais. Elas precisam 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 especial atenção aos que são mais comuns.
Variedade necessária de frases de treinamento
Inclua variações de perguntas, comandos, verbos e sinônimos de substantivos comuns para garantir que as frases englobem um amplo espectro de solicitações possíveis.
É melhor incluir frases mais curtas, como "pagar minha conta", bem como frases mais longas, como "Acabei de receber uma correspondência dizendo que preciso pagar o saldo da fatura". Não há uma proporção recomendada de frases curtas para longas, mas você deve basear isso nas entradas reais do usuário final enviadas para o agente em produção.
Definir frases de treinamento que variam em comprimento, fraseologia e estrutura de frase é importante para garantir um bom treinamento para seu agente. Não é necessário adicionar variedade por si só, mas é necessário fornecer variedade suficiente para que o modelo de NLU possa detectar a intenção do usuário final com base em uma ampla gama de entradas do usuário final. Se você não tiver variedade suficiente, há o perigo de superajuste. Em outras palavras, existe o perigo de o modelo estar muito vinculado aos exemplos específicos que você fornece e não ser generalizado o suficiente para outros exemplos.
Variação de letras maiúsculas e minúsculas
A sensibilidade à capitalização varia de acordo com o modelo de NLU que seu agente está usando.
NLU padrão
O modelo padrão de PLN não diferencia maiúsculas de minúsculas. Em casos raros, talvez seja necessário adicionar frases de treinamento que variam apenas na capitalização. 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:
- Como diminuir o limiar de classificação de ML
- Transforme as entradas do usuário final em letras minúsculas antes de enviá-las aos agentes de conversação (Dialogflow CX).
NLU avançada
Ao contrário do modelo NLU padrão, o modelo NLU avançado diferencia maiúsculas de minúsculas. Recomendamos testar e adicionar os dados de treinamento relevantes com letras maiúsculas para aumentar as taxas de correspondência de intenção.
Variedade desnecessária de frases de treinamento
Evite variações triviais nas frases de treinamento, porque elas 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 NLU padrão, evite frases duplicadas, como "Pedir um ingresso" e "pedir um ingresso", exceto em casos raros. No entanto, o modelo NLU avançado diferencia maiúsculas de minúsculas e exige mais frases de treinamento para aumentar as correspondências de intenção. Consulte a seção de variedade de maiúsculas para mais detalhes.
- Palavras de enchimento: por exemplo, "ok, compre um ingresso" e "compre um ingresso".
- Pontuação: por exemplo, "can you please help?" e "can you please help!?"
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 das frases de treinamento são anotadas para toda a intent.
Por exemplo,
a tabela a seguir mostra maneiras boas e ruins
de fazer anotações com a entidade do sistema @sys.date:
| Bom | Ruim |
|---|---|
| Partida em 7 de setembro | Saída de 7 de setembro |
| Saindo em 4 de julho | Saindo 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 anotada | Significado semântico do texto anotado |
|---|---|
| Tenho 7 anos | A idade de uma pessoa |
| O contrato é válido por 7 anos | Uma duração de tempo |
Os modelos de machine learning dos agentes de conversação (Dialogflow CX) 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 anotar o primeiro exemplo "7 anos" acima.
O significado semântico de "7 anos" não corresponde a um período 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ários não compatíveis
Defina 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 atende ao comando de parâmetro do formulário, mas, se o agente tiver uma rota de intent no escopo que possa corresponder a essa resposta, ele poderá lidar bem com a situação.
Evite @sys.any
Evite usar o tipo de entidade do sistema @sys.any.
Ele só deve ser usado se você tiver esgotado todas as possibilidades,
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.
As anotações precisam incluir vários valores de entidade
Ao definir frases de treinamento anotadas, use vários exemplos de valor de entidade nas frases. Não use 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 camisa | Quero comprar uma camisa |
| Pedir um novo chapéu | Pedir uma nova camiseta |
| Adicionar um relógio ao carrinho | Adicionar uma camisa ao carrinho |
As entidades personalizadas precisam incluir variedade
As entidades personalizadas devem abranger uma grande diversidade de exemplos. O modelo NLU vai oferecer variedade para as formas gramaticais, mas é necessário incluir todos os itens possíveis.
Evite entidades que correspondem 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?"
- "Uso de roaming de dados internacional com o plano B."
Não crie tipos de entidade para as ações e os planos, como estes:
| Tipo de entidade de ações | Tipo de entidade de planos |
|---|---|
| "Como fazer uma chamada internacional" | "Plano A" |
| "Uso do roaming de dados internacional" | "Plano B" |
Em vez disso, use frases de treinamento e correspondência de intent para detectar as ações/entidades e os planos.
Use entidades regexp para capturar identificadores que não são palavras
Ao capturar a entrada do usuário final que envolve identificadores que não sã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}".
Evite aninhar 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 NLU não pode determinar com confiança suficiente qual intent deve ser usada.
Se duas frases de treinamento representarem a mesma intenção, elas precisarão pertencer à mesma intent. Por exemplo, "mudar a data de vencimento da conta atual" e "mais tempo para pagar" precisam pertencer à mesma intenção, porque ambas solicitam uma mudança na data de vencimento. No entanto, "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 algo diferente em cada caso.
Evitar tipos de entidade semelhantes
Evite definir vários tipos de entidade com entradas de entidade semelhantes, porque isso pode causar ambiguidade no modelo de NLU.
Usar eventos sem correspondência na produção para melhorar suas intents
Ao executar o agente na produção, é inevitável que algumas entradas do usuário final resultem em eventos sem correspondências. Você pode usar essas oportunidades para melhorar seu agente de 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á ocorrer um viés de intent.
- Limpe as frases de treinamento da intent desejada para que todas reflitam com precisão a intenção. Em alguns casos, intents com frases de treinamento divergentes podem impedir a correspondência da intent.
- Se as intents que não precisam ser correspondidas à entrada do usuário final tiverem frases de treinamento que podem corresponder à entrada do usuário final, exclua essas frases de treinamento.
Evite caracteres especiais
Caracteres especiais em frases de treinamento
({, _, #, [ e assim por diante) são ignorados.
Uma exceção é para emoticons,
que funcionam como esperado.
Evite palavras desnecessárias
As palavras de enchimento são palavras que você pode ignorar e ainda entender o texto. Exemplo:
- por favor
- Você pode
- hmmm
- Que tal
Não é necessário, mas não é prejudicial 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 variem apenas por palavras de enchimento.
Nunca defina entidades compostas de pausas discursivas.
Testar as 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, é recomendável ajustar as configurações para melhorar a performance do agente.
Como responder ao usuário final
Esta seção fornece diretrizes para usar o fulfillment para responder ao usuário final.
Dar 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 confirmação que dê boas-vindas ao usuário final. Essa mensagem precisa descrever o agente e dar ao usuário final uma ideia do que ele é capaz.
Confirmar as informações do usuário final
Muitas vezes, é melhor repetir as informações fornecidas pelo usuário final nas respostas. Isso permite que o usuário final saiba que o agente está entendendo a solicitação.
Quando uma intent é correspondida e uma transição ocorre, 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: Ok, o que você quer saber sobre sua conta corrente? |
A entrada do usuário final resultou em uma correspondência de intenção, e uma rota foi seguida, incluindo uma mensagem de cumprimento e uma transição para uma página que lida com perguntas sobre verificação de conta. O agente confirma que o usuário final quer saber sobre a conta corrente dele. |
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: 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 de formulário de data, que foi o último parâmetro de formulário na página ativa. O agente confirmou a hora e a data de um corte de cabelo agendado. |
Orientar a conversa
O agente sempre precisa guiar a conversa com o usuário final. Isso é fácil de fazer, terminando cada resposta com uma pergunta como:
- Posso ajudar com mais alguma coisa?
- O que você quer saber sobre beagles?
- Quer cancelar ou enviar o pedido?
- Como posso ajudar?
- Você está viajando sozinho ou com alguém?
Ao definir essas perguntas, evite fazer várias perguntas, como:
- Você ainda está aqui? Qual serviço você está consultando?
- Você ainda quer este pedido? Quer adicionar algo?
O usuário final pode responder a apenas uma das perguntas, e o agente pode não lidar com essa situação corretamente.
Como lidar com erros e entradas inesperadas do usuário final
Esta seção oferece conselhos sobre como lidar com erros e entradas inesperadas do usuário final.
Criar manipuladores de eventos integrados
Crie manipuladores de eventos para os eventos integrados conforme aplicável. Processar esses eventos é semelhante a capturar exceções na programação de software. Dependendo da situação, você pode processar os eventos com manipuladores de eventos específicos de parâmetro, de página ou de fluxo.
Processar erros de webhook
Quando o serviço de webhook falha, é importante que o agente consiga lidar com a falha. Para isso, defina manipuladores de eventos para os eventos integrados específicos do webhook. Esta é 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 gerenciador 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 em zero. Essa página precisa estar ativa antes da página que aciona uma chamada de webhook. O fulfillment de entrada para essa página precisa inicializar o contador de erros para
0usando uma predefinição de parâmetro de fulfillment. Exemplo:Parâmetro Valor webhook-error-count0Crie uma página de erro de webhook que processe eventos de erro de webhook:
O fulfillment de entrada precisa reconhecer a falha para o 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 com uma condição em 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 vai tentar novamente. Essa rota precisa ter um destino de transição definido como PREVIOUS_PAGE, ou para qualquer página que possa fazer outra tentativa de chamar o webhook.Defina uma rota de condição que tenha uma condição em 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 cumprimento que notifique o usuário final de que o agente não vai tentar novamente. Essa rota precisa ter um destino de transição definido para uma página que não vai acionar novas tentativas de webhook.
O gerenciador 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
Esta seção oferece conselhos sobre o uso de 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 podem ajudar a evitar regressões enquanto seu agente evolui para processar mais cenários.