۵۵.۶٪ از گزارش‌های خطای هوش مصنوعی در بازرسی حفاظ‌ها مثبت کاذب بودند

اگر امروز برای تست خودکار کدهایتان به هوش مصنوعی اعتماد می‌کنید، باید بدانید که احتمال دریافت گزارش‌های غلط بسیار بیشتر از آن چیزی است که در بنچمارک‌ها می‌بینید. در جولای ۲۰۲۶، یک بازرسی فنی روی حفاظ‌ها (Guardrails) — شبیه به نرده‌های ایمنی در کنار جاده که مانع خروج ماشین از مسیر می‌شوند — نشان داد که شکاف عمیقی میان شناسایی باگ‌های قدیمی و کشف خطاهای جدید وجود دارد. این بازرسی فاش کرد که در حالی که یک چک‌لیست سفارشی توانست ۱۰۰٪ از نقص‌هایی که برای شناسایی‌شان طراحی شده بود را پیدا کند، اما وقتی با کدهای دیده نشده روبرو شد، به شدت شکست خورد و از ۱۸ مورد جدید، ۱۰ مورد را به اشتباه رد کرد.

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

تله‌ی دقت

طبق گزارش منتشرشده در dev.to، این بازرسی ۱۳ حفاظ را که پیش‌تر بررسی نشده بودند، مورد تحلیل قرار داد. عامل‌های (Agents) هوش مصنوعی بازرسی تاریخی را انجام داده و یافته‌ها و تصمیمات نهایی را ثبت کردند. از مجموع ۱۸ پرچم خطای تولیدشده توسط چک‌لیست، تنها ۸ مورد به عنوان نقص واقعی پذیرفته شد.

این امر منجر به نرخ دقت (Precision) ۴۴.۴٪ در میان یافته‌های حل‌شده شد. نویسنده گزارش به یک تمایز حیاتی در گزارش‌دهی اشاره می‌کند: این عدد یک «نرخ مثبت کاذب به ازای هر حفاظ» نیست. دلیل آن این است که بازرسی فاقد شمارش «منفی‌های واقعی» (True Negatives) بود؛ یعنی حفاظ‌هایی که هوش مصنوعی به درستی آن‌ها را نادیده گرفت. بدون این داده، محاسبه نرخ استاندارد مثبت کاذب غیرممکن است.

در ریاضیات ارزیابی، دقت به صورت TP / (TP + FP) تعریف می‌شود. در مقابل، نرخ مثبت کاذب به صورت FP / (FP + TN) محاسبه می‌گردد. چون برچسب‌های ثبت‌شده به «یافته‌ها» متصل شده بودند و نه به خودِ «حفاظ‌ها»، مخرج کسر برای محاسبه نرخ به ازای هر حفاظ در دسترس نبود.

حساب‌وکتاب بازرسی

دقت در گزارش‌دهی مستلزم بازرسیِ خودِ گزارش است. در این مورد، یک خلاصه متنی در اولین رکورد ادعا کرده بود که ۱۱ مورد از ۱۹ پرچم رد شده‌اند. با این حال، مجموع‌های ساختاریافته عدد ۱۰ از ۱۸ را نشان می‌دادند.

نویسنده با بررسی تک‌تک ۱۸ ردیف یافته‌ها، متوجه شد که ۸ برچسب «پذیرفته‌شده» و ۱۰ برچسب «ردشده» وجود دارد. این مقاله بر شمارش ردیف‌ها تکیه می‌کند، زیرا جمله خلاصه با ورودی‌های زیربنایی ناسازگار بود. این یک درس مهم است: یک گزارش بازرسی ممکن است پیش از آنکه نتایجش مفید باشد، به یک بازرسی از حساب‌وکتاب‌های ریاضی خودش نیاز داشته باشد. این چالش با گزارش‌های دیگری که ادعاهای ساختگی در مقالات فنی تولیدشده توسط AI را فاش کردند همسو است و نشان می‌دهد که خروجی‌های مدل‌ها لزوماً با واقعیت‌های داده‌ای سازگار نیستند.

خطر نشت داده

چک‌لیست مورد استفاده از ۷ نقص تأییدشده استخراج شده بود. این نقص‌ها شامل مواردی از این دست بودند:

