El aprendizaje automático ofrece un conjunto de herramientas increíblemente poderoso para

construir sistemas complejos rápidamente. Este artículo sostiene que es peligroso pensar en
estas victorias rápidas

como viniendo gratis. Utilizando el marco de la deuda técnica, observamos que es muy fácil
incurrir en costos masivos de mantenimiento continuo a nivel del sistema.

al aplicar el aprendizaje automático. El objetivo de este documento es resaltar varios factores

de riesgo específicos del aprendizaje automático y patrones de diseño que deben evitarse o
refactorizarse.

donde sea posible. Estos incluyen erosión de límites, enredos, retroalimentación oculta

bucles, consumidores no declarados, dependencias de datos, cambios en el mundo externo,

y una variedad de anti-patrones a nivel de sistema.

Los ingenieros de software del mundo real a menudo se enfrentan al desafío de moverse
rápidamente para enviar nuevos

productos o servicios, lo que puede generar un dilema entre la velocidad de ejecución y la

calidad de la ingeniería. El concepto de deuda técnica fue introducido por primera vez por
Ward Cunningham en 1992 como

forma de ayudar a cuantificar el costo de tales decisiones. Al igual que contraer deuda fiscal, a
menudo existen

Razones estratégicas para asumir deuda técnica. No toda la deuda es necesariamente mala,
pero la deuda técnica sí

tienden a agravar. Aplazar el trabajo para amortizarlo da como resultado costos crecientes,
fragilidad del sistema,

y tasas reducidas de innovación.

Los métodos tradicionales para pagar la deuda técnica incluyen la refactorización, el aumento
de la cobertura de la unidad

pruebas, eliminación de código muerto, reducción de dependencias, ajuste de API y mejora de

la documentación

[4]. El objetivo de estas actividades no es agregar nuevas funciones, sino facilitar la

incorporación de futuros

mejoras, ser más económico de mantener y reducir la probabilidad de errores.

Uno de los argumentos básicos en este documento es que los paquetes de aprendizaje
automático tienen todo el código básico

problemas de complejidad como el código normal, pero también tienen una mayor
complejidad a nivel de sistema que puede crear

deuda oculta. Por lo tanto, refactorizar estas bibliotecas, agregar mejores pruebas unitarias y
la actividad asociada es tiempo
bien gastado, pero no necesariamente aborda la deuda a nivel de sistemas.

En este documento, nos enfocamos en la interacción a nivel de sistema entre el código de

aprendizaje automático y los sistemas más grandes como un área donde la deuda técnica
oculta puede acumularse rápidamente. A nivel de sistema, una máquina

El modelo de aprendizaje puede erosionar sutilmente los límites de abstracción. Puede resultar
tentador reutilizar las señales de entrada de formas que creen un acoplamiento estrecho no
intencionado de sistemas que de otro modo serían disjuntos. Aprendizaje automático

Los paquetes a menudo pueden tratarse como cajas negras, lo que da como resultado grandes
masas de “código de pegamento” o capas de calibración que pueden bloquear suposiciones.
Los cambios en el mundo externo pueden generar modelos o entradas

Las señales cambian el comportamiento de formas no deseadas, aumentando el costo de

mantenimiento y la carga de cualquier

deuda. Incluso monitorear que el sistema en su conjunto está funcionando según lo previsto
puede resultar difícil sin cuidado diseño