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:
Para nuevos proyectos, elija bibliotecas use sabiamente un administrador de portapapeles para guardar sus clips leídos ampliamente para leer profundamente
Elegir entre bibliotecas y código propio
Los proyectos de aprendizaje automático a menudo comienzan con la misma pregunta: ¿debería construir todo usted mismo o confiar en las bibliotecas existentes?
En el nivel más fundamental, esto puede significar decidir entre marcos como Pytorch o TensorFlow. Cuando hacia la ciencia de los datos todavía estaba alojada en Medium, era un firme defensor del flujo de tensor. Hoy me inclino mucho más hacia Pytorch. Pero esta sección no se trata de tales decisiones a nivel de marco.
En cambio, quiero centrarme en las opciones a nivel de proyecto.
Imagine que tiene la tarea de configurar un nuevo proyecto ML. Los requisitos son específicos: datos etiquetados escasamente, entradas de imágenes y algunas limitaciones arquitectónicas. ¿Qué debes hacer?
Un buen punto de partida es buscar en GitHub para proyectos que ya puedan satisfacer la mayoría de sus necesidades. Si encuentra uno que coincide al 100%, genial, úselo. Si no encuentra nada cercano, eso también es genial, porque la decisión ahora es clara: necesitará construirlo usted mismo.
El caso más desafiante es cuando encuentras algo, pero no encaja del todo. ¿Parche la base de código existente hasta que funcione? ¿O sería más rápido implementar su propia solución desde cero?
No hay una sola respuesta correcta, pero he encontrado útil algunas reglas generales:
Si necesita un control de grano fino sobre todos los aspectos de la tubería ML → Cóndelo usted mismo.
Si solo necesita una tubería de entrenamiento estándar → Use una biblioteca.
Si desea modificar un método existente → Comience con la biblioteca que ya lo tiene.
Si está presentando su propio método → hágalo usted mismo.
Otro factor que vale la pena considerar es la longevidad. El código que escribe usted mismo es el código que controla plenamente: no hay cambios repentinos de ruptura, sin errores obscatos ocultos en un repositorio de terceros. Por otro lado, las bibliotecas pueden proporcionarle años de pruebas y optimización acumuladas, cosas que tendrá dificultades para reproducir solo. El arte es equilibrar la velocidad del progreso ahora contra la mantenibilidad más adelante.
A veces, incluso he descubierto que comenzar con una biblioteca para la prototipos rápidos, y luego reimplementar las partes cruciales una vez que supe lo que funciona, acaricia el mejor equilibrio. De esa manera, recibo comentarios rápidos temprano, pero aún así conservo la propiedad total sobre las piezas que más importan. En mi experiencia, las mejores bibliotecas, al menos para proyectos pesados de investigación, son aquellas que se sienten como el código de investigación.
Dos ejemplos contrastantes serían las bibliotecas de avalancha y gigantescos. Avalanche está mucho más plenamente, y todo está muy abstraído. Por otro lado, Mammoth se parece más a un proyecto de investigación ampliado, donde aún puede controlar directamente las partes metodológicas. Bibliotecas como esa última pueden darle lo mejor de ambos mundos.
Las pautas anteriores no resolverán el dilema de la biblioteca SelfVs cada vez, pero sobrevivieron me permitieron abordarlo más sistemáticamente. Con los años, y este septiembre nuevamente, me salvaron días de indecisión.
El beneficio de los gerentes de portapapeles
Supongamos que está controlando un proyecto ML desde la línea de comandos. Empiezas una carrera como esta: python3 run.py – -param1 – -param2
Luego otro con diferentes parámetros. Y otro. Pronto estás haciendo malabarismos con varias carreras y quieres comparar los resultados.
La forma ingenua es copiar cada salida manualmente en un lugar central: copiar, pegar; Copiar, pegar; Copie, pegue. Hasta que en algún momento, sobrescribe el resultado incorrecto y tienes que comenzar de nuevo.
Esta situación exacta se me ocurrió a principios de este mes. Cuando estaba configurando un nuevo proyecto (después de decidir hacerlo yo mismo en lugar de usar una biblioteca; ver arriba), también hice algunas pruebas de código. Quería ver si todo se ejecuta sin ningún error. Entonces, evalué varias configuraciones de parámetros, a menudo cambiando de uno a dos argumentos de ejecución a ejecución. Como mi proyecto era un proyecto de ML, y por lo tanto implicaba capacitar modelos ML, tardó un tiempo en que se ejecutara un script, lo que significaba que tenía que esperar hasta que pudiera probar el siguiente parámetro. Girar en ejecuciones separadas no era una opción debido a la ocupación del clúster.
Entre la prueba de dos parámetros, me concentré en la configuración del proyecto y la fijación de errores. Luego, una vez que vi que se había probado un parámetro con éxito, programé la siguiente prueba de parámetros y reanudé la configuración del proyecto.
Como puedes imaginar, esta estrategia solo funciona hasta cierto punto. Después de repetir esto de un lado a otro por un tiempo, perdí la pista de las combinaciones de parámetros que ya probé. Debido a que era solo una fase de configuración, aún no había implementado pruebas reales y recopilación de resultados; Esto lo hago más tarde. Afortunadamente, mi hábito de copiar comandos, pegarlos y luego modificar argumentos me salvó de tener que ejecutar la prueba dos veces. Esto, en combinación con el uso de un administrador de portapapeles.
En lugar de almacenar solo el elemento más reciente, estas herramientas mantienen un historial de todo lo que ha copiado. En cualquier momento, puede navegar y seleccionar el clip que necesita*.
La verdadera fuerza de los gerentes de portapapeles es cómo reducen la sobrecarga cognitiva. En lugar de preocuparme constantemente “¿Acabo de sobrescribir mi última copia?” o “¿Dónde guardé ese fragmento?”, Libres el ancho de banda mental para la tarea real en cuestión. Es una de esas herramientas pequeñas ** que no parece mucho, sino que se agrava con el tiempo.
Y lo que es más importante, se trata solo de experimentos. Lo mismo se mantiene cuando está preparando una charla, redactando un documento o recopilando cifras de múltiples fuentes. Una vez que haya usado un administrador de portapapeles el tiempo suficiente, se preguntará cómo trabajó sin uno.
Puedo dar fe de mi propia experiencia. En mis máquinas MAC, he estado usando el Manager de Playbarbook de Launchbar (¡aunque es mucho más que esto!) Durante años; Y en Windows instalé la utilidad Ditto gratuita. A menudo me han ayudado cuando recorté algo, luego eliminé el contenido original (de el cual quería recortar algo). En todo momento, los últimos clips todavía estaban disponibles con un solo comando, proporcionándome fácilmente la información necesaria.
Profundidad y amplitud en la lectura
El mismo proyecto también me recordó algo sobre los documentos de lectura. Configurarlo requirió combinar avances metodológicos recientes con datos tabulares. Como siempre, hubo una avalancha de trabajo potencialmente relevante. La pregunta era: ¿Qué debo leer y qué puedo omitir?
Esta vez, la decisión fue más fácil de lo esperado. En los últimos meses, había estado leyendo documentos regularmente, no intensamente, sino constantemente, dentro y fuera. Eso me dio un mapa mental sólido de mi campo de investigación. Más importante aún, también había leído trabajo adyacente, es decir, documentos que no son completamente de mi campo, pero que abordan desafíos muy similares.
La lectura ampliamente ahora me ayudó a identificar conexiones en todos los campos y reconocer qué métodos eran realmente relevantes. En lugar de sentirme abrumado, podía decidir rápidamente qué documentos valían mi atención y cuáles podría ignorar con seguridad.
Pero, el beneficio va más allá de la eficiencia (y el conocimiento, el objetivo principal de la lectura). Mirar fuera de su campo principal a menudo le ofrece ideas que no habría encontrado de otra manera. Para mí, las ideas de las áreas adyacentes a veces terminan dando forma al núcleo de mis propios proyectos. En otras palabras, la amplitud no es solo la preparación para la profundidad, también es una fuente de creatividad.
Con el tiempo, la práctica de la lectura de los campos cercanos genera resiliencia. Los campos de investigación cambian rápidamente, y los métodos que están en moda hoy pueden olvidarse mañana. Pero si ha cultivado la amplitud, puede adaptarse más fácilmente: ya conoce los campos vecinos y puede moverse con el campo en lugar de ser arrastrado por él.
* No se recomienda, pero a menudo la forma más rápida en las primeras etapas de un proyecto. Para etapas posteriores, recomiendo registrar centralmente los resultados.
** Para Windows: ídem; Para Mac: LaunchBar.