• یک ورودی اجباری که غایب بود اما سیستم آن را به عنوان «موفقیت» تلقی می‌کرد.
• یک انتخابگر (Selector) که هیچ موردی را پیدا نمی‌کرد و بی‌صدا از بررسی می‌گذشت.
• عملیات‌های تخریبی که بدون محدودیت کافی بر اثرگذاری‌شان اجرا می‌شدند.

از آنجایی که این هفت مورد در طراحی چک‌لیست اثر گذاشته بودند، استفاده از آن‌ها برای سنجش موفقیت، نوعی نشت داده (Data Leakage) است. این موضوع دقیقاً با توصیه‌های Scikit-learn همسو است؛ این کتابخانه هشدار می‌دهد که نتایج روی داده‌های توسعه (Development Data) اغلب بیش از حد خوش‌بینانه هستند و در پیش‌بینی عملکرد واقعی در دنیای بیرون شکست می‌خورند.

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

اصلاح معیارها

تحلیل ۱۰ مورد ردشده نشان داد که ۶۰٪ آن‌ها (۶ مورد) از یک معیار بیش از حد کلی نشأت گرفته بودند: تلقی کردن نتایج «ورودی خالی» به عنوان نقص.

در بسیاری از ابزارهای اتوماسیون، نتیجه‌ی «هیچ موردی یافت نشد» یک خروجی قانونی (یک no-op موفق) است و نه یک شکست. بازرسی فاش کرد که بدون یک قرارداد (Contract) سخت‌گیرانه که تعریف کند چه چیزی «شکست» و چه چیزی «نتیجه خالی معتبر» است، هوش مصنوعی به طور مداوم دچار زیاده‌روی در گزارش خطا می‌شود.

برای حل این مشکل، نویسنده یک قرارداد دقیق‌تر را پیشنهاد می‌کند تا تفاوت میان این موقعیت‌ها مشخص شود:

• شکست ورودی (Input Failure): یک پوشه‌ی منبع اجباری وجود ندارد. این یک مجموعه خالی نیست، بلکه یک شکست است.
• عملیات بی‌اثر موفق (Successful No-op): یک مجموعه موجود اما اختیاری، هیچ کاری برای انجام دادن ندارد. اگر این رفتار مستند شده باشد، موفقیت‌آمیز است.
• انتخاب نامعتبر (Invalid Selection): یک انتخاب صریح که هدفش شناسایی کارهای ضروری است، هیچ نتیجه‌ای نمی‌دهد. این یک انتخاب نامعتبر یا یک نتیجه حل‌نشده طبق قرارداد ابزار است.

این‌ها مثال‌هایی از قراردادهای پیشنهادی هستند، نه ادعایی مبنی بر اینکه هر ابزاری باید از یک کد خروجی یکسان استفاده کند. تست مهم این است که آیا فراخواننده (Caller) می‌تواند تفاوت بین یک no-op معتبر و یک پیش‌شرط شکست‌خورده را تشخیص دهد یا خیر.

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

توهم بهبود

پس از سخت‌گیرانه‌تر کردن معیارها، یک بازرسی تکمیلی انجام شد. این دور دوم ۱۲ حفاظ را بررسی کرد و ۴ یافته تولید کرد که ۲ مورد پذیرفته و ۲ مورد رد شدند.

در حالی که وسوسه‌انگیز است ادعا کنیم مثبت‌های کاذب از ۵۵.۶٪ به ۵۰٪ کاهش یافته است، نویسنده هشدار می‌دهد که این عدد از نظر آماری بی‌معنی است. نمونه‌ی حفاظ‌ها تغییر کرده بود، معیارها تغییر کرده بودند و تعداد کل یافته‌ها برای اثبات بهبود کیفیت بسیار کم بود. این یک آزمایش جفت‌شده‌ی «قبل و بعد» روی یک مجموعه ثابت از موارد برچسب‌گذاری‌شده به صورت مستقل نبود.

یکی از موارد ردشده در دور دوم، اهمیت «دامنه» (Scope) را برجسته کرد. طبق تاییدات ثبت شده، محدودیتی که در یک بررسی شناسایی شده بود، در واقع توسط بررسی دیگری در مسیر اجرا پوشش داده می‌شد. این ثابت می‌کند که محدودیت در یک جزء (Component) همیشه به معنای رفتار محافظت‌نشده در کل سیستم نیست. یک محدودیت می‌تواند مستحق مستندسازی باشد، بدون اینکه ثابت کند کل مسیر، قرارداد خود را نقض کرده است.

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

