PAL: مدل‌های زبانی به کمک برنامه برای محاسبات مالی قابل اطمینان

پس از صرف زمان در مطالعه ادبیات استدلال جدولی، خواستم رویکرد مکمل را درک کنم: به جای اینکه LLMها را وادار کنیم در مورد جداول با زبان طبیعی استدلال کنند، چه اتفاقی می‌افتد اگر اجازه دهیم کد بنویسند و محاسبات را کاملاً واگذار کنند؟ PAL (Gao et al., 2022, arXiv:2211.10435) پاسخ مرسوم است و پیامدهای آشکاری برای هر سیستمی دارد که نیاز به انجام محاسبات قابل اطمینان روی داده‌های مالی دارد.

مقاله

مقاله "PAL: Program-Aided Language Models" (Gao, Madaan, Zhou, Alon, Liu, Yang, Callan, Neubig; ICML 2023) با یک مشاهده ساده شروع می‌شود: LLMها مسائل را به خوبی تجزیه می‌کنند اما محاسبات ریاضی را به بدی انجام می‌دهند. پرامپت‌نویسی زنجیره اندیشه (Chain-of-thought) مشکل اول را حل می‌کند اما به مشکل دوم نمی‌پردازد. راهکار پیشنهادی تغییر چیزی است که LLM به عنوان "مراحل استدلال" خود تولید می‌کند — به جای محاسبات با زبان طبیعی، کد پایتون تولید می‌کند. سپس یک مفسر پایتون آن کد را اجرا کرده و پاسخ را برمی‌گرداند.

شکاف تجزیه-اجرا شفاف است: LLM درک مسئله و ساختار برنامه را مدیریت می‌کند؛ مفسر تمام امور عددی را بر عهده می‌گیرد. سوالی مانند "اولیویا ۲۳ دلار دارد، پنج بیگل به قیمت هر کدام ۳ دلار می‌خرد — چقدر باقی مانده است؟" تبدیل می‌شود به money_left = 23 - (5 * 3)، نه دنباله‌ای از محاسبات متنی که ممکن است مدل در آن اشتباه کند.

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

• در GSM8K (مسائل ریاضی کلامی در سطح دبستان)، PAL با مدل Codex به دقت ۷۲.۰٪ می‌رسد در حالی که زنجیره اندیشه با همان مدل Codex ۶۵.۶٪ است — یک افزایش ۶.۴ واحد درصدی — و CoT با مدل بسیار بزرگتر PaLM-540B به ۵۶.۹٪ می‌رسد. یک مدل کوچک‌تر با واگذاری محاسبات به پایتون برنده می‌شود.
• در GSM-hard، نسخه‌ای از GSM8K که در آن اعداد با مقادیر بزرگتر جایگزین شده‌اند، PAL به دقت ۶۱.۲٪ می‌رسد در حالی که CoT تنها ۲۳.۱٪ است — یک شکاف مطلق ۳۸.۱ واحد درصدی. اعداد بزرگ محاسبات در سطح توکن را مختل می‌کنند؛ اما پایتون را نه.
• با رای‌گیری اکثریت بر روی ۴۰ نمونه، PAL در GSM8K به ۸۰.۴٪ می‌رسد و مدل Minerva-540B (۷۸.۵٪) را با مدلی که تقریباً ۱/۱۰ اندازه آن است، پشت سر می‌گذارد.
• این دستاوردها به استدلال نمادین نیز تعمیم می‌یابند. در وظایف BIG-Bench Hard مانند شمارش اشیاء، PAL امتیاز ۹۶.۷٪ را در مقابل ۷۳.۰٪ برای CoT کسب می‌کند؛ در مسئله پنگوئن‌ها در جدول، ۹۳.۳٪ در مقابل ۷۹.۲٪.
• یک تحلیل حذفی (ablation) نشان می‌دهد که کار اصلی کجا انجام می‌شود: وقتی LLM به عنوان مفسر خودش عمل می‌کند (بدون پایتون خارجی)، دقت GSM8K به ۲۳.۲٪ سقوط می‌کند. مفسر یک بهبود جزئی نیست — بلکه تمام محاسبات را انجام می‌دهد.
• نام‌گذاری متغیرها مهم است. جایگزینی نام‌های معنی‌دار متغیرها با کاراکترهای تصادفی باعث افت قابل توجه دقت در وظایف نمادین می‌شود. مدل کد خودش را می‌خواند.

آنچه پابرجاست — و آنچه نمی‌ماند

ادعای اصلی به طرز بدیهی صحیح است و آزمایش‌ها آن را به شکلی متقاعدکننده تایید می‌کنند: پایتون در محاسبات بهتر از یک LLM عمل می‌کند و GSM-hard این موضوع را به شکلی بی‌رحمانه آشکار می‌سازد. آن ۳۸ واحد درصد اختلاف، یک نقص در بنچمارک نیست؛ بلکه نشان‌دهنده یک حالت شکست قطعی CoT در مقیاس است.

آنچه برای من کمتر متقاعدکننده است، قاب‌بندی آن به عنوان یک جهش در استدلال عمومی است. PAL در وظایفی عمل می‌کند که پاسخ‌های قطعی و قابل بیان در پایتون دارند. بسیاری از موارد مهم در استدلال مالی به این شکل تجزیه نمی‌شوند. تصمیم‌گیری در مورد اینکه آیا یک الگوی تراکنش "برای این حساب در سه ماهه چهارم غیرعادی" است یا اینکه آیا یک انتقال وجه نیاز به بازبینی دستی دارد، به یک عبارت پایتون قابل تقلیل نیست. PAL به شما یک موتور محاسباتی قابل اطمینان می‌دهد؛ اما قدرت قضاوت نمی‌دهد.

ابعاد امنیتی در مقاله مورد توجه قرار نگرفته است. بنچمارک‌ها در یک محیط کنترل‌شده اجرا می‌شوند، اما هر سیستمی که در پاسخ به ورودی‌های کاربر، کد پایتون دلخواه تولید و اجرا می‌کند، یک سطح حمله جدی محسوب می‌شود. فرار از کرنل مفسرهای سندباکس‌شده، دسترسی به سیستم فایل یا اسرار، و ورودی‌های مخربی که کدهای مخرب تولید می‌کنند — هیچ‌کدام از این‌ها بررسی نشده است. برای برنامه‌های مالی، این یک موضوع فرعی نیست.

همچنین مقاله به طور عمیق حالت‌های شکست را زمانی که تولید کد اشتباه پیش می‌رود، تحلیل نمی‌کند. اگر PAL پایتون نامعتبر از نظر سینتکس تولید کند، عملاً هیچ پاسخی نخواهد داشت. نویسندگان نرخ موفقیت اجرا را گزارش می‌دهند اما توصیف نمی‌کنند که چه چیزی باعث شکست در تولید کد می‌شود یا اینکه آیا این شکست‌ها تصادفی هستند یا سیستماتیک. با توجه به اینکه مفسر تمام محاسبات را انجام می‌دهد، کیفیت کد گلوگاه اصلی قابلیت اطمینان است — و این موضوع کمتر از حد لازم تحلیل شده است.

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

این یکی از کاربردی‌ترین مقالاتی است که در رابطه با Beancount خوانده‌ام. عملیات دفتر کل تقریباً به طور کامل با نقاط قوت PAL همسو هستند: جمع‌بندی تراکنش‌ها بر اساس دسته‌بندی، اعمال نرخ ارز، محاسبه مبنای مالیاتی در چندین سبد (lots)، و تطبیق مجموع صورت‌حساب‌های بانکی با موجودی دفتر کل. این‌ها عملیاتی قطعی، سنگین از نظر محاسباتی و قابل بیان در پایتون هستند. ایجنت‌های مبتنی بر CoT در اینجا اعداد را توهم خواهند زد؛ اما PAL تا زمانی که ساختار برنامه درست باشد، این کار را نمی‌کند.

مقاله Program of Thoughts (arXiv:2211.12588)، که به طور همزمان و مستقل همان ایده را توسعه داد، در سه مجموعه داده پرسش و پاسخ مالی — FinQA، ConvFinQA و TATQA — ارزیابی شد و به طور متوسط ۱۲٪ بهبود نسبت به زنجیره اندیشه گزارش کرد. این مستقیم‌ترین مدرک است که نشان می‌دهد رویکرد تولید برنامه به استدلال در حوزه مالی کمک می‌کند، نه فقط ریاضیات در سطح دبستان.

با این حال، مسئله ایمنی بازنویسی (write-back) در بافت دفتر کل حساس‌تر از بنچمارک‌ها است. ایجنتی که پایتون تولید می‌کند تا داده‌های Beancount را بخواند، کم‌خطر است. ایجنتی که پایتون تولید می‌کند تا ورودی‌های دفتر کل را بنویسد، به یک محیط اجرای بسیار محدود نیاز دارد — محیطی که فقط می‌تواند به اشیاء دفتر کل دسترسی داشته باشد و نه هیچ چیز دیگر، در صورت بروز هرگونه خطا بلافاصله متوقف شود، و کد تولید شده را قبل از اجرا از یک لیست سفید عبور دهد. PAL با مفسر به عنوان یک موتور محاسباتی خنثی برخورد می‌کند. یک ایجنت مالی عملیاتی نمی‌تواند چنین باشد.

آنچه باید بعداً بخوانید

• Program of Thoughts Prompting (Chen et al., arXiv:2211.12588) — اثر همزمانی که روی FinQA، ConvFinQA و TATQA ارزیابی شده و حدود ۱۲٪ بهبود نسبت به CoT گزارش داده است؛ همان ارزیابی تخصصی مالی که PAL انجام نداده است.
• FinQA: A Dataset of Numerical Reasoning over Financial Reports (Chen et al., EMNLP 2021) — بنچمارکی که زیربنای ارزیابی‌های مالی PoT است؛ درک آنچه واقعاً آزمایش می‌شود به شما کمک می‌کند تا میزان اعتماد به انتقال این روش به موارد واقعی Beancount را بسنجید.
• Self-Refine: Iterative Refinement with Self-Feedback (Madaan et al., arXiv:2303.17651) — از همان نویسنده اول PAL، که ایده تولید کد را به حلقه‌های اصلاح خودکار تکراری گسترش می‌دهد؛ برای اینکه بدانیم آیا ایجنت‌های سبک PAL می‌توانند از شکست‌های تولید کد خود بهبود یابند یا خیر، مرتبط است.