آیا توافق مدل‌های زبانی لزوماً به معنای صحت پاسخ است؟

تصور کنید تیمی از هوشمندترین مدل‌های هوش مصنوعی جهان، همگی با اطمینان کامل روی یک گزینه توافق می‌کنند؛ در دنیای اتوماسیون رابط کاربری، این لحظه می‌تواند خطرناک‌ترین نقطه باشد. طبق گزارش‌های پروژه Automation Sandbox، در آزمایش‌هایی که بین ۱۶ تا ۱۸ اوت ۲۰۲۶ انجام شد، مشخص شد وقتی یک المان UI حذف می‌شود، مدل‌ها نه‌تنها شکست می‌خورند، بلکه «با هم» شکست می‌خورند. هر مورد از توافق جمعی ارائه‌دهندگان روی یک المان حذف‌شده، منجر به یک «ترمیم کاذب» (False Heal) شد؛ جایی که هوش مصنوعی با اعتمادبه‌نفس کامل، دکمه همسایه اشتباهی را انتخاب کرد.

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

شکست روش‌های اکتشافی

پژوهشگران پیش از آزمایش مدل‌های زبانی، یک خط مبنا با استفاده از یک امتیازدهنده ساختاری قطعی (Deterministic) در زبان C# ایجاد کردند. آن‌ها از درخت‌های UI زنده در برنامه‌های HandBrake 1.8.2 (WPF) با ۱۴۹ گره و ۴۲ لوکیتور منحصر‌به‌فرد، و همچنین ShareX v21.0.0 (WinForms) استفاده کردند تا مطمئن شوند یافته‌ها وابسته به یک برنامه خاص نیست و در محیط‌های مختلف (WPF و WinForms) تکرارپذیر است.

برای تست تاب‌آوری موتور، پنج سطح تغییر (Mutation Tiers) شبیه‌سازی شد:

• تغییر نام خالص (Pure rename): تغییر AutomationId به یک شناسه نامفهوم و مبهم.
• تغییر برچسب (Name/label drift): بازنویسی متن قابل مشاهده یا لیبل المان.
• جابه‌جایی موقعیت (Position shift): حرکت کنترل در چیدمان (مثلاً ۱۰۰ پیکسل) در یک پاس لایه.
• تغییر ترکیبی (Compound drift): ترکیبی از تغییرات متن و جابه‌جایی در لایه.
• حذف المان (Element removal): حذف کامل زیردرخت (Subtree) از رابط کاربری.

بر اساس مستندات پروژه، در آستانه اطمینان پیش‌فرض ۰.۵۰، نتایج برای HandBrake تکان‌دهنده بود:

• تغییر نام AutomationId: ۴۲ مورد درست، ۴۰ مورد در محدوده امتیاز [1.000, 1.000].
• تغییر نام/برچسب: ۲۵ مورد درست، ۲۳ مورد در محدوده امتیاز [0.877, 0.950].
• جابه‌جایی موقعیت: ۴۲ مورد درست، ۳۴ مورد در محدوده امتیاز [0.832, 0.955].
• تغییر ترکیبی: ۲۵ مورد درست، ۶ مورد ترمیم کاذب، ۱۷ مورد از دست رفته (نیازمند بررسی)، محدوده امتیاز [0.749, 0.874].
• المان حذف‌شده: ۴۲ مورد درست، ۲۵ مورد ترمیم کاذب، ۱۷ مورد از دست رفته (نیازمند بررسی)، محدوده امتیاز [0.344, 0.955].

در نتیجه، ۴۰.۵٪ از المان‌های حذف‌شده در HandBrake به‌اشتباه «ترمیم» شدند. این رقم در ShareX به ۵۷.۱٪ رسید. برای کاهش این خطا، آستانه اطمینان به ۰.۹۰ افزایش یافت که هرچند خطاهای ترمیم در المان‌های حذف‌شده را به ۵.۵٪ کاهش داد، اما سه‌چهارم تمام لوکیتورهای معتبر را به بخش بررسی دستی منتقل کرد. در واقع هیچ تنظیماتی وجود نداشت که بتواند تعادلی رایگان بین دقت و اتوماسیون ایجاد کند.

مرز ریاضی «نبودن»

این مطالعه به‌طور دقیق ثابت کرد که یک امتیازدهنده صرفاً اکتشافی (Pure-heuristic) نمی‌تواند مورد حذف المان را حل کند. دلیل ریاضی این است که یک المان همسایه که در ظرف (Container) یک کنترل حذف‌شده باقی مانده است، از نظر ساختاری با المانی که واقعاً به کنار آن همسایه جابه‌جا شده، غیرقابل تشخیص است.

