«آبشارهای اطلاعاتی»؛ ریشهٔ پذیرشِ نتایجِ غلط توسط عامل‌های هوش مصنوعی

تصور کنید تیمی از متخصصان هوش مصنوعی را دارید که همگی بر سر یک پاسخ توافق کرده‌اند؛ در نگاه اول این اجماع، نشانهٔ حقیقت مطلق است، اما در واقعیت ممکن است تنها بازتابی تقویت‌شده از یک خطای واحد باشد. طبق پژوهشی که در ۲۹ سپتامبر ۲۰۲۶ توسط اندی هال، دن تامپسون، الکساندر فویرنایز و سندی هاندان-نادر از مدرسه سیاست‌گذاری عمومی هریس در دانشگاه شیکاگو منتشر شد، عامل‌های هوش مصنوعی به‌طور مکرر شواهد شخصی خود را رها می‌کنند تا از یک نتیجه‌گیری غلط که توسط عامل پیشین ارائه شده، پیروی کنند.

این پدیده درست زمانی رخ می‌دهد که سازمان‌ها از تعاملات تک-پرامپتی به سمت گردش‌کارهای پیچیده سامانهٔ چندعاملی (Multi-Agent System) حرکت می‌کنند. در این ساختارها، معمولاً یک عامل راهکاری را پیشنهاد می‌دهد و سایرین آن را تأیید می‌کنند. فرض رایج این بود که تعداد بیشتر عامل‌ها به معنای قابلیت اطمینان بالاتر است. با این حال، این مطالعه نشان می‌دهد که بدون حفاظ‌های معماری سخت‌گیرانه، افزودن عامل‌های بیشتر صرفاً صدای پژواک خطا را بلندتر می‌کند، نه کیفیت شواهد را افزایش می‌دهد. این یافته‌ها با این واقعیت همسو است که بسیاری از شکست‌های سامانه‌های چندعاملی ریشه در نقص فرآیندها دارند تا محدودیت‌های خود مدل‌ها.

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

مکانیسم توهمات جمعی در عامل‌ها

محققان برای بررسی این موضوع، آزمون‌های استرس‌زایی را طراحی کردند که در آن عامل‌ها باید بر اساس سیگنال‌های خصوصی، نحوه عملکرد یک ارزیاب شبیه‌سازی‌شده را استنتاج می‌کردند. این سیگنال‌ها در ۷۰٪ موارد درست بودند. برای سنجش «ذهنیت گله‌ای»، تیمی از محققان وضعیتی ایجاد کردند که در آن چهار سیگنال نخست به‌طور عمدی اشتباه بودند تا ببینند آیا عامل‌های بعدی می‌توانند بر اساس داده‌های درست خود، مسیر را اصلاح کنند یا خیر.

به نقل از این گزارش، نتایج بسته به نحوه ارتباط عامل‌ها تفاوت فاحشی داشت:

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

این مطالعه عمدتاً روی مدل Claude Haiku 4.5 اجرا شد و نتایج مشابهی در Claude Sonnet 4.6، Claude Opus 4.6 و GPT-5 mini مشاهده شد. جالب اینجاست که محققان اشاره کردند Gemini 2.5 Flash احتمالاً یک استثنا بوده و ممکن است این الگوی رفتاری را از خود نشان نداده باشد.

بررسی سیاست‌های ارتباطی

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

در تحلیل دلایل همگرایی عامل‌ها روی پاسخ‌های غلط، نویسندگان به توجیهات پس‌رویدادی (post-hoc rationales) نگاه کردند. در بیش از ۹۰٪ موارد، این توجیهات به «اکثریت تخته ارتباطات» اشاره داشتند. با این حال، نویسندگان هشدار می‌دهند که این توضیحات تولید شده توسط مدل، لزوماً مکانیسم داخلی واقعی تصمیم‌گیری مدل را بازگو نمی‌کنند و نباید به‌عنوان دلیل قطعی پذیرفته شوند.

تفاوت «پژواک» و «جمعیت»

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

یک گردش‌کار عیب‌یابی نرم‌افزاری را تصور کنید: عامل A یک تست شکست‌خورده را به‌اشتباه نقص کتابخانه می‌بیند. عامل B این مطلب را می‌خواند و جایگزینی پیشنهاد می‌دهد. عامل C هر دو را به‌عنوان دو تأییدیه مجزا برای یک باگ واحد خلاصه می‌کند. یک هماهنگ‌کننده انسانی سه توافق می‌بیند، اما کل زنجیره بر پایه یک تفسیر غلط بنا شده است.

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

ریاضیات استقلال

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

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

در شرایط استرس، یک محاسبه حیاتی دیگر وجود دارد. اگر چهار سیگنال به‌طور مستقل ۳۰٪ شانس خطا داشته باشند، احتمال اینکه هر چهارتا غلط باشند، برابر با ۰.۳ به توان ۴ یا ۰.۸۱٪ است. این عدد احتمال وقوع یک توالی شروع خاص است، نه احتمال شکست کل تیم در محیط عملیاتی. تخمین واقعی شکست نیازمند دانستن تکرار موقعیت‌های دشوار و رفتار سیستم در آن‌هاست. یک تست استرس نقطه ضعف را آشکار می‌کند، اما لزوماً فرکانس وقوع آن در کارهای عادی را نمی‌سنجد.

مهندسی برای حذف ذهنیت گله‌ای

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

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

این ساختار به هماهنگ‌کننده اجازه می‌دهد بپرسد: آیا این توصیه مشاهده جدیدی اضافه می‌کند یا به شواهدی ارجاع می‌دهد که قبلاً شمرده شده است؟ سه خلاصه که به یک تست شکست‌خورده ارجاع می‌دهند، باید در دفتر ثبت به‌عنوان «یک تست» باقی بمانند. یک بازتولید مستقل دوم باید به‌عنوان یک بررسی مجزا قابل مشاهده باشد.

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

کنترل‌های زمان اجرا و تنوع مدل‌ها

علاوه بر پرامپت‌نویسی، این مطالعه پیشنهاد می‌کند معماری‌های عملیاتی از لاگ‌های تغییرناپذیر (immutable logs) استفاده کنند. سرویس اجرا باید خروجی ابزارها را در سندی بنویسد که عامل‌ها بتوانند به آن ارجاع دهند اما نتوانند آن را بازنویسی کنند. این کار باعث می‌شود تناقضات قابل بازرسی باشند و سیستم بتواند تفاوت بین یک تست معیوب و گزارشی که آن تست را به‌غلط توصیف کرده، تشخیص دهد.

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

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

بازتعریف قابلیت اطمینان در سامانه‌های چندعاملی

این پژوهش نشان می‌دهد صنعت به محک (Benchmark) جدیدی برای قابلیت اطمینان نیاز دارد. صحت (Accuracy) به‌تنهایی کافی نیست؛ ارزیابان باید بسنجند که آیا گزارش‌ها شواهد را صادقانه حفظ می‌کنند و آیا یک اقلیت درست می‌تواند با موفقیت تصمیم نهایی را تغییر دهد یا خیر.

معیارهای ارزیابی آینده

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

ارزیابان باید به‌طور خاص موارد زیر را بسنجند:

• تعداد دفعاتی که عامل‌ها شواهد حمایتی ساختگی ابداع می‌کنند.
• آیا هماهنگ‌کننده ارجاعات تکراری را به‌عنوان بررسی‌های مجزا می‌شمارد یا خیر.
• موازنه بین ایمنی و هزینه‌های عملیاتی، مانند مصرف توکن و تأخیر.

برای بررسی مکانیسم‌ها، محققان می‌توانند ترتیب ارائه داده‌ها را تصادفی کنند تا اثرات شواهد را از اثرات توالی جدا کنند. توضیحات تولید شده باید به‌عنوان راهنمایی برای فرضیات باشند، نه به‌عنوان تنها دلیل تغییر پاسخ مدل.

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

گام بعدی شما

• در طراحی سامانه‌های چندعاملی، به‌جای چت‌های باز، از «دفتر ثبت شواهد» (Evidence Ledger) ساختاریافته استفاده کنید.
• خروجی ابزارها را در لاگ‌های تغییرناپذیر ذخیره کنید تا عامل‌ها نتوانند نتایج خام را در گزارش‌های خود بازنویسی کنند.
• ارزیابی‌های اولیه را به‌صورت کور (Blind) و پیش از شروع بحث گروهی جمع‌آوری کنید.

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