تصور کنید ابزاری که برای نظارت بر سیستم شما ساخته‌اید، با اطمینان کامل گزارش می‌دهد که همه چیز درست است، در حالی که در واقعیت، ابزار نظارت شما خراب شده و اصلاً چیزی را نمی‌بیند. این دقیقاً همان تله‌ای است که بسیاری از توسعه‌دهندگان در استقرار عامل‌های هوش مصنوعی با آن روبرو می‌شوند.
به نقل از گزارش‌های منتشر شده در ۲۳ سپتامبر ۲۰۲۶، ۹ نقص اندازه‌گیری مجزا تنها در یک روز رخ داد، اما هیچ‌کدام به دست کاربر نهایی نرسید. Firstlight، یک عامل (Agent) — شبیه به کارمندی دیجیتال که می‌تواند ابزارها را اجرا کند و تصمیم بگیرد — هر یک از این خطاها را با متصل کردن یک بررسی دوم و ارزان‌تر به هر اندازه‌گیری اصلی شکار کرد.
بسیاری از توسعه‌دهندگان تا لحظه شکست، به بررسی‌های خود اعتماد می‌کنند. این یک تله رایج است؛ ابزار گزارش موفقیت می‌دهد چون قادر نیست شکست خودش را تشخیص دهد. برای مثال، وقتی یک جست‌وجو هیچ نتیجه‌ای نمی‌یابد، ممکن است هدف واقعاً وجود نداشته باشد، یا ممکن است ابزار جست‌وجو خراب شده باشد. این چالش با مواردی که عامل‌های کدنویسی هوش مصنوعی نتایج آزمون‌ها را جعل می‌کنند شباهت دارد و نشان می‌دهد که اعتماد به گزارش‌های داخلی مدل‌ها می‌تواند گمراه‌کننده باشد. Firstlight اشاره می‌کند که نوشتن «بررسی‌های بهتر» راه حل نیست، زیرا بررسی‌ها همچنان به دلیل توکن‌های اشتباه یا الگوهای نادرست شکست می‌خورند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های مدل بدون لایه‌ی اعتبارسنجی مستقل، ریسک عملیاتی را افزایش می‌دهد. برای حل این مشکل، Firstlight از فلسفه‌ی «اجازه دادن به اندازه‌گیری برای مخالفت با اپراتور» استفاده می‌کند. به جای پیچیده کردن بررسی‌ها، این عامل از پنج کنترل ساده استفاده می‌کند که مانند یک تور نجات برای خط‌کش اصلی عمل می‌کنند.
مکانیزم‌های پنج‌گانه کنترل
کنترل‌های مثبت (تأیید «بله»): قبل از اعتماد به جست‌وجویی که نتیجه‌ای ندارد، عامل آن را روی چیزی اجرا می‌کند که می‌داند هدف در آن هست.
- مثال: برای تأیید حضور نام یک ابزار در فایل‌ها، Firstlight جست‌وجو را روی فایل منبع خودِ آن ابزار اجرا کرد. وقتی نتیجه «صفر» شد، عامل فهمید خط‌کش خراب است و قبل از باور کردن نتایج واقعی، عملیات را متوقف کرد.
- قاعده: عدد صفر تنها زمانی مدرک است که همان ابزار همین حالا یک عدد یک را نشان داده باشد.
کنترل‌های منفی تازه (تأیید «خیر»): عامل بررسی را روی چیزی اجرا می‌کند که قطعاً نباید تطابق داشته باشد و انتظار عدد صفر دارد.
- تله: استفاده از کلمات ثابت مثل "zzz-nope" شکست خورد چون برخی اسناد واقعاً شامل این کلمه بودند.
- راه حل: تولید یک رشته تصادفی در لحظه اجرا با استفاده از
/dev/urandom. اگر این رشته‌ای که همین یک ثانیه پیش اختراع شده با چیزی در داده‌ها تطابق یابد، یعنی خط‌کش در حال تطبیق چیزهایی است که نباید.
تنوع ابزارها (روش‌های نامرتبط): عامل یک معیار را با دو روش کاملاً متفاوت اندازه می‌گیرد. اگر اعداد با هم اختلاف داشته باشند، این اختلاف ارزشمندترین خروجی روز است.
- مورد اول: شمارش عبارت با
grepبیش از حد بالا بود چون کلماتی مثل "uncomfortable" را هم می‌شمرد. استفاده از مرز کلمات این مشکل را حل کرد. - مورد دوم: جست‌وجوی دقیق برای "5/5" چیزی نیافت چون متن اصلی شامل "5/5" (با فرمت‌بندی) بود.
- مورد سوم: بررسی یک پردازش، خودِ دستور بررسی را هم می‌شمرد. یک کنترل منفی برای پردازشی که وجود نداشت، عدد ۲ را برگرداند و خطا را افشا کرد.
- مورد اول: شمارش عبارت با
تأیید اعداد غیرممکن (نابرابری‌های رایگان): عامل نابرابری‌های تک‌خطی می‌نویسد که بر اساس رابطه جزء و کل، همیشه باید درست باشند.
- مثال: یک بررسی یکتایی، ۱۰ کلید یکتا را در جدولی گزارش کرد که کلاً ۷ ردیف داشت. الگو به اشتباه اعداد پررنگ خارج از جدول را می‌شمرد.
- منطق: تعداد شکست‌ها نمی‌تواند بیشتر از تعداد تلاش‌ها باشد و زمان پایان نمی‌تواند قبل از زمان شروع باشد.
نوشتن دوگانه عمدی (تأیید وضعیت): برای هر پردازشی که داده می‌نویسد، عامل ابتدا یک اجرای واقعی و بلافاصله یک اجرای دوم مشابه انجام می‌دهد.
- باگ: ابزاری فایل‌ها را بدون هشدار بازنویسی می‌کرد. Firstlight بعد از یک تحویل موفق، عمداً همان فایل را دوباره فرستاد. در حالی که فایل هدف دست‌نخورده بود، رسید تحویل اول ناپدید شد. این باگ در ۱۲ ثانیه پیدا شد چون اجرای دوم عمدی بود.
محدودیت‌ها و موارد خاص
با وجود این کنترل‌ها، برخی شکست‌ها نامرئی می‌مانند. یک هش SHA-256 ثابت می‌کند فایل «تغییر نکرده»، اما ثابت نمی‌کند که بایت‌ها از ابتدا «درست» بوده‌اند. خواندن یک هش منطبق به عنوان نشانه «همه چیز خوب است» یک اشتباه است.
علاوه بر این، موردی رخ داد که دو مسیر به یک فایل اشاره می‌کردند. یک فایل و کپی آن هش یکسان اما زمان تغییر متفاوتی داشتند. مشخص شد یکی از آن‌ها یک لینک نمادین (Symbolic Link) است. برای جلوگیری از این خطا، عامل اکنون قبل از مقایسه هر فایلی، دستور test -L را اجرا می‌کند.
کاربرد عملی برای توسعه‌دهندگان
برای توسعه‌دهندگانی که به دنبال بهره‌وری هستند، این به معنای تغییر هدف از «بررسی‌های بی‌نقص» به «شکست‌های مرئی» است. بررسی‌ای که هرگز شکست نخورده، هنوز اثبات نشده است. تنها راه اعتماد به یک اندازه‌گیری این است که ابتدا آن را مجبور به شکست عمدی کنید.
این رویکرد، معیار قابلیت اطمینان هوش مصنوعی را از پیچیدگی مجموعه تست‌ها به «استواریِ اختلاف» تغییر می‌دهد. وقتی دو ابزار ساده با هم اختلاف دارند، آن اختلاف تبدیل به ارزشمندترین نقطه داده روز می‌شود. در همین راستا، برای مدیریت دقیق‌تر رفتار عامل‌ها، راهکار جدید Rulestack برای جلوگیری از پاسخ‌های یکسان معرفی شده است تا از تکرار خروجی‌های بی‌فایده جلوگیری شود.
گام بعدی شما
- بحرانی‌ترین نتایج «صفر» در سیستم خود را شناسایی کنید و برای هر کدام یک کنترل مثبت بسازید تا مطمئن شوید صفر واقعاً به معنای نبودِ داده است، نه خرابی لوله انتقال داده.
- برای هر عملیات نوشتن (Write)، یک اجرای دوم عمدی را برای تست بازنویسی یا حذف ناخواسته داده‌ها اضافه کنید.
- نابرابری‌های ساده (مثل: تعداد خطاها $\le$ تعداد درخواست‌ها) را به عنوان لایه نهایی اعتبارسنجی در کد خود بگنجانید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو