TableLlama: ¿Puede un modelo abierto de 7B igualar a GPT-4 en la comprensión de tablas?

El registro de MAC-SQL de la semana pasada me dejó pensando en el eslabón más débil de los agentes basados en tablas: la capacidad del modelo subyacente para comprender la estructura y la semántica de la tabla antes de generar cualquier consulta. TableLlama (NAACL 2024) ataca esa capa directamente, no mejorando la interfaz de consulta, sino construyendo un modelo de código abierto generalista que puede manejar una amplia gama de tareas de tablas sin ingeniería específica para cada tarea. Lo estoy leyendo ahora porque es la respuesta más directa a la pregunta de si un modelo abierto de 7B puede realmente igualar a GPT-4 en los problemas de comprensión de tablas a los que se enfrentaría un agente de Beancount.

El artículo

TableLlama, de Tianshu Zhang, Xiang Yue, Yifei Li y Huan Sun de la Universidad Estatal de Ohio, realiza un ajuste fino de Llama 2 (7B) en un nuevo conjunto de datos de ajuste por instrucciones que llaman TableInstruct: 2,6 millones de ejemplos que abarcan 11 tareas de tablas. Para manejar el contexto extenso que imponen las tablas, adoptan LongLoRA, un enfoque de extensión eficiente en parámetros que estira la ventana de contexto a 8K tokens sin un reentrenamiento completo. La evaluación cubre ocho tareas dentro del dominio (anotación de tipos de columnas, extracción de relaciones, vinculación de entidades, aumento de esquema, población de filas, QA de tablas jerárquicas, QA de celdas resaltadas y verificación de hechos) además de seis conjuntos de datos fuera del dominio con los que el modelo nunca fue entrenado.

La afirmación central: un único modelo abierto ajustado puede igualar o superar el SOTA específico de la tarea en la mayoría de los referentes dentro del dominio y superar al modelo base Llama 2 entre 5 y 44 puntos absolutos fuera del dominio, incluyendo la reducción de la brecha con GPT-4 en varias tareas.

Ideas clave

• En tareas dentro del dominio, TableLlama supera decisivamente a GPT-4 en tareas de reconocimiento estructural: Anotación de Tipos de Columnas (F1 94,39 vs 31,75), Extracción de Relaciones (F1 91,95 vs 52,95), FeTaQA BLEU (39,05 vs 21,70) y precisión de ejecución de HiTab (64,71 vs 48,40).
• En conjuntos de datos fuera del dominio, la situación se invierte. GPT-4 lidera en precisión de WikiTQ (68,40 vs 35,01) e HybridQA (58,60 vs 39,38), ambas tareas que requieren un razonamiento compositivo de múltiples saltos sobre las tablas en lugar de una coincidencia de patrones estructurales.
• WikiSQL expone la brecha de generación de consultas de forma cruda: TableLlama puntúa 50,48% frente a un SOTA de 92,70%. Esta brecha de 42 puntos es el número más relevante en la práctica para cualquiera que construya interfaces de lenguaje natural a consulta.
• LongLoRA es fundamental aquí. Las tablas financieras son largas. Sin la ventana de contexto extendida, toda esta clase de tareas estaría fuera del alcance de un modelo de 7B.
• Los autores reconocen que las limitaciones de cómputo los limitaron al tamaño de 7B, dejando sin evaluar las variantes de 13B y 70B.

Qué se mantiene y qué no

La configuración del referente mezcla peras con manzanas de una manera que merece escrutinio. La comparación dentro del dominio enfrenta a un TableLlama ajustado contra un GPT-4 zero-shot. En tareas basadas en TURL como la Anotación de Tipos de Columnas, la puntuación de GPT-4 de 31,75 F1 no significa que GPT-4 sea fundamentalmente incapaz de entender los tipos de columnas; significa que un prompt zero-shot sin un ajuste específico al formato falla en un conjunto de datos que espera un formato de salida muy particular. La comparación honesta es en tareas fuera del dominio, donde ninguno de los modelos ha visto datos de entrenamiento, y allí la brecha es humillante: precisión en WikiTQ de 35,01 vs 68,40.

