TAPAS: Слабо контролирано таблично QA без SQL и какво означава това за Beancount

Прекарвам доста време в изследване на линията text-to-SQL — BIRD, DIN-SQL, MAC-SQL — но всички те споделят едно предположение, което искам да поставя под въпрос: че правилният интерфейс за таблично QA е генерирането на SQL. TAPAS, публикуван от Herzig et al. в Google Research (ACL 2020), залага на обратното. Той никога не генерира заявка. Вместо това, той просто избира клетки и по избор прилага скаларна агрегация, обучен изцяло (end-to-end) само от денотациите на отговорите.

Документът

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

По време на извод (inference) моделът избира набор от клетки чрез прагове на вероятностите за всяка клетка, след което прилага един от четири агрегационни оператора — NONE, COUNT, SUM или AVERAGE — за да произведе крайния отговор. Няма междинен SQL или логическа форма. Предварителното обучение (pre-training) изпълнява стандартна задача за маскиран езиков модел върху 6,2 милиона двойки таблица-текст от английската Wikipedia.

Ключови идеи

• Вгражданията за колони/редове са критично важни. Аблационните изследвания показват, че премахването им струва 19,4 точки точност при SQA, 10,6 при WikiSQL и 11,6 при WikiTQ — много повече от всеки друг архитектурен компонент.
• Предварителното обучение върху таблици има почти толкова голямо значение. Премахването му сваля SQA с 12,5 точки и WikiTQ с 11,1 точки, дори след фина настройка (fine-tuning).
• При SQA (разговорно таблично QA), TAPAS повишава точността от 55,1% на 67,2%, скок от 12 точки. Вграждането на токена Previous Answer е механизмът, който позволява пренасянето на контекста в разговора без отделен тракер на състоянието.
• При WikiSQL (една таблица, предимно търсене и агрегация), TAPAS достига 83,6% — на практика съвпадайки с 83,9% на най-модерния семантичен парсер, при това с нула генериране на SQL.
• Трансферното обучение от WikiSQL към WikiTQ (многостъпково разсъждение върху множество колони) дава 48,7%, което е с 4,2 точки над най-доброто постижение към онзи момент. Трансферът от SQA дава 48,8%.
• Слабият надзор (weak supervision) е ключовият аргумент за достъпност: моделът се обучава върху двойки (въпрос, отговор), а не върху тройки (въпрос, SQL, отговор), така че можете да анотирате големи корпуси без експертни познания по SQL.

Какво се запазва — и какво не

Основното прозрение — че много въпроси върху таблици могат да бъдат отговорени чрез избиране на клетки и прилагане на една от четири скаларни операции — е емпирично доказано за тестваните бенчмаркове. Но честният анализ на грешките в статията за WikiTQ е показателен: 37% от грешките са некласифицирани от самите автори, 16% изискват манипулация на низове, която моделът не може да прави, а 10% включват сложни времеви разсъждения. Това означава, че таванът на TAPAS не е в грешните агрегационни оператори; той е в цели категории въпроси, които са структурно извън неговия обхват.

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

TAPEX (ICLR 2022) директно адресира тесните места на предварителното обучение, като заменя Wikipedia table MLM със синтетично изпълнение на SQL върху автоматично генерирани програми, изтласквайки WikiTQ до 57,5% (+4,8) и SQA до 74,5% (+3,5). Това е значителна разлика. Но TAPEX наследява същите архитектурни ограничения за размера на таблицата и дълбочината на композицията.

По-дълбокият нерешен въпрос, който нито една от статиите не засяга, е дали парадигмата за избор на клетки е по-подходяща за реално таблично QA от генерирането на SQL по практически съображения — не точност на бенчмарка, а гаранции за одитируемост и коректност. Избирането на клетки е непрозрачно: получавате отговор, но не и програма. Генерирането на SQL е многословно, но проверимо. За производствена употреба този компромис има по-голямо значение от няколко точки точност.

Защо това е важно за финансовия AI

Регистърът на Beancount на практика е плоска, структурирана таблица: сметки в редовете, суми, дати, валути и тагове в колоните. Парадигмата на TAPAS за директен избор на клетки се съпоставя естествено с най-честите заявки към регистъра — "каква е общата сума, похарчена за хранителни стоки през март?" — които са точно SUM и COUNT агрегации върху филтрирани редове. Вграждането на Previous Answer е директно полезно за разговорни сесии, където потребителят прецизира заявка ("а какво ще кажете за миналата година?").

Но регистрите на Beancount в мащаб нарушават ограниченията на TAPAS. Многогодишен регистър с хиляди транзакции надвишава бюджета от 512 токена с порядъци. Йерархиите на сметките изискват разсъждения върху групи от редове. Заявки като "кои сметки имат нетен отлив, по-голям от средния им за последните три години?" се нуждаят от вложени агрегации, които главата с четири оператора не може да изрази. И което е критично: за безопасност при записване обратно (write-back), изборът на клетки не дава одитируема програма, която да бъде проверена преди потвърждаване на промяна. SQL поне предоставя артефакт, който подлежи на инспекция.

Моето предварително заключение е, че парадигмата за избор на клетки е правилният интерфейс за слой за четене на естествен език върху малки моментни снимки на регистъра — транзакции за месец, история на една сметка. За разсъждения върху целия регистър и всичко, включващо записване, подходът със синтез на програми (независимо дали в стил SQL или Beancount DSL) остава по-безопасен и по-изразителен.

Какво да прочетете след това

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — директният наследник, който заменя Wikipedia 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 се допълват, вместо да се конкурират.