Removendo Riscos de Projetos de Aprendizado de Máquina (ML) em Tempo Real: Resolvendo Modos de Falha Comuns

Escrito por Felipe Almeida e revisado por Rubens Bolgheroni 

Aprendizado de máquina (ML) é uma ferramenta poderosa, mas cara e arriscada. Ela é poderosa porque costuma ser a única solução dimensionável para problemas complexos. É cara porque os recursos (profissionais especializados e potência de computação) são caros. E é arriscada porque os modelos quebram de formas muitas vezes estranhas e silenciosas: desvio de dados (data drift) ou recursos quebrados não ativam exceções, apesar de que as previsões do modelo provavelmente serão ruins.

Um projeto de aprendizado de máquina (ML) é o processo de levar uma ideia de fato para um sistema de software funcional usando um modelo de aprendizado de máquina (ML).

Escrevemos sobre os usos do aprendizado de máquina (ML) em tempo real no passado. Mas antes que você possa pensar em usar aprendizado de máquina (ML) para ajudar sua empresa, precisa de um projeto que o transforme de uma ideia para um equipamento funcional, retornando resultados. E você não quer que o projeto fracasse, pois é dinheiro e tempo que poderiam ter sido usados em outro lugar na empresa. Isso, obviamente, presume que você de fato precise de um modelo de aprendizado de máquina (ML) em primeiro lugar.

Porém, mesmo que um projeto de aprendizado de máquina (ML) realmente fracasse, é melhor que seja cedo, antes que muito tempo e dinheiro sejam investidos nele. A Figura 1 abaixo mostra os diferentes resultados de um projeto, dependendo de ele ter retornado valor à empresa e do tempo que levou até sua conclusão.

Figura 1: Os resultados do projeto raramente são binários, mas uma constância de “níveis” de sucesso. O sucesso depende do impacto dos resultados, mas levamos em consideração o tempo e os custos do projeto.

E por que projetos de aprendizado de máquina (ML) fracassam?

Há muitos motivos: problemas com dados e expectativas desalinhadas entre clientes e a equipe de modelagem, para citar alguns.

Entretanto, projetos de aprendizado de máquina (ML) em tempo real aumentam os riscos: eles possuem ainda mais modos de fracasso do que projetos regulares (sem ser em tempo real). Além de todos os riscos inerentes ao aprendizado de máquina (ML), modelos em tempo real são sistemas de software que precisam ser integrados a outros sistemas em tempo real através de APIs, e costumam estar sujeitos a tempos de resposta restritos para manter a paridade com o ambiente de treinamento.

Nesta postagem mostraremos como é um projeto de aprendizado de máquina (ML) típico e depois veremos as formas mais comuns em que esses projetos podem fracassar. Por fim, forneceremos instruções práticas para resolver ou reduzir o risco de cada ponto.

Linha temporal típica de um projeto

Como mencionado antes, um projeto é o processo que transforma uma ideia em realidade. No caso de aprendizado de máquina (ML), isso inclui escolher um problema corporativo, entender se e como pode ser resolvido com aprendizado de máquina (ML) e, por fim, criar um modelo e integrá-lo à infraestrutura de TI básica da empresa.

Os estágios de um projeto de aprendizado de máquina (ML) em tempo real típico podem ser resumidos assim:

1. Concepção e entendimento do caso de uso: Entender como e por quem o modelo será usado. Às vezes, o veredito pode ser que aprendizado de máquina (ML) não seja a solução correta.
2. Análise de Dados e Modelagem: Quando o caso de uso estiver estabelecido, organize os dados e realize a exploração de dados. Então, modele o problema: seleção de recursos e treinamento de modelo.
3. Definição da camada de decisão: No pós-treinamento, entenda como os resultados do modelo serão traduzidos em escolhas corporativas. Isso pode incluir técnicas de otimização (por exemplo, qual a pontuação de corte ideal para que uma determinada métrica da empresa seja maximizada?)
4. Implementação / Integração em Tempo Real: Integre o modelo à infraestrutura de TI básica, conectando-o a outros serviços para buscar recursos e retornar as decisões aos serviços de solicitação.
5. Configure o monitoramento: Configure o registro de dados e ferramentas como Splunk ou Grafana para rastrear métricas e recursos do modelo.

