Como lidar com Distorção entre Treinamento e Exibição em Modelos de Aprendizado de Máquina (ML) em tempo real: Um Breve Guia

Escrito por Felipe Almeida
Revisado por Tiago Magalhães

---

Nesta postagem explicaremos o que é “treinamento e exibição” e por que precisamos entender isso quando trabalhamos com modelos de aprendizado de máquina em tempo real. 

Daremos exemplos de como monitorar e depurar incompatibilidades de treinamento e exibição, além das lições que aprendemos ao longo dos anos aplicando aprendizado de máquina (ML) em tempo real a problemas corporativos no Nubank.

O que é distorção entre treinamento e exibição?

Para entender a distorção entre treinamento e exibição é preciso lembrar que modelos de aprendizado de máquina (ML) em tempo real são treinados em um ambiente diferente daquele no qual são usados (exibidos). Além disso, esses modelos normalmente são treinados e produzidos por pessoas diferentes.

Normalmente, o treino é feito em um ambiente analítico (cadernos interativos ou datalakes, por exemplo), mas a exibição acontece no ambiente de produção (microsserviços, dispositivos periféricos etc.). Isso é mostrado na Figura 1 abaixo:

Figura 1: O treinamento de modelos de aprendizado de máquina (ML) normalmente acontece em um ambiente analítico (tabelas de bases de dados, cadernos etc.), enquanto o uso de modelos ocorre no ambiente de produção (serviços em tempo real, dispositivos periféricos, APIs etc.). Diferenças inesperadas entre eles causam a distorção entre treinamento e exibição.

Tudo no Aprendizado de Máquina (ML) depende de uma premissa muito importante: o treinamento definido precisa refletir os dados reais que o modelo pontuará na hora da exibição.

Distorção entre treinamento e exibição refere-se à situação em que a simetria entre os ambientes de treinamento e exibição está quebrada devido a problemas operacionais ou a uma lógica incorreta. Em outras palavras, temos distorção quando há diferenças entre o jeito com que o modelo foi treinado e o jeito com que ele é exibido. 

Distorção entre treinamento e exibição refere-se às diferenças entre o ambiente em que um modelo é treinado e onde é exibido (ou usado).

Alguns exemplos de distorção entre treinamento e exibição são:

• Filtros de data diferentes: um cientista de dados codificou um recurso que conta a quantidade de compras que um cliente fez nos últimos 30 dias. A implementação do tempo de exibição foi codificado incorretamente: apenas os últimos 15 dias estão sendo contados.
• Null x Zeros: na hora do treinamento, escolhemos usar NULL para representar quando um recurso está ausente para algum cliente. Entretanto, os sistemas em tempo real usam 0 (zero) para sinalizar dados ausentes.
• Fontes de dados diferentes: na hora do treinamento, montamos um recurso categórico usando dados de imagem instantânea estática obtidos de um fornecedor de dados terceirizado. Na hora da exibição, recuperamos valores do recurso de um API e notamos que não são exatamente iguais.

É possível acessar mais exemplos na seção “Entenda o tipo de incompatibilidade” deste artigo.

Conheça nossas oportunidades

Por que se importar com a distorção entre treinamento e exibição?

Precisamos consertar (ou ao menos estar cientes) da distorção entre treinamento e exibição porque isso pode ter impactos severos nas previsões de um modelo e, consequentemente, nos processos corporativos que dependem delas.

Um exemplo claro está na concessão de crédito: os bancos normalmente usam modelos de risco de crédito em tempo real para decidir quem pode receber um empréstimo. Distorções entre treinamento e exibição não detectadas podem fazer com que clientes de alto risco recebam empréstimos quando não deveriam, causando perdas financeiras aos bancos, sem falar na possível falha sistêmica do sistema do banco.

Por que acontecem distorções entre treinamento e exibição?

O principal motivo da ocorrência de distorções entre treinamento e exibição é falha de comunicação durante a fase de pré-instalação de um modelo. 

Modelos em tempo real normalmente são treinados e instalados por pessoas diferentes (cientistas de dados e engenheiros de aprendizado de máquina, respectivamente), então erros de comunicação são frequentes, e o que é implementado, ou exibido, não é o mesmo que foi treinado.

A distorção entre treinamento e exibição é causada por falha de comunicação entre as equipes de modelagem e engenharia ou por mudanças inesperadas em serviços usados para buscar recursos.

