«موفقیت کاذب»؛ خطری پنهان در حذف داده‌های تکراری عامل‌های هوش مصنوعی

تصور کنید داشبورد مدیریتی شما تمام چراغ‌های سبز را نشان می‌دهد و گزارش‌ها از موفقیت ۱۰۰ درصدی خبر می‌دهند، اما در واقعیت هیچ خروجی‌ای تولید نشده است. این دقیقاً همان وضعیتی است که در ۳۰ اوت ۲۰۲۶ برای خط لوله‌ی VibeJobHunterAIPA_AIMCF رخ داد؛ جایی که ۱۷۵ مورد داده بدون اینکه حتی یک بار پردازش شوند، در وضعیت «تکمیل‌شده» ثبت شدند. در حالی که سیستم در تاریخ ۳۰ اوت ۲۰۲۶ تعداد ساعتی سالم و موفقیت کلی را گزارش می‌کرد، صف خروجی کاملاً خالی باقی مانده بود.

این تضاد، یک نقص منطقی را در خط لوله‌ی عامل VibeJobHunterAIPA_AIMCF آشکار کرد که منجر شد ۱۷۵ مورد داده به عنوان «تکمیل‌شده» علامت‌گذاری شوند، بدون اینکه حتی یکی از آن‌ها به مراحل پایین‌دستی تحویل داده شود. این اتفاق یک شکست خاموش نبود، بلکه یک «موفقیت بلند و توخالی» بود؛ وضعیتی که در آن ابزارهای نظارتی چراغ سبز نشان می‌دادند اما خروجی واقعی صفر بود.

این حادثه یک آسیب‌پذیری حیاتی در نحوه‌ی مدیریت وضعیت و حذف داده‌های تکراری توسط عامل (Agent) — شبیه به یک کارمند اداری که بدون خواندن نامه‌ها، مهر «رسید شد» می‌زند و آن‌ها را دور می‌اندازد — را آشکار کرد. در بسیاری از گردش‌های کاری خودکار، یک دفتر ثبت برای حذف داده‌های تکراری (Deduplication Ledger) وجود دارد تا سیستم یک مورد را دوبار پردازش نکند. اما اگر ترتیب عملیات اشتباه باشد، سیستم می‌تواند شغل‌ها را «بسوزاند»؛ یعنی پیش از آنکه واقعاً پردازش شوند، آن‌ها را به عنوان موارد مدیریت‌شده علامت بزند.

به نقل از گزارشی از النا رویچوا در AIdeazz، این خطا به این دلیل رخ داد که دفتر ثبت تکراری‌ها، موارد را پیش از اعمال سقف پردازش (Processing Cap) سیستم به عنوان «انجام‌شده» علامت می‌زد. این خط لوله از یک سقف داخلی برای مدیریت مصرف منابع و جلوگیری از فشار بیش از حد به سرویس‌های پایین‌دستی استفاده می‌کند؛ به این معنا که هر موردی که از حد مجاز فراتر رود، باید برای چرخه بعدی نگه داشته شود.

از آنجایی که وضعیت «انجام‌شده» ابتدا اعمال می‌شد، عامل بر اساس به‌روزرسانی دفتر ثبت، گزارش موفقیت می‌داد، در حالی که سقف پردازش صرفاً موارد را دور می‌ریخت. در نتیجه، عامل VibeJobHunterAIPA_AIMCF که مسئول مصرف این داده‌ها بود، با وجود حضور داده در ورودی، عملاً گرسنه ماند.

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

اصلاحات فنی

برای رفع این مشکل، توسعه‌دهنده در ۳۰ اوت ۲۰۲۶ دو تغییر کد مشخص را برای بازچیدمان مراحل حیاتی خط لوله اعمال کرد تا ترتیب گام‌ها اصلاح شود:

• Commit 3d68e45: به‌طور خاص منبع «wellfound» را هدف قرار داد تا از گزارش موفقیت در حالی که هیچ خروجی‌ای برنمی‌گرداند، جلوگیری شود.
• Commit 36e985c: ترتیب خط لوله را تغییر داد تا از سوزاندن شغل‌ها در نقطه سقف پردازش و گرسنگی بهترین منبع داده جلوگیری شود. این تغییر تضمین می‌کند که سقف پردازش پیش از علامت‌گذاری مورد به عنوان «انجام‌شده» در دفتر ثبت تکراری‌ها، اعمال شود.

این اصلاح تضمین می‌کند که تنها مواردی ثبت می‌شوند که واقعاً از سقف پردازش عبور کرده و یا در حال پردازش فعال هستند یا پردازششان به طور کامل تمام شده است. اختلاف ۱۷۵ موردی از طریق مقایسه لاگ‌های منبع داده داخلی (که ورود موفق داده‌ها را نشان می‌داد) با لاگ‌های پذیرش پایین‌دستی (که عدد صفر را نشان می‌داد) شناسایی و تعیین شد.

شکاف‌های نظارتی

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

• لیست پردازش PM2: ۸ پردازش آنلاین بودند. با این حال، algom-stream در ۱۴ روز ۵۵,۱۹۳ بار ری‌استارت شده بود و cto-aipa در ۲ روز ۹۹ بار. اگرچه این اعداد نشانه‌هایی برای نشت حافظه (Memory Leak) یا استثناهای مدیریت‌نشده (Unhandled Exceptions) هستند، اما هیچ سیگنالی درباره خطای منطقی جریان داده ارسال نکردند.
• دنبال کردن لاگ‌ها: فایل concierge-selftest.log وضعیت «✅ PASS — 4 checks, 3318ms to first card» را نشان می‌داد و hs-watch-manual-emails.log مقدار «ok: true» را برمی‌گرداند. این‌ها وضعیت عملیاتی را تایید می‌کردند اما خطای منطقی را نادیده گرفتند.
• معیارهای تجاری: ردیابی معاملات HubSpot نشان داد ۱۰۰ معامله در وضعیت «پاسخ دادند» (They replied) و ۰ معامله در وضعیت «بسته شد/برنده» (closed won) هستند. این‌ها شاخص‌های پس‌رو (Lagging Indicators) هستند و معیار مستقیم سلامت لحظه‌ای عامل نیستند.

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

شکاف زمینه‌ای

دیباگ کردن این مشکل به دلیل نبود زمینه مشترک (Shared Context) بین ابزارهای AI دشوارتر شد. توسعه‌دهنده از Cursor Cloud، Cursor Desktop و Claude Code استفاده می‌کند که هیچ‌کدام تاریخچه چت‌های یکدیگر را نمی‌بینند. هیچ گفتگو یا پروتکل MCP (پروتکل زمینه مدل) مشترکی در Cursor وجود ندارد و راهی برای ارسال پیام بین این عامل‌ها نیست.

برای پر کردن این شکاف، یک فایل دستی در مسیر /home/ubuntu/cto-aipa/docs/oracle/NOW.md به عنوان حافظه کاری مشترک عمل می‌کند. این فایل تنها چیزی است که تمام عامل‌ها می‌خوانند و به عنوان یک پروتکل عمل می‌کند تا عامل‌هایی که نمی‌توانند با هم صحبت کنند، از اقدامات متضاد جلوگیری کنند.

این فقدان حافظه یکپارچه، شناسایی تناقضات منطقی — مانند شکاف عظیم بین ورودی و خروجی — را بدون دخالت دستی بسیار سخت می‌کند. اکنون یک ورودی در ویکی تیم اضافه شده تا حادثه «علامت‌گذاری ۱۷۵ مورد به عنوان انجام‌شده پیش از خواندن آن‌ها» ثبت شود و یادآوری کند که برای هر منبع داده جدید، معیارهای سنجش دقیق تعریف شود.

برای توسعه‌دهندگانی که گردش‌های کاری عامل‌محور (Agentic) می‌سازند، این یک هشدار است: سیستمی که گزارش «موفقیت» می‌دهد، لزوماً سیستمی نیست که درست کار می‌کند. تنها معیار قابل اعتماد، مقایسه مستقیم ورودی در برابر خروجی با یک تفاضل مورد انتظار است.

گام بعدی شما

• خط لوله‌های عامل خود را بازبینی کنید تا مطمئن شوید علامت‌های تغییر وضعیت (مانند «انجام شد» یا «پردازش شد») تنها پس از تایید نهایی تحویل داده اعمال می‌شوند، نه در ابتدای صف.
• یک معیار سنجش (Metric) برای مقایسه تعداد داده‌های وارد شده به صف در برابر داده‌های خروجی از لایه پردازش تعریف کنید.
• برای هماهنگی بین ابزارهای مختلف AI، یک فایل «منبع حقیقت واحد» (Single Source of Truth) ایجاد کنید تا حافظه مشترک عامل‌ها تامین شود.

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