7 min de lectura
El modelo estaba bien. Las métricas de validación eran sólidas, el backtesting cerraba, el equipo técnico tenía razones para estar satisfecho. Tres meses después de entrar en producción, nadie lo consultaba antes de tomar decisiones. El proceso de negocio que se suponía que iba a consumir su salida seguía funcionando igual que antes.
Los requerimientos que llevan a un proyecto de Data Science a ser usado por el negocio son distintos de los criterios que hacen que un modelo pase validación técnica. La mayoría de los proyectos no llega a producción, y de los que llegan una fracción significativa queda sin uso real; el algoritmo es raramente la causa. Los que sí funcionan comparten tres condiciones, y las tres se definen antes de que el primer modelo se entrene. Sin cualquiera de ellas, el resultado más probable es un entregable técnicamente correcto que nadie consume.
Un sponsor con autoridad sobre el proceso
La primera condición es una distinción que suele pasarse por alto. Alguien que quiere el modelo no es lo mismo que alguien con autoridad para cambiar el proceso que lo va a consumir. El primero puede ser el director de marketing que lleva meses pidiendo algo con machine learning, o el jefe de analítica convencido de que los datos van a transformar la operación. Su apoyo es necesario, pero no alcanza. Para que el proyecto llegue a ser usado, hace falta que alguien más esté en la sala desde el principio.
Al sponsor no se le pide entender cómo funciona el modelo. La pregunta que hay que poder responder es quién tiene la autoridad para rediseñar el proceso de decisión alrededor de la salida del modelo. Si el modelo de propensión de recompra produce una priorización de clientes cada semana, alguien tiene que tener la autoridad para que el equipo de contacto trabaje con esa priorización en vez de con el criterio anterior. Si esa persona no está involucrada desde el principio, el modelo llega a producción y encuentra que el proceso de decisión no lo esperaba.
El criterio para saber si el sponsor correcto está presente es concreto. Si la respuesta implica convencer a otra persona que no está en la conversación, el proyecto tiene un problema antes de arrancar. Los proyectos que terminan siendo usados casi siempre tienen a esa persona en la definición del alcance, con visibilidad de qué proceso va a cambiar cuando el modelo esté disponible y con autoridad para que ese cambio ocurra.
Una integración diseñada desde el principio
El modelo llega a producción y aparece la pregunta de cómo el equipo de negocio va a acceder a la salida. Cuando la integración no se pensó desde el principio, el equipo técnico tiene que construirla después de que el modelo ya está entrenado, con restricciones que no se conocían al diseñar la solución. La salida puede no tener el formato que el sistema de destino espera. El proceso puede necesitar datos que el modelo no produce. La frecuencia de actualización puede no coincidir con la frecuencia con la que el equipo necesita la información.
Estos problemas son resolubles, pero cada uno tiene un costo. El costo se acumula. En algún punto del proceso de integración tardía, el proyecto deja de tener el apoyo que tenía cuando empezó, porque el tiempo transcurrido ya superó la expectativa de cuándo iba a estar disponible algo útil. Los proyectos que funcionan diseñan la integración junto con el modelo. Desde la semana uno se sabe en qué sistema vive el proceso de decisión, qué formato espera ese sistema, qué tiene que hacer el equipo de forma diferente cuando el modelo emite su salida.
Hay una consecuencia menos obvia de diseñar la integración desde el arranque. El modelo que se entrena cuando ya se sabe cómo se va a consumir es un modelo distinto al que se entrena sin esa información. La variable que predice mejor puede no ser la variable disponible en producción. El umbral de decisión puede cambiar si el proceso de negocio tiene restricciones de capacidad. La integración es un insumo para el diseño del modelo, más que una etapa técnica final.
Una cadencia que coincide con el proceso
Los modelos de Data Science tienen una cadencia de actualización. Los procesos de negocio tienen una cadencia de decisión. Cuando las dos no coinciden, el modelo pierde valor aunque la predicción sea correcta. Un modelo de probabilidad de abandono que se actualiza mensualmente para un equipo de retención que contacta clientes cada semana tiene un problema. El equipo necesita saber qué clientes están en riesgo esta semana, y el modelo le dice qué clientes estaban en riesgo a principios del mes. Para la cuarta semana, parte de esa información ya no representa la realidad actual.
El caso inverso también ocurre. Un modelo que genera predicciones diarias para un proceso de decisión que opera mensualmente crea trabajo innecesario. El equipo recibe actualizaciones que no puede consumir a esa frecuencia. La cadencia es una pregunta sobre cuándo el equipo de negocio toma la decisión que el modelo informa, más allá del costo computacional de actualizar el modelo. Si el equipo de supply chain decide el reabastecimiento los lunes por la mañana, el modelo de previsión de demanda tiene que tener su salida disponible antes de esa reunión, no el jueves previo ni en tiempo real.
Esta alineación requiere una conversación entre quien construye el modelo y quien lo va a usar, y tiene que ocurrir antes de que el modelo se entrene, porque la cadencia de actualización afecta cuántos datos históricos se usan para entrenarlo y qué tipo de validación tiene sentido hacer. Los equipos que la definen desde el principio terminan con un modelo que el negocio sabe cómo consumir en el ritmo del proceso real.
Qué cambia cuando las tres condiciones se cumplen
Las tres condiciones no se pueden resolver retroactivamente. Lo que no se acordó antes de entrenar el primer modelo aparece como deuda cuando el proceso ya está en marcha, y esa deuda se paga con reajustes de integración, re-validación del modelo y erosión de la confianza del equipo receptor.
Los primeros meses de producción muestran la diferencia. El sponsor con autoridad puede rediseñar el proceso cuando el modelo lo recomienda. La integración diseñada desde el principio no tiene que adaptarse a restricciones que nadie conocía. La cadencia alineada hace que la salida llegue cuando el equipo de negocio la necesita. Lo que los proyectos que llegan a producción tienen en común no es el stack tecnológico ni el tipo de modelo ni el tamaño del equipo técnico. Es que alguien, antes de que el primer modelo se entrenara, respondió las tres preguntas que definen esas condiciones: quién tiene autoridad sobre el proceso, cómo va a llegar la salida al lugar de decisión, y cuándo necesita estar disponible.
Estas preguntas son anteriores a cualquier elección técnica. Responderlas bien permite elegir el algoritmo más sencillo que resuelva el problema y llegar a producción con eso. La distinción entre los proyectos archivados y los proyectos en uso raramente se hace por los datos o los modelos. Se hace por las conversaciones que ocurrieron (o no ocurrieron) antes de que el proyecto arrancara.