خطای ایجنت و مرز اختیار

خطای انباشته

یه قدم ۹۵ درصد درسته؛ خوبه. ولی بیست قدم پشت هم؟

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

اگه هر قدم ۹۹ درصد درست باشه، بیست قدم هنوز ۸۲ درصده. ولی با ۹۵ درصد می‌رسه به ۳۶ درصد، و با ۹۰ درصد به ۱۲ درصد. این فقط یه فرض ساده‌ست؛ ایجنت واقعی گاهی اشتباهش رو از روی نتیجه‌ی ابزار می‌فهمه و درستش می‌کنه. ولی فکر اصلی درسته: هر چی کار طولانی‌تره، یه درصد کوچیک خطا بزرگ‌تر می‌شه. برای همین کار طولانی رو بهتره به تیکه‌های کوتاه با ایستگاه بازبینی بشکنید.

جور خطاها

راهنمای Claude درباره‌ی ایجنت‌هایی که با کامپیوتر کار می‌کنن، چند جور خطا رو صاف می‌گه.

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

میان‌بر به هدف

یکی از «کارهای غیرمنتظره» اسم خودش رو داره: دور زدن هدف، به انگلیسی Reward Hacking یا Specification Gaming. یعنی سیستم دقیقا همون چیزی رو که بهش گفتید برآورده می‌کنه، ولی نه اون چیزی رو که می‌خواستید.

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

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

محیط جدا

اولین مرز اینه که ایجنت کجا کار کنه و به چی دست بزنه.

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

تایید آدم

مرز دوم اینه که ایجنت چه کارهایی رو خودش بکنه و چه کارهایی رو نه.

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

یه تایید خوب

تایید آدم فقط وقتی به درد می‌خوره که آدم بفهمه داره چی رو تایید می‌کنه. «ادامه بدم؟» تنها کافی نیست.

پیشنهاد ما اینه که یه درخواست تایید خوب چهار چیز رو روشن بگه: چه کاری، به کی یا کجا، چقدر، و اینکه برمی‌گرده یا نه. اگه ایجنت می‌خواد یه قبض رو بپردازه، باید ببینید کدوم قبض، به کدوم شرکت، چه مبلغی، و اینکه پرداخت برگشت نداره. اگه یکی از این‌ها توی پیام نبود، تایید نکنید و بپرسید. و اگه درخواست با چیزی که خودتون خواسته بودید جور نیست، شاید ایجنت از یه دستور پنهان پیروی کرده؛ همون‌جا دست نگه دارید.

دیدن برنامه

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

چقدر تنها جلو می‌رن

ایجنت‌ها چه کارهای طولانی‌ای رو می‌تونن تنهایی تموم کنن؟ یه پژوهش ۲۰۲۵ یه عدد ساده براش ساخت.

کارهای برنامه‌نویسی و پژوهشی جورواجور رو اول دادن به آدم‌های کاربلد و زمان گرفتن، بعد به مدل‌ها. بعد پرسیدن: کاری که آدم چقدر طول می‌کشه، مدل نصف وقت‌ها درست تموم می‌کنه؟ برای بهترین مدل‌های اوایل ۲۰۲۵، مثل یه Claude اون موقع، این عدد حدود ۵۰ دقیقه بود. و از ۲۰۱۹ تا اون موقع، هر حدود هفت ماه دو برابر شده بود.

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

شما

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

چند نکته

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

با این درس ایستگاه ابزار و ایجنت تموم شد. ایستگاه بعد سراغ مدل‌هایی می‌ره که پیش از جواب خودشون فکر می‌کنن: مدل استدلالی چیست.