Abordagens de teste para modelos de ML do Amazon SageMaker

Republicado por Platão

seguidores: 0

Esta postagem foi co-escrita com Tobias Wenzel, gerente de engenharia de software da plataforma de aprendizado de máquina Intuit.

Todos nós apreciamos a importância de um modelo de aprendizado de máquina (ML) confiável e de alta qualidade ao usar direção autônoma ou interagir com Alexa, por exemplo. Os modelos de ML também desempenham um papel importante de maneiras menos óbvias — eles são usados por aplicativos de negócios, assistência médica, instituições financeiras, amazon.com, TurboTax e muito mais.

À medida que os aplicativos habilitados para ML se tornam essenciais para muitos negócios, os modelos precisam seguir o mesmo vigor e disciplina dos aplicativos de software. Um aspecto importante do MLOps é entregar uma nova versão do modelo de ML desenvolvido anteriormente em produção usando práticas estabelecidas de DevOps, como teste, controle de versão, entrega contínua e monitoramento.

Existem vários prescritivo diretrizes sobre MLOps, e este post fornece uma visão geral do processo que você pode seguir e quais ferramentas usar para teste. Isto é baseado em colaborações entre Intuit e AWS. Temos trabalhado juntos para implementar as recomendações explicadas neste post na prática e em escala. O objetivo da Intuit de se tornar um Plataforma especializada orientada por IA é fortemente dependente de uma estratégia de aumento da velocidade de desenvolvimento inicial do modelo, bem como teste de novas versões.

Requisitos

A seguir estão as principais áreas de consideração ao implantar novas versões de modelo:

Desempenho de precisão do modelo – É importante observar de métricas de avaliação de modelo, como exatidão, precisão e recall, e garantir que as métricas objetivas permaneçam relativamente as mesmas ou melhorem com uma nova versão do modelo. Na maioria dos casos, a implantação de uma nova versão do modelo não faz sentido se a experiência dos usuários finais não melhorar.
Teste a qualidade dos dados – Os dados em ambientes de não produção, sejam simulados ou cópia pontual, devem ser representativos dos dados que o modelo receberá quando totalmente implantado, em termos de volume ou distribuição. Caso contrário, seus processos de teste não serão representativos e seu modelo poderá se comportar de maneira diferente na produção.
Importância e paridade do recurso – A importância do recurso na versão mais recente do modelo deve ser relativamente comparada ao modelo mais antigo, embora possa haver novos recursos introduzidos. Isso é para garantir que o modelo não esteja se tornando tendencioso.
Testes de processos de negócios – É importante que uma nova versão de um modelo possa atender aos objetivos de negócios necessários dentro de parâmetros aceitáveis. Por exemplo, uma das métricas de negócios pode ser que a latência de ponta a ponta para qualquer serviço não deve ser superior a 100 milissegundos, ou o custo para hospedar e retreinar um modelo específico não pode ser superior a US$ 10,000 por ano.
Custo – Uma abordagem simples para testar é replicar todo o ambiente de produção como um ambiente de teste. Esta é uma prática comum no desenvolvimento de software. No entanto, essa abordagem no caso de modelos de ML pode não gerar o ROI correto dependendo do tamanho dos dados e pode afetar o modelo em termos do problema de negócios que ele está abordando.
Segurança – Em geral, espera-se que os ambientes de teste tenham dados de amostra em vez de dados reais do cliente e, como resultado, o manuseio de dados e as regras de conformidade podem ser menos rigorosas. Assim como o custo, se você simplesmente duplicar o ambiente de produção em um ambiente de teste, poderá introduzir riscos de segurança e conformidade.
Escalabilidade do repositório de recursos – Se uma organização decidir não criar um repositório de recursos de teste separado por motivos de custo ou segurança, o teste de modelo precisará acontecer no repositório de recursos de produção, o que pode causar problemas de escalabilidade, pois o tráfego é duplicado durante o período de teste.
Desempenho do modelo online – As avaliações online diferem das avaliações offline e podem ser importantes em alguns casos, como modelos de recomendação, porque medem a satisfação do usuário em tempo real, em vez da satisfação percebida. É difícil simular padrões de tráfego reais em não produção devido à sazonalidade ou outro comportamento do usuário, portanto, o desempenho do modelo online só pode ser feito em produção.
Performance operacional – À medida que os modelos crescem e são implantados cada vez mais de maneira descentralizada em diferentes hardwares, é importante testar o modelo para o desempenho operacional desejado, como latência, taxa de erros e muito mais.

A maioria das equipes de ML tem uma abordagem multifacetada para o teste de modelos. Nas seções a seguir, fornecemos maneiras de lidar com esses desafios durante vários estágios de teste.

Teste de modelo offline

O objetivo desta fase de teste é validar novas versões de um modelo existente do ponto de vista de precisão. Isso deve ser feito de maneira offline para não afetar nenhuma previsão no sistema de produção que esteja atendendo a previsões em tempo real. Ao garantir que o novo modelo tenha um desempenho melhor para as métricas de avaliação aplicáveis, este teste aborda o desafio 1 (desempenho de precisão do modelo). Além disso, usando o conjunto de dados correto, esse teste pode abordar os desafios 2 e 3 (qualidade dos dados de teste, importância e paridade do recurso), com o benefício adicional de enfrentar o desafio 5 (custo).

Esta fase é feita no ambiente de teste.

Você deve capturar o tráfego de produção, que pode ser usado para reproduzir em backtest offline. É preferível usar o tráfego de produção anterior em vez de dados sintéticos. o Monitor de modelo do Amazon SageMaker recurso de captura de dados permite capturar o tráfego de produção para modelos hospedados em Amazon Sage Maker. Isso permite que os desenvolvedores de modelos testem seus modelos com dados de dias úteis de pico ou outros eventos significativos. Os dados capturados são então reproduzidos na nova versão do modelo em lote usando Transformação em lote do Sagemaker. Isso significa que a execução de transformação em lote pode ser testada com dados coletados ao longo de semanas ou meses em apenas algumas horas. Isso pode acelerar significativamente o processo de avaliação do modelo em comparação com a execução de duas ou mais versões de um modelo em tempo real lado a lado e o envio de solicitações de previsão duplicadas para cada endpoint. Além de encontrar uma versão com melhor desempenho mais rapidamente, essa abordagem também usa os recursos de computação por um período menor de tempo, reduzindo o custo geral.

Um desafio com essa abordagem de teste é que o conjunto de recursos muda de uma versão de modelo para outra. Nesse cenário, recomendamos a criação de um conjunto de recursos com um superconjunto de recursos para ambas as versões para que todos os recursos possam ser consultados de uma só vez e registrados por meio da captura de dados. Cada chamada de previsão pode trabalhar apenas nos recursos necessários para a versão atual do modelo.

Como um bônus adicional, ao integrar Esclarecimento do Amazon SageMaker em seu teste de modelo offline, você pode verificar a nova versão do modelo quanto ao viés e também comparar a atribuição de recursos com a versão anterior do modelo. Com pipelines, você pode orquestrar todo o fluxo de trabalho de forma que, após o treinamento, uma etapa de verificação de qualidade possa ocorrer para realizar uma análise das métricas do modelo e da importância do recurso. Essas métricas são armazenadas no Registro de modelo SageMaker para comparação na próxima rodada de treinamento.

Teste de integração e desempenho

O teste de integração é necessário para validar processos de negócios de ponta a ponta de uma perspectiva de desempenho funcional e de tempo de execução. Nesse processo, todo o pipeline deve ser testado, incluindo a busca e o cálculo de recursos no repositório de recursos e a execução do aplicativo de ML. Isso deve ser feito com uma variedade de cargas úteis diferentes para cobrir uma variedade de cenários e solicitações e obter alta cobertura para todas as execuções de código possíveis. Isso aborda os desafios 4 e 9 (teste de processos de negócios e desempenho operacional) para garantir que nenhum dos processos de negócios seja interrompido com a nova versão do modelo.

Este teste deve ser feito em um ambiente de teste.

Tanto o teste de integração quanto o teste de desempenho precisam ser implementados por equipes individuais usando seu pipeline de MLOps. Para o teste de integração, recomendamos o método testado e comprovado de manter um ambiente de pré-produção funcionalmente equivalente e testar com algumas cargas úteis diferentes. O fluxo de trabalho de teste pode ser automatizado conforme mostrado em esta oficina. Para o teste de desempenho, você pode usar Recomendador de inferência do Amazon SageMaker, que oferece um ótimo ponto de partida para determinar qual tipo de instância e quantas dessas instâncias usar. Para isso, você precisará usar uma ferramenta geradora de carga, como os projetos de código aberto perfsizesagemaker e tamanho perfeito que a Intuit desenvolveu. O Perfsizesagemaker permite testar automaticamente as configurações de endpoint do modelo com uma variedade de requisitos de cargas úteis, tempos de resposta e transações de pico por segundo. Ele gera resultados de teste detalhados que comparam diferentes versões do modelo. Perfsize é a ferramenta complementar que tenta diferentes configurações, considerando apenas as transações de pico por segundo e o tempo de resposta esperado.

Teste A / B Exemplo: crie XNUMX textos de email > XNUMX pessoas na sua lista, XNUMX receberao XNUMX email e XNUMX receberão outro e veja qual email converteu mais

Em muitos casos em que a reação do usuário à saída imediata do modelo é necessária, como aplicativos de comércio eletrônico, a avaliação funcional do modelo offline não é suficiente. Nesses cenários, você precisa testar os modelos A/B em produção antes de tomar a decisão de atualizar os modelos. O teste A/B também tem seus riscos porque pode haver um impacto real no cliente. Esse método de teste serve como a validação final do desempenho do ML, uma verificação de sanidade de engenharia leve. Este método também aborda os desafios 8 e 9 (desempenho do modelo online e excelência operacional).

O teste A/B deve ser realizado em um ambiente de produção.

Com o SageMaker, você pode facilmente realizar testes A/B em modelos de ML executando várias variantes de produção em um ponto final. O tráfego pode ser roteado em incrementos para a nova versão para reduzir o risco que um modelo de mau comportamento pode ter na produção. Se os resultados do teste A/B forem bons, o tráfego será roteado para a nova versão, eventualmente tomando mais de 100% do tráfego. Recomendamos usar proteções de implantação para fazer a transição do modelo A para o B. Para uma discussão mais completa sobre testes A/B usando Amazon Customize modelos como exemplo, consulte Usar testes A/B para medir a eficácia das recomendações geradas pelo Amazon Personalize.

Teste de modelo online

Nesse cenário, a nova versão de um modelo é significativamente diferente daquela que já atende tráfego ao vivo na produção, portanto, a abordagem de teste offline não é mais adequada para determinar a eficácia da nova versão do modelo. A razão mais importante para isso é uma alteração nos recursos necessários para produzir a previsão, de modo que as transações registradas anteriormente não possam ser usadas para testar o modelo. Nesse cenário, recomendamos o uso de implantações de sombra. As implantações de sombra oferecem a capacidade de implantar uma sombra (ou desafiador) ao lado da produção (ou campeão) que atualmente está atendendo a previsões. Isso permite avaliar o desempenho do modelo de sombra no tráfego de produção. As previsões do modelo de sombra não são fornecidas ao aplicativo solicitante; eles são registrados para avaliação offline. Com a abordagem de sombra para testes, abordamos os desafios 4, 5, 6 e 7 (teste de processos de negócios, custo, segurança e escalabilidade do repositório de recursos).

O teste de modelo online deve ser feito em ambientes de teste ou produção.

Este método de testar novas versões de modelo deve ser usado como último recurso se todos os outros métodos não puderem ser usados. Recomendamos como último recurso porque a duplicação de chamadas para vários modelos gera carga adicional em todos os serviços de downstream em produção, o que pode levar a gargalos de desempenho, bem como aumentar o custo de produção. O impacto mais óbvio que isso tem é na camada de serviço de feição. Para casos de uso que compartilham recursos de um conjunto comum de dados físicos, precisamos ser capazes de simular vários casos de uso acessando simultaneamente a mesma tabela de dados para garantir que não haja contenção de recursos antes da transição para a produção. Sempre que possível, as consultas duplicadas no repositório de recursos devem ser evitadas e os recursos necessários para ambas as versões do modelo devem ser reutilizados para a segunda inferência. Lojas de recursos baseadas em Amazon DynamoDB, como o que a Intuit construiu, pode implementar Acelerador do Amazon DynamoDB(DAX) para armazenar em cache e evitar dobrar a E/S para o banco de dados. Essas e outras opções de armazenamento em cache podem mitigar o desafio 7 (escalabilidade do repositório de recursos).

Para lidar com o desafio 5 (custo), bem como o 7, propomos o uso de implantações de sombra para amostrar o tráfego de entrada. Isso dá aos proprietários de modelos outra camada de controle para minimizar o impacto nos sistemas de produção.

A implantação de sombra deve ser integrada ao Monitor de modelo ofertas assim como as implantações de produção regulares, a fim de observar as melhorias da versão desafiadora.

Conclusão

Esta postagem ilustra os blocos de construção para criar um conjunto abrangente de processos e ferramentas para enfrentar vários desafios com teste de modelo. Embora cada organização seja única, isso deve ajudá-lo a começar e restringir suas considerações ao implementar sua própria estratégia de teste.

Sobre os autores

Tobias Wenzel é gerente de engenharia de software da plataforma de aprendizado de máquina Intuit em Mountain View, Califórnia. Ele trabalha na plataforma desde o início em 2016 e ajudou a projetar e construir desde o início. Em seu trabalho, ele se concentrou na excelência operacional da plataforma e em trazê-la com sucesso por meio dos negócios sazonais da Intuit. Além disso, ele é apaixonado por expandir continuamente a plataforma com as tecnologias mais recentes.

Shivanshu Upadhyay é um arquiteto de soluções principal no grupo AWS Business Development and Strategic Industries. Nessa função, ele ajuda os usuários mais avançados da AWS a transformar seu setor usando dados e IA com eficiência.

Alan Tan é Gerente de Produto Sênior da SageMaker, liderando esforços na inferência de grandes modelos. Ele é apaixonado por aplicar o aprendizado de máquina à área de análise. Fora do trabalho, ele gosta de atividades ao ar livre.