عامل هوش مصنوعی شما در تمرین کار میکند، اما در دموی زنده مسیر دیگری را انتخاب میکند و در همان کار شکست میخورد. این روی صحنه خجالتآور است؛ در محیط عملیاتی اما یک مسئله قابلیتاعتماد است: گردش کاری که یک بار موفق شد، دفعه بعد که کاربر همان درخواست را میدهد ممکن است شکست بخورد. در کارهای حیاتی — مثل تطبیق یک تراکنش مالی یا بررسی یک قرارداد برای یافتن تعهدات — این مسئله میتواند کار را کامل متوقف کند.
بیشتر بنچمارکها این نوسان را پشت یک میانگین پنهان میکنند. در بنچمارک AppWorld، یک عامل ReAct مبتنی بر GPT-4.1 در پنج تکرار روی ۷۷.۴ درصد اجراها موفق شد؛ اما فقط در ۵۳ درصد از کارها در هر پنج اجرا موفق بود. یعنی یک شکاف پایداری ۲۴.۴ واحدی. بیشتر بنچمارکها عدد اول را گزارش میکنند. ما روشی ساختیم که عدد دوم را اندازه بگیرد — و بهترش کند.
در مطلب پیشین، سیستم ALTK-Evolve معرفی شد؛ سیستمی که مسیرهای گذشته خود عامل را به دستورالعملهای قابلاستفاده تبدیل میکند، بهطور خودکار تقطیر میکند و در زمان استنتاج برمیگرداند. این سیستم موفقیت در وظایف را بهطور قابلاندازهگیری بالا میبرد، اما آن نتایج هم فقط پرسش حالت میانگین را میپرسیدند. این مطلب «دستورالعملهای پایداری» را معرفی میکند؛ نوع تازهای از دستورالعمل در altk-evolve که روی ابزاری تشخیصی بهنام Consistency Analyzer ساخته شده و دقیقاً همین شکاف را هدف میگیرد.
خلاصه در چند خط: دقت، مسئله ناپایداری را پنهان میکند. یک عامل ReAct (GPT-4.1 روی AppWorld test_normal) که بهطور میانگین ۷۷.۴ درصد موفق است، فقط در ۵۳ درصد کارها در هر پنج اجرا موفق میشود — یک شکاف پایداری ۲۴.۴ واحدی. روی کارهای سخت این شکاف به ۳۰ واحد میرسد.
ما دقیقاً برای همین یک ابزار تشخیصی ساختیم. تحلیلگر پایداری، مسیر ثبتشده خود عامل را بازنمونهگیری (resample) میکند تا نقاط تصمیم مستعد تغییر را پیدا کند؛ گامهایی که مدل فقط یک نمونهبرداری توکن با انجام کاری متفاوت فاصله داشت. این ابزار به یک رد (trace) نیاز دارد و هیچ داده مرجع یا برچسب درست نمیخواهد؛ بهجای اجرای دوباره کل کار از ابتدا تا انتها، هر نقطه تصمیم در همان رد را با یک فراخوانی که k تکمیل میخواهد (بهطور پیشفرض k=۵) بازنمونهگیری میکند.
تبدیل این تشخیص به دستورالعمل، شکاف را نصف میکند: از ۲۴.۴ واحد به ۱۲.۰ واحد (Pass⁵ در همان کار ۱۶ واحد بهتر و در کار مشابه ۱۳ واحد بهتر)، بدون هیچ هزینهای در دقت میانگین. روششناسی و ارزیابی کامل در گزارش فنی روی arXiv آمده است.
معیاری که تقریباً هیچکس گزارش نمیکند
ارزیابی استاندارد عاملها Mean@k را گزارش میکند: بنچمارک را k بار اجرا کن و نرخ موفقیت را میانگین بگیر. اغلب k برابر ۳ و بعضی وقتها فقط ۱ است. این عددی است که روی هر لیدربوردی میبینید و همان چیزی است که «۷۷ درصد دقت» در عمل به آن معناست. اما Mean@k به پرسش «این عامل بهطور میانگین چقدر خوب است؟» پاسخ میدهد، نه به پرسشی که کاربر واقعی دارد: اگر دقیقاً همین سؤال را دوباره بپرسم، باز هم خوب خواهد بود؟ برای آن به Pass^k نیاز دارید: نسبت کارهایی که عامل در هر k اجرا موفق میشود.
یک هشدار مهم: Pass^k با Pass@k فرق دارد. Pass@k آشنا خوشبینانه است و میپرسد آیا دستکم یکی از k تلاش موفق شد؛ این پرسش درست زمانی است که میتوانید نتیجه را بررسی و دوباره تلاش کنید. Pass^k تصویر بدبینانه و آینهوار آن است: هر تلاش باید موفق شود. همیشه Pass^k ≤ Mean@k ≤ Pass@k برقرار است.
یک عامل ReAct با پشتیبانی GPT-4.1 نمره Mean@5 برابر ۷۷.۴ درصد میگیرد که واقعاً قوی است؛ اما Pass^5 آن فقط ۵۳.۰ درصد است. یعنی نزدیک یکچهارم بنچمارک را کارهایی تشکیل میدهد که عامل گاهی حلشان میکند و گاهی نه، بدون اینکه چیزی در خود کار بین اجراها تغییر کرده باشد. ما به این اختلاف — Mean@k منهای Pass^k — «شکاف پایداری» میگوییم. این مسئلهای نیست که با مدل بزرگتر حل شود؛ یک محور عمود بر قابلیت است: یک عامل میتواند همزمان توانمند و ناپایدار باشد.
چرا عاملها تاب میخورند: تصمیمهای تیز در برابر تصمیمهای تخت
هر بار که یک عامل مدل زبانی چیزی را تصمیم میگیرد — کدام API را صدا بزند، چه آرگومانی بفرستد، دوباره تلاش کند یا نه — آن تصمیم از یک توزیع احتمال روی توکنهای بعدی بیرون میآید. چیزی که مهم است شکل آن توزیع است. یک توزیع «تیز» بیشتر جرمش را روی یک توکن میگذارد: گزینههای بعدی خیلی عقبترند و همان انتخاب در اجرای بعدی هم بیرون میآید. یک توزیع «تخت» جرم قابلمقایسهای را بین چند توکن نزدیک به هم پخش میکند و برنده شدن یکی از آنها تقریباً مثل شیر یا خط انداختن است.
شکل توزیع تعیین میکند چقدر نویز لازم است تا نتیجه عوض شود. توزیعهای تیز مقاوماند: عدمشرکتپذیری محاسبات ممیز شناور در GPU، دستهبندی درخواستها و دیگر اثرهای سمت پلتفرم اعداد را کمی جابهجا میکنند، اما نه بهقدری که یک برنده واضح را عوض کنند. توزیعهای تخت دقیقاً در برابر همان جابهجایی کوچک آسیبپذیرند: نزدیکهای مساوی ممکن است با اغتشاش کوچک بازآرایی شوند. و چون یک مسیر دهها تصمیم را زنجیروار به هم میبندد، احتمال کوچک تغییر در هر گام به احتمال زیادی تبدیل میشود که یکی از اجراها متفاوت پیش برود. شکاف ۲۴ واحدی از همینجا میآید.
همین دلیل است که این مشکل با تنظیمات رمزگشایی حل نمیشود. رمزگشایی حریصانه و seed ثابت فقط تعیین میکنند یک توزیع چطور به توکن تبدیل شود؛ درباره خود توزیع چیزی نمیگویند. روی یک endpoint میزبانیشده، احتمالها از اجرا به اجرا کمی جابهجا میشوند، پس همان پرامپت به همان مدل با دمای صفر هم میتواند امروز یک نزدیکمساوی را یکطرف و فردا طرف دیگر حل کند. در تنظیمات ما، عامل ReAct با دمای ۰.۰ اجرا میشود، پس هیچکدام از این نوسانها از نمونهبرداری معمولی نیست.
تشخیص بده، بعد درست کن
اینجا مسئله به یک جستوجو تبدیل میشود: کدام گامها در یک مسیر مشخص، گامهای «تخت» بودند و وقتی فهمیدیم، چه کار کنیم؟
دستورالعملهای پایداری از یک خط لوله دو مرحلهای بیرون میآیند که به ماشین موجود ALTK-Evolve وصل میشود، با یک سیگنال منبع تازه که تعیین میکند چه چیزی نوشته شود.
۱) تشخیص — تحلیلگر پایداری: با داشتن یک مسیر ثبتشده، تحلیلگر هر گام تصمیم را از طریق بازنمونهگیری کنترلشده بازپخش میکند و میسنجد خروجی مدل در آن نقطه واقعاً چقدر تغییر میکند. بهطور مشخص، این کار یک فراخوانی مدل اضافه برای هر گام تصمیم است که یکبار بهصورت آفلاین انجام میشود و با تنظیم نمونهبرداری، k تکمیل را همزمان میگیرد (پیشفرض k=۵)؛ بازپخش روی همان زمینهای انجام میشود که از قبل ثبت شده — نه فراخوانی ابزار تازه، نه تعامل محیطی جدید و نه یک اجرای دوم کل کار. نتیجه، یک نمره پایداری برای هر گام تصمیم است که در یک کارنامه نوشته میشود تا دقیقاً مشخص شود کدام تصمیمها در معرض تابخوردن هستند. خروجی این مرحله فهرست کوتاهی از نقاط پرخطر است، نه یک عدد کلی؛ و همین ویژگی باعث میشود مداخله هدفمند شود: بهجای تلاش برای پایدارتر کردن کل مسیر، میتوان همان چند تصمیم لرزان را با دستورالعمل پوشش داد.
نتیجه این رویکرد آن است که شکاف پایداری تقریباً نصف شده، در حالی که میانگین دقت ثابت مانده است؛ یعنی هزینهای که هنگام خرید پایداری پرداخت میشود، افت توانایی نیست. برای تیمهایی که عاملها را در گردشکارهای مالی، حقوقی یا پشتیبانی مشتری به کار میگیرند، این تفاوت میان «دموی خوب» و «سیستم قابل اتکا» است. جزئیات کامل روششناسی، معیارها و ارزیابیها در گزارش فنی روی arXiv منتشر شده است.