چرا تست‌های تولیدشده توسط مدل‌های زبانی لزوماً معتبر نیستند؟

تصور کنید کدی را به تولید می‌فرستید که تمام تست‌هایش سبز هستند، اما در اولین برخورد با کاربر، سیستم کرش می‌کند. این کابوس زمانی رخ می‌دهد که شما به جای اعتبارسنجی واقعی، به «تزئینات» کد اعتماد کرده باشید.

بسیاری از برنامه‌نویسان اکنون برای نوشتن تست‌های واحد (Unit Tests) به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — تکیه می‌کنند. اما طبق گزارش dev.to، این مدل‌ها معمولاً دو هدف ساده را دنبال می‌کنند: اینکه تست اجرا شود و با کدی که همین حالا نوشته‌اند هم‌خوانی داشته باشد. این وضعیت یک حلقه خطرناک می‌سازد؛ هوش مصنوعی هم باگ را تولید می‌کند و هم تستی می‌نویسد که آن باگ را نادیده بگیرد. این چالش دقیقاً همان نقطه‌ای است که پوشش کد بالا در تست‌های AI می‌تواند به توهمی تبدیل شود که باگ‌های واقعی را پنهان می‌کند.

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

برای حل این مشکل، نیکولای چرنوینیکولای در ۳۰ سپتامبر ۲۰۲۶ متدی را معرفی کرد که بر مفهوم «تمایز» (Discrimination) تأکید دارد. تمایز یعنی توانایی یک تست برای شکست خوردن در صورت نادرست بودن رفتار کد. یک تست قدرتمند باید مرزهای دقیق را هدف قرار دهد؛ مثلاً به‌جای چک کردن اینکه خروجی «عدد» است یا نه، بررسی کند که تخفیف ۱۰ درصدی دقیقاً در مرز ۲۰۰۰ دلار اعمال شود و اگر به‌جای علامت >= از > استفاده شده بود، تست را قرمز کند.

آزمایشگاه اعتبارسنجی

برای اثبات این شکاف، یک محیط آزمایشگاهی با استفاده از Node 20+ منتشر شد که این حالت شکست را شبیه‌سازی می‌کند:

• مجموعه تست‌های AI: در برابر کدی که ۴ نقص عمدی داشت، ۳ تست از ۳ تست را پاس کرد (تأیید غلط).
• اعتبارسنجی سخت‌گیرانه: ۸ تست از ۱۲ تست را رد کرد و موفق شد هر ۴ نقص را شناسایی کند.

این تفاوت نشان می‌دهد که «پوشش کد» (Code Coverage) بالا به‌معنای قابلیت اطمینان بالا نیست. وقتی مدل تولیدکننده و مدل تأییدکننده یکی باشند، فاصله انتقادی لازم برای یافتن خطاها از بین می‌رود. این موضوع یادآور راهکارهای ابزارهایی مانند Timewitness است که برای رفع خطای تأیید کاذب در اصلاح‌کدهای هوش مصنوعی طراحی شده‌اند.

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

گام بعدی شما

• از مخزن ai-test-verification-lab در گیت‌هاب برای تمرین شناسایی نقص‌های عمدی استفاده کنید.
• هر بار تستی را از AI گرفتید، این پرسش ۱۵ ثانیه‌ای را بپرسید: «کدام نسخه خراب از این کد، باز هم باعث می‌شود این تست پاس شود؟»
• تست‌های خود را بر اساس مرزهای عددی و منطقی بازنویسی کنید، نه فقط خروجی‌های کلی.

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