¿Le ha llegado a la cabeza la ilusión del aprendizaje automático?Usted gira un cuaderno, limpia un conjunto fijo de datos y capacita a un modelo hasta que brille la precisión.La confianza crece.El prototipo es perfecto, y ha emocionado a las partes interesadas. “¿Puede esto ir vivo?” es la pregunta más peligrosa en la ciencia de datos. Aquí es donde la mayoría de las iniciativas prometedoras se cortan prematuramente, o incluso se cancelan por completo, en muchos programas de aprendizaje automático.El desarrollo de un único prototipo de notebook en un sistema de producción de nube altamente viable no es sólo una extensión de su demostración.Esto implica una inmensa transformación en las prácticas de ingeniería.La nube no puede resolver los problemas arquitectónicos subyacentes por sí sola; sólo arroja más luz sobre ellos. Why Notebook Success Does Not Translate to Production Reality Por qué el éxito del notebook no se traduce a la realidad de la producción Probablemente, los portátiles son cómodos debido a la falta de fricción. Sus datos son estáticos. El mundo a su alrededor está sellado. Casos de borde y fallas son muy fáciles de ignorar. La producción elimina todo lo que es cómodo. En realidad, la información está retrasada, fragmentada o distorsionada. Usted compite con otros procesos de alta prioridad, y cuando ocurren errores, afectan a los usuarios reales. Una de las suposiciones más peligrosas que conduce al fracaso del equipo es que un modelo que funcionó históricamente operará bajo cargas continuas y simultáneas de la misma manera que lo hizo durante una predicción aislada en un cuaderno. The Data Problem Nobody Sees Coming El problema de los datos que nadie ve En su prototipo, la información es perfecta. En la producción, sin embargo, son los datos los que dictan la agenda. Los cambios de formato de arriba a menudo son silenciosos. Usted implementa modelos construidos sobre datos históricos; comienzan a envejecer tan pronto como los utilice en un mundo dinámico. La mayoría de los equipos están dispuestos a expandir el tamaño de su infraestructura en la nube y ni siquiera consideran la fiabilidad de los datos. La noción de que es increíblemente fácil montar más computación en los proveedores de nube, pero que no hay botón de escalado automático cuando las tuberías de datos fluyen de la manera equivocada, es absolutamente aterrador. La precisión de su modelo se degradará silenciosamente a medida que ignora los patrones de los datos entrantes, mientras que los servidores se hacen más ocupados, haciendo ruidos alegres. Accuracy Is Not the Finish Line La precisión no es la línea final En la práctica, la calidad de la predicción, su latencia, su estabilidad y el coste del modelo en la nube son todos parámetros de los que depende el rendimiento del modelo. Es posible trabajar con un modelo pesado, pero puede gastar más de su presupuesto de inferencia para pagar la factura de la nube. El problema es que los ingenieros son más propensos a cometer el error de usar modelos enormes y complejos sólo porque existen. modelos más pequeños y altamente optimizados son casi siempre la mejor opción de ingeniería: son más baratos, más rápidos y requieren menos babysitting operativo. Environment Mismatch and Dependency Chaos Desacuerdo ambiental y caos de dependencia La implementación a menudo fallará debido a incompatibilidades ambientales.Los servidores en la nube de producción no se parecen en modo alguno a los entornos de los portátiles. Las versiones de la biblioteca difieren. Los aceleradores de hardware no son los mismos. Las configuraciones del sistema introducen variaciones sutiles y molestas en la forma en que se ejecuta el código. Cuando los equipos no mantienen un control estricto sobre el medio ambiente, surge el caos durante la implementación. El conjunto de pruebas ya no se utiliza para hacer predicciones de una vez por todas. Los servicios simplemente se desvanecen. El proceso de depuración se convierte en una pesadilla. La reproductibilidad debe ser la preocupación principal. Se requieren modelos estrictamente empaquetados y dependencias en contenedores (Docker) para garantizar que la escala no sólo sea fiable sino también resiliente. Scaling ML Is Not the Same as Scaling Software Escalar ML no es lo mismo que escalar software Una aplicación web tradicional puede escalarse fácilmente añadiendo servidores adicionales detrás de un balanceador de carga. Los modelos pueden requerir hardware especial (como GPUs o TPUs). El consumo de memoria puede aumentar abruptamente y significativamente durante la inferencia. Los arranques fríos pueden ralentizar sus tiempos de respuesta a un crawl, y las cargas de trabajo de transmisión en tiempo real requieren una arquitectura completamente diferente a un proceso de batch nocturno. No asuma que la escalabilidad automática de la nube corregirá estas barreras automáticamente. La escalabilidad sólo es posible cuando gestiona correctamente su tráfico, la asignación de recursos y entiende la huella de hardware de su modelo. The Silent Danger of Poor Monitoring El peligro silencioso de una mala vigilancia Las API y la salud del servidor son supervisadas de cerca por la mayoría de los equipos de ingeniería, pero el seguimiento del modelo a menudo se descuida. Cuando un servidor web se colapsa, falla abruptamente y deja el servicio indisponible. Con un modelo ML, sin embargo, no puede haber colapso. Las predicciones se deslizan lentamente. Los prejuicios se deslizan. El producto se desalinea. Su modelo se degrada, y no puede permitirse esperar hasta que los clientes se quejan y los ingresos se han negado a darse cuenta de ello. Monitorar el deslizamiento de datos y el deslizamiento de la predicción no es un lujo; es la única forma de asegurarse de que su sistema está haciendo realmente lo que ha diseñado para hacerlo. Security and Governance Are Not Afterthoughts Seguridad y gobernanza no son reflexiones posteriores La seguridad en un prototipo de notebook no es una preocupación para algunas personas. sin embargo, el trabajo que deja expuesto en la Internet abierta puede contener valiosa propiedad intelectual e información altamente sensible. Los hackers perciben los endpoints abiertos como oportunidades para robar modelos o corromper datos de capacitación. Las herramientas de seguridad y gobernanza de su proveedor de nube no deben dejarse sin usar. Acceso seguro a los datos utilizando roles de IAM estrictos. Asegúrese de que los cambios de modelo y las consultas de datos sean audibles. Treating ML as a Living System Tratar la ML como un sistema vivo El mayor mito de MLOps es que el propósito es el despliegue. De hecho, el despliegue es el día cero. Los equipos de ingeniería exitosos no consideran el aprendizaje automático como una versión de software, sino como un organismo vivo. Tienes que seguir entrenando, refinando y monitoreando tus modelos a medida que operan en un mundo cambiante. Estos equipos no perciben la nube como una ayuda de banda para evitar la ingeniería seria; más bien, la ven como una base sólida para construir sistemas resilientes. Closing Thoughts Cierre de pensamientos En concreto, el reto de convertir un prototipo en producción es donde el aprendizaje automático se vuelve realmente factible, y donde muchas iniciativas fallan. Estar basado en la nube no se refiere a bromear sobre un tamaño de modelo más grande o el número de servidores que ha lanzado. Se refiere a planificar, arquitectar y respetar la complejidad pura del mundo real.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Este audio es producido en el idioma original de la historia!

Por qué su prototipo ML fallará en la producción (y cómo corregirlo)

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Telegram: el puente de Crypto Island hacia el continente

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Telegram: el puente de Crypto Island hacia el continente

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps