Mercado Livre: skew entre treino e serving e dependências de dados no antifraude

01 · CONTEXTO

Bom no laboratório, ruim em produção

Quem coloca modelos de machine learning em produção conhece a pergunta que abre o artigo do Mercado Livre: já aconteceu de os resultados de laboratório serem muito bons e os de produção não? O autor lembra que, mesmo com testes por toda parte e com a garantia de que as distribuições dos dados de treino e de produção são coerentes, seria um erro agir como se esses mecanismos fossem funcionar: haverá diferença entre os dados de treino e os de produção.

O problema pesa mais em sistemas grandes e complexos, com várias fontes de dados. Os modelos de prevenção a fraude do Mercado Livre, por exemplo, consomem muitas fontes: agregados históricos sobre diferentes entidades (como usuários ou dispositivos), agregados em tempo real, dados transacionais de contexto, relações em grafo e outras.

1. No centro do diagrama está o modelo de antifraude em serving, que consome várias fontes de dados.

2. Duas das fontes citadas são agregados: o histórico sobre entidades como usuários ou dispositivos e o calculado em tempo real.

3. As outras duas são os dados transacionais de contexto e as relações em grafo.

4. Uma dependência de dados afetada, incluindo as dependências dela, pode alterar a previsão final e o desempenho do modelo em serving.

02 · A REGRA PRÁTICA

Quanto mais fontes, menor a chance de consistência

O autor propõe uma regra prática: a probabilidade de os dados de treino e os de serving serem consistentes é 1 / (2 ^ N), em que N é o número de fontes de dados diferentes. Quanto mais fontes, maior a chance de que alguma falhe.

Mesmo com a dívida técnica bem gerida, as fontes de que se depende provavelmente ficam relativamente sob controle, mas isso não impede problemas como a queda de um serviço, a mudança na assinatura de uma API, um campo fora do nome esperado ou mudanças de produto. Uma dependência afetada, com as dependências dela, pode alterar a previsão final e o desempenho do modelo em serving.

03 · TREINO VERSUS SERVING

O que a produção tem e o ETL de treino não vê

O texto contrasta dois mundos. No ETL de treino não há problemas como timeouts, latência ou atraso na atualização de cache; em produção há. Por isso a recomendação é levar em conta as restrições de SLA do serving ao gerar os dados, e fazer o ETL refletir, o quanto possível, a distribuição que o serving vai gerar, que não é necessariamente a "realidade".

Em outras palavras, o modelo precisa estar preparado para o ruído da produção, e o autor sugere injetar no dataset de treino a mesma distribuição de ruído.

1. O diagrama mostra primeiro o caminho offline: o ETL lê as fontes offline e grava o dataset de treino.

2. No caminho online, as fontes enfrentam timeouts, latência e atraso na atualização de cache, problemas que o ETL de treino não tem.

3. A recomendação é que o ETL leve em conta as restrições de SLA do serving e reflita a distribuição que o serving gera.

4. O autor também sugere injetar no dataset de treino a mesma distribuição de ruído da produção.

04 · DEFESAS EM PRODUÇÃO

Observar, medir e reagir

A postura é defensiva. Em um esquema ideal, quem controla os produtores de dados faria com que eles mesmos detectassem os erros e os reportassem aos consumidores; na prática, ficar mais defensivo e se preparar para o pior às vezes é a melhor estratégia.

1. Primeiro, vigiar a saída do modelo para detectar anomalias, com atenção aos percentis mais baixos e mais altos da distribuição.

2. Segundo, um sistema que monitora os sinais (features) que chegam ao modelo.

3. Terceiro, manter SLA para as features mais importantes; a importância das features do modelo ajuda a classificar quais vigiar.

4. Quando a saída ou os sinais de entrada reportam problemas, devem existir procedimentos para corrigir ou mitigar o impacto.

05 · TREINAR PARA SE DEFENDER

Tolerância a ruído e seus limites

Do lado do treino, o autor recomenda preparar o modelo para tolerar ruído, sobretudo quando as fontes online e offline são diferentes: usar regularização e aplicar feature dropout, principalmente nas features com maior chance de falhar online.

Se já existem exemplos de pontos de dados afetados em serving, é boa ideia corrigir esses erros para usá-los no treino, mas também treinar o modelo com os pontos afetados para que ele aprenda a se "defender" caso o problema se repita. O custo é que isso pode afetar o desempenho do modelo.

A cada retreino, o autor pede checar a sanidade das features, para corrigir ou depurar as mais propensas a falhar.