از اجرای بنچمارکهای جدید مدلها دست بردارید و به تماشای عاملی (agent) بنشینید که سعی میکند یک اشتراک را لغو کند. شکاف بین این دو فعالیت، همان جایی است که سیستمهای عملیاتی (production systems) از کار میافتند. یک تست تکمرحلهای (single-turn) میتواند به شما بگوید که آیا پاسخ خوشایند به نظر میرسد یا خیر؛ اما نمیتواند به شما بگوید که آیا عامل بهتازگی پول مشتری اشتباهی را پس داده، یا چهارده بار در مقابل یک API تقویم در حلقه (loop) گیر کرده، یا تصمیم گرفته است که کلاً از بررسی کلاهبرداری صرفنظر کند. متن، کمخطرترین چیزی است که یک عامل تولید میکند. ریسکهای واقعی در ابزارهایی که لمس میکند، دادههایی که تغییر میدهد و لحظاتی پنهان هستند که باید درخواست کمک میکرد اما به مسیر خود ادامه داد.
چرا بنچمارکهای متنی در محیط عملیاتی شکست میخورند
امتیازات بالا در بنچمارکهای استاندارد به شکلی گمراهکننده، نوعی احساس امنیت کاذب ایجاد کردهاند. عاملی که نثر زیبایی مینویسد، همچنان میتواند یک خطر عملیاتی باشد. وقتی سیستم شما قرار ملاقات رزرو میکند، سوابق پایگاه داده را ویرایش میکند یا تیکتهای پشتیبانی ثبت میکند، متن تولید شده تنها سطح ظاهری جریان کاری (workflow) است. در لایههای زیرین، عامل در حال اتخاذ تصمیمات ملموسی درباره این است که کدام endpoint را فراخوانی کند، چه payload ای ارسال کند و چه زمانی متوقف شود. ممکن است در جدول امتیازات درک مطلب رتبه اول را کسب کند، اما همزمان با رزرو دوبله منابع، تغییر دادن ردیف اشتباه یا نشت دادههای حساس به فایلهای لاگ، برای شما هزینه تراش کند. شما باید مکانیسمهای انجام کار را تأیید کنید، نه فقط صیقل بودن خروجی را. اگر عاملی میتواند در یک تست QA آفلاین امتیاز خوبی بگیرد اما همچنان با ایجاد حلقه یا استفاده نادرست از یک ابزار، جریان کاری شما را مختل کند، یعنی ارزیابی شما در حال بررسی سیگنالهای اشتباه است.
نقشهبرداری از پنج وابستگی
تیم Van Data Team هر ارزیابی را با نقشهبرداری از پنج نقطه کنترل مشخص شروع میکند. این کار صورت مسئله را کاملاً تغییر میدهد. شما دیگر نمیپرسید که آیا یک مدل از مدل دیگر باهوشتر است یا خیر؛ بلکه میپرسید که آیا عامل واقعاً میتواند یک وظیفه عملیاتی را تحت محدودیتهای واقعی شما به پایان برساند یا خیر.
پیامدهای تجاری (Business outcomes). تعریف کنید که «انجام شدن» از نظر ارزش دلاری و تأثیر بر مشتری به چه معناست. یک وظیفه زمانی کامل نیست که عامل یک خلاصه ارائه دهد؛ بلکه زمانی کامل است که رکورد موجودی دقیق باشد، قرار ملاقات تأیید شده باشد و مشتری یک شماره پیگیری معتبر دریافت کرده باشد.
وضعیتهای تغییرپذیر (Mutable state). دقیقاً بدانید عامل مجاز به تغییر چه چیزهایی است. کدام جداول، کدام وضعیتها، کدام پرچمهای حساب؟ اگر عامل میتواند بازپرداختها را انجام دهد، زمان کارها را تغییر دهد یا آدرسهای صورتحساب را بهروز کند، باید تمام فیلدهایی را که لمس میکند، فهرست کنید.
دسترسیهای ابزار (Tool permissions). درباره اینکه کدام endpointهای API و توابع در محدوده هستند، صریح باشید. عاملی که به ابزار جستجو، ابزار نوشتن و ابزار اعلان دسترسی دارد، اگر مرزها مبهم باشند، آنها را با هم مخلوط خواهد کرد. هر دسترسی را به یک نیاز عملیاتی مشخص متصل کنید.
بازیابی از خطا (Failure recovery). تصمیم بگیرید وقتی API تقویم با تایماوت مواجه میشود، خطای 500 برمیگرداند یا یک JSON نامعتبر تحویل میدهد، چه اتفاقی میافتد. عامل نباید دچار وحشت شود، پیام موفقیت خیالی (hallucinate) تولید کند یا تا ابد تلاش مجدد (retry) کند. او به یک مسیر جایگزین (fallback) مشخص نیاز دارد.
درگاههای بازبینی انسانی (Human review gates). لحظاتی را شناسایی کنید که در آنها یک فرد باید پیش از ادامه کارِ عامل، آن را تأیید کند. این نشانهای از ضعف در اتوماسیون نیست؛ بلکه یک شیر اطمینان برای تغییرات پرخطر و منبعی برای برچسبهای واقعیت (ground-truth labels) جهت استفاده در معیارهای ارزیابی شماست.
یک برنامه ارزیابی واقعی چگونه است
پس از نقشهبرداری از وابستگیها، به برنامهای برای ارزیابی نیاز دارید که با آشفتگی محیط عملیاتی همخوانی داشته باشد. معیارهای ارائه شده در اسلایدهای ارائه (slide-deck metrics) در اینجا کمکی به شما نخواهند کرد.
مجموعه تستهایی از دل شکستهای واقعی در محیط عملیاتی بسازید، نه از بانکهای سوالات مصنوعی. اگر عامل شما روز سهشنبه گذشته با اشتباه گرفتن دو SKU مشابه شکست خورد، دقیقاً همان اشتباه باید یک مورد تست دائمی باشد. مجموعه ارزیابی شما باید هر بار که یک حادثه چیز جدیدی به شما میآموزد، رشد کند.
معیارهایی (rubrics) بنویسید که تکمیل موفقیتآمیز را با اصطلاحات عملیاتی تعریف کنند. معیارهای مبهمی مانند «مفید» یا «دقیق» بیفایده هستند. یک معیار مفید بیان میکند که یک وظیفه بازپرداخت تنها زمانی موفقیتآمیز است که به شناسه پرداخت اصلی ارجاع داده شده باشد، مبلغ با درخواست مطابقت داشته باشد، یک ایمیل تأیید در صف ارسال باشد و شناسه تراکنش ثبت شده باشد.
مشخصات ردیابی (trace specs) را برای فراخوانی ابزارها و تلاشهای مجدد تعریف کنید. شما به قابلیت مشاهده (observability) نیاز دارید تا بدانید عامل چه چیزی را برنامهریزی کرده، واقعاً چه چیزی را فراخوانی کرده، چند بار تلاش مجدد انجام داده و آیا استراتژی تلاش مجدد مناسب بوده است یا خیر. یک ردیابی (trace) بدون جزئیات در سطح ابزار، فقط یک داستان زیباست.
سیاستهایی برای زمان هشدار به انسان تعیین کنید. عامل باید مرزهای خود را بشناسد. اگر درخواستی از یک آستانه دلاری فراتر رفت، به یک حساب VIP اشاره کرد یا با وضعیتی مواجه شد که قبلاً هرگز ندیده بود، باید به جای حدس زدن، موضوع را به سطح بالاتر (escalate) ارجاع دهد.
دروازههای انتشار را برای مسدود کردن ارتقاهای نامناسب مدل نصب کنید. یک مدل جدید تنها زمانی یک ارتقا محسوب میشود که نتایج خاص شما را بهبود بخشد. اگر مدل بیشتر از حد معمول در آرگومانهای ابزار دچار توهم شود، تأخیر (latency) را افزایش دهد یا ریسکهای ایمنی جدیدی ایجاد کند، نباید منتشر شود. این دروازه باعث میشود حتی زمانی که فروشنده مدل پایه نسخه جدیدی را عرضه میکند، محیط عملیاتی پایدار بماند.
ارزیابی در زمان اجرا (Runtime Grading): نظارت بر عملکرد عامل
Anthropic صنعت را به سمت فراتر رفتن از تستهای آفلاین و حرکت به سوی ارزیابی در زمان اجرا (runtime grading) سوق داده است. به جای قضاوت درباره یک رونوشت پس از اتمام کار، ارزیابی در زمان اجرا به سیستم اجازه میدهد تا عملکرد عامل را در حالی که وظیفه هنوز در حال اجرا است، قضاوت کند. این کار فرصتی ایجاد میکند تا خطاها را پیش از آنکه به مشکلات واقعی و ماندگار تبدیل شوند، شناسایی کنیم.
افزودن یک ارزیاب (grader) باعث مصرف توکن و افزایش تأخیر میشود. شما نمیتوانید هزینه ارزیابی هر قدم کوچک را بپردازید. محل قرارگیری هر ارزیاب یک تصمیم طراحی است. آنها را جایی قرار دهید که اشتباهات در آنجا پرهزینه هستند. ارزشمندترین نقاط بازرسی دقیقاً قبل از ثبت تغییر وضعیت در پایگاه داده، درست قبل از انجام یک پرداخت، و درست قبل از ارسال پیام به مشتری قرار دارند. اینها لحظاتی هستند که یک تصمیم اشتباه به یک اقدام غیرقابل بازگشت تبدیل میشود.
مراقب یک نقطه کور خاص باشید. اگر همان مدلی که کار را انجام میدهد، وظیفه ارزیابی را نیز بر عهده داشته باشد، ممکن است همان خطاها را نادیده بگیرد. استدلالی که باعث ایجاد خطا شده است، میتواند به راحتی در طول بازبینی، آن خطا را توجیه کند. برای وظایف حساس، نظارت انسانی را در چرخه (human-in-the-loop) حفظ کنید. اجازه دهید افراد قضاوت خودِ ارزیاب را تأیید کنند، بهویژه زمانی که پول یا اعتماد مشتری در میان است.
هدف در اینجا کنترل عملیاتی است. دادههای حوادث، معیارهای ارزیابی وظایف و ردپاهای زمان اجرا (runtime traces) خود را در یک چرخه بازخورد واحد متصل کنید. کل مسیر را ارزیابی کنید: برنامه، استفاده از ابزار، رفتار بازیابی و نتیجه نهایی. از تستهای آفلاین برای شناسایی خطاهای شناختهشده و تکرارپذیر قبل از انتشار استفاده کنید. از ردپاهای زمان اجرا برای یافتن شکستهای جدیدی که پیشبینی نکرده بودید استفاده کنید. از نظارت انسانی برای کشف نقاطی که معیارهای شما سادهلوحانه هستند و نیاز به سختگیرانهتر شدن دارند، استفاده کنید.
پس از خود بپرسید: یک ارزیاب زمان اجرا را در گردش کار خود کجا قرار میدهید؟ قبل از فراخوانی یک ابزار، بعد از فراخوانی یک ابزار، یا فقط قبل از یک تغییر پرخطر؟ اکثر تیمها خیلی گسترده شروع میکنند، همه چیز را ارزیابی میکنند و سپس به دلیل هزینهها از کار میافتند. محدود شروع کنید. تنها یک اقدامی را انتخاب کنید که اگر اشتباه پیش برود، بیشترین آسیب را میزند. ابتدا یک ارزیاب در آنجا قرار دهید.
با یک اشتباه پرهزینه شروع کنید
ارزیابی عملیاتی یک تمرین پژوهشی نیست؛ بلکه راهی است برای اینکه پس از فعال شدن عامل، با خیال راحتتر بخوابید. شما در روز اول به یک چارچوب کامل نیاز ندارید. شما به یک گردش کار واحد و مشخص، یک معیار (rubric) که با اصطلاحات ساده تجاری نوشته شده باشد، و یک ارزیاب نیاز دارید که دقیقاً در لحظهای قرار گیرد که یک خطا پرهزینه میشود. اگر این کار را درست انجام دهید، زیربنایی خواهید داشت که واقعاً بتوانید به آن اعتماد کنید.
اگر میخواهید در کنار جامعهای از متخصصان، عمیقتر در بحث ارزیابی عامل و ارزیابی در زمان اجرا کاوش کنید، میتوانید جامعه یادگیری GyaanSetu را در https://t.me/GyaanSetuAi پیدا کنید.