TAPAS: Слабко контрольоване табличне QA без SQL та його значення для Beancount

Я присвятив певний час лінійці text-to-SQL — BIRD, DIN-SQL, MAC-SQL — але всі вони поділяють припущення, яке я хочу поставити під сумнів: що правильним інтерфейсом для табличного QA є генерація SQL. TAPAS, опублікована Герцигом та ін. у Google Research (ACL 2020), робить протилежну ставку. Вона ніколи не генерує запит. Натомість вона просто вибирає комірки та за потреби застосовує скалярну агрегацію, навчаючись наскрізно виключно на денотаціях відповідей.

Стаття

TAPAS розширює BERT для кодування таблиць, додаючи шість нових вимірів ембедінгів на додаток до стандартних ID позиції та сегмента. ID стовпця (Column ID) та ID рядка (Row ID) позначають, де кожен токен знаходиться у сітці таблиці. ID рангу (Rank ID) кодує відносний числовий порядок у стовпцях, які можна сортувати (ранг 0 означає непорівнюваність, ранг i+1 — для i-го найменшого значення). Індикатор попередньої відповіді (Previous Answer) позначає комірки, які були вибрані на попередньому кроці діалогу. У поєднанні з бінарним ембедінгом сегмента, який відрізняє токени запитання від токенів таблиці, це дає TAPAS її семитипне представлення токенів.

Під час логічного виводу модель вибирає набір комірок, встановлюючи пороги для ймовірностей кожної комірки, а потім застосовує один із чотирьох агрегаційних операторів — NONE, COUNT, SUM або AVERAGE — для отримання кінцевої відповіді. Немає жодної проміжної форми SQL або логічної форми. Попереднє навчання виконує стандартне завдання маскованої мовної моделі (MLM) на 6,2 мільйонах пар текст-таблиця з англійської Вікіпедії.

Ключові ідеї

• Ембедінги стовпців/рядків є вирішальними. Абляція показує, що їх видалення коштує 19,4 пункту точності на SQA, 10,6 на WikiSQL та 11,6 на WikiTQ — значно більше, ніж будь-який інший архітектурний компонент.
• Попереднє навчання на таблицях важить майже стільки ж. Його видалення знижує точність SQA на 12,5 пунктів, а WikiTQ на 11,1 пунктів навіть після тонкого налаштування.
• На SQA (діалогове табличне QA) TAPAS підвищує точність з 55,1% до 67,2%, що є стрибком на 12 пунктів. Ембедінг токена попередньої відповіді — це механізм, який дозволяє переносити контекст діалогу без окремого відстежувача стану.
• На WikiSQL (одна таблиця, переважно пошук та агрегація) TAPAS досягає 83,6% — що фактично відповідає 83,9% SOTA семантичного парсера, при цьому без жодної генерації SQL.
• Перенесення навчання (transfer learning) з WikiSQL на WikiTQ (багатокрокові міркування над кількома стовпцями) дає 48,7%, що на 4,2 пункту вище за тогочасний рівень SOTA. Перенесення з SQA дає 48,8%.
• Слабкий контроль (weak supervision) є головним аргументом на користь доступності: модель навчається на парах (запитання, відповідь), а не на трійках (запитання, SQL, відповідь), тому ви можете анотувати великі корпуси даних без знань SQL.

Що працює, а що ні

Основна ідея — що на багато запитань до таблиць можна відповісти, вибравши комірки та застосувавши одну з чотирьох скалярних операцій — емпірично підтверджується протестованими бенчмарками. Але чесний аналіз помилок авторів на WikiTQ є показовим: 37% помилок не класифіковані самими авторами, 16% вимагають маніпуляцій з рядками, які модель не може виконувати, а 10% включають складні часові міркування. Це означає, що обмеження TAPAS полягає не в помилковості агрегаційних операторів, а в тому, що цілі категорії запитань структурно виходять за межі її можливостей.

Обмеження у 512 токенів — це глуха стіна. Таблиці з понад приблизно 500 комірками мають бути обрізані, і модель не має механізму для міркувань над кількома таблицями. Це не проблема налаштування — це проблема архітектури. Модель також не може створювати вкладені агрегації: запитання на кшталт "скільки рахунків мають середній баланс більше нуля?" вимагає двох проходів (середнє значення всередині предиката COUNT), що заголовок з чотирма операторами не може виразити.

TAPEX (ICLR 2022) безпосередньо вирішує проблему попереднього навчання, замінюючи MLM для таблиць Вікіпедії на синтетичне виконання SQL на автоматично згенерованих програмах, що підняло результати WikiTQ до 57,5% (+4,8) та SQA до 74,5% (+3,5). Це суттєвий розрив. Але TAPEX успадковує ті самі архітектурні обмеження щодо розміру таблиць та глибини композиції.

Більш глибоке невирішене питання, яке не розглядається в жодній зі статей, полягає в тому, чи є парадигма вибору комірок кращою для реального табличного QA, ніж генерація SQL з практичних міркувань — не за точністю бенчмарків, а за гарантіями можливості аудиту та коректності. Вибір комірок є непрозорим: ви отримуєте відповідь, але не програму. Генерація SQL багатослівна, але її можна перевірити. Для промислового використання цей компроміс важить більше, ніж кілька пунктів точності.

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

Реєстр Beancount фактично є плоскою структурованою таблицею: рахунки в рядках, суми, дати, валюти та теги в стовпцях. Парадигма прямого вибору комірок TAPAS природно накладається на найпоширеніші запити до реєстру — "скільки всього витрачено на продукти в березні?" — які є саме агрегаціями SUM та COUNT над відфільтрованими рядками. Ембедінг попередньої відповіді безпосередньо корисний для діалогових сесій, де користувач уточнює запит ("а як щодо минулого року?").

Але реєстри Beancount у великому масштабі ламають обмеження TAPAS. Багаторічний реєстр із тисячами транзакцій перевищує ліміт у 512 токенів на кілька порядків. Ієрархії рахунків вимагають міркувань над групами рядків. Запити на кшталт "які рахунки мають чистий відтік більше, ніж їхнє середнє значення за останні три роки?" потребують вкладених агрегацій, які заголовок з чотирма операторами не може виразити. І що критично: для безпеки зворотного запису (write-back), вибір комірок не дає жодної програми, придатної для аудиту, яку можна було б перевірити перед внесенням змін. SQL принаймні надає артефакт, який можна перевірити.

Мій попередній висновок полягає в тому, що парадигма вибору комірок — це правильний інтерфейс для шару запитів природною мовою тільки для читання над невеликими зрізами реєстру: транзакціями за місяць, історією одного рахунку. Для міркувань над усім реєстром і всього, що пов’язано зі зворотним записом, підхід із синтезом програм (у стилі SQL або DSL Beancount) залишається безпечнішим і виразнішим.

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

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — прямий наступник, який замінює MLM Вікіпедії на синтетичне виконання SQL; безпосередньо відповідає на питання, чи перемагає попереднє навчання на програмах навчання на тексті для табличного QA.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — використовує GPT-3 для генерації програм на SQL або Python над таблицями та досягає SOTA на WikiTQ; гібридний підхід, з яким мають рахуватися прихильники вибору комірок.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — поєднує корпуси природних таблиць із синтетичними даними SQL в одному рецепті попереднього навчання; перевіряє, чи є TAPAS і TAPEX взаємодоповнюваними, а не конкуруючими.