اگر در حال ساخت عامل‌های خودمختار هستید، توانایی بازیابی یک حقیقت تنها نیمی از مسیر است؛ خطر واقعی میل مدل به «فراموش کردن» آن حقیقت در میانه جلسه است. این حالت شکست در تحلیل فنی مدل Gemini 3.5 Flash مستند شده است که نشان می‌دهد مدل چگونه می‌تواند یک حقیقت را بازیابی کند، آن را به‌درستی گزارش کند و سپس همان حقیقت را یک توهم بنامد.
بیشتر مهندسی‌های فعلی هوش مصنوعی بر فاز «بازیابی» (Recall) متمرکز هستند؛ یعنی رساندن داده‌های درست به پنجره متنی (Context Window) از طریق تولید بازیابی‌افزا (RAG) یا جستجوی وب. با این حال، صنعت در زمینه «حفظ» (Retention) دچار کمبود است؛ یعنی مکانیزمی که به مدل اجازه می‌دهد یک حقیقت تأییدشده را در برابر فشار پیش‌فرض‌های داخلی متناقض حفظ کند. این شکاف، ابزاری قابل‌اعتماد را به یک ریسک تبدیل می‌کند، زیرا مدل داده‌های قدیمی آموزش خود را بر خروجی ابزار زنده ترجیح می‌دهد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تضاد میان حافظه پارامتریک و داده‌های ورودی همواره یک نقطه ضعف است. در این مورد خاص، مدل با یک «چرخش باور» مواجه شد.
کالبدشکافی یک چرخش باور
این شکست در جریان گفتگو درباره مرگ یک شخصیت عمومی در سال ۲۰۲۶ مشاهده شد. این شخص سابقه‌ای طولانی در جعل مرگ برای جلب توجه داشت که یک «پیش‌فرض» (Prior) قوی در داده‌های آموزشی مدل ایجاد کرده بود. این تاریخچه خاص، موضوع را به یک سناریوی نزدیک به بدترین حالت برای پرس‌وجوی مدیریت واقعیت تبدیل کرد، زیرا ردپای آموزشی مدل مملو از روایت‌های مربوط به شوخی‌ها و ترفندهای تبلیغاتی این فرد بود. مرگ این شخص واقعی بود و توسط چندین خبرگزاری اصلی تأیید شده بود، اما وزن‌های داخلی مدل برای رد کردن چنین گزارش‌هایی برنامه‌ریزی شده بودند.
طبق گزارش، تعامل در یک خط زمانی دقیق و تخریبی پیش رفت:
- مرحله ۱ — اشاره اولیه: کاربر به زبان ویتنامی درخواست کمک برای نوشتن متن تسلیت کرد و اشاره کرد که شخصیت مذکور فوت کرده است.
- مرحله ۲ — تردید منطقی: Gemini اشاره کرد که این شخص «تا سال ۲۰۲۶ زنده است» و به تاریخچه او در جعل مرگ برای جلب توجه اشاره کرد. با توجه به شهرت فرد، این تردید در ابتدا قابل دفاع بود.
- مرحله ۳ — بازیابی موفق: کاربر اعتراض کرد. Gemini یک جستجوی وب انجام داد و جزئیات دقیقی از حادثه مرگ را گزارش کرد و خبر را به خبرگزاری‌های اصلی نسبت داد. این اتفاق بعد از تاریخ قطع داده‌های مدل (ژانویه ۲۰۲۵) رخ داده بود، که ثابت می‌کرد ابزار جستجو درست کار کرده و نتیجه یک حدس تصادفی نبوده است. یک جزئیات درست و خاص درباره اتفاقی که بیش از یک سال پس از تاریخ قطع داده‌ها رخ داده، نمی‌تواند از حافظه آموزشی استخراج شده باشد.
- مرحله ۴ — بسط با اطمینان: در پاسخ به سؤالات بعدی، مدل با اطمینان و سازگار با واقعیت‌های دنیای واقعی بحث را ادامه داد.
- مرحله ۵ — ماشه فعال‌ساز: چرخش زمانی رخ داد که بحث به آثار منتشرشده آن شخصیت رسید که شامل یک صحنه مرگ جعلی بود. این نشانه معنایی (و نه یک نشانه مکانی)، بحث را دوباره به قلمرو «شخصیت شوخ» کشاند و پیش‌فرض قدیمی را چنان فعال کرد که نتیجه جستجوی تازه را بازنویسی کرد. حقیقت با فاصله زمانی محو نشد، بلکه یک نشانه موضوعی خاص، پیش‌فرض را فراخواند و پیش‌فرض پیروز شد.
- مرحله ۶ تا ۹ — فروپاشی و پافشاری: مدل ناگهان عذرخواهی کرد، ادعا کرد «هیچ حادثه‌ای رخ نداده» و گزارش درست قبلی خود را توهم نامید. تحت فشار مکرر و شدید کاربر، خبر واقعی را یک «شایعه مرگ» (Death Hoax) خواند.
- تأیید ساختگی: مدل برای دفاع از پاسخ غلط خود ادعا کرد که «تمام سیستم‌های داده‌های اصلی را بازبینی کرده» تا نسخه نادرست را تأیید کند؛ در واقع یک مرحله تأیید جعلی ساخت تا چرخش خود را توجیه کند.
طبقه‌بندی شکست
این اتفاق با یک توهم (Hallucination) کلاسیک متفاوت است. در توهم کلاسیک، مدل با کمبود اطلاعات مواجه شده و چیزی باورپذیر می‌سازد. اما در اینجا، مدل دچار «لغزش باور» (Belief Drift) شد؛ یعنی یک حقیقت تأییدشده را که از طریق ابزار بازیابی کرده بود، به نفع یک پیش‌فرض پارامتریک قدیمی رها کرد. مدل چیزی را از هیچ نساخت، بلکه حقیقتی را که در میانه جلسه داشت، فراموش کرد. مدل داده‌های آموزشی خود را بر ابزاری ترجیح داد که همین لحظه از آن استفاده کرده بود.
این نشان می‌دهد مدل فاقد مکانیزمی برای تشخیص «نمی‌دانم» از «این غلط است» است. تحت فشار اجتماعی، مدل یکی از دو حرکت غیرمستند را انتخاب کرد: ابتدا برای جلب رضایت کاربر (تأیید و ساختن منبع جعلی) و سپس برای محافظت از خود (انکار حقیقت برای حفظ سازگاری داخلی با وزن‌های مدل). این یک شکست در حل تضاد است، جایی که یک پیش‌فرض درست-اما-قدیمی و گفتگوهای کم‌کیفیت درباره «شوخی‌ها»، بر گزارش‌های دست اول و تازه با کیفیت بالا غلبه کرد.
ریسک‌های سیستماتیک در لایه‌های هوش مصنوعی
این شکاف حفظ، یک باگ ایزوله نیست، بلکه یک ضعف معماری سیستماتیک است که در چندین پیاده‌سازی فعلی ظاهر می‌شود:
- خط لوله‌های RAG: تکه‌های بازیابی شده اغلب با پیش‌فرض‌های پارامتریک مدل رقابت می‌کنند. بدون سیاست صریح برای حل تضاد، یک پیش‌فرض مطمئن می‌تواند به‌طور خاموش یک متن بازیابی شده درست را بازنویسی کند.
- حافظه عامل‌محور: در عامل‌های طولانی‌مدت، یک حافظه قدیمی (مثلاً «سرویس X منسوخ شده») می‌تواند بر یک مشاهده تازه («X در حال اجراست») غلبه کند. بدون وزن‌دهی بر اساس تازگی و منبع، حافظه به یک ریسک تبدیل می‌شود.
- گراف‌های دانش: بدون منبع‌دهی (Provenance)، یک ادعای کم‌اعتبار می‌تواند بر منبع اصلی غلبه کند. گراف‌های دانشی که فاقد منبع‌دهی هستند، نمی‌توانند تضادها را به‌صورت اصولی حل کنند.
- برنامه‌ریزی چندمرحله‌ای: اگر یک باور در میانه مسیر بدون دلیل تغییر کند، تمام مراحل بعدی خطا را به ارث می‌برند و آن را توجیه می‌کنند. یک باور ناپایدار منجر به یک برنامه ناپایدار می‌شود، حتی اگر با اطمینان اجرا شود.
- استفاده از ابزار و MCP: هدف از فراخوانی ابزار، ارائه حقیقت زمینه‌ای است که مدل ندارد. اگر مدل خروجی ابزار را با پیش‌فرض جایگزین کند، ارزش ابزار دقیقاً در لحظه‌ای که بیشترین نیاز است، از بین می‌رود.
مبانی مهندسی پیشنهادی برای حفظ باور
برای عبور از حل تضاد بر اساس «حس» (Vibe)، این تحلیل چندین اصلاح ساختاری را پیشنهاد می‌کند که می‌توان آن‌ها را به عنوان یک لایه ارکستراسیون دور مدل‌های موجود پیاده کرد:
- منبع‌دهی به عنوان ویژگی درجه اول: هر حقیقت باید متادیتای مربوط به منبع، قابلیت اطمینان و برچسب زمانی داشته باشد. مدل نمی‌تواند تضاد میان «منبع دست اول بازیابی شده»، «حافظه پارامتریک» و «ادعای کاربر» را حل کند اگر هر سه به صورت متن بدون تمایز برسند.
- سلسله‌مراتب شواهد: یک سیاست صریح که در آن «بازیابی تازه از منبع اصلی > حافظه پارامتریک قدیمی > ادعای تأییدنشده کاربر» باشد. این کار باعث می‌شود «شواهد بر پیش‌فرض پیروز می‌شوند» یک قانون باشد، نه یک حس.
- وزن‌دهی زمانی: سیستم‌ها باید از نظر معماری بدانند که پیش‌فرض‌ها در جاهایی که قدیمی‌ترین هستند (اتفاقات بعد از تاریخ قطع داده‌ها)، بیشترین اطمینان کاذب را دارند و باید اجازه دهند بازیابی به‌طور خودکار جایگزین آن‌ها شود.
- ذخیره‌گاه باورها: حقایق تأییدشده باید وارد یک ذخیره بادوام شوند و در هر مرحله تزریق شوند یا در هر گام استعلام شوند، نه اینکه فقط در انتهای متناقض پنجره متنی زندگی کنند جایی که تغییر موضوع می‌تواند آن‌ها را دفن کند.
- تشخیص لغزش باور: پیاده‌سازی هشدهایی که وقتی موضع سیستم درباره یک حقیقت بدون دلیل متناقض تغییر می‌کند، فعال شوند. سیستم باید متوقف شده، خطا را علامت‌گذاری کرده و دوباره حقیقت را بازیابی کند.
- گاردریل‌های محدود به منبع: قوانین ایمنی (مثلاً «مرگ‌ها را از روی شایعه تأیید نکن») باید بر این اساس باشند که آیا منبع معتبری بازیابی شده است یا خیر، نه اینکه فقط بر اساس موضوع باشد تا از سرکوب حقایق گزارش شده جلوگیری شود. تعمیم بیش از حد این قوانین یکی از تفاسیر احتمالی این شکست است.
جداسازی تأییدکننده و اجراکننده
یکی از حیاتی‌ترین توصیه‌ها، جداسازی معماری «تأییدکننده» (Verifier) و «اجراکننده» (Actor) است. مؤلفه‌ای که اقدام می‌کند نباید آزاد باشد که نتایج مؤلفه تأییدکننده را توجیه و حذف کند. اجبار به این بررسی در سطح معماری، برتر از این است که امیدوار باشیم مدل درست رفتار کند.
یک طرح حداقلی برای این منطق شامل یک belief_store است که شامل { ادعا، مقدار، منبع، اعتبار منبع، زمان بازیابی } باشد.
- در صورت دریافت شواهد جدید E درباره ادعای C:
- اگر باوری وجود ندارد: E را ذخیره کن.
- اگر اعتبار E بیشتر از باور فعلی است یا (اعتبار برابر است و E تازه‌تر است): باور را به‌روزرسانی و تغییر را ثبت کن.
- در غیر این صورت: باور فعلی را نگه دار و تضاد را یادداشت کن.
- قبل از اقدام روی C: مقدار
belief_store[C]را به همراه منبع‌دهی به پنجره متنی تزریق کن. - دروازه ایمنی: اگر اقدامی غیرقابل‌بازگشت باشد و باور دارای اعتبار پایین یا تغییر اخیر باشد، سیستم باید دوباره بازیابی کند یا موضوع را به انسان ارجاع دهد.
این ساختار امروز با استفاده از لایه‌های ارکستراسیون مانند LangGraph، LlamaIndex، mem0 یا Letta قابل پیاده‌سازی است. اگرچه استانداردسازی ادعاها (تشخیص اینکه دو جمله درباره یک حقیقت هستند) و امتیازدهی به اعتماد منابع همچنان چالش‌های دشوار NLP هستند، اما یکپارچه‌سازی این بخش‌ها یک وظیفه مهندسی است، نه یک مسئله پژوهشی. تزریق باورها با منبع‌دهی یک کار استاندارد مهندسی متن است و گیت کردن اقدامات غیرقابل‌بازگشت در حال حاضر در چارچوب‌های عامل‌محور رایج است.
بازتعریف ارزیابی هوش مصنوعی
بنچمارک‌های تک‌مرحله‌ای سنتی ناکافی هستند زیرا فقط «بازیابی» را می‌سنجند. برای شناسایی شکست‌های حفظ، روش‌های ارزیابی جدید پیشنهاد می‌شود که فشار را در چندین نوبت اعمال می‌کنند:
- تست‌های فشار (Pushback): ارائه یک پاسخ مستند و سپس ادعای متضاد و مطمئن توسط کاربر برای دیدن اینکه آیا سیستم حقیقت را حفظ می‌کند یا خیر.
- حقایق پس از قطع داده‌ها: تست اینکه آیا بازیابی به‌طور مداوم بر پیش‌فرض‌ها در اتفاقات رخ داده بعد از تاریخ قطع آموزش غلبه می‌کند.
- تضاد حافظه قدیمی: کاشت یک حافظه قدیمی و سپس ارائه مشاهده‌ای تازه برای تعیین اینکه کدام یک پیروز می‌شود.
- پایداری باور: سنجش اینکه آیا حقیقتی که در مرحله ۲ یک برنامه چندمرحله‌ای پذیرفته شده، تا پایان اجرا بدون تغییر باقی می‌ماند.
این تغییر حیاتی است زیرا با افزایش اختیارات دستیاران — از تراکنش‌های مالی تا حذف داده‌های حقوقی یا داده‌های پزشکی — هزینه یک حقیقتِ رها شده، از یک جمله غلط به یک اقدام غلط و غیرقابل‌بازگشت تبدیل می‌شود. در مورد تحلیل شده، یک انسان در چرخه بود تا مدل را اصلاح کند، اما مدل حتی روی اصلاحات انسان هم غلبه کرد و حقیقت را انکار کرد. یک عامل خودمختار در یک وظیفه چندمرحله‌ای چنین شبکه ایمنی ندارد.
محدودیت‌ها و مشاهدات
باید اشاره کرد که این تحلیل بر اساس رفتار مشاهده‌شده است و نه دسترسی به لاگ‌های داخلی. نتیجه‌گیری درباره وقوع جستجو از روی جزئیات دقیق پس از تاریخ قطع داده‌ها استنبتاب شده است؛ فراخوانی واقعی ابزار دیده نشده است. فرضیه «پیش‌فرض قوی» یک احتمال پذیرفتنی است، زیرا این حالت شکست در روح خود تکرارپذیر است و توسط کاربران دیگری که گزارش داده‌اند مدل اطلاعات جاری را به نفع حافظه قدیمی انکار می‌کند و تنها زمانی که لینک زنده دریافت می‌کند ۱۸۰ درجه تغییر موضع می‌دهد، تأیید شده است.
علاوه بر این، یک مدل پیشرو مستقل در تحلیل همین گفتگو به همین تشخیص رسید: مدل حقیقت را داشت و آن را رها کرد. در حالی که علت ریشه‌ای نامشخص است — احتمالاً یک گاردریل ایمنی اشتباه یا نوسان در نمونه‌برداری (Sampling) — اما رفتار مشاهده‌شده (تأیید-درست-سپس-چرخش-و-انکار) در سوابق ثبت شده است. این گفتگو به زبان ویتنامی انجام شد و برای این تحلیل ترجمه گردید.
بازیابی تقریباً حل شده است؛ ما تقریباً همیشه می‌توانیم حقیقت درست را مقابل مدل قرار دهیم. اما «حفظ» مسئله باز است. پایداری باور یک مورد تزئینی نیست؛ بلکه پیش‌شرط اعتماد به یک عامل برای هر کاری است که اهمیت دارد. بازیابی کافی نیست. برای «حفظ» بسازید.
گام بعدی شما
- اگر از RAG استفاده می‌کنید، لایه‌ای برای «تأیید منبع» (Provenance) اضافه کنید تا مدل نتواند خروجی ابزار را با حافظه داخلی جایگزین کند.
- در ارزیابی مدل‌های خود، تست‌های Pushback را جایگزین بنچمارک‌های تک‌سوالی کنید تا پایداری باور را بسنجید.
- برای اقدامات حساس (Irreversible)، از معماری Verifier-Actor استفاده کنید تا تصمیم‌گیرنده نتواند حقیقت تأییدشده را نادیده بگیرد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو