O Oracle Digital Assistant tem suporte para dois tipos de intenções: intenções regulares e intenções de resposta. Ambos os tipos de intenção usam o mesmo modelo NLP, que deve ser definido como Trainer Tm para teste de pré-produção e em produção.

A diferença entre os dois tipos de intenção é que as intenções de resposta estão associadas a uma mensagem predefinida que é exibida sempre que a intenção é resolvida a partir de uma mensagem do usuário, enquanto as intenções regulares, quando resolvidas, levam a uma conversa do bot do usuário definida no fluxo de caixas de diálogo.

Você usa intenções de resposta para que o bot responda à pergunta mais frequente que sempre produz uma única resposta. As intenções regulares são usadas para iniciar uma interação mais longa usuário-bot que leva à conclusão de uma tarefa transacional, consultar um sistema de backend ou fornecer uma resposta a uma pergunta frequente que precisa considerar a dependência externa, como hora, data ou local, ao fornecer uma resposta.

Para tornar o desenvolvimento e a manutenção da habilidade mais eficientes, você deve criar uma convenção de nomenclatura para suas intenções que facilite para você entender imediatamente o que uma intenção específica representa e usar a opção de filtro ao procurar intenções.

Por exemplo, uma parte do nome deve delinear entre intenções de resposta e intenções regulares (e talvez também intenções regulares necessárias para que você possa retornar uma resposta direta, mas com processamento mais complexo, como com um anexo ou com base em uma consulta a um serviço remoto). Com isso em mente, você pode começar com um esquema semelhante ao seguinte:

• Intenções regulares: reg.<name_of_intent>

• Intenções de resposta: ans.<name_of_intent>

• Intenções regulares que são respostas: reg.ans.<name_of_intent>

Se sua habilidade lidar com tarefas relacionadas que podem ser categorizadas, isso também poderá ser usado na nomeação da intenção. Vamos supor que você tenha a intenção de criar prescrições e cancelar prescrições. Usando esses dois casos de uso, a convenção de nomenclatura poderia ser:

• Intenções regulares: create.reg.<name_of_intent>, cancel.reg.<name_of_intent>

• Intenções de resposta: create.ans.<name_of_intent>, cancel.ans.<name_of_intent>

• Intenções regulares que são respostas: create.reg.ans.<name_of_intent>, cancel.reg.ans.<name_of_intent>

Não há uma regra rígida sobre se você usa notação de pontos, sublinhados ou algo próprio. No entanto, mantenha os nomes curtos o suficiente para que não sejam truncados no painel do editor de intenções do Oracle Digital Assistant.

Cada intenção também tem um campo Nome da Conversa. O nome da conversa será usado em caixas de diálogo de desambiguação criadas automaticamente pelo assistente digital ou pela habilidade, se uma mensagem do usuário for resolvida para mais de uma intenção.

Cada intenção tem um campo Descrição no qual você deve descrever brevemente para que outras pessoas que mantêm a habilidade possam entendê-la sem adivinhar.

Um exemplo de intenções de escopo muito restrita é definir uma intenção separada para cada produto que você deseja que seja tratado por uma habilidade. Vamos tomar a extensão de uma apólice de seguro existente como um exemplo. Se você definiu intenções por apólice, a mensagem "Eu quero adicionar minha esposa ao meu seguro de saúde" não é muito diferente de "Eu quero adicionar minha esposa ao meu seguro de automóvel" porque a distinção entre os dois é uma única palavra. Como outro exemplo negativo, imagine se nós, da Oracle, criássemos um assistente digital para nossos clientes solicitarem suporte ao produto e, para cada um de nossos produtos, criássemos uma habilidade separada com as mesmas intenções e declarações de treinamento.

Quando criança, você provavelmente não desenvolveu habilidades separadas para segurar garrafas, pedaços de papel, brinquedos, travesseiros e bolsas. Em vez disso, você simplesmente aprendeu a segurar as coisas. O mesmo princípio se aplica à criação de intenções para um bot.

