Teste para DevOps do LUIS

  • Artigo

Importante

O LUIS será desativado em 1º de outubro de 2025 e, a partir de 1º de abril de 2023, você não poderá criar novos recursos do LUIS. É recomendável migrar seus aplicativos LUIS para a compreensão da linguagem coloquial a fim de usufruir do suporte contínuo ao produto e dos recursos multilíngues.

Os engenheiros de software que estão desenvolvendo um aplicativo de LUIS (Reconhecimento vocal) podem aplicar práticas de DevOps sobre o controle do código-fonte, compilações automatizadas, testes e gerenciamento de versão seguindo estas diretrizes.

Em metodologias de desenvolvimento de software Agile, os testes desempenham uma função integral na criação de software de qualidade. Cada alteração significativa em um aplicativo de LUIS deve ser acompanhada por testes criados para verificar a nova funcionalidade que o desenvolvedor está criando no aplicativo. Esses testes são verificados em seu repositório de código-fonte junto com a origem .lu do seu aplicativo de LUIS. A implementação da alteração é concluída quando o aplicativo atende aos testes.

Os testes são uma parte crítica dos fluxos de trabalho de CI/CD. Quando as alterações em um aplicativo de LUIS são propostas em uma PR (Solicitação de pull) ou depois que as alterações são mescladas em sua ramificação principal, os fluxos de trabalho de CI devem executar os testes para verificar se as atualizações não causaram nenhuma regressão.

Como fazer testes de unidade e testes em lote

Há dois tipos diferentes de teste para um aplicativo de LUIS que você precisa executar em fluxos de trabalho de integração contínua:

  • Testes de unidade: testes relativamente simples que verificam a funcionalidade principal do seu aplicativo de LUIS. Um teste de unidade tem aprovação quando a intenção esperada e as entidades esperadas são retornadas para um determinado enunciado de teste. Todos os testes de unidade devem passar pela execução de teste para serem concluídos com êxito.
    Esse tipo de teste é semelhante ao Teste Interativo que você pode fazer no portal do LUIS.

  • Testes em lote: o teste em lote é um teste abrangente em seu modelo treinado atual para medir o desempenho dele. Diferentemente dos testes de unidade, os testes em lote não são aprovados|reprovados. A expectativa com o teste em lote não é que cada teste retorne a intenção e as entidades esperadas. Em vez disso, um teste em lote ajuda você a ver a precisão de cada intenção e cada entidade em seu aplicativo e a fazer comparações ao longo do tempo à medida que você faz aprimoramentos.
    Esse tipo de teste é igual ao teste em lote que você pode executar interativamente no portal do Luis.

Você pode aplicar testes de unidade desde o início do projeto. O teste em lote só tem valor quando você tiver desenvolvido o esquema do seu aplicativo de LUIS e estiver trabalhando para melhorar sua precisão.

Tanto nos testes de unidade quanto nos testes em lote, verifique se seus enunciados de teste estão mantidos separados dos seus enunciados de treinamento. Se você testar os mesmos dados nos quais treina, terá a falsa impressão de que seu aplicativo está com um bom desempenho quando ele está apenas se sobreajustando aos dados de teste. Os testes não devem ser vistos pelo modelo para testar o quão bem ele está generalizando.

Escrever testes

Quando você escreve um conjunto de testes, para cada teste, precisa definir:

  • Enunciado do teste
  • Intenção esperada
  • Entidades esperadas.

Use a sintaxe do arquivo em lotes de LUIS para definir um grupo de testes em um arquivo formatado em JSON. Por exemplo:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

Algumas ferramentas de teste, como NLU.DevOps também dão suporte a arquivos de teste formatados em LUDown.

Desenvolver testes de unidade

Os testes de unidade devem ser desenvolvidos para testar a funcionalidade principal do seu aplicativo de LUIS. Em cada iteração (ou sprint) do desenvolvimento do seu aplicativo, você deve escrever um número suficiente de testes para verificar se a funcionalidade principal que você está implementando nessa iteração está funcionando corretamente.

Em cada teste de unidade, para um determinado enunciado de teste, você pode:

  • Testar se a intenção correta é retornada
  • Teste se as entidades principais, aquelas que são essenciais para sua solução estão sendo retornadas.
  • Teste se a pontuação de previsão para intenção e entidades excede um limite definido. Por exemplo, você pode decidir que só considerará que um teste foi aprovado se a pontuação de previsão para a intenção e para as entidades principais exceder 0,75.

Em testes de unidade, é uma boa ideia testar se as entidades principais foram retornadas na resposta de previsão, mas ignorar quaisquer falsos positivos. Falsos positivos são entidades que são encontradas na resposta de previsão, mas que não são definidas nos resultados esperados para o seu teste. Ignorar falsos positivos torna menos oneroso criar testes de unidade e, ao mesmo tempo, permite que você se concentre no teste de que os dados que são fundamentais para sua solução estão sendo retornados em uma resposta de previsão.

Dica

A ferramenta NLU.DevOps dá suporte a todas as suas necessidades de teste de LUIS. Quando usado no modo de teste de unidade, o comando compare declarará que todos os testes foram aprovados e ignorará resultados falsos positivos de entidades que não estejam rotuladas nos resultados esperados.

Criando testes em lote

Os conjuntos de teste em lote devem conter um grande número de casos de teste, projetados para testar todas as intenções e todas as entidades em seu aplicativo de LUIS. Confira o Teste em lote no portal do LUIS para saber como definir um conjunto de teste em lotes.

