Hoy abordaremos un tema importante: la deuda técnica oculta en los sistemas de aprendizaje automático. El artículo “Hidden Technical Debt in Machine Learning Systems” ha sido un elemento clave al actuar como un llamado de atención para la comunidad en este campo. Su importancia radica en destacar la necesidad de enfrentar y gestionar la deuda técnica oculta en dichos sistemas, lo cual es crucial para su éxito a largo plazo.

1 Introducción

A medida que los sistemas de aprendizaje automático (ML) se vuelven más complejos y evolucionan, comienzan a acumular “deuda técnica”.

La deuda técnica en el aprendizaje automático se refiere a los costos a largo plazo que se incurren al tomar atajos en el diseño, desarrollo y mantenimiento de sistemas de aprendizaje automático. En otras palabras, cuando los equipos de desarrollo de sistemas de aprendizaje automático toman decisiones que les permiten lanzar más rápidamente el modelo, pero a costa de la calidad, escalabilidad, rendimiento, mantenibilidad, etc., están incurriendo en deuda técnica.

Asumir deuda técnica puede tener razones estratégicas, pero debe ser atendida. Reducirla implica refactorizar código, mejorar pruebas, eliminar código innecesario, ajustar APIs y mejorar documentación. El objetivo de abordar la deuda técnica no es incluir nuevas funciones en un sistema sino facilitar futuras mejoras, disminuir errores y aumentar la mantenibilidad. La deuda oculta es peligrosa porque se acumula en silencio.

Este artículo no ofrece algoritmos de AA novedosos, sino que busca aumentar la conciencia de la comunidad sobre las difíciles decisiones que deben considerarse en la práctica a largo plazo.

El tentador reuso o encadenamiento de señales de entrada puede acoplar involuntariamente sistemas que, de lo contrario, estarían separados.

Explicación:

Con el “tentador reuso” se refiere a la práctica de utilizar una señal de entrada en varios lugares del sistema, quizás porque parece conveniente o porque podría ahorrar tiempo y esfuerzo. Y con el “encadenamiento” de señales de entrada se refiere a cuando las salidas de un componente del sistema se utilizan como entradas para otro componente, formando una cadena de dependencias entre ellos.

Los paquetes de AA pueden tratarse como cajas negras, lo que resulta en grandes masas de “glue code” o capas de calibración que pueden fijar supuestos. Los cambios en el mundo externo pueden influir en el comportamiento del sistema de maneras no deseadas. Incluso puede resultar difícil monitorear el comportamiento del sistema de AA sin un diseño cuidadoso.

2 Los modelos complejos erosionan los límites

La práctica tradicional de ingeniería de software ha demostrado que los límites de abstracción bien definidos mediante encapsulación y diseño modular ayudan a crear un código mantenible en el que es fácil realizar cambios y mejoras aisladas.

Desafortunadamente, es difícil aplicar límites estrictos de abstracción en sistemas de aprendizaje automático, esto se debe a que, en estos sistemas, es complicado definir de manera precisa cómo se espera que funcionen en ciertas condiciones o situaciones. El mundo real no encaja en una encapsulación ordenada.

A continuación examinamos varias formas en que la erosión resultante de los límites puede aumentar significativamente la deuda técnica en los sistemas de AA.

Entrelazamiento

Los sistemas de aprendizaje automático se enfrentan al desafío de que sus señales de entrada y parámetros están entrelazados, lo que dificulta aislar mejoras en el sistema. El principio CACE (Changing Anything Changes Everything) establece que cualquier cambio en el sistema puede tener un efecto en cascada en todo el sistema. Esto aplica a señales de entrada, hiperparámetros, configuraciones de aprendizaje y selección de datos.

Ejemplo:

Imagina que estás trabajando en un sistema de recomendación de películas basado en aprendizaje automático. En este sistema, las señales de entrada incluyen características como género, año de lanzamiento y calificación promedio de los usuarios. Ahora, supongamos que decides mejorar la calidad de las recomendaciones añadiendo nuevas características, como la presencia de actores o actrices populares.

Al añadir estas nuevas características, estás cambiando algo en el sistema, y según el principio CACE, esto podría tener un impacto en cascada en todo el sistema. Es posible que al agregar estos nuevos datos, la relación entre las características existentes y las recomendaciones cambie, afectando la precisión general de las predicciones.

Cascadas de corrección

