MLOps e implantação: movendo o modelo do laboratório para a produção

Ganhos:

• Capacidade de reconhecer os desafios especiais do ML relacionados ao trio e pacote código-dados-modelo e apresentar o modelo online ou em lote de acordo com a necessidade do negócio.
• Capacidade de implementar padrões de implantação graduais e de reversão (sombra, canário, A/B, reversão) e adicionar um plano de reversão testado a cada implantação
• Capacidade de manter rastreável o link dados-código-métrica do modelo colocado em produção com CI/CD controlado por limite de avaliação e registro de modelo

Conseguir que um modelo atinja 95% de precisão no notebook é apenas metade da história. A outra metade – muitas vezes a parte mais difícil – é levar esse modelo aos usuários reais de maneira confiável, escalável e sustentável. MLOps (Machine Learning Operations: a disciplina de colocar, operar e manter modelos de ML em produção) combina as práticas DevOps da engenharia de software com os desafios exclusivos do ML. Nesta unidade, abordamos as etapas de movimentação do modelo para produção e como a inteligência artificial ajuda nesse processo.

Por que o ML é diferente do software normal?

No software comum, o comportamento está no código; Se o código não mudar, o comportamento não muda. No ML, o comportamento depende do código, dos dados e do modelo. Essas três dimensões criam desafios extras de MLOps:

• Desvio de dados: os dados em produção se afastam dos dados em treinamento ao longo do tempo; o modelo se torna obsoleto.
• Você precisa criar versões de três coisas: código, dados e modelo – todos os três.
• Falha silenciosa: Um modelo pode falhar sem travar, sem dar erros, simplesmente por produzir previsões incorretas. Capturar isso requer monitoramento.

É por isso que existe uma grande diferença entre um “modelo funcional” e um “modelo pronto para produção”.

Embalagem e apresentação do modelo

A primeira etapa para colocar o modelo em produção é empacotá-lo: o arquivo do modelo, as bibliotecas necessárias, o código de pré-processamento e as informações de versão juntos como um todo reproduzível. A conteinerização (por exemplo, Docker: colocar a aplicação em uma caixa isolada com todas as suas dependências) é padrão aqui; Elimina o problema "estava funcionando na minha máquina".

Dois padrões básicos de servir o modelo:

• Online/tempo real (online): O modelo fica atrás de uma API, retornando uma previsão instantânea para cada solicitação recebida. A baixa latência é crítica.
• Lote: O modelo processa grandes conjuntos de dados periodicamente (por exemplo, gera pontuações para todos os clientes à noite). A latência é irrelevante, a eficiência é importante.

Qual deles depende da necessidade do negócio: recomendação instantânea on-line, pontuação de risco mensal em lote.

Dica: “Tempo real” é um custo, não o padrão. O lote é muito mais barato e simples se o resultado for usado em poucas horas. Você realmente precisa de uma resposta instantânea? Pergunte isso primeiro.

Estratégias de distribuição segura

Abrir um novo modelo diretamente a todo o tráfego é arriscado; Se estiver errado, todos serão afetados. Padrões de distribuição seguros:

• Implantação sombra: O novo modelo recebe tráfego de produção, mas suas previsões não são mostradas ao usuário, apenas registradas. Ele é comparado com o modelo antigo para ver se é seguro em dados reais.
• Implantação Canary: O novo modelo é implementado primeiro para uma pequena porcentagem de tráfego (por exemplo, 5%); Se não houver problema, aumenta gradativamente.
• Teste A/B: Dois modelos são apresentados ao usuário real em paralelo e as métricas de negócios (conversão, cliques) são comparadas.
• Rollback: Capacidade de reverter rapidamente para a versão antiga se o novo modelo for ruim. Cada implantação deve ter um plano de reversão.

Cuidado: uma implantação sem um plano de reversão não será concluída. Ser capaz de reverter para a versão antiga em poucos minutos protege o usuário quando o novo modelo se comporta de forma inesperada na produção. Teste isso antes da implantação.

Abordagem fraca/abordagem forte

Fraco: “O modelo foi bom nos testes, entramos no ar, abrimos para todo mundo”.

Güçlü: "Colocamos o modelo em contêiner e o rotulamos como uma versão. Primeiro, executamos em modo sombra com tráfego de produção por 3 dias, comparando as previsões com o modelo antigo - o desvio era aceitável. Em seguida, abrimos com 5% canário, monitoramos as métricas de rendimento e latência. Quando não houve problemas, aumentamos gradualmente para 100%. Tínhamos testado o comando de reversão de antemão."

A diferença: a abordagem forte é gradual, comedida e reversível. O risco é limitado em cada etapa.

CI/CD e automação

CI/CD (Integração Contínua/Implantação Contínua: pipeline de teste automático e liberação de alterações de código) em ML cobre não apenas o código, mas também os dados e as etapas do modelo. Um bom pipeline de CI/CD de ML: executa testes quando o código muda, realiza validação de dados, treina novamente o modelo (se necessário), verifica os limites de avaliação e só avança a implantação se os limites forem mantidos. O princípio de “o treinamento é automático, a implantação é baseada em limites” evita que o modelo ruim vaze silenciosamente para a produção.

A IA é muito útil ao configurar esses pipelines: escrever rascunhos de arquivos de configuração (YAML), casos de teste, scripts de implantação. Mas você determina os limites de distribuição (qualquer métrica que exceda o valor publicado) e a política de reversão; essas são decisões de risco de negócios.

Infraestrutura de reprodutibilidade

Para reproduzir o comportamento de um modelo em produção, é necessário registro de modelo: um registro que mantém qual modelo foi treinado com quais dados e código, e quais métricas ele recebeu. Para cada modelo de produção, o seguinte deve ser rastreável: versão dos dados de treinamento, versão do código (git commit), hiperparâmetros, pontuações de avaliação e data de implantação. Quando surgir um problema, você deverá ser capaz de responder à pergunta "qual modelo produziu esta previsão, com quais dados?" em poucos minutos. Iremos aprofundar isso na unidade 11.

três mini cases

Caso 1 - Problema detectado pela distribuição de sombras. Um modelo de recomendação superou o antigo nos testes. Descobriu-se que executá-lo com tráfego de produção no modo sombra produz recomendações muito ruins para um segmento específico de usuários (novos usuários) - os dados de teste eram sub-representativos deste segmento. O modelo foi corrigido sem nunca ser exibido ao usuário. Se fosse aberto diretamente, a nova experiência do usuário seria prejudicada.

Caso 2 – Distribuição irrevogável. Uma equipe lançou um novo modelo de preços para todo o tráfego, sem planos de reversão. O modelo inesperadamente precificou alguns produtos muito barato. A reversão para a versão antiga demorava horas porque o processo não estava pronto. Houve uma grave perda de rendimentos. Posteriormente, testes de reversão obrigatórios foram adicionados a cada implantação.

Caso 3 – Desvio silencioso de dados. Um padrão de fraude apareceu durante meses sem erros. Mas as táticas dos fraudadores mudaram (desvio de dados) e o recall do modelo caiu silenciosamente. Ninguém percebeu porque não havia monitoramento. Uma vez estabelecido um painel de monitorização da distribuição das previsões, a deriva tornou-se visível precocemente. Abordaremos o monitoramento na unidade 8.

Modelos copiáveis

Escreva um rascunho do plano de implantação para este modelo. Modelo: [o que faz], uso: [online ou lote?] Deve incluir: 1) Embalagem (contêiner, controle de versão) 2) Estratégia de implantação incremental (sombra/canário/AB) e por que 3) Métricas para rastrear (negócios + técnicas + latência) 4) Plano de reversão e como testar 5) Limites de implantação (qual métrica deve exceder qual valor)

Verifique este pipeline de CI/CD de ML:1) A validação de dados está na linha?2) A implantação pode prosseguir sem manter o limite de avaliação (não deveria)?3) A reversão é automática?4) Os dados+código+métricas são rastreados no registro do modelo?Configuração da linha: [config]

Ajude-me a decidir se a apresentação online ou em lote é adequada para este modelo. Por quanto tempo o resultado será usado: [instantâneo/minuto/hora/dia]Volume de solicitação esperado: [número]Existe uma restrição de atraso: [ms]Qual você recomendaria em termos de custo e complexidade e por quê?

Escreva um procedimento de reversão para este modelo.- Qual métrica/limite aciona um desempenho ruim?- Quais são as etapas de reversão?- Quanto tempo a reversão deve levar (meta)?- Como testar esse procedimento antes da produção?

Tabela de padrões de apresentação

critério

On-line (tempo real)

Lote

atraso

Crítico (ms)

insignificante

Uso

É necessária resposta instantânea

Pontuação periódica

Custo

alto

baixo

complexidade

alto

baixo

exemplo

Recomendação ao vivo, fraude

Pontuação de risco mensal

Erros comuns

• Distribua sem um plano de recuperação. O modelo errado atinge todo o usuário.
• Abertura direta para 100% de tráfego. Limite o risco com distribuição escalonada.
• Não estabelecer monitoramento. O modelo produz erros silenciosamente, sem erros.
• Apresentação redundante em tempo real. Embora o lote seja suficiente, o custo e a complexidade aumentam.
• Não vinculando versões de código de dados de modelo. Você não pode reproduzir o problema.
• Liberação automática sem limite de distribuição. O mau modelo entra silenciosamente.

Em resumo

Mover o modelo para produção é uma tarefa de engenharia diferente e muitas vezes mais difícil do que treiná-lo. O ML requer disciplina extra porque depende do trio código-dados-modelo: empacotamento e controle de versão, padrão de entrega (online/lote) que atende às necessidades do negócio, implantação gradual e reversível, CI/CD controlado por limite e registro de modelo. A inteligência artificial é uma ajuda poderosa na geração do código e na configuração desta infraestrutura; mas os limites de distribuição, a política de recuperação e as decisões de risco são seus. Uma distribuição sem um plano de reversão não está completa.

Tarefa de aplicativo

Containerize (Docker) um modelo e rotule-o como versão. Decida se você oferecerá on-line ou em lote com base nas necessidades do seu negócio e escreva sua justificativa. Documente um plano de implantação em fases (sombra ou canário) e um procedimento de reversão testado. Certifique-se de registrar a versão dos dados, a confirmação do código e as pontuações de avaliação no registro do modelo.

lista de verificação

• [ ] O modelo é empacotado e versionado (contêiner + rótulo).
• [ ] O padrão de apresentação (online/lote) foi escolhido de acordo com a necessidade do negócio.
• [] Estratégia de implantação em etapas (sombra/canário) implementada.
• [] Procedimento de reversão escrito e testado.
• [] O CI/CD não avança a implantação antes que o limite de avaliação seja atingido.
• [] O registro do modelo contém o link dados + código + métrica.