Tool Calling؛ وقتی بات باید کاری انجام دهد نه فقط جواب بدهد

یک بات که فقط از روی مستندات جواب می‌دهد، در نهایت به یک دیوار شیشه‌ای می‌رسد: کاربر می‌پرسد «سفارش من کجاست؟» یا «رمز عبورم را ریست کن»، و هیچ سندی جواب این سؤال را ندارد چون جواب یک عمل است، نه یک متن. اینجاست که Tool Calling وارد می‌شود؛ مکانیزمی که به مدل زبانی اجازه می‌دهد به‌جای فقط تولید متن، تشخیص دهد کدام تابع را با کدام پارامترها باید فراخوانی کند تا یک کار واقعی در سیستم انجام شود. برای دیدن این مفهوم در بستر کلی‌تر ایجنت‌های هوش مصنوعی، راهنمای کامل ایجنت هوش مصنوعی را ببینید؛ این مقاله روی جزئیات عملی تعریف و اجرای ابزار در یک بات پشتیبانی تمرکز می‌کند.

Tool Calling دقیقاً چه می‌کند

در معماری Tool Calling، به مدل زبانی فهرستی از «ابزارها» معرفی می‌شود؛ هر ابزار یک نام، توضیح، و طرحوارهٔ (schema) ورودی مشخص دارد. وقتی سؤال کاربر نیازمند یک عمل است، مدل به‌جای تولید جواب مستقیم، خروجی ساخت‌یافته‌ای تولید می‌کند که می‌گوید «این ابزار را با این پارامترها فراخوانی کن». برنامهٔ شما (نه مدل) آن ابزار را واقعاً اجرا می‌کند، نتیجه را می‌گیرد، و دوباره به مدل برمی‌گرداند تا جواب نهایی به زبان طبیعی برای کاربر ساخته شود. نکتهٔ مهم این است که مدل هرگز مستقیماً به دیتابیس یا API متصل نیست؛ او فقط «درخواست» می‌دهد و برنامهٔ میزبان تصمیم می‌گیرد آیا آن درخواست را اجرا کند.

نمونهٔ تعریف یک ابزار

فرض کنید بات پشتیبانی باید بتواند وضعیت سفارش را استعلام بگیرد. تعریف این ابزار به شکل JSON معمولاً این‌گونه است:

{
  "name": "get_order_status",
  "description": "وضعیت یک سفارش را با شمارهٔ سفارش برمی‌گرداند. فقط برای سفارش‌های متعلق به کاربر احرازهویت‌شدهٔ فعلی قابل استفاده است.",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "شمارهٔ سفارش، دقیقاً همان‌طور که کاربر وارد کرده"
      }
    },
    "required": ["order_id"]
  }
}

نام ابزار باید دقیق و بدون ابهام باشد، توضیح باید محدودهٔ استفادهٔ درست را مشخص کند (نه فقط «چه کاری می‌کند» بلکه «چه زمانی نباید استفاده شود»)، و طرحوارهٔ پارامترها باید حداقل ورودی لازم را بخواهد؛ نه یک شیء عمومی و باز که مدل هر چیزی در آن بریزد.

اصل حداقل دسترسی؛ مهم‌ترین قاعدهٔ طراحی ابزار

بزرگ‌ترین اشتباه در طراحی ابزارها، ساختن یک ابزار قدرتمند و همه‌کاره است — مثلاً ابزاری به نام run_database_query که هر پرس‌وجوی SQL دلخواه را اجرا می‌کند. چنین ابزاری هم خطرناک است (یک prompt injection یا خطای استنتاج مدل می‌تواند به حذف یا تغییر داده منجر شود) و هم دیباگش سخت است. قاعدهٔ درست این است: هر ابزار باید کمترین دسترسی لازم برای انجام دقیقاً همان یک کار را داشته باشد. به‌جای run_database_query، ابزارهای مجزا مثل get_order_status، cancel_order، و update_shipping_address تعریف کنید که هرکدام فقط به یک جدول یا یک عملیات محدود دسترسی دارند. همین اصل دربارهٔ عملیات نوشتنی (write) حساس‌تر است: ابزارهایی که داده تغییر می‌دهند یا پول جابه‌جا می‌کنند باید یا نیاز به تأیید صریح کاربر داشته باشند یا اصلاً از دسترس بات پشتیبانی خودکار خارج و به تحویل انسانی سپرده شوند. این تصمیم‌ها را باید کنار سیاست‌های امنیتی کلی‌تر پروژه بگذارید؛ نقشهٔ راه امنیت هوش مصنوعی چارچوب کاملی برای این ارزیابی دارد.

وقتی مدل ابزار اشتباه را انتخاب می‌کند

حتی با تعریف دقیق، مدل ممکن است ابزار نامناسب را فراخوانی کند یا پارامتر را اشتباه پر کند. راهکار عملی، اعتبارسنجی ورودی در لایهٔ برنامه (نه فقط اعتماد به schema) و برگرداندن خطای واضح به مدل است، تا مدل بتواند دوباره تلاش کند یا از کاربر اطلاعات بیشتری بخواهد. همچنین ثبت لاگ کامل هر فراخوانی ابزار — چه ابزاری، با چه پارامترهایی، چه نتیجه‌ای — برای دیباگ و ممیزی بعدی ضروری است.

حالت آزمایشی و اجرای تدریجی ابزارهای جدید

قبل از اینکه یک ابزار جدید — به‌خصوص ابزاری با دسترسی نوشتنی — را مستقیم در اختیار همهٔ کاربران بگذارید، اجرای آن در یک حالت آزمایشی (dry-run) عاقلانه است: ابزار همان‌طور که مدل درخواست می‌دهد فراخوانی می‌شود، اما به‌جای اجرای واقعی، فقط پارامترها و تصمیم مدل لاگ می‌شود. این کار به شما اجازه می‌دهد قبل از هرگونه تأثیر واقعی روی داده یا کاربر، ببینید مدل در چه شرایطی این ابزار را انتخاب می‌کند و آیا پارامترها را درست پر می‌کند یا نه. بعد از چند روز جمع‌آوری این داده، می‌توان با اطمینان بیشتری ابزار را برای اجرای واقعی فعال کرد، و اگر لازم بود، توضیح ابزار یا محدودیت‌های آن را قبل از فعال‌سازی نهایی اصلاح کرد.

مثال خطا و بازخورد به مدل

وقتی ورودی یک ابزار نامعتبر است — مثلاً شمارهٔ سفارش وجود ندارد یا فرمتش اشتباه است — پاسخ خطا باید ساختاری مشابه خودِ ابزار داشته باشد تا مدل بتواند آن را بفهمد و واکنش درست نشان دهد:

{
  "error": "order_not_found",
  "message": "سفارشی با این شماره برای این کاربر یافت نشد.",
  "suggestion": "از کاربر بخواه شمارهٔ سفارش را دوباره بررسی کند یا شماره موبایل ثبت‌شده در سفارش را بدهد."
}

پیام خطای مبهم یا فقط یک کد وضعیت HTTP خام باعث می‌شود مدل نتواند تصمیم درستی بگیرد و احتمالاً یا دوباره همان فراخوانی نادرست را تکرار می‌کند یا برای کاربر جوابی می‌سازد که واقعیت را پنهان می‌کند. پیام خطای واضح و همراه با پیشنهاد اقدام بعدی، به مدل کمک می‌کند مسیر درست ادامهٔ گفت‌وگو را انتخاب کند.

جمع‌بندی

• Tool Calling به مدل اجازه می‌دهد درخواست اجرای یک عمل بدهد؛ اجرای واقعی همیشه در اختیار برنامهٔ میزبان است.
• هر ابزار باید نام، توضیح دقیق، و طرحوارهٔ ورودی محدود داشته باشد.
• هرگز یک ابزار همه‌کاره و پرقدرت نسازید؛ ابزارها را به کوچک‌ترین واحد ممکن بشکنید.
• عملیات نوشتنی یا مالی حساس باید یا تأیید صریح بگیرد یا کلاً به انسان سپرده شود.
• هر فراخوانی ابزار را لاگ کنید تا رفتار بات قابل ممیزی و دیباگ باشد.