1 puntos por GN⁺ 2025-06-22 | 1 comentarios | Compartir por WhatsApp
  • Los modelos de lenguaje grandes (LLM) son buenos para encontrar información específica en entradas largas, pero tienen limitaciones para identificar información faltante
  • El nuevo benchmark AbsenceBench evalúa la capacidad de los LLM para detectar información omitida en 3 dominios: secuencias, poesía y PR de GitHub
  • Incluso el modelo más reciente, Claude-3.7-Sonnet, muestra un rendimiento bajo, con apenas 69.6% de F1-score en un contexto de 5K tokens
  • Esto se debe a una limitación del mecanismo de atención (attention) basado en Transformer, que no funciona de forma efectiva sobre los “vacíos” de un documento
  • Este estudio muestra la diferencia intrínseca de dificultad entre detectar información insertada y detectar información omitida en los LLM

Resumen general

  • Los modelos de lenguaje grandes (LLM) han mejorado mucho en encontrar información dentro de documentos largos
  • La prueba existente Needle in a Haystack (NIAH) evalúa la capacidad de encontrar información sorpresiva dentro de entradas extensas, y los LLM muestran ahí un desempeño muy alto
  • Sin embargo, que un LLM pueda encontrar información claramente ausente es un problema distinto
  • Para esto, se propuso el benchmark AbsenceBench, que elimina explícitamente parte del contenido de un documento y luego pide identificar qué información falta

Explicación del benchmark AbsenceBench

  • AbsenceBench evalúa la capacidad del modelo para detectar omisiones en 3 dominios: poesía, secuencias numéricas y Pull Requests (PR) de GitHub
  • Se entregan al LLM al mismo tiempo el documento original y una versión editada en la que se eliminó intencionalmente parte del contenido, y se evalúa si logra identificar qué falta
  • La longitud promedio de contexto es de 5K tokens, por lo que corresponde a un benchmark de “contexto intermedio”, más corto que otras pruebas de contexto largo

Principales problemas en los resultados de evaluación

  • Se evaluaron 14 LLM representativos (por ejemplo, GPT-4, Claude-3.7-Sonnet, Gemini-2.5-flash, etc.), y hasta los modelos más recientes muestran un F1-score bajo, de alrededor de 69.6%
  • Aunque en la prueba NIAH los LLM ya están en un nivel “sobrehumano”, en AbsenceBench el rendimiento cae 56.9%
  • Mientras más largo es el contexto, más cae el rendimiento, especialmente en el dominio de poesía
  • Incluso usando capacidades de inference-time compute, el rendimiento solo aumenta 7.9%, pero se consumen en promedio 3 veces más tokens de chain-of-thought
  • En cambio, mientras menor es la tasa de omisión (omission rate), peor resulta de forma inesperada el rendimiento de los LLM

Causas y análisis profundo

  • El mecanismo de self-attention basado en Transformer tiene dificultades para enfocarse en la “información faltante” (vacíos), porque por la estructura de atención basada en claves es difícil rastrear información que no existe
  • Durante las pruebas, al agregar una cadena placeholder en las partes omitidas, el rendimiento subió en promedio 35.7%

Estructura y ejemplos de AbsenceBench

  • Cada tarea se define de la siguiente manera
    • Se proporcionan el documento original (Dorig) y la versión modificada (Dmodified)
    • Se eliminan p% de los elementos de Dorig para crear Dmodified, y al comparar ambos el LLM debe derivar el conjunto correcto de información faltante (Domit)
  • Ejemplos por dominio:
    • Poesía (Poetry): se seleccionan poemas del Gutenberg Poetry Corpus y se omiten líneas al azar
    • Secuencias numéricas (Numerical Sequences): se omiten números con cierta probabilidad en secuencias generadas aleatoriamente
    • GitHub PRs: se eliminan aleatoriamente algunas líneas modificadas del archivo diff de PR populares de código abierto

Ejemplo de plantilla de evaluación (dominio de poesía)

  • Prompt del sistema: “Un estudiante recitó un poema, pero puede que haya omitido algunas líneas. Encuentra exactamente qué líneas faltan.”
  • Se proporcionan tanto el poema original como la versión recitada, y se pide responder solo con las líneas faltantes exactas

