ارزیابی ایجنت هوش مصنوعی پیش از production: هارنس ارزیابی چیست

ایجنت شما دمو را پاس کرد. این هیچ چیزی دربارهٔ دویستمین تیکت مبهم نمی‌گوید.

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

هارنس ارزیابی (Evaluation Harness) پاسخ سیستمی به همین مسئله است.

هارنس ارزیابی دقیقاً چیست؟

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

سه واژه در این تعریف بار اصلی را می‌برند. «ثابت» یعنی مجموعه بین دو نسخه تغییر نمی‌کند، وگرنه اعداد قابل مقایسه نیستند. «واقعی» یعنی ورودی‌ها از لاگ عملیات آمده‌اند، نه از ذهن تیم. «خودکار» یعنی اجرای آن به تصمیم کسی وابسته نیست.

تفاوت این با تست نرم‌افزار معمولی مهم است. تست واحد یک خروجی قطعی را می‌سنجد. هارنس ارزیابی یک توزیع را می‌سنجد: ایجنت روی ۵۰ مورد چند تا را درست حل کرد، با چه هزینه‌ای، و در چند مورد سکوت کرد.

ایجنت‌ها در چهار کلاس شکست می‌خورند

وقتی چند سیستم عملیاتی را دیده باشید، شکست‌ها الگو پیدا می‌کنند. تقریباً همه در یکی از این چهار دسته می‌افتند:

کلاس سوم بیشترین هزینه را دارد و کمترین ردپا را. سیستم سالم به‌نظر می‌رسد چون هیچ استثنایی پرتاب نمی‌شود. تنها راه دیدنش، مقایسهٔ خروجی با پاسخ درستِ از پیش ثبت‌شده است.

مجموعهٔ طلایی را از رونوشت‌های واقعی بسازید

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

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

این کار حدود دو روز وقت می‌گیرد. همان دو روز، تنها سرمایه‌گذاری در کل این فرایند است که ارزشش با گذر زمان بیشتر می‌شود.

نردبان استقرار: آفلاین، سایه، کاناری

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

1. ارزیابی آفلاین. هارنس روی مجموعهٔ طلایی اجرا می‌شود. ثابت می‌کند منطق ایجنت روی موارد شناخته‌شده درست است. تنها چیزی که ثابت نمی‌کند، رفتار در برابر ورودی تازه است.
2. حالت سایه (Shadow Mode). ایجنت روی ترافیک واقعی اجرا می‌شود ولی خروجی‌اش به کسی نمایش داده نمی‌شود؛ فقط ثبت می‌شود. یک تا دو هفته کافی است تا توزیع واقعی ورودی‌ها را ببینید.
3. کاناری. پنج درصد ترافیک واقعی، با امکان بازگشت فوری. اینجا برای اولین بار انسان بیرونی خروجی را می‌بیند.

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

معیارهای نمره‌دهی و قانون توقف

یک نمرهٔ واحد کافی نیست. چهار عدد را کنار هم بگذارید:

• درستی: چند درصد موارد مجموعهٔ طلایی پاسخ قابل قبول گرفتند.
• هزینه: میانگین هزینهٔ هر مورد، نه هزینهٔ ماهانه. هزینهٔ ماهانه رشد ترافیک را با افت کارایی قاطی می‌کند.
• تأخیر: صدک ۹۵، نه میانگین. میانگین تأخیر، تجربهٔ بدترین کاربران را پنهان می‌کند.
• نرخ ارجاع: چند درصد موارد به انسان سپرده شد.

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

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

یک نمونهٔ واقعی: ایجنت پیگیری فاکتور

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

نتیجهٔ اولین اجرای آفلاین: درستی ۸۴ درصد. سه مورد از هشت مورد شکست‌خورده یک الگوی مشترک داشتند — مشتری‌هایی که قسطی پرداخت کرده بودند. ایجنت جمع پرداخت‌ها را نمی‌دید، فقط آخرین تراکنش را می‌دید، و برای کسی که کامل تسویه کرده بود یادآوری می‌فرستاد.

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

نکتهٔ مهم‌تر: بعد از رفع باگ، درستی به ۹۶ درصد رسید و نرخ ارجاع از ۴ به ۱۱ درصد بالا رفت. عدد دوم در نگاه اول بدتر به‌نظر می‌رسد. در واقع سالم‌تر بود — ایجنت یاد گرفته بود پرونده‌های چندپرداختی را به انسان بسپارد.

مبادله‌ای که باید بپذیرید

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

در مقابل، بدون هارنس شما هر انتشار را با احساس تأیید می‌کنید. آن احساس مقیاس‌پذیر نیست.

هر چند وقت یک‌بار باید هارنس را دوباره اجرا کرد؟

در هر تغییر پرامپت، هر تغییر مدل، و هر تغییر در تعریف ابزارها. اگر اجرای کامل زیر ده دقیقه طول بکشد، در هر merge اجرایش کنید؛ اگر بیشتر، شبانه.

مالک مجموعهٔ طلایی چه کسی است؟

کسی که مسئول کیفیت خروجی عملیاتی است، نه تیم مهندسی. اگر مهندسی هم پاسخ درست را تعریف کند و هم کد را بنویسد، ارزیابی به یک آینه تبدیل می‌شود.

آیا می‌شود ارزیابی را با یک مدل دیگر خودکار کرد؟

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

جمع‌بندی

دمو نشان می‌دهد ایجنت چه کاری می‌تواند بکند. هارنس ارزیابی نشان می‌دهد چند وقت یک‌بار آن کار را نمی‌کند. عدد دوم است که تعیین می‌کند سیستم قابل اتکاست یا نه.

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