7 min de lectura
Cuando una empresa quiere predecir qué clientes van a darse de baja o dejar de consumir, se encuentra con que la mayoría de los que están en la base no lo van a hacer. Esa asimetría es la norma, no la excepción: en cualquier problema de clasificación donde la clase que interesa es minoritaria (el 2%, el 5%, el 10% del total), el modelo puede aprender a producir métricas de performance que se ven bien en el reporte mientras deja pasar casi todos los casos que el negocio quería detectar. El resultado es un modelo técnicamente correcto y operativamente inaplicable, que llega a producción respondiendo con precisión a la pregunta equivocada.
La conversación que separa una cosa de la otra ocurre antes del entrenamiento, y es una discusión sobre qué error puede permitirse el negocio y qué error no. Ese acuerdo determina la métrica, la calibración del modelo y la estrategia de intervención que sigue después. Sin él, el pipeline llega hasta producción con el criterio del data scientist (maximizar performance agregada) cuando el criterio del negocio era otro.
Cuando la métrica default esconde el problema
Supongamos un modelo de churn entrenado sobre una base donde el 2% de los clientes efectivamente abandona en el trimestre siguiente. Un modelo trivial que prediga "no abandona" para todos y cada uno de los clientes acierta el 98% de las veces. Accuracy 0.98 sobre el conjunto de test, y la métrica se ve excelente. Es también la definición operativa de un modelo inútil, porque no detectó ninguno de los abandonos reales, que es lo único para lo que se construyó.
AUC (el área bajo la curva ROC, una medida de qué tan bien el modelo ordena los casos por probabilidad de ser positivos) resiste un poco mejor este engaño porque no depende del umbral. Pero también tiene ceguera propia en desbalance extremo. Un AUC de 0.87 puede convivir con un recall de 0.18 sobre la clase minoritaria. El modelo ordena razonablemente bien entre negativos y positivos, pero cuando llega el momento de clasificar sigue enviando la mayoría de los positivos reales al lado negativo. Los dos números son reales y compatibles. El primero es el que aparece en el reporte técnico; el segundo es el que determina si la solución tiene valor.
La métrica que revela este problema es específica al tipo de error que el negocio no puede permitirse. Recall, cuando el costo de dejar pasar un caso positivo es alto. Precisión, cuando el costo de intervenir sobre un negativo es alto. El data scientist puede facilitar la elección, pero el input que la determina lo tiene el equipo que asume las consecuencias. Variables de negocio como el costo esperado de perder un cliente y el costo de la campaña que se activaría para retenerlo entran en esta decisión antes que cualquier consideración algorítmica.
Dos problemas con la misma técnica y decisiones opuestas
En un problema de propensión de recompra con campaña por email, el falso positivo cuesta poco. Se envía un email a alguien que probablemente no iba a recomprar; el costo es el envío y algo de ruido en la bandeja. El falso negativo tiene un costo de oportunidad. Es no contactar a alguien que habría recomprado si hubiera recibido el mensaje. En ese caso recall importa más. El modelo se calibra para capturar la mayoría de los compradores potenciales, aunque implique contactar a algunos que no lo eran.
En detección de fraude el análisis es el opuesto. El falso positivo tiene costo real. El cliente legítimo cuya transacción fue bloqueada llama molesto o, peor, cambia de proveedor. El falso negativo también cuesta, pero hay márgenes para tolerarlo según el volumen y el monto promedio del fraude. Precisión importa más. El modelo se calibra para que cuando diga "fraude", casi siempre tenga razón, aunque implique perder algunos casos reales.
Los dos problemas usan el mismo tipo de modelo. Lo que cambia entre uno y otro es el costo relativo de los dos tipos de error, y por lo tanto la métrica que rige el entrenamiento y la validación. Si el costo promedio de un fraude no detectado es 400 euros y el costo de bloquear una transacción legítima es 20 euros en atención al cliente, la función de pérdida asigna veinte veces más peso al falso negativo que al falso positivo. Ese ratio lo define quien conoce el negocio. Sin ese ratio, el modelo optimiza con costos implícitos iguales, que nunca coinciden con los costos reales.
La segmentación del ranking abre estrategias distintas
Elegir la métrica es una parte del trabajo. La otra es entender que el output del modelo es un ranking, no una etiqueta. Cada cliente recibe una probabilidad estimada, y esa distribución de probabilidades se puede partir en segmentos que admiten estrategias operativas distintas.
Un modelo de churn puede identificar que los clientes con probabilidad superior al 80% (el decil superior de la distribución) representan el 40% de los abandonos reales que ocurrirán en el trimestre. Ese segmento pequeño y concentrado puede justificar una intervención cara: una llamada de un gestor de cuenta, una oferta de renovación con descuento, una reunión de retención. Los clientes con probabilidad entre 60% y 80% (el segundo decil) son un grupo más grande y con menor concentración de abandonos reales; ahí una intervención más barata, como una comunicación automatizada personalizada, puede tener retorno positivo. Los clientes con probabilidad menor al 60% probablemente no justifican ninguna intervención de retención específica.
Relacionado: el análisis por segmentos del ranking se desarrolla en detalle en Segmentación del ranking de probabilidades (próximo artículo), donde se cubren cómo elegir los umbrales de corte por deciles y cómo asignar costo esperado por intervención a cada segmento.
Sin este ejercicio, la práctica default es aplicar un solo umbral de clasificación, típicamente 0.5, un valor sin justificación de negocio, y ejecutar la misma acción para todos los positivos. Esa uniformidad malgasta presupuesto sobre los positivos con probabilidad más baja y subinvierte en los de probabilidad más alta.
El umbral no es un parámetro técnico
El modelo no produce predicciones binarias directamente. Produce un ranking con probabilidades. El umbral de clasificación es el corte que convierte esas probabilidades en decisión. Por encima del umbral el sistema activa la acción; por debajo, no. Ese corte lo define quien conoce las consecuencias, no el data scientist.
Por defecto, la mayoría de las librerías usan 0.5. Ese valor no tiene justificación de negocio. Es el punto donde el modelo estima que los dos resultados son equiprobables, y casi nunca coincide con el punto donde los costos de los dos errores se equilibran. En propensión de recompra con costo bajo de contacto, bajar el umbral a 0.25 puede aumentar recall de forma significativa con una caída aceptable en precisión. En fraude con costo alto de bloqueo, subir el umbral a 0.7 puede mejorar precisión al precio de perder algunos casos reales.
El umbral se calibra sobre la curva precision-recall en datos de validación, con los costos reales del negocio como referencia. Ese corte lo define el equipo que conoce las consecuencias, no el data scientist. La segmentación por deciles vista antes es una extensión operativa del mismo principio: no hay un umbral óptimo universal, hay umbrales óptimos por segmento según el costo relativo de la intervención asociada a cada uno.
Definir la métrica es definir el resultado esperado
La conversación sobre qué error puede permitirse el negocio es el proyecto de mayor retorno que se puede hacer sin datos todavía, más que una etapa previa opcional al proyecto. Determina la métrica, la calibración del modelo, la estrategia de intervención por segmento y el criterio contra el cual se va a evaluar el resultado en producción.
Sin esa conversación, la métrica se elige por defecto y el modelo se entrena contra un criterio que nadie acordó. Cuando llegue a producción y alguien pregunte "¿funciona?", si nadie acordó de antemano cómo se responde esa pregunta, la respuesta va a ser ambigua. La discusión que no ocurrió antes del entrenamiento ocurre después, cuando cualquier cambio al modelo o al umbral tiene un costo de re-validación y re-despliegue que ya no es marginal.
Un modelo llega a producción respondiendo con precisión técnica a una pregunta que la métrica optimizó. Si esa pregunta no coincide con la que el negocio necesitaba responder, el equipo de operaciones se encuentra con un sistema que "funciona" según el data scientist y no le sirve según ellos. Cerrar ese hueco no es sofisticación de algoritmo. Es acordar antes del entrenamiento qué es lo que el modelo tiene que optimizar y por qué. Cualquier proyecto que salte esa conversación se paga después, y se paga caro.