استفاده از ابزار

چرا ابزار

مدل خودش ماشین‌حساب نیست، اینترنت هم نداره. ولی می‌تونه بنویسه «ماشین‌حساب، اینو حساب کن».

یه پژوهش ۲۰۲۳ یه تناقض جالب رو این‌طوری گفت: مدل‌های زبانی کارهای تازه رو با چند نمونه یاد می‌گیرن، ولی توی کارهای خیلی ساده‌ای مثل حساب کردن یا پیدا کردن یه واقعیت ضعیف‌ان؛ همون کارهایی که یه ابزار خیلی ساده‌تر بی‌نقص انجامشون می‌ده. توی درس چرا مدل حرف‌ها رو بد می‌شمره دیدیم چرا؛ و می‌دونیم مدل از هر چیزی بعد از تاریخ برش دانشش خبر نداره.

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

رفت و برگشت

راهنمای Claude این رفت و برگشت رو این‌طوری می‌گه. کاربر یه سوال می‌پرسه. مدل به‌جای جواب، یه «درخواست ابزار» برمی‌گردونه: اسم ابزار و ورودی‌هاش، توی یه قالب دقیق، مثل همون خروجی ساختاریافته. برنامه‌ی شما این درخواست رو می‌خونه، خودش اجراش می‌کنه، و نتیجه، اینجا ۵۰۲، رو به گفت‌وگو برمی‌گردونه. حالا مدل با نتیجه جلوی چشمش، جواب نهایی رو می‌نویسه.

نکته‌ی مهم اینه که مدل خودش هیچ کاری رو اجرا نمی‌کنه. فقط درخواست رو می‌نویسه. ماشین‌حساب، پایگاه داده یا ارسال ایمیل، همه کار برنامه‌ی شماست. برای همین کنترل هم دست شماست.

با هم یا پشت سر هم

یه سوال گاهی بیشتر از یه ابزار لازم داره، و دو جور می‌شه.

اگه کسی بپرسه «هوا و ساعت شیراز چنده؟»، این دو تا کار به هم ربطی ندارن؛ راهنمای Claude می‌گه مدل می‌تونه توی یه نوبت چند تا درخواست ابزار با هم بنویسه، و برنامه‌ی شما همه رو اجرا می‌کنه و نتیجه‌ها رو با هم برمی‌گردونه. این‌طوری یه رفت و برگشت کافیه، نه دو تا.

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

تعریف ابزار

مدل از کجا می‌دونه چه ابزارهایی داره؟ شما بهش می‌گید؛ برای هر ابزار یه کارت.

هر ابزار یه اسم داره، یه توضیح که می‌گه چی کار می‌کنه، و یه قالب ورودی که می‌گه چه ورودی‌هایی لازم داره و هر کدوم چه نوعیه. راهنمای Claude می‌گه مدل از روی همین توضیح تصمیم می‌گیره کی ابزار رو صدا بزنه؛ پس توضیح خوب، مثل یه پرامپت خوب، روشن و دقیقه. یه حالت «سخت‌گیر» هم هست که تضمین می‌کنه درخواست مدل دقیقا با قالب ورودی جور باشه.

کارت خوب

راهنمای Claude صاف می‌گه مهم‌ترین چیز توی خوب کار کردن ابزار، خیلی بیشتر از هر چیز دیگه، توضیح خود ابزاره.

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

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

کی صدا می‌زنه

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

این مرز رو با پیام سیستمی می‌شه جابه‌جا کرد: یه جمله مثل «پیش از جواب، با ابزارها بررسی کن» استفاده از ابزار رو بیشتر می‌کنه. و اگه حتما می‌خواید ابزار صدا زده بشه، می‌شه اجبارش کرد.

وقتی ابزار خطا می‌ده

ابزار همیشه جواب نمی‌ده: سرویس قطعه، ورودی غلطه، یا اجازه نیست. برنامه‌ی شما با این چی کار کنه؟

