تصور کنید یک برنامهنویس مجازی ساعتها وقت خود را صرف تغییر یک خط کد کند و هر بار با همان خطای قبلی مواجه شود، اما با اطمینانی کامل، همان راهکار شکستخورده را تکرار کند. این کابوس اتلاف هزینه در سیستمهای عاملمحور است که اکنون راهکاری برای مهار آن ارائه شده است. یک عامل کدنویسی خودکار میتواند بدون اینکه هرگز کرش کند، شکست بخورد؛ در واقع او ساعتها را صرف تلاشهای مودبانه برای اجرای یک اصلاحیه معیوب در یک حلقه تکرار میکند.
به گزارش یک توسعهدهنده در ۲۹ سپتامبر ۲۰۲۶، یک فرآیند نظارتی مجزا (Watchdog) طراحی شده است که میتواند وضعیتهای «گیر کرده» را از بیرون تشخیص دهد تا از اتلاف توکنها جلوگیری کند. این سیستم برخلاف مدلهای داخلی، به توهمات مدل اعتماد نمیکند و تنها رفتار بیرونی را میسنجد.
ماهیت شکست
این توسعهدهنده یک سیستم پیادهسازی کاملاً خودکار را اجرا میکند که در آن یک ماژول ارکستراتور (هماهنگکننده)، وظایف را به عاملهای پیادهسازی موازی میسپارد. در حالی که مدیریت کرشها آسان است زیرا آنها کدهای خروج (exit codes) و ردپاهای پشته (stack traces) ارائه میدهند، اما «حلقه تکرار» یک شکست خاموش است. این چالش دقیقاً همان نقطهای است که بسیاری از عاملهای کدنویس در بنبستهای تکراری گرفتار شده و نرخ موفقیت آنها را به شدت کاهش میدهد.
در یک مورد واقعی، لاگها نشان دادند که یک عامل — شبیه به کارآموزی که دستورات را بدون فکر کردن تکرار میکند — در یک چرخه معیوب افتاده بود. این عامل در ساعت ۰۲:۱۴ آزمونی را اجرا کرد و با یک شکست در test_export_handles_empty_rows مواجه شد. در ساعت ۰۲:۱۵، او فایل exporter.py را ویرایش کرد تا یک بررسی مقدار تهی (null check) را تغییر دهد. تا ساعت ۰۲:۱۶، آزمون دوباره شکست خورد. در ساعت ۰۲:۱۷، او تغییر مربوط به null check را لغو کرد و یک آرگومان پیشفرض را تغییر داد، اما آزمون در ساعت ۰۲:۱۸ دوباره شکست خورد. تا ساعت ۰۲:۱۹، او دوباره به تغییر همان null check بازگشته بود.
بیشتر سیستمهای فعلی از محدودیت تعداد تکرار (max-iteration caps) یا مهلتهای زمانی (wall-clock timeouts) برای متوقف کردن فرآیندهای runaway استفاده میکنند. اما این ابزارهای خام نمیتوانند تفاوت بین یک بازنویسی پیچیده که بهطور مشروع زمانبر است و یک حلقه تکرار که هیچ پیشرفتی ایجاد نمیکند را تشخیص دهند. تجربیات تلخ از نادیده گرفتن مهلتهای زمانی دقیق نشان داده است که یک عامل میتواند ساعتها در سکوت مطلق متوقف شود و منابع را هدر دهد. همانطور که این توسعهدهنده در گزارشی در dev.to اشاره کرد، یک عامل گیر کرده و یک عامل سختکوش، توکنها را با نرخ دقیقاً یکسانی میسوزانند. هیچکدام از این معیارهای زمانی، پیشرفت را اندازه نمیگیرند؛ آنها فقط تلاش را اندازه میگیرند.
برای حل این مشکل، سیستم یک واچداگ پیادهسازی میکند که استدلالهای داخلی عامل را نادیده میگیرد و فقط جریان رویدادها (event stream) را نظارت میکند. این امر تضمین میکند که ناظر در برابر خوشبینی عامل یا توجیهات مطمئن اما نادرست او برای تکرار یک مرحله شکستخورده، مصون باشد. واچداگ بررسی میکند که کدام ابزارها فراخوانی شدهاند، چه آرگومانهایی استفاده شده و چه نتایجی بازگردانده شده است.
سه سیگنال تشخیص
این سامانه نظارتی برای شناسایی حلقهها از سه سیگنال کمهزینه استفاده میکند که نیازی به فراخوانی مجدد مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — ندارند:
اثر انگشت اقدامات تکراری: سیستم هر فراخوانی ابزار را با نرمالسازی آرگومانها به یک اثر انگشت تبدیل میکند. این سیستم از یک پیادهسازی پایتون ۳.۱۳ استفاده میکند که از
hashlib.sha1برای تبدیل نام ابزارها و آرگومانها به یک شناسه ۱۲ کاراکتری بهره میبرد. بهطور خاص، از عبارات منظم (regular expressions) برای جایگزینی ارقام با حرف "N" استفاده میکند (تا شماره خطوط و برچسبهای زمانی نادیده گرفته شوند) و نویزهای مربوط به فاصلههای خالی (whitespace) را حذف میکند. اگر یک اثر انگشت خاص ۴ بار در یک پنجره لغزان ۳۰ رویدادی ظاهر شود، سیگنال فعال میشود. این کار مانع از آن میشود که سیستم وظایف سالم و طولانی را که ممکن است یک مجموعه آزمون را ۱۰ بار اجرا کنند، متوقف کند، در حالی که مواردی را که یک دستور یکسان را ۴ بار در ۳۰ رویداد تکرار میکنند، شکار میکند.رکود درخت کاری: این سیگنال وضعیت مخزن کد را با استفاده از هشهای
git diff HEADردیابی میکند. سیستم از یک کلاسProgressSignalبا آستانه «صبر» (patience) برابر با ۳ استفاده میکند. اگر عامل ویرایشهایی انجام دهد اما مخزن به وضعیتی بازگردد که قبلاً دیده شده است (نوسان A-B-A-B)، واچداگ عدم پیشرفت خالص را تشخیص میدهد. این مورد شرایطی را میگیرد که در آن عامل ویرایشهای متفاوتی انجام میدهد، اما آن ویرایشها در نهایت منجر به بازگشت به وضعیت قبلی کد میشوند.تکرار خطا: سیستم امضاهای خطا را استخراج میکند، مانند نام یک آزمون شکستخورده خاص یا نوع یک استثنا (exception) ترکیب شده با بالاترین فریم پشته. کلاس
ErrorRecurrenceSignalاین موارد را در یک شمارنده ردیابی میکند. اگر ۵ تلاش مختلف برای رفع مشکل به یک امضای خطای یکسان ختم شوند، سیستم نتیجه میگیرد که مدل ذهنی عامل از باگ اساساً غلط است. منطق این است که تلاش ششم که بر اساس همان مدل معیوب ساخته شده باشد، کمکی نخواهد کرد.
نردبان تصاعدی
تشخیص تنها نیمی از راهکار است؛ سیستم سپس یک پاسخ لایهبندی شده را برای بازیابی وظیفه بدون از دست دادن تمام پیشرفتها اعمال میکند:
۱. تلنگر (Nudge): وقتی هر یک از سیگنالها فعال شود، واچداگ پیامی را به نوبت بعدی عامل تزریق میکند. این پیام عامل را از حلقه مشاهده شده مطلع میکند — برای مثال، اشاره میکند که ۴ تلاش اخیر با همان شکست به پایان رسید یا درخت کد ۳ بار به وضعیت قبلی بازگشت. از عامل خواسته میشود پیش از ویرایش مجدد، یک فرضیه قابل اثبات (falsifiable hypothesis) درباره علت ریشهای و شواهدی که میتواند آن را رد کند، بنویسد. این رویکرد شباهت زیادی به متدولوژی CodeTeach دارد که به جای ارائه پاسخ مستقیم، با ایجاد چالشهای سازنده، مدل را به سمت درک عمیقتر هدایت میکند. این کار عامل را مجبور میکند به جای ویرایش کورکورانه، کد را بخواند.
۲. بازراهاندازی تازه: اگر تلنگر شکست بخورد و سیگنال دوباره فعال شود، سیستم عامل فعلی را متوقف کرده و عامل جدیدی را شروع میکند. این عامل جدید، وظیفه اصلی و یک یادداشت تحویل (handoff note) دریافت میکند. این یادداشت شامل لیستی از «اقدامات ممنوعه» است که از روی اثر انگشتها تولید شده است، مانند «تغییر null check در مسیر export» یا «تغییر آرگومان پیشفرض برای مدیریت ردیفها». این کار مانع از آن میشود که نمونه جدید روی همان اشتباهات قبلی متمرکز شود.
۳. پارک کردن: اگر عامل بازراهاندازی شده نیز متوقف شود، وظیفه به صف بررسی انسانی منتقل میشود. این اقدام پذیرش این واقعیت است که برخی وظایف به دلیل مشخصات متناقض یا وابستگیهای خراب، غیرممکن هستند. این یک «خروج صادقانه» برای توقف هزینه توکنها روی یک مسئله حلناپذیر است.
درسهای مهندسی
توسعهدهنده دریافت که نرمالسازی دادهها پیش از مقایسه، بزرگترین بهبود در دقت تشخیص بود. اولین اثر انگشت او یک هش دقیق از آرگومانها بود که تقریباً هیچ چیز را شکار نمیکرد، زیرا عاملها بهندرت کلمات را دقیقاً بایتبهبایت تکرار میکنند و اغلب شماره خط را تغییر میدهند یا عبارت جستجو را بازنویسی میکنند. حذف فاصلههای خالی و ارقام این مشکل را حل کرد.
علاوه بر این، سیستم ثابت میکند که «مثبت کاذب» (تشخیص اشتباه حلقه) ارزانتر از «منفی کاذب» (ندیدن حلقه) است. یک تلنگر اشتباه تنها هزینه یک نوبت محاسبات دارد — عامل صرفاً تأیید میکند که در حال پیشرفت است و ادامه میدهد — در حالی که یک حلقه نادیده گرفته شده میتواند ساعتها هزینه توکن و زمان محاسباتی به بار آورد. در نتیجه، آستانهها بهگونهای تنظیم شدهاند که در سطح ۱ سریعاً فعال شوند (trigger-happy) و در سطح ۳ محافظهکارانه باشند.
سایر نکات کلیدی عبارتند از:
- مشاهده خارجی: عامل نمیتواند واچداگ خودش باشد، زیرا آنچه در یک حلقه خراب شده است، قضاوت عامل درباره وضعیت خودش است.
- حفظ دانش: کشتن فوری یک فرآیند، بدترین پاسخ است. نردبان تصاعدی دانش را حفظ میکند: تلنگر تمام زمینه (context) را نگه میدارد و بازراهاندازی یک خلاصه را حفظ میکند.
بهبودهای آینده
توسعهدهنده قصد دارد سیستم را در سه جهت گسترش دهد. اول، تکرار معنایی (semantic repetition) با استفاده از یک مدل کوچک برای خلاصه کردن قصدِ یک تلاش، تا اصلاحاتی که ظاهر متفاوتی دارند اما ایده معیوب یکسانی را به اشتراک میگذارند، شناسایی شوند. دوم، آستانههای متناسب با نوع وظیفه؛ زیرا برای مثال، یک بهروزرسانی وابستگی ممکن است بهطور مشروع یک دستور نصب را چندین بار اجرا کند و در این حالت، یک پنجره ثابت بیش از حد سختگیرانه باشد. در نهایت، سیستم وظایف پارک شده را به فرآیند نوشتن وظایف بازمیگرداند تا نحوه نوشتن مشخصات اولیه توسط ماژول ارکستراتور بهبود یابد.
این رویکرد تمرکز را از اندازهگیری تلاش — اینکه یک عامل چه مدت اجرا شده است — به اندازهگیری پیشرفت — اینکه آیا عامل واقعاً به سمت راهکار حرکت میکند یا خیر — تغییر میدهد. با treating کردن عامل به عنوان یک جعبه سیاه و نظارت تنها بر رفتار بیرونی آن، واچداگ یک شبکه ایمنی قابل اعتماد برای سیستمهای پیادهسازی AI بدون نظارت فراهم میکند.
گام بعدی شما
- اگر از عاملهای کدنویسی خودکار استفاده میکنید، لاگهای تکراری را بررسی کنید تا ببینید چه تعداد از توکنهای شما در حلقههای A-B-A-B تلف میشود.
- برای سیستمهای خود، یک لایه نظارتی بیرونی (External Monitor) پیادهسازی کنید که مستقل از استدلال مدل باشد.
- مکانیسم «تلنگر زدن» را به جای توقف کامل فرآیند، برای افزایش دقت مدلها به کار ببرید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو