- Las evaluaciones para encontrar “información presente” en contextos largos han mejorado rápidamente, pero AbsenceBench muestra que la capacidad de detectar información faltante al comparar un original con una versión modificada sigue siendo débil.
- El benchmark se compone de 3 dominios: poesía, secuencias numéricas y diffs de PR de GitHub; usa 4,302 instancias, un contexto promedio de 5K tokens y una tasa base de omisión del 10%.
- Incluso al evaluar 14 LLM, incluidos GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash, o3-mini, Grok-3-mini y DeepSeek-R1, el desempeño de los modelos más recientes es limitado; Claude-3.7-Sonnet alcanza apenas 69.6% de F1-score con un promedio de 5K tokens.
- El F1-score de AbsenceBench cayó en promedio 56.9% frente a NIAH, y los modelos con cómputo en tiempo de inferencia solo mejoraron 7.9% aun usando en promedio 8K thinking tokens adicionales.
- Al insertar placeholders explícitos en las posiciones faltantes, el desempeño mejora en promedio 35.7%, lo que respalda la interpretación de que a la attention de Transformer le cuesta enfocarse en los “huecos” dentro de un documento.
La pregunta que plantea AbsenceBench
- Los LLM recientes muestran alto desempeño en tareas de contexto largo, y en la prueba Needle-in-a-Haystack (NIAH) demuestran su capacidad para encontrar información pequeña y distintiva dentro de entradas muy largas.
- AbsenceBench evalúa el problema en la dirección opuesta.
- En lugar de encontrar información contenida en la entrada, deben encontrar información claramente faltante.
- Al modelo se le entregan juntos el documento original y un documento modificado al que se le eliminaron algunos elementos.
- La salida debe ser el conjunto exacto de elementos faltantes en el documento modificado.
- La tarea tiene reglas simples y respuestas claras, pero incluso los modelos cerrados de última generación muestran bajo desempeño.
Definición de la tarea y composición de los datos
- AbsenceBench tiene el formato de generación controlada: se eliminan intencionalmente algunos elementos
Domitdel documento originalDorigpara crear el documento modificadoDmodified, y el modelo debe identificar los elementos eliminados. - “document length” se refiere al número de tokens del documento original, y “context length” al número total de tokens de la entrada del modelo.
- El benchmark completo consta de 4,302 instancias, con una longitud promedio de contexto de 5K tokens.
- El repositorio de código está disponible en harvey-fin/absence-bench.
- Para medir la longitud en tokens se usa GPT-4 Tokenizer.
Poesía, secuencias numéricas y diffs de PR de GitHub
-
Poesía (Poetry)
- Usa poemas del Gutenberg Poetry Corpus.
- La omisión se aplica línea por línea, y el separador de líneas es el carácter newline.
- Para obtener diversidad en la longitud de los documentos, recortan cada poema de modo que el número de líneas se distribuya uniformemente entre 100 y 1000.
-
Secuencias numéricas
- Generan un total de 1,200 secuencias numéricas sintéticas.
- Los números se ordenan de una de tres formas: ascendente, descendente o aleatoria.
- El step size entre números consecutivos es uno de 1, 4, 7 o 13.
- El primer número se elige aleatoriamente entre 0 y 9999.
-
Diff de PR de GitHub
- Usan datos públicos de GitHub y la API de GitHub para recopilar PR de los 20 repositorios con mayor cantidad de PR.
- Conservan solo PR cuyos diffs tienen entre 10 y 200 líneas actualizadas.
- Entre las líneas actualizadas que comienzan con
+o-, solo toman como objetivos de omisión las líneas únicas dentro de cada diff de PR. - Como un LLM que resuelve y verifica merge conflicts debería poder detectar omisiones en diffs de archivos, esto se conecta con casos de uso reales.
Límites revelados al evaluar 14 LLM
- En total se evaluaron 14 LLM.
- Incluyen modelos recientes como GPT-4, Claude-3.7-Sonnet y Gemini-2.5-flash.
- Incluyen modelos con cómputo en tiempo de inferencia como o3-mini, Grok-3-mini y DeepSeek-R1.
- Claude-3.7-Sonnet y Gemini-2.5-flash se evaluaron separando el uso o no de cómputo en tiempo de inferencia.
- Incluso los modelos más recientes no logran un desempeño estable en AbsenceBench.
- Claude-3.7-Sonnet registró 69.6% de F1-score con un contexto promedio de 5K tokens.
- A medida que aumenta la longitud del contexto, la tarea se vuelve más difícil, con una diferencia especialmente marcada en el dominio de poesía.
- El cómputo en tiempo de inferencia solo aporta una mejora promedio de 7.9% en el desempeño.
- En cambio, genera en promedio 8K thinking tokens adicionales.
- Esto equivale a casi 3 veces la longitud promedio del documento.
- También se observa que, cuanto menor es la tasa de omisión, peor tiende a ser el desempeño de los modelos.
Un patrón de falla distinto al de NIAH
- AbsenceBench resulta ser una tarea mucho más difícil para los LLM que NIAH.
- Al comparar tres LLM en la configuración de AbsenceBench y en la configuración original de NIAH, el F1-score cae en promedio 56.9%.
- La attention de Transformer podría tener dificultades para manejar huecos dentro de un documento.
- Esto se debe a que una omisión no corresponde a una key específica hacia la cual pueda dirigirse la attention.
- En un experimento que inserta una cadena de placeholder en la ubicación faltante, el desempeño mejora en promedio 35.7%.
- Un ejemplo es insertar un token como
<missing line>en la posición de la línea faltante.
- Un ejemplo es insertar un token como
- Este resultado muestra que los LLM pueden ser más vulnerables al identificar situaciones en las que la información está “faltante” que aquellas en las que la información está “insertada”.
- En usos como LLM-as-a-Judge, donde es necesario detectar correctamente información omitida, esta limitación puede traducirse en un riesgo práctico.
1 comentarios
Comentarios de Hacker News
Después de ver una charla de Gerald Sussman, le pasé a Claude una imagen del triángulo de Kanizsa y le pregunté de forma bastante ambigua si podía “ver” el triángulo inferido; reconoció la imagen y enseguida dio un resumen
Entonces roté la imagen 90 grados e intenté de nuevo en una conversación nueva, pero no reconoció la imagen y también se equivocó en la cantidad de elementos
Sobre la imagen rotada, Claude dijo que había 4 figuras negras tipo Pac-Man en las cuatro esquinas, 1 triángulo delgado apuntando hacia arriba y 1 triángulo delgado apuntando hacia la derecha, sobre un fondo gris claro
Octubre de 2011, 30 comentarios
https://news.ycombinator.com/item?id=3163473
Video de Strange Loop:
Julio de 2011, 36 comentarios
https://news.ycombinator.com/item?id=2820118
Ya es bien sabido que a los LLM todavía les falta mucho para procesar imágenes como procesan texto o audio
Casi no hay modelos multimodales que tomen directamente los píxeles de una imagen y rindan bien. La mayoría de las capacidades visuales son más bien hacks o añadidos de ingeniería, y la imagen pasa por varias etapas de procesamiento antes de que la salida de cada procesador entre como tokens al transformer. Puede ocurrir dentro de una sola red, pero también intervienen redes que no son transformers. Como ejemplos de preprocesamiento puede haber OCR, CNN con varias escalas/ángulos/recortes (reconocedores de patrones 2D), entre otras cosas
Me parece que este ejemplo simple revela algo central de la inteligencia. Reconocemos el triángulo porque la gran complejidad de 1,000 puntos encaja en una forma geométrica de baja entropía simple
Creo que lo que llamamos IQ se parece más al límite superior de la complejidad de patrones que uno puede detectar. Por ejemplo, esos 1,000 puntos podrían ser en realidad los vértices de un hipercubo de 10 dimensiones ligeramente rotado, y para una mente de 10 dimensiones podría ser un patrón fácil de ver
Interesante. Incluso cuando se les da a los modelos más recientes tanto el contexto original como el contexto editado, su desempeño para identificar qué información fue eliminada del contexto sigue siendo relativamente bajo
Los autores creen que el bajo rendimiento se debe a que el mecanismo de atención del transformer no puede prestar atención a los tokens eliminados porque no tienen key
Desde la perspectiva del mecanismo de atención, no hay una gran diferencia entre
Original: {prefijo común} {parte eliminada} {sufijo común} Modified: {prefijo común} {sufijo común}yOriginal: {prefijo común} {sufijo común} Modified: {prefijo común} {parte añadida} {sufijo común}Con RASP (un lenguaje para programar transformers manualmente) parece posible construir más o menos este algoritmo. En la capa 1, se presta atención a los tokens
"Original:"y"Modified:"para determinar si el token actual pertenece al original o al modificado. En la capa 2, una cabeza presta atención de manera uniforme a todos los tokens del original y promedia sus valores, mientras otra cabeza promedia todos los tokens modificados, y luego se calcula la diferencia entre ambos promedios. En la capa 3, se presta atención a los tokens parecidos a esa diferencia, y eso se convierte en la{parte eliminada}o la{parte añadida}La única parte que depende del orden es si la diferencia se calcula como
promedio del original - promedio del modificadoo al revésSi el modelo detecta adiciones pero no eliminaciones, eso podría significar que en principio tiene capacidad para aprender este algoritmo o uno parecido, pero que no hubo suficientes datos de tipo eliminación como para que se desarrollara el circuito necesario
Muy interesante. 1) Los autores dicen que, como el hueco no es un token, el mecanismo de atención quizá no pueda atender a la posición del hueco, pero yo esperaba que un buen transformer tipo LLM al menos pudiera acercarse bastante a la zona alrededor del hueco
No entiendo bien, en términos matemáticos, por qué esta estructura sería menos adecuada. Parece que sí debería poder prestar atención a la región donde podría haber un hueco. También me pregunto si afinarlo con este tipo de tareas ayudaría
2) Mientras más corta era la entrada y menos omisiones había, más difícil resultaba. Incluso para una persona, detectar que falta una sola palabra es más difícil, y una línea omitida es más difícil que diez líneas omitidas, así que no es completamente sorprendente. Aun así, es interesante que los LLM tengan este problema
3) Los modelos de razonamiento lo hacen mejor porque pueden ir escribiendo el documento mientras resuelven. Aun así, que la precisión no sea del 100% sigue siendo muy sorprendente. Debería ser una tarea trivial y, como dice el paper, se puede resolver con un programa simple. Incluso parece posible que un agente como ChatGPT lea este paper durante el entrenamiento y aprenda que, para resolver problemas de este tipo, debería escribir y ejecutar Python
Lo más interesante es cuáles son las otras facetas de la inteligencia que todavía no hemos identificado explícitamente, y si los LLM y la IA actual son muy débiles en esas áreas. Este paper sugiere que podría haber muchas, y en general parece un momento bastante interesante para la gente que crea benchmarks
Para ser justos, encontrar literalmente diferencias de cadenas lo pondría en la misma categoría que hacer que un LLM haga aritmética mecánica
El mecanismo de atención piensa de una forma excesivamente compleja para una tarea tan tonta. En casos así, en vez de hacer una predicción del siguiente token de alto nivel, debería simplificar a propósito, enfocarse y procesarlo con disciplina
Realmente ayudaría pedirle al LLM que enumere y compare el documento completo. Es una forma de dividirlo en pasos, similar a cómo los LLM suelen rendir mejor al descomponer problemas de aritmética o álgebra en pasos pequeños
Supongo que los modelos con buen rendimiento probablemente sean modelos MoE. Puede que haya uno o dos expertos especialmente adecuados para tareas que requieren concentración más que intuición. No conozco nada de Gemini Flash, pero me da la impresión de que debe ser un modelo MoE
Aún no he leído el paper, pero desde la perspectiva del mecanismo de atención estructural, que no pueda detectar ausencias no clasificadas es algo totalmente esperable. Aun así, creo que puede resolverse con pensamiento estructurado
En el problema de buscar una aguja, basta con poner atención en lo que estás buscando, y la atención hace eso bastante bien
Al buscar una ausencia, esa ausencia puede ser cualquier cosa, así que solo puedes inferirla comparando un contexto completo con otro contexto completo. A las capas de atención les cuesta hacer eso correctamente
Esto se parece al problema de “clasificar un conjunto largo de elementos”. Sin algún proceso metacognitivo, simplemente no se puede
Por ejemplo, algo como “aquí hay un poema, y hay una versión del mismo poema en la que podrían faltar algunas líneas. ¿Falta alguna línea?”
En mi opinión, esto se parece más a un problema de ajuste que a una debilidad intrínseca de los LLM
Si me pidieran encontrar una omisión en un paper de machine learning, mi cerebro la compararía con otros papers de machine learning; no necesita compararla con Star Wars, Top Gear, la historia griega, la cerámica y miles de otros contextos que conozco
Las críticas al enfoque de AbsenceBench son válidas, pero me alegra muchísimo el simple hecho de que estén haciendo un benchmark de algo así. Sin duda es un impulso en la dirección correcta
Al detectar presencia, el cerebro real recibe entrada sensorial, la compara con expectativas y mantiene la calma o registra sorpresa, y a veces genera predicciones para guiar al organismo
Al detectar ausencia, por definición el cerebro no puede depender de la entrada sensorial. Para sorprenderse en ausencia de evidencia sensorial, necesita un modelo del mundo lo bastante fuerte como para sorprenderse de que una expectativa no se cumplió incluso sin señales sensoriales
Detectar ausencia parece ser una tarea neurológica de un orden estrictamente superior al procesamiento de entrada sensorial
Si los LLM no pueden realizar esta tarea neurológica de orden superior, ¿no sería esta una capacidad que por ahora solo tienen los seres vivos?
Lo que describes está relacionado con la memoria. La memoria consiste en almacenar y reproducir entrada sensorial cuando no hay entrada sensorial. Así que el cerebro reproduce entrada sensorial pasada y la contrasta con la entrada sensorial actual
Por ejemplo, si dejas una pluma sobre la mesa, te vas y al volver ya no está, el cerebro compara el recuerdo almacenado de la pluma sobre la mesa con lo que ve ahora
Parece que los LLM son débiles con las diferencias de cadenas. Como comentario al margen, me pregunto si existe algún recurso tipo repositorio de GitHub que recopile este tipo de hallazgos sobre lo que los LLM hacen bien y mal
Es un mal benchmark
Probé su prompt [1] con 3 elementos numerados y qwq-32b lo resolvió sin ningún problema. También parece capaz de resolver 100 elementos con 100% de precisión, pero probablemente necesitaría un millón de tokens. Tal vez incluso más de 10 millones
Un límite de 5,000 tokens para un modelo de razonamiento es demasiado poco. Hay que darle mucho tiempo de cómputo para la prueba, y ni siquiera 10 veces 5,000 tokens bastaría
Si los autores hablan de entradas largas, entonces para 100 páginas habría que darle mil millones de tokens
La forma correcta de implementarlo es con procesamiento por lotes. Buscar los primeros 5 elementos numerados en el texto de entrada omitido y, si se encuentran, simplificar tanto los elementos de entrada como los omitidos y luego seguir avanzando de nuevo
Según el tamaño de la entrada siempre hará falta una cantidad considerable de tokens, pero la simplificación ayudaría a retroceder correctamente sin perder por completo el contexto
[1] Estás ayudando a un estudiante a practicar la memorización de un poema. El estudiante recita el poema, pero puede haber omitido algunas líneas. Tu tarea es identificar exactamente qué líneas faltaron en la recitación. Enumera solo las líneas faltantes y no escribas nada más. Mensaje del usuario: Aquí está el poema original completo: 1)Quisella's lashes fluttered panic-morse. 2)The Moisture Vampires leeches that sucked humidity. 3)Lysandra's nostrils flared precisely one degree. Ahora aquí está mi recitación, en la que quizá falten líneas: Quisella's lashes fluttered panic-morse. Lysandra's nostrils flared precisely one degree. ¿Qué líneas omití? Enumera solo las líneas faltantes y no escribas nada más
[1] https://gist.github.com/pramatias/fee1391ad08c7b965f435f3af1...
Me pregunto cómo se aplicaría esto a los modelos visuales. En unas cuantas pruebas con una sola imagen, parecían hacerlo bien
En algunos ejemplos de juguete, Claude y Gemini parecían bastante buenos para encontrar diferencias. Imagen de ejemplo: https://www.pinterest.com/pin/127578601938412480/
Si se voltea la imagen, parecían tener más dificultad y también más probabilidad de encontrar menos diferencias o alucinar alguna