A menudo hay situaciones en las que existe un modelo m_a para el problema A, pero se necesita una solución para un problema ligeramente diferente A’. En este caso, puede resultar tentador aprender un modelo m_a’ que utiliza m_a como entrada y aprende una pequeña corrección como una forma rápida de resolver el problema. Sin embargo, este modelo de corrección ha creado una nueva dependencia del sistema en m_a, lo que lo hace significativamente más costoso analizar las mejoras de ese modelo en el futuro. El costo aumenta cuando los modelos de corrección se concatenan, con un modelo para el problema A’’ aprendido sobre m_a’, y así sucesivamente, para varias distribuciones de prueba ligeramente diferentes. Una vez establecida, una cascada de corrección puede generar un bloqueo en el progreso, debido a que al intentar mejorar la precisión de un componente individual, en realidad, se provoca un efecto negativo en el rendimiento del sistema en su conjunto. Las estrategias para mitigar los problemas causados por las cascadas de corrección incluyen mejorar el modelo m_a incorporando las correcciones directamente en él, añadiendo características que permitan diferenciar entre los casos particulares, agregando características para distinguir entre los casos, o asumir el costo de crear un modelo separado para A’.

Consumidores no declarados

Los consumidores no declarados son sistemas que utilizan las predicciones de un modelo de aprendizaje automático sin restricciones de acceso, creando una relación oculta y fuerte entre el modelo y otras partes del sistema. Esto puede dificultar y encarecer la realización de cambios en el modelo y generar bucles de retroalimentación ocultos. La detección de estos consumidores es complicada a menos que se implementen medidas preventivas, como restricciones de acceso o acuerdos de nivel de servicio estrictos.

3 Dependencias de datos cuestan más que las dependencias de código

En sistemas de aprendizaje automático, las dependencias de datos pueden generar una deuda similar a las dependencias de código en la ingeniería de software clásica. Sin embargo, estas dependencias de datos pueden ser más difíciles de detectar ya que no existen herramientas similares al análisis estático de compiladores y enlazadores para identificarlas (Sonarqube). Como resultado, es fácil construir grandes cadenas de dependencias de datos que pueden ser difíciles de desenredar.

Dependencias de datos inestables

Se refiere a las dependencias de datos que son inestables y cambian cualitativa o cuantitativamente su comportamiento con el tiempo. Esto puede suceder implícita o explícitamente y puede ser peligroso porque las actualizaciones a las señales de entrada pueden tener efectos perjudiciales inesperados en el sistema que los consume, lo que es costoso de diagnosticar y abordar. Para mitigar estos riesgos, se pueden utilizar estrategias como la creación de copias versionadas de señales específicas, pero esto también puede tener costos adicionales.

Dependencias de datos subutilizadas

Se refiere a las dependencias de datos que proporcionan poco o ningún beneficio incremental al modelo en un sistema de aprendizaje automático. A pesar de su falta de importancia, estas dependencias pueden hacer que el modelo sea innecesariamente vulnerable a cambios en el futuro, lo que puede provocar fallas catastróficas en el sistema. A menudo, estas dependencias pueden eliminarse sin efectos negativos en el modelo, y es importante identificarlas y eliminarlas para asegurar la estabilidad y confiabilidad del sistema a largo plazo. En resumen, las dependencias de datos subutilizadas pueden ser peligrosas para el funcionamiento adecuado de un sistema de aprendizaje automático y deben ser abordadas cuidadosamente.

Las dependencias de datos subutilizadas pueden aparecer en un modelo de varias maneras.

• Una forma común es a través de características heredadas que se agregaron temprano en el desarrollo del modelo y que con el tiempo se volvieron redundantes.
• Otra forma es a través de la inclusión de un grupo de características sin evaluar individualmente cada una, lo que puede llevar a la inclusión de características que no aportan valor.
• También puede suceder que se agreguen características para mejorar la precisión del modelo, incluso si la ganancia es mínima o el costo computacional es alto.
• Además, dos características pueden estar altamente correlacionadas, pero una de ellas es la verdadera causa del resultado que el modelo está tratando de predecir. Si el modelo no puede distinguir entre ambas características y les da el mismo peso, puede incluir características innecesarias en el modelo, lo que puede disminuir su eficacia y aumentar la probabilidad de errores.