Principales resultados experimentales

  • Se hicieron experimentos variando la longitud de los documentos, la tasa de omisión y otros factores según el dominio
  • En PR de GitHub, poesía y secuencias numéricas, los LLM no logran identificar por completo las partes faltantes
  • Diferencia principal entre NIAH y AbsenceBench: NIAH se enfoca en claves o información existente, mientras que AbsenceBench exige poner atención en “partes que no existen”, por lo que es estructuralmente más difícil

Conclusión e implicaciones

  • AbsenceBench muestra que los LLM siguen siendo débiles ante la pregunta “¿qué falta?”
  • Esto sugiere que, en la práctica, cuando se usan LLM como jueces (por ejemplo, LLM-as-a-Judge), se debe tener cuidado con su confiabilidad
  • Se necesitan nuevos enfoques para superar esta debilidad de diseño en la arquitectura Transformer
  • El dataset y el código de AbsenceBench están disponibles públicamente, y se proponen como punto de partida para investigar la capacidad de detección de omisiones en LLM

Resumen de aportes principales

  • Diseño y publicación de un nuevo benchmark para detectar elementos explícitamente omitidos en documentos de contexto intermedio (5K tokens)
  • Evaluación de 14 LLM modernos, confirmando que detectar información insertada es casi perfecto, pero detectar información omitida sigue siendo difícil
  • Se muestra que incluso técnicas como inference-time compute tienen límites en la mejora real del rendimiento
  • Se confirma el fenómeno de que el rendimiento sube considerablemente cuando se insertan placeholders explícitos en las partes omitidas
  • AbsenceBench se presenta como un caso que expone una limitación fundamental del mecanismo de atención de Transformer

Composición del dataset AbsenceBench

  • Poetry: se corta un poema en documentos de distintas longitudes, entre 100 y 1000 líneas, y se omiten líneas individuales
  • Numerical Sequences: se define aleatoriamente el primer número y luego se organizan los siguientes con distintas reglas (ascendente, descendente, aleatoria, con distintos intervalos), omitiendo algunos
  • GitHub PRs: se seleccionan solo las líneas modificadas de diffs de 10 a 200 líneas en los 20 repositorios más activos, omitiendo algunas para reflejar situaciones reales

Ejemplos reales del benchmark

  • Ejemplo de Poetry
    • Original: “And so, to you, who always were / To me, I give these weedy rhymes / In memory of early times...”
    • Modificado: “And so, to you, who always were / In memory of early times...”
    • Respuesta correcta: “To me, I give these weedy rhymes”
  • Ejemplo de secuencia numérica
    • Original: 117, 121, 125, 129, 133, 137 ...
    • Modificado: 117, 125, 129, 133 ...
    • Respuesta correcta: 121, 137
  • Ejemplo de GitHub PR
    • Se omite una línea específica entre las líneas modificadas del código en el PR

Uso e importancia práctica

  • En la práctica, esto se relaciona directamente con la capacidad de detectar omisiones de cambios en diffs de PR o de información necesaria en documentos
  • Al aplicar LLM a automatización de revisión o verificación, la detección de omisiones requiere medidas complementarias aparte

