«شکاف خوش‌بینی»؛ توهم موفقیت در عیب‌یابی AI بر اساس متادیتا

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

بر اساس مستندات منتشرشده در ۱۰ جولای ۲۰۲۶، پروژه bug-cause-inference-game (نسخه v0.1.0) استدلال می‌کند که جهش بعدی در کدنویسی عامل‌محور، نه در افزایش اعتمادبه‌نفس مدل‌ها، بلکه در اتخاذ یک استراتژی هزینه-آگاه (Cost-aware) برای تصمیم‌گیری درباره‌ی اینکه کدام شواهد باید جمع‌آوری شوند. این رویکرد به‌جای دستور کلی «این باگ را رفع کن»، مدل را مجبور می‌کند از منویی از اقدامات تعریف‌شده با هزینه‌های صریح انتخاب کند.

این رویکرد در زمانی ارائه شده که توسعه‌دهندگان با کدهایی دست و پنجه نرم می‌کنند که توسط AI تولید شده و در ظاهر منطقی به نظر می‌رسند، اما در موارد خاص (edge cases) شکست می‌خورند. این چالش با یافته‌های اخیر همسو است که نشان می‌دهد بسیاری از کدهای تولید شده توسط هوش مصنوعی دارای آسیب‌پذیری‌های امنیتی هستند و نیاز به بررسی‌های دقیق‌تر دارند. در حالی که ابزارهای فعلی AI می‌توانند اصلاحاتی پیشنهاد دهند، اما اغلب بر اساس الگوهای تستینگ بایاس‌شده (دارای سوگیری) عمل می‌کنند و باگ‌های پنهان را نادیده می‌گیرند. پروژه bug-cause-inference-game با این باگ‌های سخت‌یافت به عنوان حریفانی خصمانه برخورد می‌کند که فعالانه سعی در پنهان ماندن دارند و بنابراین نیازمند سیاستی است که میان «بهره اطلاعاتی» و «هزینه بررسی» تعادل ایجاد کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر الگوهای پیش‌فرض بدون بررسی لایه‌های زیرین می‌تواند منجر به نتایج گمراه‌کننده شود. در این پروژه نیز، باگ‌های سخت‌یافت به عنوان «حریفانی فعال» در یک بازی نظری تصور شده‌اند که سعی می‌کنند خود را پنهان کنند؛ بنابراین سیستم باید توازنی میان «کاهش عدم قطعیت» و «هزینه بررسی» ایجاد کند.

زمینه: پرسشی که پروژه را آغاز کرد

این پروژه با یک نگرانی خاص در مورد گردش‌کارهای کمک‌گرفته از AI شروع شد: اگر هوش مصنوعی به نوشتن تست‌ها کمک کند، آیا آن مجموعه از تست‌ها واقعاً کافی هستند؟ اگر الگوی تستینگ دارای سوگیری باشد، باگ‌ها دقیقاً در جایی قرار می‌گیرند که تست‌ها به آنجا نگاه نمی‌کنند. چارچوب مفهومی اولیه، خصمانه و مبتنی بر نظریه بازی‌ها بود؛ به این معنا که شرایط شکست به گونه‌ای مدل شدند که گویی می‌کوشند پنهان بمانند و سپس پرسیده شد که کدام سیاست بررسی می‌تواند در برابر چنین فشاری پایداری کند.

بسیار مهم است که مرزهای این نسخه مشخص شود. تگ v0.1.0 (کامیت 9e30c93f246602d840c875e975c362e6ab1e7747) یک مرحله آماده‌سازی و یک پروتوتایپ کوچک برای بررسی علت باگ با در نظر گرفتن هزینه است. این نسخه یک موتور مکان‌یابی خطای صنعتی (production fault-localization)، یک ابزار تعمیر خودکار، یک بنچ‌مارک دیباگینگ LLM، یک چارچوب فازینگ (fuzzing) یا یک دیباگر رسمی مبتنی بر نظریه بازی‌ها نیست. طراحی آن بیشترین شباهت را به دیباگینگ احتمالی، تشخیص خطا به روش Bayesian و تشخیص فعال (active diagnosis) دارد: رتبه‌بندی علت‌های محتمل بر اساس مشاهدات و سپس انتخاب مشاهده بعدی بر اساس هزینه.

P1a: صریح کردن اقدامات بررسی

فاز نخست (P1a)، کوچکترین برش پروژه است. این بخش روی موارد مصنوعی باگ‌های مشاهده‌شده کار می‌کند، احتمالات پسین (posterior probabilities) را برای دسته‌بندی‌های کلی علت‌ها به‌روزرسانی می‌کند و یک گزارش تصمیم‌گیری (DecisionReport) صادر می‌کند که خروجی اصلی آن «اقدام بعدی توصیه شده» (recommended_next_action) است.

جزئیات و مکانیسم‌های P1a:

• مجموعه داده: ۵۰ مورد که با یک Seed ثابت (20260627) ساخته شده‌اند.
• دسته‌بندی‌های علت (۵ مورد):
  • شرایط مرزی (boundary_condition)
  • نبود مدیریت مقادیر تهی (missing_null_handling)
  • پیکربندی محیطی (configuration_environment)
  • وابستگی به ترتیب یا رقابت (race_order_dependence)
  • عدم تطابق با مشخصات (specification_mismatch)
• اقدامات بررسی (۸ مورد):
  • بررسی لاگ خطا، اجرای تست‌های مرزی، مقایسه محیط، بررسی Diffهای اخیر، اجرای ماتریس بازتولید، افزودن ابزار اندازه‌گیری (instrumentation)، بررسی پذیرش مشخصات و اجرای استرس هم‌زمانی.
• سیاست‌های پیاده‌سازی شده: سیستم سیاست‌های مختلفی را مقایسه می‌کند: random (تصادفی)، fixed_checklist (چک‌لیست ثابت)، posterior_greedy (حریص بر احتمال پسین)، cheapest_first (ارزان‌ترین ابتدا)، information_gain (بهره اطلاعاتی)، information_gain_per_cost (بهره اطلاعاتی به ازای هزینه)، static_posterior و سیاست اصلی یعنی همان information_gain_per_cost.
• محدودیت‌های توقف: برای جلوگیری از «جادویی» شدن سیستم، محدودیت‌های صریحی تعریف شده است: آستانه احتمال برتر ۰.۷۵، آستانه حاشیه (margin) ۰.۱۵، حد بودجه ۱۰، حداکثر ۵ گام، حداقل بهره اطلاعاتی مورد انتظار به ازای هزینه ۰.۰۳ و هزینه شکست ۱۲.

نتایج P1a:
مجموعه داده مصنوعی نسبتاً آسان بود؛ پیش از هر اقدامی، دقت Top-1 موارد ۷۰٪ و دقت Top-2 آن‌ها ۱۰۰٪ بود و تنها ۱۵ مورد از ۵۰ مورد در ابتدا اشتباه تشخیص داده شده بودند. با این حال، مقایسه سیاست‌ها داده‌های مفیدی ارائه کرد. سیاست information_gain_per_cost دارای میانگین هزینه رسیدن به علت واقعی (cost_to_true_cause_top1) معادل ۱.۱۲ بود، در حالی که fixed_checklist به طور میانگین ۱.۵۶ هزینه داشت. این نشان‌دهنده کاهش هزینه حدود ۲۸ درصدی نسبت به چک‌لیست ثابت است، با نرخ موفقیت ۹۴٪ در محدوده بودجه.

با این حال، این موفقیت یک نشانه هشدار را آشکار کرد: نرخ «توقف اشتباه» (wrong-stop) حدود ۱۳٪ بود (یعنی توقف بر روی یک فرضیه با اطمینان بالا اما نادرست). در زیرمجموعه‌ای که در ابتدا اشتباه تشخیص داده شده بودند، سیاست information_gain_per_cost هزینه میانگین کمتری (۳.۷۳) نسبت به fixed_checklist (۵.۲) داشت، اما fixed_checklist نرخ موفقیت بالاتری (۰.۸۷ در مقابل ۰.۸) ثبت کرد. نتیجه‌گیری این است: آگاهی از هزینه، هزینه میانگین را در یک محیط مصنوعی کاهش داد، اما دقت در دنیای واقعی را ثابت نکرد.

P1b: شکاف خوش‌بینی در متادیتا

برای عبور از موارد مصنوعی، فاز P1b یک چارچوب بنچ‌مارک قیمت‌گذاری و بررسی باگ‌های تزریق‌شده (injected-bug) را معرفی می‌کند. این فاز سیاست‌های آگاه به بودجه را بر روی ۲۰ نسخه دارای باگ و ۵ نسخه پاک (clean) ارزیابی می‌کند و بر کشف شکست، رتبه‌بندی مکان خطا در سطح تابع، استنتاج علت کلی و پیش‌بینی قصد اصلاح (fix-intent) تمرکز دارد (هرچند وصله یا Patch تولید نمی‌کند).

حالت‌های مشاهده در P1b:

• metadata_synth: یک خط مبنای ثابت از فاز A/B که شواهد را از متادیتای نسخه‌ها سنتز می‌کند.
• execution_grounded: مشاهدات را از نتایج اجرای تست‌ها، استثناها (exceptions)، توابع ردیابی شده (traced functions)، مشکوک بودن طیف پوشش (coverage-spectrum suspicion) و مصنوعات Diff واقعی در فاز C می‌سازد.

اقدامات و سیاست‌های P1b:
مجموعه اقدامات برای انعکاس یک جریان کاری واقعی دیباگینگ گسترش یافت. اقدامات تست شامل: run_smoke_tests (تست‌های دود)، run_boundary_tests (تست‌های مرزی)، run_null_missing_tests (تست‌های مقادیر تهی)، run_config_matrix_tests (تست‌های ماتریس پیکربندی) و run_state_sequence_tests (تست‌های توالی وضعیت) است. اقدامات بازرسی شامل: inspect_traceback (بررسی ردپای خطا)، inspect_coverage_spectrum (بررسی طیف پوشش)، inspect_recent_diff (بررسی Diffهای اخیر) و inspect_spec_clause (بررسی بندهای مشخصات) است. سیاست اصلی مورد استفاده در اینجا expected_utility_per_cost (سود مورد انتظار به ازای هزینه) است.

نتایج یک «شکاف خوش‌بینی» (optimism gap) شدید را نشان داد. وقتی سیاست بر اساس شواهد مشتق شده از متادیتا بود، بسیار مؤثرتر به نظر می‌رسید تا زمانی که به اجرای واقعی گره خورده بود. این پدیده مشابه توهمات ساختاری در کدنویسی است که ابزارهایی مانند BrassCoders سعی در شناسایی و حذف خودکار آن‌ها دارند تا از اعتماد کاذب به کدهای تولید شده توسط مدل‌ها جلوگیری شود. برای سیاست expected_utility_per_cost نتایج به شرح زیر بود:

• کشف باگ در محدوده بودجه: در حالت متادیتا ۰.۵۵ و در حالت اجرایی ۰.۴۰
• دقت Top-1 علت: در حالت متادیتا ۰.۸۰ و در حالت اجرایی ۰.۵۵
• دقت Top-1 قصد اصلاح: در حالت متادیتا ۰.۷۵ و در حالت اجرایی ۰.۴۰
• میانگین هزینه بررسی: در حالت متادیتا ۲.۸۰ و در حالت اجرایی ۴.۶۴

این یعنی وقتی AI فقط به متادیتا تکیه می‌کند، بسیار خوش‌بین‌تر از واقعیت عمل می‌کند و به محض اینکه کد واقعاً اجرا می‌شود، این اعتمادبه‌نفس فرو می‌ریزد.

P1c: افشای بدترین حالت‌ها

لایه نهایی، P1c، یک گزارش صرفاً تحلیلی روی همان چارچوب ۲۵ نسخه‌ای P1b است. این فاز می‌پرسد آیا سیاست‌ها زمانی که شواهد عمداً دشوار، مبهم، گران یا گمراه‌کننده باشند، همچنان مفید هستند یا خیر. P1c امتیازات میانگین را رد کرده و به جای آن از «تحلیل سبدی» (bucket analysis) برای شناسایی حالت‌های شکست خاص استفاده می‌کند.

سبدهای تحلیلی P1c:
این تحلیل از برچسب‌های سبد زیر استفاده می‌کند:

• boundary_precision (دقت مرزی)
• missing_optional_input (ورودی اختیاری گمشده)
• config_normalization (نرمال‌سازی پیکربندی)
• state_sequence (توالی وضعیت)
• spec_semantics (معناشناسی مشخصات)
• clean_false_positive (مثبت کاذب در نسخه‌های پاک)

برای سیاست اصلی expected_utility_per_cost (با خط مبنای تجمیعی: کشف ۰.۴۰، دقت علت ۰.۵۵، دقت قصد اصلاح ۰.۴۰ و هزینه میانگین ۴.۶۴)، نمای سبدی نقاط ضعف بحرانی را آشکار کرد:

• باگ‌های توالی وضعیت (State Sequence): این شکننده ترین سبد است. نرخ کشف، رتبه‌بندی Top-3 مکان، دقت Top-1 علت و دقت Top-1 قصد اصلاح همگی ۰.۰ هستند و هزینه اولین شکست ۱۴ است.
• نرمال‌سازی پیکربندی (Config Normalization): یک سبد ضعیف گسترده که در آن هر چهار معیار موفقیت ۰.۲۵ هستند و هزینه اولین شکست ۱۰.۷۵ است.
• ورودی اختیاری گمشده (Missing Optional Input): موفق اما گران. در حالی که هر چهار معیار موفقیت ۱.۰ و هزینه اولین شکست ۱ است، اما میانگین هزینه بررسی به شدت جهش کرده و به ۹.۷۵ می‌رسد.

فلسفه طراحی

کلمه «بازی» (game) با دقت انتخاب شده است. اگرچه نسخه v0.1.0 ادعای مدل بازیکن رسمی، مدل پرداخت یا سیاست بهینه minimax را ندارد، اما فلسفه آن این است که باگ‌های سخت مانند حریفی رفتار می‌کنند که سعی دارد پنهان بماند. با انتخاب بدترین موارد و شرایط استرس، P1c پرسش «میانگین‌ها قابل قبول به نظر می‌رسند» را به «کدام دسته از موارد سیاست را می‌شکند و چگونه؟» تبدیل می‌کند.

برای یک جریان کاری کدنویسی با کمک AI، درس‌های این پروژه کوچک و منضبط هستند:
۱. اقدامات بررسی را صریح کنید.
۲. برای این اقدامات هزینه تعیین کنید.
۳. سیاست‌ها را تحت قوانین توقف و محدودیت‌های بودجه یکسان مقایسه کنید.
۴. شواهد شبیه متادیتا را از شواهد مبتنی بر اجرا جدا کنید.
۵. سبدهای بدترین حالت را در کنار میانگین‌ها گزارش کنید.

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

برای بررسی منطق پروژه، کامیت v0.1.0 (9e30c93f) را در گیت‌هاب مرور کنید تا ببینید هزینه‌های اقدام در سیاست اصلی چگونه وزن‌دهی شده‌اند.

گام بعدی شما

• اگر در حال توسعه‌ی عامل‌های کدنویسی هستید، به‌جای گزارش «صحت میانگین»، تحلیل‌های مبتنی بر «دسته‌بندی شکست» (Failure Buckets) را پیاده‌سازی کنید.
• برای هر اقدام عیب‌یابی (مثلاً اجرای یک تست خاص)، یک وزن هزینه (Cost Weight) تعریف کنید تا مدل از جست‌وجوی کورکورانه فاصله بگیرد.
• تفاوت نتایج مدل را در حالت دسترسی به متادیتا در برابر اجرای واقعی کد بسنجید تا دچار توهم موفقیت نشوید.

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