Tenha em mente que as etapas acima não são necessariamente lineares. Ou seja, elas não precisam acontecer em sequência. 

Por exemplo, pode ser necessário voltar à fase de concepção durante o projeto para revisitar presunções que não eram verdadeiras. Além disso, cientistas de dados podem precisar treinar novamente o modelo se houver um problema com algum recurso que agora precise ser abandonado. A Figura 2 abaixo apresenta um resumo visual:

Figura 2: Projeto de aprendizado de máquina (ML) em tempo Real típico. Observe que às vezes pode ser necessário “voltar” aos estágios anteriores dependendo de imprevistos, como dados inconsistentes e a necessidade de abandonar recursos do modelo, exigindo um novo treinamento. Além disso, algumas etapas podem ocorrer paralelamente.

Há dois tipos de projetos de aprendizado de máquina (ML) em tempo real: introduzindo um novo modelo e atualizando um modelo existente: 

• Introduzindo um novo modelo: criar um novo modelo desde o princípio e integrá-lo a um fluxo corporativo que atualmente não usa modelos.
• Atualizando um modelo existente: atualizar ou substituir um modelo existente por uma versão aprimorada, com mais recursos, mais dados de treinamento, um novo algoritmo etc.

Essa distinção é útil porque atualizar um modelo existente é menos arriscado que introduzir um novo modelo a um fluxo corporativo. Se a maneira com que o modelo é usado for a mesma, você pode pular o estágio de validação do caso de uso, que é onde está grande parte dos riscos.

Independentemente de estarmos introduzindo um novo modelo ou atualizando um existente, todos os estágios do projeto apresentam riscos. Agora veremos algumas das formas em que projetos de aprendizado de máquina (ML) em tempo real fracassam.

Conheça nossas oportunidades

Modos de fracasso de aprendizado de máquina (ML) em tempo real

Como mencionado na introdução, há níveis de fracasso em projetos de aprendizado de máquina (ML). O fracasso de um projeto devido ao desempenho insatisfatório do modelo é ruim. Mas um projeto fracassar após investir um tempo considerável nele é muito pior.

de aprendizado tem suas vulnerabilidades singulares. Isso é especialmente verdadeiro para projetos em tempo real, pois a instalação do modelo e a integração de serviços apresentam uma camada adicional de complexidade. Projetos de aprendizado de máquina (ML) em tempo real bem-sucedidos reconhecem os riscos e os minimizam quando necessário.

“Todos os projetos de aprendizado de máquina (ML) bem-sucedidos são parecidos; cada projeto de aprendizado de máquina (ML) fracassado foi malsucedido do seu próprio jeito”. – Leo Tolstoy, provavelmente

A Tabela 1 lista alguns dos modos de fracasso para projetos de aprendizado de máquina (ML) em tempo real. Alguns deles refletem problemas de falha de comunicação e alinhamento corporativo; alguns refletem problemas de modelagem, e outros estão relacionados a acidentes de engenharia e implementação. Muitos deles também são relevantes para projetos de aprendizado de máquina (ML) em lotes (ou seja, sem ser em tempo real).

Tabela 1: Lista não exaustiva de modos de fracasso para projetos de aprendizado de máquina (ML) em tempo real

Modo de fracasso/ Risco	Exemplo / Descrição
O desempenho do modelo não é bom o bastante	Um modelo de detecção de fraude tinha precisão tão baixa no momento do treinamento que não poderia ser usado devido a grandes taxas de falso-positivos.
O tempo de resposta do modelo é longo demais	Após o modelo ter sido instalado, a equipe percebeu que o tempo de resposta dele (buscar recursos e pontuar) é inaceitavelmente longo, então o modelo nunca foi usado.
O desempenho do modelo no momento da conclusão é diferente do momento de treinamento	O desempenho do modelo foi inesperadamente ruim na produção, então precisou ser descontinuado. Possíveis causas: distorção entre treinamento e exibição, deslocamento de dados (data drift) e vazamento de dados.
O caso de uso não suporta tomadas de decisões probabilísticas	Apesar de a precisão do modelo ser boa, o fluxo corporativo não suporta um resultado “provavelmente verdadeiro”, talvez devido a responsabilidades legais. Cada decisão do modelo precisa de confirmação humana, então uma solução totalmente baseada no modelo não é viável.
Os recursos escolhidos não estão disponíveis no momento da conclusão	Durante a implementação, a equipe descobriu que alguns recursos com os quais o modelo foi treinado não estão disponíveis em tempo real. Esses recursos tiveram que ser removidos, prejudicando severamente o desempenho do modelo e o inutilizando. Possíveis causas: distorção entre treinamento e exibição e vazamento de dados.
O modelo não é economicamente viável	O custo de treinamento, implementação e operação do modelo é tão alto que não vale os ganhos financeiros que seu uso traria.
Feature creep	Gastou-se tempo demais tentando otimizar o desempenho do modelo, e demorou tanto para entrar em produção que perdeu sua janela corporativa.