Executando testes

O portal do LUIS oferece recursos para ajudar no teste interativo:

  • Os testes interativos permitem que você envie um enunciado de exemplo e obtenha uma resposta de intenções e entidades reconhecidas pelo LUIS. Você verifica o sucesso do teste por inspeção visual.

  • O teste em lotes usa um arquivo de teste em lotes como entrada para validar sua versão treinada ativa para medir a precisão de previsão dela. Um teste em lote ajuda a exibir a precisão de cada intenção e entidade na versão ativa, exibindo os resultados com um gráfico.

Executar testes em um fluxo de trabalho de compilação automatizada

Os recursos de teste interativo no portal do LUIS são úteis, mas para DevOps, os testes automatizados executados em um fluxo de trabalho de CI/CD apresentam determinados requisitos:

  • As ferramentas de teste devem ser executadas em uma etapa de fluxo de trabalho em um servidor de build. Isso significa que as ferramentas devem ser capazes de executar na linha de comando.
  • As ferramentas de teste devem ser capazes de executar um grupo de testes em um ponto de extremidade e verificar automaticamente os resultados esperados em relação aos resultados reais.
  • Se os testes falharem, as ferramentas de teste retornarão um código de status para interromper o fluxo de trabalho e "falhar a compilação".

O LUIS não oferece uma ferramenta de linha de comando ou uma API de alto nível com esses recursos. Recomendamos que você use a ferramenta NLU.DevOps para executar testes e verificar resultados, tanto na linha de comando quanto durante o teste automatizado em um fluxo de trabalho de CI/CD.

As capacidades de teste que estão disponíveis no portal do LUIS não exigem um ponto de extremidade publicado e fazem parte das capacidades de criação do LUIS. Quando você estiver implementando testes em um fluxo de trabalho de build automatizado, você deverá publicar a versão do aplicativo de LUIS para ser testada em um ponto de extremidade para que ferramentas de teste, como o NLU.DevOps, possam enviar solicitações de previsão como parte do teste.

Dica

  • Se você estiver implementando sua própria solução de teste e escrevendo código para enviar enunciados de teste para um ponto de extremidade, lembre-se de que, se você estiver usando a chave de criação do LUIS, a taxa de transação permitida será limitada a 5 TPS. Em vez disso, restrinja a taxa de envio ou use uma chave de previsão.
  • Ao enviar consultas de teste para um ponto de extremidade, lembre-se de usar log=false na cadeia de caracteres de consulta de sua solicitação de previsão. Isso garante que os enunciados de teste não sejam registrados pelo LUIS e terminem na lista de revisão de enunciados do ponto de extremidade apresentada pelo recurso de aprendizado ativo do LUIS e, consequentemente, sejam adicionados de maneira acidental aos enunciados de treinamento do seu aplicativo.

Executar testes de unidade na linha de comando e em fluxos de trabalho de CI/CD

Você pode usar o pacote NLU.DevOps para executar testes na linha de comando:

  • Use o comando test do NLU.DevOps para enviar testes de um arquivo de teste para um ponto de extremidade e capturar os resultados reais de previsão em um arquivo.
  • Use o comando compare do NLU.DevOps para comparar os resultados reais com os resultados esperados definidos no arquivo de teste de entrada. O comando compare gera a saída de teste NUnit e, quando usada no modo de teste de unidade pelo uso do sinalizador --unit-test, declarará que todos os testes foram aprovados.

Executar testes em lote na linha de comando e em fluxos de trabalho de CI/CD

Você também pode usar o pacote NLU.DevOps para executar testes em lotes na linha de comando.

  • Use o comando test do NLU.DevOps para enviar testes de um arquivo de teste para um ponto de extremidade e capturar os resultados reais de previsão em um arquivo, da mesma forma que nos testes de unidade.
  • Use o comando compare do NLU.DevOps no modo teste de Desempenho para medir o desempenho de seu aplicativo, você também pode comparar o desempenho do seu aplicativo em relação a um parâmetro de comparação de desempenho de linha de base, por exemplo, os resultados do último commit da versão principal ou atual. No modo teste de Desempenho, o comando compare gera saída de teste NUnit e resultados de teste em lote no formato JSON.

Treinamento não determinístico do LUIS e o efeito sobre os testes

Quando o LUIS está treinando um modelo, como uma intenção, ele precisa dos dados positivos, dos enunciados de treinamento rotulados que você forneceu para treinar o aplicativo para os dados de modelo e dos dados negativos que não são exemplos válidos do uso desse modelo. Durante o treinamento, o LUIS compila os dados negativos de um modelo com base em todos os dados positivos que você forneceu para os outros modelos, mas em alguns casos isso podem produzir um desequilíbrio nos dados. Para evitar esse desequilíbrio, o LUIS faz a amostragem de um subconjunto dos dados negativos de uma forma não determinística a fim de otimizar para um conjunto de treinamento com equilíbrio melhor, desempenho do modelo aprimorado e tempo de treinamento mais rápido.

O resultado desse treinamento não determinístico é que você pode obter uma resposta de previsão ligeiramente diferente entre diferentes sessões de treinamento, geralmente para intenções e/ou entidades em que a pontuação de previsão não está alta.

Se você quiser desabilitar o treinamento não determinístico para as versões do aplicativo de LUIS que você está criando para fins de teste, use a API de configurações de versão com a configuração UseAllTrainingData definida como true.

Próximas etapas