واقعیات پایدار در برابر نظرات گذرا در ارزیابی مدل‌های عامل‌محور

اگر داشبورد ارزیابی مدل شما چراغ سبز نشان می‌دهد اما عامل شما در محیط واقعی شکست می‌خورد، احتمالاً با پدیده «پوسیدگی داده» روبرو هستید. شما در حال اندازه‌گیری تطابق مدل با تصویری از جهان هستید که ماه‌ها پیش ثبت شده، نه با واقعیت جاری. زمانی که یک داشبورد سبز باقی می‌ماند در حالی که عامل در محیط تولید (Production) شکست می‌خورد، معمولاً به این معناست که عامل هنوز با تکه‌ای از داده‌های دنیای واقعی که ماه‌ها پیش گرفته شده است موافق است، نه با واقعیت فعلی. این یک حالت شکست بحرانی است که تیم‌های ارشد بارها به روشی سخت دوباره آن را کشف می‌کنند: عامل سالم است، محیط تست (Harness) سالم است، اما این «اوراکلِ تست» (Test Oracle) است که اشتباه است.

این حالت شکست، یکی از شدیدترین انواع بدهی فنی هوش مصنوعی (AI Technical Debt) است. اکثر تیم‌ها با مجموعه‌داده‌های طلایی (Golden Datasets) — یعنی خروجی‌های مورد انتظار و نمونه‌های «درست» (Known Good Traces) برای نمره دادن به یک عامل — مانند کدهای استاتیک برخورد می‌کنند. اما این داده‌ها در واقع کدهایی هستند که به محیط تولید می‌روند و سپس دیگر هرگز مورد بازبینی کد (Code Review) قرار نمی‌گیرند. طبق راهنمای فنی منتشرشده در ۹ اوت ۲۰۲۶ در وب‌سایت dev.to، این اوراکل‌های ارزیابی به‌طور خاموش فاسد می‌شوند چون پاس کردن تست‌ها به جای اینکه ادعایی باشد که نیاز به اعتبارسنجی مداوم دارد، به اشتباه به عنوان پایان داستان تلقی می‌شود.

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

• تغییرات API (API Drift): ساختار پاسخ یک API تغییر می‌کند و خروجی «مورد انتظار» شما اکنون توصیف‌کننده نقطه پایانی (Endpoint) است که دیگر وجود ندارد.
• انقضای زمانی: پاسخ‌هایی مثل «مدیرعامل فعلی»، «آخرین نسخه پایدار» یا «پرچم (Flag) توصیه‌شده»، دارای تاریخ انقضای داخلی هستند که در ذات خود تعبیه شده است.
• تغییر سیاست‌ها: یک پاسخ توسط انسان بر اساس سیاستی برچسب زده شده که اکنون به‌روزرسانی شده است؛ به این معنی که ارزیابی فعلی، قوانین فصل گذشته را تحمیل می‌کند.
• توهم‌های منجمد: یک رشته متنی مورد انتظار توسط یک مدل تولید شده است و تیم هرگز بررسی نکرده که آیا آن پاسخ واقعاً درست بوده یا خیر. آن‌ها یک حدس پذیرفتنی را منجمد کرده و آن را به عنوان «حقیقت» نامیده‌اند.

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

برای مقابله با این بحران، چارچوب agent-eval پیشنهاد می‌کند شواهد را بر اساس «استقلال» (اینکه سیگنال چقدر قابل جعل است) رتبه‌بندی کنیم، نه بر اساس هزینه (ارزان در برابر گران). این کار باعث تفکیک داده مرجع (Ground Truth) از نظرات تولیدشده توسط مدل می‌شود. این رویکرد یادآور تغییر پارادایم از سنجش کیفیت متن به صحت اقدام است که در آن نتایج قطعی جایگزین ارزیابی‌های ذهنی می‌شوند:

• لایه ۱ (اثبات مشاهده‌پذیر خارجی): این‌ها واقعیت‌هایی هستند که عامل نمی‌تواند جعل کند. نمونه‌ها شامل این موارد است: یک JSON معتبر، URLهایی که Resolve می‌شوند، فایلی که روی دیسک وجود دارد، کامپایل موفق کد، پاس شدن تست‌ها، پایان یافتن عملیات در بازه زمانی تعیین شده (Timeout) یا خروجی غیرخالی. این لایه‌ها به‌ندرت می‌پوسند چون جهان در هر اجرا خودش را اعتبارسنجی می‌کند. در واقع این لایه با رویکرد اثبات صحت کد همسو است که در آن مدل مجبور می‌شود درستی خروجی خود را از طریق شواهد خارجی ثابت کند.
• لایه ۲ (سیگنال‌های آماری): سیگنال‌هایی در برابر یک خط‌کشی (Baseline) که عامل نویسنده آن نیست. این شامل شباهت بردار معنایی (Embedding Similarity) با تسک، بررسی‌های طول متن و تکرار، و این است که آیا یک Diff واقعاً چیزی را تغییر داده است یا خیر. این‌ها به‌کندی می‌پوسند و با تغییر تسک‌ها، سیگنالی قابل فهم ارائه می‌دهند. (بردار معنایی شبیه کارت معرفی عددی برای هر واژه است که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است).
• لایه ۳ (مدل به‌مثابه داور): یک نظر با زیربنای مشترک (Shared-substrate) که در آن یک مدل، مدل دیگر را نمره می‌دهد. این تنها یک سیگنال است و هرگز یک حکم نهایی نیست؛ چون داور و مورد داوری از یک زیربنای مشترک هستند و هیچ حقیقت مستقل در این حلقه وجود ندارد. این لایه دقیقاً همان جایی است که خطای وارونگی اعتماد رخ می‌دهد؛ یعنی زمانی که اطمینان بالای مدل یا داور، لزوماً به معنای صحت پاسخ نیست.

