Toolformer: استفاده از ابزار بصورت خود-نظارتی و محدودیت‌های آن برای هوش مصنوعی مالی

Toolformer (Schick و همکاران، ۲۰۲۳، Meta AI) مقاله زیربنایی برای آموزش مدل‌های زبانی جهت فراخوانی APIهای خارجی از طریق آموزش خود-نظارتی است. من مدتی خواندن دقیق آن را به تعویق می‌انداختم زیرا "استفاده از ابزار" (tool use) به چنان کلمه پرزرق‌وبرقی تبدیل شده که ادعاهای اصلی در آن گم شده‌اند. قبل از طراحی هرگونه عامل بازنویسی (write-back agent) که ابزارهای دفتر کل را فراخوانی می‌کند، باید درک کنم که Toolformer واقعاً چه چیزی را اثبات کرده است — و در کجا بی‌سروصدا شکست می‌خورد.

مقاله

تیمو شیک و هفت نویسنده همکار در Meta AI روشی را برای آموزش یک مدل زبانی ارائه می‌دهند تا تصمیم بگیرد چه زمانی APIهای خارجی را فراخوانی کند، چه آرگومان‌هایی را ارسال کند و چگونه نتایج را در پیش‌بینی‌های خود بگنجاند — بدون اینکه برای هر ابزار به داده‌های آموزشی برچسب‌گذاری شده دستی نیاز باشد. این رویکرد بصورت خود-نظارتی (self-supervised) است: مدل فراخوانی‌های کاندید API را در موقعیت‌های محتمل در متن تولید می‌کند، آن فراخوانی‌ها را اجرا می‌کند و تنها مثال‌هایی را نگه می‌دارد که نتیجه API واقعاً پرپلکسیتی (perplexity) مدل را روی توکن‌های اطراف کاهش داده باشد. سپس از آن مجموعه داده فیلتر شده برای تنظیم دقیق (fine-tuning) استفاده می‌شود. ابزارهای آزمایش شده شامل یک ماشین حساب، دو موتور جستجو (بازیابی BM25 و جستجوی ویکی‌پدیا)، یک مدل پرسش و پاسخ (QA)، یک مترجم و یک تقویم هستند.

مدل آموزش دیده، یک مدل مبتنی بر GPT-J با ۶.۷ میلیارد پارامتر است که آن‌ها آن را Toolformer می‌نامند. این مقاله در کنفرانس NeurIPS 2023 پذیرفته شد.

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

• در مسائل ریاضی متنی (SVAMP)، مدل Toolformer 6.7B امتیاز ۲۹.۴٪ را کسب می‌کند — در حالی که خط پایه GPT-J امتیاز ۵.۲٪، مدل OPT 66B امتیاز ۴.۹٪ و GPT-3 175B امتیاز ۱۰.۰٪ را دارند. استفاده از ابزار عملاً منحنی مقیاس‌بندی معمول را برای محاسبات ریاضی درهم می‌شکند.
• در ریاضیات ASDiv، مدل Toolformer به ۴۰.۴٪ در مقابل ۷.۵٪ برای GPT-J و ۱۴.۰٪ برای GPT-3 می‌رسد؛ در MAWPS به ۴۴.۰٪ در مقابل ۹.۹٪ برای GPT-J و ۱۹.۸٪ برای GPT-3.
• در وظایف پرسش و پاسخ واقع‌گرایانه، تصویر برعکس می‌شود: GPT-3 همچنان در هر سه بنچمارک QA (شامل TriviaQA، WebQuestions، Natural Questions) علیرغم استفاده Toolformer از ابزارهای جستجو، از آن پیشی می‌گیرد. امتیاز Toolformer در TriviaQA برابر ۵۳.۵٪ در مقابل ۳۱.۹٪ خط پایه GPT-J است، اما GPT-3 بدون ابزار همچنان بالاتر است.
• خط لوله تولید داده خود-نظارتی، مثال‌های آموزشی ایجاد می‌کند که در آن مدل یاد می‌گیرد زمانی که فراخوانی API مفید نیست، آن را انجام ندهد — مرحله فیلترینگ از بهبود پرپلکسیتی به عنوان سیگنالی برای "آیا این فراخوانی ابزار واقعاً کمک کرد؟" استفاده می‌کند.
• قابلیت استفاده از ابزار تنها در مقیاس‌های بزرگ پدیدار می‌شود: مدل‌های زیر تقریباً ۷۷۵ میلیون پارامتر، حتی با همان سیگنال آموزشی، به طور قابل اعتمادی یاد نمی‌گیرند که چه زمانی ابزارها را فراخوانی کنند.
• ابزار تقویم تنها در ۰.۲٪ مواقع در وظایف استدلال زمانی فراخوانی می‌شود؛ مدل عمدتاً سوالات زمانی را به جای آن به ابزار جستجوی ویکی هدایت می‌کند.

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

بینش اصلی ماندگار است: ترفند فیلترینگ مبتنی بر پرپلکسیتی ظریف است زیرا به برچسب‌گذاری انسانی و هیچ دانای کلی که پاسخ صحیح را بداند نیاز ندارد — فقط کافی است بداند آیا نتیجه API درج شده، متن اطراف را قابل پیش‌بینی‌تر کرده است یا خیر. این یک مشارکت واقعی است و نتایج ریاضی خیره‌کننده هستند. شکست دادن GPT-3 توسط یک مدل ۶.۷ میلیاردی در ASDiv یک ترفند ارزیابی نیست؛ این یک نمایش آشکار است که یک فراخوانی صحیح ابزار، ارزشی معادل ۲۶ برابر پارامترهای بیشتر در وظایف محاسباتی دارد.

چیزی که برای من کمتر متقاعدکننده است، بخش پرسش و پاسخ (QA) است. مقاله Toolformer را به عنوان بهبوددهنده گسترده عملکرد معرفی می‌کند، اما نتایج QA نشان می‌دهد که این مدل نتوانسته GPT-3 را شکست دهد — مدلی بسیار بزرگتر بدون هیچ ابزاری. نویسندگان به این موضوع اذعان دارند، اما قاب‌بندی روایت ("اغلب با مدل‌های بسیار بزرگتر رقابت می‌کند") این واقعیت را که پیروزی چقدر انتخابی است، کمرنگ جلوه می‌دهد: مدل در وظایفی برنده می‌شود که به وضوح به یک فراخوانی واحد ماشین حساب یا جستجو تجزیه می‌شوند و در وظایفی که نیازمند استدلال واقعی روی محتوای بازیابی شده هستند، شکست می‌خورد یا برابر می‌شود.

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

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

در نهایت، ارزیابی بصورت zero-shot است. هیچ مقایسه‌ای با GPT-3 یا GPT-4 با پرامپت‌های few-shot که ابزارها در کانتکست ارائه شده‌اند انجام نشده است، روشی که ظرف چند ماه پس از این مقاله به پارادایم غالب تبدیل شد. تاریخ انتشار در NeurIPS 2023 به این معنی است که آزمایش‌ها قبل از پذیرش گسترده APIهای فراخوانی تابع (function-calling) انجام شده‌اند، که باعث می‌شود مجموعه مقایسه‌ای در زمان انتشار کمی قدیمی به نظر برسد.

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

مقاله Toolformer به سوالی پاسخ می‌دهد که برای من در Bean Labs مهم است: آیا یک مدل می‌تواند یاد بگیرد که یک API بازنویسی را به طور قابل اعتماد فراخوانی کند و با چه هزینه‌ای؟ پاسخ از نتایج ریاضی این است: "بله، اگر رابط ابزار تمیز باشد و وظیفه به یک فراخوانی واحد تجزیه شود." با این حال، حالت‌های شکست مستقیماً با سخت‌ترین بخش‌های مسئله دفترداری مطابقت دارند.

اقدامات بازنویسی Beancount — طبقه‌بندی یک تراکنش، استنتاج نگاشت حساب‌ها، تولید یک ورودی دفتر روزنامه — فراخوانی‌های تک‌مرحله‌ای ماشین حساب نیستند. آن‌ها شامل بازیابی کانتکست (ورودی‌های قبلی، نمودار حساب‌ها)، اعمال قوانین (قوانین ثبت، محدودیت‌های ارز) و تولید خروجی ساختاریافته‌ای هستند که باید از نظر سینتکسی معتبر باشد. این حداقل شامل سه فراخوانی زنجیره‌ای ابزار است و معماری Toolformer صراحتاً نمی‌تواند ابزارها را زنجیره کند. اعمال سیگنال آموزشی مبتنی بر پرپلکسیتی نیز در اینجا سخت خواهد بود: مشخص نیست "پرپلکسیتی کمتر در متن دفتر کل اطراف" چه معنایی دارد وقتی خروجی یک فایل ساختاریافته .beancount است نه یک ادامه متن به زبان طبیعی.

درس مفیدتر از Toolformer برای اهداف ما، فضای منفی آن است: یک عامل بازنویسی نمی‌تواند فقط یک مدل زبانی تنظیم‌بندی شده باشد که زمان فراخوانی API دفتر کل را حفظ کرده است. این عامل به یک لایه استدلال صریح (مانند ReAct یا مشابه آن) نیاز دارد که بتواند قبل از نهایی کردن یک ثبت، برنامه‌ریزی و اجرا کند و نتایج میانی را بررسی نماید. Toolformer ثابت می‌کند که استفاده از ابزار کار می‌کند؛ اما ثابت نمی‌کند که روی عملیات ساختاریافته و دارای عوارض جانبی (side-effecting) به طور ایمن کار می‌کند.

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

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) — مراحل استدلال زنجیره افکار صریح را با فراخوانی‌های ابزار ترکیب می‌کند؛ معماری‌ای که محدودیت زنجیره‌سازی Toolformer را برطرف می‌کند و پایه و اساس اکثر عوامل مدرن است.
• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — استفاده از ابزار را به بیش از ۱۶,۰۰۰ API واقعی از طریق مجموعه داده ToolBench مقیاس می‌دهد؛ نزدیک‌ترین چیز به تست استرس فراخوانی ابزار در سطح پیچیدگی که یک عامل حسابداری واقعی با آن روبرو می‌شود.
• FinMaster (arXiv:2505.13533) — جریان‌های کاری حسابداری انتها‌به‌انتها شامل ثبت دفتر روزنامه و مغایرت‌گیری را بنچمارک می‌کند؛ نشان خواهد داد که آیا دستاوردهایی که Toolformer در محاسبات نشان داد، به وظایف چندمرحله‌ای و محدود به طرح‌واره (schema-constrained) که برای Beancount مهم هستند، تعمیم می‌یابد یا خیر.