TableLlama: Pot un model obert de 7B igualar GPT-4 en la comprensió de taules?

El registre MAC-SQL de la setmana passada em va fer pensar en la baula més feble dels agents basats en taules: la capacitat del model subjacent per entendre l'estructura i la semàntica de la taula abans de generar una consulta. TableLlama (NAACL 2024) ataca aquesta capa directament — no millorant la interfície de consulta, sinó construint un model de codi obert generalista que pot gestionar una àmplia gamma de tasques de taules sense enginyeria específica per a cada tasca. L'estic llegint ara perquè és la resposta més directa a la pregunta de si un model obert de 7B pot realment igualar GPT-4 en els problemes de comprensió de taules que afrontaria un agent de Beancount.

L'article

TableLlama, de Tianshu Zhang, Xiang Yue, Yifei Li i Huan Sun de la Universitat Estatal d'Ohio, realitza un ajustament fi de Llama 2 (7B) en un nou conjunt de dades d'instruccions que anomenen TableInstruct — 2,6 milions d'exemples que abasten 11 tasques de taules. Per gestionar el context llarg que imposen les taules, adopten LongLoRA, un enfocament d'extensió eficient en paràmetres que amplia la finestra de context a 8.000 tokens sense un reentrenament complet. L'avaluació cobreix vuit tasques de domini intern (anotació de tipus de columna, extracció de relacions, enllaç d'entitats, augment d'esquema, població de files, QA de taules jeràrquiques, QA de cel·les ressaltades i verificació de fets) més sis conjunts de dades de fora del domini en què el model mai no havia estat entrenat.

L'afirmació principal: un sol model obert amb ajustament fi pot igualar o superar el SOTA (estat de l'art) específic per a cada tasca en la majoria dels referents de domini intern i superar el model base Llama 2 de 5 a 44 punts absoluts fora del domini — incloent-hi la reducció de la diferència amb GPT-4 en diverses tasques.

Idees clau

• En tasques de domini intern, TableLlama supera decisivament GPT-4 en tasques de reconeixement estructural: Anotació de Tipus de Columna (F1 94,39 vs 31,75), Extracció de Relacions (F1 91,95 vs 52,95), FeTaQA BLEU (39,05 vs 21,70) i precisió d'execució d'HiTab (64,71 vs 48,40).
• En conjunts de dades de fora del domini, el panorama canvia. GPT-4 lidera en precisió de WikiTQ (68,40 vs 35,01) i HybridQA (58,60 vs 39,38) — ambdues tasques que requereixen un raonament compositiu de múltiples salts sobre les taules en lloc d'una coincidència de patrons estructurals.
• WikiSQL exposa la bretxa en la generació de consultes de manera crua: TableLlama obté un 50,48% enfront d'un SOTA del 92,70%. Aquesta diferència de 42 punts és la xifra més rellevant des del punt de vista pràctic per a qualsevol que construeixi interfícies de llenguatge natural a consulta.
• LongLoRA és fonamental aquí. Les taules financeres són llargues. Sense la finestra de context ampliada, tota aquesta classe de tasques estaria fora de l'abast d'un model de 7B.
• Els autors reconeixen que les limitacions de computació els van restringir a la mida de 7B, deixant les variants de 13B i 70B sense avaluar.

El que es manté — i el que no

La configuració del referent barreja naps amb cols d'una manera que mereix ser examinada. La comparació de domini intern enfronta un TableLlama ajustat contra un GPT-4 de tret zero (zero-shot). En tasques basades en TURL com l'Anotació de Tipus de Columna, la puntuació de 31,75 F1 de GPT-4 no significa que GPT-4 fonamentalment no pugui entendre els tipus de columna — significa que una indicació (prompt) de tret zero sense un ajustament específic del format falla en un conjunt de dades que espera un format de sortida molt particular. La comparació honesta es troba en les tasques de fora del domini, on cap dels dos models ha vist dades d'entrenament, i allà la diferència és humiliant: precisió de WikiTQ 35,01 vs 68,40.

