Reproducibilidad de modelos: el mismo resultado en tu notebook y en producción

Qué significa que un modelo sea reproducible

Reproducible quiere decir que, con las mismas entradas, el modelo devuelve el mismo resultado sin importar dónde se ejecute. Es la condición que convierte a un modelo validado en un modelo confiable: lo que aprobó el área de riesgo es exactamente lo que decide sobre la cartera.

En el motor eso se apoya en tres piezas que se definen una sola vez: el entorno donde corre el modelo, el contrato de datos que recibe y devuelve, y la validación inicial contra un conjunto de casos conocidos.

• Mismas entradas, mismo resultado, en cualquier ejecución.
• Lo validado y lo que decide son la misma versión.
• La verificación queda registrada, no depende de la memoria de nadie.

El entorno queda fijado

El primer pilar es que el modelo no corre sobre un entorno que cambia por debajo. Antes de desplegar se fijan la versión de Python y las versiones exactas de las dependencias con las que fue entrenado, junto con la forma en que el modelo fue serializado y el método de inferencia que se va a invocar.

Fijar versiones exactas, y no rangos, es lo que evita que una actualización de una librería mueva el resultado sin que nadie haya tocado la política. Si el modelo necesita un paquete que no está en el entorno, conviene confirmarlo con el equipo de uFlow antes de avanzar, en lugar de asumir que estará disponible.

• Versión de Python declarada.
• Versiones exactas de las dependencias, no rangos.
• Método de inferencia y forma de serialización definidos.

El contrato de datos, declarado una vez

El segundo pilar es el contrato: qué recibe el modelo y qué devuelve. Se declaran las variables de entrada y su orden, los tipos de dato, el preprocesamiento que corresponde aplicar y las variables de salida.

Vale la pena detenerse en dos detalles que suelen quedar implícitos en el notebook. El orden de las features, porque un modelo no avisa si se las pasás cambiadas: simplemente devuelve otro número. Y el tratamiento de nulos, porque un campo vacío que en el entrenamiento valía cero no es lo mismo que un nulo en producción. Declararlo en el flujo mantiene el comportamiento parejo.

• Variables de entrada, con su orden y sus tipos.
• Preprocesamiento explícito, no heredado del notebook.
• Tratamiento de nulos definido en el flujo.
• Variables de salida que la política va a usar.

La validación de arranque: conjunto de control y tolerancia

El tercer pilar es la evidencia. Antes de publicar se pasa por el motor un conjunto de casos controlado, del que ya se conoce el resultado local, y se comparan las salidas. La tolerancia aceptable se define de antemano, porque en aritmética de punto flotante una diferencia mínima puede ser esperable y una diferencia grande nunca lo es.

Si algún caso se aparta de la tolerancia, la revisión es ordenada y corta: versiones de Python y de librerías, serialización, orden y tipo de features, tratamiento de nulos, redondeos, preprocesamiento y, cuando el modelo tiene componente aleatorio, la semilla. Es una lista de verificación, no una investigación.

• Conjunto de control con resultados locales conocidos.
• Tolerancia declarada antes de comparar.
• Revisión guiada por una lista corta y siempre la misma.

La evidencia que necesita el gobierno de modelos

Para una institución regulada, la reproducibilidad no es una comodidad técnica sino parte del expediente del modelo. El área de model risk pide poder mostrar que el modelo implementado se comporta como el que fue validado, y que cualquier cambio posterior quedó registrado.

El motor aporta esa parte: cada versión del modelo y de la política queda guardada, se puede volver a una anterior de forma controlada, y cada decisión conserva las reglas aplicadas y los datos consultados. Con eso, la validación deja de ser un documento suelto y pasa a estar unida a la versión que efectivamente decide.

• Versionado del modelo y de la política que lo invoca.
• Retorno controlado a una versión anterior.
• Trazabilidad de cada decisión, con reglas y datos aplicados.

Comparar dos versiones sobre tráfico real

Una vez reproducido, el modelo nuevo puede convivir con el vigente en un esquema champion/challenger: el actual sigue decidiendo y el nuevo se evalúa en paralelo sobre una porción acotada, hasta que los resultados justifican el cambio.

Es el complemento natural de la reproducibilidad. Primero se verifica que el modelo se comporta igual que en el laboratorio; después se mide si decide mejor que el que está en producción.

Checklist antes de publicar

Los ocho puntos que conviene tener cerrados y documentados:

• Versión de Python.
• Versiones exactas de las dependencias.
• Forma de serialización del modelo.
• Método de inferencia.
• Variables de entrada, con orden y tipos.
• Preprocesamiento y tratamiento de nulos.
• Variables de salida.
• Conjunto de control y tolerancia aceptada.