TAPAS: слабо контролируемое табличное QA без SQL и что это значит для Beancount

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

Исследование

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

Во время инференса модель выбирает набор ячеек путем порогового преобразования вероятностей для каждой ячейки, а затем применяет один из четырех операторов агрегации — NONE (нет), COUNT (количество), SUM (сумма) или AVERAGE (среднее) — для получения окончательного ответа. Промежуточный SQL или логическая форма отсутствуют. Предварительное обучение выполняется по стандартной цели masked language model на 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 пунктов. Эмбеддинг токена Previous Answer — это механизм, который обеспечивает преемственность диалога без отдельного трекера состояний.
• На WikiSQL (одна таблица, в основном поиск и агрегация) TAPAS достигает 83,6% — практически соответствуя уровню SOTA-семантического парсера (83,9%), при этом не генерируя SQL.
• Трансферное обучение с 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 многословна, но её можно проверить. Для промышленного использования этот компромисс важнее нескольких пунктов точности.

Почему это важно для финансового ИИ

Реестр Beancount фактически представляет собой плоскую структурированную таблицу: счета в строках, суммы, даты, валюты и теги в столбцах. Парадигма прямого выбора ячеек TAPAS естественно ложится на самые распространенные запросы к реестру — «сколько всего потрачено на продукты в марте?», — которые представляют собой именно агрегации SUM и COUNT по отфильтрованным строкам. Эмбеддинг Previous Answer напрямую полезен для диалоговых сессий, где пользователь уточняет запрос («а что насчет прошлого года?»).

Однако масштабные реестры Beancount выходят за рамки ограничений TAPAS. Многолетний реестр с тысячами транзакций превышает бюджет в 512 токенов на несколько порядков. Иерархии счетов требуют рассуждений по группам строк. Запросы типа «у каких счетов чистый отток больше, чем их средний показатель за последние три года?» требуют вложенных агрегаций, которые четырех-операторная голова не может выразить. И что критически важно: для безопасности обратной записи выбор ячеек не дает аудируемой программы для проверки перед фиксацией изменений. 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 взаимодополняющими, а не конкурирующими.