Recuerdo una vez, hace unos años, que desplegué un modelo de recomendación a producción con un entusiasmo ingenuo. Todo parecía funcionar en mis notebooks, las métricas eran decentes, el API respondía. Una semana después, los KPIs de negocio se desplomaron. ¿La razón? Un bug sutil en la función de feature engineering que, bajo ciertas condiciones de datos (no muy comunes en mi set de entrenamiento), generaba NaNs, los cuales luego se propagaban silenciosamente por el modelo. Una pesadilla que me tuvo a las 3 AM debuggeando logs y rebanándome los sesos. Desde entonces, el unit testing para componentes de IA se convirtió en mi obsesión, y te aseguro que es la paz mental que no sabías que necesitabas.
No, no estás testeando el modelo (directamente)
Vamos a ser claros desde el principio: no estoy sugiriendo que escribas un unit test para ver si tu modelo de deep learning aprende a clasificar gatitos. Eso es una falacia y, en mi opinión, una pérdida de tiempo. La evaluación del rendimiento global del modelo se hace con un buen set de validación y métricas de alto nivel, y sobre eso ya he escrito un poco en Métricas de Evaluación: Por qué tu accuracy no me dice nada.
Mi enfoque es diferente. Estoy hablando de testear los ladrillos que construyen tu sistema de IA. Piensa en el código que limpia los datos, el que genera las features, el que prepara los embeddings, las capas personalizadas de tu red neuronal, o incluso la lógica que orquesta las llamadas a tu modelo. Cada una de esas piezas puede romperse de forma independiente y, en el contexto de la IA, lo hará de formas mucho más insidiosas que un IndexError obvio.
¿Por qué la IA lo necesita más que el software tradicional?
En software