Chain-of-Table: Evolución de tablas en la cadena de razonamiento de LLM

Sigo volviendo a la misma observación incómoda sobre el razonamiento tabular: cuando los LLM explican su trabajo sobre tablas utilizando texto simple de cadena de pensamiento (chain-of-thought), están narrando una representación mientras razonan sobre otra. Chain-of-Table, un artículo de Google Research publicado en ICLR 2024, se toma en serio esta tensión y propone una solución sencilla: permitir que la propia tabla porte el estado de razonamiento intermedio, no el texto.

El artículo

Wang et al. presentan Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding (arXiv:2401.04398, ICLR 2024). El artículo aborda una brecha dejada por el prompting estándar de cadena de pensamiento cuando se aplica a datos tabulares: CoT razona en lenguaje natural, pero las tablas son artefactos estructurados, y la narración lingüística de las transformaciones de tablas es tanto prolija como propensa a la pérdida de información. La idea central es permitir que el LLM planifique una secuencia de operaciones programáticas de tabla —filtrar, agrupar, ordenar, seleccionar columna, añadir columna— ejecutando cada una para producir un estado de tabla intermedio y retroalimentando esa tabla evolucionada al LLM como entrada para el siguiente paso. La respuesta final se genera a partir del estado final de la tabla en lugar de una larga cadena de texto. Los autores trazan una analogía explícita con el desarrollo de SQL: un analista experto escribe pasos intermedios de CREATE TABLE ... AS SELECT, no una única consulta monolítica. Chain-of-Table formaliza esa práctica para los agentes de LLM.

La evaluación cubre tres bancos de pruebas: WikiTableQuestions (WikiTQ), TabFact y FeTaQA. El modelo principal es PaLM 2, con validación cruzada en GPT-3.5 y LLaMA 2 70B.

Ideas clave

• Chain-of-Table logra una precisión de denotación del 67,31 % en WikiTQ frente al 61,48 % de Dater, la línea base anterior más sólida, lo que supone una mejora de +5,83 puntos porcentuales.
• En tablas que superan los 4.000 tokens, la ventaja crece a +10,25 puntos (44,87 % frente a 34,62 %), que es donde el método más importa en la práctica.
• La precisión en TabFact alcanza el 86,61 % frente al 84,63 % de Dater; el BLEU de FeTaQA mejora de 29,47 a 32,61.
• Las cinco operaciones atómicas —f_select_row, f_select_column, f_group_by, f_sort_by, f_add_column— cubren la gran mayoría de los patrones de razonamiento observados en estos benchmarks; f_group_by realiza la mayor parte del trabajo en WikiTQ, donde el conteo es el modo de fallo dominante.
• Chain-of-Table requiere como máximo 25 generaciones de muestras por pregunta, frente a las 50 de Binder y 100 de Dater, lo que supone una ganancia de eficiencia del 50-75 % junto con una mejor precisión, algo genuinamente inusual en la investigación de LLM, donde el compromiso casi siempre va en la dirección opuesta.
• El enfoque es agnóstico al modelo: supera consistentemente las líneas base de CoT de texto en PaLM 2, GPT-3.5 y LLaMA 2.

Qué se mantiene firme y qué no

La contribución empírica central del artículo es sólida. Los bancos de pruebas son estándares, las líneas base son justas y la historia de eficiencia es convincente. Hacer que la tabla misma sea una representación intermedia explícita en lugar de narrarla en prosa es una idea limpia con una motivación intuitiva, y los resultados en tablas grandes son la evidencia más convincente: cuando la tabla apenas cabe en el contexto, hacer que las operaciones la recorten progresivamente a lo que importa es claramente mejor que producir aún más texto.