این نگاه لایه‌بندی‌شده منجر به دو قانون ساختاری برای عامل‌های محیط تولید می‌شود. اول اینکه لایه‌های ۱ و ۲ باید درگاه‌های لحظه‌ای (Real-time Gates) شما باشند. به دلیل قطعی و سریع بودن، این‌ها تنها بررسی‌هایی هستند که قادرند یک اجرا را در مسیر بحرانی (Hot Path) متوقف کنند. این بررسی‌ها ممکن است روی کل مسیر (Trajectory) عامل اجرا شوند.

دوم اینکه لایه ۳ باید فقط به‌صورت آفلاین اجرا شود. این بررسی‌ها دارای هزینه (Metered)، کند و غیرقطعی هستند، به این معنی که نمی‌توانند در بودجه تأخیر (Latency Budget) یک درخواست زنده قرار بگیرند. پوسیدگی مجموعه‌داده‌های طلایی دقیقاً زمانی رخ می‌دهد که یک تیم اجازه دهد یک «نظر منجمد» در لایه ۳، خود را به جای یک «واقعیت» در لایه ۱ جا بزند.

بسیاری از شکست‌های واقعی — مانند خروجی‌های قدیمی، کرش‌ها، پاسخ‌های بدشکل، مسیرهای فایل توهمی یا پاسخ‌های خالی — تنها با لایه‌های ۱ و ۲ شناسایی می‌شوند. تیم‌ها باید داور (Judge) را برای حدود ۲۰٪ از مواردsubjective (ذهنی/تفسیری) رزرو کنند و خروجی آن را به عنوان «نظر، و نه مدرک» برچسب بزنند.

برای مدیریت این وضعیت، توسعه‌دهندگان باید یک «قرارداد تازگی» (Freshness Contract) برای نمونه‌ها با ساختاری شبیه به این پیاده کنند:

type Tier = 1 | 2 | 3;
interface GoldenFixture {
  id: string;
  expected: unknown;
  oracleTier: Tier; // نحوه تثبیت «حقیقت»
  capturedAt: string; // برچسب زمانی ISO
  maxAgeDays: number; // تاریخ انقضا برای اوراکل‌های اسنپ‌شات یا نظری
  reverify?: () => Promise<boolean>; // اثبات مجدد لایه ۱ در برابر جهان واقعی
}

با اختصاص یک maxAgeDays و یک برچسب زمانی capturedAt به هر نمونه، تیم‌ها می‌توانند یک «متا-ارزیابی» (Meta-eval) — یعنی ارزیابیِ ارزیابی‌ها — اجرا کنند. اگر یک نمونه لایه ۱ در بررسی reverify() شکست بخورد یا یک نمونه لایه ۳ از maxAgeDays خود فراتر رود، متا-ارزیابی قرمز می‌شود. وقتی این اتفاق می‌افتد، تیم به‌جای تغییر دادن پرامپت‌های عامل، ابتدا اوراکل ارزیابی را بازنگری و اعتبارسنجی می‌کند.

در نهایت، اعتبارسنجی مجدد یک نمونه به چیزی فراتر از رشته متنی نهایی نیاز دارد؛ به Trajectory یا همان مسیر طی شده توسط عامل که نشان می‌دهد خروجی دقیقاً چگونه تولید شده است. اینجاست که امتیازدهی و ثبت سوابق با هم تلاقی می‌کنند.

در حالی که agent-eval خروجی را از طریق لایه‌ها و بررسی‌های توهم نمره می‌دهد و کنترل می‌کند، ابزاری مثل AgentLens تمام ردپای (Trace) کامل را ثبت می‌کند. این ردپا شامل هر فراخوانی مدل، هر گام ابزاری (Tool Step)، ورودی‌های Resolve شده و خروجی خام است. ردپا همان چیزی است که لایه‌های ۱ و ۲ را ممکن می‌سازد، زیرا این لایه‌ها به داده‌های مسیری نیاز دارند که توسط خودِ عامل نوشته نشده‌اند.

بدون وجود ردپا، اعتبارسنجی مجدد یک نمونه منقضی شده صرفاً حدس زدن است. اما با وجود ردپا، یک مهندس می‌تواند دقیقاً ببیند مقدار مورد انتظار به کدام پاسخ ابزار متصل بوده و آیا مقدار مورد انتظار یک مشاهده واقعی بوده یا یک حدس منجمد شده توسط مدل. این کار فرآیند را از «حدس زدن قصد اوراکل» به «حسابرسی شواهد» (Auditing the Evidence) تبدیل می‌کند.

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

گام بعدی شما

• تمام تست‌های «مدل-به-مثابه-داور» خود را شناسایی کرده و برای آن‌ها تاریخ انقضا (Max Age) تعیین کنید.
• لایه‌های ارزیابی خود را به سه سطح «اثبات خارجی»، «سیگنال آماری» و «نظر مدل» تفکیک نمایید.
• برای هر شکست در تست، ابتدا بررسی کنید آیا داده مرجع (Oracle) هنوز با واقعیت محیط تطابق دارد یا خیر.

اما تأمین سخت‌افزاری برای اجرای این حجم از ارزیابی‌های لایه‌بندی‌شده چالش جدیدی است — به تحلیل ما درباره‌ی بهینه‌سازی هزینه استنتاج در مقیاس بالا مراجعه کنید.