تأیید اثر به‌جای تأیید اجرا؛ راهکار مقابله با شکست‌های خاموش عامل‌های هوش مصنوعی

تصور کنید سیستمی را مدیریت می‌کنید که هر شب با دقت ساعت سوئیسی اجرا می‌شود و تمام چراغ‌های داشبورد آن سبز است، اما در واقع هیچ کاری انجام نمی‌دهد. این کابوس «شکست خاموش» (Silent No-op) است؛ وضعیتی که در آن تمام لایه‌های یک پشته فنی — از زمان‌بند (Scheduler) گرفته تا پاسخ API — چراغ سبز نشان می‌دهند، اما یک شغل اتوماسیون زمان‌بندی شده می‌تواند برای هفته‌ها نرخ موفقیت کامل را گزارش کند در حالی که عملاً هیچ کار واقعی انجام نمی‌دهد. این یک فقدان کامل از خروجی است که پشت دیواری از موفقیت‌های فنی پنهان شده است.

بیشتر توسعه‌دهندگان برای نظارت بر عامل‌های خود به کدهای وضعیت (Status Codes) و لاگ‌های خطا تکیه می‌کنند. اگر یک فرآیند با کد خروج ۰ خارج شود و پاسخ HTTP برابر با ۲۰۰ باشد، سیستم معمولاً «سالم» تلقی می‌شود. اما همان‌طور که در گزارشی منتشرشده در dev.to در ۲۳ سپتامبر ۲۰۲۶ آمده است، این رویکرد در واقع «نظر سیستم درباره خودش» را اندازه‌گیری می‌کند، نه تأثیر واقعی آن بر دنیای بیرون.

کالبدشکافی یک شکست خاموش

این نقص زمانی آغاز شد که یک شغل شبانه، که برای ساعت ۰۲:۳۰ زمان‌بندی شده بود، دیگر داده‌ای تحویل نمی‌داد. این شغل طراحی شده بود تا پرونده‌های جدید را از یک API استخراج کند، آن‌ها را نرمال‌سازی نماید و در یک صف برای گزارش صبحگاهی قرار دهد. برای شش هفته، داشبورد زمان‌بندی ۴۰ اجرای متوالی سبز را نشان می‌داد. هر یک از این اجراها کد خروج ۰ را برمی‌گرداندند. هیچ خطایی در لاگ‌ها ثبت نشده بود، زیرا API نام یک پارامتر کوئری را از since به from_date تغییر داده بود.

از آنجا که API به‌گونه‌ای طراحی شده بود که پارامترهای ناشناخته را با خوش‌رویی نادیده بگیرد، همچنان وضعیت ۲۰۰ OK را برمی‌گرداند. با این حال، به‌جای داده‌های درخواستی، یک آرایه خالی ارسال می‌کرد. حلقه تکرار (for-loop) عامل در پایتون، به‌سادگی روی این لیست خالی می‌چرخید و طبق رفتار استاندارد برای مجموعه‌های تهی در پایتون، اجرای خود را با موفقیت به پایان می‌رساند. نویسنده تنها زمانی متوجه این شکست شد که گزارش‌های صبحگاهی «لاغر» شدند؛ به‌طوری که برخی روزها تنها دو مورد و برخی روزها هیچ موردی در گزارش نبود. او در ابتدا این موضوع را به اشتباه به‌عنوان «کم بودن اخبار» (Slow News) نادیده گرفت.

چرا نظارت سنتی شکست می‌خورد؟

ابزارهای نظارتی استاندارد برای شکار «رویدادها» (Events) طراحی شده‌اند؛ مانند جهش در نرخ خطا، اتمام زمان انتظار (Timeouts) یا کرش کردن سیستم. نویسنده اشاره می‌کند که در حالی که آن‌ها مکانیزم‌های قطع‌کننده (Circuit Breakers) برای شکست‌های سخت، یک مانیتور سلامت برای عامل‌هایی که در حال مرگ هستند و سیستم حذف تکرار (Deduplication) برای شغل‌هایی که دو بار اجرا می‌شوند داشتند، اما هیچ‌یک از این ابزارها برای رصد «چیزی که اتفاق نمی‌افتد» طراحی نشده بودند. این نوع نقص در نظارت می‌تواند منجر به رفتارهای پیش‌بینی‌نشده‌ای شود، مشابه آنچه در حادثه مربوط به حلقه‌های تکرار نامحدود در عامل‌های کدنویسی مشاهده شد که در آن نبودِ یک مکانیزم توقف دقیق، هزینه‌های سنگینی ایجاد کرد.

یک استثنا (Exception) لحظه شکست مشخصی دارد: رخ می‌دهد، توسط یک هندلر گرفته می‌شود و یک هشدار ارسال می‌گردد. اما یک «عملیات تهی» (Silent No-op) چنین لحظه‌ای ندارد؛ این نوع شکست تنها در طول زمان یک «شکل» یا الگو ایجاد می‌کند. اگر داشبورد فقط وضعیت اجرا (موفق/ناموفق) و مدت زمان اجرا را رصد کند، شغلی که هیچ کاری نمی‌کند، دقیقاً شبیه شغلی است که همه چیز را بی‌نقص انجام داده است. در این مورد خاص، سیستم نظارتی در حال رسم نمودار چیز اشتباهی بود؛ وضعیت سیستم را رصد می‌کرد اما اثرات تولید شده توسط آن را خیر.

پیاده‌سازی تأیید اثر (Effect Assertions)

برای حل این مشکل، توسعه‌دهنده قانونی را تعریف کرد: «اثر را تأیید کن، نه تلاش را». این یعنی هر شغل باید اعلام کند که یک اجرای موفق از نظر اثرات جانبی (Side Effects) چگونه است؛ مثلاً تعداد ردیف‌های نوشته‌شده، پیام‌های ارسال‌شده، فایل‌های ایجادشده یا شناسه‌های (IDs) تولید شده. شغل باید این اثر را تأیید کند تا بتواند وضعیت «موفق» گزارش دهد. این رویکرد در واقع نوعی سخت‌گیری سیستمی است که در مقایسه با شهود انسانی در استقرار AI کارایی بسیار بیشتری در شناسایی نقاط شکست دارد.

برای پیاده‌سازی این موضوع، نویسنده از یک تابع کمکی برای ایجاد یک خطای خاص در صورت عدم تولید اثر استفاده می‌کند:

def assert_effect(name, produced, expected=">=1"):
    if expected == ">=1" and produced < 1:
        raise JobProducedNothingError(
            f"{name}: ran fine, produced {produced} effects"
        )
    log.info("%s: effect ok (%s)", name, produced)

تفاوت‌های کلیدی در این رویکرد عبارتند از:

• بررسی تلاش (Attempt Check): resp.status_code == 200 (این فقط ثابت می‌کند که درخواست ارسال شده و سرور پاسخ داده است).
• بررسی اثر (Effect Check): len(written_ids) > 0 (این ثابت می‌کند که کار واقعاً انجام شده است).
• پرهیز از تکرار بدیهیات (Avoiding Tautologies): نویسنده هشدار می‌دهد از تأییداتی مثل assert len(rows) >= 0 پرهیز کنید؛ زیرا این یک «بدیهی با جلیقه ایمنی» است، چون هرگز روی یک لیست خالی شکست نمی‌خورد و عملاً هیچ کاربردی ندارد.

مدیریت «تهی بودن» مشروع

هر شغلی نباید هر بار نتیجه تولید کند. برای مثال، یک ناظر (Watcher) برای یک فید خبری آرام ممکن است به‌طور مشروع صفر مورد پیدا کند. برای جلوگیری از هشدارهای کاذب و جلوگیری از بی‌توجهی به کانال‌های هشدار (Muted Alert Channel)، نویسنده پیشنهاد می‌کند به‌جای شمارش، روی «پوشش» (Envelope) پاسخ تأیید انجام شود. این متدولوژی برای جلوگیری از خود‌تصحیحی‌های کاذب مشابه است با آنچه در معماری فقط‌داور برای ممیزی داخلی عامل‌های AI به کار گرفته می‌شود تا از صحت خروجی‌ها اطمینان حاصل شود.

اگر یک API به‌جای یک پاسخ ساختاریافته که شامل نشانگر صفحه‌بندی (Pagination Cursor) و تعداد کل است، فقط یک لیست خالی [] برگرداند، این نشان می‌دهد که کوئری نادیده گرفته شده است، نه اینکه صرفاً نتیجه‌ای وجود نداشته باشد. در مورد نویسنده، یک نتیجه تهی واقعی باید شامل یک نشانگر و تعداد کل می‌بود؛ اما پاسخی که در اثر نادیده گرفته شدن پارامتر ایجاد شده بود، صرفاً یک آرایه لخت و خالی بود.

پیاده‌سازی عملی برای کارهایی که ممکن است به‌طور مشروع خروجی نداشته باشند:

data = api.get("/filings", params={"from_date": since})
if not isinstance(data, dict) or "items" not in data:
    raise UnexpectedShapeError(f"got {type(data)}: {str(data)[:80]}")
items = data["items"]
# صفر در اینجا پذیرفتنی است — چون ثابت کردیم کوئری پذیرفته شده است

مدل موفقیت سه-حالتی

برای کاربردی کردن این روش در محیط عملیاتی، نویسنده مدل موفقیت را از حالت دوتایی (موفق/ناموفق) به یک سیستم سه-حالتی تغییر داد. این کار تضمین می‌کند که «روزهای آرام» باعث فعال شدن هشدارها نشوند، در حالی که شکست‌های واقعی شناسایی گردند:

۱. succeeded_with_effect: شغل کار را انجام داد و یک شمارش قابل اندازه‌گیری تولید کرد.
۲. no_work_needed: شغل چیزی تولید نکرد، اما از طریق بررسی پوشش (Envelope Check) ثابت شد که «هیچ» پاسخ صحیح است (درخواست موفق بود و شکل مورد انتظار را برگرداند).
۳. failed: شغل چیزی تولید نکرد و نبودِ اثر توجیه نشد، که منجر به ایجاد خطای JobProducedNothingError می‌شود.

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

تأثیر در دنیای واقعی

پس از پیاده‌سازی شمارنده‌های اثر، توسعه‌دهنده در عرض یک ماه دو شکست خاموش دیگر را شناسایی کرد که در غیر این صورت نامرئی می‌ماندند:

• کاهش سطح دسترسی (Privilege Downgrade): یک توکن منقضی شده بود و به‌طور خاموش با یک نشست ناشناس با سطح دسترسی پایین‌تر جایگزین شد. API همچنان وضعیت ۲۰۰ OK برمی‌گرداند، اما نتایج خالی بود.
• تغییر مسیر فایل (Path Change): تغییری در مسیرهای فایل باعث شد یک شغل پایین‌دستی، یک دایرکتوری خالی را بخواند و یک فایل خالی اما معتبر بنویسد.

هیچ‌کدام از این حوادث استثنایی (Exception) ایجاد نکردند. هر دو برای نظارت‌های مبتنی بر وضعیت نامرئی بودند، اما در نمودار «اثرات در هر اجرا» فوراً به‌عنوان یک خط صاف (Flatline) ظاهر شدند. درس اصلی این است: شغلی که اجرا می‌شود و برای همیشه هیچ چیز تولید نمی‌کند، سالم نیست؛ بلکه شبیه چراغ سبزی است که لامپش پیچیده نشده است.

بخش قابل انتقال (The Transferable Bit)

برای هر پشته فنی — خواه یک ETL شبانه باشد، یا یک مصرف‌کننده وب‌هوک (Webhook Consumer)، یک مرحله CI یا یک عامل هوشمند — قانون این است که «نبودِ خطا» با «کار کردن» یکی نیست. ارکستراتورها و ابزارهای CI برای فرآیندی که هیچ چیز را کوئری نکرده و هیچ چیز ننوشته است، موفقیت گزارش می‌کنند، زیرا این همان چیزی است که از آن‌ها خواسته شده اندازه‌گیری کنند.

توسعه‌دهندگان باید برای هر واحد کاری، یک عدد را انتخاب کنند که اگر کار به‌طور خاموش متوقف شد، حتماً صفر شود. روی آن عدد تأیید (Assert) کنید، آن را در طول زمان رصد کنید و مطمئن شوید که هشدارها می‌توانند روی یک «خط صاف» فعال شوند، نه فقط روی یک «جهش». در حالی که جهش‌ها بلند و خودگزارش‌دهنده هستند، خطوط صاف نیازمند نظارت آگاهانه و عمدی هستند.

گام بعدی شما

• برای هر عامل یا اتوماسیونی که دارید، یک «عدد اثر» (Effect Number) تعریف کنید که اگر کار متوقف شد، حتماً صفر شود.
• نظارت خود را از رصد «جهش‌های خطا» (Spikes) به رصد «خطوط صاف» (Flatlines) در نمودار خروجی‌ها تغییر دهید.
• در توابع API، به‌جای پذیرش هر پاسخ ۲۰۰، ساختار (Shape) پاسخ را اعتبارسنجی کنید تا از نادیده گرفته شدن پارامترها مطمئن شوید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.