TableMaster: адаптивне міркування для розуміння таблиць за допомогою LLM

Гроссбух Beancount — це, по суті, структурована таблиця: рахунки як стовпці, час як одна вісь, суми та валюти як значення. Будь-який агент, який міркує над ним, повинен робити те саме, що й TableMaster — знаходити правильні рядки та стовпці, розуміти значення чисел і вибирати, чи обчислювати символічно, чи міркувати мовою. TableMaster Лан Цао та Ханьбін Лю (arXiv:2501.19378) — це найбільш здатний конвеєр розуміння таблиць, який я бачив на сьогодні без донавчання (fine-tuning), і я хотів зрозуміти, чи він дійсно просуває стан справ у галузі принциповим чином, чи просто нагромаджує евристики промптингу, доки показники бенчмарку не зрушать з місця.

Стаття

TableMaster — це фреймворк на основі промптингу, який вирішує чотири специфічні типи помилок LLM під час відповіді на запитання за таблицями: вони мають труднощі з пошуком потрібної клітинки у великій таблиці, вони втрачають семантичний контекст, закодований у заголовках стовпців, у них виникають галюцинації при арифметичних обчисленнях під час міркування простою мовою, і вони зазнають невдачі, коли символічне міркування (SQL, Python) стикається із зашумленими даними або даними змішаних типів. Автори відповідають на кожну невдачу окремим модулем, зібраним у триетапний конвеєр. Перший етап створює «фокусну таблицю» (table-of-focus) — скорочену підтаблицю, що містить лише рядки та стовпці, релевантні запиту, — використовуючи ранжований LLM пошук стовпців і фільтрацію рядків на основі SQL. Другий етап вербалізує цю підтаблицю природною мовою та перевіряє, чи достатньо отриманого фрагмента для відповіді на запитання, ітеративно розширюючи його, якщо ні. Третій етап застосовує адаптивне міркування: LLM вирішує для кожного запиту, чи запускати ланцюжок думок (chain-of-thought) над вербалізованим описом, чи генерувати та виконувати код Python або SQL, причому символічний шлях керується описом природною мовою, щоб впоратися з випадками, коли значення в таблиці є зашумленими рядками, а не чистими числовими даними.

Жодна нова модель не навчалася. Все працює на LLM загального призначення (GPT-3.5-turbo, GPT-4o-mini, Llama-3.1-70B) за допомогою промптингу.

Ключові ідеї

• На WikiTQ з GPT-4o-mini TableMaster досягає 78,13%, порівняно з 55,60% для Chain-of-Table та 64,73% для PoTable на тій самій моделі — це покращення на 13,40 пункта порівняно з наступним найкращим базовим показником.
• Така ж закономірність зберігається для GPT-3.5-turbo (68,21% проти попереднього найкращого результату ~58%) та Llama-3.1-70B (77,95%), що свідчить про те, що переваги не обмежені конкретною моделлю.
• На TabFact (перевірка фактів) TableMaster досягає 90,12% з GPT-4o-mini проти 84,24% для Chain-of-Table — менше, але стабільне покращення.
• Абляція показує, що видалення текстового міркування шкодить найбільше (–4,28%), за ним йде видалення вилучення структури (–3,38%). Адаптивне перемикання між режимами дійсно є критично важливим.
• Розмір таблиці є основним предиктором помилок: продуктивність монотонно погіршується зі збільшенням кількості рядків, стовпців і токенів, незалежно від моделі.
• Символічне міркування погіршується на 31,8% на зашумлених таблицях проти 20,5% для текстового міркування — керований текстом символічний шлях існує саме для того, щоб пом'якшити цей сценарій невдачі.
• Тільки текстове міркування погіршується на 20,1% у завданнях з великою кількістю обчислень проти 72,4% у завданнях без обчислень — що ілюструє, чому гібридне перемикання має значення.

Що витримує критику, а що ні

Діагностика чотирьох викликів є добре вмотивованою та чітко відповідає реальним випадкам невдач. Абляція чесна: видалення будь-якого компонента шкодить, причому ступінь шкоди пропорційний тому, наскільки цей компонент фактично використовувався. Це сильніше за звичайну абляцію, де видалення компонентів нічого не змінює, бо модель навчилася їх обходити.

Що мені важче оцінити, то це сам класифікатор адаптивного міркування. Рішення про те, чи спрямовувати запит до тексту чи до коду, приймається LLM за допомогою промпту — у статті не повідомляється, як часто це маршрутування є правильним, що відбувається при помилках (наприклад, спрямування обчислення до тексту) або чи просте правило (чи містить запит арифметичні оператори?) працювало б порівнянно. Враховуючи, що текстове міркування є найбільшим фактором в абляції, я підозрюю, що більшість запитів за замовчуванням йдуть текстовим шляхом, а символічна гілка несе меншу частку, ніж передбачає опис.

Порівняння з Chain-of-Table також дещо перебільшене контекстом. Оригінальна оцінка Chain-of-Table використовувала PaLM 2 і GPT-3.5 — показник 55,60% для Chain-of-Table на GPT-4o-mini може відображати недостатнє налаштування промптів Chain-of-Table для цієї моделі, а не справжню архітектурну перевагу. Це не скасовує результат, але означає, що заявлений розрив слід сприймати як верхню межу справжнього покращення.

Стаття пройшла шість редакцій з січня 2025 року, що є незвичним. Сфера обмежена англомовними наборами даних і таблицями до кількох сотень рядків. Жодного аналізу витрат не представлено — кожен запит тепер вимагає кількох викликів LLM (ранжування стовпців, SQL для рядків, перевірка достатності, вербалізація, маршрутування, міркування), і за цінами провідних моделей це швидко накопичується.

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

Типи помилок, які вирішує TableMaster, — це саме ті помилки, з якими, на мою думку, стикатимуться агенти для гроссбухів Beancount. Гроссбух із транзакціями за три роки на 40 рахунках — це велика, семантично багата таблиця — питання «яким був мій чистий дохід від фрилансу в 3 кварталі 2023 року?» вимагає пошуку правильних рахунків (пошук стовпців), фільтрації за датою (пошук рядків), розуміння того, що «фриланс» відповідає кільком назвам рахунків (семантичне збагачення), і точного підсумовування сум (символічна арифметика). Конвеєр TableMaster, застосований до інтерфейсу beanquery, атакував би саме ці кроки.

Обмеження, яке найбільше важить для бухгалтерських книг, — це масштаб. Таблиці WikiTQ мають щонайбільше кілька десятків рядків і жменьку стовпців; реальний багаторічний гроссбух Beancount має тисячі записів. Стаття показує, що продуктивність монотонно погіршується з розміром таблиці та не проводить тестування понад кілька сотень рядків. Вилучення фокусної таблиці покликане вирішити це, але сам SQL-фільтр рядків — це згенерований LLM запит до повної таблиці — що скоріше переносить складну проблему, ніж вирішує її. Взаємодія з ієрархічною пам'яттю в стилі MemGPT або з попередньо індексованим шаром beanquery є природним наступним кроком.

Керований текстом символічний шлях безпосередньо застосовний до Beancount. Суми в гроссбуху часто оточені метаданими (коди валют, анотації партій, маркери собівартості), які змусили б звичайний парсер float у Python видати помилку. Обґрунтування генерації коду в описі природною мовою того, що саме код має обчислити, є розумним методом пом'якшення ризиків, хоча це потребує систематичної оцінки на реальних форматах експорту Beancount.

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

• H-STAR: LLM-driven Hybrid SQL-Text Adaptive Reasoning on Tables (arXiv:2407.05952) — найближчий попередник адаптивної маршрутизації TableMaster із двоетапною стратегією вилучення стовпців, а потім рядків; варто порівняти архітектури безпосередньо, щоб зрозуміти, що додає TableMaster.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — хоча TableMaster націлений на QA, представлення таблиці та конвеєр нормалізації однаково релевантні для виявлення аномалій; скоринг на основі ймовірності в AnoLLM потребує подібного етапу попередньої обробки.
• CFMS: A Coarse-to-Fine Multimodal Synthesis Framework for Enhanced Tabular Reasoning (arXiv:2604.10973) — схоже, розширює ідею поетапного вилучення на мультимодальні таблиці; релевантно, якщо візуалізації гроссбуха Beancount (графіки, виписки у PDF) потрібно узгодити зі структурованими текстовими записами.