Teste para LUIS DevOps

  • Artigo

Importante

O LUIS será aposentado em 1º de outubro de 2025 e a partir de 1º de abril de 2023 você não poderá criar novos recursos do LUIS. Recomendamos migrar seus aplicativos LUIS para o entendimento de linguagem conversacional para se beneficiar do suporte contínuo ao produto e dos recursos multilíngues.

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

Em metodologias ágeis de desenvolvimento de software, o teste desempenha um papel integral na construção de software de qualidade. Cada alteração significativa em um aplicativo LUIS deve ser acompanhada por testes projetados para testar 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 .lu fonte do seu aplicativo LUIS. A implementação da alteração é concluída quando o aplicativo satisfaz os testes.

Os testes são uma parte crítica dos fluxos de trabalho de CI/CD. Quando as alterações em um aplicativo LUIS são propostas em uma solicitação pull (PR) 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 regressões.

Como fazer testes unitários e testes em lote

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

  • Testes de unidade - Testes relativamente simples que verificam a funcionalidade chave do seu aplicativo LUIS. Um teste de unidade passa 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 para que a execução do teste seja concluída com êxito.
    Este tipo de teste é semelhante ao teste interativo que você pode fazer no portal LUIS.

  • Testes em lote - O teste em lote é um teste abrangente em seu modelo treinado atual para medir seu desempenho. Ao contrário dos testes de unidade, o teste em lote não é um teste de aprovação|reprovação. A expectativa com o teste em lote não é que todos os testes retornem a intenção esperada e as entidades esperadas. Em vez disso, um teste em lote ajuda você a exibir a precisão de cada intenção e entidade em seu aplicativo e ajuda você a comparar ao longo do tempo à medida que faz melhorias.
    Esse tipo de teste é o mesmo que o teste em lote que você pode executar interativamente no portal LUIS.

Você pode empregar testes de unidade desde o início do seu projeto. O teste em lote só é realmente útil depois de desenvolver o esquema do seu aplicativo LUIS e trabalhar para melhorar sua precisão.

Para testes de unidade e testes em lote, certifique-se de que os enunciados de teste sejam mantidos separados dos enunciados de treinamento. Se você testar nos mesmos dados em que treina, terá a falsa impressão de que seu aplicativo está tendo um bom desempenho quando está apenas se ajustando demais aos dados de teste. Os testes devem ser invisíveis pelo modelo para testar o quão bem ele está generalizando.

Testes de escrita

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

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

Use a sintaxe do arquivo em lote 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. O DevOps também suporta arquivos de teste formatados em LUDown.

Projetando testes de unidade

Os testes de unidade devem ser projetados para testar a funcionalidade principal do seu aplicativo 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:

  • Teste se a intenção correta é retornada
  • Teste se as entidades "chave" - aquelas que são críticas para a sua solução - estão sendo retornadas.
  • Teste se a pontuação de previsão para intenção e entidades excede um limite que você definir. 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 suas entidades-chave exceder 0,75.

Em testes de unidade, é uma boa ideia testar se suas entidades-chave 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. Ao ignorar falsos positivos, torna menos oneroso criar testes de unidade e, ao mesmo tempo, permite que você se concentre em testar se os dados que são fundamentais para sua solução estão sendo retornados em uma resposta de previsão.

Gorjeta

A NLU. A ferramenta DevOps suporta todas as suas necessidades de teste LUIS. O compare comando quando usado no modo de teste de unidade afirmará que todos os testes passam e ignorará resultados falsos positivos para entidades que não estão rotuladas nos resultados esperados.

Projetando testes em lote

Os conjuntos de teste em lote devem conter um grande número de casos de teste, projetados para testar em todas as finalidades e todas as entidades em seu aplicativo LUIS. Consulte Teste em lote no portal LUIS para obter informações sobre como definir um conjunto de testes em lote.

Testes em execução

O portal LUIS oferece recursos para ajudar com testes interativos:

  • O teste interativo permite que você envie um enunciado de amostra 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 lote usa um arquivo de teste em lote como entrada para validar sua versão treinada ativa para medir sua precisão de previsão. Um teste em lote ajuda você a visualizar a precisão de cada intenção e entidade em sua versão ativa, exibindo resultados com um gráfico.

Executando testes em um fluxo de trabalho de compilação automatizado

Os recursos de teste interativo no portal LUIS são úteis, mas para DevOps, o teste automatizado realizado em um fluxo de trabalho de CI/CD traz certos requisitos:

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

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

Os recursos de teste disponíveis no portal LUIS não exigem um ponto de extremidade publicado e fazem parte dos recursos de criação do LUIS. Ao implementar testes em um fluxo de trabalho de compilação automatizado, você deve publicar a versão do aplicativo LUIS a ser testada em um ponto de extremidade para que ferramentas de teste, como NLU. O DevOps pode enviar solicitações de previsão como parte do teste.

Gorjeta

  • Se você estiver implementando sua própria solução de teste e escrevendo código para enviar declarações de teste para um ponto de extremidade, lembre-se de que, se você estiver usando a chave de criação LUIS, a taxa de transação permitida será limitada a 5TPS. Acelere 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 da sua solicitação de previsão. Isso garante que seus enunciados de teste não sejam registrados pelo LUIS e acabem na lista de revisão de enunciados de ponto final apresentada pelo recurso de aprendizagem ativa do LUIS e, como resultado, sejam acidentalmente adicionados aos enunciados de treinamento do seu aplicativo.

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

Você pode usar a NLU. Pacote DevOps para executar testes na linha de comando:

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

Você também pode usar a NLU. Pacote DevOps para executar testes em lote na linha de comando.

  • Use a NLU. Comando de teste DevOps para enviar testes de um arquivo de teste para um ponto de extremidade e capturar os resultados reais da previsão em um arquivo, o mesmo que acontece com os testes de unidade.
  • Use a NLU. Comando DevOps compare no modo de teste de desempenho para medir o desempenho do seu aplicativo Você também pode comparar o desempenho do seu aplicativo com uma referência de desempenho da linha de base, por exemplo, os resultados da última confirmação para a versão principal ou a versão atual. No modo de teste de desempenho, o comando gera saída de teste NUnit e resultados de compare teste em lote no formato JSON.

Treinamento não determinístico LUIS e o efeito nos testes

Quando o LUIS está treinando um modelo, como uma intenção, ele precisa de dados positivos - os enunciados de treinamento rotulados que você forneceu para treinar o aplicativo para o modelo - e dados negativos - dados que não são exemplos válidos do uso desse modelo. Durante o treinamento, o LUIS constrói os dados negativos de um modelo a partir de todos os dados positivos que você forneceu para os outros modelos, mas em alguns casos isso pode produzir um desequilíbrio de dados. Para evitar esse desequilíbrio, o LUIS coleta amostras de um subconjunto dos dados negativos de forma não determinística para otimizar para um conjunto de treinamento mais equilibrado, melhor desempenho do modelo e tempo de treinamento mais rápido.

O resultado deste 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 onde a pontuação de previsão não é alta.

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

Próximos passos