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 guia para usar o serviço de Agentes de conversa (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 seu agente evolui, use o recurso de casos de teste para desenvolvimento orientado a testes.
Agentes pré-criados
O Dialogflow CX oferece modelos de agentes 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 agentes de conversação (Dialogflow CX). Nesta seção, apresentamos as práticas recomendadas para escolher o modo de 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 você pode incorporar ao seu site, conectar-se com outras plataformas de mensagens, ou fornecer uma interface de telefonia.
API de agentes de conversação (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ê 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 Conversational Agents (Dialogflow CX).
Recursos do agente
Os recursos de agentes 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
Fluxos e páginas fornecer estrutura ao 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 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 agentes complexos quase sempre são projetados melhor 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, é 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 os tópicos relacionados em um único fluxo. Por exemplo: você pode combinar os seguintes tópicos em uma única página "Ver saldo" fluxo:
- 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, 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 você tem 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:
- 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 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, é 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 é ideal usar parâmetros de formulário e de intent. 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 pedido de camisas pode solicitar mais informações, 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 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 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 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 jeito nenhum
- Agora não
Essas intents de confirmação reutilizáveis podem ser usadas em vários cenários para seu agente.
Em alguns casos,
considere 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:
- 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 esse 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 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 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 de entrada de página:
é chamado quando a página se torna ativa inicialmente.
Ele é útil quando você quer uma mensagem que descreva a finalidade da página,
e isso 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 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 de intent,
a condição satisfeita (que pode ser uma
condição de conclusão do 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)
- Vamos falar sobre os tatus-canguru. (transição)
- Gerenciadores de eventos:
esse fulfillment é chamado quando um evento é invocado.
É ú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)
- 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 de formulário tem o próprio fulfillment inicial.
Por exemplo:
- De que tamanho 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.
Esse fulfillment 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ê pode informar uma cor válida para a camisa?
Nomenclatura
Nesta seção, fornecemos conselhos sobre como 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
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, 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 entradas 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.
Defina pelo menos 20 frases de treinamento
Você deve 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, especialmente para intents de cabeça de grandes agentes, sendo 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 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 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. 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 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, é 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 nas 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 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 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 o modelo de NLU que seu agente está usando.
NLU 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
- Transforme as entradas do usuário final em letras minúsculas antes de enviá-las para agentes de conversação (Dialogflow CX).
NLU avançado
Ao contrário do modelo NLU padrão, o modelo NLU avançado diferencia maiúsculas de minúsculas. Qa recomendamos testar e adicionar os dados relevantes de treinamento em maiúsculas para aumentar com base nas 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 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 NLU avançado é sensível a maiúsculas e requer mais frases de treinamento para aumentar as correspondências de intenção. 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, "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 | 7a partida de setembro |
Partida 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 | Idade de uma pessoa |
O contrato é válido por sete 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 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 um comportamento indesejado.
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.
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 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 camiseta |
Pedir um novo chapéu | Pedir uma nova camiseta |
Adicionar um relógio ao meu 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 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, 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 o seguinte:
Tipo de entidade de ações | Tipo de entidade de 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 detectar as ações/entidades e os planos.
Usar entidades regexp para capturar identificadores nã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", usar 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 seu agente na produção, é inevitável que algumas entradas do usuário final resultem eventos sem correspondência. Você pode usar essas oportunidades para melhorar seu agente de 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 podem impedir a correspondência da 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 desnecessárias
As palavras de enchimento são palavras que você pode ignorar e ainda entender o texto. Exemplo:
- por favor
- você pode, por favor?
- hmmm
- Que tal
É 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.
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, 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.
Dar 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. 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 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 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 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 de um corte de cabelo agendado. |
Oriente a conversa
O agente deve sempre orientar 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 os beagles?
- Quer cancelar ou enviar esse 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? 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 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. 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. Esta é 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 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
0
usando uma predefinição de 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 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 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.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 mais 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 leve à 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
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.