Hace poco publiqué una entrada en la que trataba de un sesgo bien documentado: aferrarse a sistemas existentes porque el esfuerzo pasado pesa más de lo que debería en la toma de decisión. La falacia del coste hundido aplicada a modelos de aprendizaje automático en producción produce inercia técnica, deuda acumulada, y decisiones de mantenimiento que se justifican con argumentos que miran al pasado en lugar de al futuro.
Pero hay un error simétrico que merece el mismo análisis, y que en entornos técnicos puede ser igual de frecuente y costoso: migrar hacia lo nuevo sin análisis riguroso, impulsado por entusiasmo tecnológico más que por razonamiento prospectivo.
Este error no tiene un nombre tan establecido en economía del comportamiento como la falacia del coste hundido, pero en ingeniería de software se conoce informalmente como el síndrome del objeto brillante (shiny object syndrome): la tendencia a sobrevalorar lo nuevo por el simple hecho de serlo, subestimando los costes reales de adopción y sobreestimando los beneficios esperados.
En ciencia de datos, este síndrome es especialmente prevalente por razones estructurales: el campo avanza rápido, los papers se publican continuamente, los benchmarks se baten con frecuencia, y existe una presión cultural — a veces explícita, a veces implícita — de estar al día con el estado del arte. En ese contexto, la resistencia a adoptar algo nuevo puede percibirse como conservadurismo técnico, cuando en realidad puede ser exactamente lo contrario: análisis riguroso.
Tabla de contenidos
Antes de analizar cómo se manifiesta el síndrome en proyectos concretos, vale la pena entender por qué ocurre. No es irracionalidad aleatoria — tiene mecanismos predecibles.
Cuando aparece una tecnología nueva, la comparación natural es contra la versión más deteriorada del sistema existente. El modelo en producción lleva años sin actualizarse, tiene deuda técnica acumulada, y sus métricas de producción incluyen la degradación natural por deriva. La nueva alternativa se evalúa en su mejor versión: los benchmarks del paper, implementada sobre datos limpios, con el tuning óptimo reportado por sus autores.
Esta comparación es estructuralmente injusta. Estás comparando el peor estado del sistema actual contra el mejor estado teórico del nuevo. La diferencia de rendimiento que observas no refleja únicamente la diferencia entre arquitecturas — refleja también años de mantenimiento diferido versus condiciones de laboratorio.
Una comparación honesta requeriría comparar el sistema actual bien mantenido y actualizado contra la nueva arquitectura bajo condiciones reales de producción, con sus propios costes de tuning y adaptación al dominio. Esa comparación es mucho más difícil de hacer y casi nunca es la que impulsa la decisión de migrar.
Los resultados que se publican sobre nuevas arquitecturas tienen un sesgo de selección enorme. Los papers reportan los casos en los que la nueva arquitectura funciona bien — los casos en los que no funciona o en los que la mejora es marginal tienen muchos menos incentivos para publicarse. La comunidad ve una corriente de resultados positivos que no representa la distribución real de rendimiento.
Esto es especialmente relevante en machine learning, donde la transferibilidad de los resultados de un benchmark a un problema específico de producción es frecuentemente mucho más baja de lo que sugiere el entusiasmo inicial. Un modelo que bate el estado del arte en un dataset de referencia puede ser mediocre en tu dominio específico, con tus datos, con tus restricciones de latencia y memoria.
Existe una asimetría cognitiva bien documentada entre cómo estimamos costes conocidos y costes desconocidos. Los costes del sistema actual son conocidos y concretos: sabemos cuánto tarda el reentrenamiento, sabemos qué falla y cuándo, sabemos cuánto esfuerzo requiere el mantenimiento mensual. Los costes de adopción del nuevo sistema son inciertos y tendemos a subestimarlos sistemáticamente.
La lista de costes de adopción que más frecuentemente se omiten incluye: el tiempo de aprendizaje real (que casi siempre supera la estimación inicial), los bugs e incompatibilidades que solo aparecen en producción y no en experimentos controlados, el coste de adaptar el ecosistema circundante (monitorización, logging, APIs de integración), y el coste de los proyectos que no se hacen durante el periodo de transición.
El caso más claro es cuando la decisión de migrar se justifica principalmente con métricas de benchmark que no corresponden directamente al problema de producción.
“Esta arquitectura bate el estado del arte en el dataset X con una mejora del 15% en F1” es información real pero de valor limitado para decidir si migrarla tiene sentido en tu contexto. Las preguntas relevantes son: ¿tu problema se parece al dataset X? ¿Esa mejora del 15% se mantiene con tus datos, tu distribución, tus casos edge? ¿Qué parte de esa mejora desaparece tras el proceso de adaptación al dominio? ¿Cuánto tuning requirió conseguir ese número y cuánto costará replicarlo?
La trampa aquí no es que los benchmarks sean irrelevantes — son una señal útil de que una arquitectura tiene potencial. El problema es usarlos como sustituto del análisis de viabilidad en el contexto propio, saltándose el paso de validación en condiciones reales antes de comprometerse con la migración.
Un proceso más sano incluye siempre una fase de experimentación controlada: implementar la nueva arquitectura en un subconjunto del problema, con datos reales, bajo condiciones lo más parecidas posible a producción, antes de tomar ninguna decisión de migración. Los resultados de esa fase son infinitamente más informativos que cualquier benchmark externo.
Este patrón es más sutil y más honesto en su motivación, pero igual de problemático en sus consecuencias: migrar a una nueva tecnología principalmente porque el equipo quiere aprender a usarla, y usar el proyecto de producción como vehículo de aprendizaje.
El deseo de aprender tecnologías nuevas no es irracional — es racional desde la perspectiva del desarrollo profesional individual. El problema es cuando ese interés individual se confunde con interés del proyecto. Un sistema de producción que sirve usuarios reales no es el contexto óptimo para el aprendizaje exploratorio: los errores tienen consecuencias reales, la presión de tiempo reduce la calidad del aprendizaje, y las decisiones de diseño tienden a estar sesgadas hacia lo que facilita el aprendizaje más que hacia lo que resuelve el problema mejor.
El síntoma más claro de este patrón es cuando la justificación principal de la migración es “nos va a permitir aprender X” más que “va a mejorar Y métrica en Z unidades”. El aprendizaje tiene valor real — pero debería gestionarse en proyectos secundarios, en experimentación controlada, en entornos de staging, no en sistemas críticos de producción.
La presión social en comunidades técnicas es real y no siempre opera en la dirección correcta. Cuando una tecnología o arquitectura gana tracción rápidamente, hay un efecto de señal social: si todos la están adoptando, probablemente hay algo ahí. Este razonamiento tiene cierta lógica — la adopción masiva sí revela información sobre utilidad percibida.
El problema es que la adopción masiva también refleja modas, presión de marketing, y el ciclo natural de hype tecnológico que Gartner modeló hace décadas con su curva. Una arquitectura puede estar en el pico del ciclo de expectativas infladas — máxima visibilidad, máximo entusiasmo, mínima experiencia real de producción — exactamente cuando la presión de adoptarla es mayor.
Adoptar en ese momento tiene costes específicos: la tecnología aún no está madura, la documentación es escasa o incorrecta, los patrones de uso en producción no están establecidos, y los errores que vas a cometer son errores que nadie ha cometido antes, por lo que no hay soluciones documentadas. El precio del early adoption lo pagas con tiempo y estabilidad.
Esto no significa esperar siempre a que todo esté perfectamente maduro — hay ventajas reales en adoptar pronto en algunos contextos. Pero la decisión de cuándo adoptar debería estar basada en el análisis del ciclo de madurez de la tecnología específica, no en la presión de lo que parece estar haciendo todo el mundo.
El síndrome del objeto brillante en su forma más extrema: adoptar una tecnología nueva y luego buscar casos de uso donde aplicarla, en lugar del proceso inverso.
En el contexto de los grandes modelos de lenguaje, esto ha sido especialmente visible en los últimos años. La llegada de LLMs con capacidades genuinamente impresionantes generó en muchos equipos una presión para integrarlos en sus sistemas, con la justificación implícita de que si no lo hacías estabas quedándote atrás. El resultado en muchos casos fue integrar LLMs en problemas que se resolvían perfectamente con modelos mucho más simples, más rápidos, más baratos y más interpretables — añadiendo complejidad, latencia y coste sin un beneficio real proporcional.
El diagnóstico de este patrón es relativamente sencillo: si el argumento para adoptar la nueva tecnología precede al análisis del problema que resuelve, probablemente estás en este patrón. La secuencia correcta es siempre: problema → requisitos → evaluación de opciones → decisión. La secuencia del síndrome del objeto brillante es: tecnología nueva → entusiasmo → búsqueda de justificación → adopción.
Hay una dimensión del análisis que suele omitirse cuando se discute si adoptar una nueva tecnología: la asimetría entre el coste de un fallo en producción y el beneficio de una mejora en producción.
En la mayoría de los sistemas de ML en producción, esta asimetría existe y es significativa. Una mejora de rendimiento del 5% en las predicciones produce un beneficio acotado y gradual. Un fallo de producción — predicciones incorrectas, latencia inaceptable, sistema caído — produce daño concentrado e inmediato que puede superar meses de beneficio acumulado.
Esta asimetría implica que el umbral de evidencia para migrar debería ser alto. No basta con que la nueva arquitectura sea probablemente mejor — debería ser claramente mejor bajo condiciones realistas, con suficiente margen como para que incluso si la migración introduce fricciones (y casi siempre lo hace), el resultado neto siga siendo positivo.
La nueva tecnología tiene que ganar bajo condiciones reales, no solo bajo condiciones de laboratorio. Eso requiere experimentación rigurosa antes de comprometerse con la migración, y una estrategia de despliegue que minimice el riesgo: rollouts graduales, operación en paralelo con comparación de predicciones, criterios explícitos de rollback.
Una herramienta útil para estructurar la decisión de cuándo adoptar es pensar en el ciclo de madurez de la tecnología, que en términos generales pasa por fases reconocibles:
Situar la tecnología que estás evaluando en este ciclo — de forma honesta, sin dejarse llevar por el entusiasmo del momento — da información valiosa sobre el perfil de riesgo de la adopción y el timing óptimo.
Hasta aquí hemos hablado del coste directo de migrar (tiempo de desarrollo, riesgo de regresión, coste de aprendizaje). Pero hay un coste que es igualmente real y que se omite con frecuencia: el coste de oportunidad.
Una migración consume recursos del equipo que no están disponibles para otras cosas. Si el equipo tiene capacidad limitada — como casi todos los equipos — migrar a una nueva arquitectura durante tres meses significa no hacer otras tres cosas en esos tres meses. Esas otras cosas tienen valor esperado propio, y ese valor debe incluirse en el análisis.
El coste de oportunidad de una migración es especialmente alto cuando:
Incluir el coste de oportunidad en el análisis frecuentemente cambia la decisión de migrar a migrar en diferido — no ahora, pero con un plan concreto para cuándo y bajo qué condiciones.
Tanto la falacia del coste hundido (quedarse por inercia) como el síndrome del objeto brillante (migrar por novedad) comparten un punto ciego: ambos tratan la decisión como binaria. O te quedas con lo que tienes o migras a algo nuevo.
Pero en la mayoría de los casos existe una tercera opción que es más robusta que cualquiera de las dos: mejora incremental del sistema existente, combinada con experimentación controlada de alternativas.
Esta opción tiene varias ventajas que la hacen racionalmente atractiva en muchos contextos:
La mejora incremental no es siempre la respuesta correcta — hay casos donde la deuda técnica está tan avanzada que no hay mejoras incrementales que valgan, o donde la nueva arquitectura es tan diferente que no hay camino gradual hacia ella. Pero debería estar siempre en el análisis, no como señal de indecisión sino como opción legítima con su propio perfil de costes y beneficios.
Integrando la primera parte y esta segunda, el marco de decisión que emerge tiene los siguientes elementos:
¿Elegirías hoy la arquitectura actual si empezaras desde cero?
¿Estás tendiendo hacia quedarte o hacia migrar?
Si la tendencia es quedarse, busca activamente argumentos de coste hundido en tu razonamiento. Pregunta: ¿aparece el esfuerzo pasado como justificación? Si sí, elimínalo del análisis.
Si la tendencia es migrar, busca activamente señales del síndrome del objeto brillante. Pregunta: ¿el argumento principal es el entusiasmo con la nueva tecnología? ¿Los benchmarks que estás usando son representativos de tu problema real? ¿Has estimado honestamente los costes de adopción incluyendo los invisibles?
Con los sesgos identificados y neutralizados en la medida de lo posible, el análisis se construye sobre tres ejes, todos mirando hacia el futuro:
Antes de decidir entre migrar y quedarse, evaluar explícitamente: ¿existe un camino de mejora incremental del sistema actual que tenga mejor perfil de riesgo/beneficio que la migración completa? Si existe, ¿puede combinarse con experimentación controlada de la nueva alternativa?
Una migración no es una decisión binaria en su ejecución. Las estrategias que minimizan el riesgo incluyen:
Todo el marco anterior asume implícitamente que las decisiones se toman en un contexto donde el análisis racional es posible y bienvenido. En la práctica, el contexto organizacional puede distorsionar las decisiones en cualquier dirección.
Hay organizaciones donde la presión es siempre hacia la novedad: el liderazgo técnico valora la modernidad del stack, los ingenieros son evaluados por las tecnologías que adoptan, y quedarse con sistemas antiguos se percibe como señal de conservadurismo. En ese contexto, la falacia del coste hundido tiene poco espacio pero el síndrome del objeto brillante florece.
Hay organizaciones donde ocurre exactamente lo contrario: el cambio es percibido como riesgo, la estabilidad se valora sobre la innovación, y cualquier propuesta de migración enfrenta resistencia estructural. En ese contexto, la falacia del coste hundido tiene todo el espacio para operar.
Reconocer en qué tipo de contexto operas es relevante porque el sesgo dominante no es solo individual — es también cultural. Y neutralizar un sesgo cultural requiere estrategias diferentes a neutralizar un sesgo individual: requiere hacer explícito el marco de decisión, documentar los análisis, y crear procesos que separen la evaluación técnica de las presiones organizacionales.
Podría parecer que la conclusión de este artículo es que la posición correcta está en el punto medio entre los dos extremos: ni aferrarse demasiado a lo existente ni migrar demasiado rápido hacia lo nuevo. Pero eso sería una simplificación engañosa.
El punto de equilibrio correcto no es el punto medio — es el resultado del análisis prospectivo aplicado a cada caso concreto. En algunos casos, ese análisis dirá que lo correcto es migrar cuanto antes. En otros, dirá que lo correcto es mantener el sistema actual indefinidamente. Pero, en muchos casos, dirá que lo correcto es mejorar incrementalmente mientras se experimenta con alternativas.
Lo que distingue las buenas decisiones de las malas no es su posición en el espectro entre conservadurismo e innovación — es la calidad del razonamiento que las produce. Una decisión de no migrar basada en análisis riguroso de costes y beneficios futuros es racionalmente equivalente a una decisión de migrar basada en el mismo tipo de análisis. Lo que no es racionalmente equivalente es cualquier decisión contaminada por el esfuerzo pasado (falacia del coste hundido) o por el entusiasmo con lo nuevo (síndrome del objeto brillante).
La ciencia de datos, como disciplina, debería ser especialmente buena en esto: tenemos herramientas conceptuales para razonar sobre incertidumbre, para comparar distribuciones de resultados esperados, para diseñar experimentos que produzcan evidencia real. Aplicar esas herramientas a nuestras propias decisiones técnicas — con la misma rigurosidad con la que las aplicamos a los problemas de negocio — es tanto una posibilidad como una responsabilidad.
El modelo que tienes en producción no es tu identidad. La tecnología que aprendiste hace cinco años no es tu legado. Y el paper que leíste la semana pasada no es necesariamente tu futuro. Son puntos de datos en un análisis que debería ser siempre prospectivo, siempre honesto sobre la incertidumbre, y siempre orientado a la pregunta que realmente importa: ¿qué decisión produce el mejor resultado esperado a partir de ahora?
En un entrada previa explicamos qué son el WOE y el IV y por qué…
Seguimos evolucionando el laboratorio de Analytics Lane y hoy lanzamos la versión 1.1, disponible en:…
“El interés compuesto es la octava maravilla del mundo. El que lo entiende lo gana…
Tienes los datos de ventas de tres productos en dos años distintos y quieres saber…
Imagina la situación. Tu equipo lleva tres años con un modelo en producción. No es…
Cuando un banco evalúa una solicitud de crédito necesita responder a una pregunta aparentemente simple:…
This website uses cookies.