آیا داده‌های پاسخ‌محور محدودیت مدل‌های کوچک در استفاده از ابزار را می‌شکنند؟

تصور کنید یک برنامه‌نویس بخواهد عاملی بسازد که بدون خطا با ده‌ها API مختلف تعامل کند، اما متوجه شود مدل‌های کوچک همواره در میانه راه گم می‌شوند. نرخ موفقیت ۹۹.۸ درصدی که تیم پژوهشی گوگل در همکاری با دانشگاه توکیو، RIKEN AIP و دانشگاه توهoku به آن دست یافته، دقیقاً همین بن‌بست را می‌شکند. این نتیجه در واقع ناکارآمدی آموزش سنتی عامل‌های هوش مصنوعی را با وارونه کردن خط لوله داده‌ها حل کرده است: پژوهشگران روشی را توسعه دادند که در آن هوش مصنوعی ابتدا یک زنجیره ابزاری موفق را اجرا می‌کند و تنها پس از آن، پرسش کاربر متناظر با آن را می‌نویسد.

زمینه و بستر آموزش استفاده از ابزار

بیشتر سیستم‌های فعلی از دستورالعمل «ابتدا پرسش» (query-first) پیروی می‌کنند؛ نمونه‌هایی مانند ToolBench و ToolACE از این روش استفاده می‌کنند. در این رویکرد، از یک مدل زبانی بزرگ (LLM) خواسته می‌شود تا یک دستور کاربر را ابداع کند و سپس از یک عامل جست‌وجوی اول-عمق (DFS) برای یافتن مسیری به سوی پاسخ استفاده نماید. این چالش‌ها در واقع بخشی از محدودیت‌های بنیادین مدل‌های زبانی در انجام وظایف ساده هستند که پیش‌تر به آن‌ها پرداخته‌ایم. همان‌طور که در به‌روزرسانی‌های دیگر اکوسیستم گوگل، مانند گسترش اپلیکیشن Gemini به ویندوز دیدیم، هدف نهایی ایجاد ادغامی بی‌نقص میان هوش مصنوعی و نرم‌افزارهاست.

با این حال، روش «ابتدا پرسش» اغلب به بن‌بست می‌رسد. وقتی جست‌وجو شکست می‌خورد، تمام توان محاسباتی صرف شده برای اکتشاف تلف شده و آن نمونه داده دور ریخته می‌شود. پژوهشگران این وضعیت را به عنوان یک فرآیند ناکارآمد در استخراج مسیرها از اکتشافات یک عامل شکست‌خورده توصیف می‌کنند.

سیستم ToolGrad این رویکرد را با یک حلقه چهار ماژوله جایگزین می‌کند که تضمین می‌کند هر نمونه داده حتماً کاربردی باشد. این فرآیند خط لوله را معکوس می‌کند: ابتدا با اجرای واقعی APIها، یک زنجیره استفاده از ابزار (ground-truth) می‌سازد و سپس آن زنجیره را با یک پرسش کاربر متناسب برچسب‌گذاری می‌کند. از آنجایی که یک زنجیره فعال و موفق، بسیار کمتر از یک دستور فرضی ابهام دارد، مرحله تبدیل زنجیره به پرسش تنها به یک فراخوانی LLM نیاز دارد.

جزئیات فنی حلقه ToolGrad

در هر تکرار، چهار ماژول به‌صورت متوالی اجرا می‌شوند تا یک نمونه شامل پرسش کاربر، یک گردش‌کار تأییدشده API و یک پاسخ نهایی تولید کنند:

• پیشنهاددهنده API (API Proposer): مجموعه‌ای از APIهای نمونه‌برداری شده را محدود کرده و چند کاندیدای احتمالی را که می‌توانند گردش‌کار فعلی را گسترش دهند، انتخاب می‌کند.
• مجریان API (API Executors): این کاندیداها را به‌صورت موازی اجرا کرده و گزارش‌های دقیقی از نتایج اجرا تولید می‌کنند.
• انتخاب‌گر API (API Selector): گزارش‌ها را بررسی کرده، تنها یک فراخوانی با بهترین عملکرد را انتخاب می‌کند و آن را به گردش‌کار می‌افزاید. این بازخورد جهت‌دار در واقع به عنوان «گرادیان متنی» عمل می‌کند.
• به‌روزرسانی‌کننده LLM (LLM Updater): پرسش کاربر مصنوعی و پاسخ هوش مصنوعی را بازنویسی می‌کند تا با مجموعه جدید APIها مطابقت داشته باشند.

پیکربندی پیش‌فرض این مخزن (Repository)، ۱۰ تکرار را روی ۵۰ API نمونه‌برداری شده برای هر گردش‌کار اجرا می‌کند.

طبق مقاله پژوهشی، این تغییر رویکرد نتایج خیره‌کننده‌ای در پایگاه داده ToolBench (شامل بیش از ۱۶,۰۰۰ API واقعی) داشت:

• نرخ موفقیت از ۶۳.۸٪ (در روش DFS) به ۹۹.۸٪ جهش کرد.
• میانگین تعداد ابزارهای استفاده‌شده در هر نمونه (ground-truth) از ۲.۱ به ۳.۴ افزایش یافت که منجر به ایجاد زنجیره‌های طولانی‌تر شد.
• تعداد مراحل استفاده از ابزار در هر نمونه از ۳۴.۳ به ۲۰.۰ کاهش پیدا کرد.
• تعداد فراخوانی‌های LLM در هر نمونه کاهش اندکی داشت و از ۶۴.۵ به ۶۳.۹ رسید.

تنها موارد شکست (۰.۲٪) زمانی رخ داد که عامل نتوانست در تمام ۱۰ تکرار، پاسخی موفق از سه API منتخب دریافت کند.

برای آزمایش این چارچوب، تیم پژوهشی مجموعه داده ToolGrad-500 را تولید کرد؛ مجموعه‌ای شامل تنها ۵۰۰ نمونه که توسط مدل Gemini 2.5 Flash-Lite ساخته شده بود. آن‌ها از این داده‌ها برای آموزش تکمیلی (Post-train) مدل‌های Gemma-3 در ابعاد ۱، ۴ و ۱۲ میلیارد پارامتر استفاده کردند.

در جدول رده‌بندی فراخوانی توابع برکلی (BFCL) — که به عنوان یک تست توزیع‌نشده (out-of-distribution) با ابزارهای دیده‌نشده عمل می‌کند — مدل ToolGrad-12B امتیاز ۸۳.۱ را کسب کرد. این عدد مدل ۱۲ میلیاردی را در رقابتی مستقیم با غول‌های تجاری قرار می‌دهد: Gemini 2.5 Pro امتیاز ۸۳.۲، Claude 4.5 Opus امتیاز ۸۲.۸ و GPT-5 در زمان انتشار مقاله امتیاز ۷۴.۴ را کسب کرده بودند. به‌طور قابل توجهی، این مدل دانش‌آموز ۱۲ میلیاردی از معلم خود (Gemini 2.5 Flash-Lite) پیشی گرفت و بر سایر مدل‌های تخصصی باز مانند ToolACE و Hammer-2.1-7B برتری یافت.

این نتیجه، این فرض را که برای تخصص در استفاده از ابزار به مجموعه‌داده‌های عظیم نیاز است، تغییر می‌دهد. این پژوهش ثابت می‌کند که مقدار اندکی داده‌ی کاملاً تأییدشده، بسیار ارزشمندتر از هزاران مسیر فرضی و نویزی است. برای توسعه‌دهندگان، این بدان معناست که قابلیت‌های پیشرفته عامل‌محور را می‌توان اکنون در مدل‌های کوچک با وزن‌های باز (Open Weights) جای‌گذاری کرد که قابلیت استقرار سریع دارند.

این پروژه به‌طور کامل برای پیاده‌سازی باز است. کدها تحت مجوز Apache-2.0 منتشر شده‌اند و مدل‌ها و مجموعه‌داده‌ها از طریق یک بسته PyPI در Hugging Face در دسترس هستند. اسکریپت‌های بازتولید، نسخه‌های V1 و V2 از BFCL را از طریق یک فورک سفارشی هدف قرار داده و استنتاج را در یک تصویر Docker vLLM اجرا می‌کنند.

گام بعدی شما

• مدل ToolGrad-12B را روی یک GPU تک‌هسته‌ای NVIDIA A100 (۴۰ گیگابایت) مستقر کنید تا ببینید آیا گردش‌کارهای API اختصاصی شما را بهتر از جایگزین‌های تجاری بزرگتر مدیریت می‌کند یا خیر.
• مستندات ToolGrad در Hugging Face را برای تبدیل داده‌های نویزی خود به داده‌های تأییدشده بررسی کنید.
• عملکرد مدل‌های کوچک آموزش‌دیده با ToolGrad را در برابر مدل‌های تجاری در محیط‌های عملیاتی مقایسه کنید.

اما بهینه‌سازی هزینه استنتاج در این مدل‌های کوچک حتی جذاب‌تر است — به تحلیل ما درباره‌ی کاهش هزینه‌های Inference در مدل‌های لبه مراجعه کنید، مشابه آنچه در رویکرد EarlyEval برای کاهش مصرف توکن‌ها مشاهده شد.