WildToolBench: چرا هیچ مدل زبانی بزرگی در دقت جلسات استفاده از ابزار در دنیای واقعی از ۱۵٪ فراتر نمیرود
معیارهای ارزیابی استفاده از ابزار که من دنبال میکردم — BFCL، ToolBench، τ-bench — همگی یک نقص طراحی مشترک دارند: آنها وظایف را بر اساس تصور نویسندگان معیار از کارهایی که کاربران انجام میدهند، میسازند. WildToolBench که در ICLR 2026 پذیرفته شده است، به سراغ گزارشهای واقعی کاربران میرود و میپرسد که کاربران واقعاً چه کار میکنند. پاسخ تاملبرانگیز است: ۵۷ مدل زبانی بزرگ (LLM) ارزیابی شدند و هیچکدام از دقت ۱۵ درصدی در سطح جلسه فراتر نرفتند.
مقاله
پیجی یو (Peijie Yu)، وی لیو (Wei Liu)، ایوان یانگ (Yifan Yang) و همکارانشان در علیبابا، WildToolBench (arXiv:2604.06185) را معرفی کردند؛ بنچمارکی شامل ۲۵۶ سناریوی گفتگوی چند مرحلهای با ۱۰۲۴ وظیفه که از الگوهای رفتاری واقعی کاربران استخراج شده و بر پایه حدود ۱۶۰۰ API عمومی بنا شده است. استدلال اصلی این است که بنچمارکهای موجود نه به دلیل خوب بودن مدلها، بلکه به دلیل مصنوعی بودن وظایف در حال اشباع شدن هستند. کاربران واقعی درخواستها را با هم ترکیب میکنند، زمینهای (context) را که دو مرحله قبل به اشتراک گذاشته بودند حذف میکنند و بین پرسیدن سوال ابزاری، احوالپرسی کوتاه و درخواست توضیح جابجا میشوند — گاهی اوقات همه اینها در یک پیام واحد. WildToolBench این حالتهای شکست را در سه دسته چالش ساختاریافته عملیاتی میکند و هم دقت در سطح وظیفه و هم دقت بسیار سختگیرانهتر در سطح جلسه (که مستلزم موفقیت در هر چهار وظیفه یک گفتگو است) را اندازهگیری میکند.
ایدههای کلیدی
- دقت جلسه برای اکثر مدلها به تکرقمی سقوط میکند: مدل Gemini-2.0-Flash-Thinking با ۱۴.۴۵٪ دقت جلسه پیشتاز است، Claude-4-Sonnet با ۱۲.۵۰٪ و GPT-4o با ۱۱.۷۲٪ در رتبههای بعدی هستند. گذراندن تمام وظایف در یک جلسه چهار مرحلهای به قدری دشوار است که حتی دقت ۶۰ درصدی در سطح وظیفه به دقت زیر ۱۵ درصدی در سطح جلسه تبدیل میشود — یک جریمه احتمالی تجمعی بر روی هر تعامل.
- سازماندهی ترکیبی (Compositional orchestration) جدیترین چالش است: توپولوژیهای ابزاری ترکیبی (متوالی به علاوه موازی) سقف دقت مدلهای برتر را به ۲۵٪ محدود میکنند، در حالی که این رقم برای زنجیرههای صرفاً موازی یا متوالی بین ۵۴ تا ۶۲ درصد است. وقتی یک وظیفه نیازمند یک توزیع موازی (parallel fan-out) و پس از آن یک ادغام متوالی (sequential merge) باشد، مشکل هماهنگی از توانایی فعلی هر مدلی برای مدیریت قابل اطمینان فراتر میرود.
- نیت پنهان شکافی بزرگتر از آنچه قبلاً تصور میشد است: بنچمارک WildToolBench تضمین میکند که ۱۰۰٪ وظایف شامل اطلاعات ضمنی یا بینمرحلهای باشند؛ در حالی که BFCL v3 تنها ۱۵.۷٪ را پوشش میدهد. وظایف با وابستگی دوربرد — جایی که اطلاعات مفقود شده مربوط به بیش از دو مرحله قبل است — دشوارترین نوع فرعی هستند و هیچ مدلی حتی در سطح وظیفه نتوانسته دقت ۵۰٪ را بشکند.
- انتقالهای دستورالعمل خطاها را با نرخ خطی افزایش میدهند: هر سوئیچ سیاستی اضافی (وظیفه ابزار ← چت ← شفافسازی ← وظیفه ابزار) دقت را تقریباً ۵ تا ۱۵ واحد درصد کاهش میدهد. در سه انتقال، مدلهایی که بیشترین تأثیر را پذیرفتهاند ۳۰ واحد از دست میدهند. نویسندگان این پدیده را «خود-شرطیسازی» (self-conditioning) مینامند: پاسخهای قبلی باعث سوگیری در تفسیر مدل از دستورالعملهای بعدی میشوند، به گونهای که اصلاح آن در میانه جلسه دشوار است.
- نرخ مسیر بهینه (Optimal Path Rate) زیر ۴۳٪ باقی میماند: حتی زمانی که مدلها وظایف را به درستی انجام میدهند، فراخوانیهای API اضافی مصرف میکنند. Claude-4-Sonnet بهترین نرخ مسیر بهینه را با ۴۲.۷۴٪ به دست آورده است، به این معنی که اکثریت تکمیلهای صحیح، گامهای بیشتری از حد لازم برمیدارند — که هزینهای مستقیم در تاخیر و توکن برای هر سیستم عملیاتی محسوب میشود.
- مدلهای تخصصی استفاده از ابزار ضعیفتر از مدلهای عمومی پیشرو عمل میکنند: مدلهای xLAM-2-70B و ToolACE2-8B هر دو نرخ خطای نامگذاری اشتباه تابع بیش از ۳۰٪ را ثبت کردهاند که بدتر از GPT-4o یا Claude-4-Sonnet است. به نظر میرسد تنظیم دقیق (Fine-tuning) روی مجموعهدادههای محدود استفاده از ابزار، به جای ایجاد استحکام، باعث شکنندگی مدل در هنگام مواجهه با تغییر توزیع به سمت رفتار واقعی کاربران میشود.
چه چیزی تایید میشود — و چه چیزی نه
طراحی بنچمارک در مهمترین بخشها قوی است. تمایز بین دقت در سطح وظیفه و دقت در سطح جلسه کاملاً درست است: حالتهای شکست تجمعی همان چیزی است که استقرارهای واقعی را با شکست مواجه میکند، و اکثر کارهای قبلی اعدادی را در سطح وظیفه گزارش میدهند که این موضوع را پنهان میکند. طبقهبندی چالشهای سهگانه (سازماندهی ترکیبی، نیت پنهان، انتقال دستورالعمل) دارای منطق قوی و شواهد تجربی است — منحنیهای افت عملکرد در انواع چالشها واقعی و چشمگیر هستند.
نقطه ضعف آن مقیاس است. ۱۰۲۴ وظیفه از ۲۵۶ سناریو برای یک اثر پژوهشی معتبر است، اما برای جدول امتیازاتی که قصد ردیابی ۵۷ مدل را در طول زمان دارد، کم به نظر میرسد. نویسندگان مستقیماً به این موضوع اذعان کرده و به یک خط لوله مقیاسبندی خودکار در کارهای آینده اشاره کردهاند. مسئله دیگر این است که عبارت «بر پایه گزارشهای واقعی کاربران» بار سنگینی را به دوش میکشد: وظایف نهایی تا حدودی مصنوعی هستند و توسط یک سیستم چند-عاملی از الگوهای اولیه ساخته شده و سپس توسط ارزیابهای انسانی تایید شدهاند. ادعا ریشه در واقعیت دارد اما دادهها دقیقاً همان چیزی نیست که در دنیای واقعی رخ داده — بلکه الهامگرفته از آن است. این موضوع در نحوه تفسیر لفظی سقف ۱۵ درصدی اهمیت دارد؛ اگر خط لوله تولید داده دشواریهای مصنوعی ایجاد کرده باشد که کاربران واقعی عملاً از خود نشان نمیدهند، بخشی از این شکاف ممکن است پر شود.
من همچنین نسبت به تحلیل انتقال دستورالعمل به عنوان یک ادعای معماری مشکوک هستم. مقاله آن را به یک محدودیت بنیادی نسبت میدهد، اما عدم تطابق توزیع آموزشی بین اهداف تنظیم دقیق RLHF و جلسات چند-وجهی کاربران، توضیح سادهتر و محتملتری است. این موضوع قابل حل است و ساختاری نیست.
چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد
سه حالت شکست ذکر شده دقیقاً با نحوه تعامل کاربران واقعی با یک عامل ثبت تراکنش (write-back) در Beancount مطابقت دارد. کاربر میپرسد: «ماه گذشته چقدر برای خواربار هزینه کردم، و در ضمن رسید امروز Whole Foods را هم اضافه کن» — این یک وظیفه ترکیبی است که در یک نوبت ارائه شده است. سپس ادامه میدهند: «در واقع مبلغ را ۴۷.۲۳ دلار بگذار نه ۴۲ دلار، الان چک کردم» — این یک اصلاح پارامتر است که مستلزم ردیابی وضعیت جلسه توسط عامل است. سپس میپرسند: «آیا آن دستهبندی درست است؟» — این یک درخواست شفافسازی است و عامل نباید عملیات ثبتی را که همین الان تمام کرده دوباره اجرا کند. سقف ۲۵ درصدی در سازماندهی ترکیبی مختلط و افت ۳۰ واحدی ناشی از انتقالهای دستورالعمل، دقیقاً همان حالتهای شکستی هستند که در یک عامل دفتر کل (ledger agent) در مواجهه با جلسات واقعی کاربران ظاهر میشوند.
یافتهای که نشان میدهد مدلهای تخصصی استفاده از ابزار ضعیفتر از مدلهای عمومی پیشرو عمل میکنند، به ویژه مرتبط است. اگر ما به فکر تنظیم دقیق یک مدل متنباز کوچکتر روی نمونههای فراخوانی ابزار خاص Beancount بودیم — که راهکاری بدیهی برای کاهش هزینه است — WildToolBench یک هشدار مستقیم است که تخصص ممکن است استحکام در برابر توزیع رفتارهای واقعی کاربران را قربانی کند. یافته نرخ مسیر بهینه نیز مهم است: عاملی که برای تکمیل یک وظیفه دو برابر بیشتر از API استفاده میکند، فقط ناکارآمد نیست؛ برای عملیاتهای ثبت تراکنش، فراخوانیهای میانی تکراری میتواند دفتر کل را در وضعیتهای میانی ناسازگار رها کند.
پیشنهادات برای مطالعه بیشتر
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — چارچوب آموزشی بنیادی که WildToolBench صراحتاً خود را در مقابل آن قرار میدهد؛ درک طراحی ارزیابی مصنوعی آن، دقیقاً نشان میدهد که اجرای زنده چه ارزشی را اضافه میکند.
- τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — نزدیکترین کار قبلی در زمینه استفاده واقعی از ابزار در چند مرحله؛ مقایسه دامنههای خردهفروشی/هواپیمایی در τ-bench با پوشش API عمومی در WildToolBench نشان میدهد که این چالش چقدر تعمیمپذیر است.
- AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — اگر مشکل انتقال دستورالعمل از طریق کشف خودکار جریانهای کاری بهتر برای عاملها (به جای مقیاسبندی دادههای آموزشی) قابل حل باشد، AFlow معتبرترین مکانیسم برای انجام این کار است.
