Y digo que es normal porque, en el fondo, eso, lo que aporta al negocio o a nuestra actividad, es lo más atractivo, los más transformador, lo más diferencial de la inteligencia artificial, como pasa con cualquier otra tecnología.
Sin embargo, en la vida real, y para que cualquier tecnología, cualquier sistema en el caso del software, y cualquier solución basada en inteligencia artificial puedan proporcionar de manera escalable y fiable esas capacidades, es preciso aplicar criterios y técnicas profesionales de desarrollo y de operación de sistemas.
La ingeniería de software y la operación de servicios
La combinación de los mecanismos tradicionales de la ingeniería de software con los principios agile y el apoyo de soluciones basadas en la nube y arquitecturas cloud nativa da lugar al enfoque DevOps predominante hoy en día Cuando eso se adapta al caso específico de soluciones basadas en machine learning, llegamos al MLOps y, en el caso específico de las soluciones basadas en grandes modelos de lenguaje (LLM, 'Large Language Models') llegamos al LLMOps.
En realidad, los pasos de la ingeniería de software y operación de servicios tradicional al DevOps, de éste al MLOps y de éste, a su vez, al LLMOps, son evoluciones y adaptaciones, algunas muy importantes ciertamente, de unas ideas, que en lo más fundamental, se conocen y aplican desde hace muchos años en ingeniería software y operación de servicios.
Los seis principios para la operación del machine learning
Podríamos decir que, en el fondo, existe una filosofía o una serie de principios subyacentes a toda esta gestión y operación de sistemas y servicios.
Precisamente, en el libro 'LLM Engineer's handbook' de Paul Lusztin y Maxime Labonne, dedicado en gran medida a esta ingeniería del software en el caso de LLMs, dedican un apéndice final a identificar seis principios para la operación de los sistemas de machine learning aunque, en el fondo, no están hablando tanto de machine learning en general, como de soluciones basadas en LLMs.
Los seis principios que identifican estos autores, son los siguientes:
- Automatización y operativización
- Versionado
- Experimentos y seguimiento de experimentos
- Pruebas
- Monitorización
- Reproducibilidad
Vamos a repasarlos, brevemente.
Principio 1: Automatización y operativización
La ingeniería de software no deja de ser un proceso productivo, un proceso que, como tal, se ha intentado automatizar aunque es cierto que, sólo hace pocos años se ha conseguido una automatización real, una automatización de momento más centrada en el despliegue y la operación, especialmente con la llegada, no sólo de la filosofía DevOps sino con soluciones para automatizar pruebas y 'pipelines' de despliegue. Una automatización que, sin embargo, y por mor, precisamente, de los grandes modelos de lenguaje, apunta a que se va a poder automatizar también en buena medida en lo relativo a desarrollo.
Los autores mencionados nos hablan de una suerte de tres etapas en automatización. La primera sería esencialmente manual.
En la segunda se introduce el entrenamiento continuo (CT, 'Continuous Training') que se lanza cada vez que es necesario re-entrenar un modelo y donde se automatizan, aparte del entrenamiento propiamente dicho, los pasos de validación de datos y del modelo. En este caso se recurre a herramientas de orquestación de las que los autores citan como ejemplo ZenML. A modo meramente ilustrativo, abajo se puede ver un esquema de las pipelines de ZenML
 |
| Pipelines ZenML |
En la última fase, sugieren la introducción de los principios de la entrega y despliegue continuos (CI/CD, 'Continuous Integration' / 'Continuous Deployment') tan característicos de DevOps y donde se incluye también la construcción, prueba y despliegue.
Principio 2: Versionado
La creación y control de versiones cae dentro de la muy tradicional actividad de la ingeniería de software tradicional conocida como control de configuración. En esa actividad se gestiona la gestión del software que aporta cada desarrollador, las versiones de componentes, la integración de componentes en versiones o 'releases' consistentes y la construcción ('building') del software de las esas 'releases'.
Para el caso de las soluciones de machine learning o basadas en LLMs, los autores nos sugieren centrarnos en las versiones tanto del código (que es lo que se hace, digamos, 'desde siempre') como de modelos y de datos.
Para la gestión de versiones del código se pueden usar las habituales herramientas de control de configuración, estando muy presente hoy día Git, directamente o a través de hostings como GitHub. Y el control de versiones del modelo no es muy diferente y se apoya en registro de modelos ('model registry').
Sin embargo, para el caso de control de versiones de datos, los autores apuntan la dificultad derivada de la existencia de diferentes tipos de datos. No obstante, existen soluciones de entre las cuales los autores mencionan Comet ML, Weights & Biases y, de nuevo, ZenML.
Principio 3: Experimentos y seguimiento de experimentos
El entrenamiento de modelos es un proceso iterativo y, en buena medida, experimental. En ese proceso experimental se realizan, claro, experimentos, unos experimentos que con frecuencia se llevan a cabo en paralelo y, una vez vistos los resultados, se decide el modelo que realmente 'se da por bueno' y que se traslada a producción
De estos experimentos, también conviene realizar una gestión, un trazado ('tracking') de los que también conviene realizar un seguimiento y gestión mediante herramientas que permiten el registro de 'logs', la representación visual de las predicciones de los modelos, la comparativa de métricas y la selección final el mejor modelo.
Como apoyo a esta actividad loas autores mencionan herramientas como Comet ML, Weights & Biases, MLFlow y Neptune.
Principio 4: Pruebas
Las pruebas, y su automatización, es uno de los focos desde siempre de la ingeniería de software y de las soluciones de operación de servicios.
Los autores nos recuerdan los diferentes niveles de pruebas (unitarias, integración, sistema, aceptación) y algunas variantes concretas como las pruebas de regresión o las de stress. En ese sentido, 'nada nuevo bajo el sol', es de lo que se habla en ingeniería de software desde hace años y años.
Sin embargo, sí que nos aportan alguna idea original o específica del caso del machine learning, cuando explican la prueba de modelos, donde se añade la dificultad de que los modelos no son deterministas al, contrario de lo que sucede en muchas otras formas de software. Además, los modelos pueden no reportar ningún error y, sin embargo, no estar funcionando adecuadamente y esos malos comportamientos sólo se pueden observar en evaluaciones.
Los autores mencionan algunas técnicas específicas para la prueba de modelos, como
- Probar la 'forma' de los tensores de entrada y salida del modelo
- Probar que la pérdida o error ('loss') realmente decrece, como es lo que cabe esperar después de un lote ('bacth') de entrenamiento
- Probar que el 'pipeline' de entrenamiento funciona tanto con CPUs como con GPUs.
- etc
Todas las pruebas se realizan en la fase de integración continua (CI, 'Continous Integration').
También nos hablan de la prueba de comportamiento ('behavioral testing') en que se considera al modelo una caja negra y se comprueban sólo entradas y salidas.
Principio 5: Monitorización
La monitorización es, desde siempre, una actividad fundamental de la operación de sistemas y, en el caso de machine learning no iba a ser menos. En la monitorización se observa, por ejemplo, que los sistemas están disponibles, que los tiempos de respuesta son adecuados, que no está recibiendo ciberataques, que no se producen errores, etc
Los sistemas de información tradicionales, una vez que están probados, depurados y estabilizados, tienden a no producir errores salvo ataques, averías o sobrecargas. Y eso es así porque se trata de sistemas deterministas con sus condicionas y casos de uso bien definidos.
Sin embargo, en el caso de los sistemas basados en modelos de machine learning esto no es así, porque su entorno y los casos de uso no se suelen encontrar completamente cerrados, porque su comportamiento con frecuencia no es determinista y porque el entorno varía. Eso puede llevar, por ejemplo, a que un modelo que funciona inicialmente muy bien, poco a poco vaya degradando sus resultados, sus predicciones y sea necesario un re-entrenamiento.
De cara a la monitorización los sistemas deben producir registros en forma de 'logs' que permitan el análisis, y se deben definir también una serie de métricas, tanto a nivel de sistema (métricas tradicionales) como de modelo (métricas como las conocidas F1, precision y 'recall') que permitan seguir y analizar el comportamiento y levantar alarmas en su caso.
Los autores nos hablan también de las derivas ('drifts') es decir, desviaciones progresivas del comportamiento original y que pueden producirse tanto en las distribuciones de los datos de entrada ('data drift'), distribuciones de las salidas ('target drift'), o en la relación entre ambos ('concept drift'). También aportan ideas sobre cómo tratar estas derivas, aunque ya no profundizaré más en ello.
Principio 6: Reproducibilidad
Finalmente, se menciona la reproducibilidad que quiere decir que las mismas entradas deben producir las mismas salidas.
En software tradicional, determinista y basado en reglas, se trata de un concepto muy básico, muy evidente y es fundamental en el planteamiento de las pruebas.
Pero ¿Cómo entender esto en el caso de modelos de machine learning y específicamente grandes modelos de lenguaje que siempre decimos que son probabilistas y no deterministas?
Bien, el truco está en que, estrictamente hablando, los modelos no son probabilistas sino que dependen de parámetros concretos, como la semilla ('seed') o la temperatura que es lo que los convierte realmente en probabilistas. Si utilizamos siempre la misma semilla ('seed') y ajustamos adecuadamente otros parámetros como la temperatura, el modelo se convierte en perfectamente determinista y es posible, y deseable, ver que en esas condiciones se mantiene la reproducibilidad..
Conclusiones
Como se puede observar, los sistemas basados en machine learning y, particularmente, los basados en grandes modelos de lenguaje, además de ofrecer unas grandes capacidades, presentan necesidad de ser gestionados y operados de manera profesional.
En esa labor, heredan muchas de las buenas prácticas y herramientas de los sistemas tradicionales y procedentes de la ingeniería de software o de planteamientos como DevOps.
En buena medida, son aplicables estas mismas buenas prácticas y herramientas, pero también se presentan particularidades y desafíos propios que precisan de nuevas técnicas y herramientas específicas.
