۱۰ الگوی شکست در آزمون‌های هوش مصنوعی که با چراغ سبز تایید می‌شوند

یک تیک سبز در پنل نظارتی، ادعاست، نه حقیقت. طی روزهای ۱۸ و ۱۹ آوریل ۲۰۲۶، یک بازرسی تک‌روزه در Phronesis بحرانی سیستمی را فاش کرد: کتاب‌های پولی به‌طور رایگان توزیع می‌شدند، فرم‌های تماس تمام درخواست‌ها را از دست می‌دادند و نقشه سایت کاملاً خالی بود؛ علاوه بر این، معیاری به نام «پیوستگی» (coherence) وجود داشت که در واقع بیشتر از آن برای اندازه‌گیری کوتاهیِ متن استفاده می‌شد. با وجود این شکست‌های بحرانی، تک‌تک چک‌های خودکار وضعیت «PASS» یا همان موفقیت را گزارش می‌کردند.

این شکست به این دلیل رخ داد که مهندس سایت — که در واقع یک نمونه از مدل Claude بود — دقیقاً همان تست‌هایی را نوشته بود که در شناسایی اشتباهات خودش ناتوان بودند. مثال‌هایی که در اینجا فهرست شده‌اند، فرضی نیستند یا از یک مسیر شغلی طولانی جمع‌آوری نشده‌اند؛ بلکه همگی حاصل تنها یک روز ممیزی هستند. آنچه آن روز را غیرعادی کرد، تعداد نقص‌ها نبود، بلکه «استتار» آن‌ها بود: هر نقص جدی پشت تستی پنهان شده بود که پیش‌تر تایید شده بود. در واقع، تیک سبزِ موفقیت، نقابی برای پنهان کردن خطاها بود.

مشکل بنیادین در درک اشتباه از مفهوم اعتبارسنجی است: اجرای مجدد یک ابزار فقط «پایداری» (Stability) را می‌سنجد، اما تغییر روش بررسی است که «صحت» (Validity) را آزمایش می‌کند. در دنیای امروز که توسعه با کمک AI پیش می‌رود، چراغ سبز به نقابی برای پوشاندن نقص‌های بحرانی تبدیل شده است. همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، وقتی یک عامل (AI Agent) — شبیه به کارگری که هم محصول را می‌سازد و هم خودش بازرس کیفیت است — هم مسئول پیاده‌سازی و هم مسئول تایید باشد، یک حلقه بسته از «سوگیری تایید» ایجاد می‌شود که در آن ابزار قادر نیست حقیقت را درباره سلامت سیستم بگوید. این پدیده مشابه مواردی است که در آن سوگیری‌های مدل‌های هوش مصنوعی باعث پنهان ماندن حفره‌های امنیتی شدید در سیستم‌های پزشکی شده است.

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

بر اساس مستندات بازرسی phronesis.world، ۱۰ روش متمایز وجود دارد که در آن‌ها یک تست با وجود شکست در عمل، وضعیت موفقیت را گزارش می‌کند. این موارد از نقص‌های منطقی تا نقاط کور معماری را در بر می‌گیرند:

• تلهٔ عدم قابلیت شکست (The Unfailability Trap): اسکریپت‌هایی که هرگز نمی‌توانند شکست بخورند، صرفاً تزیینی هستند. یک اسکریپت اعتبارسنجی در Phronesis دوازده خط پیغام «BAD» چاپ کرد اما در نهایت نتیجه را «PASS» اعلام نمود؛ زیرا پرچم خطا در یک زیرپوسته (subshell) تعریف شده بود و با پایان آن می‌میرفت، در حالی که خلاصه نهایی متغیری را می‌خواند که هیچ‌چیز قادر به تغییر آن نبود. نمونه مشابه آن مجموعه‌تستی است که از رفتار فعلی سیستم ضبط شده و برای همیشه پاس می‌شود، چون صرفاً تایید می‌کند که سیستم هر کاری که اکنون انجام می‌دهد، انجام دهد. راه شناسایی: یک بار عمداً سیستم را خراب کنید. اگر تست باز هم پاس شد، شما ابزار ندارید، بلکه تزیینات دارید.
• عدم تطبیق گویش (Dialect Mismatches): تست‌ها اغلب دنبال فرمت اشتباهی می‌گردند. جست‌وجو برای href="/courses" چیزی پیدا نکرد چون فریم‌ورک خروجی را به صورت href="/courses/" (با یک اسلش اضافه) تولید می‌کرد. یک علامت دلار که قرار بود به صورت تحت‌اللفظی خوانده شود، به عنوان یک لنگر Regex (منظم) شناسایی شد و با هیچ‌چیز تطبیق نیافت. به همین ترتیب، قیمت‌ها هرگز به صورت یک رشته متصل ظاهر نشدند چون رندرکننده بین بخش‌های متن، گره‌های کامنت (comment nodes) قرار می‌داد و ممیزی که انتظار min="0" داشت، با JSX مواجه شد که min={0} می‌نوشت. در هر مورد، تست از نظر ساختاری درست بود، اما برای زیربنایی نوشته شده بود که در محیط عملیاتی وجود نداشت. راه شناسایی: یک مورد مثبت شناخته‌شده به چک‌کننده بدهید. اگر نتوانست چیزی را که می‌دانید آنجاست پیدا کند، پیام «هیچ‌چیز پیدا نشد» بی‌معنا است.
• ممیزی‌های سطحی (Surface-Level Audits): بررسی کد منبع با بررسی صفحه رندر شده متفاوت است. نقشه سایت یک روز کامل خالی بود، اما تمام ممیزی‌ها پاس شدند چون لینک‌ها در سورس کد (Source Code) وجود داشتند و درست بودند. کنسول برای خطاها بررسی شد و هیچ خطایی نداشت، زیرا خطای تجزیه (Parse Error) اسکریپت را قبل از اینکه هرگونه هندلری برای گزارش آن وجود داشته باشد، می‌کشت. نسخه پشتیبان HTML تمام لینک‌ها را داشت، اما آن‌ها توسط CSS در دسکتاپ مخفی شده بودند. هر تست جایی را بررسی کرد که بررسی در آن راحت بود. راه شناسایی: لایه‌ای را چک کنید که پیامد در آن رخ می‌دهد؛ ممیزی سورس، حقیقتی درباره سورس است، نه صفحه.
• پایداری در برابر صحت (Reliability vs. Validity): ابزار نویسنده، نمره «پیوستگی» را بر اساس اتصال جبری گراف جملات می‌سنجید. این معیار ریاضیاتی پایدار و تعریف‌شده بود اما عملاً فقط «طول متن» را اندازه می‌گرفت؛ متنی که به ۸ جمله کوتاه شده بود نمره ۰.۳۹ گرفت، در حالی که نسخه کامل نمره ۰.۱۱ داشت. نثر کاملاً یکسان باعث نوسانی چهار برابر در نمره شد. این مورد از طریق یک «تست ناپذیری» (Invariance Test) فاش شد: اعمال تغییری که معیار نباید به آن حساس باشد. چهار مخرج مختلف برای اصلاح امتحان شد و همه شکست خوردند؛ تنها راه حل، یک مقیاس اندازه‌گیری ثابت بود. راه شناسایی: تغییری اعمال کنید که معیار نباید به آن حساس باشد و ببینید آیا نتیجه تغییر می‌کند یا خیر.
• مجموعه تست‌های سوگیرانه (Biased Test Sets): برای تست معیار پیوستگی، چهار متن دستی نوشته شد: یک استدلال دقیق، یک تامل، یک لیست گسسته و یک متن فنی. این‌ها مورد مشکوک را تایید کردند اما موارد دیگر را پنهان کردند، زیرا عامل مورد شک را تغییر می‌دادند در حالی که عامل ناشناخته را ثابت نگه می‌داشتند. با این حال، ۷۴ سند موجود (مقالات سایت و ماژول‌های دوره) در یک اجرا، این یافته را به کلی وارونه کردند. راه شناسایی: مجموعه تستی که توسط کسی که فرضیه را می‌داند نوشته شده، ضعیف‌ترین مدرک است. از داده‌هایی استفاده کنید که پیش از طرح پرسش وجود داشتند.
• حذف طراحی‌شده (Erasure by Design): سه طرح آزمایشی نتوانستند یک «حلقه هیسترزیس» (Hysteresis Loop) موجود را پیدا کنند. اولی اندازه‌گیری‌ها را چنان طولانی کرد که حافظه سیستم رها شد و اثر در حد quasi-static ناپدید گشت. دومی بهترین اثر را با بدترین کنترل مقایسه کرد. سوم نسبت دو عدد را گرفت که هر دو نویز بودند. حلقه تنها در طرح چهارم ظاهر شد که جفت‌شده، تطبیق‌یافته از نظر نرخ و مطلق بود. راه شناسایی: برای تمایز بین «اثر واقعی» و «مصنوعاتی که شبیهش است» طراحی کنید.
• سوگیری سکوت (The Silence Bias): سامانه‌هایی که از بلوک‌های خالی catch(()=>{}) استفاده می‌کنند، شکست‌ها را می‌بلعند. فرم تماس Phronesis داده‌ها را به Worker-ی می‌فرستاد که هفته‌ها بود وجود نداشت؛ هر ارسال شکست می‌خورد اما بلوک catch هر اتفاقی را می‌بلعید. جعبه پیشنهادها نیز همین بیماری را داشت. امتیازات یک بازی به Endpointهایی می‌رفت که هرگز مستقر نشده بودند و هر درخواست در catch(()=>{}) پایان می‌یافت. سکوت بین «نبود شکست» و «نبود سیگنال» مبهم است. راه شناسایی: نبودِ خطا به معنای وجود موفقیت نیست. قبل از باور کردن، سیگنال مثبت (مثل کد 201، رکورد ذخیره شده یا پاسخ) را مطالبه کنید.

رانش داده‌ها و شکاف‌های پیاده‌سازی

• رانش مستندات (The Documentation Drift): صفحه‌ای ادعا می‌کرد دمای لمسی میز فولادی و کاج حدود ۹ درجه اختلاف دارد. این عدد از جدولی از رسانایی‌ها و تراکم‌ها در همان فایل محاسبه شده بود. وقتی جدول با اعداد بهتر اصلاح شد، تمام تست‌ها سبز ماندند چون کد درست بود اما جمله اشتباه. سندی که عددی را نقل می‌کند بدون اینکه آن را اندازه بگیرد، یک ادعای تست‌نشده است. برای اصلاح، جملات به عنوان تست نوشته شدند (مثلاً: «فولاد و کاج حدود ۹ درجه اختلاف دارند»). این کار فاش کرد ادعای اینکه «هر ماده گیاهی از هر ماده نفتی بهتر است» غلط است، زیرا کف فوم پلی‌اورتان بهترین عدد را داشت. نثر مجبور شد تضعیف شود به: «یکی از آن‌ها با بهترین مصنوعی موجود برابری می‌کند». رانش‌های دیگر زمانی رخ داد که تغییر قانون، مواد معدنی را پذیرفت و باعث شد چک «سطوح تمیز» بتن را با خودش مقایسه کند، یا زمانی که یک صفت برترین (superlative) به دلیل اضافه شدن ماده جدید برعکس شد و ادعای «فوم کمترین انتشار را دارد» غلط گشت. راه شناسایی: هر عددی در متن که از جای دیگری می‌آید را ردیابی کنید؛ اگر با تغییر داده، متن تغییر نکرد، ادعای شما بدون حفاظ است.
• موفقیت توخالی (Vacuous Success): اسکریپتی رشته‌ای را در فایل جایگزین کرد و پیام «updated» چاپ نمود، اما هیچ چیزی تغییر نکرد چون فرض کرده بود ۶ فاصله (indentation) وجود دارد در حالی که فایل ۴ فاصله داشت؛ یعنی صفر بار تطبیق یافت اما موفقیت گزارش کرد. این اتفاق ۴ بار در یک روز افتاد. در یک مورد، یک گیت ساخت (build gate) باقی ماند که پاس می‌شد زیرا قانونی که با هیچ ورودی تطبیق نمی‌یابد، از قانونی که هیچ خطایی نمی‌یابد تمایز ندارد. یکی دیگر حتی تا استقرار کامل پیش رفت. راه شناسایی: ادیت و گزارش نباید از یک فرآیند باشند. ابزار باید در صورت عدم یافتن الگو خطا دهد یا تعداد تطبیق‌ها را تایید کرده و فایل را دوباره بخواند.
• سراب حافظه پنهان (The Cache Mirage): اصلاحات موبایل، جدول رده‌بندی و یک شمارش اصلاح‌شده اعمال نشده به نظر می‌رسیدند. در واقع، دامین اصلی داشت HTML قدیمی را با اعتبار یک هفته‌ای (edge-cached) سرو می‌کرد. اعتبارسنجی نسخه قدیمی را می‌سنجید و روش‌های cache-busting با query-string غیرقابل اعتماد بودند. عکس این موضوع نیز ممکن است: تغییری زنده به نظر می‌رسد چون یک کپی کش‌شده با انتظارات مطابقت دارد. این در Workerی دیده شد که کد مستقر‌شده‌اش دیگر با سورس مخزن مطابقت نداشت، در حالی که تنها یکی از سه مسیر پاسخ می‌داد و دایرکتوری خروجی ساخته‌شده جایگزین سورسی شده بود که جابجا گشته است. راه شناسایی: به جای نام مستعار (alias)، مستقیماً روی URL استقرار، هشِ کامیت (commit hash) یا خروجی ساخت بررسی کنید.

مکانیزم‌های اعتبارسنجی واقعی

برای مبارزه با این «شکست‌های چراغ‌سبز»، این بازرسی چندین گام اثرگذار پیشنهاد می‌دهد که در عمل منجر به یافتن نقص‌ها شد:

۱. پرسیدن سوال متفاوت: اجرای مجدد همان ممیزی هیچ نتیجه‌ای نداشت. با این حال، هر ابزار جدید — تغییر از لینک‌ها به Endpointها، سپس رندرهای صفحه و در نهایت دسترسی‌پذیری (accessibility) — در اولین اجرای خود، دسته‌ای از نقص‌های جدید را یافت.
۲. استنباط از ادعا، نه رفتار: استفاده از یک موتور استدلالی قطعی با مجموعه‌ای که مستقیماً از روی مستندات نوشته شده است. این روش در اولین دقیقه دو باگ واقعی را پیدا کرد، از جمله کد fallback مرده‌ای که ورودی‌های غیرقابل خواندن را به عنوان بهترین حالت فریم‌ورک گزارش می‌داد.
۳. کاوش سرتاسری (تمرین کنید، نه فقط بازرسی): به گزارش‌ها اعتماد نکنید. شخصاً صفحه را در مرورگر برانید، فرم را پر کنید، محصول را بخرید و Endpoint را فراخوانی کنید. گزارشِ یک چیز، خودِ آن چیز نیست.
۴. اعتبارسنجی تغییرناپذیر: دامین اصلی را سوالی درباره «انتشار» (propagation) بدانید، نه «صحت». مستقیماً روی URL استقرار یا هش کامیت چک کنید تا از نسخه دیروز صفحه درست اجتناب کنید.
۵. حلقه انسانی: یک نگاه انسانی را در مسیر نگه دارید. نقشه سایت خالی را انسان پیدا کرد، در حالی که ۵ ممیزی خودکار آن را پاس داده بودند. انسان‌ها تنها ابزاری هستند که گویش ثابتی ندارند.
۶. تبدیل شکست‌ها به گیت‌های بازه: هر شکست شناسایی شده باید به یک گیت در خط لوله ساخت (build gate) تبدیل شود. اکنون اسکریپت‌های درون‌خطی (inline) از نظر تجزیه بررسی می‌شوند (چون یک تک‌کوتیشن یک صفحه را خالی کرده بود) و اگر مسیری هندلر خود را از دست بدهد، ساخت شکست می‌خورد.
۷. اجبار ابزار به امتناع: ویرایشگرهایی را ترجیح دهید که وقتی الگویی را پیدا نمی‌کنند، خطا (Error) می‌دهند. برای تغییرات حجیم، اسکریپت را مجبور کنید تعداد تطبیق‌ها را تایید کند و در صورت صفر بودن، شکست بخورد.

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

برای اجتناب از این تله‌ها، ابتدا تمام اعداد موجود در مستندات خارجی خود را که از یک منبع داده می‌آیند، شناسایی کنید. از خود بپرسید: «اگر این داده تغییر کند، آیا تست من شکست می‌خورد؟» اگر پاسخ خیر است، ادعای شما بدون حفاظ است. در چارچوب این بحث، یک چک، یک «ابزار» است و یک چک موفق، «ادعایی از پیوستگی» است. ارزش این ادعا دقیقاً برابر با میزان جابجایی است که چک می‌توانست ثبت کند. عقربه‌ای که نمی‌تواند تکان بخورد، هیچ‌چیز را اندازه نمی‌گیرد، فارغ از اینکه به کجا اشاره می‌کند.

گام بعدی شما

• تمام اعداد موجود در مستندات خارجی خود را که از یک منبع داده می‌آیند، شناسایی کنید.
• از خود بپرسید: «اگر این داده تغییر کند، آیا تست من شکست می‌خورد؟» اگر پاسخ خیر است، ادعای شما بدون حفاظ است.
• برای هر ابزار نظارتی، یک «مجموعه داده شکست» (Negative Test Set) بسازید تا مطمئن شوید ابزار شما توانایی اعلام خطا را دارد.

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