WikiTQ és la prova d'estrès adequada perquè requereix preguntes com "Quin país va guanyar més medalles en esdeveniments on el rècord anterior s'havia establert abans de 1990?" — un raonament compositiu genuí entre cel·les de la taula. El dèficit de 33 punts de TableLlama a WikiTQ en comparació amb GPT-4 és el senyal més clar que l'ajustament d'instruccions en tasques estructurals no es transfereix automàticament al raonament relacional.

Les victòries en l'augment d'esquemes i l'enllaç d'entitats són reals i significatives — aquestes tasques realment requereixen entendre l'estructura de la taula de maneres amb què una indicació de tret zero de GPT-4 té dificultats. Però també estan més a prop de la recuperació que del raonament, la qual cosa limita fins on es poden generalitzar aquests resultats.

Una preocupació a part: el conjunt de dades TableInstruct de 2,6 milions d'exemples és un esforç d'enginyeria significatiu, però col·lapsa tipus de tasques molt diferents en un únic format d'instrucció. No hi ha cap ablació que mostri quins tipus de tasques interfereixen entre si o quines són fonamentals per als guanys fora del domini. El propi referent de seguiment del grup d'OSU (TableBench, AAAI 2025) va trobar que els models ajustats amb TableInstruct aconsegueixen un rendiment comparable a GPT-3.5 però encara es queden curts respecte a GPT-4 — cosa que modera considerablement l'optimisme de l'article original.

Per què això és important per a la IA financera

Els llibres majors de Beancount són taules estructurades: cada entrada té una data, un compte, un import i metadades opcionals. Les tasques de taules d'aquest article es mapegen directament amb les operacions que un agent de Beancount ha de realitzar. L'anotació de tipus de columna es tradueix en entendre quins comptes pertanyen a quin tipus de compte (Actius, Passius, Despeses). L'enllaç d'entitats es tradueix en resoldre els noms dels beneficiaris a través de descripcions de transaccions inconsistents. I la bretxa de WikiSQL es tradueix precisament en el problema de la interfície de llenguatge natural de beanquery.

Els resultats aquí em donen una visió calibrada: un model de 7B amb ajustament fi pot gestionar el reconeixement de l'estructura del llibre major amb prou fiabilitat per ser útil, però encara no se li pot confiar la traducció de preguntes de forma lliure en expressions de beanquery correctes sense un model de més capacitat en el bucle. La precisió del 50% de WikiSQL (enfront del 93% del SOTA) significa que una interfície de beanquery només amb models oberts generaria consultes errònies aproximadament la meitat de les vegades en frases de preguntes no familiars. Per a un agent d'escriptura, aquesta taxa de fallada és massa alta. Per a una interfície de consulta de només lectura amb revisió humana, podria ser acceptable com a primer esborrany.

La contribució de LongLoRA és directament aplicable: els llibres majors de Beancount de diversos anys poden superar fàcilment els 8.000 tokens, i l'enfocament aquí mostra com fer un ajustament fi per a taules llargues sense un cost de computació prohibitiu.

Què llegir a continuació

• TableBench: A Comprehensive and Complex Benchmark for Table Question Answering (arXiv:2408.09174, AAAI 2025) — el seguiment del propi grup d'OSU que avalua més de 30 LLM en QA de taules més complexes i troba que la bretxa entre models oberts i GPT-4 persisteix fins i tot després de l'ajustament fi amb TableInstruct.
• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — preentrenament en execució de SQL sintètic com a contrast a l'ajustament d'instruccions; base de referència important per al debat entre preentrenament i ajustament fi en la comprensió de taules.
• Rethinking Table Instruction Tuning (arXiv:2501.14693) — treball recent que qüestiona si la recepta estàndard de TableInstruct realment es generalitza i quines eleccions de composició de dades són les més importants.