ایجنت هوش مصنوعی چیست و چطور آن را ارزیابی کنیم؟
English
پاسخ کوتاه: ایجنت هوش مصنوعی سیستمی است که برای رسیدن به یک هدف، فقط متن تولید نمیکند؛ وضعیت را میسنجد، گام بعدی را انتخاب میکند، از ابزار استفاده میکند، نتیجه را میبیند و تا رسیدن به نقطه پایان یا نیاز به دخالت انسان ادامه میدهد. ارزش واقعی آن با یک دموی جذاب ثابت نمیشود. باید نشان دهد کار مشخص را با شواهد قابلبررسی، هزینه قابلقبول و کنترل ایمن انجام میدهد.
این راهنما یک کارت امتیاز هفتبخشی ارائه میکند تا تیم محصول، مدیر کسبوکار یا سازنده غیرتکنیکال بتواند پیش از خرید یا استقرار، یک ایجنت را با کار واقعی بسنجد. نسخه CSV کارت ارزیابی ایجنت را میتوانید دانلود و برای سناریوی خود تکمیل کنید.
چه چیزی یک سیستم را به ایجنت تبدیل میکند؟
هر چتبات یا فراخوانی مدل زبانی ایجنت نیست. در تعریف عملی راهنمای ساخت ایجنت OpenAI، سیستم زمانی ایجنت است که اجرای گردشکار را مدیریت کند، تصمیم بگیرد، ابزار مناسب را بهکار بگیرد و در صورت شکست مسیر را اصلاح یا کنترل را به انسان برگرداند. Anthropic همین تفاوت را با حلقه برنامهریزی، عمل، مشاهده و اصلاح توضیح میدهد.
برای نمونه، خلاصهکردن یک ایمیل بهتنهایی ایجنت نیست. سیستمی که ایمیلهای مرتبط را پیدا میکند، اطلاعات لازم را استخراج میکند، پیشنویس پاسخ میسازد، محدودیتهای سازمان را کنترل میکند و پیش از ارسال نهایی در نقطه مناسب اجازه میگیرد، رفتار ایجنتی دارد. هر ابزار تازه، توان سیستم را بیشتر میکند و همزمان سطح دسترسی و ریسک را نیز بالا میبرد.
چه زمانی اصلاً ایجنت نسازیم؟
اگر مسیر کار ثابت، قانونها روشن و خروجی کاملاً قابلپیشبینی است، اتوماسیون معمولی اغلب ارزانتر و قابلاعتمادتر است. ایجنت برای مسئلههایی مناسبتر است که تصمیمگیری وابسته به زمینه، داده بدون ساختار یا استثناهای متعدد دارند. حتی در این حالت، ابتدا کوچکترین دامنه مفید را انتخاب کنید. یک ایجنت با سه ابزار محدود معمولاً بهتر از سامانهای است که از روز اول به ایمیل، فایل، پرداخت و CRM دسترسی کامل دارد.
| نوع مسئله | شروع مناسب | نشانه هشدار |
|---|---|---|
| فرایند ثابت و تکراری | قانون یا اسکریپت قطعی | استفاده از مدل فقط برای جذابیت |
| تصمیم زمینهمحور | یک ایجنت محدود با ابزار خواندنی | نبود معیار پایان روشن |
| اقدام حساس یا برگشتناپذیر | تأیید انسانی اجباری | ارسال، حذف یا پرداخت خودکار از روز اول |
| چند نقش تخصصی | ابتدا یک ایجنت و ابزارهای شفاف | چندایجنتیکردن زودهنگام |
کارت امتیاز هفتبخشی ارزیابی ایجنت
پیش از آزمایش، ۲۰ تا ۵۰ وظیفه واقعی و نماینده انتخاب کنید. برای هر وظیفه، وضعیت نهایی قابلقبول، داده ورودی، اقدامهای مجاز و شرایط توقف را بنویسید. سپس هر بُعد را از صفر تا پنج امتیاز دهید و نتیجه را با وزن پیشنهادی محاسبه کنید.
۱. موفقیت در انجام کار — ۲۵ درصد
معیار اصلی این نیست که پاسخ «خوب بهنظر برسد». بررسی کنید آیا وضعیت واقعی به نتیجه مورد انتظار رسیده است: رکورد درست بهروزرسانی شده، فایل صحیح ساخته شده یا درخواست با محدودیتهای تعریفشده تکمیل شده است. داوری را تا جای ممکن با بررسی مستقل سیستم، تست یا مقایسه با پاسخ مرجع انجام دهید.
۲. کیفیت شواهد — ۱۵ درصد
برای ادعاهای مهم، منبع یا رکورد پشتیبان باید قابلبازیابی باشد. نرخ ادعای پشتیبانیشده، لینک نامعتبر و استناد نامرتبط را جدا ثبت کنید. پاسخ روان بدون مسیر شواهد، در کار پژوهشی، حقوقی، مالی یا تصمیم سازمانی قابل اتکا نیست.
۳. تکرارپذیری — ۱۵ درصد
یک اجرای موفق کافی نیست. همان وظیفه حساس را دستکم پنج بار با شرایط ثابت اجرا کنید و توزیع نتیجه را ببینید. آزمایش NIST درباره ربایش ایجنت نشان میدهد تکرار حمله میتواند بر برآورد ریسک اثر جدی بگذارد؛ بنابراین میانگین، بدترین حالت و نرخ شکست را با هم ثبت کنید.
۴. ایمنی ابزار و داده — ۱۵ درصد
ابزارها را براساس خواندن، نوشتن، برگشتپذیری، داده حساس و اثر مالی طبقهبندی کنید. سپس ورودی مخرب، دستور پنهان در سند، لینک نامطمئن و داده ناقص را آزمایش کنید. ایجنت باید محتوای ورودی را «داده» بداند، نه دستور معتبر برای تغییر هدف. مجوز حداقلی و جداسازی محیط از یک guardrail متنی مهمتر است.
۵. کنترل انسانی — ۱۰ درصد
نقطههای تأیید باید از قبل تعریف شوند: ارسال پیام بیرونی، حذف داده، پرداخت، انتشار عمومی یا پذیرش تعهد. سیستم خوب فقط سؤال زیاد نمیپرسد؛ تفاوت تصمیم قابلاستنتاج و ترجیحی را که فقط انسان میداند تشخیص میدهد. نرخ توقف درست و نرخ مزاحمت بیدلیل را هر دو بسنجید.
۶. بازیابی و توقف امن — ۱۰ درصد
خرابی API، پاسخ ناقص، قطع اتصال یا نبود مدرک را عمداً وارد سناریو کنید. ایجنت باید بتواند دوباره تلاش محدود انجام دهد، مسیر جایگزین امن انتخاب کند یا با گزارش روشن متوقف شود. تکرار بینهایت، پنهانکردن شکست و تولید نتیجه حدسی هر سه failure محسوب میشوند.
۷. هزینه و زمان تا نتیجه پذیرفتهشده — ۱۰ درصد
هزینه هر فراخوانی تصویر دقیقی نمیدهد. مجموع token، ابزار، زمان اجرا، تلاش مجدد و بازبینی انسانی را بر تعداد کارهای پذیرفتهشده تقسیم کنید. تأخیر متوسط را کنار صدک ۹۵ ببینید تا چند اجرای بسیار کند پنهان نشوند. بهینهسازی مدل تنها بعد از تثبیت baseline کیفیت معنا دارد.
یک برنامه آزمون پنجمرحلهای
- قرارداد کار را بنویسید: ورودی، خروجی، معیار موفقیت، ابزار مجاز و نقطه توقف.
- مجموعه وظایف نماینده بسازید: حالت عادی، مرزی، داده ناقص و اقدام حساس را پوشش دهید.
- baseline بگیرید: با مدل و تنظیمات ثابت چند بار اجرا کنید و trace، هزینه و زمان را ذخیره کنید.
- خرابی را تزریق کنید: ابزار قطع، سند آلوده، منبع نامعتبر و تعارض دستور را آزمایش کنید.
- تصمیم انتشار بگیرید: حداقل قابلقبول هر بعد و شرط rollback را پیش از پایلوت واقعی تعیین کنید.
راهنمای ارزیابی ایجنت Anthropic توصیه میکند کیفیت نتیجه نهایی و مسیر اجرای چندمرحلهای هر دو دیده شوند. Google ADK نیز ارزیابی پاسخ نهایی و trajectory را در برابر test caseهای از پیش تعریفشده جدا میکند. این یعنی فقط متن آخر را نمرهدادن، انتخاب ابزار اشتباه یا یک میانبُر خطرناک را پنهان میکند.
نکتههای مهم برای تیمهای ایرانی
پشتیبانی از زبان فارسی با دسترسی رسمی، امکان پرداخت یا مجازبودن پردازش داده یکسان نیست. پیش از ساخت وابستگی محصول، کشورها و حسابهای پشتیبانیشده، شرایط استفاده، محل نگهداری داده و روش billing را در منبع رسمی همان روز بررسی کنید. این راهنما هیچ روش دورزدن محدودیت منطقهای پیشنهاد نمیکند.
برای فارسی، مجموعه آزمون باید اعداد فارسی و لاتین، نیمفاصله، نامهای مشابه، تاریخ شمسی و میلادی، متن راستبهچپ، فایل اسکنشده و ترکیب فارسیـانگلیسی را پوشش دهد. معیار موفقیت را با نمونههای واقعی کاربران بنویسید؛ ترجمه یک benchmark انگلیسی برای ارزیابی تجربه فارسی کافی نیست.
هزینه را نیز فقط با قیمت دلاری API نسنجید. نوسان دسترسی، زمان بازبینی، نیاز به جایگزین و ریسک قفلشدن به ارائهدهنده بخشی از هزینه محصولاند. برای جریان حساس، خروجی و trace قابلحمل و مسیر fallback تعریف کنید.
ایجنت واحد یا سیستم چندعاملی؟
چند ایجنت لزوماً نتیجه بهتری نمیسازند. ابتدا یک ایجنت را تا مرز قابلاندازهگیری توسعه دهید. اگر نقشها، ابزارها یا دستورها آنقدر متنوع شدند که یک عامل مرتب ابزار اشتباه انتخاب میکند، تقسیم نقش میتواند مفید باشد. اما ارزیابی باید از سطح هر عامل فراتر برود و سازگاری کل شبکه را نیز بسنجد.
پروژه Phronesis Index یک preprint عمومی درباره تشخیص سازگاری در شبکهها و سامانههای چندعاملی است. نتایج آن author-reported و peer-reviewed نیستند؛ بنابراین در این راهنما بهعنوان یک مسیر پژوهشی و نمونه مسئله معرفی میشود، نه اثبات مستقل یک معیار تولیدی.
جمعبندی
ایجنت را با میزان خودمختاری یا جذابیت دموی آن نخرید. یک کار محدود و ارزشمند انتخاب کنید، نتیجه قابلبررسی تعریف کنید و موفقیت، شواهد، تکرارپذیری، ایمنی ابزار، کنترل انسانی، بازیابی و هزینه واقعی را با چند اجرای تکراری بسنجید. اگر سیستم در اقدام حساس بهدرستی توقف نمیکند، نبود مدرک را تشخیص نمیدهد یا هزینه هر نتیجه پذیرفتهشده روشن نیست، هنوز برای دامنه بزرگتر آماده نیست.
برای زمینه حرفهای و پژوهشی نویسنده، صفحه فارسی سپهر بیات را ببینید؛ مقالههای بعدی درباره AI، محصول و سیستمهای چندعاملی در وبلاگ فارسی منتشر میشوند.