Mercado Livre: training-serving skew and data dependencies in anti-fraud

01 · CONTEXT

Good in the lab, bad in production

Anyone who puts machine learning models into production knows the question that opens the Mercado Libre article: has it ever happened that lab results were very good and production results were not? The author points out that, even with tests everywhere and with the guarantee that the training and production data distributions are consistent, it would be a mistake to act as if these mechanisms would work: there will be a difference between training data and production data.

The problem weighs more in large, complex systems with many data sources. Mercado Libre's fraud prevention models, for example, consume many sources: historical aggregates on different entities (such as users or devices), real-time aggregates, transactional context data, graph relationships, and others.

1. At the center of the diagram is the fraud model in serving, which consumes several data sources.

2. Two of the cited sources are aggregates: the history on entities such as users or devices and the one computed in real time.

3. The other two are transactional context data and graph relationships.

4. An affected data dependency, including its own dependencies, can change the final prediction and the model's performance in serving.

02 · THE RULE OF THUMB

The more sources, the lower the chance of consistency

The author proposes a rule of thumb: the probability that the training and serving data are consistent is 1 / (2 ^ N), where N is the number of different data sources. The more sources, the greater the chance that one of them fails.

Even with technical debt well managed, the sources you depend on are probably relatively under control, but that does not prevent problems such as a service going down, a change in an API signature, a field outside the expected name, or product changes. An affected dependency, along with its own dependencies, can change the final prediction and the model's performance in serving.

03 · TRAINING VERSUS SERVING

What production has that the training ETL does not see

The text contrasts two worlds. In the training ETL there are no problems such as timeouts, latency, or cache update delays; in production there are. That is why the recommendation is to take the serving SLA constraints into account when generating the data, and to make the ETL reflect, as far as possible, the distribution that serving will generate, which is not necessarily "reality".

In other words, the model must be prepared for production noise, and the author suggests injecting the same noise distribution into the training dataset.

1. The diagram first shows the offline path: the ETL reads the offline sources and writes the training dataset.

2. On the online path, the sources face timeouts, latency, and cache update delays, problems that the training ETL does not have.

3. The recommendation is that the ETL take the serving SLA constraints into account and reflect the distribution that serving generates.

4. The author also suggests injecting the same production noise distribution into the training dataset.

04 · DEFENSES IN PRODUCTION

Observe, measure, and react

The stance is defensive. In an ideal setup, whoever controls the data producers would have them detect errors themselves and report them to the consumers; in practice, being more defensive and preparing for the worst is sometimes the best strategy.

1. First, watch the model's output to detect anomalies, paying attention to the lowest and highest percentiles of the distribution.

2. Second, a system that monitors the signals (features) arriving at the model.

3. Third, maintain an SLA for the most important features; the importance of the model's features helps rank which ones to watch.

4. When the output or the input signals report problems, there should be procedures to fix or mitigate the impact.

05 · TRAINING TO DEFEND ITSELF

Noise tolerance and its limits

On the training side, the author recommends preparing the model to tolerate noise, especially when the online and offline sources are different: use regularization and apply feature dropout, mainly on features with the highest chance of failing online.

If there are already examples of data points affected in serving, it is a good idea to fix those errors to use them in training, but also to train the model with the affected points so it learns to "defend" itself if the problem recurs. The cost is that this can affect the model's performance.

At every retrain, the author asks to check feature sanity, to fix or debug the ones most prone to fail.