در طراحی سیستمهای مبتنی بر مدلهای زبانی بزرگ، فراخوانی سادهی یک تابع در یک مرحله دیگر چالشی جدی به حساب نمیآید. چالش واقعی توسعهدهندگان ساخت سیستمهایی است که بتوانند در طول چندین مرحله، ابزارهای مختلف را با اسکیمای دقیق صدا بزنند، دادهها را میان مراحل حفظ کنند و در صورت بروز خطا مسیرشان را اصلاح نمایند.
اگر از ایران با ارائهدهندگانی مثل OpenAI یا Anthropic کار میکنید، محدودیتهای دسترسی بر پایهی IP و موانع پرداخت ارزی معمولاً استفادهی پایدار از APIها را دشوار میسازد. در این سناریوها، تسلط بر منطق رجیستری ابزار و ارسال خطاهای ساختاریافته اهمیت دوچندانی دارد؛ زیرا هر فراخوانی ناموفق یا اشتباه، هزینه و تاخیر شبکه را افزایش میدهد.
در این درس یاد میگیرید که چگونه یک رجیستری اختصاصی برای ابزارها در پایتون بسازید، اسکیمای ورودیها را اعتبارسنجی کنید و با بهکارگیری اصولی مانند اجرای موازی و ساندباکس، ایجنتهایی پایدار و مقاوم در برابر توهم پیادهسازی کنید.
مقالهی Toolformer (شیک و همکاران، 2023) نقطهی آغاز نشانهگذاری خودنظارتی ابزارها بود. لیدربورد فراخوانی تابع برکلی نسخه 4 (BFCL V4؛ پاتیل و همکاران، 2025) استاندارد ارزیابی سال 2026 را تعیین کرده است: 40% رفتار ایجنتی، 30% چندنوبته، 10% دادههای زنده، 10% دادههای غیرزنده و 10% توهم. مسئلهی فراخوانی در یک نوبت حل شده است؛ اما حافظه، تصمیمگیری پویا و زنجیرههای ابزاری طولانیمدت هنوز حلنشده باقی ماندهاند.
اهداف یادگیری
- توضیح سیگنال آموزشی خودنظارتی در Toolformer: حفظ نشانهگذاری ابزارها صرفاً در صورتی که اجرای آنها تابع زیان (loss) توکن بعدی را کاهش دهد.
- نام بردن پنج دستهی ارزیابی BFCL V4 و معیارهای سنجش هر کدام.
- پیادهسازی رجیستری ابزار با کتابخانهی استاندارد پایتون (stdlib) شامل اعتبارسنجی اسکیمای JSON، تبدیل اجباری نوع ورودیها (argument coercion) و ساندباکس (محیط ایزوله) اجرا.
- تحلیل سه چالش حلنشده در سال 2026: زنجیرهسازی ابزارها در افقهای زمانی طولانی، تصمیمگیری پویا و حافظه.
صورت مسئله
در روزهای نخست فراخوانی ابزار، پرسش این بود: آیا مدل میتواند فراخوانی یک تابع را درست پیشبینی کند؟ در رویکرد نوین، پرسش تغییر کرده است: آیا مدل میتواند ابزارها را در طول 40 مرحله به هم زنجیر کند، حافظه را نگه دارد، با مشاهدهپذیری ناقص (partial observability) کنار بیاید، از خطاهای ابزار جان سالم به در ببرد و ابزارهایی را که اصلاً وجود ندارند توهم نکند؟
مقالهی Toolformer خط مبنا را مشخص کرد: مدلها میتوانند با یادگیری خودنظارتی بفهمند چه زمانی باید ابزارها را فراخوانی کنند. BFCL V4 نیز هدف ارزیابی سال 2026 را تعریف میکند. فاصلهی بین این دو نقطه، همان فضایی است که ایجنتهای سطح تولید در آن کار میکنند.
مفاهیم پایه
مدل Toolformer (شیک و همکاران، NeurIPS 2023)
ایده این است: به مدل اجازه دهیم متنهای پیکرهی پیشآموزش خود را با فراخوانیهای پیشنهادی API نشانهگذاری کند. سپس هر پیشنهاد را اجرا کنیم. تنها در صورتی این نشانهگذاری را نگه میداریم که گنجاندن خروجی ابزار، مقدار تابع زیان (loss) را روی توکن بعدی کاهش دهد. در نهایت، مدل را روی این پیکرهی فیلترشده فاینتیونینگ میکنیم.
ابزارهای تستشده عبارت بودند از: ماشینحساب، سیستم پرسش و پاسخ، موتورهای جستوجو، مترجم و تقویم. سیگنال خودنظارتی کاملاً بر این مبنا استوار است که آیا ابزار به پیشبینی متن کمکی میکند یا نه؛ بدون نیاز به هیچ برچسبگذاری انسانی.
نتیجهی حاصل از مقیاس: توانایی فراخوانی ابزار در مقیاسهای بزرگ ظهور میکند. مدلهای کوچکتر با اضافه شدن این نشانهگذاریها دچار افت عملکرد میشوند، در حالی که مدلهای بزرگتر رشد میکنند. به همین دلیل است که در سال 2026 مدلهای پیشرو این مهارت را بهطور پیشفرض در خود دارند، اما اکثر مدلهای 7B برای رسیدن به قابلیت اطمینان، همچنان به فاینتیونینگ اختصاصی فراخوانی ابزار نیازمندند.
لیدربورد فراخوانی تابع برکلی نسخه 4 (پاتیل و همکاران، ICML 2025)
لیدربورد BFCL استاندارد ارزیابی عملی در سال 2026 به شمار میرود. ساختار V4 به این شرح است:
- ایجنتی (40%) — مسیرهای کامل رفتار ایجنت: حافظه، تعامل چندنوبته، تصمیمگیری پویا.
- چندنوبته (30%) — گفتوگوهای تعاملی به همراه زنجیرههایی از ابزارها.
- زنده (10%) — پرامپتهای واقعی ارسالشده از سوی کاربران (توزیع دادهای سختتر).
- غیرزنده (10%) — سناریوهای آزمون سنتتیک.
- توهم (10%) — تشخیص موقعیتهایی که نباید در آنها هیچ ابزاری فراخوانی شود.
در نسخهی V3 ارزیابی بر پایهی وضعیت (state-based) معرفی شد: پس از اجرای زنجیرهای از ابزارها، وضعیت واقعی API بررسی میشود (مثلاً «آیا فایل ساخته شده است؟») به جای آنکه صرفاً درخت نحو انتزاعی (AST) فراخوانیها با الگو مقایسه شود. نسخهی V4 دستههای جستوجوی وب، حافظه و حساسیت به قالب داده را نیز اضافه کرد.
یافتهی کلیدی سال 2026: فراخوانی تابع در یک نوبت تقریباً یک مسئلهی حلشده است. خطاها عمدتاً در این بخشها متمرکز شدهاند: حافظه (انتقال بافت در طول نوبتها)، تصمیمگیری پویا (انتخاب ابزار بر اساس نتایج قبلی)، زنجیرههای طولانیمدت (انحراف مدل پس از بیش از 20 مرحله) و تشخیص توهم (امتناع از فراخوانی وقتی هیچ ابزاری مناسب نیست).
اسکیمای ابزار
هر ارائهدهندهای اسکیمای خاص خود را دارد. جزئیات آنها متفاوت است اما ساختار کلی یکسانی دارند:
name: string
description: string (what it does, when to use it)
input_schema: JSON Schema (properties, required, types, enums)
شرکت Anthropic مستقیماً از input_schema استفاده میکند. شرکت OpenAI کلید function.parameters را به کار میبرد. هر دو نیز JSON Schema را میپذیرند. توضیحات (descriptions) نقش حیاتی و باربر دارند؛ مدل بر اساس همین توضیحات ابزار درست را انتخاب میکند. توضیحات ضعیف، علت ریشهای شماره یک در خطای «انتخاب ابزار اشتباه» هستند.
اعتبارسنجی ورودیها
به هیچ فراخوانی ابزاری اعتماد نکنید. همواره این موارد را بسنجید:
- تبدیل اجباری نوع داده (Type coercion): ممکن است مدل رشتهی "5" را برگرداند، در حالی که اسکیما عدد صحیح (int) خواسته است. اگر تبدیل بدون ابهام است آن را تغییر دهید؛ در غیر این صورت درخواست را رد کنید.
- اعتبارسنجی مقادیر مجاز (Enum validation): اگر اسکیما مقدار
status in {"open", "closed"}را مشخص کرده و مدل"in_progress"فرستاده است، درخواست را با خطایی توصیفی رد کنید. - فیلدهای اجباری: نبود فیلد اجباری نباید برنامهتان را متوقف کند؛ بلکه باید بلافاصله یک خطای ساختاریافته در قالب مشاهده (observation) به مدل بازگرداند.
- اعتبارسنجی قالب داده: تاریخها، ایمیلها و نشانیهای URL را با پارسرهای واقعی و مشخص اعتبارسنجی کنید، نه با الگوهای Regex.
هر شکست در اعتبارسنجی باید یک مشاهدهی ساختاریافته بازگرداند تا مدل بتواند با ساختار درست تلاش خود را تکرار کند.
فراخوانیهای موازی ابزار
ارائهدهندگان امروزی از فراخوانیهای موازی ابزار در یک نوبت گفتوگو پشتیبانی میکنند. چرخهی کار به این صورت است:
- مدل سه فراخوانی ابزار با شناسههای متمایز
tool_use_idصادر میکند. - محیط اجرا آنها را اجرا میکند (اگر مستقل از هم باشند، به شکل موازی).
- هر نتیجه در قالب یک بلوک
tool_resultبازمیگردد که با شناسهیtool_use_idنظیر به نظیر پیوند خورده است.
یک قاعدهی مهندسی: شناسههای تطبیق (correlation IDs) ستون فقرات فرایند هستند. اگر آنها را جابهجا کنید، نتیجهی یک ابزار به ابزار دیگری نسبت داده میشود.
ساندباکس (محیط ایزوله)
محل اجرای ابزار همان مرز ساندباکس است. برای جزئیات به بخش 26 از فاز 13 مراجعه کنید. خلاصهی ماجرا: هر ابزار باید دامنهی خواندن و نوشتن، دسترسی به شبکه، مهلت زمانی (timeout) و سقف حافظهی مشخصی داشته باشد. استفاده از یک تابع همهمنظورهی run_shell(cmd) نشانهی خطری بزرگ است؛ اما تابعی دقیق مثل git_status() امنتر محسوب میشود.
پیادهسازی از صفر
فایل code/main.py یک رجیستری ابزار با استانداردهای سطح تولید پیاده میکند:
- اعتبارسنجی زیرمجموعهای از JSON Schema (صرفاً با کتابخانهی استاندارد).
- ثبت ابزار همراه با توضیحات، اسکیمای ورودی، مهلت زمانی و تابع اجراکننده.
- تبدیل اجباری ورودیها و اعتبارسنجی مقادیر مجاز (enum).
- هدایت و ارسال موازی ابزارها با شناسههای پیگیری.
- ثبت خطاهای مشاهده به شکل رشتههای ساختاریافته.
برای اجرا:
python3 code/main.py
ردگیری محاسبات (trace) نشان میدهد که یک مینیایجنت سه ابزار را در یک نوبت فراخوانی میکند؛ یکی از این فراخوانیها عمداً اشتباه فرستاده شده تا با یک پیام خطای توصیفی رد شود و مدل بتواند بر اساس آن مسیرش را اصلاح کند.
استفاده از ابزارهای واقعی
هر ارائهدهندهای اسکیمای ابزار خودش را دارد؛ از Anthropic و OpenAI گرفته تا Gemini و Bedrock. اگر به پشتیبانی همزمان از چند ارائهدهنده نیاز دارید، یک لایهی تبدیل مثل OpenAI Agents SDK، Vercel AI SDK یا مبدل ابزار LangChain به کار ببرید. بنچمارک BFCL مرجع اصلی است؛ اگر فراخوانی ابزار بخش اصلی محصول شماست، پیش از ارائهی نهایی مدل، آن را با این بنچمارک بسنجید.
خروجی این درس
فایل outputs/skill-tool-registry.md یک کاتالوگ ابزار، اسکیما و رجیستری برای حوزهی کاری مدنظرتان تولید میکند. این خروجی شامل ارزیابی کیفیت توضیحات نیز هست (آیا توضیحات هر ابزار برای مدل مشخص میکند که چه زمانی باید از آن استفاده کند؟).
تمرینها
- ابزاری با رفتار بدون عملیات («no-op») اضافه کنید تا مدل بتواند صریحاً از فراخوانی هرگونه ابزار دیگری امتناع کند. عملکرد آن را در تستی شبیه به ارزیابی توهم BFCL بسنجید.
- تبدیل اجباری نوع داده را برای مقادیر عددی صحیح و اعشاری که به شکل رشته آمدهاند پیاده کنید. این تبدیل از چه نقطهای به بعد، خطاهای واقعی برنامه را پنهان میکند؟
- برای هر ابزار یک مهلت زمانی (timeout) و یک مدارشکن (قطع دسترسی به ابزار به مدت 60 ثانیه پس از 3 بار شکست متوالی) بسازید. این کار رفتار مدل را در بازیابی پس از خطا چه تغییری میدهد؟
- مستندات BFCL V4 را بخوانید. یکی از دستهها (مثل «چندنوبته») را انتخاب کنید و 10 پرامپت نمونه را به ایجنت خود بدهید. در نهایت، نرخ قبولی (Pass Rate) را گزارش کنید.
- اعتبارسنج استاندارد خود را به Pydantic یا Zod منتقل کنید. کتابخانههای Pydantic یا Zod چه خطاهایی را پیدا کردند که اعتبارسنج سادهی شما ندیده بود؟
اصطلاحات کلیدی
| اصطلاح | در گفتوگوهای عامیانه | معنای دقیق فنی |
|---|---|---|
| Function calling | «استفاده از ابزار» | فراخوانی ابزار با خروجی ساختاریافته و اسکیمای اعتبارسنجیشده |
| Toolformer | «نشانهگذاری خودنظارتی ابزار» | مقالهی شیک 2023 — حفظ فراخوانیهایی که نتیجهشان تابع زیان (loss) توکن بعدی را کاهش میدهد |
| BFCL | «لیدربورد فراخوانی تابع برکلی» | بنچمارک سال 2026: 40% ایجنتی، 30% چندنوبته، 10% دادهی زنده، 10% دادهی غیرزنده، 10% توهم |
| Tool schema | «امضای تابع برای مدل» | نام، توضیحات و اسکیمای JSON مربوط به ورودیها |
| tool_use_id | «شناسهی پیگیری» | پیونددهندهی فراخوانی ابزار به خروجی آن؛ عنصری حیاتی در ارسال موازی فراخوانیها |
| Hallucination detection | «دانستن اینکه چه زمانی نباید ابزار صدا زد» | یکی از دستههای V4: امتناع از فراخوانی وقتی هیچ ابزاری مناسب نیست |
| Argument coercion | «اصلاح رشته به عدد» | اصلاحات محدود برای ناهماهنگیهای قابلپیشبینی با اسکیما؛ در صورت وجود ابهام باید رد شود |
| Sandboxing | «مرز امنیتی اجرای ابزار» | محدودهی خواندن و نوشتن، دسترسی به شبکه، مهلت زمانی و سقف حافظه برای هر ابزار |
برای مطالعهی بیشتر
- شیک و همکاران، Toolformer (arXiv:2302.04761) — نشانهگذاری خودنظارتی ابزارها
- لیدربورد فراخوانی تابع برکلی (BFCL V4) — بنچمارک ارزیابی سال 2026
- مستندات فراخوانی ابزار در Anthropic — اسکیمای ابزار در مقیاس عملیاتی در Claude Agent SDK
- مستندات OpenAI Agents SDK — ابزارهای نوع تابع و گاردریلها (سازوکارهای ایمنی)