WikiTQ es la prueba de esfuerzo adecuada porque requiere preguntas como "¿Qué país ganó más medallas en eventos donde el récord anterior se estableció antes de 1990?", un razonamiento compositivo genuino a través de las celdas de la tabla. El déficit de 33 puntos de TableLlama en WikiTQ frente a GPT-4 es la señal más clara de que el ajuste por instrucciones en tareas estructurales no se transfiere automáticamente al razonamiento relacional.

Las victorias en aumento de esquema y vinculación de entidades son reales y significativas; esas tareas requieren genuinamente comprender la estructura de la tabla de maneras con las que un prompt de GPT-4 zero-shot tiene dificultades. Pero también están más cerca de la recuperación que del razonamiento, lo que limita hasta qué punto se pueden generalizar estos resultados.

Otra preocupación: el conjunto de datos TableInstruct de 2,6 millones de ejemplos es un esfuerzo de ingeniería significativo, pero colapsa tipos de tareas muy diferentes en un solo formato de instrucción. No hay una ablación que muestre qué tipos de tareas interfieren entre sí o cuáles son fundamentales para las ganancias fuera del dominio. El propio referente de seguimiento del grupo de la OSU (TableBench, AAAI 2025) encontró que los modelos ajustados en TableInstruct logran un rendimiento comparable a GPT-3.5 pero aún quedan por debajo de GPT-4, lo que modera considerablemente el optimismo del artículo original.

Por qué esto es importante para la IA financiera

Los libros mayores de Beancount son tablas estructuradas: cada entrada tiene una fecha, cuenta, monto y metadatos opcionales. Las tareas de tablas en este artículo se mapean directamente con las operaciones que un agente de Beancount necesita realizar. La anotación de tipos de columnas se mapea con la comprensión de qué cuentas pertenecen a qué tipo de cuenta (Activos, Pasivos, Gastos). La vinculación de entidades se mapea con la resolución de nombres de beneficiarios en descripciones de transacciones inconsistentes. Y la brecha de WikiSQL se mapea precisamente al problema de la interfaz de lenguaje natural de beanquery.

Los resultados aquí me dan una visión calibrada: un modelo ajustado de 7B puede manejar el reconocimiento de la estructura del libro mayor de manera lo suficientemente confiable como para ser útil, pero aún no se puede confiar en él para traducir preguntas de forma libre a expresiones correctas de beanquery sin un modelo de mayor capacidad en el ciclo. La precisión del 50% en WikiSQL (frente al 93% del SOTA) significa que una interfaz de beanquery basada solo en modelos abiertos generaría consultas incorrectas aproximadamente la mitad de las veces en frases de preguntas desconocidas. Para un agente de escritura, esa tasa de falla es demasiado alta. Para una interfaz de consulta de solo lectura con revisión humana, podría ser aceptable como un primer borrador.

La contribución de LongLoRA es directamente aplicable: los libros mayores de Beancount de varios años pueden superar fácilmente los 8K tokens, y el enfoque aquí muestra cómo realizar un ajuste fino para tablas largas sin un cómputo prohibitivo.

Qué leer a continuación

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025): el propio seguimiento del grupo de la OSU que evalúa más de 30 LLM en tareas de QA de tablas más complejas y encuentra que la brecha entre modelos abiertos y GPT-4 persiste incluso después del ajuste fino con TableInstruct.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022): preentrenamiento en ejecución sintética de SQL como contraste al ajuste por instrucciones; base importante para el debate entre preentrenamiento y ajuste fino en la comprensión de tablas.
• Rethinking Table Instruction Tuning (arXiv:2501.14693): trabajo reciente que cuestiona si la receta estándar de TableInstruct realmente se generaliza y qué opciones de composición de datos importan más.