Porém, mesmo após um modelo estar em operação há algum tempo, novas incompatibilidades de treinamento e exibição podem aparecer. Isso se deve a mudanças ou erros nas fases iniciais quando buscar recursos em tempo real. 

Empresas modernas operam em uma arquitetura de microsserviços, então modelos de tempo real precisam de informações de outros serviços, possuídos por outras equipes, e esses serviços podem mudar ou quebrar sem aviso, afetando os recursos usados no modelo.

Quais tipos de distorção existem?

Na nossa experiência, há dois tipos diferentes de distorção entre treinamento e exibição, dependendo do estágio do ciclo de vida em que acontecem.

• Distorções pré-instalação acontecem quando há erros assim que o modelo é enviado para a produção;
• Distorções pós-instalação podem ocorrer a qualquer momento durante a operação do modelo devido a mudanças inesperadas ou defeitos em serviços nas fases iniciais onde os recursos são buscados.

Isso pode ser visto abaixo, na Figura 2:

Figura 2: Ciclo de vida do Modelo de Aprendizado de Máquina (ML) Simplificado A primeira instalação precisa de uma verificação de distorção entre treinamento e exibição para garantir que os recursos do modelo estejam implementados corretamente. Após ser devidamente instalado, ainda precisamos monitorar, detectar e possivelmente consertar quaisquer incompatibilidades à medida que aparecerem.

Nas seções a seguir, veremos algumas estratégias para evitar ou minimizar os efeitos da distorção entre treinamento e exibição nos nossos modelos em tempo real no Nubank.

Evitando e minimizando distorções entre treinamento e exibição

A distorção entre treinamento e exibição nunca será totalmente eliminada. Sempre haverá casos em que um recurso em tempo real quebrará devido a defeitos temporários em serviços de apoio, por exemplo. Alguns casos de recursos ruins aqui e ali não devem causar problemas, especialmente se você usar classificadores robustos como modelos baseados em árvore.

Os casos dos quais queremos nos proteger são aqueles em que grande parte das previsões do modelo é afetada por recursos ruins, pois eles podem ter impactos severos em processos corporativos que usem previsões de modelos.

Para evitar ou minimizar a distorção entre treinamento e exibição, você precisa primeiramente coletar dados de recurso de ambos os trajetos de dados (treinamento e exibição). Cobrimos este artigo em Pré-requisitos: Coleta de dados.

Quando os dados de recurso estiverem sendo coletados em ambos os trajetos de dados, a tarefa de resolver a distorção é reduzida a:

• comparar e monitorar valores do recurso;
• detectar incompatibilidades; 
• depurar e resolver problemas quando necessário.

Em uma arquitetura de microsserviços, modelos em tempo real são apenas mais um serviço. Os modelos dependem de serviços de etapas iniciais para dados de recurso, mas é impossível controlar o que as outras equipes farão, e nem deveríamos, pois isso prejudicaria a autonomia e agilidade delas. 

É por isso que acreditamos que monitorar é o único jeito dimensionável de se defender contra distorção entre treinamento e exibição para que você possa detectar e reagir aos problemas sem virar um gargalo para as outras equipes.

Usar um armazenamento de recursos também ajuda a evitar distorção entre treinamento e exibição. Armazenamentos de recursos costumam ser operados por uma equipe centralizada, liberando a equipe de modelagem de precisar cuidar do problema. Se puder, use um armazenamento de recursos.

Nas próximas subseções, veremos a abordagem completa de como lidar com distorção entre treinamento e exibição no Nubank: falaremos sobre os pré-requisitos (certificando-nos de que você esteja coletando os dados necessários), e então cobriremos o que e como monitorar a distorção entre treinamento e exibição, como interpretá-la para detectar incompatibilidades e, por fim, cobriremos algumas estratégias para de fato depurar e consertar os problemas.

Pré-requisitos: coleta de dados

Para comparar dados dos dois trajetos de dados diferentes, primeiro você precisa se certificar de que está coletando aqueles dados.

Isso significa que você precisa de (a) uma forma programática de gerar dados de treinamento sob demanda e (b) gravar ou registrar recursos usados para cada execução em tempo real do modelo.

Para resolver a questão (a), você precisa de uma forma programática de gerar dados de treinamento para datas arbitrárias que seja possível repetir. Você precisa de algum tipo de função ou rotina que pegue um par de dados e produza os dados de treinamento para aquele período. Veja a Figura 3 para ter um exemplo:

Figura 3: Geração de dados de treinamento programáticos para um determinado período é essencial para conseguir lidar com a distorção entre treinamento e exibição, por que é a eles que compararemos os dados de exibição. Observe que não precisamos incluir a variável-alvo nos dados, apenas os recursos.

Na questão (b) (gravar dados de recurso da execução em tempo real), você precisa de algum jeito de registrar o identificador de pontuação (ID) e os recursos usados no momento da exibição. Isso pode ser feito facilmente salvando dados de recurso em uma base de dados ou a um serviço de registro como o Splunk.

Quando as questões (a) e (b) tiverem resolvidas, detectar a distorção entre treinamento e exibição é muito mais fácil, basta usar join nos recursos para uma determinada instância e compará-los. Isso é mostrado na Figura 4, na próxima seção.

Monitorando incompatibilidades de treinamento e exibição

Conforme explicado acima, você precisa tanto de dados de treinamento quanto de exibição para monitorar distorções entre treinamento e exibição. Quando você tiver uma forma robusta de gerá-los continuamente, é uma simples questão de usar qualquer ferramenta de painel para visualizar os dados.

O monitoramento pode ser usado tanto no estágio de pré-instalação quanto de pós-instalação. É possível monitorar um modelo antes de ser usado tendo uma instalação do chamado modo sombra: instalar um modelo em tempo real, mas ignorar suas previsões.

É possível monitorar recursos em uso por um modelo em tempo real antes mesmo da produção: instalar o modelo no modo sombra é um padrão comum.

Você pode gerar dados de monitoramento assim: pegue dados do momento do treinamento e do momento de exibição e aplique join, usando o ID da instância como a chave do join. Isso é mostrado abaixo na Figura 4:

Figura 4: Montando um conjunto de dados de monitoramento a partir de dados de treinamento e exibição: quando tiver dados de ambos os trajetos, você pode simplesmente agrupá-los e montar um conjunto de dados temporário com ambos os valores para cada recurso. No exemplo mostrado, temos uma incompatibilidade para o recurso x: seu valor deveria ser 5.0, mas recebemos 10.0.

Quando tiver um conjunto de dados de monitoramento como o mostrado na Figura 4, você pode avançar para o monitoramento de fato, como explicamos abaixo.

Tipos de monitoramento de distorção entre treinamento e exibição

Só precisamos do chamado “conjunto de dados de monitoramento” para gerar todos os mapas de monitoramento mostrados nas próximas seções.

Apesar de poder haver outras formas de visualizar a distorção entre treinamento e exibição, cobriremos as que achamos mais importantes e usamos no nosso trabalho cotidiano.

• Porcentagem de correspondências exatas;
• diferenças médias em valores de recursos;
• diferenças percentuais em valores de recursos.

Cada um desses itens cumpre uma função em ajudar os profissionais a manterem os sistemas de aprendizado de máquina (ML) saudáveis. Explicaremos cada um deles em detalhes nas próximas subseções.

Porcentagem de correspondências exatas por dia e por recurso

Você pode monitorar a distorção entre treinamento e exibição mapeando a porcentagem de correspondências exatas, por recurso e ao longo do tempo.

Na Figura 5 abaixo, podemos ver um desses mapas para o “Recurso X”. No eixo Y, temos as porcentagens de correspondências exatas, e, no eixo X, a data. 

É fácil ver que tínhamos cerca de 90% de taxa de correspondência no dia 2 de janeiro de 2022 e cerca de 60% no dia 5 de janeiro de 2022. Isso significa que 10% e 40%, respectivamente, das instâncias pontuadas tinham valores errados para o Recurso X no momento da exibição.

Figura 5: Mapeando a porcentagem de correspondências exatas para um recurso por dia. É muito fácil ver que havia um pequeno problema em 02/01/2022 e um grande problema em 5/1/2022. Um painel de monitoramento deve incluir diversos mapas como este, um para cada recurso em um modelo.

Repare que este mapa não dá informações sobre a magnitude das diferenças. Continue lendo para saber o que fazer em seguida.

Diferença média entre treinamento e exibição por recurso

