توهم بنچمارک تألیفی
بیشتر مجموعه‌های ارزیابی ایجنت با فهرستی از وظایفی آغاز می‌شوند که تیم از قبل در ذهن دارد: رزرو پرواز، خلاصه‌سازی یک سند، حل یک تیکت پشتیبانی. این وظایف برای تست دودی مفیدند، اما یک نقص ساختاری مشترک دارند. آن‌ها از همان تخیلاتی برگرفته شده‌اند که ایجنت را تولید کرده‌اند. وظایفی که تیم به آن‌ها فکر کرده، تقریباً طبق تعریف، همان وظایفی هستند که ایجنت از قبل انجام می‌دهد. بنچمارکی که هرگز شکست نمی‌خورد بنچمارک نیست؛ آینه است.
شکست‌هایی که اهمیت دارند در دنباله توزیع زندگی می‌کنند: ترتیب فراخوانی ابزارهایی که کسی پیش‌بینی نکرده، طوفان‌های تلاش مجدد ناشی از یک سرویس بالادستی ناپایدار، نوشتن‌های ناقصی که وضعیت را ناسازگار می‌گذارند، نسخه مدلی که بی‌صدا تفسیر یک اسکیما را تغییر می‌دهد. این ترکیب‌ها طراحی نمی‌شوند. کشف می‌شوند. و تنها منبع قابل اعتماد شکست‌های کشف‌شده، تولید است.
به همین دلیل ارزیابی ایجنت‌ها باید بازپخش رخداد باشد. پیکره رگرسیون یک مجموعه گزینش‌شده از سناریوهای خیالی نیست؛ آرشیوی روبه‌رشد از مسیرهای واقعی است، که هر یک فیکسچری است که شکستی را رمزگذاری می‌کند که سیستم واقعاً از خود نشان داده. این تغییر به همان اندازه که فنی است، فرهنگی نیز هست: مجموعه ارزیابی به محصول جانبی عملیات تبدیل می‌شود، نه یک تمرین تألیف جداگانه.
یک بازپخش رخداد واقعاً چه چیزی در خود دارد
یک رد تولید غنی‌تر از یک جفت پرامپت-پاسخ است. یک رخداد قابل بازپخش حداقل چهار لایه دارد:
- وضعیت ورودی: درخواست کاربر، تاریخچه مکالمه، زمینه بازیابی‌شده، و هر وضعیت محیطی (فلگ‌های ویژگی، پیکربندی مستأجر، فراداده نشست).
- توالی فراخوانی ابزار: فهرست مرتب فراخوانی‌های ابزار، شامل آرگومان‌ها، هویت فراخوان، و مقصد خروجی.
- مشاهدات میانی: نتایج ابزار، بارهای خطا، تأخیر، و هر تلاش مجدد یا جایگزین.
- عوارض جانبی نهایی: پاسخ نهایی، و همچنین نوشتن‌ها، ایمیل‌ها، تیکت‌ها، یا تغییر وضعیت‌هایی که ایجنت ایجاد کرده.
ثبت این لایه‌ها لازم است اما کافی نیست. یک بازپخش باید قطعی باشد. نقاط پایانی خارجی با پاسخ‌های ضبط‌شده جایگزین می‌شوند؛ ساعت‌ها متوقف یا تزریق می‌شوند؛ نسخه‌های مدل به همان اسنپ‌شاتی که رد را تولید کرده پین می‌شوند. بدون قطعیت، بازپخش یک بازسازی است و سیگنال قبولی/رد آن نویز است.
بنابراین وفاداری بازپخش پیش از آنکه یک مسئله ارزیابی باشد، یک مسئله خط لوله داده است. تیم‌هایی که ردیابی را به عنوان یک فکر بعدی می‌بینند، کشف می‌کنند که رخدادهایشان قابل بازپخش نیستند: پاسخ‌های ابزار ثبت نشده‌اند، نسخه مدل ثبت نشده، ساعت ثبت نشده. راه‌حل در بالادست است: ایجنت را ابزارگذاری کنید تا هر مسیر یک مصنوع درجه‌یک و نسخه‌دار باشد.
یک هارنس رگرسیون حداقلی
هارنسی که اینجا توصیف می‌شود عمداً کوچک است. سه مؤلفه را فرض می‌کند: یک مخزن رد، یک اجراکننده بازپخش، و یک دروازه ادغام.
ردها را به عنوان مصنوعات نسخه‌دار ذخیره کنید
ردها در کنار کدی که آن‌ها را تولید کرده ذخیره می‌شوند، نه در یک پایگاه داده جداگانه که منحرف می‌شود. یک مصنوع رد شامل وضعیت ورودی، توالی ابزار، مشاهدات، و عوارض جانبی نهایی، به علاوه نسخه مدل و هش پیکربندی ایجنت است. نسخه‌دار کردن مصنوع یعنی یک تغییر در ایجنت می‌تواند در برابر زمینه تاریخی دقیق ارزیابی شود.
# trace-2025-03-14-001.yaml
trace_id: 2025-03-14-001
agent_config_hash: 9f2c...
model_version: gpt-4.1-2025-04-14
input_state:
user_request: "reconcile invoice 8842"
conversation: [...]
tool_sequence:
- name: fetch_invoice
args: {id: 8842}
result: {status: 200, body: {...}}
- name: post_ledger_entry
args: {amount: 120.00, account: "AR"}
result: {status: 500, error: "timeout"}
terminal_side_effects:
- type: ledger_entry
status: not_written
بر اساس ویژگی‌های مسیر امتیاز دهید، نه فقط پاسخ نهایی
دقت پاسخ نهایی سیگنال ضعیفی برای ایجنت‌هاست. پاسخ درستی که نیاز به یک فراخوانی ابزار خطرناک، یک خروجی غیرمجاز، یا یک طوفان تلاش مجدد داشته، قبولی نیست. هارنس ویژگی‌های مسیر را امتیاز می‌دهد:
- مجموعه ابزار: کدام ابزارها فراخوانی شده‌اند، و آیا هیچ‌کدام خارج از مجموعه مجاز بوده‌اند.
- ترتیب: آیا توالی به وابستگی‌ها و محدودیت‌های خودتوانی احترام می‌گذارد.
- مقاصد خروجی: کدام نقاط پایانی خارجی تماس گرفته شده‌اند، و آیا با لیست مجاز مطابقت دارند.
- رفتار تلاش مجدد: چند تلاش مجدد رخ داده، و آیا محدود بوده‌اند.
- سازگاری عوارض جانبی: آیا وضعیت نهایی با توجه به شکست‌های میانی منسجم است.
این ویژگی‌ها بدون یک مدل داور قابل بررسی هستند. قطعی، سریع و قابل توضیح‌اند. بازپخشی که در مجموعه ابزار یا خروجی شکست می‌خورد یک رخداد امنیتی یا قابلیت اطمینان است، نه یک رگرسیون
هارنس روی هر پول ریکوئست اجرا می‌شود. دروازه یک امتیاز واحد نیست بلکه نرخ قبولی در سراسر پیکره است، با یک سیاست برای رگرسیون‌ها: هر ردی که در شاخه پایه قبول شده و در شاخه سر شکست می‌خورد، ادغام را مسدود می‌کند مگر اینکه صریحاً با دلیل ثبت‌شده معاف شود. رخدادهای جدید به عنوان فیکسچرهای اجباری جدید در نظر گرفته می‌شوند. وقتی یک رخداد حل می‌شود، ردی که آن را بازتولید کرده در همان پول ریکوئست به عنوان اصلاح به پیکره اضافه می‌شود.
این مکانیزمی است که عملیات را به ارزیابی تبدیل می‌کند. پیکره با سطح شکست واقعی سیستم رشد می‌کند، نه با تخیلات تیم.
هزینه‌ها و محدودیت‌ها
یک پیکره بازپخش به صورت یکنوا رشد می‌کند. هر رخداد یک فیکسچر اضافه می‌کند، و فیکسچرها ذخیره‌شان ارزان است اما اجرایشان گران. معامله صادقانه بین پوشش و زمان اجراست. پیکره‌ای که بازپخشش یک ساعت طول می‌کشد نادیده گرفته می‌شود؛ پیکره‌ای که یک دقیقه طول می‌کشد کم‌نمونه‌برداری می‌شود. پاسخ عمل‌گرایانه یک سیاست هرس است، نه حذف. ردها لایه‌بندی می‌شوند: یک لایه سریع روی هر کامیت اجرا می‌شود (یک زیرمجموعه کوچک با سیگنال بالا)، یک لایه کامل شبانه اجرا می‌شود، و یک لایه آرشیو برای استفاده پزشکی قانونی نگهداری می‌شود. هرس یک تصمیم سیاستی درباره اینکه کدام شکست‌ها هنوز نماینده هستند، است، نه یک مسئله جمع‌آوری زباله.
برخی شکست‌ها به طور ساختاری غیرقابل بازتولید هستند. یک شرایط رقابتی که به وضعیت زنده یک شخص ثالث بستگی دارد، یک خرابی داده یک‌باره، یک رفتار مدل که نمی‌تواند پین شود چون ارائه‌دهنده اسنپ‌شات‌ها را افشا نمی‌کند. این‌ها نمی‌توانند وفادارانه بازپخش شوند. وسوسه این است که دور انداخته شوند. تمرین بهتر این است که به عنوان فیکسچرهای ناشناخته-شناخته‌شده ثبت شوند: یک رد با یک مالک، یک توصیف از مکانیزم مشکوک، و یک نشانگر که بخشی از دروازه قبولی/رد نیست. سپس پیکره بین آنچه آزمایش می‌شود و آنچه صرفاً به یاد آورده می‌شود تمایز قائل می‌شود.
محدودیت دوم این است که بازپخش وفاداری به گذشته را می‌سنجد، نه درستی برای آینده. پیکره‌ای که کاملاً از رخدادها ساخته شده باشد، بیش از حد بر حالت‌های شکستی که قبلاً رخ داده‌اند وزن می‌گذارد. این قابل قبول است زیرا جایگزین — پیکره‌ای که از وظایف خیالی ساخته شده — بیش از حد بر حالت‌های شکستی که هرگز رخ نخواهند داد وزن می‌گذارد. نظم این است که پیکره را به عنوان یک سند زنده ببینیم، نه یک مشخصات.
تغییر عملیاتی
استدلال این نیست که بنچمارک‌های تألیفی بی‌فایده‌اند. آن‌ها برای آنبوردینگ، تست دودی، و انتقال قصد مفیدند. استدلال این است که به عنوان سطح ارزیابی اصلی برای ایجنت‌ها ناکافی هستند. شکست‌هایی که اهمیت دارند در تولید کشف می‌شوند، و تنها راه جلوگیری از تکرارشان بازپخش آن‌هاست.
این نیازمند تغییری در نحوه برخورد تیم‌ها با ردهاست: به عنوان مصنوعات نسخه‌دار، نه لاگ. نیازمند تغییری در نحوه برخورد تیم‌ها با رخدادهاست: به عنوان فیکسچرهای اجباری، نه آتش‌های یک‌باره. و نیازمند تغییری در نحوه برخورد تیم‌ها با ارزیابی است: به عنوان آرشیوی روبه‌رشد از مسیرهای واقعی، نه یک مجموعه ایستا از وظایف خیالی.
نتیجه یک پیکره رگرسیون است که رفتار واقعی سیستم را منعکس می‌کند. هرگز کامل نخواهد بود. همیشه از رخداد بعدی عقب‌تر خواهد بود. اما صادقانه خواهد بود، و مفید خواهد بود.