¿Pueden los LLM razonar sobre datos tabulares? Lo que cuatro evaluaciones nos dicen sobre la IA financiera

Las tablas son la forma en que piensan los contadores. Un libro mayor de Beancount es esencialmente una tabla: las cuentas como filas, las fechas y los montos como columnas, y las aserciones como restricciones entre celdas. Por eso, cuando empecé a preguntarme si los LLM pueden potenciar agentes financieros autónomos, me topé con la misma pregunta previa: ¿pueden siquiera leer una tabla de manera confiable? La literatura al respecto es más desoladora de lo que esperaba.

El artículo

Fang et al. publicaron "Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey" en TMLR 2024 (arXiv:2402.17944). Es una taxonomía de 41 páginas que cubre tres dominios: la predicción de resultados estructurados a partir de características tabulares, la generación de datos tabulares sintéticos y la comprensión de tablas lo suficientemente bien como para responder preguntas sobre ellas. El área de comprensión —respuestas a preguntas sobre tablas (TableQA), verificación de hechos y razonamiento estructural— es donde reside el trabajo más relevante para la IA financiera.

El artículo que leí junto a este, "Table Meets LLM: Can Large Language Models Understand Structured Table Data?" de Sui et al. (WSDM 2024, arXiv:2305.13062), adopta un enfoque más controlado: definen una evaluación de Capacidad de Comprensión Estructural (SUC) con siete tareas específicas: partición de tabla, detección de tamaño, detección de celdas combinadas, búsqueda de celdas, búsqueda inversa, recuperación de columnas y recuperación de filas, y prueban GPT-3.5 y GPT-4 directamente. Sin cadenas de razonamiento, sin trucos de recuperación. Simplemente: ¿puede el modelo hacer lo que le pedimos?

Ideas clave

• La brecha de formato es real y sorprendentemente grande. En la evaluación SUC, la serialización HTML supera al formato de lenguaje natural con separadores en aproximadamente un 6,76% global. La clasificación (HTML > XML > JSON > Markdown > NL+Sep) se mantiene constante en todas las tareas. Los archivos de Beancount están más cerca del extremo de lenguaje natural de este espectro, lo cual es una señal de advertencia.
• La búsqueda de celdas es sorprendentemente difícil. GPT-3.5 logra solo un 44% de precisión en la búsqueda directa de celdas (encontrar el valor en la fila X, columna Y). GPT-4 alcanza el 73,34% en la misma tarea. Para una operación determinista que una fórmula de hoja de cálculo maneja en microsegundos, una brecha de 26 puntos porcentuales entre modelos es alarmante.
• Los ejemplos de pocos disparos (few-shot) son fundamentales. Eliminar los ejemplos de 1 disparo de los prompts de SUC provocó una caída de la precisión global del 30,38% en todas las tareas. La comprensión estructural del modelo está fuertemente andamiada por la demostración, no genuinamente internalizada.
• La brecha entre humanos y LLM en TableQA real es enorme. TableBench (arXiv:2408.09174, AAAI 2025) evalúa 886 preguntas sobre verificación de hechos, razonamiento numérico, análisis de datos y visualización. La precisión humana es del 85,91%. GPT-4-Turbo obtiene un 40,38%, GPT-4o un 42,73%. Los mejores modelos actuales rinden aproximadamente a la mitad del nivel humano en una evaluación diseñada para reflejar la complejidad de las tablas del mundo real.
• El colapso de la complejidad en las hojas de cálculo financieras es severo. FinSheet-Bench (arXiv:2603.07316) prueba los LLM en plantillas de fondos de capital privado con variada complejidad estructural. Las búsquedas simples logran un 89,1% de precisión. Las agregaciones complejas caen al 19,6%. El archivo de prueba más grande (152 empresas, 8 fondos) arroja una precisión promedio del 48,6% en todos los modelos, frente al 86,2% en el archivo más simple.
• Las tablas largas rompen los modelos categóricamente. El estudio de TMLR informa que más allá de los 1000 tokens, el rendimiento de GPT-3 se degrada hasta ser casi aleatorio. Incluso los modelos con ventanas de contexto de 200K tienen dificultades con conjuntos de datos masivos debido al coste cuadrático de la autoatención sobre secuencias largas.

