Os serviços preditivos e de otimização baseados no Machine Learning são de interesse para muitas empresas atualmente: de grandes bancos a pequenas lojas online. Resolvendo os problemas de vários clientes, encontramos vários problemas, que serviram de base para nossas discussões sobre os recursos dos testes de ML. Para quem estiver interessado, este é o próximo post de Sergey Agaltsov, gerente de testes da Jet Infosystems.
Anteriormente, apenas as grandes empresas podiam tirar proveito do aprendizado de máquina, pois era caro e difícil, e havia muito poucos dados no domínio público. Hoje ficou muito mais fácil. A expertise ML pode ser solicitada a um integrador, empresa especializada ou em um site temático. Isso é bom para todos, porque, com o crescimento da experiência, novos algoritmos são desenvolvidos, e o “mealheiro da experiência” no campo do aprendizado de máquina é constantemente enriquecido.
O único aspecto para o qual não encontramos uma solução pronta é testar os serviços de ML. No Google, você pode garantir que, nos resultados da pesquisa, não haja menção das atividades dos testadores no desenvolvimento de tais serviços. Obviamente, os próprios especialistas em ciência de dados testam seus modelos usando várias métricas e, de acordo com essas métricas, o serviço pode ser o mais preciso possível, no entanto, a realidade é que o modelo nem sempre é capaz de levar em consideração várias nuances e gargalos de produção. Então, a lógica do aprendizado de máquina começa a se transformar em um código rígido.
Nesse sentido, estamos começando a enfrentar vários problemas:
- Nosso modelo de otimização sempre leva em consideração possíveis restrições de produção?
- Nossos modelos são capazes de trabalhar com gargalos?
- Nosso modelo é capaz de responder corretamente às mudanças na produção?
Foi aqui que decidimos focar a equipe de teste.
Nossa tarefa é unificar a prática de teste de ML para poder responder a todos os problemas acima. No momento, chegamos a várias conclusões e agora vou lhe dizer quais.
Teste a conformidade com as restrições e requisitos de produção para consideração pelo algoritmo de otimização
Nos testes clássicos, em qualquer teste, sempre temos um "resultado esperado". Nós sabemos perfeitamente qual deve ser a reação do sistema em um ou outro dos dados de entrada. No entanto, se estamos falando de ML em ambientes de produção, esse resultado mais esperado pode ser a conformidade com documentos regulamentares, como GOSTs, instruções tecnológicas e fluxogramas temporários, que limitam os próprios processos de produção e os critérios de qualidade do produto final. Durante o teste, precisamos ter certeza de que todas essas restrições são realmente observadas e, apesar do número, temos certeza de que cada uma delas é coberta por casos de teste.
No exemplo de um projeto real para otimizar a produção dos materiais N (ainda não divulgamos o caso, usaremos nomes anônimos), resolvemos esse problema da seguinte maneira:
- Classificamos todos os tipos de misturas de materiais N pelo nível de elementos químicos neles. Como resultado, obtivemos uma lista, que mais tarde planejamos usar como um auxílio para garantir uma cobertura de teste suficiente.
- Estávamos convencidos de que as recomendações emitidas pelo modelo para todas essas misturas eram de fato incondicionalmente aceitas pelos técnicos de produção e registramos o resultado desse problema em um arquivo CSV. Assim, recebemos recomendações do sistema de um certo "padrão ouro".
- Em seguida, foi escrito um script que executava a lista de nossas misturas de referência através do modelo de versão para versão e comparava o resultado de sua entrega com o que estava armazenado em nosso "padrão ouro" csv.
- Se nenhuma mudança no comportamento do modelo for detectada, os testes de regressão poderão ser considerados bem-sucedidos. Caso contrário, um "interrogatório" foi realizado.
Assim, fomos capazes de resolver o problema do teste de regressão e ganhar confiança de que as alterações introduzidas no modelo não afetam os resultados anteriores do nosso trabalho.
Testes focados em gargalos
Os modelos de otimização são mais capazes de prever o que é encontrado com mais frequência nos dados históricos e, inversamente, um modelo pode “se transformar em abóbora” assim que encontrar algo incomum para si.
Freqüentemente, nesses casos, o serviço de otimização precisa "solicitar" um modelo de comportamento adequado e isso gera o código rígido que eu escrevi anteriormente. Mas como identificar esses gargalos e depurar o serviço? Vou falar sobre isso no exemplo do desenvolvimento de um serviço para recomendações sobre o gerenciamento da produção do material N (o caso ainda não está sujeito à divulgação, portanto, os nomes velados são mencionados abaixo).
Primeiro, nosso arquiteto desenvolveu um emulador de integração que gerou dados semelhantes aos produtivos e, assim, preencheu o período, com base no qual o modelo de otimização emitiu recomendações para o processamento do material N. Em seguida, o testador analisou essas recomendações e identificou as mais suspeitas - aquelas que foram eliminadas parâmetros recomendados para o fluxo mássico total. Já nessa fase, conseguimos identificar muitos problemas quando o modelo, de uma maneira ou de outra, não conseguia processar adequadamente o fluxo de dados recebidos. Isso nos permitiu estabilizar o estado do serviço e seguir para a próxima etapa.
A segunda etapa foi o teste "Silêncio". O serviço foi criado no ambiente de produção em segundo plano. Ele trabalhou sem distrair o operador de processamento de material N do controle da máquina e, por sua vez, coletamos "soluções de operador", comparando-as com o que o serviço recomendava. Devido a isso, encontramos os pontos cegos do modelo que não puderam ser capturados no estágio anterior.
O modelo deve ser capaz de responder às alterações de produção.
Temos um portfólio de serviços em nosso portfólio de projetos para otimizar a produção de materiais combustíveis. A essência do serviço é que o tecnólogo transfere o estoque dos componentes de produção para o modelo, define os indicadores limitantes da qualidade do produto e define o plano de produção necessário e, em resposta, recebe uma recomendação: em que proporções ele precisa usar determinados componentes para obter o combustível da quantidade especificada qualidade.
No processo de desenvolvimento desse serviço, encontramos um problema curioso que não podíamos prever com antecedência.
Durante vários anos, a empresa na produção de combustível trabalhou em um certo intervalo de rotações agregadas e, ao mesmo tempo, usou mais / menos a mesma proporção de componentes.
Recentemente, porém, a organização mudou o fornecimento desses componentes e tornou-se possível compensar esse fato aumentando a velocidade das unidades. O cliente esperava que o modelo fosse capaz de responder a essas mudanças, portanto, do ponto de vista da produção tecnológica - essa é uma solução aceitável, mas isso não aconteceu. Porque A resposta é óbvia - o modelo foi treinado em uma amostra histórica, onde isso não havia acontecido antes. Você pode discutir por um longo tempo sobre quem está certo nesta situação e quem é o culpado, mas no futuro planejamos reduzir a probabilidade de tais situações, como a seguir:
- Trabalhe mais de perto com o representante do cliente da unidade de produção para identificar gargalos e possíveis alterações no produto.
- Cubra casos de teste com casos semelhantes com antecedência.
- Escreva autotestes para verificar a conformidade com as restrições de produção e a correlação de sinais.
Apenas algumas palavras sobre as ferramentas de teste que tivemos que usar:
- rastreamento de bugs - Jira,
- sistema de gestão da qualidade - Test Rail,
- sistema de controle de versão - GitLab,
- CI / CD - Jenkins,
- autotests - Java + Junit / TestNG,
- scripts para interação direta com o modelo - Python + Jupyter.
Você testa ML?
Para nós, a construção de uma prática de teste de ML tornou-se um desafio; na verdade, foi preciso crescer do zero. Mas o teste é necessário - ajuda a reduzir o número de erros antes de iniciar a operação de teste e a diminuir o tempo de implementação.
Hoje, todos precisamos compartilhar e trocar experiências. É necessário iniciar discussões sobre testes em sites especializados e fóruns profissionais, que, a propósito, estão se tornando cada vez mais no campo da ML. E se você já estabeleceu práticas para testar o ML, acho que todos estarão interessados em ler sobre eles, então compartilhe sua experiência nos comentários.
Sergey Agaltsov, Gerente de Testes, Jet Infosystems