توزیع امتیازات شباهت این دو حالت به‌شدت هم‌پوشانی دارد: [0.665, 0.955] برای فریب‌های المان حذف‌شده در مقابل [0.749, 0.874] برای تغییرات ترکیبی واقعی. به دلیل این هم‌پوشانی، هیچ آستانه اطمینانی، حاشیه رده‌دوم (Runner-up margin)، تراکم خوشه‌ای یا فیلتر نوع کنترل نمی‌تواند خطی قابل‌اعتماد بین این دو رسم کند. همین نتیجه منفی بود که تیم را به سمت آزمایش مدل‌های زبانی سوق داد تا ببینند آیا استدلال معنایی می‌تواند تفاوت «جابه‌جایی» را از «ناپدید شدن» تشخیص دهد.

آزمایش اجماع مدل‌های زبانی

تیم تحقیق بررسی کرد که آیا یک «کواروم» یا حد نصاب از مدل‌های مستقل می‌تواند حذف واقعی یک المان را تشخیص دهد. آن‌ها از مجموعه‌ای از ارائه‌دهندگان شامل Cloudflare/Qwen، Mistral و OpenRouter/gpt-oss استفاده کردند.

برای جلوگیری از تقلب مدل‌ها، سیستم حفاظتی شدیدی برای جلوگیری از نشت داده‌ها (Leakage Protection) اجرا شد. هر AutomationId در درخت تغییریافته به فرمت نامفهوم تبدیل شد (با استفاده از ablation- + SHA-256 hex). این کار تضمین کرد که مدل‌ها نتوانند سناریوها را صرفاً با شناسایی یک شناسه «عجیب» یا «متفاوت» حل کنند. از آنجا که شناسه‌ها هیچ سرنخ معنایی نداشتند، این نتایج را به پایین‌ترین حد ممکن (Lower Bound) تبدیل کرد؛ در محیط واقعی، شناسه‌های توصیفی مثل btnSaveDocument سیگنال‌های بیشتری می‌دهند.

پروتکل ارزیابی و داده‌ها

ارزیابی با دمای (Temperature) صفر انجام شد تا پاسخ‌ها قطعی باشند. یک سناریو تنها زمانی «قابل استفاده» بود که حداقل دو ارائه‌دهنده پاسخ می‌دادند، زیرا یک نظر واحد نمی‌تواند توافق یا عدم توافق را ثابت کند. برای مدیریت هزینه‌های توکن (Token)، تیم روی دو زیرمجموعه متمرکز شد: ۲۵ سناریوی تغییر ترکیبی و ۴۲ سناریوی حذف المان.

در بازه ۱۶ تا ۱۸ اوت ۲۰۲۶ و در ۱۳۳ سناریوی قابل استفاده، الگوی بحرانی زیر مشاهده شد:

• المان‌های باقی‌مانده: توافق جمعی در ۵۲ مورد از ۵۲ مورد درست بود.
• المان‌های حذف‌شده: توافق جمعی در ۳۴ مورد از ۳۴ مورد غلط بود.

در ۷ مورد از این شکست‌ها، سه خانواده کاملاً متفاوت از مدل‌ها (Cloudflare/Qwen، Mistral و OpenRouter/gpt-oss) به‌طور هم‌زمان روی یک المان غیرموجود توافق کردند. افزایش تعداد مدل‌ها از ۳ به ۷ نیز کمکی نکرد؛ نرخ توافق روی المان‌های حذف‌شده نوسان داشت (۲۵٪ $\rightarrow$ ۴۵٪ $\rightarrow$ ۵۸٪ $\rightarrow$ ۴۰٪) اما هیچ روند نزولی نداشت و دقت در تمام مراحل ۰٪ باقی ماند.

مکانیسم عدم توافق

این مطالعه نتیجه می‌گیرد که مدل‌های زبانی در واقع متوجه حذف یک کنترل نمی‌شوند. فرضیه اولیه این بود که مدل‌ها یا از پاسخ دادن خودداری می‌کنند یا روی گزینه‌های مختلف پراکنده می‌شوند. در عمل، خودداری از پاسخ تقریباً هرگز رخ نداد؛ در ۷۸ سناریوی قابل استفاده از حذف المان، حالت «همه ارائه‌دهندگان خودداری کردند» دقیقاً یک بار رخ داد.

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

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

مهندسی برای دور زدن نقص

به دلیل این یافته‌ها، Automation Sandbox یک گیت معماری سخت‌گیرانه اجرا می‌کند. مدل زبانی هرگز تصمیم‌گیرنده اصلی نیست و سلسله‌مراتب زیر را دنبال می‌کند:

• اولویت با اکتشافی (Heuristic-First): یک امتیازدهنده ساختاری C# تصمیم می‌گیرد. این سیستم حدود ۳۰۰۰ کنترل را در ۲۳ میلی‌ثانیه و بدون مصرف توکن پردازش می‌کند. مدل زبانی هرگز در مسیر پیش‌فرض نیست. این رویکرد مشابه استراتژی‌هایی است که در جایگزینی کد قطعی با متن برای حل ناپایداری داورهای هوش مصنوعی به کار رفته تا از توهمات مدل‌های زبانی جلوگیری شود.
• کواروم اختیاری (Opt-in Quorum): مدل‌های زبانی تنها به عنوان جایگزین (Fallback) و با شرط توافق مستقل (حداقل ۲ ارائه‌دهنده باید به‌طور مستقل یک کاندید یکسان را نام ببرند) وارد می‌شوند. اطمینان یک مدل تک را بی‌ارزش می‌دانند.
• اعتبارسنجی اجرا (Execution Validation): یک ترمیم تنها زمانی ثبت می‌شود که اقدام مجدد در برنامه واقعاً موفق شود. اگر یک انتخاب اشتباه نتواند مرحله تست را اجرا کند، پیش از ثبت دائمی شناسایی و رد می‌شود.
• ممیزی کامل (Full Audit): هر تصمیم در گزارش‌های JSON و HTML ثبت می‌شود. این گزارش ثبت می‌کند که کدام سیگنال چه وزنی داشت و کدام ارائه‌دهندگان رای دادند تا عبارت «هوش مصنوعی آن را ترمیم کرد» هرگز تنها دلیل یک تغییر نباشد.

این رویکرد، یک شکست خاموش (تستی که باید قرمز باشد اما سبز می‌ماند) را به یک رویداد قابل مشاهده و قابل رد تبدیل می‌کند و می‌پذیرد که تشخیص نبودِ بدون کمک، به‌طور ریاضی توسط هم‌پوشانی ساختاری محدود شده است.

بازتولید نتایج

برای کسانی که می‌خواهند این یافته‌ها را تأیید کنند، پروژه سه مسیر اصلی را از طریق .NET SDK فراهم کرده است:
۱. خط مبنای اکتشافی: اجرای LocatorAblationTests.HandBrakeFixture_RunsEndToEndAndReportsMetrics و ThresholdSweep برای مشاهده نرخ شکست قطعی بدون مصرف توکن.
۲. کالیبراسیون سفارشی: استفاده از samples/CalibrationCli برای کالیبره کردن سیستم در برابر یک درخت UI ثبت‌شده سفارشی.
۳. ارزیابی زنده: اجرای LocatorAblationTests.HandBrakeFixture_LlmConsensus_LiveEvaluation با تنظیم کلیدهای API ارائه‌دهندگان در متغیرهای محیطی برای تست اجماع چند-ارائه‌دهنده.

محدودیت‌ها و دامنه

این مطالعه چندین محدودیت را می‌پذیرد. داده‌ها از یک خانواده مجموعه داده (دو برنامه) آمده‌اند و اجرای ۴۲ سناریوی حذف، تقریباً دارای ±۱۴٪ عدم قطعیت آماری است. علاوه بر این، استفاده از شناسه‌های نامفهوم (Ablation IDs) به این معناست که عملکرد در محیط تولید با شناسه‌های توصیفی ممکن است بالاتر باشد، هرچند یافته اصلی — اینکه توافق روی یک المان حذف‌شده غیرقابل اعتماد است — همچنان پابرجاست.

در نهایت، این مطالعه یک طراحی پرامپت (لیست کوتاه N-تاپ محدود شده، دمای ۰) را تست کرد. اگرچه این ثابت نمی‌کند که هیچ پرامپتی هرگز نمی‌تواند عمل کند، اما ثابت می‌کند که «توافق ارائه‌دهندگان» به عنوان یک مکانیسم، آن تضمین امنیتی را که بسیاری تصور می‌کنند، ندارد.

پروژه Automation Sandbox تحت لایسنس MIT است، به‌طور کامل با C#/.NET نوشته شده و از طریق هفت بسته در nuget.org در دسترس است. این پروژه قابلیت ترمیم خودکار لوکیتورها و تولید تست‌های مبتنی بر قصد (Intent-driven) را برای دسکتاپ ویندوز (FlaUI/UIA3) و وب (Playwright) فراهم می‌کند. برای توسعه‌دهندگانی که تست‌های UI آن‌ها با هر بازطراحی می‌شکند، این پروژه راهی ارائه می‌دهد تا شکست‌ها به‌جای خاموش و سبز بودن، قابل مشاهده و رد شوند.

گام بعدی شما

• اگر از تست‌های UI استفاده می‌کنید، هرگز به «اطمینان» (Confidence) تک‌مدلی برای ترمیم لوکیتورها اعتماد نکنید.
• برای کاهش نرخ False Heal، لایه‌ای از اعتبارسنجی اجرایی (Execution Validation) را به خط لوله تست خود اضافه کنید.
• در صورت استفاده از مدل‌های زبانی، از استراتژی Quorum (توافق چند مدل مستقل) برای شناسایی توهمات جمعی استفاده کنید.

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