اگر امروز از چندین مدل هوش مصنوعی برای بازبینی کد استفاده می‌کنید، احتمالاً در حال تماشای یک نمایش تئاتر هستید، نه یک بازبینی فنی. حقیقت این است که وقتی از مدل دوم می‌خواهید کار مدل اول را بررسی کند، مدل دوم معمولاً حکم مدل اول را می‌بیند و صرفاً با آن موافقت می‌کند. این پدیده در علوم شناختی و هوش مصنوعی به عنوان لنگر انداختن (Anchoring) شناخته می‌شود.
این مشکل ساختاری باعث می‌شود یک حسابرسی مستقل به یک تمرین تایید ساده تبدیل شود. انسان‌ها هم مدام تحت تاثیر این فشار اجتماعی قرار می‌گیرند و تمایل دارند با نظر اول موافقت کنند؛ به همین دلیل جامعه علمی دهه‌ها پیش سیستم «داوری دو سو کور» (Double-blind review) را پذیرفت تا پیش‌داوری‌ها حذف شوند. اما در دنیای عامل‌های هوش مصنوعی (AI Agents) — شبیه به کارمندانی دیجیتال که می‌توانند وظایف پیچیده را به‌طور خودکار انجام دهند — ما تا امروز این حفاظ حیاتی را نادیده گرفته‌ایم.
توهمِ بحث و مناظره
بسیاری از برنامه‌نویسان هنگام کدنویسی با هوش مصنوعی، نوع خاصی از «انتظار» را تجربه می‌کنند؛ آن‌ها صرفاً به جریان تغییرات کد (diff stream) خیره می‌شوند و بدون اینکه کد را به‌طور کامل تحلیل کرده باشند، با دیدن خروجی سر تکان می‌دهند. برای پر کردن این خلاء و ایجاد حس اطمینان، برخی سیستم‌هایی ساختند که در آن مدل دوم سعی می‌کند کار مدل اول را به چالش بکشد یا آن را خراب کند. اما طبق بررسی لاگ‌های خام، این مناظره‌ها اغلب جعلی هستند.
در نسخه‌های اولیه، مدل‌ها ادعاهای مطمئنی رد و بدل می‌کردند و به صورت نقطه به نقطه به هم پاسخ می‌دادند که شبیه به یک بحث واقعی بود، اما در واقع این‌ها ضبط‌شده‌هایی از یک مناظره بودند، نه خودِ مناظره. مدل دوم در حال تحلیل نبود، بلکه متونی را که از پیش تولید شده بودند بازپخش می‌کرد. در این فرآیند، هیچ موضعی تغییر نمی‌کرد و هیچ مدرک یا شواهد جدیدی ارائه نمی‌شد. این «تئاتر»، حالت پیش‌فرض اکثر نظرات دوم در سیستم‌های فعلی هوش مصنوعی است.
برای حل این بحران، یک توسعه‌دهنده در ۱۹ سپتامبر ۲۰۲۶ سیستم AdversarialDebate را منتشر کرد تا به‌طور ساختاری جلوی لنگر انداختن را بگیرد. برخلاف گردش‌کارهای استاندارد که در آن مدل B هم اثر نهایی و هم خروجی مدل A را می‌بیند، این سیستم هر دو مدل را مجبور می‌کند به‌طور موازی و با «صفر زمینه مشترک» (Zero shared context)، نظر نهایی خود را ثبت و قفل کنند.
تنها پس از اینکه هر دو موضع به‌طور مستقل قفل شدند، یک مناظره محدود (Bounded debate) آغاز می‌شود. در این مرحله، هر اعتراض باید حتماً به یک ادعای متقابل خاص اشاره کند و هر ادعا باید متنی مشخص و دقیق از کد یا اثر مورد بررسی را نقل کند. اگر مدل‌ها نتوانند اختلافشان را حل کنند، سیستم به‌جای تحمیل یک اجماع جعلی، یک گزارش اختلاف ساختاریافته تولید می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حفظ تنش در اختلافات، ارزشمندترین سیگنال در یک بازبینی فنی است، زیرا نقاط کور را آشکار می‌کند.
نتایج تست میدانی
به نقل از مستندات پروژه، اثربخشی این روش روی ۷۰ درخواست تغییر (Pull Request) عمومی در ۴۱۱ مناظره آزمایش شد. نتایج نشان داد که دقت این روش نسبت به بازبینی‌های تک‌مرحله‌ای جهش بزرگی داشته است:
- ۸۸.۷٪ تطابق باینری در برابر یک مجموعه داده اصلاح‌شده شامل ۲۳۳۳ ردیف.
- ۸۱٪ از ادعاهای مناظره با نتایج واقعی و مستند شده در PRها مطابقت داشت.
- نرخ تئاتر ۰٪ در نسخه 0.2.0؛ به این معنا که هیچ بحث جعلی یا تکرار متنی در لاگ‌ها شناسایی نشد.
- هزینه پایین: کل هزینه برای ۳۶۰ اجرای بازبین تنها ۰.۴۲ دلار بود. این عدد ثابت می‌کند که قدرت محاسباتی گلوگاه اصلی نیست، بلکه مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — و اندازه‌گیری دقیق داده‌های مرجع (Ground-truth) چالش اصلی هستند.
دردهای مقیاس‌پذیری
رسیدن به این اعداد مستلزم رفع چندین «باگ مقیاس» بود که فقط هنگام اجرا روی مخازن (Repositories) واقعی ظاهر می‌شدند. این موارد شامل موارد زیر بود:
- پارسرهای CSV که وقتی با کاما در توضیحات PR مواجه می‌شدند، از کار می‌افتادند.
- شناسه‌های مدل (Model slugs) که به‌طور خاموش درخواست‌ها را به تامین‌کننده اشتباه می‌فرستادند.
- یک باگ در عملیات Join داده‌ها که باعث شده بود مجموعه داده از ۲۳۳۳ ردیف به ۳۵۹ ردیف کاهش یابد و نتایج را تحریف کند.
پارادوکس تنوع
یکی از شگفت‌انگیزترین یافته‌ها این بود که توانایی خام و قدرت تک‌مدلی، اهمیت کمتری نسبت به تنوع آموزشی دارد. بهترین نتایج نه از ترکیب دو مدل بسیار هوشمند، بلکه از جفت کردن GPT-4o-mini با Mistral Small 3.2 به دست آمد.
مدل‌هایی که از یک آزمایشگاه هستند (مثل GPT و Gemini)، به‌دلیل آموزش شدید با روش RLHF (یادگیری تقویتی با بازخورد انسانی) برای ترجیح دادن هماهنگی و ادب، تمایل داشتند خیلی سریع با هم موافقت کنند. در مقابل، جفت کردن یک مدل آمریکایی با یک مدل اروپایی مثل Mistral، منجر به اختلافات واقعی و در نهایت همگرایی قابل‌اعتمادتر شد.
این موضوع نشان می‌دهد که برای داشتن یک «نظر دوم» واقعی، باید مدل‌هایی از آزمایشگاه‌های مختلف انتخاب کنید، نه اینکه صرفاً به دنبال بالاترین امتیازات بنچمارک باشید. قانون عملی در این پروژه این شد: «همیشه Mistral را اضافه کنید»، زیرا مدل‌های غیر Mistral تمایل داشتند فقط خروجی یکدیگر را مهر تایید بزنند.
شکاف‌های باقی‌مانده
با این حال، سیستم کامل نیست. حدود ۱۱.۳٪ از نتایج همچنان ناقص یا غلط هستند، به‌ویژه در حوزه‌های روایتی (Narrative) مثل گزارش‌های حادثه (Incident reports) و پیشنهادهای تغییر که داده مرجع در آن‌ها مبهم‌تر است. پرامپت‌های عمومی که روی کد جواب می‌دهند، به‌راحتی به تحلیل‌های پس از حادثه (Postmortems) منتقل نمی‌شوند.
ریسک «منفی کاذب» (False negatives) همچنان وجود دارد؛ اگر هر دو مدل مستقل یک باگ را نبینند و هر دو به این نتیجه برسند که «همه چیز خوب است»، کاربر یک حکم غلط اما تمیز دریافت می‌کند. این چالش دقیقاً همان نقطه‌ای است که در یک مورد بحرانی، دو عامل هوش مصنوعی با وجود بازبینی متقابل نتوانستند یک باگ را شناسایی کنند و در نهایت یک انسان متوجه خطا شد. هرچند احتمال اینکه دو مدل مستقل هم‌زمان یک اشتباه را مرتکب شوند بسیار کمتر از بازبینی تک‌مرحله‌ای است، اما این موضوع هرگز یک تضمین مطلق نیست.
برای توسعه‌دهنده، این تغییر نقش انسان را از یک ناظر غیرفعال که به چشمک‌زنِ مکان‌نما خیره شده، به یک قاضی فعال تبدیل می‌کند. حالا انسان به‌جای اسکرول کردن در تغییرات کد، حالت‌های شکست (Failure modes) را می‌خواند، ارزیابی‌ها (Eval) را می‌نویسد و تصمیم می‌گیرد که «خوب بودن» برای این پروژه واقعاً به چه معناست. این نوع متفاوتی از توجه است که کمتر از تماشای یک مکان‌نما، احساس تنهایی می‌کند.
گام بعدی شما
- اگر از سیستم‌های چندعاملی برای بازبینی کد استفاده می‌کنید، لاگ‌های خود را بررسی کنید تا ببینید آیا مدل دوم واقعاً تحلیل می‌کند یا فقط خروجی مدل اول را تایید می‌کند.
- برای افزایش دقت، مدل‌هایی را جفت کنید که از آزمایشگاه‌های مختلف (مثلاً ترکیب OpenAI و Mistral) باشند.
- به‌جای تکیه بر اجماع مدل‌ها، روی گزارش‌های «اختلاف نظر» تمرکز کنید تا نقاط کور کد را بیابید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو