TableLlama: Чи може відкрита модель 7B зрівнятися з GPT-4 у розумінні таблиць?

Минулого тижня лог MAC-SQL змусив мене замислитися над найслабшою ланкою в табличних агентах: здатністю базової моделі розуміти структуру та семантику таблиць ще до того, як вона згенерує запит. TableLlama (NAACL 2024) атакує саме цей рівень — не шляхом покращення інтерфейсу запитів, а шляхом створення універсальної моделі з відкритим кодом, яка може виконувати широкий спектр табличних завдань без специфічної інженерії під кожне з них. Я читаю цю статтю зараз, бо це найбільш пряма відповідь на питання, чи може відкрита модель 7B насправді зрівнятися з GPT-4 у задачах розуміння таблиць, з якими стикається агент Beancount.

Стаття

TableLlama від Тяньшу Чжана, Сян Юе, Іфей Лі та Хуаня Суня з Університету штату Огайо донавчає Llama 2 (7B) на новому наборі даних для інструктивного навчання (instruction-tuning), який вони називають TableInstruct — 2,6 мільйона прикладів, що охоплюють 11 табличних завдань. Для роботи з довгим контекстом, який вимагають таблиці, вони використовують LongLoRA — метод розширення з ефективним використанням параметрів, що розтягує вікно контексту до 8 тисяч токенів без повного перенавчання. Оцінка охоплює вісім завдань у межах домену (анотування типів стовпців, вилучення зв'язків, зв'язування сутностей, розширення схеми, заповнення рядків, QA для ієрархічних таблиць, QA для виділених клітинок та верифікація фактів) плюс шість наборів даних поза доменом, на яких модель ніколи не навчалася.

Основне твердження: одна донавчена відкрита модель може зрівнятися або перевершити спеціалізовані SOTA на більшості бенчмарків у межах домену та перевершити базову модель Llama 2 на 5–44 абсолютних пункти поза доменом — включно зі скороченням розриву з GPT-4 у кількох завданнях.

Ключові ідеї

• У завданнях у межах домену TableLlama впевнено перемагає GPT-4 у завданнях структурного розпізнавання: анотування типів стовпців (F1 94,39 проти 31,75), вилучення зв'язків (F1 91,95 проти 52,95), FeTaQA BLEU (39,05 проти 21,70) та точність виконання HiTab (64,71 проти 48,40).
• У наборах даних поза доменом ситуація змінюється. GPT-4 лідирує у точності WikiTQ (68,40 проти 35,01) та HybridQA (58,60 проти 39,38) — в обох завданнях, які вимагають композиційного багатоходового міркування над таблицями, а не просто структурного зіставлення патернів.
• WikiSQL чітко висвітлює розрив у генерації запитів: TableLlama отримує 50,48% проти SOTA у 92,70%. Цей розрив у 42 пункти є найбільш практично значущим показником для будь-кого, хто створює інтерфейси NL-to-query.
• LongLoRA тут відіграє критичну роль. Фінансові таблиці довгі. Без розширеного вікна контексту весь цей клас завдань був би недоступним для моделі 7B.
• Автори визнають, що обмеження обчислювальних ресурсів обмежили їх розміром 7B, залишивши варіанти 13B та 70B без оцінки.

Що підтверджується, а що ні

Налаштування бенчмарку змішує грішне з праведним, що заслуговує на критичний розгляд. Порівняння в межах домену протиставляє донавчену TableLlama та zero-shot GPT-4. У завданнях на основі TURL, як-от анотування типів стовпців, результат GPT-4 у 31,75 F1 не означає, що GPT-4 принципово не розуміє типи стовпців — це означає, що zero-shot промпт без налаштування під конкретний формат зазнає невдачі на наборі даних, який очікує дуже специфічний формат виводу. Чесне порівняння — це завдання поза доменом, де обидві моделі не бачили тренувальних даних, і там розрив протвережує: точність WikiTQ 35,01 проти 68,40.