Agora veremos algumas etapas práticas que você, profissional de aprendizado de máquina (ML) ou gerente de projetos, pode realizar para resolver esses problemas. Elas não estão listadas em nenhuma ordem particular, e todas provaram-se úteis para nós no Nubank. 

Redução de riscos: Eduque os clientes onde possível

Riscos Resolvidos: Todos

Muitos ainda veem o aprendizado de máquina (ML) como “bruxaria” e possuem crenças irrealistas do que é possível fazer com isso. Você pode, e deve, ajudar os clientes a entender, ao menos superficialmente, como o aprendizado de máquina (ML) funciona para que possam calibrar suas expectativas em níveis mais realistas, e isso ajuda você a trabalhar

Pessoas de setores como bancos são mais acostumadas a trabalhar com modelos, mas nem lá seria inteligente presumir que entendem, mesmo em um nível superficial, o que é aprendizado de máquina (ML).

Aqui estão três pontos essenciais que todos os usuários não técnicos deveriam entender sobre aprendizado de máquina (ML):

• Modelos são probabilísticos. Eles podem ter bom desempenho na média, mas terão previsões individuais erradas. Às vezes muito erradas.
• Modelos precisam de uma camada de decisão. Tão importante quanto o próprio modelo é a lógica que decide o que fazer com uma determinada previsão do modelo. Às vezes isso é chamado de camada de política.
• Modelos declinam ao longo do tempo. Eles precisam de manutenção e monitoramento após serem enviados para produção. E eles eventualmente precisam ser treinados novamente.

Um bom jeito de ajudar os usuários finais a terem intuição sobre aprendizado de máquina (ML) é mostrar mapas de importância de recurso, como o mapa de enxame (beeswarm) visto abaixo na Figura 3. Isso motiva discussões interessantes com usuários não técnicos e os ajuda a entender como a pontuação de um modelo é calculada a partir de seus recursos.

Figura 3: Mapa de enxame de amostragem da biblioteca SHAP. Trabalhar com mapas de importância de recurso é um ótimo jeito de “ensinar” usuários não técnicos o básico de como um modelo funciona. Isso os ajuda a desenvolver intuição sobre o aprendizado de máquina (ML) e tornará a interação mais eficiente. O mapa de força também é útil para explicar uma única previsão. Fonte

Redução de riscos: Certifique-se de que os dados sejam bons

Riscos Resolvidos: O desempenho do modelo não é bom o bastante | O desempenho do modelo no momento da conclusão é diferente do momento de treinamento.

O ditado “entra lixo, sai lixo” engloba a essência do aprendizado de máquina (ML). É sua responsabilidade garantir que os dados sejam bons o bastante para fins de modelagem.

É seu trabalho, como profissional de aprendizado de máquina (ML), entender se os dados disponíveis são bons o bastante para modelagem, tanto no momento de treinamento quanto no momento da conclusão.

Como sempre, o aprendizado de máquina (ML) em tempo real adiciona uma dimensão a mais a esse problema, então você precisa se preocupar não apenas com os dados de treinamento (se são suficientes e possuem boa qualidade), mas também com a forma de recuperar os dados no momento da conclusão.

Sugerimos uma abordagem de redução de risco de três frontes: (a) fazer as perguntas corretas sobre os dados, (b) realizar análises de dados extensivas e (c) estabelecer uma relação com a equipe de dados em tempo real:

Faça as perguntas certas sobre os dados

No início do projeto, você deve fazer diversas perguntas sobre quais dados estão disponíveis e como identificá-los. Aqui estão algumas sugestões:

• Quantos dados temos? (Isto é, quantas fileiras, clientes e pontos de dados)

• Os dados são de quanto tempo atrás?
• Os dados de treinamento são semelhantes aos dados no momento da conclusão?
• Os dados antigos foram substituídos de alguma forma? Podemos nos certificar de que os dados antigos são “imutáveis” e que podemos voltar àquele momento quando treinarmos o modelo? 

Realize análises de dados extensivas

Quando você tem acesso aos dados, é preciso realizar rotinas de automação de design eletrônico (EDA) para verificar a qualidade dos dados, e você precisa conferir minuciosamente cada informação que recebeu sobre os dados para garantir que não haja decisões equivocadas.

Estabeleça uma relação com a equipe de dados em tempo real assim que possível

As equipes responsáveis por tornar os dados disponíveis em tempo real normalmente não são as mesmas responsáveis por dados “inertes”.

Descubra quem são essas pessoas e mantenha contato com elas para garantir que as informações com as quais você treinará o modelo também estejam disponíveis quando você precisar fazer previsões em tempo real. Certifique-se de que você entende a velocidade da busca de dados.

Redução de riscos: Entenda como as previsões do modelo serão usadas

Riscos Resolvidos: O desempenho do modelo não é bom o bastante | O tempo de resposta do modelo é longo demais | O caso de uso não suporta tomadas de decisões probabilísticas.

Imagine criar um modelo perfeitamente bom, com ótimo desempenho, só para vê-lo juntar poeira. O pior que pode acontecer com um projeto de aprendizado de máquina (ML) é produzir um modelo que nunca seja usado para tomar decisões corporativas.

Você precisa saber antecipadamente como as previsões do modelo serão usadas, e por quem. 

Um dos motivos disso é que a equipe de modelagem não dedicou tempo para entender com clareza como o modelo deve ser usado, e por quem. 

Uma parte essencial do entendimento do uso do modelo é discutir a camada de decisão: o código ou processo corporativo que receberá as previsões do modelo e decidirá qual ação tomar com base nas previsões. Falar sobre a camada de decisão força as equipes de modelagem e cliente a discutirem como exatamente as previsões do modelo serão usadas, e esclarecer qualquer confusão no processo.

A Figura 4 mostra um exemplo de como seria uma camada de decisão bem simples para um simples modelo de risco de crédito. 

Figura 4: Um sistema de concessão de crédito típico com uma camada de decisão simples. Uma “camada de decisão” para um modelo pode ser tão simples quanto uma única condição if/else com base na previsão do modelo.  Se a pontuação de risco estiver abaixo de algum limite, conceder o empréstimo, de outro modo, negue-o. 

Além da discussão da camada de decisão, quanto mais perguntas você fizer sobre o caso de uso do modelo, maior a chance de descobrir presunções implícitas que podem causar problemas posteriormente.

Algumas perguntas que você deve se fazer: 

• Engenharia
  • Qual equipe ou serviço usará o modelo?
  • Como o serviço de solicitação fará solicitações ao modelo? Chamadas de http? Chamadas de async?
  • Onde os recursos e as previsões do modelo serão salvos ou registrados?
  • Onde as verdadeiras metas serão salvas? (para que você possa monitorar o desempenho e treinar novamente o modelo depois)
  • Há restrições de tempo de resposta para o modelo?
• Empresa
  • Qual será o impacto na empresa se as previsões do modelo estiverem erradas?
    • Qual deve ser o “plano b” se o modelo parar de funcionar?
• Modelagem
  • Precisaremos explicar as decisões do modelo individualmente?
  • As previsões do modelo precisam ser probabilidades calibradas?
  • Precisaremos de um teste A/B para medir o impacto do modelo?

Redução de riscos: Realize um pré-mortem

Riscos Resolvidos: Todos

Um encontro pós-mortem acontece após um projeto fracassar. Seu objetivo é entender as causas do fracasso para que possam ser evitadas no futuro.

Um pré-mortem é semelhante, mas ocorre no início de um projeto. É uma reunião para expor ideias, e seu objetivo não é entender por que um projeto fracassou, e sim impedir que fracasse. Ele funciona com pessoas fingindo que o projeto fracassou e perguntando a elas: “por que fracassou?”. 