O escopo de uma intenção será muito amplo se você ainda não conseguir ver o que o usuário deseja depois que a intenção for resolvida. Por exemplo, suponha que você tenha criado uma intenção chamada "handleExpenses" e treinado-a com as declarações a seguir e um bom número de suas variações.

• "Quero criar um novo relatório de despesas"

• "Quero verificar meu relatório de despesas recente"

• "Cancelar meu relatório de despesas recente"

• "Meu relatório recente requer correções"

Com isso, seria necessário um processamento adicional para entender se um relatório de despesas deve ser criado, atualizado, excluído ou pesquisado. Para evitar código complexo no fluxo de caixas de diálogo e reduzir a superfície de erros, não projete intenções muito amplas no escopo.

Lembre-se sempre de que o machine learning é seu amigo e que seu design de modelo deve torná-lo um amigo igualmente bom da IA de conversação no Oracle Digital Assistant.

E há mais funcionalidades fornecidas pelas entidades que fazem valer a pena gastar tempo identificando informações que podem ser coletadas com elas.

Por exemplo, e se um usuário inserir a mensagem "Comprei este item em 12 de junho de 2021 e 2 de julho de 2021" quando for solicitada uma data de compra? Nesse caso, a entidade, se usada com o componente Resposta Comum ou Resolver Entidades, gerará automaticamente uma caixa de diálogo de desambiguação para que o usuário selecione um único valor como entrada de dados. Como na conversa humana em que uma pessoa pediria a outra para desambiguar uma declaração ou ordem, as entidades farão o mesmo por você. E, claro, as entidades também podem ser configuradas para aceitar vários valores se o caso de uso oferecer suporte a ele.

Além disso, ao usar o componente Resposta Comum ou Entidades Resolvidas com entidades personalizadas, os prompts exibidos aos usuários podem ser definidos na entidade de forma que os usuários recebam prompts alternados quando solicitados novamente para entrada de dados com falha anterior. Quando a mensagem de prompt muda entre as chamadas, isso torna seu bot menos robótico e mais conversacional. Além disso, você pode usar prompts alternados para revelar progressivamente mais informações para ajudar os usuários a fornecer uma entrada correta.

Como prática geral, é recomendável usar entidades para executar a validação de entrada do usuário e exibir mensagens de erro de validação, bem como para exibir prompts e caixas de diálogo de desambiguação.

Assim como nas intenções, recomendamos uma convenção de nomenclatura a ser seguida ao criar nomes de entidades. Para começar, se você incluir o tipo de entidade no nome da entidade, isso facilitará a compreensão rápida e fornecerá uma maneira fácil de filtrar uma lista de entidades. Por exemplo, é possível usar o seguinte esquema:

• Entidade da lista de valores: list.<name_of_entity>

• Entidade de expressão regular: reg.<name_of_entity>

• Entidade derivada: der.<name_of_entity> ou der.DATE.<name_of_entity>

• Entidade composta: cbe.<name_of_entity>

• Entidade de aprendizado de máquina: ml.<name_of_entity>

Se você usa notação de ponto como nos exemplos acima, sublinhados ou algo seu depende de você. Além disso, sugerimos que você tente manter os nomes bastante curtos.

Cada entidade tem um campo Description no qual você deve descrever brevemente a finalidade de uma entidade. O campo é limitado no número de caracteres que você pode inserir, portanto, certifique-se de ser conciso.

Ao criar declarações para suas intenções, você usará a maioria das declarações como dados de treinamento para as intenções, mas também deverá reservar algumas declarações para testar o modelo que criou. Uma divisão de dados 80/20 é comum na IA de conversação para a proporção entre as declarações a serem criadas para treinamento e as declarações a serem criadas para teste.

Outra proporção que você pode encontrar ao ler sobre machine learning é uma divisão 70/15/15. Uma divisão 70/15/15 significa que 70% de suas declarações seriam usadas para treinar uma intenção, 15% para testar a intenção durante o desenvolvimento e os outros 15% para serem usados para teste antes de você ir para produção com ela. Uma boa analogia para o treinamento intencional é um exame escolar. O 70% é o que um professor ensina sobre um tópico. Os primeiros 15% são então testes que você faz enquanto estuda. Então, quando se trata de escrever seu exame, você recebe outro conjunto de 15% de testes que você não viu antes.

Embora o 70/15/15 seja atraente, ainda recomendamos o uso de uma divisão 80/20 para treinar intenções do Oracle Digital Assistant. Como você verá mais adiante neste guia, obterá dados adicionais para teste de declarações de teste cruzado no contexto do assistente digital (teste próximo). Portanto, se você seguir as recomendações deste guia, estará coletando dados suficientes para testes para garantir que seus modelos funcionem (mesmo que não acabem sendo uma divisão 70/15/15). E você será capaz de executar repetidamente esses testes para ter uma ideia de melhorias ou regressão ao longo do tempo.

Não há lixo, diamantes quando se trata de IA conversacional. A qualidade dos dados com os quais você treina seu modelo tem um impacto direto no entendimento do bot e em sua capacidade de extrair informações.

O objetivo de definir declarações é criar um conjunto imparcial e equilibrado de dados de treinamento e teste que não desorganize o modelo de intenção. A fim de fazê-lo, aqui estão algumas regras para você seguir que, em nossa experiência, dar bons resultados

• Não use ferramentas de geração para criar declarações. É provável que você obtenha muitas declarações com pouca variação.

• Considere diferentes abordagens para acionar uma intenção, como "Quero redefinir minha senha" vs. "Não consigo fazer login no meu email".

• Não use declarações que consistam em palavras únicas, pois elas não têm o contexto a partir do qual o modelo de máquina pode aprender.

• Evite palavras como "por favor", "obrigado", etc. que não contribuam muito para o significado semântico das declarações.

• Use um conjunto representativo de valores de entidade, mas não todos.

• Varie o posicionamento da entidade. Você pode colocar a entidade no início, no meio e no final da declaração.

• Mantenha o número de declarações balanceadas entre intenções (por exemplo, evite 300 para uma intenção e 15 para outra).

• Esforce-se para frases semanticamente e sintaticamente completas.

• Use grafias corretas. Somente por exceção você adicionaria alguns erros ortográficos e erros de digitação nas declarações. O modelo geralmente é capaz de lidar com erros ortográficos e erros de digitação por conta própria.

• Adicione variações específicas do país (por exemplo, lixeira vs. lata de lixo, fralda vs. fralda).

• Varie a estrutura da frase (por exemplo, "Eu quero pedir uma pizza", "Eu quero uma pizza, posso pedir").

• Mude o pronome pessoal (por exemplo, eu, nós somos, nós somos, eu faria, eu faria, nós, você, seu, nós).

• Use termos diferentes para o verbo (por exemplo, ordem, obter, perguntar, querer, gostar, querer).

• Use termos diferentes para o substantivo (por exemplo, pizza, calzone, havaiano).

• Crie declarações de tamanhos variados (frases curtas, médias e longas).

• Considere a pluralização (por exemplo, "Quero pedir pizzas", "Posso pedir algumas pizzas").

• Considere o uso de diferentes formas verbais e gerúndios ("A pesca é permitida", "Eu quero pescar, posso fazer isso").

• Use a pontuação em alguns casos e omita-a em outros.

• Use termos representativos (por exemplo, evite muitos termos técnicos se o software for usado pelos consumidores).

As declarações não devem ser definidas da mesma forma que você escreveria argumentos de linha de comando ou listaria palavras-chave. Certifique-se de que todas as declarações que você definir tenham a noção de "conversa" com elas. A criação de declarações que só têm palavras-chave listadas não tem contexto ou é muito curta para o modelo de aprendizado de máquina aprender.

Idealmente, boas declarações são selecionadas a partir de dados reais. Se você não tiver logs de conversa existentes para começar, considere as declarações de crowdsourcing, em vez de apenas sintetizá-las. Sintetizá-los deve ser o seu último recurso.

Para declarações de origem coletiva, envie por email as pessoas que você conhece que representam ou sabem como representar o público-alvo do seu bot. Além disso, você pode usar o recurso Data Manufacturing do Oracle Digital Assistant para configurar um processo automatizado para coletar (crowdsourcing) sugestões de declarações, que você provavelmente desejará selecionar para que elas cumpram as regras que descrevemos para o que faz uma boa declaração.

Observe que você pode achar que as pessoas que você pede declarações de amostra se sentem desafiadas a apresentar exemplos excepcionalmente bons, o que pode levar a casos de nicho irrealistas ou a um uso excessivamente artístico da linguagem que exige que você faça a curadoria das frases.

Além disso, lembre-se de que a curadoria de declarações de amostra também envolve a criação de várias variações de amostras individuais que você colheu por meio de crowdsourcing.

A qualidade das declarações é mais importante do que a quantidade. Algumas boas declarações são melhores do que muitas recomendações utterances.Our mal projetadas: começar com 20 a 30 boas declarações por intenção em desenvolvimento e, eventualmente, aumentar esse número para 80 a 100 para testes sérios de suas intenções. Com o tempo e à medida que o bot for testado com usuários reais, você coletará declarações adicionais que serão selecionadas e usadas para treinar o modelo de intenção.

Dependendo da importância e do caso de uso de uma intenção, você pode acabar com números diferentes de declarações definidas por intenção, variando de cem a várias centenas (e, raramente, até milhares). No entanto, como mencionado anteriormente, a diferença nas declarações por intenção não deve ser extrema.

Um modelo de machine learning avalia uma mensagem do usuário e retorna uma pontuação de confiança para o que ele acha que é o rótulo de nível superior (intenção) e os atletas. Na IA de conversação, o rótulo de nível superior é resolvido como a intenção de iniciar uma conversa.

Assim, com base no treinamento do modelo e na mensagem do usuário, imagine um caso em que o modelo tenha 80% de confiança de que a Intenção A é uma boa correspondência, 60% de confiança para a Intenção B e 45% para a Intenção C. Nesse caso, você provavelmente ficaria bastante confortável de que o usuário deseja a Intenção A.

Mas e se o rótulo de pontuação mais alta tiver apenas 30% de confiança de que é isso que o usuário quer? Você arriscaria o modelo a seguir essa intenção ou preferiria reproduzi-lo com segurança e assumir que o modelo não pode prever o que um usuário gostaria e exibir uma mensagem para o usuário reformular uma solicitação?

Para ajudar o modelo de intenção a tomar uma decisão sobre quais intenções considerar a correspondência com uma declaração do usuário, a IA de conversação usa uma definição chamada limite de confiança. O modelo de intenção avalia uma declaração do usuário em relação a todas as intenções e designa pontuações de confiança para cada intenção. O limite de confiança é um valor dentro do intervalo de possíveis pontuações de confiança que marca a linha:

• abaixo do qual se considera que uma intenção não corresponde de modo algum à declaração; e,

• acima do qual uma intenção é considerada uma intenção candidata para iniciar uma conversa.

No Oracle Digital Assistant, o limite de confiança é definido para uma habilidade nas definições da habilidade e tem um valor padrão de 0.7.

Uma definição de 0.7 é um bom valor para começar e testar o modelo de intenção treinado. Se os testes mostrarem que a intenção correta para mensagens do usuário é resolvida bem acima de 0,7, então você tem um modelo bem treinado.

Se você obtiver bons resultados com uma configuração de 0,7, tente 0,8. Quanto maior a confiança, maior a probabilidade de você remover o ruído do modelo de intenção, o que significa que o modelo não responderá a palavras em uma mensagem do usuário que não sejam relevantes para a resolução do caso de uso.

No entanto, quanto maior o limite de confiança, maior a probabilidade de que o entendimento geral diminua (o que significa que muitas declarações viáveis podem não corresponder), o que não é o que você deseja. Em outras palavras, 100% de "compreensão" (ou 1,0 como nível de confiança) pode não ser um objetivo realista.

Lembre-se de que a IA conversacional é sobre entender o que um usuário quer, mesmo que ele possa expressar isso de muitas maneiras diferentes. Por exemplo, em um caso de bot de pizza, os usuários devem ser capazes de pedir pizza com frases tão diversas como "Eu quero pedir uma pizza" e "Estou com fome".