WikiTQ — це правильний стрес-тест, оскільки він вимагає відповідей на питання на кшталт "Яка країна виграла найбільше медалей у змаганнях, де попередній рекорд був встановлений до 1990 року?" — справжнє композиційне міркування по клітинках таблиці. Дефіцит TableLlama у 33 пункти на WikiTQ порівняно з GPT-4 є найчіткішим сигналом того, що інструктивне навчання на структурних завданнях не переноситься автоматично на реляційне мислення.

Перемоги у розширенні схеми та зв'язуванні сутностей є реальними та значущими — ці завдання справді потребують розуміння структури таблиці таким чином, з яким zero-shot промпт GPT-4 справляється насилу. Але вони також ближчі до пошуку (retrieval), ніж до міркування (reasoning), що обмежує ступінь узагальнення цих результатів.

Окреме занепокоєння: набір даних TableInstruct з 2,6 млн прикладів є значним інженерним досягненням, але він зводить дуже різні типи завдань до єдиного формату інструкцій. Немає абляційного дослідження, яке б показувало, які типи завдань заважають один одному, а які є критичними для покращення результатів поза доменом. Власний наступний бенчмарк групи OSU (TableBench, AAAI 2025) виявив, що моделі, донавчені на TableInstruct, досягають продуктивності, порівнянної з GPT-3.5, але все ще поступаються GPT-4, що значно стримує оптимізм оригінальної статті.

Чому це важливо для фінансового ШІ

Леджери Beancount — це структуровані таблиці: кожен запис має дату, рахунок, суму та необов'язкові метадані. Табличні завдання в цій статті безпосередньо відображаються на операції, які повинен виконувати агент Beancount. Анотування типів стовпців відповідає розумінню того, які рахунки належать до якого типу (Assets, Liabilities, Expenses). Зв'язування сутностей відповідає розпізнаванню імен отримувачів платежів у суперечливих описах транзакцій. А розрив у WikiSQL точно відповідає проблемі інтерфейсу NL для beanquery.

Результати дають мені зважений погляд: донавчена модель 7B може надійно розпізнавати структуру леджера, щоб бути корисною, але їй поки не можна довіряти переклад питань у вільній формі у правильні вирази beanquery без участі потужнішої моделі. Точність WikiSQL 50% (проти 93% у SOTA) означає, що інтерфейс beanquery лише на базі відкритої моделі генеруватиме неправильні запити приблизно в половині випадків при незнайомих формулюваннях питань. Для агента з правом запису такий рівень помилок занадто високий. Для інтерфейсу запитів тільки для читання з перевіркою людиною це може бути прийнятним як перша чернетка.

Внесок LongLoRA безпосередньо застосовний: багаторічні леджери Beancount можуть легко перевищувати 8 тисяч токенів, і підхід, описаний тут, показує, як донавчати модель для довгих таблиць без надмірних витрат на обчислення.

Що почитати далі

• TableBench: Комплексний та складний бенчмарк для відповідей на питання за таблицями (arXiv:2408.09174, AAAI 2025) — власне продовження групи OSU, де тестуються понад 30 LLM на складніших QA по таблицях; встановлено, що розрив між відкритими моделями та GPT-4 зберігається навіть після донавчання на TableInstruct.
• TAPEX: Попереднє навчання таблиць через вивчення нейронного виконавця SQL (arXiv:2107.07653, ICLR 2022) — попереднє навчання на синтетичному виконанні SQL як контраст до інструктивного навчання; важливий базовий рівень для дискусії про попереднє навчання проти донавчання у розумінні таблиць.
• Переосмислення інструктивного навчання таблиць (arXiv:2501.14693) — нещодавня робота, яка ставить під сумнів, чи справді стандартний рецепт TableInstruct забезпечує узагальнення, і які вибори складу даних мають найбільше значення.