راهنمای Claude می‌گه خطا رو قایم نکنید؛ همون پیام خطا رو به‌عنوان نتیجه برگردونید، با یه علامت که بگه این خطاست. اون‌وقت مدل خودش به کاربر می‌گه چی شد، مثلا «سرویس هوا الان در دسترس نیست، کمی بعد امتحان کنید». اگه خطا به‌خاطر یه ورودی جاافتاده باشه، مثلا شهر رو نگفته، مدل معمولا دو سه بار با درست کردن ورودی دوباره امتحان می‌کنه و بعد از کاربر عذرخواهی می‌کنه.

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

دو جور ابزار

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

کد، ابزار همه‌کاره

یه ابزار خاص هست که جای خیلی از ابزارها رو می‌گیره: اجرای کد.

یه پژوهش ۲۰۲۲ به‌جای اینکه از مدل بخواد مسئله‌ی ریاضی رو قدم به قدم حل کنه، ازش خواست یه برنامه‌ی کوچیک بنویسه که حلش کنه؛ بعد یه مفسر پایتون اون برنامه رو اجرا کرد و جواب داد. یعنی مدل فقط کاری رو می‌کنه که خوب بلده، یعنی شکستن مسئله به قدم‌ها، و حساب کردن، که مدل‌ها توش اشتباه می‌کنن، با کامپیوتره. روی یه آزمون معروف مسئله‌های ریاضی دبستانی، این روش حدود ۱۵ امتیاز از مدلی خیلی بزرگ‌تر که قدم به قدم فکر می‌کرد جلو زد.

امروز خیلی از چت‌بات‌ها یه ابزار اجرای کد دارن که برای حساب، جدول، نمودار و کار با فایل ازش استفاده می‌کنن. کد توی یه جای جدا و محدود اجرا می‌شه، چون هر برنامه‌ای که مدل بنویسه، مثل هر چیز دیگه‌ای که مدل می‌نویسه، باید با احتیاط دید.

یه پریز برای همه

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

برای همین سال ۲۰۲۴ یه استاندارد باز ساخته شد به اسم MCP، کوتاه‌شده‌ی Model Context Protocol. سایت خودش می‌گه MCP رو مثل یه درگاه یکسان ببینید، همون‌طور که یه نوع درگاه شارژ، دستگاه‌های مختلف رو به یه شکل وصل می‌کنه. هر ابزار یه بار به شکل MCP ساخته می‌شه و هر اپی که MCP بلده، مثل Claude یا ChatGPT، می‌تونه بهش وصل بشه؛ پس به‌جای ۹ اتصال، ۶ تا. فکر پشتش همون کارت ابزاره که بالا دیدیم؛ فقط شکلش برای همه یکی شده. یادتون باشه هر ابزاری که وصل می‌کنید، به دستیار دسترسی تازه می‌ده؛ پس همون قانون کمترین دسترسی این‌جا هم هست.

خطرها

خطر اول ورودی حدسیه. راهنمای Claude یه مثال داره: اگه ابزار «آب‌وهوا» شهر رو لازم داشته باشه و کاربر فقط بپرسه «هوا چطوره؟»، مدل ممکنه بپرسه کدوم شهر، ولی ممکنه هم یه شهر رو حدس بزنه. برای ابزارهای مهم، مثل پرداخت، این حدس می‌تونه گرون تموم بشه؛ پس بهتره ورودی‌های مهم رو برنامه‌تون هم بسنجه.

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

چند نکته

• حساب و داده‌ی دقیق، با ابزار. نه با حدس مدل.
• توضیح ابزار، روشن و دقیق. مدل از روی همون تصمیم می‌گیره.
• ورودی‌های مهم رو بسنجید. مدل ممکنه حدس بزنه.
• نتیجه‌ی ابزار، داده‌ست. نه دستور.

وقتی مدل بتونه چند بار پشت هم ابزار صدا بزنه و از نتیجه‌ها قدم بعد رو تصمیم بگیره، یه ایجنت داریم: ایجنت هوش مصنوعی از درون.