Um pré-mortem é uma reunião para expor ideias que ocorre no início do projeto. Ele tenta responder às perguntas: “Vamos fingir que o projeto fracassou. O que fez ele fracassar?”

Não há muitas regras sobre como a reunião deve ser conduzida, desde que ela ocorra. 

No fim de uma boa sessão pré-mortem, você deve ter não apenas um entendimento muito melhor dos riscos dos quais já estava ciente, mas também conhecimento dos riscos até agora desconhecidos que agora pode avaliar.

Por isso é importante que a reunião inclua pessoas com experiências diferentes, como especialistas em negócios, outros profissionais de aprendizado de máquina (ML) e, de máxima importância para projetos de aprendizado de máquina (ML) em tempo real, engenheiros de software, para sinalizarem potenciais problemas de integração e dados.

Redução de riscos: Calcule a estimativa do projeto

Riscos Resolvidos: O modelo não é economicamente viável

Cada projeto de aprendizado de máquina (ML) aplicado deve ter um impacto tangível na empresa. Tal impacto costuma ser medido em unidades monetárias (Dólar ou equivalente) ou outras métricas corporativas, como conversão e engajamento, entre outros.

Calcular a estimativa de um projeto significa entender o impacto do projeto em termos dessas métricas. Isso ajuda a reduzir os riscos do projeto porque você pode descobrir assim que possível se o projeto é economicamente viável e ajustar o curso se não for.

Os benefícios adicionais de calcular a estimativa de um projeto incluem ordenar por classificação quantitativamente os projetos e minimizar a influência indevida de políticas de poder (HiPPOs)

Se perguntando como calcular a estimativa? Sugerimos que isso seja feito em dois ciclos:

• Primeiro ciclo de estimativa (início do projeto)  Antes de qualquer modelagem ser feita, crie um valor aproximado da estimativa para ver se vale a pena seguir com o projeto.  Não há problema em fazer presunções sobre o desempenho do modelo. O objetivo é detectar ameaças existenciais ao projeto, como no exemplo abaixo:
  • Exemplo 1: De acordo com o primeiro valor, usar o modelo teria um saldo positivo, mesmo com sua precisão tão baixa quanto 20%. Faz sentido.
  • Exemplo 2: O modelo só faria sentido economicamente se seu desempenho estivesse acima de 99%. Arriscado demais, é melhor abortar.
• Segundo ciclo de estimativa (definição da camada de decisão): Durante o estágio de definição da camada de decisão (veja a Figura 2), devemos ter o conjunto de teste do modelo, que é um bom comparativo para avaliar o desempenho do modelo no momento da conclusão. Com o conjunto de teste é possível atualizar a estimativa produzida no primeiro ciclo.
  • Example 2: Com o conjunto de teste, as projeções indicam um aumento de 50% nas conversões de e-mail, resultando em mais 1 milhão de dólares anualmente. Portanto, o projeto está economicamente justificado.
  • Exemplo 2: Com o conjunto de teste, agora estimamos um lucro total de 50 mil dólares em um ano. Mas a compensação da equipe sozinha é mais de 100 mil dólares naquele período. Não faz sentido economicamente seguir com o projeto, pois seu custo é maior que os benefícios.

Redução de riscos: Selecione recursos com base na importância e no esforço de implementação

Riscos Resolvidos: Feature creep | Os recursos escolhidos não estão disponíveis no momento da conclusão

Em modelos de lote (ou seja, sem ser tempo real), os recursos são mais ou menos iguais em termos do esforço necessário para implementá-los. Claro, alguns podem precisar de um pouco mais de consulta de SQL envolvida, alguns joins extras, mas raramente é mais que isso.

Entretanto, recursos em tempo real variam muito em termos do esforço de engenharia necessário. Alguns recursos podem ser buscados com uma simples chamada de HTTP no momento da conclusão. Outros podem precisar que você crie um serviço e um ponto final para que o modelo possa usar no momento da conclusão.

Em projetos de aprendizado de máquina (ML) em tempo real, é preciso levar o esforço de implementação em consideração quando selecionar recursos.

Durante a seleção de recurso você também precisa levar em consideração o trabalho necessário para implementar um determinado recurso, presumindo que esteja disponível na infraestrutura em tempo real! Na Figura 5 abaixo, vemos uma classificação de recursos de 4 maneiras, dependendo das duas dimensões relevantes para selecionar recursos: poder preditivo e esforço de implementação.

Figura 5: Nem todos os recursos no aprendizado de máquina (ML) em tempo real nascem iguais: Além de ponderar a importância de um recurso (por exemplo, SHAP), também precisamos levar em consideração o esforço de engenharia necessário para usar um determinado recurso no momento da conclusão. Os recursos com maior custo-benefício são os que possuem grande poder preditivo, embora sejam simples do ponto de vista da implementação (canto superior esquerdo). 

Quanto à classificação de recursos em termos de esforço de implementação, sugerimos começar com as questões na Tabela 2. Como de costume, os recursos mais fáceis são os disponíveis em um feature store (com o benefício extra de não precisar se preocupar com distorção entre treinamento e exibição).

Tabela 2: A facilidade de implementação para recursos em tempo real, presumindo uma arquitetura de microsserviços síncrona.

Descrição	Esforço de implementação
O recurso está prontamente disponível em um feature store	BAIXO
O recurso não está em um feature store, mas já está em uso por outro modelo, então pode ser facilmente reaproveitado.	BAIXO
O recurso está prontamente disponível em um ponto final HTTP externo	BAIXO
O recurso está disponível através de um único ponto final HTTP, mas precisa de certo pré-processamento.	BAIXO / MÉDIO
O recurso precisa de informações de diversos pontos finais HTTP.	MÉDIO
O recurso existe em uma base de dados de produção, mas precisamos criar um ponto final para buscá-lo.	MÉDIO
O recurso existe em uma base de dados de produção que não é acessível. Um novo serviço precisa ser criado para acessá-la.	GRANDE
Não está claro como acessar o recurso no momento da conclusão, se for possível. É preciso descobrir mais para avaliar o problema.	GRANDE + PRECISA DE MAIS DESCOBERTA

Quando um conjunto razoável de recursos estiver decidido, a liderança do projeto deve declarar um congelamento de recursos, para que apenas os selecionados sejam incluídos no projeto. Isso reduz o risco de feature creep, uma situação em que novos recursos continuam sendo adicionados ao modelo e o projeto nunca termina.

Redução de riscos: Resolvendo primeiro os recursos de maior risco

Riscos Resolvidos:  O desempenho do modelo no momento da conclusão é diferente do momento de treinamento | Os recursos escolhidos não estão disponíveis no momento da conclusão | O desempenho do modelo não é bom o bastante

Se você seguir a máxima “selecione recursos com base no esforço”, terá uma estimativa aproximada do esforço de engenharia necessário para implementar cada recurso. Entretanto, as estimativas de esforço de engenharia costumam ser imprecisas e difíceis de acertar, semelhante a bruxaria.

Normalmente (mas nem sempre), os recursos que exigem maior esforço também serão os mais arriscados de implementar. “Arriscados” quer dizer que podem comprometer o sucesso do projeto.

Comece a implementação com eles para resolver logo esse risco. Em outras palavras, a implementação rápida de recursos arriscados à esquerda na linha temporal do projeto.

A resolução das partes mais incertas de um projeto primeiro, para expor logo os riscos ocultos, às vezes é chamada de estratégia “shift-left” (deslocar para a esquerda).

Por quê? Porque deslocar essas tarefas arriscadas para a esquerda possibilita que potenciais estraga-prazeres sejam descobertos cedo: Pontos finais externos que são lentos demais para suas necessidades. Serviços que não conseguem lidar com a dimensão das solicitações feitas. Recursos que ficaram completamente indisponíveis.

Quanto mais cedo a equipe de modelagem estiver ciente de problemas de recurso, mais cedo podem se adaptar, usando representações ou até abandonando-os de vez.

Descobrir estraga-prazeres no início do projeto ajuda a prevenir o pior modo de fracasso possível: descobrir que o projeto fracassou depois de muito esforço já ter sido aplicado a ele.

Assim que os recursos tiverem sido escolhidos, você pode começar a trabalhar na descoberta de implementação (exposição de ideias, desenvolver estratégias de implementação, discutir com outros engenheiros etc.). Quanto antes melhor.

Deslocar o risco para a esquerda é um bom conselho em todas as partes de qualquer projeto, especialmente durante a implementação de recurso em aprendizado de máquina (ML) em tempo real, devido às mudanças em cascata que ativarão novas rodadas de modelagem e adaptação da camada de decisão (veja a Figura 2).

