TAPAS: پرسش و پاسخ جدولی با نظارت ضعیف بدون SQL، و معنای آن برای Beancount

من مدتی را روی نسل تبدیل متن به SQL - یعنی BIRD، DIN-SQL و MAC-SQL - وقت گذاشته‌ام، اما همه آن‌ها در یک فرض مشترک هستند که می‌خواهم آن را زیر سوال ببرم: اینکه رابط کاربری درست برای پرسش و پاسخ جدولی، تولید SQL است. مدل TAPAS که توسط Herzig و همکاران در بخش تحقیقات گوگل (ACL 2020) منتشر شد، شرط متفاوتی را می‌بندد. این مدل هرگز پرس‌وجویی تولید نمی‌کند. در عوض، صرفاً سلول‌ها را انتخاب کرده و به‌صورت اختیاری یک تجمیع اسکالر را اعمال می‌کند که به‌صورت سرتاسری (end-to-end) تنها از روی مقادیر نهایی پاسخ آموزش دیده است.

مقاله

TAPAS مدل BERT را برای کدگذاری جداول با افزودن شش بعد جدید از جاسازی (embedding) فراتر از شناسه‌های موقعیت و بخش استاندارد گسترش می‌دهد. شناسه ستون (Column ID) و شناسه ردیف (Row ID) مشخص می‌کنند که هر توکن در کجای شبکه جدول قرار دارد. یک شناسه رتبه (Rank ID) ترتیب عددی نسبی را در ستون‌های قابل مرتب‌سازی کدگذاری می‌کند (رتبه ۰ به معنای غیرقابل مقایسه، رتبه i+1 برای i-امین مقدار کوچک‌تر). یک نشانگر پاسخ قبلی (Previous Answer) سلول‌هایی را که در نوبت گفتگوی قبلی انتخاب شده بودند، علامت‌گذاری می‌کند. ترکیب این‌ها با جاسازی بخش باینری که توکن‌های سوال را از توکن‌های جدول متمایز می‌کند، نمایش توکن هفت‌گانه TAPAS را می‌سازد.

در زمان استنتاج، مدل مجموعه‌ای از سلول‌ها را با اعمال آستانه بر احتمالات هر سلول انتخاب می‌کند، سپس یکی از چهار عملگر تجمیع - NONE (هیچ)، COUNT (تعداد)، SUM (جمع) یا AVERAGE (میانگین) - را برای تولید پاسخ نهایی اعمال می‌کند. هیچ فرم منطقی یا SQL میانی وجود ندارد. پیش‌آموزش یک هدف مدل زبانی ماسک‌شده (MLM) استاندارد را روی ۶.۲ میلیون جفت متن-جدول ویکی‌پدیا انگلیسی اجرا می‌کند.

ایده‌های کلیدی

• جاسازی‌های ستون/ردیف بسیار حیاتی هستند. تحلیل فرسایشی (Ablation) نشان می‌دهد که حذف آن‌ها باعث کاهش ۱۹.۴ امتیازی دقت در SQA، ۱۰.۶ امتیازی در WikiSQL و ۱۱.۶ امتیازی در WikiTQ می‌شود - که بسیار بیشتر از هر مؤلفه معماری دیگری است.
• پیش‌آموزش جدول تقریباً به همان اندازه اهمیت دارد. حذف آن حتی پس از تنظیم دقیق (fine-tuning)، دقت SQA را ۱۲.۵ امتیاز و WikiTQ را ۱۱.۱ امتیاز کاهش می‌دهد.
• در SQA (پرسش و پاسخ جدولی محاوره‌ای)، TAPAS دقت را از ۵۵.۱٪ به ۶۷.۲٪ می‌رساند که یک جهش ۱۲ امتیازی است. جاسازی توکن پاسخ قبلی سازوکاری است که باعث می‌شود تداوم گفتگو بدون یک ردیاب وضعیت (state tracker) جداگانه عمل کند.
• در WikiSQL (تک‌جدولی، عمدتاً جستجو و تجمیع)، TAPAS به ۸۳.۶٪ می‌رسد - که اساساً با تجزیه‌کننده معنایی SOTA با ۸۳.۹٪ مطابقت دارد، آن هم با صفر تولید SQL.
• یادگیری انتقالی از WikiSQL به WikiTQ (استدلال چندمرحله‌ای و چندستونی) ۴۸.۷٪ را به دست می‌دهد که ۴.۲ امتیاز بالاتر از وضعیت هنر در آن زمان است. انتقال SQA دقت ۴۸.۸٪ را می‌دهد.
• نظارت ضعیف ادعای اصلی مقرون‌به‌صرفه بودن است: مدل روی جفت‌های (سوال، پاسخ) آموزش می‌بیند، نه سه‌گانه‌های (سوال، SQL، پاسخ)، بنابراین می‌توانید مجموعه‌های داده بزرگ را بدون تخصص SQL برچسب‌گذاری کنید.

چه چیزی پابرجا می‌ماند - و چه چیزی نه

بینش اصلی - اینکه بسیاری از سوالات پرسش و پاسخ جدولی را می‌توان با انتخاب سلول‌ها و اعمال یکی از چهار عملیات اسکالر پاسخ داد - برای بنچمارک‌های آزمایش شده از نظر تجربی درست است. اما تحلیل خطای صادقانه مقاله در WikiTQ گویاست: ۳۷٪ از خطاها توسط خود نویسندگان طبقه‌بندی نشده‌اند، ۱۶٪ نیاز به دستکاری رشته (string manipulation) دارند که مدل قادر به انجام آن نیست، و ۱۰٪ شامل استدلال‌های پیچیده زمانی هستند. این بدان معناست که سقف TAPAS به دلیل اشتباه بودن عملگرهای تجمیع نیست؛ بلکه به این دلیل است که کل دسته‌هایی از سوالات از نظر ساختاری خارج از محدوده هستند.

