TableLlama: آیا یک مدل متن‌باز ۷ میلیاردی می‌تواند در درک جداول با GPT-4 رقابت کند؟

گزارش MAC-SQL در هفته گذشته مرا به فکر واداشت که ضعیف‌ترین حلقه در عامل‌های (agents) مبتنی بر جدول چیست: توانایی مدل زیربنایی در درک ساختار و معناشناسی جدول، پیش از آنکه اصلاً درخواستی (query) ایجاد کند. TableLlama (NAACL 2024) مستقیماً به آن لایه حمله می‌کند — نه با بهبود رابط کاربری پرس‌وجو، بلکه با ساخت یک مدل متن‌باز عمومی که می‌تواند طیف گسترده‌ای از وظایف جدولی را بدون مهندسی خاصِ هر وظیفه انجام دهد. من اکنون آن را می‌خوانم زیرا مستقیم‌ترین پاسخ به این سوال است که آیا یک مدل متن‌باز ۷ میلیاردی واقعاً می‌تواند در مسائل درک جدولی که یک عامل Beancount با آن‌ها مواجه می‌شود، با GPT-4 رقابت کند یا خیر.

مقاله

TableLlama، توسط تیانشو ژانگ، شیانگ یوئه، ییفی لی و هوآن سان در دانشگاه ایالتی اوهایو، مدل Llama 2 (7B) را بر روی مجموعه داده جدیدی از تنظیم با دستورالعمل (instruction-tuning) که آن‌ها TableInstruct می‌نامند — شامل ۲.۶ میلیون نمونه در ۱۱ وظیفه جدولی — تنظیم دقیق می‌کند. برای مدیریت بافتار طولانی (long context) که جداول تحمیل می‌کنند، آن‌ها از LongLoRA استفاده کرده‌اند؛ رویکردی برای گسترش پارامتر-بهینه که پنجره بافتار را بدون بازآموزی کامل به ۸ هزار توکن افزایش می‌دهد. ارزیابی شامل هشت وظیفه درون‌دامنه (برچسب‌گذاری نوع ستون، استخراج رابطه، پیوند موجودیت، گسترش طرح‌واره، پر کردن ردیف، پرسش و پاسخ جدول سلسله‌مرتبی، پرسش و پاسخ سلول برجسته و تایید واقعیت) به علاوه شش مجموعه داده خارج از دامنه است که مدل هرگز روی آن‌ها آموزش ندیده بود.

ادعای اصلی: یک مدل متن‌باز تنظیم‌دقیق شده می‌تواند در اکثر معیارهای درون‌دامنه با SOTA (بهترین مدل‌های موجود) خاصِ آن وظیفه برابری کند یا از آن‌ها پیشی بگیرد و در وظایف خارج از دامنه ۵ تا ۴۴ امتیاز مطلق از مدل پایه Llama 2 بهتر عمل کند — از جمله کاهش فاصله با GPT-4 در چندین وظیفه.

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

• در وظایف درون‌دامنه، TableLlama قاطعانه GPT-4 را در وظایف تشخیص ساختاری شکست می‌دهد: برچسب‌گذاری نوع ستون (F1 ۹۴.۳۹ در مقابل ۳۱.۷۵)، استخراج رابطه (F1 ۹۱.۹۵ در مقابل ۵۲.۹۵)، FeTaQA BLEU (۳۹.۰۵ در مقابل ۲۱.۷۰) و دقت اجرای HiTab (۶۴.۷۱ در مقابل ۴۸.۴۰).
• در مجموعه‌داده‌های خارج از دامنه، تصویر برعکس می‌شود. GPT-4 در دقت WikiTQ (۶۸.۴۰ در مقابل ۳۵.۰۱) و HybridQA (۵۸.۶۰ در مقابل ۳۹.۳۸) پیشتاز است — هر دو وظیفه‌ای هستند که به استدلال ترکیبی چندمرحله‌ای روی جداول نیاز دارند، نه صرفاً تطبیق الگوهای ساختاری.
• WikiSQL شکاف تولید پرس‌وجو را به وضوح نشان می‌دهد: TableLlama امتیاز ۵۰.۴۸٪ را در مقابل SOTA که ۹۲.۷۰٪ است کسب می‌کند. این شکاف ۴۲ امتیازی، مرتبط‌ترین عدد عملی برای هر کسی است که در حال ساخت رابط‌های زبان طبیعی به پرس‌وجو (NL-to-query) است.
• LongLoRA در اینجا نقش حیاتی دارد. جداول مالی طولانی هستند. بدون پنجره بافتار گسترش‌یافته، کل این کلاس از وظایف برای یک مدل 7B دور از دسترس بود.
• نویسندگان اذعان می‌کنند که محدودیت‌های محاسباتی آن‌ها را به اندازه 7B محدود کرده و نسخه‌های 13B و 70B ارزیابی‌نشده باقی مانده‌اند.

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

ساختار بنچمارک، موارد متفاوت را به گونه‌ای با هم مقایسه می‌کند که شایسته بررسی دقیق است. مقایسه درون‌دامنه، یک TableLlama تنظیم‌دقیق شده را در مقابل GPT-4 بدون آموزش (zero-shot) قرار می‌دهد. در وظایف مبتنی بر TURL مانند برچسب‌گذاری نوع ستون، امتیاز ۳۱.۷۵ برای GPT-4 به این معنی نیست که GPT-4 اساساً نمی‌تواند انواع ستون‌ها را درک کند — بلکه به این معنی است که یک پرامپت zero-shot بدون تنظیمات خاصِ فرمت، در مجموعه‌داده‌ای که انتظار خروجی با فرمت بسیار خاصی را دارد، شکست می‌خورد. مقایسه صادقانه در وظایف خارج از دامنه است، جایی که هیچ‌کدام از مدل‌ها داده‌های آموزشی را ندیده‌اند و در آنجا شکاف چشمگیر است: دقت WikiTQ ۳۵.۰۱ در مقابل ۶۸.۴۰.

WikiTQ آزمون استرس مناسبی است زیرا به سوالاتی مانند "کدام کشور بیشترین مدال را در رویدادهایی به دست آورد که رکورد قبلی در آن‌ها قبل از ۱۹۹۰ ثبت شده بود؟" نیاز دارد — استدلال ترکیبی واقعی در سلول‌های جدول. نقص ۳۳ امتیازی TableLlama در WikiTQ نسبت به GPT-4 واضح‌ترین سیگنال است که تنظیم دستورالعمل در وظایف ساختاری، به طور خودکار به استدلال رابطه‌ای منتقل نمی‌شود.

موفقیت‌ها در گسترش طرح‌واره و پیوند موجودیت واقعی و معنادار هستند — این وظایف واقعاً به درک ساختار جدول به روش‌هایی نیاز دارند که یک پرامپت zero-shot در GPT-4 با آن دست و پنجه نرم می‌کند. اما این‌ها بیشتر به بازیابی (retrieval) نزدیک هستند تا استدلال، که باعث می‌شود تعمیم‌پذیری این نتایج محدود باشد.

نگرانی دیگر: مجموعه داده ۲.۶ میلیونی TableInstruct یک تلاش مهندسی قابل توجه است، اما انواع وظایف بسیار متفاوت را در یک فرمت دستورالعمل واحد ادغام می‌کند. هیچ تحلیل حذف‌کننده‌ای (ablation) وجود ندارد که نشان دهد کدام نوع وظایف با یکدیگر تداخل دارند یا کدام‌یک برای دستاوردهای خارج از دامنه حیاتی هستند. بنچمارک بعدی خود گروه OSU (تحت عنوان TableBench، در AAAI 2025) نشان داد که مدل‌های تنظیم‌دقیق شده بر روی TableInstruct به عملکردی مشابه GPT-3.5 می‌رسند اما همچنان از GPT-4 عقب می‌مانند — که خوش‌بینی مقاله اصلی را به میزان قابل توجهی تعدیل می‌کند.

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

دفاتر کل Beancount جداول ساختاریافته هستند: هر ورودی دارای تاریخ، حساب، مبلغ و متادیتای اختیاری است. وظایف جدولی در این مقاله مستقیماً بر روی عملیاتی که یک عامل Beancount باید انجام دهد منطبق است. برچسب‌گذاری نوع ستون با درک اینکه کدام حساب‌ها به کدام نوع حساب (دارایی، بدهی، هزینه) تعلق دارند، مطابقت دارد. پیوند موجودیت با حل کردن نام طرف‌های معامله (payee) در توضیحات تراکنش‌های ناهماهنگ مطابقت دارد. و شکاف WikiSQL دقیقاً با مسئله رابط زبان طبیعیِ beanquery مطابقت دارد.

نتایج در اینجا دیدگاهی کالیبره شده به من می‌دهد: یک مدل ۷ میلیاردی تنظیم‌دقیق شده می‌تواند تشخیص ساختار دفتر کل را به اندازه کافی قابل اطمینان انجام دهد تا مفید باشد، اما هنوز نمی‌توان به آن اعتماد کرد تا سوالات با فرم آزاد را بدون حضور یک مدل با توانایی بالاتر در چرخه، به عبارات صحیح beanquery ترجمه کند. دقت ۵۰ درصدی WikiSQL (در مقابل ۹۳ درصد SOTA) به این معنی است که یک رابط beanquery که فقط از مدل متن‌باز استفاده می‌کند، در حدود نیمی از مواقع برای سوالاتی با بیان ناآشنا، پرس‌وجوهای اشتباه تولید می‌کند. برای عاملی که اجازه نوشتن (write-back) دارد، این نرخ خطا بسیار بالا است. برای یک رابط پرس‌وجوی فقط-خواندنی با بررسی انسانی، ممکن است به عنوان پیش‌نویس اول قابل قبول باشد.

دستاورد LongLoRA مستقیماً قابل استفاده است: دفاتر کل Beancount که چندین سال را پوشش می‌دهند به راحتی می‌توانند از ۸ هزار توکن فراتر بروند و رویکرد ارائه شده در اینجا نشان می‌دهد که چگونه می‌توان مدل را برای جداول طولانی بدون هزینه‌های محاسباتی سرسام‌آور تنظیم دقیق کرد.

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

• TableBench: یک بنچمارک جامع و پیچیده برای پرسش و پاسخ جدولی (arXiv:2408.09174, AAAI 2025) — مقاله بعدی گروه OSU که بیش از ۳۰ مدل زبانی بزرگ را در پرسش و پاسخ‌های پیچیده‌تر جدولی ارزیابی می‌کند و نشان می‌دهد که شکاف بین مدل‌های متن‌باز و GPT-4 حتی پس از تنظیم دقیق TableInstruct نیز پابرجا می‌ماند.
• TAPEX: پیش‌آموزش جدول از طریق یادگیری یک اجراکننده عصبی SQL (arXiv:2107.07653, ICLR 2022) — پیش‌آموزش روی اجرای SQL مصنوعی به عنوان تضادی با تنظیم دستورالعمل؛ یک خط پایه مهم برای بحث پیش‌آموزش در مقابل تنظیم دقیق در درک جدول.
• بازاندیشی در تنظیم دستورالعمل جدولی (arXiv:2501.14693) — کار اخیر که بررسی می‌کند آیا فرمول استاندارد TableInstruct واقعاً تعمیم می‌یابد و کدام انتخاب‌های ترکیب داده‌ها بیشترین اهمیت را دارند.