I. Introdução
De um modo geral, os robôs podem conversar com as pessoas. A coisa mais difícil para um robô dizer é escrever algumas regras e modelos manualmente para responder. Mas é realmente muito difícil para os robôs entenderem as intenções humanas. Por causa da diversidade de linguagem, palavras polissêmicas, trocadilhos, frases longas e curtas, etc., especialmente a profundidade do chinês. Portanto, o robô precisa de muitos dados, ou seja, simular o método de questionamento do humano, para que o robô possa entender as características dessas intenções, entender o método de questionamento do humano e como o humano responde às perguntas de outras pessoas perguntas. Esta parte do conteúdo é chamada de dados de treinamento em Rasa.
O Rasa usa o formato YAML como uma forma unificada e extensível de gerenciar todos os dados de treinamento, incluindo dados NLU, dados de histórias e regras. Os dados de treinamento podem ser divididos em qualquer número de arquivos YAML, cada um dos quais pode conter qualquer combinação de dados NLU, histórias e regras. O analisador de dados de treinamento usa a chave superior para determinar o tipo de dados de treinamento.
Os desenvolvedores ainda procuram o formato de dados Markdown? Ele foi removido no Rasa 3.0, mas a documentação para dados NLU de remarcação e histórias de remarcação ainda pode ser encontrada. Se você ainda tiver dados de treinamento no formato Markdown, o método recomendado é usar o Rasa 2.x para converter seus dados de Markdown em YAML. O guia de migração explica como fazer isso.
1.1 Estrutura de alto nível
Cada arquivo pode conter uma ou mais chaves e dados de treinamento correspondentes . Um arquivo pode conter várias chaves, mas cada chave só pode aparecer uma vez em um único arquivo . As chaves disponíveis incluem:
versão
nlu
histórias
regras
Os desenvolvedores devem especificar a chave da versão em todos os arquivos de dados de treinamento YAML. Se o desenvolvedor não especificar uma chave de versão no arquivo de dados de treinamento, o Rasa assumirá que o desenvolvedor está usando o formato de dados de treinamento mais recente compatível com a versão Rasa instalada. Arquivos de dados de treinamento com uma versão do Rasa superior à versão instalada na máquina do desenvolvedor serão ignorados. Atualmente, a especificação de formato de dados de treinamento mais recente para Rasa 3.x é 3.1.
1.2 exemplo
Aqui está um exemplo para ilustrar, nlu, stroies e regras de dados são todos exibidos em um arquivo:
versão: "3.1"
nlu:
- intent: cumprimentar
exemplos: |
- Oi
- Oi
- oi aí [Sara](nome)
- intenção: perguntas frequentes/
exemplos de idioma: |
- Qual língua você fala?
- Você só lida com inglês?
histórias:
- história: cumprimentar e perguntas frequentes
etapas:
- intenção: cumprimentar
- ação: total_greet
- intenção: faq
- ação: total_faq
regras:
- regra: Cumprimentar
as etapas do usuário:
- intenção: cumprimentar
- ação: total_greet
Para testar histórias específicas, coloque-as em um arquivo separado e prefixe-as com test_:
histórias:
- história: cumprimentar e perguntar linguagem
- passos:
- usuário: |
hey
intenção: cumprimentar
- ação: total_greet
- usuário: |
que idioma você fala
intenção: faq/idioma
- ação: absolute_faq
2. Dados de treinamento NLU
Os dados de treinamento NLU consistem em conversas de usuário de exemplo categorizadas por intenção. Os dados de treinamento NLU também incluem entidades, que podem extrair informações estruturadas das mensagens do usuário. Você também pode adicionar informações adicionais aos dados de treinamento, como expressões regulares e tabelas de pesquisa, para ajudar o modelo a identificar corretamente intenções e entidades. Os dados de treinamento NLU são definidos na chave NLU. Coisas que podem ser adicionadas neste item incluem:
Exemplos de treinamento agrupados por intenção do usuário
Por exemplo, uma entidade com um rótulo, mas as informações do rótulo são opcionais.
nlu:
- intent: check_balance
exemplos: |
- Qual é o meu saldo de [crédito](conta)?
- Qual é o saldo da minha [conta de cartão de crédito]{"entity":"account","value":"credit"}
sinônimos
nlu:
- sinônimo:
exemplos de crédito: |
- conta de cartão de crédito
- conta de crédito
expressão regular
nlu:
- regex: account_number
exemplos: |
- \d{10,12}
tabela de verificação
nlu:
- lookup:
exemplos de bancos: |
- JPMC
- Comerica
- Bank of America
2.1 Exemplos de treinamento (amostras de dados de treinamento)
Os exemplos de treinamento são agrupados por intenção e listados no campo exemplos. Normalmente, os desenvolvedores listarão um exemplo por linha, assim:
nlu:
- intent: cumprimentar
exemplos: |
- oi
- oi
- tudo bem
No entanto, se o desenvolvedor tiver um componente NLU personalizado e precisar de metadados para as amostras, o formato estendido também poderá ser usado:
nlu:
- intenção: cumprimentar
exemplos:
- texto: |
oi
metadados:
sentimento: neutro
- texto: |
ei!
O campo de metadados pode conter dados de valor-chave arbitrários associados a uma instância e acessíveis por componentes em NLU. No exemplo acima, os metadados de sentimento podem ser usados para análise de sentimento por um componente personalizado no pipeline.
Os desenvolvedores também podem especificar esses metadados no nível de intenção:
nlu:
- intenção: saudar
metadados:
sentimento: neutro
exemplos:
- texto: |
oi
- texto: |
ei!
Nesse caso, o conteúdo contido no campo de metadados será aplicado a cada instância de intenção.
Se o desenvolvedor precisar especificar a intenção de recuperação, seu exemplo de NLU pode ser assim:
nlu:
- intent: chitchat/ask_name
exemplos: |
- Qual o seu nome?
- Posso saber o seu nome?
- Como as pessoas te chamam?
- Você tem um nome para si mesmo?
- intenção: chitchat/ask_weather
exemplos: |
- Como está o tempo hoje?
- Está ensolarado lá fora hoje?
- Oh, você se importa de verificar o tempo para mim, por favor?
- Eu gosto de dias ensolarados em Berlim.
Todas as intenções de recuperação têm um sufixo adicionado para identificar o campo de resposta específico do bot. No exemplo acima, ask_name e ask_weather são sufixos. O sufixo e o nome da intenção são separados por um separador /.
2.2 Entidades
As entidades são informações estruturadas que podem ser extraídas das mensagens do usuário e são rotuladas com nomes de entidades nos dados de treinamento. Além dos nomes das entidades, os desenvolvedores podem rotular entidades com sinônimos, funções ou grupos.
Nos dados de treinamento, exemplos de entidades rotuladas são os seguintes:
nlu:
- intent: check_balance
exemplos: |
- quanto tenho na minha conta [poupança](conta)
- quanto dinheiro tem na minha conta [corrente]{"entity": "account"}
- Qual é o saldo da minha [conta de cartão de crédito]{"entity" :"conta","valor":"crédito"}
A sintaxe completa para rotular entidades é a seguinte:
[<entity-text>]{"entity": "<nome da entidade>", "role": "<nome da função>", "group": "<nome do grupo>", "value": "<sinônimo da entidade> "}
As palavras-chave role, group e value são opcionais durante a anotação. O conteúdo do campo de valor pode se referir a sinônimos. Se você quiser entender o conteúdo dos campos de função e grupo, consulte as funções e grupos da entidade.
2.3 Sinônimos (sinônimos)
Sinônimos mapeiam entidades extraídas para valores fora do texto extraído. Os desenvolvedores podem definir sinônimos usando os seguintes formatos:
nlu:
- sinônimo:
exemplos de crédito: |
- conta de cartão de crédito
- conta de crédito
Os desenvolvedores também podem definir sinônimos diretamente nos dados de treinamento e definir sinônimos especificando o campo de valor:
nlu:
- intent: check_balance
exemplos: |
- quanto tenho na minha [conta de cartão de crédito]{"entidade": "conta", "valor": "crédito"} - quanto devo
na minha [conta de crédito]{"entidade": "conta" , "valor": "crédito"}
Se você precisa saber mais sobre sinônimos, você pode ir aqui na página NLU Training Data.
2.4 Regular Expressions (expressões regulares)
Os desenvolvedores podem usar expressões regulares para melhorar o efeito da classificação de intenção e extração de entidade. As expressões regulares usam principalmente os módulos RegexFeaturizer e RegexEntityExtractor.
O formato para definir uma expressão regular é o seguinte:
nlu:
- regex: account_number
exemplos: |
- \d{10,12}
- intent: informe
exemplos: |
- o número da minha conta é [1234567891](account_number)
- Este é o número da minha conta [1234567891](account_number)
account_number é o nome da expressão regular. Quando usado como um recurso RegexFeaturizer, o nome da expressão regular não importa. Ao usar RegexEntityExtractor, o nome da expressão regular deve corresponder ao nome da entidade a ser extraída pelo Bot.
Se você precisa saber mais sobre expressões regulares, você pode ir aqui na página NLU Training Data.
2.5 Lookup Tables (tabela de consulta)
Uma tabela de pesquisa é usada para gerar uma lista de expressões regulares que não diferencia maiúsculas de minúsculas. Eles podem ser usados da mesma forma que as expressões regulares, em combinação com os componentes regexfeatureizer e RegexEntityExtractor no pipeline. Uma tabela de pesquisa pode ser usada para ajudar a extrair entidades com um conjunto conhecido de valores possíveis. Mantenha a tabela de pesquisa do desenvolvedor o mais específica possível. Por exemplo, para extrair nomes de países, você pode adicionar uma tabela de pesquisa de todos os países do mundo. Na verdade, este lugar é a função de adicionar dicionário de sinônimos.
nlu:
- lookup:
exemplos de bancos: |
- JPMC
- Comerica
- Bank of America
3. Dados de treinamento de conversação
Tanto as histórias quanto as regras representam o fluxo de diálogo entre o usuário e o assistente de diálogo e são usadas principalmente para treinar o modelo de gerenciamento de diálogo. As histórias são usadas para treinar modelos de aprendizado de máquina para reconhecer padrões em conversas e generalizar para caminhos de conversa invisíveis. rules descreve o princípio de que o bot precisa sempre seguir o mesmo caminho e a estratégia de regra de treinamento RulePolicy.
3.1 Histórias
As histórias geralmente consistem nas seguintes partes:
história: O nome da história. O nome é arbitrário e não é usado para treinamento; os desenvolvedores podem usá-lo como uma referência legível para a história para estatísticas e ilustrações.
metadados: arbitrários e opcionais, não usados para treinamento, você pode usar isso para armazenar informações relevantes sobre a história, como o autor.
A lista de etapas: Mensagens e ações do usuário que compõem a história.
Uma amostra é a seguinte:
histórias:
- história: Cumprimente os
metadados do usuário:
autor:
Chave de alguém: valor
etapas:
# lista de etapas
- intenção: saudação
- ação: total_greet
Cada etapa pode ser uma das seguintes:
As mensagens do usuário são compostas principalmente por intenções e entidades.
instrução sob a qual duas ou mais mensagens do usuário estão contidas.
ação do robô.
forma.
Eventos de slot.
ponto de verificação, que conecta uma história a outra história.
Mensagens do usuário
Todas as mensagens do usuário podem ser especificadas com o campo de intenção e o campo de entidades, este campo é opcional.
Ao escrever histórias, os desenvolvedores não precisam lidar com as especificidades das mensagens que os usuários enviam. Em vez disso, os desenvolvedores podem aproveitar a saída do pipeline NLU, que usa uma combinação de intenções e entidades para se referir a todas as mensagens possíveis que um usuário pode enviar com o mesmo significado.
As mensagens do usuário seguem o seguinte formato:
histórias:
- história:
etapas da estrutura da mensagem do usuário:
- intenção: intent_name #
Entidades necessárias: # Opcional
- entity_name: entity_value
- ação: action_name
No exemplo "Quero verificar meu saldo de crédito", "crédito" é uma entidade. As entidades incluídas nos dados de treinamento também são importantes, pois a política aprende a prever a próxima ação com base na combinação de intents e entidades (no entanto, os desenvolvedores também podem alterar esse comportamento usando o atributo use_entities).
Ações
Todas as ações executadas pelo Bot são especificadas usando o campo de ação, seguido do nome da ação. Ao escrever uma história, geralmente existem dois tipos de ações:
1. Resposta. Comece com "utter_" e retorne mensagens específicas. Por exemplo:
histórias:
- história: história com
etapas de resposta:
- intenção: cumprimentar
- ação: total_greet
2. Personalize as ações. Iniciado com "action_", executa código arbitrário e envia qualquer número de mensagens (ou nenhuma). Por exemplo:
histórias:
- história: história com
etapas de ação personalizadas:
- intenção: feedback
- ação: action_store_feedback
Formulários
Os formulários são um tipo específico de ação personalizada que contém a lógica para percorrer um conjunto de slots necessários e solicitar essas informações ao usuário. O desenvolvedor define um formulário no Domínio. Uma vez definidos os Formulários, o desenvolvedor deve especificar o caminho do formulário como regra. Os desenvolvedores devem incluir quebras na forma ou outros "caminhos indeterminados" nas histórias para que os modelos possam prever sequências de diálogo não vistas. Um formulário, como uma etapa de uma ação, geralmente assume o seguinte formato:
stories:
- story: story with a form
steps:
- intent: find_restaurant
- action: restaurant_form # Ative o formulário
- active_loop: restaurant_form # Este formulário está ativo no momento
- active_loop: null # Formulário completo, nenhum formulário está ativo
- action: total_restaurant_found
A etapa de ação ativa o formulário e começa a percorrer os slots necessários. active_loop: A etapa restaurant_form indica que existe atualmente um formulário de ação. Muito parecido com a etapa slot_was_set, a etapa de formulário não define o formulário como ativo, mas indica que ele já deve estar ativo. Da mesma forma, uma etapa active_loop: null indica que nenhum formulário deve estar ativo até que as etapas subsequentes sejam executadas.
Um formulário pode ser interrompido e permanecer ativo, neste caso, a interrupção deve ocorrer após o passo action: <formulário a ativar>, seguido do passo active_loop: <formulário ativo>. Uma quebra de tabela pode ter esta aparência:
histórias:
- história: etapas de alimentação interrompidas
:
- intenção: request_restaurant
- ação: restaurant_form
- intenção: chitchat
- ação: total_chitchat
- active_loop: restaurant_form
- active_loop: nulo
- ação: total_slots_values
slots
Os eventos de slot são especificados no campo slot_was_set: com um nome de slot e um valor de slot opcional. Os slots atuam como a memória do robô, definidos pelo campo action_extract_slots padrão ou por uma ação personalizada, de acordo com o mapeamento de slot especificado no domínio. Eles são referenciados por histórias na etapa slot_was_set. Por exemplo:
histórias:
- história: história com um slot
etapas:
- intenção: comemorar_bot
- slot_was_set:
- feedback_value: positivo
- ação: total_yay
Isso significa que as histórias exigem que o valor atual de feedback_value seja positivo para que a conversa prossiga conforme especificado.
Se um valor para um slot precisa ser incluído depende do tipo de slot e se o valor pode ou deve afetar o diálogo. Se o valor não importa, como um slot de texto, você pode apenas listar o nome do slot:
stories:
- story: story with a slot
steps:
- intent: greet
- slot_was_set:
- name
- action: total_greet_user_by_name
pontos de verificação
Os pontos de verificação são especificados pelo campo de ponto de verificação, no início ou no final da história.
Os pontos de verificação são como você conecta as histórias. Eles podem ser o primeiro ou o último passo de uma história. Se forem os últimos passos de uma história, ao treinar o modelo, essa história será associada a outras histórias que começam com pontos de controle de mesmo nome. Aqui está um exemplo de uma história que termina com um ponto de verificação e um exemplo de uma história que começa com o mesmo ponto de verificação:
histórias:
- história: story_with_a_checkpoint_1
passos:
- intenção: cumprimentar
- ação: total_greet
- ponto de verificação: greet_checkpoint
- história: story_with_a_checkpoint_2
etapas:
- ponto de verificação: greet_checkpoint
- intenção: book_flight
- ação: action_book_flight
Você também pode definir condições para slots se o ponto de verificação for definido no início da história, por exemplo:
stories:
- story: story_with_a_conditional_checkpoint
steps:
- checkpoint: greet_checkpoint
# Este ponto de verificação só deve ser aplicado se os slots forem definidos com o valor especificado
slot_was_set:
- context_scenario: feriado
- holiday_name: ação de graças
- intenção: saudação
- ação: total_greet_thanksgiving
Os pontos de verificação podem ajudar a simplificar e reduzir a redundância em seus dados de treinamento em desenvolvimento, mas não os abuse. O uso de muitos pontos de verificação pode dificultar o acompanhamento da história. Faz sentido usá-los se uma série de etapas for repetida com frequência em histórias diferentes, mas histórias sem pontos de verificação são mais fáceis de ler e escrever.
3.2 Regras
As regras geralmente são definidas no campo de regras, que se parece com as histórias. As regras também têm um campo de etapas que contém a mesma lista de etapas das histórias. As regras também podem conter campos conversation_started e conditions. Estes são usados para especificar as condições sob as quais a regra se aplica.
Uma regra com uma condição se parece com isto:
regras:
- regra: Diga `hey` apenas quando o usuário fornecer um nome
condição:
- slot_was_set:
- user_provided_name: true
steps:
- intent: cumprimentar
- ação: total_greet
Se você precisa saber mais sobre as regras, pode ir aqui Regras
4. Histórias de teste (test stories)
As histórias de teste verificam se as mensagens do usuário são classificadas corretamente e as previsões de ação. As histórias de teste usam o mesmo formato das histórias, exceto que a etapa da mensagem do usuário pode incluir o texto real e as entidades de anotação da mensagem do usuário especificada pelo usuário. Aqui está um exemplo de uma história de teste
histórias:
- história: Uma
etapa básica de teste de ponta a ponta:
- usuário: |
hey
intenção: cumprimentar
- ação: total_ask_howcanhelp
- usuário: |
mostre-me [chinês]{"entidade": "cozinha"} restaurantes
intenção: informar
- ação: total_ask_location
- usuário: |
em [Paris]{"entity": "location"}
intenção: informar
- ação: total_ask_price
Os desenvolvedores podem testar executando o seguinte comando:
teste de sabor
Se você precisa saber mais sobre o teste, pode ir aquiTestar seu assistente.
Cinco, Treinamento de ponta a ponta (treinamento de ponta a ponta)
Por meio de treinamento de ponta a ponta, os desenvolvedores devem lidar com a intenção específica extraída pelo pipeline NLU. Em vez disso, os desenvolvedores podem usar o campo do usuário para colocar o texto da mensagem do usuário diretamente na história.
Essas mensagens de usuário de ponta a ponta seguem o seguinte formato:
stories:
- story:
etapas da estrutura da mensagem do usuário:
- user: o texto real da mensagem do usuário
- action: action_name
Além disso, os desenvolvedores podem adicionar tags de entidade que podem ser extraídas pela Política TED. A sintaxe para rótulos de entidade é a mesma dos dados de treinamento NLU. Por exemplo, a história a seguir contém o enunciado do usuário Eu sempre posso comer sushi. Usando a gramática nos dados de treinamento NLU [sushi](cozinha), os desenvolvedores podem marcar o sushi como entidades do tipo cozinha.
histórias:
- história: história com
etapas de entidades:
- usuário: eu sempre posso ir para [sushi](cozinha)
- ação: total_suggest_cuisine
Da mesma forma, os desenvolvedores podem colocar as declarações do bot diretamente nas histórias usando o campo bot seguido do texto que o desenvolvedor deseja que o bot fale.
Uma história com apenas o campo bot pode ser assim:
histórias: - história: história com etapas
de resposta de ponta a ponta : - intenção: cumprimentar entidades: - nome: Ivan - bot: Olá, uma pessoa com um nome!
Os desenvolvedores também podem ter uma história híbrida de ponta a ponta:
histórias: - história: etapas
completas da história de ponta a ponta : - intenção: cumprimentar entidades: - nome: Ivan - bot: Olá, uma pessoa com um nome! - intent: search_restaurant - action: absolute_suggest_cuisine - user: sempre posso ir para [sushi](cuisine) - bot: Pessoalmente, prefiro pizza, mas com certeza vamos procurar restaurantes de sushi - action: absolute_suggest_cuisine - user: Tenha um lindo dia! - ação: adeus absoluto
O treinamento ponta a ponta do Rasa é totalmente integrado aos métodos Rasa padrão. Isso significa que os desenvolvedores podem misturar histórias em que algumas etapas são definidas por ações ou intenções, enquanto outras são definidas diretamente por mensagens do usuário ou respostas do bot.
6. Referências
Formato de dados de treinamento
Introdução ao Rasa Open Source e Rasa Pro
(13) Dados de treinamento RASA