Para combatir estos problemas, es vital realizar evaluaciones exhaustivas de “leave-one-feature-out”, es decir, ir dejando fuera una característica a la vez para identificar y eliminar las innecesarias.

Análisis estático de dependencias de datos

El análisis estático de dependencias de datos es una técnica que se utiliza para verificar y rastrear las conexiones entre diferentes elementos de un sistema de aprendizaje automático. En el código tradicional, los compiladores y sistemas de build realizan este análisis de dependencia, pero en el aprendizaje automático, estas herramientas son menos comunes.

Para resolver esto, existen herramientas que permiten la anotación de fuentes y características de datos, como el sistema automatizado de gestión de características. Esta herramienta ejecuta comprobaciones automáticas para garantizar que todas las dependencias tengan las anotaciones adecuadas y que los árboles de dependencia estén completamente resueltos. De esta manera, se puede hacer que la migración y eliminación de dependencias sean mucho más seguras en la práctica, evitando errores y problemas en el sistema.

4 Bucles de retroalimentación

En los sistemas de aprendizaje automático que están activos y en uso en tiempo real, se ha observado que a menudo terminan influyendo en su propio comportamiento si se actualizan con el tiempo. Esto conduce a una forma de deuda de análisis, en la que es difícil predecir el comportamiento de un modelo dado antes de que se publique. Estos bucles de retroalimentación pueden tomar diferentes formas, pero todos son más difíciles de detectar y abordar si ocurren gradualmente con el tiempo, como puede ser el caso cuando los modelos se actualizan con poca frecuencia, lo que dificulta la medición del impacto de cada actualización en el comportamiento general del sistema.

Ejemplo:

Imagina un modelo que selecciona canciones para tocar en una fiesta. El modelo aprende de las reacciones de la gente y se actualiza con el tiempo para elegir mejor las canciones. A medida que el modelo aprende y cambia, también influye en su propio comportamiento.

Al principio, el modelo toca mucha música pop, pero con el tiempo empieza a tocar más música electrónica porque nota que la gente baila más con ese estilo. Cada actualización del modelo hace que sea difícil predecir qué canciones tocará en el futuro.

Bucles de retroalimentación directos

En el campo del aprendizaje automático, un modelo puede tener un impacto en la elección de los datos de entrenamiento que se utilizarán en el futuro, lo que origina un ciclo de retroalimentación directa. Esto puede generar dificultades, ya que los datos de entrenamiento podrían no reflejar adecuadamente la población en su totalidad y, como resultado, el modelo podría no ser efectivo al enfrentarse a nuevos datos. A pesar de que los algoritmos de bandit serían la opción ideal, su capacidad limitada para escalar los hace poco útiles en problemas reales. En su lugar, se pueden emplear métodos como la randomización de datos o el aislamiento de ciertos segmentos de los datos para reducir estos efectos negativos y mejorar la capacidad de generalización del modelo.

Ejemplo:

Imagina que estás construyendo un modelo de aprendizaje automático para predecir si un correo electrónico es spam o no. El modelo se entrena con datos históricos de correos electrónicos etiquetados como spam o no spam. Al implementar el modelo, este empieza a etiquetar automáticamente nuevos correos electrónicos como spam.

Sin embargo, el modelo también influye en la selección de datos de entrenamiento futuros, ya que los correos electrónicos etiquetados como spam se utilizan para mejorar y actualizar el modelo. Si el modelo comete errores al etiquetar inicialmente correos electrónicos, estos errores se propagan y afectan el rendimiento futuro del modelo.

Bucles de retroalimentación ocultos

En los sistemas de aprendizaje automático, es posible que haya bucles de retroalimentación ocultos en los que dos sistemas se influyan mutuamente de manera indirecta a través del mundo. Por ejemplo, dos sistemas pueden determinar aspectos de una página web de manera independiente, como seleccionar productos para mostrar y seleccionar reseñas relacionadas. Mejorar uno de estos sistemas puede llevar a cambios en el comportamiento del otro. Estos bucles de retroalimentación pueden existir entre sistemas completamente separados, lo que los hace difíciles de detectar.

Imagina una tienda en línea que vende ropa. La tienda tiene dos modelos que trabajan en su página web:

1. Modelo A: Se encarga de seleccionar y mostrar las camisetas más populares en la página principal.
2. Modelo B: Se encarga de escoger y mostrar las opiniones de los clientes sobre las camisetas en la página principal.

