Costes hundidos en ciencia de datos: cuándo mantener un modelo y cuándo migrar

Imagina la situación. Tu equipo lleva tres años con un modelo en producción. No es el estado del arte, pero funciona: predice razonablemente bien, el pipeline de datos está estabilizado, el sistema de monitorización detecta la mayoría de las derivas, y todo el mundo sabe cómo tocarlo sin romper nada. Es el tipo de sistema que genera confianza silenciosa — nadie habla de él porque no da problemas.

Entonces aparece algo nuevo. Puede ser una arquitectura que acaba de publicarse en un paper, un framework que la comunidad ha adoptado masivamente en los últimos meses, o simplemente la constatación de que el enfoque que usasteis ya no es el que elegiríais hoy. Alguien en el equipo plantea la pregunta inevitable: ¿no deberíamos migrar a algo más moderno?

Y antes de que nadie haya abierto un notebook, antes de que se haya evaluado nada, aparece la primera respuesta. No viene de un análisis técnico. Viene de un lugar más visceral:

“Pero si llevamos tres años con esto…”

“Hemos invertido muchísimo tiempo en ajustar este pipeline…”

“El modelo ya lo conocemos bien, sería empezar de cero…”

Estas frases suenan a prudencia técnica. Suenan a experiencia. Pero en muchos casos encubren algo diferente: la falacia del coste hundido aplicada a decisiones de ingeniería de modelos.

Este entrada trata justamente de eso: de cómo un sesgo cognitivo bien documentado en economía contamina silenciosamente las decisiones técnicas en ciencia de datos, cómo identificarlo cuando ocurre, y cómo construir un marco de decisión que lo neutralice.

En Analytics Lane

Nuevo test de normalidad interactivo en el laboratorio de Analytics Lane

Qué es un coste hundido

Antes de aplicar el concepto al mundo del machine learning, conviene definirlo con precisión, porque se malinterpreta con frecuencia.

Un coste hundido (sunk cost en inglés) es cualquier recurso ya consumido que no puede recuperarse independientemente de la decisión que tomes a partir de ahora. Tiempo, dinero, esfuerzo, atención — si ya se gastaron y no hay forma de recuperarlos, son costes hundidos.

La conclusión económica es tan simple como incómoda: los costes hundidos no deberían influir en ninguna decisión racional futura. La única información relevante para una decisión es lo que ocurre a partir del momento en que la tomas: los beneficios esperados de cada opción y los costes futuros de cada camino. El pasado, en tanto que irrecuperable, es irrelevante.

Esto choca frontalmente con nuestra intuición. El ejemplo clásico es la entrada de cine: pagas diez euros por una película que a los treinta minutos resulta ser horrible. La decisión racional es irte. Los diez euros ya están perdidos tanto si te quedas como si te vas. Quedarte solo añade tiempo perdido al dinero perdido. Y sin embargo, la mayoría de las personas se quedan — porque “ya han pagado” y marcharse se siente como un desperdicio.

Ese mismo mecanismo, trasladado a decisiones de ingeniería con mucho más en juego, produce errores mucho más costosos.

La falacia del coste hundido es precisamente eso: el error de dejar que recursos irrecuperables del pasado distorsionen decisiones que deberían basarse exclusivamente en el futuro. No es irracionalidad aleatoria — es un patrón predecible y bien documentado en economía del comportamiento. Y en ciencia de datos, tiene formas de manifestarse que son especialmente difíciles de detectar porque se disfrazan de argumentos técnicos legítimos.

Cómo se manifiesta la falacia en proyectos de machine learning

La particularidad de los proyectos de ML es que acumulan costes hundidos en capas. No es solo el tiempo de entrenamiento inicial — es el tuning, las iteraciones, las pruebas fallidas, las integraciones, el conocimiento tácito del equipo, la documentación. Cada capa añade peso emocional a la decisión de cambiar. Y ese peso se filtra en el razonamiento técnico de formas que conviene identificar.

Patrón 1: “Ya tenemos el pipeline montado”

Este es el argumento más frecuente y, en su forma más pura, el más claro ejemplo de falacia.

El pipeline de datos — ingesta, transformación, feature engineering, validación — representa semanas o meses de trabajo. Está testeado, tiene sus quirks documentados, y el equipo sabe exactamente en qué puntos puede fallar. Cuando alguien propone migrar el modelo a una arquitectura diferente que implicaría rehacerlo, la resistencia es inmediata: ”¿Sabes el trabajo que nos costó montar esto?”

El problema es que esa frase mira hacia atrás. La pregunta relevante no es cuánto costó montarlo, sino cuánto costaría rehacerlo ahora y qué se gana a cambio. Si el pipeline existente tiene deuda técnica acumulada, si está acoplado a decisiones de diseño que ya no tienen sentido, si mantenerlo tiene un coste operativo creciente — todo eso son argumentos prospectivos perfectamente válidos para migrar. Pero “ya lo tenemos” no lo es.

Pero hay una sutileza importante: que el pipeline existente tenga valor real (documentación sólida, tests, estabilidad probada) sí es un argumento legítimo para quedarse, pero debe cuantificarse y compararse con los beneficios de migrar. Lo que no vale como argumento es simplemente su existencia como resultado del esfuerzo pasado.

Patrón 2: “Este modelo ya lo conocemos bien”

El conocimiento acumulado sobre un modelo concreto — sus puntos ciegos, sus condiciones de fallo, sus rangos de operación seguros — tiene valor real. No es un coste hundido en sentido estricto: es un activo que el equipo posee y que puede aplicar a futuras iteraciones.

Pero este argumento se pervierte cuando se usa para evitar el coste de aprender algo nuevo, en lugar de para cuantificar el valor real de lo que se conoce.

La distinción importa: si el conocimiento acumulado sobre el modelo actual es transferible al nuevo (comprensión del dominio, intuiciones sobre las features, experiencia con los patrones de deriva), entonces su valor no desaparece con la migración — se reutiliza. Si en cambio es conocimiento muy específico sobre los artefactos de una implementación concreta (este hiperparámetro concreto en esta versión de esta librería), entonces su valor sí desaparece, pero eso no es argumento para quedarse — es simplemente un coste de transición a incluir en el análisis.

Donde aparece la falacia es cuando el argumento es “nos costó mucho aprenderlo” en lugar de “lo que sabemos vale X y perderíamos Y al migrar”.

Patrón 3: “Hemos ajustado esto durante años”

El tuning de hiperparámetros, la selección de features, el ajuste de umbrales de decisión — en modelos complejos sobre dominios difíciles, esto puede representar un trabajo enorme. Y hay una tentación natural de tratar ese trabajo como un argumento en sí mismo para no cambiar.

Aquí el error es confundir estabilidad con bondad técnica. Un modelo muy ajustado puede estar sobreajustado al comportamiento histórico de los datos, incluyendo sus anomalías. El hecho de que funcione en producción no significa que sea el mejor enfoque posible — significa que el equipo ha aprendido a hacerlo funcionar. Eso tiene valor, pero no es lo mismo que valor intrínseco de la arquitectura.

El argumento correcto sería: “El tuning actual nos da un rendimiento de X, replicar ese rendimiento en la nueva arquitectura estimamos que costaría Y tiempo, y la ganancia esperada es Z.” Eso es análisis racional. “Hemos invertido años en esto” no lo es.

Patrón 4: El coste hundido colectivo

Hay una dimensión organizacional que merece mención aparte: cuando el coste hundido no es solo técnico sino político o reputacional.

Si un modelo fue una apuesta grande del equipo, si se presentó internamente como una solución estratégica, si hay personas cuya identidad profesional está vinculada a esa tecnología — migrar implica implícitamente reconocer que aquella elección fue subóptima. El coste hundido se convierte en coste reputacional, y eso añade otra capa de resistencia que raramente se nombra de forma explícita pero que contamina el análisis técnico.

Este patrón es particularmente difícil de detectar porque se racionaliza con facilidad. El argumento que se verbaliza es técnico; el argumento real es proteger una narrativa. Identificarlo requiere una honestidad organizacional que no siempre es cómoda.

El test racional: la pregunta que corta el ruido