Qué se sostiene y qué no

La evaluación de Sui et al. está cuidadosamente diseñada y las cifras son creíbles. El hallazgo de que el HTML supera al markdown para tareas estructurales es contraintuitivo —el markdown es más compacto y los LLM ven más de él en el entrenamiento— pero se alinea con lo que cabría esperar: el etiquetado explícito del HTML le da al modelo más anclajes para navegar por la estructura sin tener que inferirla.

De lo que soy escéptico: la técnica de auto-aumentación (incitación en dos etapas donde el primer prompt pide al modelo identificar valores críticos antes de responder) produce mejoras de entre el 0,84 y el 5,68% en evaluaciones posteriores como TabFact y ToTTo. Estas son cifras reales de experimentos reales, pero son marginales. La técnica no aborda el problema fundamental: es un parche de ingeniería de prompts sobre una comprensión estructural genuinamente débil.

El estudio de TMLR tiene el problema de alcance común a todos los surveys: cubre todo, desde la predicción tabular (terreno de XGBoost) hasta la síntesis generativa de tablas y QA, lo que diluye el análisis. La sección más útil para mis propósitos es la de QA estructurado, e incluso allí el estudio mayormente cataloga métodos en lugar de sintetizar cuáles son realmente confiables.

El hallazgo de FinSheet-Bench de que las agregaciones complejas obtienen una puntuación del 19,6% es la señal de alarma más específica para las finanzas. La agregación de carteras, los resúmenes a nivel de fondo y las comparaciones multiperíodo son exactamente las operaciones que hacen que los informes financieros no sean triviales, y es precisamente donde los LLM fallan.

Por qué esto es importante para la IA financiera

Los libros mayores de Beancount son tablas. Cuando un agente autónomo lee un libro mayor para detectar anomalías, generar informes o decidir sobre una escritura de vuelta (write-back), está realizando un razonamiento tabular. La evidencia sugiere que los LLM actuales manejan razonablemente bien las búsquedas simples (recuperación de celdas al 73% para GPT-4) pero colapsan en las operaciones que más importan: agregación de múltiples pasos, estimación de tamaño para libros mayores grandes y razonamiento sobre variaciones estructurales.

El hallazgo sobre la serialización tiene implicaciones prácticas inmediatas. Si estoy enviando archivos de Beancount a un LLM, el formato que elija afecta la precisión en varios puntos porcentuales antes de haber escrito una sola línea de lógica del agente. La sintaxis nativa de Beancount está cerca del extremo "NL+Sep" de la jerarquía de formatos: legible para humanos, subóptima para LLM. Convertir a un intermedio más estructurado (una tabla JSON o HTML de transacciones) antes de alimentar al modelo puede valer el coste del preprocesamiento.

El colapso de la complejidad a escala es el hallazgo más aleccionador. Un libro mayor de Beancount real para una pequeña empresa podría tener miles de transacciones, docenas de cuentas e historia de varios años. Los resultados de FinSheet-Bench sugieren que una vez que una tabla crece hasta el tamaño en que realmente importa, la precisión del LLM se degrada a un territorio que no es seguro para la escritura de vuelta autónoma.

Qué leer a continuación

• TableLLM (arXiv:2311.09206): un modelo ajustado (fine-tuned) entrenado con 169 tablas de Kaggle (UniPredict); se informa que supera sustancialmente a GPT-4 en modo zero-shot en predicción tabular, lo que sugiere que el ajuste específico del dominio sigue siendo el enfoque correcto para tareas de tablas financieras.
• TAT-QA (arXiv:2105.07624): un conjunto de datos específicamente para el razonamiento discreto sobre documentos financieros híbridos (tablas + texto, como informes de ganancias); el modelo TAT-LLM acompañante es el precedente más directo para aplicar modelos especializados al razonamiento de tablas financieras.
• ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412): se centra en perturbaciones adversas como el desorden de filas y el reordenamiento de columnas; si un agente de Beancount es robusto al reordenamiento, es una señal de que comprende la estructura en lugar de la posición.