Figura 1: Solo una pequeña fracción de los sistemas de ML en el mundo real está compuesta por el código de ML, como se muestra en la pequeña caja negra en el medio. La infraestructura circundante requerida es vasta y compleja.

5 Anti-patrones de sistemas de aprendizaje automático

Vamos a explorar diferentes anti-patrones que pueden surgir en sistemas de aprendizaje automático. Estos patrones pueden afectar negativamente el rendimiento y la eficiencia de los sistemas, por lo que es crucial reconocerlos, evitarlos o reestructurarlos cuando sea posible.

Glue Code

Los investigadores de ML suelen utilizar paquetes genéricos de propósito general, lo que lleva a un diseño de sistema basado en “glue code” (código de soporte) para conectar los paquetes. Esto puede ser costoso a largo plazo, ya que dificulta probar alternativas y aprovechar las propiedades específicas del dominio. Un sistema maduro puede contener mayormente “glue code”, por lo que a veces es mejor crear una solución nativa limpia. Para combatir este problema, es útil envolver paquetes de caja negra en API comunes, lo que permite una mayor reutilización y reduce el costo de cambiar paquetes.

Pipeline Jungles

Las “junglas de tuberías” en la preparación de datos son sistemas complejos que evolucionan orgánicamente al agregar nuevas señales e información. Estos sistemas pueden ser difíciles de gestionar, probar y depurar debido a su complejidad, lo que incrementa la deuda técnica y obstaculiza la innovación. Para evitar estos problemas, es esencial abordar la recolección y extracción de datos de manera integral, diseñando sistemas de preparación de datos desde cero. Además, es crucial que científicos y desarrolladores colaboren en equipos integrados en lugar de trabajar en roles separados, reduciendo así la fricción y el uso de soluciones de “caja negra”.

Dead Experimental Codepaths

El glue code y los pipeline jungles pueden llevar a la creación de ramas experimentales dentro del código de producción, ya que esto facilita la experimentación a corto plazo sin la necesidad de modificar la infraestructura circundante. Aunque puede ser atractivo en un principio, esta práctica acumula deuda técnica a largo plazo debido a la creciente dificultad en mantener la compatibilidad hacia atrás y el incremento en la complejidad del código, lo que dificulta su mantenimiento y evolución.

Abstraction Debt

La deuda de abstracción hace referencia a la falta de conceptos sólidos y bien definidos para respaldar los sistemas de aprendizaje automático (ML). Zheng comparó las abstracciones en ML con la tecnología de bases de datos, señalando que no hay nada comparable al éxito de las bases de datos relacionales como concepto básico. La falta de abstracciones adecuadas dificulta definir interfaces apropiadas para describir flujos de datos, modelos y predicciones en ML.

En el aprendizaje distribuido, aún no existen abstracciones ampliamente aceptadas. Se podría argumentar que el uso generalizado de MapReduce en ML se debe a la ausencia de abstracciones sólidas en el aprendizaje distribuido. De hecho, existe un consenso en que MapReduce no es una abstracción adecuada para algoritmos de ML iterativos.

En cambio, la abstracción del servidor de parámetros parece más sólida y adecuada para algoritmos de ML iterativos en entornos distribuidos. Sin embargo, hay diferentes propuestas para implementar esta idea básica, lo que genera cierta confusión y falta de consenso en la comunidad. La ausencia de abstracciones estándar hace que sea fácil confundir y mezclar componentes en el ámbito de ML.

Common Smells

En la ingeniería de software, un “smell” de diseño puede indicar un problema subyacente en un componente o sistema. Identificamos algunos “smell” en los sistemas de aprendizaje automático, no como reglas estrictas, sino como indicadores subjetivos.

1. Plain-Old-Data Type Smell: A menudo, la información utilizada y producida por los sistemas de ML se codifica con tipos de datos simples como flotantes y enteros. En un sistema robusto, un parámetro del modelo debería conocer su función específica, y una predicción debería conocer información sobre el modelo que la generó y cómo debe ser consumida.
2. Multiple-Language Smell: A veces es tentador escribir una parte de un sistema en un lenguaje específico, especialmente si ese lenguaje tiene una biblioteca o sintaxis conveniente para la tarea. Sin embargo, usar varios lenguajes a menudo aumenta el costo de las pruebas efectivas y puede dificultar la transferencia de responsabilidad a otras personas.
3. Prototype Smell: Los prototipos son útiles para probar ideas rápidamente, pero depender demasiado de ellos en lugar de mejorar el sistema principal puede indicar fragilidad o falta de buenas abstracciones en el sistema. Mantener un entorno separado para prototipos tiene costos adicionales, y existe el riesgo de que un prototipo incompleto o no probado se utilice en producción, generando problemas a largo plazo.

