Imagínate esto: Un científico de datos recibe un problema, desaparece en las profundidades del data warehouse durante meses y emerge triunfante con un archivo pickle. ¿Qué contiene ese archivo? Un modelo que presume de una precisión impresionante y que está listo para que los ingenieros de software lo pongan en producción.

¡Lo hemos conseguido! ¡hicimos machine learning!

Er... no, la verdad es que no.

En los primeros días del ML -y seamos sinceros, esto sigue siendo así en muchas empresas hoy en día- todo giraba en torno a esta criatura mítica conocida como «El Científico de Datos». Se esperaba que lo hicieran todo, desde la gestión de los datos hasta la creación de modelos y el despliegue en producción. Esta es sin duda una idea seductora, pero llena de problemas.

La dura realidad

Algunos de los problemas que surgen de este enfoque y otros similares son los siguientes:

• Mala asignación de competencias: Los científicos de datos son brillantes, pero sus habilidades a menudo se utilizan mejor en otros ámbitos. Sus habilidades de codificación pueden no ser las mejores cuando se trata de código optimizado, y estoy bastante seguro de que para la mayoría de ellos, escribir miles de líneas de SQL no es algo que les fascine.

• Desconexión de la producción: Este enfoque mantiene a los científicos de datos en la oscuridad sobre las realidades de los despliegues de producción, y aunque esto suena como una buena idea para algunos de ellos, en realidad les está quitando oportunidades de aprendizaje que podrían informar sus futuras oportunidades de trabajo.

• Problemas de produccionalización: Cuando llega el momento del despliegue, los ingenieros de MLOps, ML y software a menudo se encuentran rascándose la cabeza, tratando de descifrar el código del científico de datos y entender cómo se supone que debe resolver el problema. Es como recibir un rompecabezas al que le faltan la mitad de las piezas.

• Discrepancia en features: Dado que en un data warehouse, es fácil usar todas las que encontremos. El modelo puede construirse con características que ni siquiera están disponibles cuando llega el momento de ejecutar la inferencia en el mundo real. Imagínese entrenarse para un maratón en casa en una caminadora y luego sorprenderse al descubrir que la carrera es en el Himalaya.

• Falta de escalabilidad: Cuando cada proyecto depende de una sola persona o de un pequeño equipo que se encarga de todo de principio a fin, resulta casi imposible ampliar las operaciones o asumir varios proyectos simultáneamente.

• Dificultad de mantenimiento: Una vez implantado el modelo, ¿quién supervisa su rendimiento? ¿Quién lo actualiza cuando inevitablemente empieza a degradarse? A menudo, cuando hay que reentrenar el modelo el científico de datos ya está trabajando en el siguiente proyecto.

¿El resultado de todo esto? Interesados frustrados que se dan golpecitos en los pies, preguntándose por qué todo tarda tanto o se rompe en pedazos, a veces lentamente, a veces con un fuerte estruendo. La promesa de ML se convierte en un juego de espera.

No estoy aquí para señalar a nadie. Los científicos de datos son increíbles -incluso intenté ser uno de ellos-, pero no tuve su paciencia ni sus habilidades. A lo que quiero llegar es a la importancia de la colaboración, las herramientas y la cultura para que los proyectos de ML tengan éxito.

De las fábricas de modelos a las fábricas de fábricas

Esta es mi propuesta: En lugar de ver el producto final como un modelo entrenado en producción, ¿qué pasaría si apuntáramos a algo más grande? ¿Y si nuestro objetivo fuera crear código que cree, reentrene y supervise modelos?

En otras palabras, dejemos de ser una fábrica de modelos para convertirnos en una fábrica de fábricas de modelos.

No se trata sólo de una diferencia semántica: es un cambio fundamental para abordar los proyectos de aprendizaje automático.

Ventajas del enfoque de fábrica de fábricas

• Reproducibilidad mejorada: No dependemos de la suerte al entrenar un modelo o de la intuición de un único científico de datos. Cada paso del proceso está documentado y es repetible.

• Mejor gestión de errores: Gracias a los de supervisión y formación, a menudo podemos solucionar los problemas sin necesidad de recurrir al científico de datos cada vez que algo va mal.

• Escalabilidad mejorada: Una vez que disponemos de la infraestructura necesaria para crear y gestionar modelos de forma automática, podemos gestionar varios proyectos simultáneamente sin un aumento lineal de la carga de trabajo.

• Tiempo de comercialización más rápido: Con canales automatizados para la preparación de datos, la formación de modelos y el despliegue, podemos pasar de la idea a la producción mucho más rápidamente.

• Mejor asignación de recursos: Los científicos de datos pueden centrarse en tareas de alto valor, como la ingeniería de características y la arquitectura de modelos, en lugar de estancarse en tareas operativas.

• Mayor colaboración: Los procesos claramente definidos y las interfaces compartidas facilitan que los miembros del equipo con diferentes especialidades trabajen juntos de forma eficaz.

• Mejora continua: Con el reentrenamiento y la supervisión automatizados, los modelos pueden adaptarse continuamente a los nuevos datos, manteniendo su rendimiento a lo largo del tiempo sin intervención manual.

• Mejora de la gobernanza y el cumplimiento: Los pipelines automatizados facilitan la implementación y el cumplimiento de las normas para el manejo de datos, la validación de modelos y el despliegue.

Hacerlo realidad: La ruta hacia el éxito

Convertirse en una fábrica de fábricas no se consigue de la noche a la mañana. Requiere un cambio fundamental tanto en las herramientas como en la cultura.
He aquí una lista no exhaustiva de lo que se necesita:

Herramientas esenciales

• Almacenes de datos bien documentados: Ya sea un data lake, un warehouse o una feature store, los datos deben estar listos para que los científicos de datos los consuman. La documentación debe incluir el linaje y la disponibilidad de las funciones (es decir, ¿esta función está disponible en tiempo real?). Los almacenes de datos también deben ser fáciles de modificar y añadir funciones según sea necesario.

• Plataformas de experimentación: Los científicos de datos necesitan entornos en los que puedan probar ideas rápidamente sin preocuparse por romper los sistemas de producción.

• Infraestructura específica de ML: Ya sea una plataforma en la nube o una solución local, la infraestructura debe estar optimizada para las demandas de las cargas de trabajo de aprendizaje automático.

• Seguimiento de experimentos, artefactos y modelos: Herramientas que permitan a los equipos realizar un seguimiento de los diferentes experimentos, comparar versiones de modelos y comprender qué funciona y qué no. Esto también podría servir como catálogo de modelos, un lugar donde todo el mundo pueda saber qué está en producción.

• Frameworks de desarrollo y despliegue: Herramientas que funcionen a la perfección desde el desarrollo hasta la producción, minimizando la necesidad de reescribir el código o de complejas transferencias de código.

• Soluciones de supervisión automatizadas: Sistemas que pueden realizar un seguimiento del rendimiento del modelo, la deriva de los datos y otras métricas clave sin supervisión humana constante, pero capaces de alertar cuando las cosas van mal.

• Sistema de control de versiones: No basta con hacer un seguimiento de los modelos y experimentos; también es necesario hacer un seguimiento del código que los crea, que es nuestro principal producto.

• Plataformas de colaboración: Herramientas que facilitan la comunicación y el intercambio de conocimientos entre los diferentes roles dentro y fuera del equipo de ML.

Cambios culturales necesarios

• Científicos de datos más interesados: Necesitan sentirse cómodos con una gama más amplia de herramientas. No buscamos un científico de datos que lo sepa todo, sino uno que entienda y aproveche las herramientas que tiene a su disposición.

• Inversión en infraestructura: Las empresas deben comprender que invertir en las herramientas y plataformas adecuadas reporta dividendos a largo plazo.

• Planificación inclusiva: Todo el mundo, incluido el personal técnico, debe tener un sitio en la mesa de negociación, desde el principio de un proyecto y a la hora de definir su alcance y etapas.

• Compromiso de las partes interesadas: Tiene que haber voluntad de probar y comprobar los resultados intermedios. El aprendizaje automático no es una solución mágica; necesita una retroalimentación temprana y constante. Los equipos deben sentirse cómodos con la mejora continua y la iteración.

• Pensamiento a largo plazo: Las organizaciones deben planificar el mantenimiento y la mejora continuos de sus sistemas de ML. El software se degrada rápidamente, y el aprendizaje automático se degrada aún más porque es software MÁS datos desordenados.

• Comunicación mejorada: Las reuniones regulares y los canales de comunicación claros entre los equipos de datos, los equipos de ML y otras partes de la organización son esenciales. Debido a su naturaleza, el ML tiende a estar al final de la cadena alimentaria de los datos y, como tal, a menudo es olvidado por los generadores de datos.

• Equipos interfuncionales: Romper los silos entre los científicos de datos, los ingenieros de ML, los desarrolladores de software y los expertos en el dominio conduce a soluciones más sólidas y prácticas.

Nota sobre AutoML

Algunas personas ven AutoML como una solución para adoptar el aprendizaje automático en sus organizaciones. Estas plataformas intentan automatizar muchos aspectos del proceso de ML y ofrecen ventajas como una estrecha integración con los datos, la democratización del ML, una supervisión sencilla y una comercialización más rápida.

Sin embargo, las herramientas AutoML tienen posibles inconvenientes: el riesgo de dependencia del proveedor, la personalización limitada para necesidades empresariales específicas, las posibles restricciones de despliegue y la dificultad para comprender lo que ocurre bajo el capó.

Aunque valiosas, las herramientas AutoML no pueden reemplazar la necesidad de canalizaciones ML personalizadas a medida que las operaciones se vuelven más complejas; son sólo una herramienta en el conjunto de herramientas ML y no niegan la necesidad de cambios. Puede considerarlas un punto de partida, pero prepárese para complementarlas o sustituirlas por soluciones personalizadas a medida que maduren sus operaciones de ML.

La verdadera medida del éxito

Esto no significa que tengas que tener todas las piezas en su sitio ahora mismo para considerarse un éxito. Conseguirlo lleva tiempo y es un proceso. Cada paso que das hacia esta visión es un progreso. Empieza poco a poco, céntrate en una parte de tu flujo de trabajo y sigue avanzando a partir de ahí.

Y si tienes que empezar por algún sitio, hazlo por la cultura. Las herramientas van y vienen, pero una base cultural sólida te servirá independientemente de las tecnologías concretas que utilices.

A medida que esta cultura arraigue, le resultará más fácil identificar qué herramientas necesita y cómo implantarlas con eficacia. También estará mejor posicionado para utilizar estas herramientas de una manera que realmente mejore sus capacidades de ML en lugar de simplemente añadir complejidad.

El verdadero objetivo de un equipo de aprendizaje automático nunca debería ser crear un único modelo perfecto o tener el stack tecnológico más elegante. Se trata de crear un sistema (y un equipo) que pueda producir, mejorar y mantener modelos eficaces de forma constante. Así es como realmente aprovecharemos el poder del aprendizaje automático de una manera que sea sostenible, escalable y realmente útil.

Recuerda, fábricas de fábricas.

[Gracias a Ned Webster y Lorraine D'Almeida por sus comentarios sobre este artículo].