~No te repitas~

No te repitas means Don't repeat yourself in English.

馃 Filosof铆a de Dise帽o de Transformers

“No te repitas a ti mismo”, o DRY, es un principio bien conocido en el desarrollo de software. El principio se origina en “El programador pragm谩tico”, uno de los libros m谩s le铆dos sobre dise帽o de c贸digo. El mensaje simple del principio tiene un sentido obvio: no vuelvas a escribir una l贸gica que ya existe en otro lugar. Esto asegura que el c贸digo permanezca sincronizado, haci茅ndolo m谩s f谩cil de mantener y m谩s robusto. Cualquier cambio en este patr贸n l贸gico afectar谩 uniformemente a todas sus dependencias.

A primera vista, el dise帽o de la biblioteca Transformers de Hugging Face no podr铆a ser m谩s contrario al principio DRY. El c贸digo del mecanismo de atenci贸n se copia m谩s o menos 50 veces en diferentes archivos de modelos. A veces, el c贸digo del modelo completo de BERT se copia en otros archivos de modelos. A menudo forzamos que las nuevas contribuciones de modelos id茅nticos a los modelos existentes – excepto una peque帽a modificaci贸n l贸gica – copien todo el c贸digo existente. 驴Por qu茅 hacemos esto? 驴Somos simplemente demasiado perezosos o abrumados para centralizar todas las piezas l贸gicas en un solo lugar?

No, no somos perezosos: es una decisi贸n muy consciente no aplicar el principio de dise帽o DRY a la biblioteca Transformers. En cambio, decidimos adoptar un principio de dise帽o diferente al que nos gusta llamar la pol铆tica del archivo de modelo 煤nico. La pol铆tica del archivo de modelo 煤nico establece que todo el c贸digo necesario para el pase hacia adelante de un modelo se encuentra en un solo archivo, llamado el archivo de modelo. Si un lector quiere entender c贸mo funciona BERT para inferencia, solo tiene que mirar el archivo modeling_bert.py de BERT. Por lo general, rechazamos cualquier intento de abstraer los subcomponentes id茅nticos de diferentes modelos en un nuevo lugar centralizado. No queremos tener un attention_layer.py que incluya todos los posibles mecanismos de atenci贸n. Nuevamente, 驴por qu茅 hacemos esto?

En resumen, las razones son:

  • 1. Transformers se construye por y para la comunidad de c贸digo abierto.
  • 2. Nuestro producto son los modelos y nuestros clientes son usuarios que leen o ajustan el c贸digo del modelo.
  • 3. El campo del aprendizaje autom谩tico evoluciona extremadamente r谩pido.
  • 4. Los modelos de aprendizaje autom谩tico son est谩ticos.

1. Construido por y para la comunidad de c贸digo abierto

Transformers se construye para incentivar activamente las contribuciones externas. Una contribuci贸n suele ser una correcci贸n de errores o una nueva contribuci贸n de modelo. Si se encuentra un error en uno de los archivos de modelo, queremos que sea lo m谩s f谩cil posible para el que lo encuentra corregirlo. Hay pocas cosas m谩s desmotivantes que corregir un error solo para ver que caus贸 100 fallas en otros modelos.

Debido a que el c贸digo del modelo es independiente de todos los dem谩s modelos, es bastante f谩cil para alguien que solo comprende el modelo con el que est谩 trabajando corregirlo. De manera similar, es m谩s f谩cil agregar nuevo c贸digo de modelado y revisar la PR correspondiente si solo se agrega un nuevo archivo de modelo. El contribuyente no tiene que averiguar c贸mo agregar nueva funcionalidad a un mecanismo de atenci贸n centralizado sin romper los modelos existentes. El revisor puede verificar f谩cilmente que ninguno de los modelos existentes est谩 roto.

2. El c贸digo de modelado es nuestro producto

Suponemos que una cantidad significativa de usuarios de la biblioteca Transformers no solo lee la documentaci贸n, sino que tambi茅n revisa el c贸digo de modelado real y potencialmente lo modifica. Esta hip贸tesis est谩 respaldada por la biblioteca Transformers que se ha bifurcado m谩s de 10,000 veces y el art铆culo de Transformers que ha sido citado m谩s de mil veces. Por lo tanto, es de suma importancia que alguien que lea el c贸digo de modelado de Transformers por primera vez pueda entenderlo y potencialmente adaptarlo. Proporcionar todos los componentes l贸gicos necesarios en orden en un solo archivo de modelado ayuda mucho a lograr una mejor legibilidad y adaptabilidad. Adem谩s, nos importa mucho el nombre de las variables/m茅todos y preferimos un c贸digo expresivo/legible en lugar de un c贸digo eficiente en caracteres.

