FinSheet-Bench: From Simple Lookups to Complex Reasoning, Where LLMs Break on Financial Spreadsheets

El artículo presenta FinSheet-Bench, un nuevo benchmark de datos financieros sintéticos que revela que, aunque los modelos de lenguaje actuales logran una precisión moderada en tareas simples, sus altos índices de error en hojas de cálculo complejas e industriales impiden su uso autónomo en aplicaciones financieras profesionales, lo que sugiere la necesidad de enfoques arquitectónicos que separen la comprensión del documento del cálculo determinista.

Lo esencial

Imagina que tienes un bibliotecario extremadamente inteligente (una Inteligencia Artificial) al que le pides que lea miles de libros de contabilidad antiguos, llenos de números, tablas y notas al pie, para responder preguntas sobre inversiones.

Este documento, llamado FinSheet-Bench, es como un examen de la vida real que le pusimos a los mejores bibliotecarios del mundo (modelos de IA como GPT-5, Gemini y Claude) para ver si son lo suficientemente buenos para trabajar en una oficina de finanzas.

Aquí tienes la historia de lo que descubrimos, explicada de forma sencilla:

1. El Problema: La "Biblioteca del Caos"

En el mundo de las inversiones privadas (como fondos de capital privado), la información no está en libros ordenados. Está en hojas de cálculo de Excel que parecen un laberinto.

• Tienen filas y columnas mezcladas.
• Hay celdas unidas, colores que significan cosas, y títulos que saltan de un lado a otro.
• Un error de un solo número puede costar millones de dólares.

El problema es que, aunque estas IAs son geniales escribiendo poemas o resumiendo textos, se pierden cuando intentan leer estos "laberintos" de números.

2. El Experimento: Creando un "Gimnasio" Falso

Como nadie quiere compartir sus libros de contabilidad reales (son secretos comerciales), los autores crearon FinSheet-Bench.

• La analogía: Imagina que quieres entrenar a un atleta para correr en un estadio lleno de obstáculos. Como no puedes usar el estadio real, construyes una réplica exacta con materiales sintéticos.
• Usaron la estructura de hojas de cálculo reales (el diseño, las filas, los encabezados), pero cambiaron todos los nombres y números por datos inventados.
• Luego, le dieron a 10 modelos de IA diferentes una serie de preguntas, desde lo fácil ("¿Cuántos fondos hay?") hasta lo imposible ("Calcula la mediana de la deuda neta de todos los fondos y ordénalos").

3. Los Resultados: ¡Casi, pero no del todo!

Los resultados fueron una mezcla de esperanza y realidad dura:

• El "Campeón" (Gemini 3.1 Pro): Fue el mejor, acertando el 82.4% de las preguntas.

  • La analogía: Imagina que le pides a un estudiante que resuelva 6 problemas de matemáticas. El estudiante acierta 5, pero falla 1.
  • El problema: En finanzas, fallar 1 de cada 6 preguntas es demasiado peligroso. Si estás gestionando millones, un error así no es aceptable sin que un humano lo revise.

• La caída en picada:

  • Si la pregunta era simple (buscar un número), la IA acertaba casi siempre (90%+).
  • Pero si la pregunta requería pensar y calcular (sumar, promediar, ordenar listas), la puntuación se desplomó. En las tareas más difíciles, la precisión bajó a menos del 20%.
  • La analogía: Es como si el estudiante pudiera copiar la respuesta de un libro perfectamente, pero si le pides que haga una operación matemática con esos números, se confunde y da un resultado aleatorio.

• El tamaño importa: Cuanto más grande y desordenada era la hoja de cálculo, peor lo hacían. En los archivos más grandes, la IA se comportaba casi como si estuviera adivinando.

4. ¿Por qué fallan? (El "Entrenamiento" vs. La "Realidad")

El paper explica que la culpa no es solo de la IA, sino de cómo le damos la información:

• El problema del "Traductor": Las hojas de cálculo son bidimensionales (tienen filas y columnas, como una cuadrícula). Pero las IAs leen texto en una sola línea, de izquierda a derecha.
  • La analogía: Es como si le dieras a alguien un mapa de metro (con líneas cruzadas) y le pidieras que lo lea como si fuera una lista de compras en una sola línea. Se pierde la conexión entre "Estación A" y "Línea Roja".
• Falta de "Calculadora": Las IAs son muy buenas con las palabras, pero malas con los números exactos. No tienen una calculadora integrada; intentan "adivinar" el resultado matemático basándose en patrones de texto, lo cual es peligroso en finanzas.

5. La Solución Propuesta: No confíes en el "Todo en Uno"

El paper concluye que ninguna IA actual puede trabajar sola en este tipo de tareas sin supervisión humana.

