تصور کنید یک توسعه‌دهنده در حال عیب‌یابی عاملی است که در یک مرحله حساس، مسیر اشتباهی را انتخاب کرده و کل عملیات را به شکست کشانده است. در حال حاضر، او مجبور است کل Session را از ابتدا اجرا کند چون نمی‌داند مدل چرا گزینه‌های درست را رد کرده است.
این مشکل ریشه در «مسیرهای پاک» دارد؛ گزارش‌هایی که فقط نتیجه را نشان می‌دهند و توهم می‌کنند انتخاب مدل اجتناب‌ناپذیر بوده است. این نقص در سیستم‌های نظارتی، در واقع ادامه همان چالشی است که در بررسی پیش‌فراخوانی برای جلوگیری از حلقه‌های تکرار هزینهبر به آن پرداختیم، جایی که فقدان داده‌های دقیق در زمان اجرا منجر به تحلیل‌های نادرست می‌شود. طبق یک پیشنهاد فنی از پروژه MonkeyCode که در ۱۴ ژوئیه ۲۰۲۶ ارائه شد، برای حل این بحران باید «لاگ تصمیمات» (Decision Log) جایگزین لاگ‌های سنتی شود. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پایداری عملیاتی عامل‌ها دیدیم، شکاف بین توانایی خام مدل و اجرای واقعی، اغلب در همین نقاط تصمیم‌گیری پنهان شده است.
به نقل از مستندات فنی منتشر شده در dev.to، این سامانه جدید انتخاب را از اجرا جدا می‌کند. در این ساختار، هر رکورد باید شامل موارد زیر باشد:
- شناسه تصمیم (decision_id) و بستر مورد نیاز
- گزینه انتخاب‌شده به همراه شواهد پذیرش
- لیست گزینه‌های ردشده به همراه دلیل رد و شرط بازبینی (revisit_when)
مثلاً اگر مدل از یک آداپتور (Adapter) — شبیه قطعه‌ای که برق یک دستگاه را با پریز خانه سازگار می‌کند — استفاده نکند، باید دقیقاً ذکر شود که چه تغییری در نسخه آداپتور باعث می‌شود مدل دوباره این گزینه را بررسی کند.
برای جلوگیری از انباشت داده‌های زائد، این پیشنهاد یک رابط کاربری سه‌لایه ارائه می‌دهد. ابتدا «خط زمانی» (Timeline) یک یادداشت سطح بالا نمایش می‌دهد؛ سپس بخش «چرا» (Why) یک قضاوت سریع درباره اعتماد ایجاد می‌کند و در نهایت بخش «جزئیات» (Details)، تمام عمق بازرسی شامل گزینه‌های ردشده را باز می‌کند.
بر اساس این پیشنهاد، تفکیک منطق تصمیم از نتیجه اجرا حیاتی است. اگر عامل بر اساس شواهد درستی مدل B را انتخاب کند اما اجرای آن شکست بخورد، لاگ همچنان استدلال اولیه را حفظ می‌کند تا رابط کاربری به اشتباه القا نکند که انتخاب اولیه غلط بوده است. برای تضمین این سخت‌گیری، یک ابزار اعتبارسنج مستقل به نام validate-decision-log.mjs معرفی شده که وجود شواهد و شرایط بازبینی را برای هر رد کردن بررسی می‌کند.
این تغییر، ردیابی عامل‌ها را از یک تاریخچه خطی به یک «بستر خلاف‌واقع» (Counterfactual Context) تبدیل می‌کند. اپراتور اکنون می‌تواند بدون بازسازی کل جلسه، فقط نقطه شکست را به چالش بکشد و مسیر را اصلاح کند.
گام بعدی شما
- در پیاده‌سازی‌های فعلی خود، ستونی برای ثبت «دلایل رد گزینه‌های جایگزین» اضافه کنید.
- تاریخچه‌های «فقط اجرا» را با «لاگ‌های تصمیم‌محور» مقایسه کنید تا کاهش زمان بازیابی (Recovery Time) را بسنجید.
- ابزار
validate-decision-log.mjsرا برای بررسی انضباط داده‌ای در لاگ‌های خود به کار بگیرید.
اما این نظم‌دهی به داده‌ها تنها نیمی از راه است؛ بررسی اینکه چگونه مدل‌های استدلالی می‌توانند خود این لاگ‌ها را برای اصلاح مسیر تحلیل کنند، در گزارش بعدی ما منتشر می‌شود.
گفتگو