Las lecciones de aprendizaje automático que he aprendido este mes

En el aprendizaje automático son los mismos.

Codificación, esperando resultados, interpretándolos, volviendo a la codificación. Además, algunas presentaciones intermedias del progreso de uno. Pero, las cosas en su mayoría ser las mismas no significa que no hay nada que aprender. ¡Bastante por el contrario! Hace dos o tres años, comencé un hábito diario de escribir lecciones que aprendí de mi trabajo de ML. Al mirar hacia atrás a través de algunas de las lecciones de este mes, encontré tres lecciones prácticas que se destacan:

  1. Sigue registrando simple
  2. Use un cuaderno experimental
  3. Mantenga en cuenta la noche

Sigue registrando simple

Durante años, utilicé pesos y sesgos (W&B)* como mi registrador de experimentos. De hecho, una vez he estado en el 5% superior de todos los usuarios activos. Las estadísticas en la figura a continuación me dicen que, en ese momento, he entrenado cerca de 25000 modelos, utilicé 5000 horas acumulativas de cómputo e hice más de 500 búsquedas de hiperparameter. Lo usé para documentos, para grandes proyectos como la predicción del clima con grandes conjuntos de datos y para rastrear innumerables experimentos a pequeña escala.

Mis estadísticas de tiempo Once Upon a Time de usar W&B para el registro de experimentos. Imagen del autor.

Y W&B realmente es una gran herramienta: si quieres hermosos paneles y estás colaborando ** con un equipo, W&B brilla. Y, hasta hace poco, al reconstruir datos de redes neuronales capacitadas, ejecuté múltiples barridos de hiperparameter y las capacidades de visualización de W&B fueron invaluables. Podría comparar directamente las reconstrucciones entre las ejecuciones.

Pero me di cuenta de que para la mayoría de mis proyectos de investigación, W&B fue excesivo. Raramente revisé las carreras individuales, y una vez que se realizó un proyecto, los registros simplemente se sentaron allí, y no hice nada con ellos nunca después. Cuando refactoré el proyecto de reconstrucción de datos mencionado, eliminé explícitamente la integración W&B. No porque algo estuviera mal con eso, sino porque no era necesario.

Ahora, mi configuración es mucho más simple. Acabo de registrar métricas seleccionadas en CSV y archivos de texto, escribiendo directamente en el disco. Para las búsquedas de hiperparameter, confío en Optuna. Ni siquiera la versión distribuida con un servidor central, solo Optuna local, guardando los estados de estudio en un archivo de encurtido. Si algo se bloquea, vuelvo a cargar y continúo. Pragmático y suficiente (para mis casos de uso).

La información clave aquí es esta: el registro no es el trabajo. Es un sistema de soporte. Gastar el 99% de su tiempo decidiendo lo que quiere registrar: ¿Gradientes? pesas? distribuciones? ¿Y en qué frecuencia? – Puede distraerlo fácilmente de la investigación real. Para mí, el registro local simple cubre todas las necesidades, con un mínimo esfuerzo de configuración.

Mantener cuadernos de laboratorio experimentales

En diciembre de 1939, William Shockley escribió una idea en su cuaderno de laboratorio: reemplace los tubos de vacío con semiconductores. Aproximadamente 20 años después, Shockley y dos colegas en Bell Labs recibieron premios Nobel por la invención del transistor moderno.

Si bien la mayoría de nosotros no estamos escribiendo entradas dignas de Nobel en nuestros cuadernos, aún podemos aprender del principio. De acuerdo, en el aprendizaje automático, nuestras laboratorias no tienen productos químicos o tubos de ensayo, como todos imaginamos cuando pensamos en un laboratorio. En cambio, nuestros laboratorios a menudo son nuestras computadoras; El mismo dispositivo que uso para escribir estas líneas ha entrenado innumerables modelos a lo largo de los años. Y estos laboratorios son inherentemente portátiles, especialmente cuando nos desarrollamos de forma remota en grupos de cómputo de alto rendimiento. Aún mejor, gracias a cosas administrativas altamente calificadas, estos grupos se ejecutan las 24 horas, los 7 días de la semana, ¡así que siempre hay tiempo para ejecutar un experimento!

Pero, la pregunta es, ¿qué experimento? Aquí, un ex colega me presentó la idea de maquillar un cuaderno de laboratorio, y últimamente he vuelto a él en la forma más simple posible. Antes de comenzar experimentos de larga duración, escribo:

Lo que estoy probando y por qué lo estoy probando.

Luego, cuando regrese más tarde, generalmente a la mañana siguiente, puedo ver de inmediato qué resultados están listos y qué esperaba aprender. Es simple, pero cambia el flujo de trabajo. En lugar de simplemente “volver a ejecutar hasta que funcione”, estos experimentos dedicados se convierten en parte de un ciclo de retroalimentación documentado. Las fallas son más fáciles de interpretar. Los éxitos son más fáciles de replicar.

Ejecutar experimentos durante la noche

Esas son lecciones pequeñas pero dolorosas que (re) aprendí este mes.

Un viernes por la noche, descubrí un error que podría afectar los resultados de mi experimento. Lo parché y volví a los experimentos para validar. Para el sábado por la mañana, las carreras habían terminado, pero cuando inspeccioné los resultados, me di cuenta de que me había olvidado de incluir una ablación clave. Lo que significaba … otro día completo de espera.

En ML, durante la noche es precioso. Para los programadores, es descansar. Para nuestros experimentos, es trabajo. Si no tenemos un experimento funcionando mientras dormimos, efectivamente estamos desperdiciando ciclos de cómputo gratuitos.

Eso no significa que debas ejecutar experimentos solo por el bien. Pero cada vez que hay uno significativo para lanzar, comenzar por la noche es el momento perfecto. Los grupos a menudo están subutilizados y los recursos están más rápidamente disponibles y, lo más importante, tendrá resultados para analizar a la mañana siguiente.

Un simple truco es planificar esto deliberadamente. Como Cal Newport menciona en su libro “Profunde Work”, los buenos días de trabajo comienzan la noche anterior. Si conoce las tareas de mañana hoy, puede configurar los experimentos correctos a tiempo.


* Eso no está atacando a W&B (habría sido lo mismo con, por ejemplo, mlflow), sino pedir a los usuarios que evalúen cuáles son los objetivos de su proyecto, y luego pasar la mayor parte del tiempo en perseguir esos objetivos con el mayor enfoque.

** Nota al pie: la mera colaboración no es suficiente en mis ojos para justificar el uso de tales paneles compartidos. Debe obtener más información de tales herramientas compartidas que el tiempo dedicado a establecerlas.