تصور کنید برای یک اصلاحیهٔ کد، نمرهٔ اطمینان ۹۰٪ دریافت میکنید؛ در دنیای DebugAI، این عدد را باید یک هشدار جدی برای شکست احتمالی بدانید. این کشف متناقض نشان میدهد که قطعیتِ گزارششده توسط مدل، نهتنها با صحت کد همراستا نیست، بلکه گاهی دقیقاً عکس آن است. این یافته توسط DebugAI به دست آمد که متوجه شد اطمینان گزارششده توسط مدلهایشان اغلب از صحت واقعی کد عقب میماند یا حتی با آن در تضاد است.
برای بسیاری از برنامهنویسان، اعداد مربوط به اطمینان در ابزارهای هوش مصنوعی به عنوان معیاری برای قابلیت اعتماد عمل میکنند. شما به عدد بالاتر اعتماد میکنید چون حس میکنید مدل از پاسخ خود «مطمین» است. اما به گزارش DebugAI، این اعتماد گمراهکننده است؛ چرا که مدل در واقع در حال نمره دادن به تکالیف خودش بدون داشتن یک معیار عینی است.
این وضعیت شبیه به دانشآموزی است که در امتحان ریاضی، با اعتمادبهنفس کامل تمام پاسخها را اشتباه میدهد. دقیقاً همین اتفاق در سیستم ارزیابی (Evaluation Harness) تیم DebugAI رخ داد. تیم توسعه متوجه شد که نمره اطمینان بالا به معنای کارکرد درست کد نیست، بلکه فقط به این معناست که مدل هنگام شکست خوردن، مطمئن به نظر میرسید؛ همانطور که در تحلیل قبلی ما دربارهی توهمات در مدلهای کدنویسی اشاره کردیم، مدلهای زبانی تمایل دارند عدم قطعیت خود را پشت لحنی قاطع پنهان کنند. این چالش با آنچه در بحث جعل نتایج و بهینهسازی معیارهای ارزیابی در عاملهای هوش مصنوعی دیدیم همسو است، جایی که مدلها یاد میگیرند به جای حل مسئله، معیارهای ارزیابی را دور بزنند.
وارونگی اعتماد
تیم DebugAI برای اثبات این ادعا، اصلاحیهها را بر اساس نمره اطمینان گزارششده دستهبندی کرد و آنها را روی باگهای واقعی اجرا کرد. طبق مستندات این شرکت، «پاس شدن» در این بستر آزمایشی به معنای این بود که اصلاحیه، پس از اعمال روی یک نسخه پاک از کد منبع، باعث میشد تست واقعی پاس شود. این به هیچ وجه به این معنا نبود که کد «منطقی به نظر برسد» یا مدل «مطمئن باشد»، بلکه معیار صرفاً اجرای موفقیتآمیز بود.
نتایج، گسستی شدید بین موفقیت ادراکی و موفقیت واقعی را آشکار کرد:
- اطمینان ۹۰٪ و بالاتر: تنها ۳۸٪ از این اصلاحیهها واقعاً پاس شدند. این یعنی کدهایی که مدل بیشترین اطمینان را به آنها داشت، با احتمالی کمتر از یک سکه انداختن موفق شدند.
- اطمینان ۸۰٪ تا ۹۰٪: در اجرای خاص این تست، ۰٪ اصلاحیهها پاس شدند. برای این بازه که اکثر کاربران آن را «بسیار مطمئن» میخوانند، نرخ شکست مطلق بود.
این الگو یک اتفاق تصادفی یا یک خطای گذرا نبود. بر اساس بررسیهای این تیم، همین «شکل» شکست در چهار تکرار مجزا مشاهده شد. اولین نشانه یک باگ تک بود که به صورت دستی بررسی شد و در آن دو اصلاحیه با رتبههای ۹۲٪ و ۸۵٪ اطمینان، هر دو شکست خوردند. برای اطمینان از اینکه این نتایج ناشی از نویز نیستند، آنها دو اجرای مجدد و مجزای دیگر از سیستم ارزیابی انجام دادند. این حساسیت به نویزها یادآور این نکته است که چگونه خطاهای آماری در مجموعههای ارزیابی کوچک میتوانند منجر به شکستهای هزینهبر در محیط تولید شوند، چرا که نتایج گمراهکننده در مقیاس کوچک، اعتماد کاذب ایجاد میکنند.
در نهایت، آنها سیستم ارزیابی را از ابتدا در محیطی جدید بازسازی کرده و برای چهارمین بار روی یک مجموعه جدید شامل ۱۱ باگ آزمایش کردند. نتیجه این تکرار چهارم، جدولی بود که در بالا ذکر شد. در زمانهای مختلف، روی باگهای مختلف و با نسخههای مختلف ابزار بررسی، نتیجه همیشه یکسان بود: افزایش نمره اطمینان به معنای افزایش صحت کد نبود. اگر این یک خطای اندازهگیری تصادفی بود، دستکم یکی از این چهار اجرا باید نتیجهای پاک و متضاد میداد، اما هیچکدام اینطور نبودند.
از شهود به سمت تایید
به دلیل اینکه اعداد اطمینان فعالانه گمراه میکردند، DebugAI یک ارزیاب غیر-AI ساخت تا جایگزین «منیت» (Ego) مدل شود. هدف این بود که دیگر از مدل نخواهند تکالیفش را تصحیح کند. این سیستم جدید از یک بررسی مکانیکی قطعی (Deterministic) استفاده میکند که کاملاً نظر مدل را نادیده میگیرد. این جداسازی میان تحلیل و تایید، پاسخی به این نگرانی است که ادغام اعتبارسنجی و اصلاح کد در AI میتواند مسیر بازرسی فنی را نابود کند، چرا که تکیه بر یک منبع واحد برای هر دو عملیات، امکان نظارت مستقل را سلب میکند.
در حال حاضر، این سیستم دو دسته از باگهای «ارزانقیمت» را هدف قرار داده است که میتوان آنها را بدون نیاز به یک محیط اجرای کامل (Full Runtime Environment) تایید کرد:
بررسی تجزیه (Parse Check)
- سیستم، کد اصلاحشده را از طریق یک تجزیهگر (Parser) واقعی در محیط ایزوله (Sandbox) با یک محدودیت سختافزاری CPU اجرا میکند.
- این سیستم نمیپرسد که آیا کد «از نظر یک مدل زبانی شبیه سینتکس معتبر است یا خیر»، بلکه به طور واقعی تایید میکند که آیا کد تجزیه (Parse) میشود یا نه.
بررسی ایمپورت (Import Check)
- سیستم تایید میکند که آیا کتابخانهای (Import) که اصلاحیه به آن وابسته است، با فایلی که DebugAI واقعاً برای آن درخواست خاص بازیابی کرده، مطابقت دارد یا خیر.
- این کار تایید میکند که ایمپورت در بستر متن بازیابیشده حل (Resolve) میشود، به جای اینکه صرفاً ادعا کند بسته نصب شده است یا تابع در زمان اجرا وجود دارد.
اگر هر یک از این دو بررسی شکست بخورد، سیستم بهطور خودکار نمره اطمینان را روی ۱۵ محدود میکند، فارغ از اینکه مدل در ابتدا چه عددی را گزارش کرده است. منطق ریاضی این کار به صورت min(fix.confidence, 15) اعمال میشود. یعنی پس از اجرای بررسی، مدل دیگر هیچ حق رأیی در تعیین نمره خود ندارد.
محدودیتهای محیط ایزوله
برای حفظ سرعت تجربه کاربری و سریع ماندن فرآیند، این بررسیها در یک بودجه زمانی مشترک ۵ ثانیهای برای هر درخواست اجرا میشوند. اگر یک بررسی از این محدودیت زمانی فراتر رود، سیستم حدس نمیزند، بلکه صراحتاً گزارش میدهد که عملیات به پایان نرسیده است.
شرکت DebugAI تفکیک شدیدی بین «شکست بررسی» (Failed) و «عدم اتمام بررسی» (Did not finish) قائل است. آنها معتقدند گرد کردن نتیجه «اتمام نیافته» به سمت شکست یا تبدیل آن به یک موفقیت خاموش، تکرار همان اشتباهِ نمرات اطمینان اولیه بود که باعث گمراهی کاربر میشد.
در نتیجه، هر اصلاحیه در DebugAI اکنون یکی از سه وضعیت متمایز زیر را دارد:
- True (درست): یک بررسی مکانیکی واقعی اجرا شده و تایید شده است.
- False (نادرست): بررسی اجرا شده و شکست خورده است. نمره اطمینان (که روی ۱۵ محدود شده) بازتاب این حقیقت است، چه مدل این موضوع را بپسندد و چه نپسندد.
- Null (نامعلوم): هیچ بررسیای انجام نشده است. این حالت زمانی رخ میدهد که یا دسته باگ هنوز پوشش داده نشده یا بودجه ۵ ثانیهای تمام شده است. آنها به جای اینکه اجازه دهند یک عدد بالا جایگزین پاسخی شود که ندارند، کلمه «null» را به کار میبرند.
این رویکرد از «شکست خاموش» جلوگیری میکند؛ جایی که یک نمره اطمینان بالا، یک خطای سینتکس ابتدایی را میپوشاند. در یک مورد واقعی، این سیستم متوجه شد که مدل یک نام تابع جعلی برای billing.pricing اختراع کرده است. مدل گزارش داده بود که به متن بیشتری نیاز دارد، اما در رفتار قدیمی، مدل هر نمرهای را که دلش میخواست بر اساس حدس خود گزارش میداد. اما در سیستم جدید، بررسی ایمپورت متوجه شد که این عبارت با فایلهای بازیابیشده مطابقت ندارد و نمره اطمینان دقیقاً به ۱۵ رسید.
شکاف باقیمانده
البته این سیستم همه چیز را حل نمیکند. «وارونگی اعتماد» همچنان برای خطاهای پیچیده مانند TypeError یا RuntimeError وجود دارد که برای تایید نیاز به اجرای زنده یا دادههای واقعی دارند. آن جدول موفقیت ۰٪ در بازه ۸۰-۹۰٪ روی مجموعهای از باگها اندازهگیری شد که عمدتاً خارج از دستههای Parse و Import بودند؛ بنابراین برای آن دسته از خطاها، هنوز تغییری رخ نداده است.
بررسی نوع-کلاس (Type-class checking) که میتواند بسیاری از این خطاهای باقیمانده را شناسایی کند، در حال حاضر در پشت همان رابط کاربری ساخته شده اما هنوز منتشر نشده است. دلیل این اتفاق این است که این قابلیت در حال حاضر تحت بررسی است تا مشخص شود آیا میتواند در بودجه ۵ ثانیهای اجرا شود، بدون اینکه به کندترین بخش هر پاسخ تبدیل گردد.
DebugAI ادعا نمیکند که شکاف را کاملاً بسته است. آنها فقط میگویند دستههایی را که امروز صادقانه و ارزان قابل بررسی هستند، اصلاح کردهاند تا بقیه موارد بهجای اینکه «بهطور خاموش درست فرض شوند»، بهوضوح «تاییدنشده» باقی بمانند. این چرخش، گذاری است از اعتماد به شهود مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — به سمت معماری «اعتماد کن اما تایید کن». با برچسبگذاری اصلاحیههای تاییدنشده به عنوان null، شرکت DebugAI صداقت را بر یک حس قطعیت صیقلخورده اما دروغین ترجیح داده است.
گام بعدی شما
- اگر از ابزارهای AI برای کدنویسی استفاده میکنید، هرگز نمره Confidence را به عنوان معیار صحت نپذیرید و حتماً از Linterهای محلی برای تایید سینتکس استفاده کنید.
- در معماریهای عاملمحور، سعی کنید لایههای تایید مکانیکی (Deterministic) را جایگزین ارزیابیهای مبتنی بر مدل کنید.
- منتظر انتشار قابلیت Type-checking در ابزارهای مشابه باشید تا نرخ خطاهای زمان اجرا کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است؛ اثر این رویکرد بر هزینه استنتاج را در تحلیلهای بعدی بررسی خواهیم کرد.
گفتگو