) en el trabajo de aprendizaje automático son los mismos.
Codificar, esperar resultados, interpretarlos, volver a codificar. Además, algunas presentaciones intermedias de su progreso a la dirección*. Pero que las cosas sean prácticamente iguales no significa que no haya nada que aprender. ¡Todo lo contrario! Hace dos o tres años, comencé el hábito diario de escribir las lecciones que aprendí de mi trabajo de ML. Aún así, hasta el día de hoy, cada mes me deja un puñado de pequeñas lecciones. Aquí hay tres lecciones del mes pasado.
Conexión con humanos (sin ML involucrado)
A medida que se acerca la temporada navideña, comienzan las reuniones de fin de año. A menudo, estas reuniones se componen de charlas informales. No se hace mucho “trabajo”, lo cual es natural, ya que normalmente se trata de eventos posteriores al trabajo. Por lo general, me salto esos eventos. Para la temporada navideña, sin embargo, no lo hice. Me uní a algunas reuniones después del trabajo durante las últimas semanas y simplemente hablé, nada urgente, nada profundo. La socialización fue buena y me divertí mucho.
Me recordó que nuestros proyectos de trabajo no se ejecutan solo con código y computación. Funcionan con el combustible de trabajar juntos con otros durante mucho tiempo. Aquí, los pequeños momentos (una broma, una historia breve, una queja compartida sobre las GPU defectuosas) pueden recargar el motor y hacer que la colaboración sea más fluida cuando las cosas se pongan tensas más adelante.
Piénselo desde otra perspectiva: sus colegas tendrán que vivir con usted durante muchos años. Y tú con ellos. Si esto fuera un “rodamiento” – nono, no es bueno. Pero si esto es “juntos”, sí, definitivamente es bueno.
Entonces, cuando las invitaciones a reuniones de su empresa o instituto de investigación lleguen a su buzón: únase.
Copiloto no necesariamente me hizo más rápido
El mes pasado, estuve configurando un nuevo proyecto y adaptando una lista de algoritmos a un nuevo problema.
Un día, mientras perdía tiempo sin pensar en la web, me encontré con un estudio del MIT** que sugería que la asistencia (intensa) de la IA, especialmente antes de hacer el trabajo, puede reducir significativamente el recuerdo, reducir el compromiso y debilitar la identificación con el resultado. Por supuesto, el estudio utilizó la redacción de ensayos como objetivo de la prueba, pero codificar un algoritmo es una tarea igualmente creativa.
Así que intenté algo simple: desactivé completamente Copilot en VS Code.
Después de algunas semanas, mis resultados (subjetivos y autoevaluados, por lo tanto muy sesgados) fueron: ninguna diferencia notable en mis tareas principales.
Para escribir bucles de entrenamiento, los cargadores, la anatomía del entrenamiento, los conozco bien. En estos casos, las sugerencias de la IA no agregaron velocidad; a veces incluso añadían fricción. Basta pensar en corregir los resultados de la IA que son casi correctos.
Ese hallazgo contrasta un poco con cómo me sentí hace uno o dos meses cuando tuve la impresión de que Copilot me hacía más eficiente.
Al pensar en las diferencias entre los dos momentos, se me ocurrió que el efecto parece depender del dominio. Cuando estoy en un área nueva (por ejemplo, programación de carga), la asistencia me ayuda a entrar en el campo más rápidamente. En mis dominios locales, las ganancias son marginales y pueden conllevar desventajas ocultas que tardan años en notarse.
Mi opinión actual sobre los asistentes de IA (que solo he usado para codificar a través de Copilot): son buenos para avanzar hacia territorios desconocidos. Para el trabajo principal que define la mayor parte de su salario, es, en el mejor de los casos, opcional.
Por lo tanto, para el futuro, puedo recomendar otros a
Escribe tú mismo el primer pase; use IA solo para pulir (nombrar, pequeños refactores, pruebas). Honestamente, compruebe los beneficios proclamados de la IA: 5 días con la IA apagada, 5 días con ella encendida. Entre ellos, realice un seguimiento: tareas completadas, errores encontrados, tiempo para finalizar, qué tan bien puede recordar y explicar el código un día después. Alternar al alcance de su mano: vincule una tecla de acceso rápido para habilitar/deshabilitar sugerencias. Si lo busca cada minuto, probablemente lo esté usando demasiado.
Pragmatismo cuidadosamente calibrado
Como gente de ML, podemos pensar demasiado en los detalles. Un ejemplo es qué tasa de aprendizaje utilizar para la capacitación. O bien, utilizar una tasa de aprendizaje fija en lugar de degradarlas en pasos fijos. O si se debe utilizar una estrategia de recocido coseno.
Verá, incluso para el caso LR simple, rápidamente se pueden encontrar muchas opciones; ¿Cuál deberíamos elegir? Recientemente di vueltas sobre una versión de esto.
En estos momentos me ayudó a alejarme: ¿qué le importa al usuario final? Principalmente, se trata de latencia, precisión, estabilidad y, a menudo, principalmente, costo. No les importa qué horario de LR elijas, a menos que afecte a esos cuatro. Esto sugiere un enfoque aburrido pero útil: elegir la opción viable más sencilla y apegarse a ella.
Unos pocos valores predeterminados cubren la mayoría de los casos. Optimizador de línea base. Vainilla LR con un hito de descomposición. Una simple regla para detenerse temprano. Si las métricas son malas, opte por opciones más sofisticadas. Si son buenos, sigue adelante. Pero no arrojes todo al problema de una vez.
* Parece ser que incluso en Deepmind, probablemente el instituto de investigación pura más exitoso (al menos antes), los investigadores tienen gestión que satisfacer.
** El estudio está disponible en arXiv en: https://arxiv.org/abs/2506.08872