Monitorar a porcentagem de correspondências exatas (como acima) é um bom começo, mas não é suficiente. Você precisa entender a magnitude da incompatibilidade para saber a seriedade dela e se precisa investigar mais.

Você pode mapear a diferença entre os valores dos recursos no momento do treinamento e no momento da exibição, como é possível ver no exemplo abaixo.

Figura 6: Mapear a diferença média numérica entre os valores no momento do treinamento e no momento de exibição para um determinado recurso. Podemos ver que a magnitude da distorção no dia 2/1/2022 é muito maior que no dia 5/1/2022. A magnitude da distorção (junto da porcentagem de correspondência exata, conforme visto na Figura 5) informará você sobre a urgência do problema.

Olhar as médias das diferenças, em vez das porcentagens de correspondência simples, é um grande passo adiante, mas as médias podem enganar e levar você a conclusões equivocadas.

Percentuais das diferenças entre treinamento e exibição por recurso

Se já estiver monitorando a taxa de correspondências exatas e a magnitude média, você tem um bom nível de proteção contra distorção entre treinamento e exibição. Mas discrepâncias e outros valores extremos podem ter enganado você, já que possuem um grande impacto nas médias: uma ou duas discrepâncias podem afetar muito o valor médio.

Entender o comportamento dos recursos nos extremos (P99) é importante para casos em que há interesse apenas nos maiores valores das previsões, como em concessões de crédito, detecção de fraudes etc.

Como proteção contra as discrepâncias, podemos monitorar as diferenças percentuais entre valores de recurso no momento do treinamento e no momento de exibição, como visto na Figura 7 abaixo. A distorção no dia 2/1/2022 parece ter sido unicamente nos percentuais maiores: dificilmente teve impacto em percentuais menores. A distorção no dia 5/1/2022 afetou todos os percentuais de modo relativamente igual.

Figura 7: Mapeando os percentuais das diferenças numéricas entre os valores no momento do treinamento e no momento de exibição para um determinado recurso. Incompatibilidades afetando apenas os maiores percentuais (como em 2/1/2022) podem indicar algumas pontuações ruins devido a problemas temporários, mas não problemas propagados. Incompatibilidades que afetam todos os percentuais (como em 5/1/2022) normalmente indicam distorção baseada em lógica e podem ser mais sérias.

Vimos como monitorar adequadamente as incompatibilidades de recurso; agora veremos como interpretar esses mapas para detectar quando tivermos distorção entre treinamento e exibição.

Detectando quando a distorção ocorre

Na nossa experiência, a maioria das incompatibilidades pós-instalação acontecem devido a mudanças nos estágios iniciais de serviços dos quais buscamos recursos em tempo real. Isso presume que você esteja trabalhando em uma arquitetura de microsserviços.

A distorção entre treinamento e exibição pós-instalação normalmente aparece como uma mudança súbita e constante nos mapas de monitoramento. Veja um exemplo na Figura 8.

Figura 8: Mapa de amostragem mostrando um recurso “quebrado”. Uma queda súbita que não volta aos níveis normais é um sinal claro de que algo fundamental mudou.

E como detectamos distorção pré-instalação? Precisamos monitorar apenas os dados de uma instalação em modo sombra, conforme explicado na seção Monitorando incompatibilidades de treinamento e exibição.

Entenda a magnitude da incompatibilidade

Para saber a seriedade das incompatibilidades, temos que ver os mapas que mostram as diferenças nos valores do recurso. Você provavelmente não se dará ao trabalho de investigar cada incompatibilidade, especialmente quando a magnitude for pequena, já que provavelmente teria pouco impacto na previsão do modelo e, por extensão, no negócio.

Considere o impacto da incompatibilidade do recurso no negócio

Mesmo se você tiver um recurso com muita distorção, há casos em que você preferirá não investigá-la se o impacto no negócio for pequeno. Isso pode acontecer, por exemplo, em casos em que a distorção está presente em um recurso pouco importante, então não está causando nenhum impacto real no negócio.

Podemos pensar em duas formas de medir o impacto de recursos distorcidos no negócio:

• Monitorar a distorção também na previsão, para ver se as distorções de recurso também causaram uma distorção na previsão do modelo. Por exemplo: as distorções de recurso deixam a previsão do modelo equivocadamente maior ou menor do que deveria ser?
• Monitore decisões corporativas tomadas usando o modelo. Isso é o que chamamos de monitoramento da camada de decisão. Se isso indicar um problema nos mesmos dias em que você teve distorção, é provável que a distorção esteja impactando decisões corporativas em estágios posteriores, então é mais séria.

