LLM como juez se ha convertido en una forma dominante de evaluar qué tan bueno es un modelo para resolver una tarea, ya que funciona sin un conjunto de pruebas y maneja casos donde las respuestas no son únicas. Pero a pesar de lo ampliamente que se utiliza, casi todos los resultados reportados están altamente sesgados. Emocionado de compartir nuestro preprint sobre cómo usar correctamente LLM como juez. 🧵 === Entonces, ¿cómo utilizan las personas realmente LLM como juez? La mayoría de las personas simplemente utilizan el LLM como evaluador y reportan la probabilidad empírica de que el LLM diga que la respuesta parece correcta. Cuando el LLM es perfecto, esto funciona bien y proporciona un estimador no sesgado. Si el LLM no es perfecto, esto falla. Considera un caso donde el LLM evalúa correctamente el 80 por ciento del tiempo. Más específicamente, si la respuesta es correcta, el LLM dice "esto parece correcto" con una probabilidad del 80 por ciento, y el mismo 80 por ciento se aplica cuando la respuesta es realmente incorrecta. En esta situación, no deberías reportar la probabilidad empírica, porque está sesgada. ¿Por qué? Deja que la verdadera probabilidad de que el modelo probado sea correcto sea p. Entonces, la probabilidad empírica de que el LLM diga "correcto" (= q) es q = 0.8p + 0.2(1 - p) = 0.2 + 0.6p Así que la estimación no sesgada debería ser (q - 0.2) / 0.6 Las cosas se vuelven aún más interesantes si el patrón de error es asimétrico o si no conoces estas tasas de error a priori. === Entonces, ¿qué significa esto? Primero, sigue la guía sugerida en nuestro preprint. No hay almuerzo gratis. No puedes evaluar qué tan bueno es tu modelo a menos que tu LLM como juez se sepa que es perfecto en juzgarlo. Dependiendo de qué tan cerca esté de un evaluador perfecto, necesitas un tamaño suficiente de conjunto de pruebas (= conjunto de calibración) para estimar las tasas de error del evaluador, y luego debes corregirlas. En segundo lugar, muy desafortunadamente, muchos hallazgos que hemos visto en artículos durante los últimos años necesitan ser revisados. A menos que dos artículos hayan utilizado el mismo LLM como juez, comparar resultados entre ellos podría haber producido afirmaciones falsas. La mejora podría simplemente provenir de cambiar ligeramente el pipeline de evaluación. Se necesita urgentemente un estudio meta riguroso. === tldr: (1) Casi todas las evaluaciones de LLM-como-juez en los últimos años se reportaron con un estimador sesgado. (2) Es fácil de arreglar, así que espera nuestro preprint completo. (3) Muchos resultados de LLM-como-juez deben tomarse con precaución. ¡El preprint completo llegará en unos días, así que mantente atento! Un trabajo increíble por parte de mis estudiantes y colaboradores. @chungpa_lee @tomzeng200 @jongwonjeong123 y @jysohn1108

Un hilo más serio sobre el bombo de DeepSeek-OCR / la grave mala interpretación que está ocurriendo. 1. Sobre la reducción de tokens mediante la representación de texto en imágenes, investigadores de Cambridge han demostrado anteriormente que es posible una compresión de tokens de 500x (ACL'25, Li, Su y Collier). Sin usar la idea de convertir texto en imágenes. 2. No deberíamos atribuir el éxito de DeepSeek OCR al poder de la representación de imágenes. Al mismo tiempo, no hay nada fundamentalmente incorrecto con la representación de texto con cualquier tokenizador. De hecho, puedes hacer lo opuesto a lo que hizo DeepSeek-OCR, es decir, puedes representar imágenes como una secuencia de tokens de texto (cada uno representando sus valores RGB), y las cosas funcionarán bien. (Consulta el artículo de LIFT.) 3. La única conclusión correcta es que los espacios de incrustación actuales utilizados por los LLM son simplemente enormes y tal vez incluso muy derrochadores. Y lo más importante, aún no estamos aprovechándolos al máximo. 4. Hay mucha evidencia reciente que apoya el mismo mensaje. Por ejemplo, se ha demostrado que si proporcionas demostraciones en contexto de múltiples tareas pero mezcladas en un solo contexto, entonces tu modelo puede resolver múltiples tareas de predicción ICL simultáneamente. (Consulta el artículo de EVERYTHING EVERYWHERE ALL AT ONCE.) 5. tldr; - DeepSeek-OCR es genial - pero puedes lograr una mayor tasa de reducción de tokens simplemente ajustando finamente los LLM en tokens de texto comprimidos - hay más evidencia de que los LLM no están utilizando completamente el gran espacio de incrustación y la enorme cantidad de computación que se utiliza en el tiempo de inferencia - y esa es la única conclusión real que deberías llevarte.

Los DLLMs parecen prometedores... pero la generación paralela no siempre es posible Los LLMs basados en difusión pueden generar muchos tokens en diferentes posiciones a la vez, mientras que la mayoría de los LLMs autorregresivos generan tokens uno por uno. Esto hace que los LLMs basados en difusión sean muy atractivos cuando necesitamos una generación rápida con menos computación. Una gran pregunta es... ¿es posible la generación paralela sin perder precisión en el modelado? La respuesta es no. Hay límites fundamentales sobre cuánto paralelismo podemos lograr. Considera este ejemplo: "Elige una ciudad uniformemente al azar de las siguientes cuatro ciudades: Nueva York, Nueva Orleans, Ciudad de México o Ciudad de Panamá." Entonces, P(Y₁ = Nueva, Y₂ = York) = 1/4, P(Y₁ = Nueva, Y₂ = Orleans) = 1/4, y así sucesivamente. Por lo tanto, P(Y₁ = Nueva) = 1/2, P(Y₂ = Ciudad) = 1/2. Si decides generar Y₁ y Y₂ en paralelo, no importa qué algoritmo de decodificación uses... Estás condenado a muestrear "Nueva Ciudad." Ninguno de los DLLMs de hoy puede generar estas dos palabras correctamente sin renunciar al paralelismo. ----- ¿Por qué es este el caso? De hecho, nunca entrenamos a los LLMs para aprender la distribución conjunta sobre múltiples tokens en una sola iteración hacia adelante. Siempre enseñamos una distribución marginal de un solo token condicionada al contexto. (Lo mismo ocurre con los modelos autorregresivos también.) Por lo tanto, muestrear múltiples tokens a la vez solo es posible cuando esos tokens son mutuamente independientes dado el contexto actual. Y esta limitación del muestreo paralelo puede ser formalizada con precisión. Se puede derivar un límite teórico de la información que es agnóstico a la estrategia de decodificación, y también derivar límites específicos de la estrategia. ----- ¿Entonces, están condenados los DLLMs? ¡No! Tienen un gran potencial para ahorrar computación y tiempo. Pero: (1) necesitamos ser conscientes de sus limitaciones fundamentales, y (2) necesitamos diseñar mejores estrategias de entrenamiento y decodificación. En particular, hay un gran margen de mejora en la decodificación. ¿Por qué? Idealmente, queremos que el modelo controle el grado de paralelismo durante la generación. Al mismo tiempo, debería elegir un subconjunto de futuros tokens que sean casi mutuamente independientes dado el contexto actual. ¿Son buenas las estrategias de decodificación actuales en esto? Difícil de decir. La mayoría de los DLLMs nunca fueron sometidos a pruebas de estrés para ello. ----- Por eso introdujimos un benchmark sintético para poner a prueba los DLLMs. Lo llamamos ParallelBench. La idea es simple: estas son tareas de lenguaje natural, pero cuidadosamente diseñadas para que la generación paralela sea inherentemente difícil. (Piensa en "Nueva Ciudad", pero en tareas más naturales y reales.) ¿Qué encontramos? Probamos DLLMs populares con varios algoritmos de decodificación, y ninguno se acercó al rendimiento "oracle", el rendimiento ideal que obtendrías si el modelo pudiera ajustar óptimamente su paralelismo durante la decodificación. ----- Conclusión: (1) La generación paralela no siempre es posible y consulta nuestro artículo para más detalles :) (2) Si puedes diseñar un DLLM que iguale el rendimiento oracle en nuestro benchmark, bueno, quién sabe, podrías recibir una llamada de alguien en Menlo Park. 😉