Dicho esto, existen lagunas reales. El análisis de propagación de errores es superficial. Si el LLM genera un argumento f_select_row incorrecto en el segundo paso de una cadena de cinco, cada operación subsiguiente se ejecuta sobre una tabla intermedia corrupta y la respuesta final es basura. El artículo informa sobre la precisión agregada pero no analiza con qué frecuencia el razonamiento falla debido a errores en los pasos iniciales frente a errores en los pasos finales, o si el enfoque es robusto ante operaciones parcialmente incorrectas. Para un método que depende de una secuencia de llamadas correctas, esta es una omisión significativa.

El vocabulario de operaciones también es una apuesta. Cinco operaciones cubren la mayoría de los patrones en WikiTQ y TabFact porque esos benchmarks fueron diseñados en torno a tareas de tablas relacionales. Las tablas financieras del mundo real —balances, balances de comprobación del libro mayor, calendarios fiscales— requieren habitualmente uniones (joins) entre tablas relacionadas, agregados calculados con condiciones (SUMA de débitos DONDE la cuenta EMPIEZA CON '6') y transformaciones dinámicas. Ninguna de ellas está en el conjunto de operaciones. Los autores reconocen esto implícitamente pero no lo prueban.

Finalmente, no existe una explicación teórica de por qué los estados intermedios de las tablas deberían ser mejores que el texto intermedio. La intuición es atractiva, pero el artículo es puramente empírico. Los trabajos posteriores (TableMaster, arXiv:2501.19378; H-STAR, NAACL 2025) se movieron rápidamente hacia enfoques híbridos adaptativos que mezclan el razonamiento SQL y de texto, lo que sugiere que la comunidad detectó la misma brecha que yo: las operaciones puramente tabulares no son universalmente mejores, solo mejores en los benchmarks probados.

Por qué esto es importante para la IA financiera

Para los agentes de libros mayores de Beancount, la arquitectura de Chain-of-Table se ajusta casi perfectamente a lo que busco en un pipeline de escritura diferida. Una consulta de Beancount como "¿cuáles son mis gastos netos por categoría para el primer trimestre, excluyendo las transacciones etiquetadas como :ignore?" requiere exactamente el tipo de transformaciones de tabla secuenciales que propone el artículo: filtrar filas por fecha, filtrar por etiqueta, agrupar por categoría de cuenta, sumar importes. Si el agente puede planificar eso como una cadena de operaciones intermedias explícitas en lugar de generar una sola consulta o razonar sobre ella en prosa, el rastro de auditoría es legible y cada paso es verificable de forma independiente.

La mejora de la eficiencia en tablas grandes también es directamente relevante. Un libro mayor de Beancount de varios años con decenas de milies de transacciones supera fácilmente los 4.000 tokens cuando se materializa. La mejora de 10 puntos en ese régimen no es un artefacto de benchmark; refleja lo que sucede realmente cuando la tabla necesita ser estrechada progresivamente antes de que el razonamiento pueda ser preciso.

La pieza que falta para Beancount es la operación de unión (join). La contabilidad de partida doble vincula transacciones entre cuentas, y cualquier tarea de conciliación requiere razonar a través de al menos dos líneas de tiempo de cuentas. Chain-of-Table, tal como se publicó, no puede expresar eso. Ampliar el vocabulario de operaciones para incluir uniones entre cuentas es el siguiente paso de ingeniería obvio para un agente de razonamiento de Beancount en producción.

Qué leer a continuación

• Chain-of-Query: Unleashing the Power of LLMs in SQL-Aided Table Understanding via Multi-Agent Collaboration (2025, arXiv:2508.15809) — amplía el concepto de operación hacia la generación de SQL multi-agente, lo que aborda la brecha de las uniones.
• TableMaster: A Recipe to Advance Table Understanding with Language Models (arXiv:2501.19378) — introduce el razonamiento adaptativo que cambia entre operaciones tabulares y CoT textual; el seguimiento más directo de Chain-of-Table.
• DATER: Decomposition-based Text-to-SQL for LLMs over Long Context (arXiv:2308.01463) — enfoque de descomposición complementario para SQL complejo sobre esquemas grandes, relevante para el diseño de interfaces de lenguaje natural para beanquery.