چارچوبی برای گزارش‌دهی صادقانه

برای جلوگیری از «اشتباه در مخرج کسر»، نویسنده یک الگوی گزارش‌دهی را پیشنهاد می‌کند که یافته‌های پذیرفته‌شده، ردشده و حل‌نشده را در ردیف‌های مجزا نگه دارد.

نویسنده با استفاده از یک بازسازی مبتنی بر پایتون از این بازرسی، نحوه مدیریت این برچسب‌ها را نمایش می‌دهد. با استفاده از Counter برای برچسب‌هایی مانند «accepted»، «rejected» و «unresolved»، گزارش می‌تواند دقت را در میان یافته‌های حل‌شده محاسبه کند، بدون اینکه موارد در انتظار را به طور پنهانی به عنوان درست یا غلط طبقه‌بندی کند.

from collections import Counter
# Reconstructed counts from the recorded adjudications.
labels = ["accepted"] * 8 + ["rejected"] * 10
counts = Counter(labels)
allowed = {"accepted", "rejected", "unresolved"}
if set(counts) - allowed:
    raise ValueError("Unknown finding label")
accepted = counts["accepted"]
rejected = counts["rejected"]
resolved = accepted + rejected
report = {
    "unit": "finding",
    "findings_total": len(labels),
    "resolved": resolved,
    "unresolved": counts["unresolved"],
    "precision_among_resolved": accepted / resolved if resolved else None,
    "rejected_share_among_resolved": rejected / resolved if resolved else None,
    "per_guard_false_positive_rate": None, # Required labels unavailable.
    "recall_on_new_cases": None, # Missed defects not established.
}
print(report)

برای این برچسب‌ها، دو سهم محاسبه شده تقریباً ۰.۴۴۴ و ۰.۵۵۶ هستند. اگر یک یافته «حل‌نشده» اضافه کنید، تعداد کل و تعداد حل‌نشده‌ها افزایش می‌یابد بدون اینکه به طور پنهانی به عنوان درست یا غلط طبقه‌بندی شود. در این صورت، دو سهم محاسبه شده فقط توصیف‌کننده زیرمجموعه «حل‌شده» هستند و ممکن است نماینده یافته‌های در انتظار نباشند. در صورت نبود یافته‌های حل‌شده، هر دو مقدار به جای تبدیل شدن به یک صفر آرام‌بخش، None باقی می‌مانند.

برای بررسی‌های آینده، نویسنده توصیه می‌کند برای هر یافته یک ردیف نگه دارید که شامل موارد زیر باشد:

• معیاری که استفاده شده است.
• شواهد بازتولید (Reproduction evidence).
• رفتار مورد انتظار.
• حکم نهایی (Verdict).
• دلیل حکم.

موارد حل‌نشده را حفظ کنید. پیش از نقل هر درصد کلی، آن ردیف‌ها را دوباره بشمارید. اگر می‌خواهید دو نسخه از چک‌لیست را مقایسه کنید، ابتدا واحد ارزیابی و برچسب‌ها را تعریف کنید، یک مجموعه ارزیابی مجزا را منجمد (Freeze) کنید و هر دو نسخه را روی آن اجرا کنید. موارد no-op قانونی را در کنار نقص‌های شناخته‌شده قرار دهید. با هفت نقص اولیه به عنوان «تست‌های رگرسیون» برخورد کنید و نتیجه آن‌ها را از ارزیابی موارد جدید جدا نگه دارید.

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

این رویکرد تمرکز را از یک درصد موفقیت «شیک» به درکی دقیق از جاهایی که منطق هوش مصنوعی زیاده‌روی می‌کند، تغییر می‌دهد. این کار بازرسی را از یک حالت باینری (قبول/رد) به ابزاری برای اصلاح مشخصات سیستم تبدیل می‌کند.

گام بعدی شما

• در ارزیابی مدل‌های خود، داده‌های آموزش و آزمون را کاملاً تفکیک کنید تا دچار توهم نشت داده نشوید.
• برای گزارش‌های AI، به جای درصد کلی، از جدولی استفاده کنید که موارد «پذیرفته»، «ردشده» و «نامشخص» را در ردیف‌های مجزا نگه دارد.
• هر گزارش خطای هوش مصنوعی را با یک «قرارداد خروجی» (Exit Contract) تعریف‌شده بسنجید تا نتایج خالی با شکست‌های سیستمی اشتباه نشوند.

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