6 Deuda de configuración

La configuración en los sistemas de aprendizaje automático puede ser complicada debido a la gran cantidad de opciones y ajustes disponibles. A menudo, investigadores e ingenieros no le dan la importancia debida a la configuración y su verificación. Como resultado, se pueden cometer errores que afectan la eficiencia, la precisión y el rendimiento del sistema.

La configuración incorrecta puede llevar a problemas en la recopilación y uso de datos, así como en la implementación del modelo en entornos de producción. Estos errores pueden resultar en pérdidas de tiempo, desperdicio de recursos informáticos y problemas en producción.

Para abordar estos desafíos, es crucial desarrollar y seguir principios sólidos en la configuración de los sistemas de aprendizaje automático, prestando atención a la organización, verificación y prueba de las configuraciones. Esto nos lleva a articular los siguientes principios de buenos sistemas de configuración:

• Debería ser fácil especificar una configuración como un pequeño cambio a partir de una configuración anterior.
• Debería ser difícil cometer errores, omisiones o descuidos manuales.
• Debería ser fácil ver, visualmente, la diferencia de configuración entre dos modelos.
• Debería ser fácil afirmar y verificar automáticamente hechos básicos sobre la configuración: número de características utilizadas, cierre transitivo de las dependencias de datos, etc.
• Debería ser posible detectar configuraciones no utilizadas o redundantes.
• Las configuraciones deben someterse a una revisión completa del código y ser registradas en un repositorio.

7 Manejando Cambios en el Mundo Externo

Una de las cosas que hace tan fascinantes a los sistemas de aprendizaje automático (ML) es que a menudo interactúan directamente con el mundo externo. La experiencia ha demostrado que el mundo externo rara vez es estable. Esta tasa de cambio constante crea un costo continuo de mantenimiento.

Umbral Fijo en Sistemas Dinámicos

El umbral de decisión en un modelo de aprendizaje automático es crucial para realizar acciones como predecir verdadero/falso o clasificar correos electrónicos. A pesar de que estos umbrales se ajustan manualmente, esto puede ser inválido si el modelo se actualiza con nuevos datos. La solución presentada en [14] propone aprender los umbrales utilizando una evaluación en datos de validación separados para evitar ajustes manuales constantes y fragilidad en el proceso.

Monitoreo y Pruebas

Aunque las pruebas unitarias y las pruebas de end-to-end son valiosas, no son suficientes para garantizar que un sistema de ML funcione como se espera en un entorno en constante cambio. Es esencial monitorear el comportamiento del sistema en tiempo real y tener respuestas automatizadas para garantizar la confiabilidad a largo plazo del sistema. Sin embargo, determinar qué monitorear puede ser difícil ya que muchos sistemas de ML se adaptan con el tiempo. Se ofrecen algunos puntos de partida para abordar esta cuestión.

• Sesgo de predicción. El sesgo de predicción se refiere a la coincidencia entre las distribuciones de etiquetas predichas y observadas en un sistema funcional. A pesar de no ser una prueba definitiva, resulta útil para detectar problemas, como cambios en el comportamiento del mundo. Analizarlo en distintas dimensiones permite identificar rápidamente problemas y generar alertas automáticas.
• Límites de acción. En sistemas que realizan acciones en situaciones reales, como ofertar en subastas o identificar correos spam, es útil establecer límites de acción para asegurar un funcionamiento adecuado. Estos límites deben ser lo suficientemente flexibles para evitar falsas alarmas. Si se alcanza un límite, se deben activar alertas automáticas que lleven a una intervención o investigación manual.
• Productores de flujo ascendente. Los sistemas de aprendizaje automático a menudo reciben datos de múltiples fuentes, llamadas productores up-stream. Es importante supervisar y evaluar estos procesos, asegurándose de que cumplan con los objetivos de nivel de servicio, teniendo en cuenta las necesidades del sistema de aprendizaje automático. También es crucial que las alertas generadas en el up-stream se transmitan al sistema de aprendizaje automático para mantener su accuracy. Asimismo, si el sistema de aprendizaje automático no cumple con los objetivos establecidos, esto debe comunicarse down-stream a todos los usuarios afectados y, si es posible, a sus sistemas de control.

Up-stream hace referencia a las fuentes o productores de datos que alimentan un sistema de aprendizaje automático y Down-stream se refiere a los consumidores o usuarios de la información y resultados generados por un sistema de aprendizaje automático.

Debido a que los cambios externos ocurren en tiempo real, las respuestas también deben ser en tiempo real. Confiar en la intervención humana para responder a las alertas es una estrategia, pero puede ser frágil en situaciones urgentes. Crear sistemas que permitan respuestas automáticas sin intervención humana directa suele ser una inversión valiosa.

8 Otras áreas de deuda técnica relacionada con ML

Ahora destacamos brevemente algunas áreas adicionales donde puede acumularse deuda técnica relacionada con el aprendizaje automático.

Deuda de pruebas de datos. Se refiere a la necesidad de probar los datos de entrada en los sistemas de aprendizaje automático para garantizar su correcto funcionamiento. Es importante realizar pruebas básicas y sofisticadas para detectar errores y monitorear cambios en las distribuciones de entrada. En resumen, es la cantidad de trabajo necesario para probar adecuadamente los datos de entrada en un sistema de ML.

Deuda de reproducibilidad. Como científicos, es importante que podamos volver a ejecutar experimentos y obtener resultados similares, pero diseñar sistemas del mundo real que permitan una reproducibilidad estricta es una tarea difícil debido a algoritmos aleatorios, indeterminación inherente en el aprendizaje paralelo, dependencia de condiciones iniciales e interacciones con el mundo exterior.

Deuda de gestión de procesos. La mayoría de los casos de uso descritos en el documento han hablado sobre el costo de mantener un solo modelo, pero los sistemas maduros pueden tener muchos modelos funcionando simultáneamente, lo que aumenta la complejidad y los desafíos de gestión. La deuda de gestión de procesos en este caso se refiere a la acumulación de costos y riesgos que surgen de la necesidad de actualizar muchas configuraciones para muchos modelos similares de manera segura y automática, la gestión y asignación de recursos entre modelos con diferentes prioridades comerciales, la visualización y detección de bloqueos en el flujo de datos en un proceso de producción, y la necesidad de desarrollar herramientas para ayudar en la recuperación de incidentes de producción. Para evitar la acumulación de deuda de gestión de procesos, es importante evitar los procesos comunes con muchos pasos manuales y adoptar procesos claros y eficientes en la gestión de sistemas.

Deuda cultural. A veces hay una línea dura entre la investigación de ML y la ingeniería, pero esto puede ser contraproducente para la salud del sistema a largo plazo. Es importante crear culturas de equipo que recompensen la eliminación de características, la reducción de complejidad, las mejoras en la reproducibilidad, estabilidad y monitoreo en la misma medida en que se valoran las mejoras en la precisión. En nuestra experiencia, esto es más probable que ocurra dentro de equipos heterogéneos con fortalezas tanto en investigación de ML como en ingeniería.

9 Conclusiones: Evaluando y liquidando la deuda técnica

La deuda técnica es un concepto útil, pero carece de una métrica clara para seguirla en el tiempo. Determinar la deuda técnica en un sistema y su costo completo puede ser complicado. Avanzar rápidamente en proyectos puede generar deuda técnica. Algunos aspectos a considerar son la facilidad para probar nuevos enfoques, las dependencias de datos y cómo afectan los cambios en el sistema. También es importante la rapidez con la que los nuevos miembros se integran al equipo.

Este documento busca impulsar avances en aprendizaje automático (ML) sostenible, mejorando abstracciones, pruebas y patrones de diseño. Es fundamental que ingenieros e investigadores sean conscientes de la deuda técnica y eviten soluciones que aumenten la complejidad del sistema. Añadir dependencias de datos innecesarias puede frenar el progreso.

Liquidar la deuda técnica en ML requiere un compromiso específico y un cambio en la cultura del equipo. Es crucial reconocer, priorizar y recompensar estos esfuerzos para garantizar la salud a largo plazo de los equipos de ML exitosos.

---

Referencias:

1. Hidden Technical Debt in Machine Learning Systems https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf