محک TOOLCALL-300: نرخ شکست ۹۶.۷ درصدی مدل‌های زبانی در فراخوانی ابزارها

اگر امروز یک عامل هوش مصنوعی را مستقیماً به سرورهای عملیاتی خود متصل کرده‌اید، احتمالاً با بمب‌های ساعتی در لایه اجرا رو‌به‌رو هستید. طبق گزارشی که در ۱۹ اوت ۲۰۲۶ توسط Toolkit Labs منتشر شد، یک آداپتور (Adapter) ساده — که صرفاً خروجی را تجزیه کرده و بدون اصلاح ارسال می‌کند — در محک جدید TOOLCALL-300 تنها ۱۰ امتیاز از ۳۰۰ کسب کرد. این یعنی در ۹۶.۷٪ موارد، وقتی مدل از طرحواره (Schema) منحرف می‌شود، ارسال مستقیم خروجی‌های خام LLM به یک اجراکننده تابع (Function Runner) با شکست مواجه می‌شود.

بسیاری از توسعه‌دهندگان تصور می‌کنند وقتی مدلی «قابلیت استفاده از ابزار» دارد، خروجی JSON آن لزوماً قابل استفاده است. در واقعیت، مدل‌ها مدام خروجی‌هایی تولید می‌کنند که «نزدیک به درست» (Near Misses) هستند؛ یعنی در ظاهر شبیه دستورات معتبر برای سرور به نظر می‌رسند اما با طرحواره تعریف‌شده در تضاد هستند. این موضوع یک شکاف خطرناک ایجاد می‌کند؛ جایی که ناتوانی مدل در تولید یک فراخوانی قابل استفاده، توسط سرور به عنوان «فراخوانی بدون آرگومان» تفسیر می‌شود و می‌تواند منجر به اجرای دستورات ناخواسته و خطرناک در سرور گردد. این آسیب‌پذیری‌ها دقیقاً همان نقاط ضعفی هستند که در بررسی امنیتی عامل‌های هوش مصنوعی به عنوان مسیرهای احتمالی نشت داده‌ها و اجرای غیرمجاز شناسایی شده‌اند.

همان‌طور که در تحلیل قبلی ما درباره‌ی لایه‌های حافظه پنهان (Caching) و کاهش هزینه‌های استنتاج اشاره کردیم، اکنون تمرکز صنعت از بهینه‌سازی هزینه به سمت قابلیت اطمینان لایه اجرا تغییر کرده است. بدون یک لایه نرمال‌ساز (Normalizer) قدرتمند، تمام هوشمندی یک عامل (Agent) — شبیه به یک مدیر باهوش که دستوراتش را روی کاغذهای پاره و نامفهوم می‌نویسد — توسط شکنندگی خروجی‌های JSON محدود می‌شود.

کالبدشکافی شکست‌ها

محک TOOLCALL-300 شامل ۳۰۰ فراخوانی برچسب‌گذاری‌شده است که به ۱۲ دسته از خطاهای رایج تقسیم شده‌اند. هر دسته ۲۵ مورد را پوشش می‌دهد تا دقیقاً نقاط ضعف مدل‌ها در رعایت طرحواره‌ها شناسایی شود. این دسته‌ها بر روی رایج‌ترین روش‌های شکست LLMها در رعایت طرحواره ابزارها تمرکز دارند:

• نام‌گذاری و آرگومان‌ها: شامل wrong_tool_name (نام اشتباه ابزار)، missing_required_arg (نبود آرگومان‌های ضروری) و extra_undeclared_arg (افزودن آرگومان‌های تعریف‌نشده).
• یکپارچگی داده‌ها: خطاهایی مثل type_coercion (اجبار نوع)، enum_violation (نقض مقادیر Enum) و array_vs_scalar (جابجایی آرایه با مقدار تک‌مقدار).
• خطاهای ساختاری: شامل nested_flattened (ساختارهای تو در تو یا تخت‌شده)، args_as_string (ارسال آرگومان‌ها به صورت رشته متنی) و multiple_calls (فراخوانی‌های چندگانه).
• شکست‌های بحرانی: شامل hallucinated_tool (توهم ابزار)، خروجی‌های truncated (بریده‌شده) و خطاهای unrecoverable (غیرقابل بازیابی).

از این ۳۰۰ مورد، ۵۰ مورد اصلاً فراخوانی درستی ندارند. در این موارد، تنها نمره قبولی برای مدل «امتناع از پاسخ» (Refusal) است. اگر مدل خروجی {"name": ..., "arguments": {}} برگرداند، این مورد به عنوان شکست ثبت می‌شود، نه یک پاسخ نزدیک به درست.

عملکرد گروه کنترل

آداپتور ساده‌ای که هیچ اصلاحی روی خروجی انجام نمی‌دهد (Naive Control Adapter)، ریسک ادغام مستقیم را به رخ می‌کشد. در ۲۵۰ موردی که امکان بازیابی فراخوانی وجود داشت، این آداپتور نمره صفر گرفت. اما در ۵۰ موردی که پاسخ درست «عدم وجود فراخوانی» بود، این سیستم ۴۰ بار دستور را به سرور ارسال کرد؛ این شامل تمام ۲۵ موردی است که مدل ابزارهایی را فراخوانی کرده بود که اصلاً تعریف نشده بودند. این نرخ بالای خطا یادآور بحران کاربردپذیری در سرورهای MCP است که در آن بسیاری از زیرساخت‌های ارتباطی با عامل‌ها، استانداردهای لازم برای اجرای بدون خطا را ندارند.

تمام امتیازات این گروه کنترل از خروجی‌هایی به دست آمد که آن‌قدر خراب بودند که اصلاً تجزیه (Parse) نشدند. این موضوع دقیقاً همان رفتاری را نشان می‌دهد که این محک می‌سنجد: تمایل سیستم‌ها به تبدیل «عدم تولید فراخوانی قابل استفاده» به «فراخوانی ابزاری با آرگومان‌های خالی».

محک نرمال‌ساز

برای ارائه راهکار، Toolkit Labs یک نرمال‌ساز مرجع به نام toolshim.py را معرفی کرد. این آداپتور نمره ۲۹۳ از ۳۰۰ (۹۷.۷٪) را کسب کرد. در این نتایج، ۴۹ مورد از ۵۰ امتناع درست بود، هیچ امتناع اشتباهی رخ نداد و تنها ۱ فراخوانی ساختگی (Invented Call) وجود داشت. نویسنده تأکید می‌کند که این عدد مربوط به داده‌های داخل نمونه (In-sample) است و باید به عنوان معیاری برای توافق با قوانین (Rulebook) دیده شود، نه یک ادعای کلی درباره عملکرد در دنیای واقعی.

حتی این نرمال‌ساز مرجع هم در ۷ مورد خاص شکست خورد که نشان‌دهنده دشواری مدیریت جریان‌های بریده‌شده (Truncated Streams) است. در حالی که ۱۰ دسته از ۱۲ دسته نمره کامل (۲۵/۲۵) گرفتند، شکست‌ها در دسته‌های «بریده‌شده» (۱۹/۲۵) و «غیرقابل بازیابی» (۲۴/۲۵) رخ داد.

تحلیل شکست‌های لبه‌ای

این هفت مورد شکست در مستندات پروژه (README) بدون اصلاح رها شده‌اند تا نتایج به ادعای تبلیغاتی تبدیل نشود. این خطاها به سه دسته تقسیم می‌شوند:

• کانتینرهای ساختگی (۴ مورد): جریان متن در جایی مثل "tags": [ متوقف شد و نرمال‌ساز آن را به صورت [] بست. چون آرایه خالی در سرور به معنای «پاک کردن فیلد» است و نه «نبود مقدار»، این یک شکست محسوب می‌شود.
• عناصر بسته نشده (۲ مورد): یک عنصر کامل در آرایه‌ای قرار داشت که هرگز بسته نشد (مثلاً "tags": [ "regression" به ["regression"] تبدیل شد). این مجموعه داده خوانشی سخت‌گیرانه دارد و معتقد است که ویژگی به طور کامل نوشته نشده است.
• بریدگی در میان ارقام (۱ مورد): عددی در میان ارقامش قطع شد (مثلاً "days": 1 در حالی که عدد اصلی می‌توانست ۱۲ یا ۱۴ باشد). این بدترین نوع شکست است چون خروجی معتبر و پذیرفتنی است و هیچ لایه‌ای در پایین‌دست نمی‌تواند آن را تشخیص دهد.

پیاده‌سازی و نظام نمره‌دهی

قوانین نمره‌دهی در این مجموعه بسیار سخت‌گیرانه است. نام ابزارها تنها زمانی پذیرفته می‌شوند که پس از حذف پیشوندهای فضای نام (Namespace)، فاصله‌ها، پرانتزهای انتهایی ()، تفاوت‌های حروف کوچک و بزرگ و تفاوت‌های بین خط تیره، زیرخط و فاصله، دقیقاً با یکی از ابزارهای تعریف‌شده مطابقت داشته باشند. سیستم هرگز «نزدیک‌ترین عضو» (Closest-looking member) را نمی‌پذیرد و همین منطق برای Enumها نیز جاری است.

سایر قوانین سخت‌گیرانه عبارتند از:

• اجبار نوع (Coercion): تنها در صورتی مجاز است که بدون تلفات و بازگشت‌پذیر باشد (مثلاً تبدیل رشته "3" به عدد ۳، یا ۳.۰ به ۳).
• ویژگی‌های ضروری: مقادیر مفقود تنها از مقادیر پیش‌فرض خودِ طرحواره (Schema) پر می‌شوند و از هیچ منبع دیگری.
• ویژگی‌های تعریف‌نشده: این ویژگی‌ها به طور کامل حذف می‌شوند.
• بریدگی (Truncation): سیستم آنچه را که کامل نوشته شده نگه می‌دارد، دنباله ناقص را حذف می‌کند، کانتینرهای باز را می‌بندد و هیچ مقداری را اختراع نمی‌کند.

تمام موارد توسط generate.py و بر اساس قالب‌ها و قوانین جهش (Mutation) ساخته شده‌اند. داده مرجع (Ground Truth) از طریق ساختار اولیه تولید شده است، به این معنی که فراخوانی مورد انتظار پیش از متن خراب وجود داشته و هیچ تجزیه‌کننده‌ای برای یافتن پاسخ درست مورد استفاده قرار نگرفته است.

تست کد شخصی

توسعه‌دهندگان می‌توانند کد خود را با یک نمونه رایگان ۳۰ موردی تست کنند. این مجموعه در قالب یک فایل zip با حجم ۳۵,۴۴۵ بایت و هش sha256 a9284eb4304f5eb265ba4c55844513cbba0c0d3cd9aebe235b51c3071ed4fa03 ارائه شده است.

برای اجرای محک، از دستورات زیر استفاده کنید:
curl -O https://toolkitlabs.org/toolcall300/toolcall300-free.zip
unzip toolcall300-free.zip && cd toolcall300-free
python3 score.py --corpus sample30.jsonl --adapter naive

این مجموعه از آداپتورهای غیر پایتونی نیز از طریق پرچم --adapter-cmd پشتیبانی می‌کند. این پرچم یک زیرپردازش (Subprocess) را اجرا می‌کند که ورودی {"text": ..., "tools": [...]} را از stdin می‌خواند و انتظار دارد فراخوانی نهایی در stdout باشد. خروج با کد غیر صفر یا stdout خالی به عنوان «امتناع» (Refusal) تلقی می‌شود.

ابزار score.py در صورت شناسایی رگرسیون (پسرفت) نسبت به یک خط پایه ذخیره شده، با کد ۲ خارج می‌شود. این موضوع حیاتی است زیرا به‌روزرسانی مدل یا تغییر وابستگی‌ها می‌تواند دقت آداپتور را بدون فعال شدن تست‌های واحد (Unit Tests) به طور خاموش از ۹۷٪ به ۸۸٪ کاهش دهد.

هزینه قابلیت اطمینان

در حالی که نمونه ۳۰ موردی رایگان است (تحت لایسنس CC0)، مجموعه کامل ۳۰۰ موردی یک محصول تجاری است. لایسنس تک‌کاربره ۲۹ یورو و لایسنس تیمی یا CI ۹۹ یورو قیمت دارد. این مجموعه کامل شامل دلیل برچسب‌گذاری (Label Rationale) برای هر شکست است که به تیم‌ها اجازه می‌دهد دقیقاً بفهمند چرا عامل آن‌ها شکست می‌خورد.

این چرخش به سمت مجموعه‌های ارزیابی تجاری و با دقت بالا نشان می‌دهد که صنعت از بنچمارک‌های کلی به سمت تست‌های «لبه‌ای» (Edge-case) برای عامل‌های در سطح تولید (Production-grade) حرکت می‌کند. برای پیاده‌سازی عملی این رویکرد، می‌توان از متدهایی مشابه پلتفرم SpaceAI360 استفاده کرد که با ترکیب Zod و لایه‌های پاک‌سازی، توقف‌های ناگهانی API را به دلیل خطاهای ساختاری JSON حذف می‌کند.

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

برای اطمینان از اینکه عامل‌های شما آماده تولید هستند، باید یک خط لوله تست رگرسیون (Regression-testing pipeline) ایجاد کنید که صحت فراخوانی ابزارها را در هر به‌روزرسانی نسخه مدل مانیتور کند.

گام بعدی شما

• نمونه رایگان ۳۰ موردی TOOLCALL-300 را روی آداپتور فعلی خود اجرا کنید تا نرخ شکست‌های ساکت را بسنجید.
• یک خط لوله تست رگرسیون (Regression Testing) ایجاد کنید که با هر به‌روزرسانی مدل، صحت فراخوانی ابزارها را مانیتور کند.
• لایه‌ای برای نرمال‌سازی خروجی‌های JSON اضافه کنید که بر اساس طرحواره (Schema)، مقادیر ناقص را اصلاح یا رد کند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.