- Si el objetivo estándar de los LLM, la predicción del siguiente token, se cambia por la predicción simultánea de varios tokens futuros, se puede extraer más rendimiento en generación de código y lenguaje natural con los mismos datos y presupuesto de cómputo
- La arquitectura consiste en colocar varios cabezales de salida sobre un cuerpo Transformer compartido; en la inferencia básica solo se usa el cabezal del siguiente token, por lo que funciona como la generación autorregresiva existente
- En modelos de código, un modelo de 13B parámetros resolvió 12% más en HumanEval y 17% más en MBPP que un modelo comparable de siguiente token, y la ganancia es más clara en modelos grandes
- Los cabezales adicionales se aprovechan para decodificación autoespeculativa; un modelo de predicción de 4 tokens mostró hasta 3× de mejora en velocidad de inferencia, y un modelo de predicción de 8 bytes, 6.4×
- En tareas sintéticas fue favorable para induction heads y razonamiento algorítmico, y es posible que reduzca la diferencia entre teacher forcing durante el entrenamiento y la distribución autorregresiva durante la generación
Enfoque de predicción multitoken
- El modelado de lenguaje tradicional minimiza la pérdida de entropía cruzada de un solo token siguiente en cada posición
- La predicción multitoken amplía el objetivo de entrenamiento para predecir de una vez los siguientes n tokens en cada posición
- La arquitectura del modelo se divide en tres partes
- Un cuerpo Transformer compartido genera representaciones latentes del contexto observado
- n cabezales de salida independientes predicen en paralelo cada token futuro
- Una matriz de unembedding compartida calcula las probabilidades finales de tokens
- La forma más simple de inferencia es la predicción autorregresiva común, usando solo el cabezal de predicción del siguiente token; los demás cabezales pueden descartarse
- Los cabezales de salida adicionales pueden usarse para decodificación autoespeculativa (self-speculative decoding), como blockwise parallel decoding o Medusa-like tree attention
Implementación eficiente en memoria
- En una implementación simple, hay que mantener en memoria los logits y gradientes de cada cabezal, lo que aumenta el uso de memoria de GPU
- En los LLM actuales, el tamaño del vocabulario V es mucho mayor que la dimensión d de la representación latente, por lo que el vector de logits se vuelve el cuello de botella de memoria en GPU
- La implementación propuesta ejecuta secuencialmente el forward/backward de cada cabezal de salida después del forward pass del cuerpo compartido
- Los logits y gradientes de un cabezal se liberan antes de pasar al siguiente cabezal
- En el cuerpo solo se mantiene el gradiente acumulado
- Este método reduce el uso pico de memoria de GPU de O(nV + d) a O(V + d), sin aumentar el costo de ejecución
Resultados experimentales en modelos de código
- Los experimentos con datos reales comparan modelos de predicción del siguiente token y modelos de predicción de n tokens con el mismo número de parámetros
- Si se agregan n−1 capas a los cabezales de predicción futura, se eliminan n−1 capas del cuerpo compartido
- Se entrenaron desde cero seis tamaños de modelos, de 300M a 13B, con al menos 91B tokens de código
- En las evaluaciones MBPP y HumanEval, los modelos pequeños podían ser peores que el modelo base, pero a medida que aumentaba la escala la predicción multitoken pasaba al frente
- El modelo de 13B resolvió más problemas que el modelo comparable de siguiente token
- Resolvió 12% más problemas en HumanEval
- Resolvió 17% más problemas en MBPP
- En una ablación donde se entrenó un modelo de 7B con 200B tokens de código, se compararon n=1, 2, 4, 6, 8
- n=4 fue consistentemente el mejor en pass@1, pass@10 y pass@100 de HumanEval y MBPP
- En APPS/Intro, n=6 quedó por delante
- El tamaño óptimo de la ventana puede variar según la distribución de los datos de entrada
Velocidad de inferencia y modelos a nivel de byte
- Se aplicó greedy self-speculative decoding a un modelo de predicción de 4 tokens de 7B, y se midió la velocidad de decodificación en prompts de prueba de código y lenguaje natural no usados en el entrenamiento
- Los resultados muestran una mejora de velocidad de 3.0× en código y 2.7× en texto
- En código, de las 3 propuestas, en promedio 2.5 tokens fueron aceptados
- El modelo de predicción de 8 bytes registró una mejora de 6.4× en velocidad de inferencia
- En los experimentos de tokenización a nivel de byte, se entrenó un transformer byte-level de 7B con 314B bytes, equivalentes a aproximadamente 116B tokens
- El modelo de predicción de 8 bytes resolvió más problemas que la predicción del siguiente byte
- Resolvió 67% más problemas en MBPP pass@1
- Resolvió 20% más problemas en HumanEval pass@1
- La predicción multibyte puede ser una vía para entrenar modelos a nivel de byte de forma más eficiente
Múltiples epochs, ajuste fino y resultados en lenguaje natural
- Incluso al entrenar durante varios epochs con los mismos datos, la predicción multitoken mantiene cierta ventaja frente a la predicción del siguiente token
- MBPP pass@1 fue +2.4%
- HumanEval pass@100 fue +3.2%
- Las demás métricas fueron similares
- En el ajuste fino con CodeContests, un modelo de 7B preentrenado con predicción de 4 tokens superó al modelo base de siguiente token en pass@k en general
- También fue mejor que el modelo base cuando el modelo de predicción de 4 tokens se ajustó fino tal cual con loss n′=4
- En general, el mejor resultado se obtuvo al eliminar los cabezales adicionales y hacer el ajuste fino con un target de next-token
- En lenguaje natural, se entrenaron modelos de 7B con 200B tokens y se evaluaron en 6 benchmarks estándar de NLP
- El modelo de predicción de 2 tokens fue similar al modelo base de siguiente token
- El modelo de predicción de 4 tokens tuvo una caída moderada de rendimiento
- Podría requerirse un tamaño de modelo mayor
- La evaluación de lenguaje natural generativo se realizó dividiéndola en tareas de resumen y matemáticas
- En 8 benchmarks de summarization, los modelos n=2 y n=4 superaron al modelo base de siguiente token según ROUGE-L F1 tanto con entrenamientos de 200B como de 500B tokens
- En la evaluación GSM8K 8-shot, n=2 superó al modelo base con 200B tokens, pero el patrón se invirtió después de 500B tokens, y n=4 fue peor en general
Induction y razonamiento algorítmico observados en tareas sintéticas
- La induction es el patrón en el que, si aparece “AB” en una oración y luego vuelve a aparecer “A”, se predice “B” a continuación
- Se entrenaron modelos de 1M a 1B nonembedding parameters con el dataset children stories, y se midió la induction capability con un test set que incluía nombres aleatorios de 2 tokens
- En modelos pequeños de 30M o menos, la pérdida de predicción de 2 tokens mejoró mucho la formación de induction capability
- A partir de 100M, esta ventaja desapareció
- En la tarea de aritmética polinómica, se entrenaron y evaluaron expresiones que incluían negación unaria, suma, multiplicación y composición en F7[X]/(X5)
- La predicción multitoken elevó la precisión en todo el rango de dificultad de la tarea, y también mejoró de forma importante la generalización out-of-domain, aunque con valores absolutos bajos
- El efecto de cambiar next-token prediction por predicción multitoken fue mayor que el de aumentar el modelo de 30M a 100M
Por qué podría funcionar
- La predicción multitoken puede aliviar el desajuste de distribución entre el entrenamiento con teacher forcing y la generación autorregresiva en tiempo de inferencia
- La predicción del siguiente token puede concentrarse en predicciones de corto alcance e ignorar dependencias de largo alcance
- La predicción multitoken asigna un mayor peso implícito a los tokens fuertemente relacionados con los tokens posteriores
- Esto puede interpretarse como un refuerzo de choice points
- Se considera que la generación de texto útil depende de elegir las decisiones correctas en los choice points
- En el desarrollo desde teoría de la información, la predicción de 2 tokens aparece como una forma que aumenta más la importancia del término de información mutua entre X e Y que la predicción del siguiente token
Limitaciones y costos
- Las tareas pendientes son encontrar cómo elegir automáticamente n en la predicción multitoken, usar loss scale y loss balancing, ajustar el vocabulary size y desarrollar pérdidas de predicción auxiliares que operen en el embedding space
- Para entrenar todos los modelos experimentales se usaron en total cerca de 500K GPU hours
- El hardware fue A100-80GB y H100
- Las emisiones totales estimadas son de unos 50 tCO2eq, y fueron compensadas al 100% mediante el sustainability program de Meta
- El objetivo es mejorar la eficiencia de cómputo y datos de los modelos de lenguaje, pero hay que tener cuidado con los rebound effects y considerar en conjunto los beneficios y riesgos sociales de los LLM
1 comentarios
Opiniones de Hacker News
Están pasando demasiadas cosas en este campo.
Sería bueno tener algún material que explique en orden cronológico, como una visita a una fábrica, cuándo aparecen en el flujo real términos como datos, preentrenamiento, entrenamiento, inferencia, mezcla de expertos, RAG.
La mayoría de las veces no sé dónde encajan los términos en el panorama general, y cuando vi por primera vez el preentrenamiento pensé que era un proceso para tratar los datos antes del entrenamiento, pero en realidad era otro tipo de entrenamiento.
En este campo la relación señal/ruido es muy baja, e incluso la documentación de líderes de la industria como Langchain a veces ya está obsoleta o se contradice entre sí.
Con la fiebre del blockchain pasó algo parecido, así que parece una característica del tren del hype.
Especialmente en cosas como RAG, donde los avances recientes son tan rápidos que durante un tiempo será difícil que exista un libro de referencia que se mantenga actualizado, por lo que cuesta saber por dónde empezar.
Aun así, la documentación de herramientas de alto nivel como LlamaIndex es un buen punto de partida, no tanto porque explique en profundidad los conceptos en sí, sino porque muestra dónde encajan dentro del panorama general.
YouTube, como siempre, está lleno como un océano de no especialistas que intentan atraer clics con la última moda, así que no me parece un buen punto de partida.
Claro, eso pasa con todo, pero en vez de intentar parcharlo, es mejor asumir que en un futuro cercano aparecerá algo mucho mejor que GPT-4 y diseñar un producto diferenciado sobre esa premisa.
Para quienes conocen la decodificación especulativa, esto básicamente es decodificación especulativa propia.
La secuencia de etiquetas predicha se vuelve a introducir en la red de forma autorregresiva, y solo se conservan las predicciones hasta el punto en que coinciden.
Por eso el rendimiento no empeora y solo se vuelve más rápido; aquí llega hasta 3 veces, que es algo normal en la decodificación especulativa.
También podría mejorar gracias al aprendizaje multitarea. La idea de predecir objetivos varios pasos hacia adelante como pérdida auxiliar ya existe desde hace bastante tiempo, y es un buen trabajo.
Si la decodificación especulativa también mejora el desempeño de planificación, será más fácil adoptarla.
La decodificación especulativa no reduce el desempeño del modelo en términos de exactitud o calidad de la salida.
Matemáticamente, la distribución modificada de la que se muestrea es la misma que al hacer decodificación autorregresiva normal, y las diferencias se deben simplemente al azar.
Si con rendimiento te referías a velocidad, la decodificación especulativa sí puede reducir la velocidad, pero no debería hacerlo para la mayoría de las entradas y con una elección adecuada del modelo borrador.
¿Acaso los LLM no consideran, en la predicción de secuencias, la distribución de probabilidad de todas las combinaciones posibles de tokens hasta cierta longitud de salida? Yo pensaba que ya lo hacían.
Si no es así, sorprende que funcionen tan bien como ahora.
Por ejemplo, si las posibilidades y probabilidades de una secuencia de 2 bits son 00: p=0.36, 01: p=0.04, 10: p=0.30, 11: p=0.30, la secuencia de 2 bits más probable es 00.
Pero si solo se predice el siguiente token, 0: p=0.40, 1: p=0.60, entonces el siguiente bit parece ser 1, lo que lleva a un punto de partida no óptimo al predecir el bit posterior.
En secuencias largas, cuanto peor se descomponga la distribución de probabilidad conjunta en distribuciones marginales, más evidente será el error.
Pensándolo más, parece posible hacer un estudio sencillo cambiando la función de pérdida de entropía cruzada para que, en datos de entrenamiento de texto, considere solo el enésimo token futuro, y graficar la relación entre el desempeño del LLM y n.
Si asumimos que los LLM actuales tienen todos n=1, la hipótesis es que se podría evitar en gran medida la explosión de recursos necesaria para predecir la distribución de probabilidad conjunta desde el siguiente token hasta n tokens.
Esto se debe a que predecir directamente el enésimo token requiere implícitamente un mejor modelo de datos. Al menos en textos creados por humanos; no necesariamente aplica a todos los tipos de datos.
Los LLM están diseñados para muestrear texto que siga la distribución de entrenamiento, no para decir cuál es el texto “más probable” que sigue, y de hecho eso no es lo que queremos.
Eso eliminaría la diversidad de las salidas.
En tu ejemplo, si fuera una aplicación de chat, tendría sentido muestrear 0 el 40% de las veces y 1 el 60%.
Para usos como preguntas y respuestas, donde importa la oración más probable, la búsqueda por haz ayuda, como dijeron otros.
También hay que considerar que el modelo puede “mirar hacia adelante” y calcular tokens futuros de antemano, y luego usar eso para predecir el token actual.
De hecho, investigaciones como [1] tratan esto.
Por último, predecir un token a la vez no es un enfoque equivocado, porque es lo que hacen los humanos al hablar. Antes de hablar, hacemos ese tipo de “mirada hacia adelante” en la cabeza.
[1] https://arxiv.org/abs/2404.00859
Según recuerdo, se observan patrones extraños en la salida de los LLM; por ejemplo, muchas veces “an” es menos probable que “a”, por lo que aparecen menos sustantivos que empiezan con vocal de lo esperado.
Es decir, si entrenas un modelo de lenguaje con una distribución determinada y muestreas con temperatura 1, obtienes exactamente la misma distribución.
Si muestreas con baja temperatura o de forma codiciosa, naturalmente obtienes una distribución distinta.
Existen varias estrategias de muestreo de optimización local, como la búsqueda por haz, y también ha habido muchos trabajos de muestreo más globales, como la decodificación especulativa.
¿Los LLM actuales realmente empiezan desde cero con cada token de salida?
Si uno pregunta “¿Qué hace que las bananas sean amarillas?” y responde “Bananas are yellow due to a pigment called bromelain.”, al generar “a” parecería que dentro de la red neuronal ya están activados en cierta medida los conceptos de pigment y bromelain.
Como ya no puede cambiar de idea y continuar con una respuesta como “an optical illusion...”, da la impresión de que ya planeó por adelantado hablar de un pigmento llamado bromelaina.
¿Puede el LLM aprovechar en la siguiente respuesta el trabajo que ya hizo al generar “a”? ¿Puede conservar el estado de la red neuronal para la siguiente respuesta?
“Bananas are yellow due to a” y “Bananas are yellow due to an”
En el primer caso podría responder “Bananas are yellow due to a pigment called bromelain.”, y en el segundo “Bananas are yellow due to an organic compound called bromelain, which is a yellow pigment.”
En cualquiera de los dos casos, aunque GPT elija “a” o “an”, quizá eso no afecte el significado de la respuesta.
Llevándolo al extremo, se podría decir que el LLM se mueve con una heurística tonta según la cual el token siguiente a “due to” es “a” con 55% de probabilidad y “an” con 45%.
La realidad, por supuesto, es más sofisticada, pero esa conducta se puede explicar incluso solo con esa heurística.
Si en los datos de preentrenamiento no se hubieran incluido hechos relacionados con la bromelaina, el LLM realmente podría autocompletar algo como “an optical illusion”.
Recuerdo que GPT-3 cometía errores factuales de ese tipo con bastante frecuencia, aunque sí había descubierto las reglas gramaticales de “a” y “an”.
Como se dijo, no creo que los conceptos tengan que estar realmente activados de antemano, pero en un sentido implícito y emergente sí es posible que ocurra esa preactivación.
Se puede ver la caché KV como una representación del texto hasta el momento y de lo que el modelo piensa sobre él.
Como los modelos de lenguaje se entrenan con la secuencia completa hasta el final, creo que es muy probable que esto ocurra.
La predicción de múltiples tokens fomenta explícitamente este comportamiento, pero solo dentro de la pequeña ventana de n tokens definida.
Por otro lado, también hay mucho trabajo para aumentar el aprovechamiento del cómputo en modelos de lenguaje transformer, como early exit, mezcla de profundidad y nuevas arquitecturas como SSM.
Probablemente tenga un plan conceptual sobre qué podría venir después de “a” u otros candidatos, pero esas predicciones de alto nivel se reconsideran desde cero cuando se genera “a”.
El modelo no solo puede cambiar de idea después de generar cada palabra, sino que debe hacerlo.
Por eso ese “plan” es muy efímero, y se parece más a un rapero de freestyle improvisando que a una persona que piensa con profundidad para elegir su respuesta y su expresión.
El LLM central recibe tokens y devuelve un conjunto ordenado de tokens que podrían venir a continuación, junto con su “confianza”.
Luego normalmente hay una etapa de filtrado y búsqueda, en la que esos tokens ordenados se vuelven a pasar al LLM para obtener más tokens ordenados y construir un árbol de probabilidades corto.
Por ejemplo, si se vuelven a introducir los N tokens principales, cada uno genera un nuevo conjunto de N tokens principales.
Al observar ese árbol, se aplica un filtrado básico para elegir, por ejemplo, la rama con mayor confianza acumulada, la rama con menos tokens repetidos o la rama con menos tokens que coincidan con los tokens de entrada; por lo general se combinan estos criterios y además se agrega una elección aleatoria ponderada por la confianza acumulada.
Por eso, aunque se dé varias veces la misma entrada a un LLM con pesos completamente fijos, pueden salir resultados distintos.
Es decir, respondiendo a la pregunta concreta: el modelo puede “cambiar de idea”. Cada token generado le da al filtro probabilístico de salida la oportunidad de elegir una nueva ruta entre las rutas de salida posibles.
Quizá sea una pregunta muy ingenua, pero si suponemos que se puede crear un vector que codifique el significado de una oración completa, ¿por qué no podríamos entrenar un LLM para que prediga ese vector de oración en vez de una sola palabra?
Entrenar un autoencoder para lenguaje es en realidad muy fácil, porque la cantidad de información contenida en texto es menor que en imágenes/video.
La parte difícil es lograr que el modelo se enfoque en la parte semántica cuando todas las señales vienen de coincidencias exactas en el espacio de tokens.
De ahí surge la idea de Yann LeCun de una arquitectura predictiva de embeddings conjuntos.
Además, con las tareas auxiliares siempre hay un trade-off: dan más señales, pero desplazan el foco.
En nuestro caso, vimos una caída de rendimiento cuando la cantidad de tokens predichos era demasiado grande.
Por lo tanto, los métodos de predicción latente tienen que aclarar qué resulta útil.
El problema es que, después de obtener un vector que representa la respuesta, se necesitaría algo así como otro modelo que convierta esa respuesta de vuelta a una representación en palabras.
Podría ser algo como un modelo de difusión para texto.
Además, la función que tendría que aproximar este modelo de difusión no es inyectiva; en el mejor de los casos es sobreyectiva, y en el peor quizá ni siquiera sea una función en el sentido matemático.
Esto se debe a que para un mismo embedding hay muchas representaciones textuales posibles, y la mayoría de ellas podría no ser válida gramatical o semánticamente.
Por último, un embedding es una representación con pérdida de ciertos datos, así que su inversa perdería muchos matices y contexto.
Los LLM evitan ese problema prediciendo el siguiente token —y ahora los siguientes n tokens— de manera que mantengan coherencia propia con la consulta y los n tokens anteriores; la función que aproximan debería ser, en general, cercana a sobreyectiva.
Hoy, más o menos, trabaja con palabras, así que la IA solo puede usar palabras que conoce, pero puede sintetizar nuevas oraciones con esas palabras.
Si la IA opera a nivel de oraciones, ¿no estaría simplemente repitiendo oraciones que ya vio? Entonces podría sintetizar párrafos nuevos, pero no nuevas oraciones.
En inglés no estoy seguro de que la oración sea una abstracción útil para la IA. Incluso para los humanos apenas lo es.
Si uno mira chats comunes, correos electrónicos o comentarios de YouTube, muchísimas veces no son realmente oraciones o ni siquiera usan puntuación.
No veo que las oraciones correspondan a unidades de significado.
Una oración puede tener dos palabras o abarcar la mitad de un paper en inglés, según quién escriba; puede cruzar seis ideas o contener solo una.
Dónde termina una oración depende, en general, más del estilo del autor que del significado.
Si se divide una oración en tokens, cada token obtiene una representación vectorial.
Si pasamos al nivel de oraciones, el vocabulario de todos los tokens se volvería infinito.
Se podría intentar hacerlo con un modelo más rápido, pero creo que bajaría la calidad de la salida.
Todavía no leí el paper con muchísimo detalle, pero tengo un pequeño comentario de edición.
El apéndice L.2 me pareció satisfactorio, pero la argumentación comprimida de la sección 5.2 me pareció un poco floja.
En particular, no me quedó claro eso de “descartar” H(Y | X) en H(X) + H(Y) = H(X | Y) + 2I(X ; Y) + H(Y | X).
Si se predice un tercer token Z, ¿H(Y | X) no debería estar dentro del contexto implícito C y, por lo tanto, no poder descartarse libremente?
Tampoco me pareció que el apéndice aclarara ese argumento.
Dicho eso, no me confundió al punto de dudar de la idea principal de la afirmación; en general es un problema de forma de expresión.
Entonces, dentro del objetivo de 2 tokens H(X) + H(Y), ¿qué parte es información auxiliar que ayuda al entrenamiento y qué parte es desperdicio?
H(X | Y) e I(X; Y) son útiles para generar el siguiente token, pero H(Y | X) es, por definición, una cantidad de información no relacionada con el siguiente token X.
Por eso se puede decir que “la predicción multitoken intercambia la información útil I(X; Y) de H(Y) por cómputo desperdiciado en H(Y | X)”.
Sin embargo, hay que notar que H(Y | X) es la entropía del siguiente token al predecir Y a partir del prefijo (C, X).
Si el mecanismo de atención puede trasladar al siguiente paso el cómputo que ya hizo para la predicción Y|X, entonces ese cómputo quizá no haya sido realmente desperdicio, sino precómputo.
Leí un texto que decía que los LLM, literalmente, solo tienen una ventana unidimensional hacia el mundo.
Todo no es más que una secuencia de tokens.
Tal vez algo como esta predicción múltiple amplíe esa visión a algo así como 1.1 dimensiones.
En cualquier caso, hay un argumento real de que de alguna manera hay que expandir esa ventana a 2 dimensiones o más.
Por ejemplo, si tuvieras recursos al nivel de FAIR y quisieras entrenar un modelo de programación en Java realmente bueno, tendría sentido entrenarlo para predecir un AST en vez de tokens.
Para predecir comentarios, nombres de identificadores, etc., probablemente seguiría siendo necesaria alguna forma combinada con un LLM general, pero no modelaría el programa en sí como un flujo de tokens.
En cambio, se le podría hacer predecir cosas como “agregar un bloque if” o “agregar un bloque de llamada a método con 4 parámetros”.
También se podría entrenar el modelo para reservar ciertas posiciones de la ventana de contexto para información como los miembros del tipo del cursor actual, e integrar el loop de inferencia con análisis estático estilo IDE/LSP.
Así el modelo podría ver más información de la que está contenida en el texto real.
Creo que la razón por la que hoy no vemos muchos modelos así es que esta investigación es costosa, y la gente de IA está muy centrada en Python, donde Python no se beneficia tanto de los IDE.
En machine learning, la palabra head no se usa de manera consistente y puede confundir.
En este paper aparecen tanto el concepto de multihead attention como el de multiple output heads.
Multihead attention, en la arquitectura transformer, consiste en enfocarse en distintas regiones de la entrada; aquí la analogía biológica se parece más a la cabeza como unidad central de procesamiento.
Un output head es la última capa de una red neuronal, y se pueden tener varias que produzcan salidas distintas a partir de las mismas capas anteriores.
Esta también es una analogía biológica laxa, pero se parece más a una cabeza en un extremo del cuerpo que a una cabeza como CPU.
Ninguno de los dos casos es una analogía con el cabezal de una cinta que lee datos.
Los LLM parecen “pensar” en gran parte alimentando su propia salida de vuelta como entrada, y por eso se ha observado de forma constante que obligar al modelo a pensar en voz alta mejora la calidad del razonamiento.
Es decir, a diferencia de hacer que responda directamente a la pregunta, el razonamiento de cadena de pensamiento hace que vuelva a decir qué se le está pidiendo, exprese una estrategia de alto nivel sobre qué información podría necesitar para responder, diga la información que conoce y explique cómo esa información afectará el razonamiento inicial.
Pero preocupa que hacer que prediga varios tokens siguientes en cada momento pueda tener, en esencia, el efecto contrario.
El prompting de cadena de pensamiento parece mostrar que el modelo es más “inteligente” cuando tiene n + m tokens como entrada que cuando solo tiene n tokens.
Por lo tanto, obtener los siguientes 5 tokens a partir de un n dado podría producir peores resultados que obtener el siguiente token en n, luego el siguiente token en n+1, y así sucesivamente.
El hecho de que este método específico requiera más tokens no es importante.
Si no hay un modelo barato, siempre estaremos sujetos al sesgo del LLM de intentar responder con una estimación en lugar de la respuesta real.
Además, la mayoría de las estrategias de decodificación especulativa producen la misma salida que ejecutar el modelo de forma secuencial.
Si la predicción es incorrecta, ese token se descarta y solo desaparece la mejora de velocidad.
Si los tokens/palabras +1 y +2 se predicen de forma independiente, ¿cómo es que el resultado sigue teniendo sentido gramaticalmente? ¿No se rompería con frecuencia?
No queda claro en el resumen, pero la explicación de la Figura 1 dice: “Durante la inferencia, solo se usa la cabeza de salida del siguiente token. Opcionalmente, las otras tres cabezas pueden usarse para reducir el tiempo de inferencia”.
Si se tomaran todas las predicciones superiores, también podrían usarse las tres cabezas, pero entonces no se podrían usar las estrategias de muestreo comunes.
No sé cuánta gente realmente ejecuta LLM con temperatura 0 fuera de los benchmarks, y si se hace algo mejor que aplicar temperatura, podría ser otra historia.