¿Cómo funcionan realmente los productos reales de aprendizaje automático en las principales empresas o departamentos de tecnología? En caso afirmativo, este artículo es para ti 🙂
Antes de hablar sobre la escalabilidad, no dude en leer mi primer artículo sobre los conceptos básicos del aprendizaje automático en producción.
En este último artículo, les dije que pasé 10 años trabajando como ingeniero de inteligencia artificial en la industria. Al principio de mi carrera, aprendí que un modelo en un cuaderno es sólo una hipótesis matemática. Sólo resulta útil cuando su resultado llega a un usuario, a un producto o genera dinero.
Ya les he mostrado cómo se ve el “Aprendizaje automático en producción” para un solo proyecto. Pero hoy la conversación gira en torno a la escala: gestionar decenas, o incluso cientos, de proyectos de aprendizaje automático simultáneamente. Estos últimos años hemos pasado de la Era Sandbox a la Era de la Infraestructura. “Implementar un modelo” es ahora una habilidad no negociable; el verdadero desafío es garantizar que una cartera masiva de modelos funcione de manera confiable y segura.
1. Salir del Sandbox: la estrategia de la disponibilidad
Para comprender el aprendizaje automático a escala, primero debe dejar atrás la mentalidad de “zona de pruebas”. En un sandbox, tienes datos estáticos y un modelo. Si se desvía, lo ves, lo detienes, lo arreglas.
Pero una vez que pasa al modo de escala, ya no administra un modelo, sino una cartera. Aquí es donde el teorema CAP (consistencia, disponibilidad y tolerancia de partición) se convierte en realidad. En una configuración de un solo modelo, puedes intentar equilibrar las compensaciones, pero a escala, es imposible ser perfecto en las tres métricas. Debes elegir tus batallas y, en la mayoría de los casos, la disponibilidad se convierte en la máxima prioridad.
¿Por qué? Porque cuando tienes 100 modelos funcionando, siempre algo se rompe. Si detuvieras el servicio cada vez que un modelo cambiara, tu producto estaría fuera de línea el 50% del tiempo.
Como no podemos detener el servicio, diseñamos modelos para que fallen “limpiamente”. Tomemos un ejemplo de un sistema de recomendación: si su modelo obtiene datos corruptos, no debería fallar ni mostrar un “error 404”. Debería volver a una configuración predeterminada segura (como mostrar los “10 elementos más populares”). El usuario sigue contento y el sistema sigue disponible, aunque el resultado no sea óptimo. Pero para hacer esto, necesita saber cuándo activar ese retroceso. Y eso nos lleva a nuestro mayor desafío a escala…”El monitoreo”.
2. El desafío del monitoreo y por qué las métricas tradicionales mueren a escala
Al decir que a escala es importante que nuestro sistema falle “limpiamente”, se podría pensar que es fácil y que sólo necesitamos verificar o monitorear la precisión. Pero a escala, la “precisión” no es suficiente y te diré exactamente por qué:
La falta de consenso humano: en visión por computadora, por ejemplo, el monitoreo es fácil porque los humanos están de acuerdo con la verdad (es un perro o no lo es). Pero en un sistema de recomendación o en un modelo de ranking de anuncios, no existe un “estándar de oro”. Si un usuario no hace clic, ¿el modelo es malo? ¿O simplemente el usuario no está de humor? La trampa de la ingeniería de características: debido a que no podemos medir fácilmente la “verdad” a través de una métrica simple, compensamos en exceso. Agregamos cientos de características al modelo, con la esperanza de que “más datos” resuelvan la incertidumbre. El techo teórico: luchamos por obtener ganancias de precisión del 0,1% sin saber si los datos son demasiado ruidosos para dar más. Estamos persiguiendo un “techo” que no podemos ver.
Así que vinculemos todo eso para entender hacia dónde vamos y por qué es importante: debido a que monitorear la “verdad” es casi imposible a escala (zonas muertas), no podemos confiar en simples alertas que nos digan que nos detengamos. Esta es exactamente la razón por la que priorizamos la disponibilidad y las alternativas seguras: asumimos que el modelo podría estar fallando sin que las métricas nos lo indiquen, por lo que construimos un sistema que puede sobrevivir a esa falla “confusa”.
3. ¿Qué pasa con The Engineering Wall?
Ahora que hemos discutido la estrategia y los desafíos de monitoreo, todavía no estamos listos para escalar, ya que aún no hemos abordado el aspecto de infraestructura. El escalamiento requiere tanto habilidades de ingeniería como habilidades de ciencia de datos.
No podemos hablar de escalar si no contamos con una infraestructura sólida y segura. Debido a que los modelos son complejos y a que la disponibilidad es nuestra prioridad número uno, debemos pensar seriamente en la arquitectura que configuramos.
En esta etapa, mi sincero consejo es que te rodees de un equipo o de personas acostumbradas a construir grandes infraestructuras. No necesariamente necesitas un clúster masivo o una supercomputadora, pero sí debes pensar en estos tres conceptos básicos de ejecución:
Nube versus dispositivo: un servidor le brinda energía y es fácil de monitorear, pero es costoso. Su elección depende completamente de Costo versus Control. El hardware: simplemente no se pueden poner todos los modelos en una GPU; irías a la quiebra. Necesita una estrategia escalonada: ejecute sus modelos “alternativos” simples en CPU baratas y reserve las GPU costosas para los modelos pesados que “generan dinero”. Optimización: a escala, un retraso de 1 segundo en su mecanismo de respaldo es una falla. Ya no estás simplemente escribiendo Python; debe aprender a compilar y optimizar su código para chips específicos para que el cambio de “Falla limpia” ocurra en milisegundos.
4. Tenga cuidado con las fugas de etiquetas
Entonces, anticipó las fallas, trabajó en la disponibilidad, ordenó el monitoreo y construyó la infraestructura. Probablemente piense que finalmente está listo para dominar la escalabilidad. En realidad, todavía no. Hay un problema que simplemente no puedes anticipar si nunca has trabajado en un entorno real.
Incluso si su ingeniería es perfecta, Label Leakage puede arruinar su estrategia y sus sistemas que ejecutan múltiples modelos.
En un solo proyecto, es posible que detectes fugas en un cuaderno. Pero a escala, donde los datos provienen de 50 oleoductos diferentes, las fugas se vuelven casi invisibles.
El ejemplo de abandono: imagina que estás prediciendo qué usuarios cancelarán su suscripción. Tus datos de entrenamiento tienen una función llamada Last_Login_Date. El modelo luce perfecto con una puntuación del 99% en F1.
Pero esto es lo que realmente sucedió: el equipo de la base de datos configuró un activador que “borra” el campo de fecha de inicio de sesión en el momento en que un usuario presiona el botón “Cancelar”. Su modelo ve una fecha de inicio de sesión “nula” y se da cuenta: “¡Ajá! ¡Cancelaron!”.
En el mundo real, en el milisegundo exacto en el que el modelo necesita hacer una predicción antes de que el usuario la cancele, ese campo aún no es nulo. El modelo busca la respuesta desde el futuro.
Este es un ejemplo básico para que puedas entender el concepto. Pero créanme, si tiene un sistema complejo con predicciones en tiempo real (lo que sucede a menudo con IoT), esto es increíblemente difícil de detectar. Sólo podrás evitarlo si eres consciente del problema desde el principio.
Mis consejos:
Monitoreo de latencia de funciones: no solo supervise el valor de los datos, supervise cuándo se escribieron y cuándo ocurrió realmente el evento. La prueba del milisegundo: pregunte siempre: “En el momento exacto de la predicción, ¿esta fila específica de la base de datos ya contiene este valor?”
Por supuesto, estas son preguntas simples, pero el mejor momento para evaluarlas es durante la fase de diseño, antes de escribir una línea de código de producción.
5. Finalmente, el bucle humano
La última pieza del rompecabezas es la rendición de cuentas. A escala, nuestras métricas son confusas, nuestra infraestructura es compleja y nuestros datos tienen fugas, por lo que necesitamos una “red de seguridad”.
Despliegue en la sombra: esto es obligatorio para escalar. Implementa el “Modelo B” pero no muestra sus resultados a los usuarios. Lo dejas correr “en las sombras” durante una semana, comparando sus predicciones con la “Verdad” que finalmente llega. Si es estable, sólo entonces lo promocionas a “En vivo”. Human-in-the-Loop: para modelos de alto riesgo, necesita un pequeño equipo para auditar los “valores predeterminados seguros”. Si su sistema ha vuelto a “Elementos más populares” durante tres días, un humano debe preguntar por qué el modelo principal no se ha recuperado.
Y un breve resumen antes de empezar a trabajar con ML a escala:
Como no podemos ser perfectos, elegimos permanecer en línea (Disponibilidad) y fallar de manera segura. La disponibilidad es nuestra métrica número 1, ya que el monitoreo a escala es “confuso” y las métricas tradicionales no son confiables. Construimos la infraestructura (Nube/Hardware) para acelerar estas fallas seguras. Estamos atentos a los datos “engañosos” (fugas) que hacen que nuestras métricas confusas parezcan demasiado buenas para ser verdad. Usamos Shadow Deploys para demostrar que el modelo es seguro antes de que llegue a tocar a un cliente.
Y recuerde, su báscula es tan buena como su red de seguridad. No dejes que tu trabajo esté entre el 87% de proyectos fallidos.
👉 LinkedIn: Sabrine Bendimerad
👉 Medio: https://medium.com/@sabrine.bendimerad1
👉 Instagram: https://tinyurl.com/datailearn