. Llevas tres semanas en un modelo de predicción de abandono, encorvado sobre una computadora portátil, observando cómo un barrido de optimización bayesiano avanza a través de su prueba número 200. El AUC de validación oscila entre 0,847 y 0,849. Le haces una captura de pantalla. Lo publicas en Slack. Su jefe reacciona levantando el pulgar.
Te sientes productivo. Usted no.
Si alguna vez ha pasado días exprimiendo fracciones de un porcentaje de una métrica de aprendizaje automático (ML) mientras una voz tranquila en el fondo de su cabeza le susurraba: ¿algo de esto realmente importa?, ya siente el problema. Esa voz tiene razón. Y silenciarlo con otra búsqueda en la red es uno de los hábitos más caros de la profesión.
Aquí está la incómoda matemática: más del 80% de los proyectos de Inteligencia Artificial (IA) fracasan, según una investigación de RAND Corporation publicada en 2024. La causa principal número uno no son los malos modelos. No son datos insuficientes. Es no comprender (o comunicar mal) qué problema debe resolverse. No es un fracaso de modelaje. Un fracaso en el encuadre.
Este artículo le brinda un protocolo concreto para detectar ese error antes de escribir una sola línea de código de entrenamiento. Cinco pasos. Cada uno toma una conversación, no un clúster de GPU.
"Todo ese progreso en los algoritmos significa que en realidad es hora de dedicar más tiempo a los datos". Andrew Ng no dijo que dedique más tiempo al modelo. Dijo lo contrario.
La trampa de la procrastinación productiva
El ajuste de hiperparámetros parece ingeniería. Tienes un espacio de búsqueda. Tienes una función objetivo. Usted itera, mide, mejora. El ciclo de retroalimentación es estrecho (de minutos a horas), el progreso es visible (las métricas aumentan) y el trabajo es legible para su equipo (“Mejoré el AUC en 2 puntos”).
Enmarcar el problema parece un estancamiento. Te sientas en una sala con partes interesadas del negocio que utilizan un lenguaje impreciso. Haces preguntas que no tienen respuestas claras. No hay ninguna métrica que suba. No hay captura de pantalla de Slack para publicar. Su gerente le pregunta qué hizo hoy y usted dice: "Pasé cuatro horas averiguando si deberíamos predecir la deserción o predecir la probabilidad de reactivación". Esa respuesta no parece un progreso.
Pero es el único progreso que importa.
Imagen del autor.
La razón es estructural. El ajuste opera dentro del problema tal como está definido. Si el problema se define incorrectamente, el ajuste optimiza una función que no se corresponde con el valor comercial. Obtienes un hermoso modelo que resuelve lo incorrecto. Y ninguna cantidad de barridos de Optuna puede arreglar una variable objetivo que no debería existir.
Zillow apostó 500 millones de dólares al problema equivocado
En 2021, Zillow cerró su división de compra de viviendas, Zillow Offers, después de perder más de 500 millones de dólares. La compañía había adquirido aproximadamente 7.000 viviendas en 25 áreas metropolitanas, pagando de más constantemente porque su algoritmo de fijación de precios (el Zestimate) no se ajustaba a un mercado en enfriamiento.
Las autopsias se centraron en la deriva conceptual. El modelo entrenado con datos de mercados calientes no pudo seguir el ritmo a medida que la demanda se desaceleró. La escasez de contratistas durante las renovaciones retrasadas por COVID. El ciclo de retroalimentación entre la compra y la reventa fue demasiado lento para detectar el error.
Pero el fallo más profundo ocurrió antes de que se entrenara cualquier modelo.
Zillow planteó el problema de la siguiente manera: dadas las características de una casa, predecir su valor de mercado. Ese marco suponía una relación estable entre características y precio. Supuso que Zillow podría renovar y revender lo suficientemente rápido como para que la ventana de predicción fuera corta. Supuso que la distribución de errores del modelo era simétrica (pagar de más y de menos con la misma probabilidad). Ninguna de esas suposiciones se mantuvo.
Los competidores Opendoor y Offerpad sobrevivieron al mismo cambio de mercado. Sus modelos detectaron el enfriamiento y ajustaron los precios. La diferencia no fue la sofisticación algorítmica. Fue la forma en que cada empresa enmarcó lo que su modelo debía hacer y la rapidez con la que actualizaron ese marco.
Zillow no perdió 500 millones de dólares por un mal modelo. Lo perdieron porque nunca cuestionaron si "predecir el valor de la vivienda" era el problema correcto para resolver a su velocidad operativa.
Cuando la IA aprendió a detectar gobernantes en lugar de cáncer
Un equipo de investigación construyó una red neuronal para clasificar las lesiones cutáneas como benignas o malignas. El modelo alcanzó una precisión comparable a la de los dermatólogos certificados. Cifras impresionantes. Curvas de validación limpias.
Luego, alguien observó lo que realmente aprendió el modelo.
Estaba detectando gobernantes. Cuando los dermatólogos sospechan que una lesión puede ser maligna, colocan una regla al lado para medir su tamaño. Entonces, en los datos de entrenamiento, las imágenes que contienen reglas se correlacionan con la malignidad. El modelo encontró un atajo: regla presente = probablemente cáncer. Gobernante ausente = probablemente benigno.
La precisión era real. El aprendizaje fue basura. Y ningún ajuste de hiperparámetros podría haber detectado esto, porque el modelo estaba funcionando exactamente como se indicaba en los datos, exactamente como se proporcionaron. El fracaso fue ascendente: nadie preguntó: "¿Qué debería considerar el modelo para tomar esta decisión?" antes de medir qué tan bien tomó la decisión.
Este es un patrón llamado aprendizaje de atajos y aparece en todas partes. Los modelos aprenden a explotar correlaciones en sus datos que no se mantienen en producción. La única defensa es una especificación clara de lo que el modelo debe y no debe usar como señal, y esa especificación proviene del encuadre del problema, no de la sintonización.
Por qué los errores de encuadre sobreviven tanto tiempo
Si un mal planteamiento del problema es tan destructivo, ¿por qué los equipos inteligentes siguen saltándoselo?
Tres dinámicas que lo refuerzan lo hacen persistente.
Primero, la asimetría de retroalimentación. Cuando ajustas un hiperparámetro, ves el resultado en minutos. Cuando replanteas un problema, la recompensa es invisible durante semanas. Los cerebros humanos descuentan las recompensas retrasadas. Por lo tanto, los equipos gravitan hacia el rápido ciclo de retroalimentación del ajuste, incluso cuando el lento trabajo de encuadre tiene un retorno 10 veces mayor.
En segundo lugar, el sesgo de legibilidad. “Mejoré la precisión del 84,7 % al 84,9 %” es una afirmación clara y defendible en una reunión de pie. "Pasé ayer convenciendo al equipo de producto de que estamos optimizando la métrica incorrecta" suena como si no hubieras logrado nada. Las organizaciones recompensan los resultados visibles. El encuadre no produce ningún resultado visible hasta que previene un desastre que nadie sabe que se avecina.
En tercer lugar, la identidad. Los científicos de datos están capacitados como constructores de modelos. Las herramientas, los cursos, las tablas de clasificación de Kaggle, las preguntas de la entrevista: todos se centran en el modelado. La formulación del problema se siente como el trabajo de otra persona (producto, negocio, estrategia). Reclamarlo significa salir de su identidad técnica, y eso es incómodo.
Andrew Ng nombró este patrón cuando presentó el concepto de Inteligencia Artificial (IA) centrada en datos en 2021. Lo definió como “la disciplina de diseñar sistemáticamente los datos necesarios para construir un sistema de IA exitoso”. Su argumento: la comunidad de ML había pasado una década obsesionada con la arquitectura de modelos mientras trataba los datos (y, por extensión, la definición de problemas) como el trabajo de otra persona. Los beneficios de las mejores arquitecturas se habían estancado. Los beneficios de una mejor definición de los problemas apenas se habían aprovechado.
El hombre de acero para el tuning
Antes de continuar: el ajuste de hiperparámetros no es inútil. Hay situaciones en las que es exactamente lo correcto.
Si ya ha validado que su variable objetivo se correlaciona directamente con una decisión empresarial. Si su distribución de datos en producción coincide con la capacitación. Si ha confirmado que sus funciones capturan la señal que le interesa a la empresa (y solo esa señal). Si todo esto es cierto, entonces ajustar la capacidad, la regularización y la tasa de aprendizaje del modelo es una optimización legítima.
El reclamo no es "nunca sintonices". La afirmación es: la mayoría de los equipos comienzan a realizar ajustes antes de ganarse el derecho a hacerlo. Se saltan el trabajo de encuadre que determina si la sintonización tendrá alguna importancia. Y cuando la sintonización produce ganancias marginales en un problema mal planteado, esas ganancias son ilusorias.
La investigación de análisis de datos muestra claramente el patrón: una vez que se ha logrado el 95% del rendimiento posible con la configuración básica, pasar días para extraer otro 0,5% rara vez justifica el costo computacional. Ese cálculo empeora cuando el 95% se mide con respecto al objetivo equivocado.
El protocolo de formulación de problemas de cinco pasos
Este protocolo se ejecuta antes de cualquier modelado. Tarda de 2 a 5 días dependiendo de la disponibilidad de las partes interesadas. Cada paso produce un artefacto escrito al que su equipo puede hacer referencia y desafiar. Si salta un paso, estará apostando a que sus suposiciones son correctas. La mayoría no lo es.
Paso 1: Nombre la decisión (no la predicción)
Quién: Líder de ciencia de datos + la parte interesada del negocio que actuará sobre el resultado del modelo.
Cuándo: Primera reunión. Antes de cualquier exploración de datos.
Cómo: Haz esta pregunta y escribe la respuesta palabra por palabra:
"Cuando este modelo produce un resultado, ¿qué decisión específica cambia? ¿Quién toma esa decisión y qué hacen de manera diferente?"
Ejemplo (bueno): "El equipo de retención llama a los 200 principales clientes en riesgo cada semana en lugar de enviar correos electrónicos a los 5000. El modelo clasifica a los clientes según la probabilidad de reactivación para que el equipo sepa a quién llamar primero".
Ejemplo (malo): "Queremos predecir la deserción". (No se menciona ninguna decisión. No se identifica ningún actor. No se especifica ninguna acción).
Señal de alerta: si la parte interesada no puede nombrar una decisión específica, el proyecto aún no tiene un caso de uso. Pausa. No continúe con la exploración de datos. Un modelo sin decisión es un informe que nadie lee.
Paso 2: Definir la asimetría del costo del error
Quién: Líder de ciencia de datos + parte interesada del negocio + finanzas (si está disponible).
Cuándo: Misma reunión o al día siguiente.
Cómo: Preguntar:
"¿Qué es peor: un falso positivo o un falso negativo? ¿En cuánto?"
Ejemplo: para un modelo de detección de fraude, un falso negativo (fraude no detectado) le cuesta a la empresa un promedio de 4200 dólares por incidente. Un falso positivo (bloquear una transacción legítima) cuesta $12 en tiempo de servicio al cliente más un 3% de probabilidad de perder al cliente (valor esperado de $180). La proporción es aproximadamente 23:1. Esto significa que el modelo debe ajustarse para recordar, no para ser preciso, y el umbral de decisión debe establecerse muy por debajo de 0,5.
Por qué esto es importante: las métricas de ML predeterminadas (precisión, F1) asumen costos de error simétricos. Los problemas empresariales reales casi nunca tienen costes de error simétricos. Si optimiza F1 cuando su relación de costos real es 23:1, construirá un modelo que funcionará bien en papel y mal en producción. Zestimate de Zillow trató las sobreestimaciones y las subestimaciones como igualmente malas. No lo eran. Pagar de más por una casa que no se puede revender durante meses es catastróficamente peor que ofertar menos y perder un trato.
Paso 3: auditar la variable objetivo
Quién: líder en ciencia de datos + experto en el dominio.
Cuándo: Después de documentar los pasos 1 y 2. Antes de cualquier ingeniería de características.
Cómo: Responda estas cuatro preguntas por escrito:
¿Esta variable objetivo realmente mide lo que le importa a la empresa? "Curn" puede significar "suscripción cancelada" en sus datos, pero "dejó de usar el producto" en la mente de la parte interesada. Estas son poblaciones diferentes. Aclare cuál se relaciona con la decisión del Paso 1. ¿Cuándo se observa el objetivo en relación con el momento en que el modelo debe actuar? Si predice una deserción de 30 días pero el equipo de retención necesita 14 días para intervenir, su ventana de predicción es incorrecta. El modelo debe predecir la deserción al menos 14 días antes de que ocurra. ¿El objetivo está contaminado por la intervención que intenta optimizar? Si los esfuerzos de retención anteriores ya redujeron la deserción de algunos clientes, sus datos de capacitación subestiman su verdadero riesgo de deserción. El modelo aprende que "estos clientes no abandonan" cuando la verdad es "estos clientes no abandonan porque intervinimos". Esta es la trampa de la inferencia causal y es invisible en las divisiones estándar entre tren y prueba. ¿Puede el modelo aprender la señal correcta o encontrará atajos? El problema del gobernante en dermatología. Enumere las características. Para cada uno, pregunte: "¿Un experto en el dominio utilizaría esta función para tomar esta decisión?" De lo contrario, podría ser un proxy que no se generalizará.
Paso 4: Simular la decisión de implementación
Quién: Equipo completo del proyecto (DS, ingeniería, producto, partes interesadas del negocio).
Cuándo: Después de documentar los pasos 1 a 3. Antes de que comience el modelaje.
Cómo: Ejecute un ejercicio teórico. Presente al equipo 10 resultados del modelo sintético (una combinación de predicciones correctas, falsos positivos y falsos negativos) y pregunte:
“Ante este resultado, ¿qué medidas adopta la empresa?” “¿Es esa acción correcta dada la verdad sobre el terreno?” "¿Cuánto cuesta cada tipo de error?" “¿A partir de qué umbral de confianza la empresa deja de confiar en el modelo?”
Este ejercicio pone de manifiesto desalineaciones que ninguna métrica puede detectar. Es posible que descubra que la empresa realmente necesita una clasificación (no una clasificación binaria). O que la parte interesada no actuará según las predicciones inferiores al 90% de confianza, lo que significa que se ignora la mitad del resultado de su modelo. O que la “acción” requiere información que el modelo no proporciona (como por qué un cliente está en riesgo).
Artefacto: una lista de especificaciones de implementación de una página: quién usa la salida, en qué formato, con qué frecuencia, con qué umbral de confianza y qué sucede cuando el modelo es incorrecto.
Paso 5: escriba el antiobjetivo
Quién: líder en ciencia de datos.
Cuándo: Después de los pasos 1 a 4. La última comprobación antes de comenzar el modelado.
Cómo: Escribe un párrafo respondiendo:
"Si este proyecto tiene éxito en todas las métricas que hemos definido pero aún falla en producción, ¿qué salió mal?"
Ejemplo 1: "El modelo de abandono alcanza 0,91 AUC en el conjunto de pruebas, pero el equipo de retención lo ignora porque las predicciones llegan 48 horas después de su reunión de planificación semanal. El modelo es preciso pero operativamente inútil porque no alineamos la cadencia de predicción con la cadencia de decisión".
Ejemplo 2: "El modelo de fraude detecta el 15% de las transacciones, lo que abruma al equipo de revisión. Comienzan a aprobar aprobaciones para despejar la cola. Técnicamente, el modelo detecta el fraude; en la práctica, los humanos involucrados han aprendido a ignorarlo".
El anti-objetivo es una inversión: en lugar de definir el éxito, define el fracaso más plausible. Si puedes escribir un anti-objetivo vívido, a menudo podrás evitarlo. Si no puede escribir uno, no ha pensado lo suficiente en la implementación.
¿Es esto un problema de ajuste o un problema de encuadre?
No todos los proyectos estancados necesitan ser replanteados. A veces el problema está bien planteado y realmente se necesita un mejor rendimiento del modelo. Utilice este diagnóstico para notar la diferencia.
¿Qué cambia cuando los equipos encuadran primero?
El cambio del trabajo centrado en modelos al trabajo centrado en problemas no se trata sólo de evitar el fracaso. Cambia lo que significa "senior" en la ciencia de datos.
Los científicos de datos jóvenes son valorados por sus habilidades de modelado: ¿pueden entrenar, ajustar e implementar? Los científicos de datos senior deben ser valorados por su habilidad de enmarcar: ¿pueden traducir una situación empresarial ambigua en un problema de predicción bien planteado con el objetivo correcto, las características correctas y los criterios de éxito correctos?
La industria se está poniendo al día lentamente. El impulso de Andrew Ng hacia la IA centrada en datos es una señal. El informe de 2024 de RAND Corporation sobre antipatrones de IA es otra: su principal recomendación es que los líderes se aseguren de que el personal técnico comprenda el propósito y el contexto de un proyecto antes de comenzar. El análisis de QCon de 2024 sobre las fallas de ML menciona los “objetivos desalineados” como el error más común.
El patrón es claro. El cuello de botella del aprendizaje automático no son los algoritmos. Es la alineación entre el objetivo del modelo y la necesidad real del negocio. Y esa alineación es una conversación humana, no computacional.
El cuello de botella en el aprendizaje automático no son los cálculos ni los algoritmos. Es la conversación entre la persona que construye el modelo y la persona que utiliza el resultado.
Para las organizaciones, esto significa que la formulación de problemas debe ser una actividad de primera clase con su propia asignación de tiempo, sus propios resultados y su propio proceso de revisión. No es un preámbulo del "trabajo real". El verdadero trabajo.
Para los científicos de datos individuales, significa que la forma más rápida de aumentar su impacto no es aprender un nuevo marco ni dominar la capacitación distribuida. Es aprender a hacer mejores preguntas antes de abrir un cuaderno.
Son las 11:14 de la noche de un miércoles. Llevas tres semanas en un proyecto. Su métrica de validación está subiendo. Estás a punto de lanzar otro barrido.
Detener.
Abra un documento en blanco. Escriba una oración: "La decisión que cambia según el resultado de este modelo es ___". Si no puede completar el espacio en blanco sin llamar a una parte interesada, acaba de encontrar la actividad con mayor retorno de la inversión para mañana por la mañana. No se sentirá como un progreso. No producirá una captura de pantalla digna de Slack. Pero es el único trabajo que determina si las próximas tres semanas importan o no.
Referencias
RAND Corporation, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed”, James Ryseff, Brandon De Bruhl, Sydne J. Newberry, 2024. MIT Sloan, “Why It's Time for 'Data-Centric Artificial Intelligence'”, Sara Brown, junio de 2022. insideAI News, “The $500mm+ Debacle at Zillow Offers: What Went Wrong with the ¿Modelos de IA?”, diciembre de 2021. Escuela de Graduados en Negocios de Stanford, “Flip Flop: Why Imploded Algorithmic Home Buying Venture” de Zillow. Diagnostics (MDPI), “Descubriendo y corrigiendo el aprendizaje abreviado en modelos de aprendizaje automático para el diagnóstico de cáncer de piel”, 2022. VentureBeat, “Cuando la IA marca la regla, no el tumor”. InfoQ, “QCon SF 2024: Por qué los proyectos de aprendizaje automático no logran alcanzar la producción”, noviembre de 2024. Number Analytics, “8 conocimientos de ajuste de hiperparámetros respaldados por análisis de datos”.