3. El aprendizaje autom谩tico est谩 evolucionando a una velocidad vertiginosa

La investigaci贸n en el campo del aprendizaje autom谩tico, y especialmente en las redes neuronales, evoluciona extremadamente r谩pido. Un modelo que era estado del arte hace un a帽o puede estar desactualizado hoy. No sabemos qu茅 mecanismo de atenci贸n, incrustaci贸n de posici贸n o arquitectura ser谩 la mejor dentro de un a帽o. Por lo tanto, no podemos definir patrones l贸gicos est谩ndar que se apliquen a todos los modelos.

Como ejemplo, hace dos a帽os, se podr铆a haber definido la capa de auto-atenci贸n de BERT como la capa de atenci贸n est谩ndar utilizada por todos los modelos de Transformers. L贸gicamente, una funci贸n de atenci贸n “est谩ndar” podr铆a haberse movido a un archivo central attention.py. Pero luego vinieron capas de atenci贸n que agregaron incrustaciones posicionales relativas en cada capa de atenci贸n (T5), m煤ltiples formas diferentes de atenci贸n segmentada (Reformer, Longformer, BigBird) y un mecanismo de atenci贸n separado para las incrustaciones de posici贸n y palabras (DeBERTa), etc. Cada vez tendr铆amos que habernos preguntado si la funci贸n de atenci贸n “est谩ndar” deb铆a adaptarse o si hubiera sido mejor agregar una nueva funci贸n de atenci贸n a attention.py. Pero, 驴c贸mo la nombramos? attention_with_positional_embd, reformer_attention, deberta_attention?

Es peligroso dar nombres generales a los componentes l贸gicos de los modelos de aprendizaje autom谩tico porque la percepci贸n de lo que representa este componente puede cambiar o volverse obsoleta muy r谩pidamente. Por ejemplo, 驴corresponde la atenci贸n fragmentada a la atenci贸n fragmentada de GPTNeo, Reformer o BigBird? 驴La capa de atenci贸n es una capa de autoatenci贸n, una capa de atenci贸n cruzada o incluye ambas? Sin embargo, si nombramos las capas de atenci贸n por el nombre de su modelo, deber铆amos colocar directamente la funci贸n de atenci贸n en el archivo de modelado correspondiente.

4. Los modelos de aprendizaje autom谩tico son est谩ticos

La biblioteca Transformers es una colecci贸n unificada y pulida de modelos de aprendizaje autom谩tico creados por diferentes equipos de investigaci贸n. Cada modelo de aprendizaje autom谩tico generalmente va acompa帽ado de un art铆culo y su repositorio oficial en GitHub. Una vez que se publica un modelo de aprendizaje autom谩tico, rara vez se adapta o se cambia posteriormente.

En cambio, los equipos de investigaci贸n tienden a publicar un nuevo modelo basado en modelos anteriores, pero rara vez realizan cambios significativos en el c贸digo ya publicado. Esta es una realizaci贸n importante al momento de decidir los principios de dise帽o de la biblioteca Transformers. Significa que una vez que se ha agregado una arquitectura de modelo a Transformers, los componentes fundamentales del modelo ya no cambian. A menudo se encuentran y corrigen errores, los m茅todos y variables pueden cambiar de nombre, y el formato de entrada o salida del modelo puede cambiar ligeramente, pero los componentes principales del modelo ya no cambian. En consecuencia, la necesidad de aplicar cambios globales a todos los modelos en Transformers se reduce significativamente, lo que hace menos importante que cada patr贸n l贸gico exista solo una vez, ya que rara vez cambia.

Una segunda realizaci贸n es que los modelos no dependen entre s铆 de manera bidireccional. Los modelos publicados m谩s recientes pueden depender de modelos existentes, pero es bastante obvio que un modelo existente no puede depender l贸gicamente de su sucesor. Por ejemplo, T5 se basa en parte en BERT y, por lo tanto, el c贸digo de modelado de T5 puede depender l贸gicamente del c贸digo de modelado de BERT, pero BERT no puede depender l贸gicamente de ninguna manera de T5. Por lo tanto, no ser铆a l贸gicamente correcto refactorizar la funci贸n de atenci贸n de BERT para que tambi茅n funcione con la funci贸n de atenci贸n de T5: alguien que lea la capa de atenci贸n de BERT no deber铆a tener que saber nada sobre T5. Nuevamente, esto aboga por no centralizar componentes como la capa de atenci贸n en m贸dulos a los que todos los modelos puedan acceder.