محدودیت ۵۱۲ توکنی یک دیوار سخت است. جداول با بیش از تقریباً ۵۰۰ سلول باید کوتاه شوند و مدل هیچ سازوکاری برای استدلال چند‌جدولی ندارد. این یک مشکل تنظیم نیست - بلکه یک مشکل معماری است. مدل همچنین نمی‌تواند تجمیع‌های تودرتو را انجام دهد: سوالی مانند "چند حساب دارای میانگین موجودی بزرگتر از صفر هستند؟" به دو مرحله نیاز دارد (میانگین در داخل یک گزاره COUNT)، که هِد (head) چهار عملگری نمی‌تواند آن را بیان کند.

TAPEX (ICLR 2022) مستقیماً با جایگزینی MLM جدول ویکی‌پدیا با اجرای SQL مصنوعی روی برنامه‌های خودکار تولید شده، به تنگنای پیش‌آموزش می‌پردازد و WikiTQ را به ۵۷.۵٪ (+۴.۸) و SQA را به ۷۴.۵٪ (+۳.۵) می‌رساند. این یک شکاف معنادار است. اما TAPEX همان محدودیت‌های معماری را در مورد اندازه جدول و عمق ترکیب‌بندی به ارث می‌برد.

سوال عمیق‌تر و حل‌نشده‌ای که هیچ‌کدام از مقاله‌ها به آن نمی‌پردازند این است که آیا الگوی انتخاب سلول از نظر عملی برای پرسش و پاسخ جدولی در دنیای واقعی مناسب‌تر از تولید SQL است یا خیر - نه دقت بنچمارک، بلکه قابلیت حسابرسی و تضمین صحت. انتخاب سلول مبهم است: شما یک پاسخ می‌گیرید اما هیچ برنامه‌ای ندارید. تولید SQL پرگو است اما قابل تایید است. برای استفاده عملیاتی، این سبک‌سنگین کردن (tradeoff) بیشتر از چند امتیاز دقت اهمیت دارد.

چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد

یک دفترکل Beancount در واقع یک جدول تخت و ساختاریافته است: حساب‌ها در ردیف‌ها و مبالغ، تاریخ‌ها، ارزها و تگ‌ها در ستون‌ها. الگوی انتخاب مستقیم سلول TAPAS به‌طور طبیعی بر رایج‌ترین پرس‌وجوهای دفترکل منطبق می‌شود - "کل هزینه صرف شده برای خواربار در ماه مارس چقدر است؟" - که دقیقاً تجمیع‌های SUM و COUNT روی ردیف‌های فیلتر شده هستند. جاسازی پاسخ قبلی مستقیماً برای جلسات محاوره‌ای مفید است که در آن کاربر پرس‌وجو را اصلاح می‌کند ("و در مورد سال گذشته چطور؟").

اما دفترکل‌های Beancount در مقیاس بزرگ محدودیت‌های TAPAS را می‌شکنند. یک دفترکل چندساله با هزاران تراکنش، چندین مرتبه بزرگی از بودجه ۵۱۲ توکنی فراتر می‌رود. سلسله مراتب حساب‌ها نیازمند استدلال در گروه‌های ردیفی است. پرس‌وجوهایی مانند "کدام حساب‌ها خروجی خالص بزرگتر از میانگین خود در سه سال گذشته دارند؟" به تجمیع‌های تودرتویی نیاز دارند که هد چهار عملگری نمی‌تواند بیان کند. و نکته حیاتی: برای ایمنی بازنویسی (write-back)، انتخاب سلول هیچ برنامه قابل حسابرسی برای بررسی قبل از ثبت تغییر ارائه نمی‌دهد. SQL حداقل یک اثر قابل بازبینی ارائه می‌دهد.

نتیجه‌گیری موقت من این است که الگوی انتخاب سلول رابط مناسبی برای یک لایه پرس‌وجوی فقط‌خواندنی به زبان طبیعی روی اسنپ‌شات‌های کوچک دفترکل است - تراکنش‌های یک ماه، سابقه یک حساب واحد. برای استدلال در کل دفترکل و هر چیزی که شامل بازنویسی باشد، رویکرد ترکیب برنامه (چه به سبک SQL یا DSL اختصاصی Beancount) ایمن‌تر و گویاتر باقی می‌ماند.

آنچه باید در ادامه بخوانید

• TAPEX: Table Pre-training via Learning a Neural SQL Executor (arXiv:2107.07653, ICLR 2022) — جانشین مستقیم که MLM ویکی‌پدیا را با اجرای SQL مصنوعی جایگزین می‌کند؛ مستقیماً به این سوال پاسخ می‌دهد که آیا پیش‌آموزش روی برنامه‌ها بهتر از پیش‌آموزش روی متن برای پرسش و پاسخ جدولی است یا خیر.
• Binder: Binding Language Models in Symbolic Languages (arXiv:2210.02875) — از GPT-3 برای تولید برنامه‌ها در SQL یا پایتون روی جداول استفاده می‌کند و به SOTA در WikiTQ می‌رسد؛ رویکرد ترکیبی که مدافعان انتخاب سلول باید به آن توجه کنند.
• OmniTab: Natural and Artificially Structured Data for Table QA (arXiv:2207.02270) — مجموعه‌های جدولی طبیعی را با داده‌های SQL مصنوعی در یک دستورالعمل پیش‌آموزش واحد ترکیب می‌کند؛ آزمایش می‌کند که آیا TAPAS و TAPEX مکمل یکدیگر هستند یا رقیب.