Para cualquier decisión de migración o mantenimiento de modelo, existe una pregunta que neutraliza de forma eficaz la influencia de los costes hundidos:

Si empezaras este proyecto desde cero hoy, con el conocimiento actual, ¿elegirías esta arquitectura y esta tecnología?

La respuesta a esta pregunta no determina automáticamente qué hacer — pero sí determina qué argumentos son válidos.

Si la respuesta es sí, entonces mantener el modelo actual es probablemente la decisión correcta, y los costes hundidos no tienen ningún papel en ese razonamiento. El sistema existe, funciona, y lo elegirías de nuevo. No hay problema.

Si la respuesta es no, entonces la conversación correcta es sobre costes y beneficios futuros: ¿cuánto cuesta migrar? ¿Qué se gana? ¿En qué horizonte temporal? ¿Cuál es el coste de no migrar (deuda técnica, mantenimiento creciente, riesgo de obsolescencia)? Todas esas son preguntas legítimas con respuestas que pueden justificar tanto migrar como quedarse. Lo que no es legítimo como argumento es el esfuerzo pasado.

El test funciona porque obliga a separar dos cosas que tendemos a mezclar: la evaluación de la tecnología en sí, y el coste de transición hacia algo diferente. Ambas son relevantes, pero son independientes y deben analizarse por separado.

Deuda técnica como coste hundido acumulado

Hay una conexión entre la falacia del coste hundido y el concepto de deuda técnica que no suele hacerse explícita, y que creo que es especialmente relevante para proyectos de ML.

La deuda técnica — en su sentido más amplio — es el coste futuro que pagas como consecuencia de decisiones pasadas que priorizaron la velocidad o la conveniencia sobre la calidad estructural. En software general está bien documentada. En machine learning tiene características propias que la hacen especialmente peligrosa.

Un modelo de ML no es solo código: es código más datos más artefactos de entrenamiento más decisiones de diseño implícitas en su arquitectura. Cada uno de esos componentes puede acumular deuda. Y a diferencia del software general, parte de esa deuda es invisible: está codificada en los sesgos del conjunto de entrenamiento, en las features que se incluyeron sin justificación rigurosa, en los umbrales que se ajustaron a mano para resolver un caso edge y que nadie recuerda por qué tienen ese valor.

La conexión con los costes hundidos es esta: cada vez que un equipo decide no migrar o no refactorizar porque “ya está montado”, está convirtiendo el coste hundido actual en deuda técnica futura. El coste hundido de hoy es el interés que pagarás mañana.

Esto tiene una implicación práctica importante: el coste de migrar no es estático. Tiende a crecer con el tiempo, porque la deuda técnica se acumula y porque el ecosistema sigue evolucionando mientras el sistema permanece estático. Un análisis honesto de costes de migración debe incluir esta dinámica temporal — no es lo mismo migrar ahora que dentro de dos años.

La deuda técnica específica de ML

En proyectos de machine learning, la deuda técnica toma formas particulares que vale la pena enumerar:

• Deuda en features: Features que se añadieron en un momento dado porque correlacionaban con el target, pero cuya relación causal nunca se validó. Con el tiempo, esas correlaciones pueden desaparecer o invertirse, y el modelo degrada silenciosamente. Migrar a una arquitectura más moderna que fuerza una revisión del feature engineering puede descubrir que parte del rendimiento actual descansa sobre arena.
• Deuda en datos de entrenamiento: El conjunto de entrenamiento original puede contener sesgos históricos que el modelo ha aprendido y reproduce. Cuanto más tiempo lleva el modelo en producción, más difícil es separar qué parte del rendimiento se debe a la arquitectura y qué parte a la calidad del conjunto de entrenamiento.
• Deuda en integración: Los sistemas en producción tienden a acumular dependencias. El modelo se integra con un sistema de logging, con un pipeline de monitorización, con una API interna que tiene sus propias versiones y contratos. Cada integración añadida es una deuda de migración futura.
• Deuda en conocimiento: El conocimiento sobre por qué el modelo funciona como funciona tiende a concentrarse en pocas personas y a no estar documentado. Cuando esas personas cambian de rol o de empresa, el equipo hereda un sistema que funciona pero que nadie entiende del todo. Migrar en ese contexto es especialmente costoso, pero no migrar perpetúa la concentración de conocimiento.

Construir el análisis correcto: costes y beneficios futuros

Una vez identificada la falacia y aplicado el test racional, la pregunta que queda es cómo estructurar el análisis de la decisión real. Aquí propongo un marco en tres ejes.

Eje 1: Coste de migración

Este es el eje que más atención recibe, y con razón — pero tiende a subestimarse porque se calcula de forma incompleta.

El coste de migración visible incluye: tiempo de desarrollo para implementar la nueva arquitectura, tiempo de validación y testing, coste de reentrenamiento, periodo de operación en paralelo durante la transición, y coste de actualizar la documentación y los procesos.

El coste de migración invisible — el que se omite con más frecuencia — incluye: el tiempo de aprendizaje del equipo si la nueva tecnología es desconocida, el coste de los errores que inevitablemente aparecen durante la transición, el impacto en otros proyectos del equipo durante el periodo de migración, y el riesgo de regresión en métricas de negocio durante la transición.

Un análisis honesto debe intentar cuantificar ambos. Los costes invisibles tienden a multiplicar los visibles por un factor que varía según la complejidad del sistema y la experiencia del equipo con la nueva tecnología.

Eje 2: Beneficio esperado de migrar

Este eje tiende a sobreestimarse en la dirección contraria: cuando hay entusiasmo con una nueva tecnología, el beneficio esperado se infla.

Los beneficios legítimos de migrar pueden incluir: mejora en métricas de rendimiento del modelo, reducción del coste de mantenimiento operativo, mejor alineación con el ecosistema actual (más soporte, más documentación, más talento disponible), reducción de riesgo técnico por obsolescencia, y mejora en la capacidad de iterar rápido en el futuro.

Para cada uno de estos beneficios, la pregunta relevante es cuándo se materializa y con qué probabilidad. Un beneficio de rendimiento que solo aparece tras seis meses de tuning en la nueva arquitectura tiene un valor presente diferente al de un beneficio inmediato.

Eje 3: Coste de no migrar

Este es el eje que más frecuentemente se omite en el análisis, y es donde la dinámica temporal se vuelve crítica.

El coste de no migrar no es cero y no es estático. Incluye: el coste de mantenimiento creciente de un sistema sobre tecnología que pierde soporte activo, el riesgo de no poder incorporar mejoras futuras, el coste de oportunidad de no tener las capacidades que la nueva arquitectura permitiría, y la acumulación de deuda técnica con interés compuesto.

En el contexto específico del machine learning, hay un coste adicional que merece mención: el coste de deriva del modelo frente a un entorno cambiante. Un modelo estático en un dominio dinámico pierde rendimiento con el tiempo. Si la nueva arquitectura ofrece mecanismos más robustos de adaptación continua, el coste de no migrar incluye esa degradación acumulada.

Combinando los tres ejes

La decisión racional es migrar cuando:

Beneficio esperado de migrar > Coste de migración + Coste de oportunidad del tiempo de migración

Y la decisión racional es quedarse cuando la desigualdad se invierte. Pero hay dos condiciones adicionales que modifican este análisis simple:

• Condición temporal: Si el coste de migrar crece más rápido que el beneficio de quedarse, hay un punto óptimo de migración que puede no ser ahora pero que no es nunca. Retrasar indefinidamente no es una estrategia — es acumulación de deuda con interés.
• Condición de reversibilidad: Una migración que puede hacerse de forma incremental, con rollback posible en cada paso, tiene un perfil de riesgo muy diferente a una migración big bang. El coste de migración en el primer caso es menor y el riesgo es mucho más controlable. Antes de decidir si migrar, vale la pena analizar cómo migrar.

El papel de la monitorización en la decisión

Un aspecto que suele omitirse en esta discusión es el papel que juega la monitorización existente del modelo en la decisión de migrar o mantener.

Un sistema bien monitorizado — con alertas de deriva de datos, seguimiento de métricas de rendimiento en producción, logging detallado de predicciones — proporciona información objetiva sobre el estado real del modelo. Esa información es exactamente lo que necesitas para construir el análisis de costes y beneficios con datos reales en lugar de suposiciones.

Si el modelo está degradando silenciosamente — si las métricas de producción muestran una tendencia a la baja aunque no haya alertas activas — eso es un argumento prospectivo concreto y cuantificable para migrar. No es el coste hundido del pasado: es el coste presente y creciente de mantenerse.

Si en cambio el modelo mantiene sus métricas estables y el sistema funciona con un coste de mantenimiento bajo y predecible, eso también es información objetiva — e inclina la balanza hacia quedarse, al menos hasta que aparezca un beneficio claro de migrar.

La monitorización, en este sentido, es la herramienta que convierte una decisión contaminada por sesgos cognitivos en una decisión basada en evidencia. Equipos sin monitorización robusta son más vulnerables a la falacia del coste hundido porque no tienen datos objetivos con los que contrastar los argumentos emocionales.

Un ejemplo de análisis estructurado

Para hacer concreto el marco anterior, recorramos un escenario hipotético con suficiente detalle para que sea útil.

• El escenario: Un equipo tiene en producción un modelo de clasificación entrenado hace cuatro años. El modelo predice la probabilidad de abandono de clientes. Funciona: tiene una AUC de 0.78 en producción, y el equipo lo conoce bien. La nueva incorporación al equipo, que viene de un contexto más actualizado, señala que arquitecturas más modernas podrían mejorar ese número significativamente, y que el framework actual está perdiendo soporte activo de la comunidad.
• Aplicando el test racional: ¿Elegiríais hoy este framework y esta arquitectura para un problema de clasificación tabular? Probablemente no — hay alternativas más mantenidas, con mejor ecosistema, y potencialmente con mejor rendimiento. El test dice: la conversación debe ser sobre futuro, no sobre pasado.
• Analizando el eje de costes de migración: El pipeline de features es complejo y tiene dependencias internas. Replicarlo en la nueva arquitectura se estima en seis semanas de desarrollo. La validación y el periodo de operación en paralelo añaden otras cuatro semanas. El equipo no tiene experiencia con el nuevo framework, lo que añade un coste de aprendizaje estimado en dos o tres semanas efectivas.
  • Total visible: aproximadamente tres meses de esfuerzo distribuido.
  • Costes invisibles: el riesgo de regresión durante la transición (que puede cuantificarse con el impacto económico de un punto de AUC), el impacto en otros proyectos del equipo durante esos tres meses, y el coste de actualizar todos los procesos de monitorización.
• Analizando el eje de beneficios esperados: La mejora de rendimiento esperada es incierta — se habla de potencialmente llegar a AUC 0.83, pero eso requiere tuning que llevará tiempo. El beneficio más concreto e inmediato es reducir el coste de mantenimiento: el framework actual ya no recibe actualizaciones de seguridad activas, lo que crea un riesgo técnico creciente. El beneficio de ecosistema también es real: hay más documentación disponible, más talento en el mercado con experiencia en el nuevo stack.
• Analizando el eje del coste de no migrar: El riesgo de seguridad del framework sin soporte activo crece con el tiempo. El coste de mantenimiento ha aumentado un 30% en el último año por incompatibilidades con actualizaciones del sistema. La degradación de rendimiento del modelo es lenta pero detectable: la AUC ha bajado de 0.81 a 0.78 en dos años sin cambios en el modelo, lo que sugiere deriva acumulada.
• La conclusión del análisis: El coste de migrar es significativo pero acotado. El beneficio principal no es el rendimiento (incierto) sino la reducción del riesgo técnico (concreto) y la tendencia de degradación ya observable. El coste de no migrar crece. La decisión racional apunta a migrar, pero con una estrategia incremental que minimice el riesgo: migrar el pipeline de features primero, validar en paralelo, y migrar el modelo solo cuando el nuevo pipeline esté estabilizado.

Nótese que en ningún momento del análisis aparece el argumento “llevamos cuatro años con esto”. No porque sea incorrecto recordarlo, sino porque no aporta información relevante para la decisión.

Cuándo quedarse es la decisión correcta

Esta entrada trata principalmente de identificar la falacia del coste hundido, pero sería un análisis incompleto si no aclarara explícitamente que quedarse con el modelo actual puede ser perfectamente la decisión correcta — y no por las razones equivocadas.

Quedarse es racional cuando:

• El modelo funciona y el coste de migración es alto en relación al beneficio. Esto es especialmente frecuente cuando la nueva alternativa ofrece mejoras marginales en rendimiento pero requiere reescribir infraestructura crítica. La estabilidad tiene valor real.
• El dominio es estable y el modelo no está degradando. Si los datos no derivan, si el rendimiento se mantiene, y si el coste de mantenimiento es predecible y bajo — no hay urgencia de migrar. La curiosidad técnica no es un argumento de negocio.
• El equipo no tiene capacidad de asumir la transición sin impacto severo en otras prioridades. El coste de oportunidad del tiempo del equipo es real. Una migración que paraliza durante tres meses puede no ser el mejor uso de esos tres meses aunque técnicamente sea la decisión correcta en abstracto.
• La nueva alternativa no está suficientemente madura. Adoptar tecnología en fases tempranas de su ciclo de vida tiene costes ocultos: APIs inestables, bugs no descubiertos, falta de documentación, comunidad pequeña. En ese caso, esperar no es falacia del coste hundido — es gestión sensata del riesgo.

La diferencia entre estas razones válidas para quedarse y la falacia del coste hundido es siempre la misma: las razones válidas son prospectivas. No dicen nada sobre el pasado. Solo dicen que el futuro esperado de quedarse es mejor que el futuro esperado de migrar.

Señales de alerta en tu propio razonamiento

Para terminar este análisis, un checklist práctico. Si en una discusión sobre migración de modelo escuchas — o te descubres usando — alguno de estos argumentos, es una señal de alerta que merece examen:

• “Llevamos X años con esto”: La duración de una inversión no determina su valor futuro. Pregúntate qué argumentos prospectivos respaldan la decisión de quedarse.
• “Hemos invertido muchísimo en esto”: El volumen de inversión pasada es irrelevante para la decisión futura. Pregúntate cuánto costaría rehacerlo ahora y qué se ganaría.
• “Este modelo ya lo conocemos bien”: Cuantifica el valor de ese conocimiento: ¿cuánto de él es transferible? ¿Cuánto es específico a la implementación actual?
• “Sería empezar de cero”: Rara vez es literalmente cierto. El conocimiento del dominio, las métricas de referencia, la comprensión de los fallos — todo eso no desaparece con la migración. Analiza qué se pierde realmente.
• “Ahora mismo no es el momento”:Puede ser perfectamente válido. Pero si “ahora mismo” lleva años siendo la respuesta, probablemente no es gestión del timing — es evitación del coste.
• “Funciona, ¿para qué cambiarlo?”: Esta es quizás la más peligrosa porque tiene una lógica superficial sólida. Funcionar no es lo mismo que ser óptimo ni que tener un coste de oportunidad cero. La pregunta relevante no es si funciona, sino si seguirá funcionando y a qué coste.

Conclusiones

La falacia del coste hundido en machine learning no es un problema de falta de conocimiento técnico — es un problema de cómo estructuramos el razonamiento sobre decisiones que involucran inversiones pasadas significativas.

Los equipos técnicos son, en general, buenos evaluando arquitecturas. Son menos buenos separando esa evaluación de la historia emocional del proyecto. Y esa dificultad no es una debilidad personal: es el resultado predecible de cómo funcionan los sesgos cognitivos bajo condiciones de incertidumbre y presión.

El antídoto no es ignorar el pasado — es ser explícito sobre qué argumentos pertenecen al análisis racional y cuáles son residuos emocionales de inversiones anteriores. El test de la pregunta contrafactual (¿lo elegirías hoy?) y el marco de análisis en tres ejes (coste de migrar, beneficio de migrar, coste de no migrar) son herramientas sencillas pero efectivas para estructurar esa separación.

Imagen de rumpel en Pixabay