a veces veintinueve. Así es febrero: un mes corto.
Aproximadamente cuatro semanas estándar. Unos veinte días laborables. A gran escala, no se produce mucho progreso en estos 4 x 5 días. Y, sin embargo, como siempre, se hacen muchas cosas día a día. Se realizan algunos experimentos. Algunas ideas son rechazadas. Unas cuantas discusiones hacen avanzar las cosas. Algunos cambios de código resultan más importantes de lo esperado.
Al recordar el mes pasado, encontré tres lecciones que me destacaron del mundo de la investigación y la ingeniería de ML:
Los intercambios con otros son importantes, la documentación a menudo se subestima hasta que es demasiado tarde y MLOps sólo tiene sentido si realmente se adapta al entorno en el que se supone que debe usarse.
1. Intercambios con otros
Si lees artículos de ML con regularidad, conoces el patrón: en las citas, normalmente solo se muestra el nombre del primer autor. Los demás nombres sólo aparecen en la sección de referencias. ¿Eso significa que el primer autor lo hizo todo él solo?
Casi nunca. Sólo en el caso especial en el que un solo autor haya escrito únicamente el artículo.
La mayor parte de la investigación vive del intercambio. Vive de discusiones con coautores, de comentarios de colegas, de preguntas que te obligan a agudizar tu pensamiento y de disciplinas adyacentes que aportan ideas que tu propio campo no habría producido por sí solo. Una buena investigación a menudo se siente como entrar en el territorio de otras personas y aprender lo suficiente de su idioma para recuperar algo útil.
Pero esto no se aplica sólo a los trabajos académicos. Esto es igualmente cierto para el trabajo cotidiano de ingeniería.
Un breve intercambio con un colega puede ahorrarle horas de deambular por el camino equivocado. Una conversación de cinco minutos frente a la máquina de café puede brindarle la pieza que falta y que hace que su configuración funcione. Incluso la conversación informal importa. No todas las discusiones útiles comienzan en una reunión programada con una presentación de diapositivas pulida. A veces comienza con “por cierto, noté algo extraño en los registros”.
Este mes me recordó eso nuevamente. Un par de pequeños intercambios aclararon las cosas mucho más rápido que una reflexión solitaria. Nada dramático, nada digno de un discurso de apertura: sólo el valor normal y tranquilo de hablar con otras personas que piensan en cosas similares.
2. Documentación
¿Alguna vez has realizado algunos cambios en tu código?
Seguro que sí.
¿Y aún podrías recordar al día siguiente por qué hiciste esos cambios? Con suerte, sí; después de todo, es solo un día. Pero ¿qué pasa una semana después? ¿Un mes después? ¿Medio año después?
Ahí es donde las cosas se vuelven menos obvias.
La mayoría de los cambios en una base de código son pequeños y benignos. No todas las pequeñas correcciones de errores merecen una explicación larga. Si cambia el nombre de una variable, corrige un error tipográfico o corrige un problema de registro inofensivo, normalmente no necesita documentación especial. Lo mismo ocurre a menudo con las correcciones de errores que no alteran ninguna conclusión relevante de resultados anteriores.
Pero algunos cambios son diferentes.
Algunos cambios alteran los supuestos. Algunos cambian la forma en que se preprocesan los datos. Algunos afectan las características de la capacitación, la lógica de evaluación o incluso el significado de los resultados. Vale la pena anotar esos cambios, porque son exactamente los que habrá olvidado cuando regrese al proyecto más tarde.
Este mes me recordaron, una vez más, que la documentación no es principalmente para algún futuro colaborador abstracto. Es para tu yo futuro. Hoy, mientras estás inmerso en el código, todo parece obvio. En tres meses no será así. Luego mirarás una línea, una configuración o una misteriosa transformación de datos y te preguntarás: “¿Por qué lo hice de esta manera?”
Ésa es una pregunta fácilmente evitable.
3. MLOps puestos en práctica
El objetivo de la mayoría de las investigaciones sobre ML es, de una forma u otra, producir modelos entrenados.
Pero apuesto a que sólo una pequeña minoría de estos modelos se utiliza realmente.
Muchos modelos permanecen donde nacieron: en cuadernos, en servidores de investigación, en presentaciones internas o en artículos. Para ir más allá y darle un uso productivo a un modelo, se necesita más que el modelo en sí. Necesita infraestructura, procesos, monitoreo, reproducibilidad, estrategias de implementación; en otras palabras, herramientas y principios de MLOps.
Si lee anuncios de trabajo en esa dirección, MLOps a menudo parece estar estrechamente vinculado a los proveedores de la nube: AWS, GCP, Azure, canalizaciones nativas de la nube, servicios administrados, entornos de implementación distribuida. Y sí, esas herramientas son importantes. Son importantes y en muchos entornos son exactamente la elección correcta.
Pero vale la pena hacerse una pregunta sencilla: ¿el entorno de destino es realmente un entorno de nube?
Realice un control de calidad automatizado en un entorno industrial. Supongamos que un modelo se utiliza directamente en producción, cerca de las máquinas que crean el producto. ¿Realmente creemos que todos los datos relevantes simplemente se transmiten desde la empresa a alguna nube? ¿Especialmente si esos datos reflejan los procesos centrales de la empresa y, por tanto, parte de su ventaja competitiva? Dudo que muchas empresas se sientan totalmente cómodas exponiendo los entornos críticos para la producción de esa manera.
Aquí es donde cobra importancia una visión más fundamentada de MLOps.
MLOps es útil, sí. Pero no es un conjunto de herramientas específicas, sino más bien una colección de cómo replicar una herramienta en condiciones cambiantes. Y tiene que adaptarse al entorno en el que debe utilizarse, y no al revés. El objetivo no es forzar cada problema de implementación al molde de cualquier herramienta que esté de moda. El objetivo es hacer que los modelos sean útiles bajo restricciones reales, creando las herramientas necesarias para el problema en cuestión.
A veces eso significa canalizaciones en la nube. A veces significa implementación local. A veces significa entornos restringidos con conectividad limitada, control de acceso estricto o limitaciones de hardware en el borde. En todos estos casos, los principios siguen siendo similares: control de versiones, reproducibilidad, monitoreo, implementación segura, operación robusta. Pero la implementación puede verse muy diferente.
Pensamiento final
Febrero fue corto, pero no vacío. Como ocurre con cualquier otro mes del año, hay muchas lecciones que aprender:
El progreso en ML a menudo depende del intercambio con otros, no solo del pensamiento solitario, la documentación es más importante cuando crees que no la necesitarás y MLOps solo se vuelve valioso cuando se adapta al entorno real.
Apuesto a que el mes que viene habrá otra serie de esas lecciones. No necesariamente las llamativas, sino las tranquilas lecciones de “oh, sí, probablemente sea una buena manera” que dictan las actividades diarias.