Por otro lado, el c贸digo de modelado de los modelos sucesores puede depender l贸gicamente de su modelo predecesor. Por ejemplo, el c贸digo de modelado de DeBERTa-v2 depende l贸gicamente en cierta medida del c贸digo de modelado de DeBERTa. La mantenibilidad mejora significativamente al garantizar que el c贸digo de modelado de DeBERTa-v2 se mantenga sincronizado con el de DeBERTa. Arreglar un error en DeBERTa idealmente tambi茅n deber铆a corregir el mismo error en DeBERTa-v2. 驴C贸mo podemos mantener la pol铆tica de un solo archivo de modelo mientras nos aseguramos de que los modelos sucesores se mantengan sincronizados con su modelo predecesor?

Ahora, explicaremos por qu茅 colocamos el asterisco * {}^{\textbf{*}} * despu茅s de “Repeat Yourself”. No copiamos ciegamente todo el c贸digo de modelado existente, aunque parezca as铆. Uno de los principales colaboradores de Transformers, Sylvain Gugger, encontr贸 un mecanismo excelente que respeta tanto la pol铆tica de un solo archivo como los costos de mantenibilidad. Este mecanismo, llamado de forma flexible “el mecanismo de copia”, nos permite marcar componentes l贸gicos, como una funci贸n de capa de atenci贸n, con una declaraci贸n # Copiado de <modelo_predecesor>.<funci贸n>, que obliga al c贸digo marcado a ser id茅ntico a la <funci贸n> del <modelo_predecesor>. Por ejemplo, esta l铆nea de c贸digo de la clase DeBERTa-v2 obliga a que toda la clase sea id茅ntica a la clase DeBERTa, excepto por el prefijo DeBERTav2. De esta manera, el mecanismo de copia mantiene el c贸digo de modelado muy f谩cil de entender y reduce significativamente el mantenimiento. Si se cambia alg煤n c贸digo en una funci贸n de un modelo predecesor al que hace referencia una funci贸n de su modelo sucesor, existen herramientas que corrigen autom谩ticamente la funci贸n del modelo sucesor.

Desventajas

Claramente, tambi茅n existen desventajas en la pol铆tica de un solo archivo, dos de las cuales queremos mencionar r谩pidamente aqu铆.

Uno de los principales objetivos de Transformers es proporcionar una API unificada tanto para inferencia como para entrenamiento para todos los modelos, de modo que un usuario pueda cambiar r谩pidamente entre diferentes modelos en su configuraci贸n. Sin embargo, garantizar una API unificada entre los modelos es mucho m谩s dif铆cil si no se permite que los archivos de modelado utilicen patrones l贸gicos abstractos. Resolvemos este problema ejecutando muchas pruebas (aproximadamente se ejecutan 20,000 pruebas diariamente al momento de escribir esta publicaci贸n del blog) para asegurarnos de que los modelos sigan una API consistente. En este caso, la pol铆tica de un solo archivo nos exige ser muy rigurosos al revisar las adiciones de modelos y pruebas.

En segundo lugar, hay mucha investigaci贸n sobre solo un componente de un modelo de Aprendizaje Autom谩tico. Por ejemplo, los equipos de investigaci贸n investigan nuevas formas de un mecanismo de atenci贸n que se aplicar铆a a todos los modelos pre-entrenados existentes, como se ha hecho en el Rethinking Attention with Performers . 驴C贸mo deber铆amos incorporar dicha investigaci贸n en la biblioteca Transformers? De hecho, es problem谩tico. 驴Deber铆amos cambiar todos los modelos existentes? Esto ir铆a en contra de los puntos 3 y 4 como se mencion贸 anteriormente. 驴Deber铆amos agregar m谩s de 100 nuevos archivos de modelado, cada uno con el prefijo Performer... ? Esto parece absurdo. En tal caso, lamentablemente no hay una buena soluci贸n y optamos por no integrar el art铆culo en Transformers en este caso. Si el art铆culo hubiera tenido mucho m谩s impacto e incluyera puntos de control pre-entrenados s贸lidos, probablemente habr铆amos agregado nuevos archivos de modelado de los modelos m谩s importantes, como modeling_performer_bert.py disponibles.

Conclusi贸n

En resumen, en 馃 Hugging Face estamos convencidos de que la pol铆tica de un solo archivo es la filosof铆a de codificaci贸n correcta para Transformers.

驴Qu茅 opinas? Si llegaste hasta aqu铆, nos interesar铆a mucho escuchar tu opini贸n. Si deseas dejar un comentario, visita el post correspondiente en el foro aqu铆 .