Habr AI y Spar: cómo probar sistemas de ML cuando los datos sufren drift y rompen las predicciones

Habr AI publicó una guía práctica para probar sistemas de ML—no en teoría, sino en un proyecto en vivo de auto-pedidos para la cadena minorista Spar. El autor demuestra que estos productos no solo se rompen en los modelos: los errores se esconden en los datos, estacionalidad, integraciones e incluso en la selección de métricas.

Por Qué Esto Es Difícil

En QA clásico, puedes tomar requisitos, preparar casos de prueba y comparar el resultado real con el esperado. En ML, este enfoque solo funciona parcialmente. El modelo no produce una "respuesta correcta" por una regla rígida; construye un pronóstico probabilístico.

Entonces el probador verifica no un número específico, sino un rango de error aceptable, robustez en diferentes cortes de datos e impacto del error en el negocio. La complejidad se amplifica por el hecho de que el objeto siendo probado es no solo código. Si un modelo fue entrenado en datos incompletos, sucios o desactualizados, un buen algoritmo seguirá produciendo malos resultados.

Para minorista, esto es especialmente crítico: la demanda cambia por el clima, feriados, eventos locales y nuevos hábitos de compra del cliente. Lo que funcionaba con precisión ayer puede fallar sistemáticamente mañana debido a drift de datos y cambios en el comportamiento real del cliente.

Cómo Construyen el Control

En el caso de Spar, el equipo se alejó de la idea de "encontrar una respuesta correcta" y se apoyó en métricas técnicas y de negocio. En la etapa de requisitos, primero acuerdan qué constituye calidad aceptable: por ejemplo, cuánto un pronóstico por categoría puede desviarse de los resultados reales sin daño real en ventas y descartes. Luego, las pruebas se construyen alrededor de rangos en lugar de pass/fail binario. En paralelo, verifican no solo escenarios normales sino también datos anómalos que no deben romper el pronóstico. En la práctica, el control se ensambla desde varias capas:

• versiones fijas de bibliotecas y containerización vía Docker;
• anonimización de datos para usar ventas realistas sin filtración de información personal;
• pruebas dirigidas en diferentes tiendas, formatos y categorías de productos, no solo métricas promedio;
• regresión del nuevo modelo contra el antiguo para que la mejora en una métrica no rompa otras;
• monitoreo de infraestructura e intercambios nocturnos de datos, porque el negocio necesita pronósticos no solo precisos sino también oportunos.

Una conclusión separada del artículo es que probar ML "en promedio en el hospital" es inútil. Un modelo puede verse bien en chocolate pero fallar en una marca específica, contar pan con precisión mientras simultaneamente se equivoca en salsas. Entonces la prueba va más profundo: por categoría, por niveles de detalle y por una muestra representativa de tiendas. Este enfoque cuesta más, pero proporciona un cuadro real antes del lanzamiento, no después de quejas del negocio.

Fallos en Producción

La parte más instructiva del material son los fallos reales. En un caso, el equipo confundió dos parámetros casi idénticos de un algoritmo estacional: prediction_share y predict_share. Eso fue suficiente para que el sistema sobreestimara dramáticamente el pronóstico de mantequilla, crema agria y queso cottage.

Productos lácteos en exceso llegaron a las tiendas, y parte del inventario tuvo que ser rápidamente descuento debido al corto plazo de vencimiento. El error era pequeño a nivel de código pero costoso a nivel del negocio operativo. También hubo el caso opuesto—una subestimación de lavash después del lanzamiento.

La estacionalidad semanal comenzó a calcularse incorrectamente, y el pico de demanda "se movió" de los fines de semana a mediados de semana. Debido a los bajos volúmenes de ventas, el problema no se notó inmediatamente, pero para los clientes el efecto era simple: el producto desaparecía de los estantes exactamente cuando lo necesitaban. Otro fallo ocurrió a principios de 2025: el modelo interpretó incorrectamente el campo year y esencialmente "no entendió" que un año nuevo había llegado, y el sistema de detección de anomalías no lo capturó.

La conclusión es dura: ML debe ser probado no solo en datos conocidos, sino también en períodos futuros, nuevos rangos de valores y fallos de mecanismos de protección.

Qué Significa Esto

El artículo de Habr AI demuestra claramente un cambio en cómo se entiende QA para ML. Aquí, ejecutar casos de prueba contra código no es suficiente: necesitas una combinación de métricas, datos, monitoreo y contexto de negocio. Para equipos que implementan pronósticos en minorista, logística o fintech, esto ya no es una disciplina adicional sino una capa obligatoria de protección contra errores costosos y silenciosos.