• La idea brillante: En lugar de pedirle a la IA que lea todo el documento y haga los cálculos (lo cual es donde falla), deberíamos dividirlo en dos pasos:
  1. El "Ojo" (IA): Usa la IA solo para encontrar los datos (ej: "¿Dónde está el número de la empresa X?"). La IA es excelente buscando.
  2. El "Cerebro Lógico" (Código): Una vez que la IA encuentra los números, pásalos a un programa de computadora normal (como Excel o Python) para que haga las sumas, promedios y cálculos.
  • La analogía: No le pidas al bibliotecario que haga las matemáticas. Pídele que saque los libros de la estantería (eso lo hace genial) y luego deja que una calculadora haga la suma.

En Resumen

Este estudio nos dice que, aunque la Inteligencia Artificial avanza a toda velocidad y ya puede leer documentos financieros bastante bien, todavía no es lo suficientemente precisa para tomar decisiones de inversión por sí sola.

Es como tener un copiloto muy inteligente que puede leer el mapa, pero que a veces se equivoca al sumar la gasolina. Por ahora, necesitamos un humano al volante para verificar los números. El futuro no es una IA que lo hace todo, sino una IA que trabaja en equipo con herramientas de cálculo tradicionales.

Resumen técnico

Resumen Técnico: FinSheet-Bench

1. El Problema: La Brecha en la Extracción de Datos Financieros

Aunque los Modelos de Lenguaje Grande (LLM) han demostrado un rendimiento excepcional en tareas basadas en texto (análisis de contratos legales, resúmenes de diligencia debida), existe una brecha crítica en su capacidad para extraer y razonar sobre datos tabulares estructurados provenientes de hojas de cálculo financieras complejas.

• El Cuello de Botella: En la inversión alternativa (Private Equity, Venture Capital), la evaluación de carteras depende de hojas de cálculo de Excel no estandarizadas. Estas contienen estructuras complejas, celdas combinadas, encabezados multinivel, fórmulas incrustadas y formatos visuales que transmiten significado semántico.
• La Tolerancia al Error: En finanzas profesionales, la precisión es crítica. Un error del 5% en una métrica de valoración puede alterar decisiones de inversión de millones de dólares. La industria requiere una precisión superior al 97% para flujos de trabajo automatizados, un umbral que los modelos actuales no alcanzan.
• Falta de Datos de Referencia: El avance se ha visto frenado por la falta de conjuntos de datos públicos y reales. Las salas de datos de fondos de Private Equity son confidenciales, lo que impide crear benchmarks públicos a partir de datos reales. Los benchmarks existentes (como TabFact o FinQA) utilizan tablas simplificadas que no capturan la complejidad de los modelos financieros reales.

2. Metodología: FinSheet-Bench

Para abordar esta carencia, los autores introducen FinSheet-Bench, un nuevo benchmark diseñado específicamente para evaluar el rendimiento de los LLMs en hojas de cálculo financieras.

2.1 Construcción del Dataset

• Origen: Los datos se derivan de hojas de cálculo reales enviadas por Socios Generales (GPs) a oficinas familiares, pero no son datos reales anonimizados.
• Generación Sintética: Se utilizaron 8 plantillas estructurales reales. Los valores de las celdas se regeneraron completamente mediante un proceso de transformación:
  • Identidad: Nombres de empresas y personas reemplazados por ficticios.
  • Valores Numéricos: Se aplicaron factores de escala aleatorios ($A, B \in [0.5, 2.0]$) y factores de perturbación ($k \in [0.95, 1.05]$) para preservar las relaciones estadísticas sin revelar los datos originales.
  • Estructura: Se generaron 24 archivos en total (Versiones A, B y C). Las versiones B y C introducen modificaciones estructurales (eliminación de filas, fusión de columnas, cambios en separadores) para probar la robustez del modelo.
• Verdad Terrenal (Ground Truth): Las respuestas correctas se calcularon mediante funciones Python deterministas sobre tablas estandarizadas extraídas manualmente, asegurando precisión numérica total.

2.2 Configuración Experimental

• Modelos Evaluados: Se probaron 10 configuraciones de modelos de tres proveedores principales (OpenAI, Google, Anthropic), incluyendo las versiones más recientes (GPT-5.2, Gemini 3.1 Pro, Claude Opus 4.6) y sus variantes con razonamiento activado.
• Formato de Entrada: Las hojas de cálculo se convirtieron a texto serializado (CSV). Esta decisión metodológica refleja el uso industrial actual (pipelines RAG), aunque implica la pérdida de información visual (colores, bordes, celdas combinadas).
• Tipos de Preguntas: Se definieron 16 plantillas de preguntas en 7 categorías de complejidad creciente:
  • Baja: Búsqueda simple (ej. "¿Cuántos fondos hay?").
  • Media: Filtrado, conteo, extracción de listas.
  • Alta: Agregación, ordenamiento, cálculos simples.
  • Muy Alta: Operaciones estadísticas complejas (mediana, percentiles) que requieren pasos intermedios.
• Protocolo de Evaluación: Se utilizó un sistema de verificación en cascada de tres niveles:
  1. Coincidencia Exacta: Regex estricto y normalización.
  2. Coincidencia Difusa: Tolerancia del 5% en números y similitud de secuencias.
  3. Adjudicación por LLM: Un modelo LLM (GPT-4o-mini/Gemini Flash) actúa como juez para respuestas ambiguas o complejas, resolviendo el 48% de los casos.

3. Resultados Clave

3.1 Rendimiento General

• Ningún modelo es listo para producción: Ninguna configuración de LLM alcanzó una tasa de error lo suficientemente baja para un uso no supervisado en finanzas.
• El mejor modelo: Gemini 3.1 Pro obtuvo la mayor precisión con 82.4% (aproximadamente 1 error cada 6 preguntas). Le siguen GPT-5.2 con razonamiento (80.4%) y Claude Opus 4.6 con pensamiento (80.2%).
• Degradación por complejidad: El rendimiento cae drásticamente en archivos grandes y complejos. En el archivo más grande (152 empresas, 8 fondos), la precisión promedio cayó a 48.6%, frente al 86.2% en los archivos más sencillos.

3.2 Análisis por Categoría de Tarea

Existe una brecha significativa entre la recuperación de información y el razonamiento numérico:

• Búsqueda Simple: Alta precisión (~89-94% para los mejores modelos).
• Agregación y Cálculo: Precisión moderada (~53-76%).
• Ordenamiento y Conteo: Dificultad notable. El ordenamiento (Sorting) cayó al 37.5% en todos los modelos, y el conteo (Counting) al 41.7%.
• Agregación Compleja: Precisión muy baja (~19.6% en todos los modelos, subiendo a 33.3% solo con los top 3).

3.3 Impacto del Razonamiento

Activar el "razonamiento" (Chain-of-Thought o modos de pensamiento extendido) mejoró significativamente la precisión:

• GPT-5.2: +22.8 puntos porcentuales (de 57.7% a 80.4%).
• Claude Opus 4.6: +13.6 puntos porcentuales.
  Sin embargo, esto conlleva un costo mayor en tokens de salida (hasta 11x más) y tiempo de respuesta.

3.4 Progreso de Generación

En dos años, la precisión ha mejorado de ~25% (GPT-3.5) a ~82%, lo que indica un progreso rápido, pero aún insuficiente para eliminar la necesidad de revisión humana en entornos críticos.

4. Contribuciones Clave

1. FinSheet-Bench: El primer benchmark público diseñado específicamente para evaluar LLMs en hojas de cálculo de Private Equity, superando las limitaciones de los benchmarks de tablas simplificadas.
2. Evidencia de Limitaciones Arquitectónicas: Demuestra que el fallo de los LLMs no es solo por falta de conocimiento, sino por una incapacidad estructural para realizar razonamiento numérico multietapa sobre datos tabulares, independientemente del proveedor.
3. Análisis de Serialización: Identifica que la conversión de Excel a texto plano (pérdida de estructura 2D, celdas combinadas y formato visual) es un factor contribuyente importante, aunque no el único, en los errores de identificación de filas y columnas.
4. Propuesta de Arquitectura Híbrida: Sugiere que la solución no es esperar a modelos más grandes, sino cambiar la arquitectura de los sistemas: separar la comprensión del documento (donde los LLMs son buenos) de la computación determinista (donde fallan).

5. Significado e Implicaciones

• Para la Industria Financiera: Los resultados indican que los LLMs actuales no pueden reemplazar a los analistas humanos en la extracción de datos financieros sin supervisión. El riesgo de errores sistemáticos en métricas clave (IRR, múltiplos) es demasiado alto.
• Dirección Futura: El camino hacia la automatización fiable no reside en mejorar solo el modelo de lenguaje, sino en desarrollar pipelines en etapas:
  1. Uso de LLMs para descubrir el esquema y extraer valores individuales (donde son muy precisos).
  2. Uso de código determinista (Python/SQL) para realizar cálculos, agregaciones, ordenamientos y verificaciones de identidad contable.
• Investigación: Se abre la puerta a evaluar modalidades multimodales (imágenes de hojas de cálculo) para recuperar pistas visuales perdidas en la serialización de texto, y a probar arquitecturas de agentes que utilicen herramientas de ejecución de código.

En conclusión, FinSheet-Bench establece que, aunque los LLMs han avanzado rápidamente, la extracción confiable de datos financieros complejos requiere una arquitectura híbrida que combine la inteligencia semántica del lenguaje con la precisión matemática de la computación tradicional.