1 comentarios

 
GN⁺ 2025-06-22
Opiniones en Hacker News
  • Comparte una experiencia haciendo una prueba tras ver una charla de Gerald Sussman: le mostró a Claude una imagen del triángulo de Kanizsa y le hizo una pregunta ambigua para ver si reconocía el triángulo. Como Claude reconoció correctamente la imagen e incluso la resumió, volvió a intentarlo girando la imagen 90 grados. Sin embargo, Claude no pudo reconocerla y hasta identificó mal la cantidad de elementos. La descripción de Claude estaba compuesta por “cuatro círculos parciales tipo Pac-Man, dos triángulos negros delgados o formas de flecha, y un fondo gris claro”

    • Predice que en el futuro esto podría resolverse agregando a los datos de entrenamiento versiones de todas las imágenes rotadas 90 grados

    • Comparte la opinión de que, como el alcance del paper se limita a documentos de texto, el experimento del triángulo de Kanizsa no aplica directamente a esa discusión. Enfatiza que los LLM todavía están poco desarrollados en procesamiento de imágenes. Explica que la mayoría de las funciones de visión se tokenizan mediante un preprocesamiento separado antes de entrar al transformer, y menciona ejemplos de varias etapas de preprocesamiento como OCR, reconocimiento de patrones basado en CNN, imágenes en distintos ángulos y ampliadas

    • Señala una falta de comprensión sobre el cálculo en sí. Comparte contenido de discusiones antiguas de Hacker News relacionadas con ese debate y videos de charlas de Strange Loop enlace, enlace

    • Opina que si se le muestra a un LLM una foto de un perro con 5 patas, no podrá determinar cuántas patas hay

    • Como ejemplo de generalización abstracta, menciona la capacidad humana de reconocer de inmediato un triángulo cuando muchos puntos están dispuestos con esa forma. Dice que en ejemplos simples como ese siente que puede encontrarse la esencia de la inteligencia, y sostiene que el significado del IQ es precisamente poder reconocer incluso una complejidad enorme como un patrón simple. Plantea la perspectiva de que, si esos puntos fueran los vértices de un cubo de 10 dimensiones ligeramente rotado, entonces sería un patrón muy fácil desde un pensamiento en 10 dimensiones

  • Comparte un resumen de la afirmación de los autores del paper de que incluso los modelos recientes muestran bajo desempeño cuando se les presentan simultáneamente el original y la versión modificada para identificar información omitida, y que con el mecanismo de attention de Transformer no se puede prestar atención a tokens que ya fueron eliminados

    • Señala que la clave real está en el texto original, así que si el modelo recibe ambos como entrada podría prestar atención a esa clave. Desde la perspectiva de attention,

      Original: {parte común} {parte eliminada} {parte común final}
      Modified: {parte común} {parte común final}
      

      y

      Original: {parte común} {parte común final}
      Modified: {parte común} {parte agregada} {parte común final}
      

      no serían tan diferentes. Propone un enfoque concreto de que podría implementarse un algoritmo así mediante RASP: en la etapa 1 identificar la posición de los tokens de Original/Modified, en la etapa 2 calcular el valor promedio de los tokens de cada uno y luego obtener la diferencia, y en la etapa 3 determinar que el token más cercano a esa diferencia es la {parte eliminada} o {parte agregada}. Solo quedaría el problema de desde qué lado restar la diferencia. Analiza que, si detecta bien agregados pero no eliminaciones, tal vez el LLM entiende el principio pero fue menos entrenado porque hay pocos datos de eliminaciones

    • Señala que los resultados experimentales de los modelos punteros más recientes (OpenAI opus, o3, Gemini 25 pro, etc.) no están incluidos en el paper

    • Expresa curiosidad sobre si, en el caso de modelos de visión, podría entrenarse mejor con fotos en negativo, rotaciones de imagen y similares. También menciona si habría sido posible probar experimentalmente un formato de preguntas y respuestas para rellenar espacios en blanco, como en madlib

    • Como el desempeño varía entre modelos, ahora que existe este benchmark y hay atención sobre el tema, espera mejoras en el rendimiento a futuro. Parece claro que hay margen de mejora

  • Sostiene que, por la estructura del mecanismo de attention, es natural que no pueda encontrar partes omitidas no clasificadas. Explica que en el problema needle-in-a-haystack sí hay un objetivo específico que buscar, así que attention funciona bien, pero en el caso de una omisión no se sabe qué falta, por lo que hay que comparar todo el contexto y las capas de attention existentes tienen límites. Dice que es parecido a problemas como ordenar listas largas

    • Considera que, en el experimento de búsqueda de omisiones, sí se le está dando al LLM la información necesaria (por ejemplo, tanto el original como el modificado), así que esto sería un problema de ajuste del modelo y no una limitación estructural. Por ejemplo, al buscar omisiones en papers de ML, el cerebro compara entre papers de ML y no contra recuerdos irrelevantes como Star Wars o Top Gear, por lo que cree que funciona eficientemente reduciendo el contexto
  • Dice que todavía no ha leído el paper, pero aun así coincide con la explicación sobre los límites del mecanismo de attention. Como no se sabe qué falta en una omisión, simplemente es difícil detectarla y hace falta comparar el contexto completo

  • Aunque considera válidas algunas críticas a nuevos métodos de benchmark como AbsenceBench, ve de forma positiva que se estén haciendo estos intentos y siente que pueden servir como impulso para avanzar en una mejor dirección

  • Coincide parcialmente con la opinión de los autores de que, a diferencia de los humanos, los LLM ni siquiera se acercan a la ubicación de las omisiones en el contexto, pero se pregunta por qué la arquitectura sería matemáticamente menos adecuada. También siente curiosidad por si el fine-tuning para este tipo de tareas ayudaría. Menciona que el resultado de que cuanto más corta es la entrada y menos omisiones hay, peor resuelve el problema, recuerda a la limitación humana de que también cuesta notar si faltan una o dos palabras. Dice que, aunque los modelos de razonamiento lo hicieron mejor, le sorprende que no llegaran al 100% de precisión. Señala que, como muestra el paper, es un problema que puede resolverse fácilmente con un programa simple. Le resulta interesante que el paper sugiera que todavía hay muchos aspectos de la inteligencia humana que no están definidos formalmente y en los que los LLM podrían ser débiles

  • Buscar un literal string diff sería un caso de sobreasignar complejidad, similar a pedirle a un LLM que haga cálculo aritmético. Observa que quizá convenga más un enfoque de reasoning, como hacer que el LLM enumere el documento completo y lo compare directamente. Lo compara con el fenómeno de que el rendimiento mejora en problemas aritméticos cuando se resuelven paso a paso. Plantea la posibilidad de que los modelos con mejor rendimiento usen arquitectura MoE (Mixture of Experts), y supone que Gemini Flash también podría estar basado en MoE

  • Si se le permite al LLM un enfoque “meta”, podría resolver el problema escribiendo y ejecutando por sí mismo un script en Python para detectar omisiones

    • Pero advierte que podría no distinguir algorítmicamente cuándo debe usar Python, y asume que si se le dieran instrucciones para intentar siempre usar código, se reducirían los errores. Señala que incluso problemas triviales pueden ser difíciles para un LLM y que esa debilidad también podría limitar su capacidad de programación
  • Expresa descontento con el benchmark concreto. En el ejemplo de prompt, el modelo qwq-32b encontró perfectamente el ítem omitido en un experimento de 3 elementos. Cree que también podría resolver fielmente uno de 100 elementos, pero necesitaría muchos más tokens. Sostiene que un límite de 5000 tokens es demasiado poco para un reasoning model, y afirma que si se repitieran más lotes y procesos de simplificación, siempre podría encontrarlo correctamente. Propone una metodología de tokenizar el documento completo y compararlo de forma iterativa para extraer la respuesta correcta. [Comparte el ejemplo completo del prompt]

    • De hecho, hizo una prueba por su cuenta con qwq-32b usando una lista de 26 titulares de HN de la que quitó 3, y demostró experimentalmente que encontró todos correctamente sin consumir 50 mil tokens. Enlace al material del experimento

    • Critica que simplificar un poco el problema reduciéndolo a contar números es una investigación sin sentido, y enfatiza que el verdadero objetivo de este estudio es identificar áreas límite de los LLM que no pueden resolverse con ordenamiento o clasificación

  • Presenta una experiencia real en la que le preguntó a ChatGPT si en Hamlet aparece la frase “utter love”. ChatGPT respondió que había revisado todo el texto de Hamlet y que esa expresión no aparecía. Pero al buscar directamente en el texto original en línea, la encontró de inmediato; cuando se la mostró a ChatGPT, este lo reconoció, se disculpó y hasta volvió a proporcionar el pasaje completo. Comparte la sensación de que “al final, la memoria humana resultó superior al índice de ChatGPT” en esa experiencia

    • Corrige que la respuesta correcta es Act 2, Scene 1, y que quien habla es Polonius

    • Reconoce que, sin un loop de búsqueda o herramientas, la capacidad de recuperación de los LLM es muy pobre; incluso el modelo 4o falla sin búsqueda, y solo con la función de search puede acertar. Extrae como aprendizaje que cada vez cobra más importancia “usar correctamente la herramienta adecuada para cada problema”

  • Los LLM pueden detectar relativamente bien la existencia basándose en input sensorial, pero detectar absence (ausencia) es difícil porque no hay input sensorial. Para detectarla hace falta un modelo del mundo y expectativas muy fuertes. Sugiere que este tipo de tarea neurológica de orden superior podría ser una capacidad única de los organismos y todavía no de los LLM

    • Señala que los LLM pueden tener problemas de consistencia por diseño: una parte depende de simple memorización y otras rutas de matching de patrones más avanzados

    • Indica que, comparado con el pensamiento en tiempo real, el razonamiento de los LLM se basa en una realidad “fija y estática”, así que también hay un límite en el aspecto temporal

    • La detección real de ausencia está estrechamente relacionada con la memoria. Por ejemplo, si un bolígrafo que estaba sobre el escritorio desaparece, el cerebro reconoce la ausencia comparando el input sensorial pasado (el recuerdo de haber visto el bolígrafo) con la situación actual. Sostiene que, por ahora, el thinking es una característica exclusiva de los organismos