O QUE FAZER e O QUE NÃO FAZER no Design de Conversa
A criação de um conjunto robusto de intenções para uma habilidade bem-sucedida exige muita atenção. Veja aqui algumas práticas recomendadas para você ter em mente.
Design e Treinamento da Intenção
DO | Não |
---|---|
FAÇA planos para adicionar conexões até você obter os resultados esperados. No sentido geral, os modelos são bem executados à medida que você adiciona mais declarações de treinamento de qualidade. O número de declarações que você precisa depende do modelo, dos dados de treinamento e do nível de precisão considerado realista para o seu modelo. | NÃO FAÇA treinamentos em excesso de intenções individuais. Não adicione dados de treinamento excessivos a algumas intenções para fazer com que elas funcionem "perfeitamente". Se a resolução da intenção não se comportar conforme esperado, avalie a estrutura dela quanto à substituição entre as intenções. A resolução da intenção NUNCA será 100% exata. |
FAÇA uso de dados da vida real. É fundamental o uso da linguagem real que sua habilidade muito provavelmente encontrará. As declarações fabricadas só poderão levar você até aqui; elas não vão preparar sua habilidade para envolvimento real. | NÃO use apenas palavras-chave nos dados de treinamento. Embora seja aceitável usar uma única palavra e frases curtas para treinamento, os dados de treinamento devem ter a mesma estrutura que as entradas do usuário. Quanto menos palavras nas declarações, menos bem-sucedida a classificação será. |
FAÇA uso de sentenças completas para treinar intenções. Embora não haja problemas em usar declarações de treinamento curtas, certifique-se de uma correspondência mais próxima possível com o estilo de conversa dos seus usuários. | NÃO provoque distorções acidentais das intenções. Tenha cuidado com palavras que não adicionam significado específico (por exemplo, "please" e "thanks") ou valores de entidades dentro de declarações, visto que podem inadvertidamente distorcer o significado da resolução da intenção se forem muito usados em uma intenção, mas não em outra. |
FAÇA uso de números semelhantes de declarações por intenção. Algumas intenções (por exemplo, "hello", "goodbye") podem ter menos declarações em seus conjuntos de treinamento. No entanto, certifique-se de que suas principais intenções tenham um número semelhante de declarações para evitar influenciar seu modelo. | NÃO dependa APENAS da resolução da intenção. Use entidades para eliminar ambiguidades das intenções comuns. Se houver substituição linguística entre as intenções, considere usar entidades para eliminar ambiguidades das intenções do usuário (e do correspondente caminho de conversa exclusivo). |
Trate as conversas casuais. Os usuários farão solicitações que não são relevantes para a finalidade da habilidade, como brincadeiras e comentários sobre o clima. Eles também podem perguntar se a habilidade é humana. Certifique-se de ter uma estratégia para conversas casuais e teste exaustivamente a maneira de responder da habilidade em todas as etapas do seu fluxo de conversa. | Não use em excesso unresolvedIntent. Crie intenções “fora do escopo" para coisas que você sabe que não sabe (que você possa ou não permitir que a habilidade faça posteriormente). |
Considere várias intenções para um único caso de uso. Os clientes podem expressar a mesma necessidade de várias formas, por exemplo, em termos de solução que desejam OU sintoma de seus problemas. Use várias intenções que sejam resolvidas todas com a mesma "resposta". | NÃO ignore interações abusivas. Tenha um plano para abusos, da mesma forma que para chat casual. Esse plano pode precisar incluir medidas para garantir que qualquer entrada abusiva do usuário não seja refletida pela habilidade, além de providenciar escalação imediata. |
Experiência de Conversa do Usuário
DO | Não |
---|---|
Dê indicações das respostas mais prováveis (incluindo ajuda e saída). Por exemplo, "Hey, I'm Bob the Bot. Pergunte sobre X, Y ou Z. Se você encontrar algum problema, basta digitar 'help'." | NÃO atrase o design de conversa até "mais adiante no projeto". Para quase todas as habilidades mais simples, o design de conversa deve ter a mesma prioridade e urgência que outro trabalho de desenvolvimento. Deve começar antecipadamente e continuar em paralelo com outras tarefas. |
Considere uma personalidade para seu bot. Considere a personalidade e o tom do seu bot. No entanto, tome cuidado para não exagerar na interação semelhante à humana (humor e simpatia muitas vezes não combinam com um robô) e nunca tente enganar os usuários fazendo-os pensar que eles estão interagindo com um humano. | NÃO diga que a habilidade "ainda está aprendendo". Apesar de ser bem intencionada, essa prática ruim sinaliza ao usuário (de forma consciente ou inconsciente) que a habilidade não está apta para a tarefa. |
Oriente o usuário naquilo que se espera dele. A habilidade deve tentar orientar o usuário para uma resposta apropriada e não deixar as perguntas em aberto. As perguntas em aberto fazem com que o usuário fique mais propenso a sair do caminho feliz. | NÃO use respostas "fofas" ou "irritantes". Consulte "Oriente o usuário naquilo que se espera dele". |
Divida respostas longas em bolhas de chat individuais e/ou use quebras de linha. Bolhas grandes de texto sem quebras visuais são difíceis de ler e podem levar à confusão. | NÃO diga "I’m sorry, I don’t understand. Gostaria de reformular sua pergunta?" Essa abordagem cômoda de tratamento de erros é, mais do que nunca, incorreta. Não importa quantas vezes um usuário reformule uma pergunta fora do escopo, a habilidade NUNCA terá nada inteligente para dizer. |
-- | NÃO FAÇA uso excessivo de frases de "confirmação". Há hora certa para frases de confirmação. No entanto, não abuse delas. Considere os fluxos de caixas de diálogo que podem levar em conta os níveis de confiança antes de pedir confirmação aos usuários. |
Estratégias de Teste
DO | Não |
---|---|
Desenvolva declarações ciclicamente. O desenvolvimento de um corpus de treinamento robusto exige várias repetições e ciclos de teste, além do monitoramento e do ajuste contínuos. Use uma abordagem cíclica "criar, testar, implantar, monitorar, atualizar". | NÃO negligencie a necessidade de um plano de medição e melhora do desempenho. Se faltar um plano para medir e melhorar sua habilidade, você não terá como saber se ela está realmente funcionando. |
FAÇA testes das declarações usando a regra 80/20. Teste sempre a robustez de suas intenções em relação a outra conduzindo vários testes 80/20, em que 80% das declarações recém-coletadas seja usado para treinar o modelo e 20% seja adicionado aos dados dos testes. | NÃO FAÇA testes apenas do caminho feliz. "Colocar em funcionamento" é 20% do trabalho. Os 80% restantes são testes e ajustes de como a habilidade responde a entrada incorreta e ações do usuário. |
FAÇA testes de falha da habilidade. Avalie intensamente a falha da sua habilidade em ver o que acontece. Não dependa exclusivamente de testes positivos. | NÃO ignore o processamento de mensagens fora da ordem. Os usuários rolarão para trás no histórico de conversas e clicarão nos botões anteriores. O teste dos resultados precisa fazer parte do trabalho de 80% (conforme indicado em NÃO FAÇA testes apenas do caminho feliz). |
-- | NÃO se esqueça de testar novamente à medida que atualizar suas intenções. Se você adicionar mais dados de treinamento (por exemplo, conforme seu bot obtém mais usos da vida real) e/ou adicionar novas intenções para novos casos de uso, não se esqueça de testar seu modelo novamente. |
Considerações de Projetos
DO | Não |
---|---|
FAÇA seleções de casos de uso que sejam melhorados pela IU de conversa (CUI). A ativação da IU de conversão (por meio de habilidades e assistentes digitais) funciona. Certifique-se de que o caso de uso será realmente aprimorado pela adição da CUI. | NÃO deixe de ter um caminho de escalação. Mesmo que você não planeje permitir a escalação para um humano, tenha uma estratégia para aquelas interações em que a habilidade não pode ajudar. |
Providencie para que o primeiro dia não seja o pior. Até mesmo habilidades e assistentes digitais mais bem testados exigem ajustes para o primeiro dia. | NÃO desfaça a equipe de desenvolvimento imediatamente após o lançamento. Ao programar seu projeto de habilidade, certifique-se de manter os criadores da habilidade (Designer de Conversa, Gerente de Projeto, Lead de Tecnologia etc.) no projeto por tempo suficiente para ajustes adequados e, por último, para transferência de conhecimento. |