- Byte Latent Transformer (BLT) es una arquitectura de LLM a nivel de bytes que aprende con bytes sin procesar, sin tokenización de vocabulario fijo, y aun así alcanza un rendimiento comparable al de los LLM basados en tokenización a gran escala
- La clave es agrupar los bytes en parches de tamaño dinámico en lugar de tratarlos como tokens fijos, asignando más cómputo y capacidad del modelo a las posiciones donde la entropía del siguiente byte es alta
- Meta realizó un estudio de escalado con FLOP controlados de hasta 8B parámetros y 4T bytes de entrenamiento para validar la escalabilidad de los modelos a nivel de bytes
- Cuanto más predecibles son los datos, se eligen parches más largos para mejorar la eficiencia de entrenamiento e inferencia, y también se observan mejoras cualitativas en razonamiento y generalización de cola larga
- Con un costo de inferencia fijo, el enfoque BLT de aumentar conjuntamente el tamaño de los parches y del modelo muestra un mejor escalado que los modelos basados en tokenización
La estructura de LLM a nivel de bytes que propone BLT
- Byte Latent Transformer (BLT) es una arquitectura de LLM a nivel de bytes que usa bytes sin procesar como unidad de entrada en lugar de tokenización basada en vocabulario fijo
- En configuraciones a gran escala, iguala el rendimiento de los LLM basados en tokenización y además muestra mejoras considerables en eficiencia de inferencia y robustez
Los parches dinámicos se convierten en la unidad de cómputo
- BLT codifica los bytes en parches de tamaño dinámico y los usa como la principal unidad de cómputo
- La división en parches se realiza dinámicamente según la entropía del siguiente byte
- En los puntos donde aumenta la complejidad de los datos, se asigna más cómputo y capacidad del modelo
- Cuando los datos son predecibles, se eligen parches más largos para reducir el cómputo
Experimentos de escalado con FLOP controlados
- Meta realizó un estudio de escalado con FLOP controlados sobre modelos a nivel de bytes
- La escala de los experimentos llegó hasta 8B parámetros y 4T bytes de entrenamiento
- Los resultados muestran que los modelos entrenados con bytes sin procesar, sin vocabulario fijo, también pueden escalar
Resultados de eficiencia y generalización
- El enfoque de seleccionar dinámicamente parches más largos mejora tanto la eficiencia de entrenamiento como la eficiencia de inferencia
- En los resultados cualitativos también se observaron mejoras en razonamiento y en generalización de cola larga
- Con un costo de inferencia fijo, BLT muestra un mejor escalado que los modelos basados en tokenización
- Se usa un enfoque que aumenta al mismo tiempo el tamaño de los parches y el tamaño del modelo
Material
- Download the Paper: descargar el artículo de Byte Latent Transformer
1 comentarios
Opiniones de Hacker News
Paper: https://scontent-sjc3-1.xx.fbcdn.net/v/t39.2365-6/470135129_...
El verano en que salió BERT, trabajaba en una startup que hacía clasificación con un modelo CNN basado en caracteres
En el equipo pensamos mucho en formas alternativas de representación, y aunque otros miembros preferían vectores de palabras, a mí no me convencían. En los documentos que manejábamos aparecían con frecuencia palabras fuera del diccionario, esas palabras eran importantes, y descartarlas parecía llevar al fracaso
Como nosotros también estábamos construyendo un “modelo base”, no solo era un problema que esas palabras quedaran fuera del diccionario en el modelo final, sino también que quedaran fuera del diccionario en la etapa del modelo base, donde el costo de entrenamiento era mayor
La clasificación con modelos basados en caracteres funcionaba bastante bien, pero había muchas expectativas puestas en los tokens porque existía la percepción de que guardar un “diccionario” dentro de una red neuronal no era una buena forma de usar redes neuronales
Por otro lado, yo estaba convencido de que enfoques como Word2Vec no tenían futuro, al punto de que dejé un proyecto anterior en el que entrenábamos una RNN para escribir abstracts falsos de reportes de casos de PubMed, con la idea de crear un modelo base para comprensión de texto
Cuando apareció la codificación por pares de bytes (byte-pair encoding), recuerdo haber dicho en una reunión que era el primer método de tokenización de los que habíamos revisado que podía apoyar
Aun así, sinceramente sigo pensando que sería bueno poder trabajar a nivel de caracteres
Los tokens son una solución provisional. En general funcionan bien, pero cuando no funcionan, se nota claramente
[1] https://arxiv.org/abs/2103.06874
En la vida real, la gente crea y usa todos los días palabras que no están en el diccionario para comunicarse. Por ejemplo, “notify” está en el diccionario, pero “notifier”, en el sentido de “medio para avisarle algo a alguien”, no lo está, y el código que envía notificaciones por email se vuelve un “email notifier”. Después vienen cosas como notifiers de mensajes de texto, llamadas de voz o callbacks de call centers
Todas las industrias y organizaciones tienen jerga, palabras personalizadas que no están en el diccionario y abreviaturas poco distintivas
Si no puede manejar la comunicación real y solo puede producir respuestas dentro del diccionario depuradas al estilo de laboratorio, no veo cómo podrían ser útiles las salidas de machine learning
Ojalá esto salga bien. Los tokenizers deberían desaparecer
Es una estructura jerárquica, y es interesante que solo tenga dos niveles. Apilar más niveles parece una dirección natural para trabajos posteriores
Como referencia, dejé este comentario también en otro post relacionado[1], y el autor respondió así
“Soy el autor :), ¡creo que es una buena dirección para explorar! Pero además de que hacerlo todo de una vez agregaría bastante trabajo, hay que tener cuidado con cómo repartir el presupuesto de FLOPs en toda la jerarquía. Con dos niveles, uno (bytes/codificador local) puede hacerse eficiente en FLOPs, y el otro (patches/codificador global) puede hacerse intensivo en FLOPs. También habría que encontrar una forma de agrupar los patches en unidades más grandes. Aun así, ¡hay muchas direcciones que se desprenden de esto!”
[1] https://news.ycombinator.com/item?id=42413430
Para crear patches, se predice con un modelo pequeño la probabilidad del siguiente carácter de la cadena de entrada
Si la cadena de entrada es “Lazy dog jumped over a fence.”, el modelo predice la probabilidad de cada carácter
Por ejemplo, podría estar 100% seguro de que el siguiente carácter es “a”, o podría asignar 10% a “a” y 10% a “b”, y así
Luego agrupa esas estimaciones de caracteres. ¿Cuántos caracteres? Los suficientes para que la incertidumbre total de cada grupo, es decir la entropía, sea parecida
Así se obtiene un patch o “token”
Solo usa la entropía del siguiente byte, y mira si supera un umbral (restricción global) o si es mayor que la entropía del byte anterior por otro umbral (restricción de monotonía aproximada)
Por eso, como se muestra en el Apéndice E, las secuencias largas y repetitivas pueden llevar a patches patológicamente largos
Lo que realmente me da curiosidad es el pequeño modelo CNN a nivel de bytes que usa un contexto de 2 bytes de la figura 3(f), pero no se menciona en ninguna otra parte del paper
Post relacionado reciente:
Meta FAIR comparte nuevas investigaciones, modelos y datasets - https://news.ycombinator.com/item?id=42412360 - diciembre de 2024, 61 comentarios
¿Significa que lo único que enseña al modelo, es decir, la pérdida, es una predicción de probabilidad en el espacio de un solo byte?
Si no estoy entendiendo mal, eso bastaría, y se ve bastante prometedor
Según entiendo, ¿este enfoque no elimina solo la tokenización sino también el sampling?
El sampling puede ser un dolor de cabeza en los LLM, pero también habilita usos interesantes, como imponer una gramática para que el modelo siempre produzca JSON válido, ajustar la temperatura para obtener una distribución más diversa, o usar sampling XTC
¿Cuál sería el equivalente de eso en BLT?
Lo único que se me ocurre es darle al decodificador, como entrada adicional, bytes permitidos/prohibidos y repetir la decodificación hasta obtener una salida válida, aunque quizá haya un enfoque más simple y obvious
Igual que en los modelos basados en BPE, basta con calcular el softmax en la capa de salida solo sobre los bytes permitidos y samplear desde ahí
¿Esto significa que la IA también podría preentrenarse con binarios?
Creemos que el final es que la IA escriba código por nosotros, pero quizá podría tomar el control de una forma mucho más simple
Es interesante cuánto han pasado de moda los enfoques lingüísticos y basados en la experiencia
Los humanos, aunque pueden hacerlo, normalmente no leen carácter por carácter. Tenemos raíces de palabras y entendemos las flexiones. La tokenización no reproduce esa experiencia, y eso se nota especialmente al ver los tokens que aparecen en el vocabulario de los LLM; lo mismo pasa con las codificaciones por caracteres o bytes
Los humanos parseamos las palabras de varias maneras. Podemos entender una oración completa de golpe, leer frases, leer palabra por palabra o descifrar una palabra nueva letra por letra en voz alta
Muy pocos papers afirman explícitamente que un método es bueno porque reproduce la forma en que los humanos realizan una tarea o perciben el mundo
A medida que aumente la dependencia de los LLM, creo que vamos a querer ajustar más los modelos a nuestra experiencia. Entonces los errores que produzcan también serán más fáciles de entender
La frase “a diferencia de la tokenización, BLT no tiene un vocabulario fijo para los patches”, si la entiendo bien, significa que el vocabulario de patches no se conoce antes del entrenamiento
Una vez que el entrenamiento establece el vocabulario de patches, supongo que en inferencia se usa el mismo vocabulario fijo. Si no, no veo cómo podría funcionar
¿Es así?