El Office Comprehension Bench: Avanzando más allá del análisis de archivos basado en texto

Analizar un archivo .xlsx sigue siendo una pesadilla. Hemos pasado los últimos años fingiendo que la “ventana de contexto” lo resuelve todo, pero la realidad es que la mayoría de nosotros simplemente estamos metiendo texto aplanado y despojado de su estructura en un prompt, esperando que el modelo pueda reconstruir la lógica original. Cuando despojas una hoja de cálculo compleja de su estructura, no le estás dando al modelo una versión limpia de los datos; le estás dando un fantasma de los datos.

El problema es que la industria ha dependido en demasía de Markdown como traductor universal. Si puede convertirse en una tabla en Markdown, probablemente el LLM pueda manejarlo. Pero los documentos de oficina del mundo real no son tablas limpias. Son pesadillas de XML anidado envueltas en contenedores zip (y todos hemos pasado demasiadas horas haciendo exactamente eso). Un archivo .docx no es un documento; es un directorio de archivos XML fingiendo ser una página.

Aquí es donde entra el Office Comprehension Bench (OCB). En lugar de depender del método de “convertir a texto y rezar”, el OCB analiza cómo los sistemas de LLM manejan los archivos de Word, Excel y PowerPoint en sus formatos nativos reales. Según el artículo https://arxiv.org/abs/2607.01245, el benchmark evalúa la capacidad de comprender realmente la estructura y el contenido de los archivos .docx, .xlsx y .pptx.

¿Por qué seguimos fingiendo que un CSV es lo mismo que una hoja de cálculo de Excel con formato? No lo es. Un CSV es una lista; un libro de trabajo es una base de datos relacional con una capa visual. Cuando un modelo falla al “entender” una hoja de cálculo, rara vez es un fallo de razonamiento. Es un fallo de percepción. Intentar analizar un archivo de Excel complejo usando un divisor de texto genérico es como intentar leer un libro que ha pasado por una trituradora y luego ha sido pegado con cinta en un orden aleatorio. Podrías reconocer las palabras, pero la narrativa se ha perdido.

El OCB introduce dos vías para separar el grano de la paja. Al probar formatos nativos, obliga a los desarrolladores a dejar de ignorar el pipeline de preprocesamiento. La mayoría de los “agentes de IA” de hoy son solo envoltorios alrededor de un analizador muy frágil. Si el analizador tropieza con una celda fusionada en Excel o un cuadro de texto flotante en PowerPoint, el modelo está alucinando basándose en una entrada rota antes incluso de empezar a pensar.

El analizador es el problema.

Esta es la clave: este benchmark no está probando realmente la “inteligencia” del LLM. Está probando la calidad del middleware. Si un modelo obtiene una mala puntuación en el OCB, no significa que el modelo sea tonto; significa que el desarrollador está usando una biblioteca mediocre para alimentarlo de datos. Tenemos la tendencia a culpar al cerebro cuando son los ojos los que fallan.

El enfoque actual de “aplanar todo a texto” es un atajo perezoso que ha llegado a su límite. Ya hemos visto esto antes con el análisis de PDF: todos afirmaban que estaba resuelto hasta que se toparon con un diseño de varias columnas con imágenes incrustadas, y todo se desmoronó. Lo mismo está ocurriendo con los archivos de Office. Estamos tratando formatos altamente estructurados y adyacentes al binario como si fueran simples cadenas de texto.

Si queremos agentes que realmente puedan operar en un entorno corporativo, necesitamos dejar de tratar el formato de archivo como un obstáculo a superar y empezar a tratarlo como una fuente de datos primaria. Esto implica alejarse de la obsesión de “convertir a Markdown” y avanzar hacia un sistema donde el modelo pueda consultar la estructura XML directamente o utilizar una representación especializada que preserve la lógica espacial y relacional.

Me temo que los resultados del OCB se verán inicialmente deprimentes para los grandes laboratorios. Pero eso es bueno. Destaca la enorme brecha entre “chatear con un documento” y la comprensión real.

Para Q4, veremos surgir una biblioteca de preprocesamiento específica y de alto rendimiento —probablemente de un equipo pequeño y especializado— que aumente las puntuaciones del OCB en general al menos un 15 % sin requerir un solo cambio en los pesos del modelo subyacente. Una vez que ocurra, la conversación cambiará de “¿puede el modelo leer esto?” a “¿qué tan rápido puede ejecutarse el analizador?” Por ahora, solo estamos mirando el desastre.