Tu sistema de ML tiene un problema de datos

Algo no está bien

Un stakeholder te manda un mensaje por Slack: “El modelo está mal.” Lo descartás inicialmente porque las métricas parecían bien, probablemente mala suerte. Pero revisás, y no es mala suerte. Funciona mal.

Entonces hacés lo que suelen hacer los equipos cuando se enfrentan a un sistema de machine learning que rinde menos de lo esperado: te apurás a intentar arreglar el propio modelo.

Tu primer reflejo: ajustar el modelo

En este escenario el modelo puede ser cualquier cosa. Una regresión lineal, un clasificador de imágenes, un LLM al que accedés vía la API de un tercero, o lo que sea que tome datos y devuelva datos mediante la interacción de parámetros aprendidos.

Los arreglos van desde lo simple hasta algo bastante esotérico, pero por lo general implican cambiar de alguna forma el comportamiento del modelo. Lo que más he visto suele incluir:

• Entrenar por más épocas.
• Cambiar el system prompt para que en lugar de “Actuá como un experto…” diga “Sos un experto…”.
• Cambiar la arquitectura del modelo o congelar algunas capas.
• Jugar con la temperatura.
• ¿Capaz si pasamos de regresión logística a LASSO lo solucionamos?
• Correr alguna librería de feature engineering automático que muy probablemente solo va a introducir ruido.
• Ajustar la learning rate.

Todos somos culpables de alguno o varios de estos. Creo que la razón es que normalmente implican cambiar un par de líneas de código y esperar, mientras que la solución real tiende a llevar mucho más tiempo y ser mucho más tediosa.

En mi experiencia, esos ajustes no suelen generar mejoras significativas y en ocasiones empeoran la performance.

Por qué mejores datos importan

Por otro lado, datos mejores suelen llevar a mejor performance. De hecho, en el 100% de las veces en las que estuve involucrado en una de estas situaciones, trabajar sobre los datos llevó a mejoras significativas.

Mejorar los datos puede significar muchas cosas.

• Datos de entrenamiento: más muestras, mayor diversidad y menos errores.
• Datos de evaluación/test: más muestras, más alineados con el universo de datos en el que el modelo va a operar, y obviamente con menos errores.
• Definición del problema: ¿qué debería intentar resolver el modelo y dónde? A veces esperamos demasiado de los sistemas de aprendizaje automático, y a veces el universo de datos se desplazó tanto que necesitamos reenfocar.

También es analizar las trazas de razonamiento de tu LLM preferido para entender en qué parte del proceso de pensamiento del modelo las cosas salieron mal y cómo podés prevenirlo en el futuro.

Una vez a mi equipo en Mercado Libre le pidieron que se hiciera cargo de un clasificador de texto multilabel porque el otro equipo no tenía la capacidad para mantenerlo y mejorarlo. Junto con eso vino un dataset de 500k filas que descartamos en cuanto nos dimos cuenta de lo mal etiquetado que estaba. Empezamos de cero y lo fuimos reconstruyendo manualmente, y con poco más de 10k muestras estábamos obteniendo scores F1 mucho mejores en todas las labels.

La solución poco glamorosa

El problema es que el trabajo con datos es tedioso y no tiene nada de gloria. En general se lo asocia con trabajo rutinario de nivel inicial que encajaría mejor con pasantes de empresas aburridas. Los data scientists junior sueñan con el día en que puedan ascender y dejar de volverse locos mirando datos durante horas.

Sin embargo, sostengo que mirar los datos manualmente y corregir errores es la forma más eficiente de usar el tiempo de quien es responsable de un sistema de machine learning. Es decir: un día dedicado a mirar datos en una planilla va a producir una mejora mayor que un día cambiando esquemas de tasa de aprendizaje u otro ajuste del modelo.

También sostengo que es algo que todo el mundo debería hacer, independientemente de la seniority o el skillset. En mi equipo en Mercado Libre, los engineering managers y los product owners revisan manualmente los datos y sus observaciones suelen ser clave para mejorar el rendimiento del modelo.

Incluso unas pocas horas de error analysis en las que te enfocás en los fallos más evidentes del modelo comparando predicciones con etiquetas reales pueden hacer maravillas¹.

Aunque existan algunas mejoras fáciles, la mejor forma de mejorar tu modelo es mejorar tus datos².

Los modelos son código; los sistemas son datos. Si estás debuggeando lo primero sin entender lo segundo, estás debuggeando a ciegas.