Depurando e resolvendo problemas

Então você detectou que seu modelo realmente está sofrendo de distorção entre treinamento e exibição, entendeu a magnitude da incompatibilidade e viu que está tendo um impacto no negócio suficiente para justificar o foco nisso. Agora você precisa depurar e consertar a incompatibilidade.

A detecção de distorção entre treinamento e exibição pode ser feita olhando painéis e mapas. Entretanto, quando depurar, você precisa acessar os dados de comparação brutos para entender a natureza da distorção.

Depurar e consertar incompatibilidades de treinamento e exibição envolve comparar valores de recurso usados nos momentos de treinamento e exibição para instâncias individuais, por isso sugerimos que você crie um conjunto de dados de monitoramento onde possa ver os valores de recurso para ambos os trajetos de dados.

Como mencionado anteriormente, coletar dados é um pré-requisito para lidar com distorção entre treinamento e exibição: se você não coletar dados de treinamento e exibição, não será possível monitorar ou consertar incompatibilidades de treinamento e exibição.

Na Figura 9 é possível ver outro exemplo de como um “conjunto de dados de monitoramento” deve ser para um modelo em tempo real com 3 recursos: “A”, “B” e “C”.

Figura 9: A depuração de incompatibilidades de treinamento e exibição normalmente exige que você analise o “conjunto de dados de monitoramento” bruto e compare valores de recurso de ambos os trajetos de dados. O conjunto de dados de monitoramento é apenas um agrupamento de dados de recurso nos momentos de treinamento e exibição. 

Agora veremos como priorizar as investigações e exemplos de tipos comuns de incompatibilidades. 

Concentre-se primeiro em recursos de alta importância

Se você tiver que lidar com incompatibilidades em muitos recursos,  precisará escolher em quais se concentrar primeiro, especialmente quando se trata de distorção pré-instalação. É comum ter diversos recursos distorcidos quando instala seu modelo em tempo real (de preferência, no modo sombra para que não haja danos!).

Use a importância de recurso (por exemplo, valores SHAP) para decidir quais recursos investigar primeiro.

Entenda o tipo de incompatibilidade 

Agora listaremos os tipos comuns de incompatibilidades, além dos motivos e reparos mais comuns.

Eles estão explicados nas próximas subseções e resumidos na tabela abaixo:

Tipo de incompatibilidade	Quando costuma ocorrer	Possíveis reparos
Valores Null no momento de exibição	Pré-instalação e pós-instalação	Depende do motivo. Pode precisar de reparo ou novo treinamento do modelo se for devido a vazamento de dados.
Null x Valores 0	Normalmente pré-instalação	Depuração e reparo da lógica de recurso no momento de exibição (normalmente adicionando um fillna(0))
O valor no momento de exibição normalmente é maior	Pré-instalação e pós-instalação	Depuração e reparo da lógica de recurso no momento de exibição
O valor no momento de exibição normalmente é menor	Pré-instalação e pós-instalação	Depuração e reparo da lógica de recurso no momento de exibição
Exemplos não sendo pontuados no momento de exibição	Pré-instalação e pós-instalação	Depende do motivo

Valores Null no momento de exibição

Você presumiu (no momento de treinamento) que alguma informação estaria disponível no momento da conclusão, mas quando instalou o modelo em tempo real, todos os valores de recurso estão NULL. 

Isso pode ser uma forma de vazamento de dados: você usou informações futuras para montar recursos. Se isso acontecer, você verá valores NULL no momento da conclusão, embora tivesse valores que não eram null durante o treinamento. Pode ser necessário remover esses recursos e treinar o modelo novamente. Veja um exemplo abaixo na Figura 10:

Figura 10: Se você tiver apenas valores NULL para um recurso no momento de exibição, isso pode significar que houve vazamento de dados durante o treinamento. Se for o caso, pode ser necessário abandonar esse recurso e treinar o modelo novamente.

Você só deve suspeitar de vazamento de dados se todos os valores para um recurso forem NULL no momento de exibição; se apenas alguns valores forem NULL, o problema pode ser causado por exceções no tempo de execução ou esgotamentos de tempo.

Null x Valores 0

É comum que valores NULL sejam misturados com 0 (zero) durante a implementação do recurso. Isso acontece com recursos baseados em contagens, somas e médias. Um reparo comum é usar fillna(0) para substituir NULLs por zeros.

Exemplo: O modelo foi criado com um pacote R, que representa os tamanhos das listas vazias como NULL. Mas no momento de exibição, os recursos são buscados com código Java, e as semânticas podem ser diferentes: contagens de listas vazias são representadas como 0 (zero) em vez de NULL. Veja a Figura 11 abaixo:

Figura 11: Este é um exemplo clássico de distorção de Null x 0; repare que só temos incompatibilidades nos exemplos onde o valor real do recurso é 0. Não houve incompatibilidades de treinamento e exibição nos outros casos.

O valor no momento de exibição normalmente é maior

Quando os valores para um recurso são consistentemente maiores do que deveriam, provavelmente temos um erro nos filtros e/ou nas faixas de datas usados no momento de exibição. Veja a Figura 12 abaixo.

Exemplo: Um dos recursos em um modelo de fraude é a quantidade de compras em cartão de crédito liquidadas que um cliente fez no mês anterior. Entretanto, o recurso foi implementado erroneamente no momento de exibição: em vez disso, ele está usando todas as compras (liquidadas ou de outra forma), então os números às vezes estão maiores do que deveriam.

Figura 12: Quando valores de recurso estão consistentemente maiores do que deveriam, isso pode indicar que a implementação de recurso no momento de exibição está usando filtros excessivamente vagos e incluindo mais informações do que deveria.

O valor no momento de exibição normalmente é menor

Isso é análogo ao tipo de incompatibilidade anterior, com valores menores que o esperado, em vez de maiores. Veja a Figura 13 abaixo para saber como seria.

Exemplo: Um modelo de pontuação de crédito em tempo real tem um recurso chamado “num_transfers_last_day“, que contém a quantidade de transferências que um cliente fez nas últimas 24 horas. Entretanto, o engenheiro encarregado de implementá-lo no momento de exibição achou que isso significava a quantidade de transferências no dia atual (isto é, começando à 0h até o presente momento).

Figura 13: Neste caso, vemos que muitas instâncias possuem valores inferiores aos que deveriam. Novamente, isso pode ser devido a um filtro implementado equivocadamente, erros com diferença de um etc.

Exemplos não sendo pontuados no momento de exibição

Às vezes, modelos em tempo real acabam pontuando distribuições de evento que não existiam nos dados de treinamento. Isso é perigoso porque não podemos confiar nas previsões dadas para amostras de instâncias de uma distribuição diferente daquela com a qual o modelo foi treinado.

Exemplo 1: Um banco treinou um modelo para pontuar o risco de crédito padrão para o primeiro empréstimo na vida de um cliente. Entretanto, os engenheiros equivocadamente instalaram o modelo para pontuar também empréstimos subsequentes.

Exemplo 2: Um modelo de fraude foi treinado para detectar tentativas de fraude nas compras em cartão de crédito feitas on-line. Entretanto, uma equipe de engenharia equivocadamente instalou o modelo para pontuar também compras em pessoa.

Este tipo de distorção é diferente das anteriores porque não se refere a incompatibilidades de recurso, mas a casos em que o exemplo inteiro não devia ter sido pontuado. Na Figura 14, vemos como esse tipo de problema apareceria nos conjuntos de dados de monitoramento: todos os valores de recurso do trajeto de dados de treinamento serão NULL.

Figura 14: Aqui vemos um caso em que dois exemplos (IDs 0004 e 0005) foram pontuados pelo modelo em tempo real, mas não apareceram no conjunto de dados de treinamento gerado programaticamente. É muito importante usar um OUTER join para agrupar ambos os conjuntos de dados para que os exemplos em qualquer trajeto de dados apareçam no conjunto de dados de monitoramento.

Observe que isso é diferente de desvio de dados (data drift): a distribuição não mudou apenas pela passagem do tempo, mas devido a diferenças na maneira como o modelo é usado.

Dicas gerais

Aqui estão algumas outras dicas e sugestões gerais que podem ajudar você a lidar com distorção entre treinamento e exibição.

Se puder, use um armazenamento de recursos

Com um armazenamento de recursos, a tarefa de calcular recursos é delegada para um sistema especializado.

Armazenamentos de recursos modernos suportam cálculos de lote e em tempo real, evidenciando a necessidade de se preocupar com distorção entre treinamento e exibição. Tais sistemas normalmente suportam semântica de “escrita uma vez” (write-once) para que os recursos sejam definidos em uma camada de abstração superior, em vez de serem recodificados em sistemas de produção.

Diferenças na precisão do ponto de flutuação

Às vezes os dados de treinamento e exibição são diferentes por apenas algumas casas decimais.

Uma das situações em que isso acontece é quando você usa tecnologias diferentes (por exemplo, Python e Java) para criar recursos de momento de treinamento e momento de exibição. Pode acontecer de a precisão de flutuação ser diferente em ambos, e você acabará com incompatibilidades como as mostradas abaixo na Figura 15:

Figura 15: Diferenças na precisão do ponto de flutuação como as mostradas normalmente não são indicativas de um problema real: elas refletem como diferentes tecnologias lidam com números do ponto de flutuação

Essas pequenas diferenças normalmente não contam como incompatibilidades reais, pois normalmente não afetam os resultados do modelo. Aplique uma margem de folga quando comparar valores do ponto de flutuação para evitar perder tempo com isso.

Nomeie os recursos com precisão

Nomes de recursos bem escritos ajudam a evitar desentendimentos entre as equipes de modelagem e engenharia. A tabela abaixo mostra exemplos de nomes de recurso bons e ruins.

BOM	RUIM	Motivo
num_transf_ult_24h	num_transf_ult_dia	ult_dia é ambíguo: significa as últimas 24 horas? Ou o dia atual (0h até agora)?
num_comp_liqui_120d	num_comp_120d	Se o recurso só incluir compras liquidadas, isso deve estar claro no nome do recurso.

Comunicação constante entre cientistas de dados e engenheiros de aprendizado de máquina

Como mencionamos antes, cientistas de dados e engenheiros de aprendizado de máquina são essenciais para levar um modelo de aprendizado de máquina à produção, cuidar da modelagem e da implementação em tempo real, respectivamente.

Eles devem ser parte de uma única equipe, como um esquadrão. Se equipes diferentes forem responsáveis por modelar e implementar os modelos, há grandes chances de haver um desentendimento que cause distorção entre treinamento e exibição.

Você provavelmente pode usar dados de amostragem para monitorar

O monitoramento de modelos de aprendizado de máquina (ML) é demorado e caro. Você não precisa usar todos os dados para monitorar distorções entre treinamento e exibição.

Se você usar dados de amostragem, certifique-se de que sejam de uma amostra determinística para que amostras em ambos os trajetos de dados (treinamento e exibição) estejam incluídas. Amostragem baseada em hash é um jeito de fazer isso.

Instalações em modo sombra

Instalação em modo sombra refere-se a instalar completamente um modelo em tempo real, mas usando suas previsões para tomar decisões de fato. Isso pode ser feito com uma alternância de recursos (ou um simples if-statement)

Você pode usar instalações em modo sombra para testar incompatibilidades de treinamento e exibição sem causar danos ao negócio, pois as previsões não serão usadas.

Conclusão

Em resumo, a distorção de treinamento e exibição é um problema considerável em modelos de aprendizado de máquina em tempo real, que surge das diferenças entre os ambientes de treinamento e de exibição. Isso pode ser devido a uma falha de comunicação entre as equipes ou mudanças inesperadas nas fontes de dados.

Para minimizar isso, é crucial monitorar e depurar incompatibilidades, com foco em recursos de alta importância. Isso envolve coletar e comparar dados de recursos tanto do trajeto de treinamento quanto de exibição e resolver os problemas assim que surgirem.

Usar um armazenamento de recursos pode simplificar esse processo terceirizando o cálculo de recurso para outras equipas. Além disso, manter uma boa comunicação entre cientistas de dados e engenheiros de aprendizado de máquina pode prevenir desentendimentos que levem a distorções.

Instalar modelos em modo sombra, onde as previsões não são usadas para tomar decisões, pode ajudar a testar incompatibilidades sem afetar os negócios. Resolvendo distorções entre treinamento e exibição, as empresas podem garantir que seus modelos de aprendizado de máquina (ML) em tempo real sejam mais precisos e confiáveis.