¿Para qué escribirías tests de verdad en un pipeline de machine learning?

Prueba bien las partes deterministas y de forma conductual las estocásticas. Haz tests unitarios de las transformaciones de características contra fixtures, impón contratos de esquema y de rango sobre las entradas, mantén un test de fila dorada que cargue el pipeline serializado y compruebe que entradas conocidas producen puntuaciones conocidas, y escribe tests conductuales sobre las salidas del modelo (invarianza, expectativas direccionales) en vez de comprobar un número exacto de precisión.

La mayor parte de un pipeline es código normal y se prueba exactamente como código normal. Las transformaciones de características llevan tests unitarios contra fixtures pequeños, incluidos los casos feos: nulos, una categoría nunca vista en entrenamiento, un valor negativo donde solo se esperaban positivos. Los datos de entrada llevan comprobaciones de contrato, o sea esquema, tipos, rangos y tasas de nulos esperadas, ejecutadas como puerta antes de entrenar en vez de descubrirse después como un modelo raro. Luego un test de fila dorada, donde guardo un pipeline serializado y un puñado de entradas fijas con sus puntuaciones esperadas, y CI falla si una refactorización las cambia. Eso me ha pillado cambios de preprocesado sin ruido más de una vez. Para el modelo en sí no compruebo que la precisión supere cierto número, porque eso es inestable y es una mala puerta. Escribo tests conductuales en su lugar: invarianza, o sea que cambiar un campo irrelevante mueve la puntuación apenas, y expectativas direccionales, o sea que subir una característica que sabemos monótonamente relacionada mueve la predicción en el sentido correcto. Los entrenamientos completos son demasiado lentos para cada commit, así que van cada noche, con un entrenamiento de humo rápido sobre una muestra diminuta en CI para probar que el pipeline sigue funcionando de extremo a extremo.