Redução de riscos: Instale o modelo no modo sombra assim que possível 

Riscos Resolvidos: O tempo de resposta do modelo é longo demais | O desempenho do modelo no momento da conclusão é diferente do momento de treinamento | Os recursos escolhidos não estão disponíveis no momento da conclusão  

A última parte da implementação, onde você conecta o serviço de solicitação ao modelo em tempo real, é a parte mais arriscada do projeto da perspectiva da engenharia. Muitos imprevistos acontecem na hora de conectar serviços regulares a modelos de aprendizado de máquina (ML) em tempo real.

Mas não precisa ser assim. Adotando uma instalações em modo sombra desde o princípio, é possível simular um fluxo de ponta a ponta sem esperar a culminação do projeto.

Modo sombra – instalação padrão com uma surpresa: os resultados do modelo são ignorados pelos serviços de solicitação.

Instalação em modo sombra é o nome de um padrão de aprendizado de máquina (ML) aplicado através do qual você implementa um modelo de aprendizado de máquina (ML) em tempo real, mas ignora a resposta no último instante, por exemplo, usando um feature flag. Instalações em modo sombra são ótimas para redução de riscos em projetos porque possibilita a observação do funcionamento do modelo em um cenário de “vida real” sem exposição a nenhum risco corporativo. A Figura 6 fornece uma representação visual.

Figura 6: Instalação Regular x Em Modo Sombra de modelos de aprendizado de máquina (ML) em tempo real: Tudo é igual, exceto pelo fato de que as pontuações do modelo são descartadas, e o serviço de solicitação segue como se nada tivesse acontecido. Uma instalação em modo sombra reduz os riscos de um projeto porque possibilita a detecção de muitos problemas no momento da produção como desempenho sob carga, integração com serviços de recurso, problemas com o esboço etc. 

Instalar um modelo no modo sombra é útil por si só. Mas fazer isso no início do projeto, ou até antes de todos os recursos serem implementados, é melhor ainda.

• O código de busca de recurso e o modelo passarão por testes de estresse sob circunstâncias de produção, expondo problemas de tempo de resposta e outros conforme forem implementados.
• Tarefas de monitoramento são desbloqueadas quando se tem uma instalação em modo sombra. Mesmo se o modelo não estiver em uso, é possível criar a infraestrutura de monitoramento (funções de registro, painéis, relatórios etc.).

A Figura 7 abaixo mostra que: habilitando o modo sombra no início reduz os riscos do projeto e o deixa mais eficiente.

Figura 7: Quanto antes você habilitar o modo sombra, melhor: Instalar um novo modelo em modo sombra logo no início reduz os riscos do projeto e o deixa mais eficiente devido a oportunidades de paralelização. Evidentemente, as pontuações do modelo não serão úteis se a maioria dos recursos for NULL. Você conseguirá expor riscos de engenharia assim que possível, e poderá configurar o monitoramento imediatamente. 

Claro, o modo sombra pode exigir trabalho de configuração antecipado, mas vira o jogo para projetos de aprendizado de máquina (ML), garantindo interações mais tranquilas e seguras do modelo em tempo real.

Conclusão

A verdade é que aprendizado de máquina (ML) em tempo real é difícil porque envolve modelos de aprendizado de máquina (ML) e serviços em tempo real, ambos sendo um sistema complexo que depende de diversas partes que precisam funcionar perfeitamente. 

Listamos muitos dos modos de fracasso de aprendizado de máquina (ML) em tempo real, mas observe que muitos deles estão relacionados ao aprendizado de máquina (ML) em geral, com algumas particularidades para a configuração de tempo real.

Também sugerimos diversas práticas para ajudar a evitar esses modos de fracasso. Entretanto, mesmo quando seguir todas elas, ainda é possível que o projeto fracasse, a vida é assim mesmo, mas as chances de sucesso serão maiores.
E lembre-se, tudo nesta postagem é relacionado a tirar o modelo do papel. Depois disso, ainda é um caminho difícil para continuar operando. Após a primeira instalação, você precisará monitorar cuidadosamente (especialmente distorção entre treinamento e exibição) e criar alertas para garantir que tudo funcione bem.