En el edificio Aprendizaje automático Los modelos eran una habilidad, solo los científicos de datos con conocimiento de Python podían dominar. Sin embargo, las plataformas AI de bajo código han hecho las cosas mucho más fáciles ahora.
Ahora cualquiera puede hacer directamente un modelo, vincularlo a los datos y publicarlo como un servicio web con solo unos pocos clics. Los especialistas en marketing ahora pueden desarrollar modelos de segmentación de clientes, los equipos de soporte de usuarios pueden implementar chatbots y los gerentes de productos pueden automatizar el proceso de predecir las ventas sin tener que escribir código.
Aun así, esta simplicidad tiene sus desventajas.
Un comienzo falso a escala
Cuando una compañía de comercio electrónico de tamaño mediano introdujo su primer modelo de aprendizaje automático, fue por la ruta más rápida: una plataforma de bajo código. El equipo de datos rápidamente creó un modelo de recomendación de productos con Microsoft Azure ML Designer. No había necesidad de codificación o una configuración complicada, y el modelo estaba en funcionamiento en solo unos días.
Cuando se organizó, lo hizo bien, recomendando productos relevantes y manteniendo el interés de los usuarios. Sin embargo, cuando 100,000 personas usaron la aplicación, enfrentó problemas. Los tiempos de respuesta se triplicaron. Las recomendaciones solo se mostraron dos veces, o no aparecieron en absoluto. Finalmente, el sistema se bloqueó.
El problema no era el modelo que se estaba utilizando. Era la plataforma.
Azure ML diseñador y el lienzo de AWS Sagemaker está diseñado para operar rápidamente. Gracias a sus herramientas de arrastrar y soltar fáciles de usar, cualquiera puede usar el aprendizaje automático. Sin embargo, la simplicidad que los hace fáciles de trabajar también cubre sus debilidades. Las herramientas que comienzan como prototipos simples fallan cuando se ponen en producción de alto tráfico, y esto sucede debido a su estructura.
La ilusión de la simplicidad
Las herramientas de IA de bajo código se promueven a personas que no son expertos en tecnología. Se encargan de las partes complejas de la preparación de datos, la creación de características, la capacitación del modelo y lo usan. Azure ML Designer hace que sea muy posible que los usuarios importen datos, creen una tubería de modelo e implementen la tubería como servicio web.
Sin embargo, tener una idea abstracta es positiva y negativa.
Gestión de recursos: limitado e invisible
La mayoría de las plataformas de bajo código ejecutan modelos en entornos de cómputo preestablecidos. La cantidad de CPU, GPU y memoria a la que los usuarios pueden acceder no es ajustable. Estos límites funcionan bien en la mayoría de los casos, pero se convierten en un problema cuando hay un aumento en el tráfico.
Una plataforma de tecnología educativa que utiliza el lienzo de AWS Sagemaker creó un modelo que podría clasificar las respuestas de los estudiantes a medida que se presentaron. Durante la prueba, funcionó perfectamente. Sin embargo, como el número de usuarios alcanzó los 50,000, el punto final API del modelo falló. Se descubrió que el modelo se estaba ejecutando en una instancia básica de cómputo, y la única solución para actualizarlo era reconstruir todos los flujos de trabajo.
Gestión del Estado: Oculto pero peligroso
Debido a que las plataformas de bajo código mantienen el estado del modelo entre las sesiones, son rápidas para las pruebas, pero pueden ser riesgosos en el uso de la vida real.
Se creó un chatbot para el comercio minorista en Azure ML Designer para que los datos del usuario se mantuvieran durante cada sesión. Mientras probaba, sentí que la experiencia estaba hecha solo para mí. Sin embargo, en el entorno de producción, los usuarios comenzaron a recibir mensajes destinados a otra persona. El problema? Almacenó información sobre la sesión del usuario, por lo que cada usuario sería tratado como una continuación de la anterior.
Monitoreo limitado: con los ojos vendados a escala
Los sistemas de bajo código dan resultados básicos, como precisión, AUC o puntaje F1, pero estas son medidas para las pruebas, no para ejecutar el sistema. Es solo después de los incidentes que los equipos descubren que no pueden rastrear lo que es esencial en el entorno de producción.
Una startup de logística implementó un modelo de pronóstico de demanda utilizando Azure ML Designer para ayudar con la optimización de la ruta. Todo fue bueno hasta que llegaron las vacaciones, y las solicitudes aumentaron. Los clientes se quejaron de respuestas lentas, pero el equipo no pudo ver cuánto tiempo tardó la API en responder o encontrar la causa de los errores. El modelo no se pudo abrir para ver cómo funcionaba.
Tubería escalable versus no escalable (imagen por autor)
Por qué los modelos de bajo código tienen problemas para manejar proyectos grandes
Los sistemas AI de bajo código no se pueden escalar, ya que carecen de los componentes clave de los sistemas de aprendizaje automático fuertes. Son populares porque son rápidos, pero esto viene con un precio: la pérdida de control.
1. Los límites de recursos se convierten en cuellos de botella
Los modelos de bajo código se utilizan en entornos que han establecido límites en los recursos informáticos. A medida que pasa el tiempo y más personas los usan, el sistema se ralentiza o incluso se bloquea. Si un modelo tiene que lidiar con mucho tráfico, estas limitaciones probablemente causarán problemas significativos.
2. Estado oculto crea imprevisibilidad
La gestión del estado generalmente no es algo que debe considerar en las plataformas de bajo código. Los valores de las variables no se pierden de una sesión a otra para el usuario. Es adecuado para las pruebas, pero se desorganiza una vez que múltiples usuarios emplean el sistema simultáneamente.
3. Bloques de falta de observabilidad deficiente depuración
Las plataformas de bajo código brindan información básica (como precisión y puntaje F1) pero no admiten monitorear el entorno de producción. Los equipos no pueden ver la latencia de la API, cómo se utilizan los recursos o cómo se ingresan los datos. No es posible detectar los problemas que surgen.
Riesgos de escala AI de bajo código: una vista en capas (imagen del autor)
Una lista de factores a considerar al hacer modelos de código bajo escalable
El código bajo no significa automáticamente que el trabajo sea fácil, especialmente si desea crecer. Es esencial recordar Escalabilidad Desde el principio al hacer un sistema ML con herramientas de bajo código.
1. Piense en la escalabilidad cuando comience a diseñar el sistema.
- Puede utilizar servicios que proporcionen escala automática, como el servicio de Azure Kubernetes en Azure ML y SageMaker Pipelines en AWS.
- Evite los entornos de cómputo predeterminados. Vaya a instancias que puedan manejar más memoria y CPU según sea necesario.
2. Gestión del estado aislado
- Para usar modelos basados en sesiones como chatbots, garantizar que los datos del usuario se borren después de cada sesión.
- Asegúrese de que los servicios web manejen cada solicitud de forma independiente, para que no transmitan la información accidentalmente.
3. Mire los números de producción, así como los números de modelo.
- Monitoree el tiempo de respuesta de su API, el número de solicitudes que fallan y los recursos que usa la aplicación.
- Use PSI y KS-Score para averiguar cuándo las entradas en su sistema no son estándar.
- Concéntrese en los resultados de la empresa, no solo en los números técnicos (tasas de conversión e impacto en las ventas).
4. Implementar equilibrio de carga y escala automática
- Coloque sus modelos como puntos finales administrados con la ayuda de equilibradores de carga (Azure Kubernetes o AWS ELB).
- Puede establecer pautas de escala automática dependiendo de la carga de la CPU, el número de solicitudes o la latencia.
5. Versiones y modelos de prueba continuamente
- Asegúrese de que cada modelo tenga una nueva versión cada vez que cambie. Antes de lanzar una nueva versión al público, debe verificarse en la puesta en escena.
- Realice pruebas A/B para verificar cómo funciona el modelo sin molestar a los usuarios.
Cuando los modelos de código bajo funcionan bien
- Las herramientas de bajo código no tienen fallas significativas. Son poderosos para:
- La prototipos rápidos significa dar prioridad a la velocidad sobre resultados estables.
- Análisis que se realizan dentro del sistema, donde el potencial de falla es mínimo.
- El software simple es valioso en las escuelas, ya que acelera el proceso de aprendizaje.
Un grupo de personas en una startup de atención médica construyó un modelo utilizando AWS Sagemaker Canvas Para atrapar errores de facturación médica. El modelo se creó solo para informes internos, por lo que no necesitaba ampliar y podría usarse fácilmente. Fue un caso perfecto para usar un código bajo.
Conclusión
Las plataformas AI de bajo código proporcionan inteligencia instantánea, ya que no requieren ninguna codificación. Sin embargo, cuando el negocio crece, se revelan sus fallas. Algunos problemas son recursos insuficientes, se filtran información y visibilidad limitada. Estos problemas no se pueden resolver simplemente haciendo unos pocos clics. Son problemas arquitectónicos.
Al comenzar un proyecto de IA de código bajo, considere si se utilizará como un prototipo o un producto comercializable. Si este último, bajo código solo debe ser su herramienta inicial, no la solución final.