تصور کنید سیستمی ساخته‌اید که با اطمینان کامل، درآمدهای سال ۲۰۱۸ را به گزارش‌های ۲۰۲۲ نسبت می‌دهد، اما تمام داشبوردهای نظارتی شما چراغ سبز نشان می‌دهند. این وضعیت «حلقه توهم خاموش» است؛ وضعیتی که در آن هوش مصنوعی به‌طور فعال حافظه بلندمدت خود را مسموم می‌کند. امانوئل آکیتا در یک پست‌مورتم (تحلیل پس از حادثه) در جولای ۲۰۲۶ در وب‌سایت The New Stack، این عبارت را برای توصیف یک شکست فاجعه‌بار به کار برد.
این حادثه مربوط به تیمی در یک شرکت فین‌تک بود که خط لوله RAG آن‌ها شروع به ارائه داده‌های مالی کاملاً غلط اما با لحنی مطمئن کرد. در حالی که داشبوردهای مشاهده‌پذیری (Observability) آن‌ها هیچ خطایی را نشان نمی‌دادند، سیستم در حال تخریب حافظه خود بود. این شکست شکافی حیاتی را در نحوه استقرار خطوط لوله داده‌های خودگردان نشان می‌دهد. در حالی که ما پیش‌تر بررسی کردیم که چگونه حافظه پذیری معنایی (Semantic Caching) می‌تواند هزینه‌های استنتاج را تا ۵۰٪ کاهش دهد، اما اگر ذخیره‌ساز برداری زیربنایی با داده‌های زباله پر شده باشد، این بهره‌وری‌ها کاملاً بی‌معنا هستند. مسئله اصلی یک خطای دسته‌بندی بنیادی است: برخورد با یک فرآیند احتمالی (Probabilistic) به عنوان یک فرآیند قطعی (Deterministic).
کالبدشکافی یک شکست خاموش
تیم مذکور یک سیستم RAG برای بلعیدن هزاران فایل PDF مالی بدون ساختار ساخته بود. آن‌ها از یک مدل زبانی پیشرو (Frontier LLM) استفاده کردند تا متادیتای کلیدی — مانند سال‌های مالی و موجودیت‌های شرکتی — را استخراج کرده و به فرمت JSON تبدیل کند. سپس این تگ‌ها به بردار معنایی (Embedding) تبدیل شده و در یک پایگاه‌داده برداری ذخیره شدند تا یک چت‌بات پرسش‌وپاسخ داخلی را تغذیه کنند.
در ابتدا، سیستم به خوبی عمل می‌کرد. اما سپس، چت‌بات شروع کرد به نسبت دادن درآمدهای سال ۲۰۱۸ به گزارش‌های سال ۲۰۲۲ و مخلوط کردن شرکت‌های تابعه مشتریان با رقبای آن‌ها. بخش ترسناک این ماجرا نبودن هیچ‌گونه «کرش» یا توقف فنی بود. بازیابی داده‌ها سریع بود (زیر ۱۰۰ میلی‌ثانیه) و جست‌وجوی برداری دقیقاً همان چیزی را برمی‌گرداند که درخواست شده بود؛ مشکل این بود که خودِ داده‌های ذخیره‌شده غلط بودند.
حلقه سوگیری تأییدی
برای جلوگیری از این اتفاق، تیم یک «عامل اعتبارسنج» (Validator Agent) پیاده کرد؛ مدل زبانی دومی که طراحی شده بود تا JSON استخراج‌شده توسط مدل اول را با متن خام PDF مطابقت دهد. این کار باعث ایجاد الگوی خطرناکی شد که به «حلقه سوگیری تأییدی» معروف است. از آنجایی که هم استخراج‌کننده و هم اعتبارسنج، هر دو مدل‌های احتمالی بودند، اعتبارسنج اغلب شروع به توجیه خطاهای مدل اول می‌کرد.
در بسیاری از موارد، اعتبارسنج نمی‌توانست یک تاریخ را در یک PDF تار یا بی‌کیفیت پیدا کند و به اشتباه فرض می‌کرد که مدل اول چیزی را دیده است که خودش متوجه نشده است. این «چاپلوسی» (Sycophancy) به این معنا بود که توافق بین دو مدل احتمالی منجر به درستی نمی‌شد، بلکه صرفاً منجر به یک «اجماع بر سر خطا» می‌گشت.
چرا مهندسی پرامپت شکست می‌خورد؟
تیم در ابتدا سعی کرد نشت داده‌ها را از طریق پرامپت‌های سخت‌گیرانه‌تر اصلاح کند و دستوراتی مانند «توهم نزن» (DO NOT HALLUCINATE) و «تو یک حسابرس مالی سخت‌گیر هستی» را اضافه کرد. این رویکرد از دو جهت نتیجه معکوس داد:
اول اینکه مدل اعتبارسنج بیش از حد تدافعی شد و حتی داده‌های کاملاً درست را رد می‌کرد. دوم اینکه افزایش مراحل استدلالی (Reasoning Steps)، هزینه‌های API را تقریباً ۴۰٪ افزایش داد.
این تجربه تأیید می‌کند که یک پرامپت تنها یک «حس» یا «مود» است، نه یک تضمین فنی. شما نمی‌توانید یک مشکل ساختاری در قابلیت اطمینان را با درخواست از مدل برای «دقیق‌تر بودن» یا «مراقب‌تر بودن» حل کنید.
ساخت حفاظ قطعی (Deterministic Harness)
برای متوقف کردن مسمومیت داده‌ها، تیم مدل زبانی را از مقام تصمیم‌گیری برکنار کرد و اعتبارسنج را با یک «هارنس» یا حفاظ از کدهای سنتی پایتون جایگزین نمود. آن‌ها سه مرز قطعی و سخت‌گیرانه پیاده کردند:
۱. مبنی‌سازی با Pydantic: هر فیلد استخراج شده، مانند سال مالی، باید حتماً یک عدد صحیح (Integer) باشد و از طریق بررسی‌های Regex (عبارات منظم)، حضور فیزیکی آن در متن خام منبع تأیید شود.
۲. ارجاع متقاطع قطعی: موجودیت‌های شرکتی اکنون از طریق تطبیق فازی (Fuzzy Matching) با یک جدول SQL ثابت از موجودیت‌های واقعی مشتریان مقایسه می‌شوند.
۳. قرنطینه پیش‌فرض: هیچ داده‌ای مستقیماً وارد پایگاه‌داده برداری نمی‌شود. همه داده‌ها ابتدا در یک جدول Stage در PostgreSQL قرار می‌گیرند و تا زمانی که تست‌های مبتنی بر کد را پاس نکنند، تبدیل به بردار (Embed) نمی‌شوند.
این رویکرد لایه‌بندی شده برای جلوگیری از مسمومیت حافظه، با مفاهیمی که در بررسی گیت‌های سخت‌افزاری در برابر دستورات متنی تحلیل شد، همسو است تا دسترسی‌های غیرمجاز یا داده‌های مسموم در سطح زیرساختی مسدود شوند.
نتایج و تأثیرات گسترده‌تر
جایگزینی اعتبارسنج LLM با یک حفاظ قطعی، مسموم‌سازی داده‌ها را فوراً متوقف کرد. علاوه‌بر این، حذف مدل زبانی دوم از مسیر نوشتن (Write-path)، هزینه‌های API را تقریباً ۵۰٪ کاهش داد.
این مورد بازتابی از یافته‌های مطالعه سپتامبر ۲۰۲۵ توسط Shao et al با عنوان «عامل شما ممکن است دچار تکامل اشتباه شود» است که ردیابی می‌کند چگونه عامل‌ها بدون نیاز به مهاجمان خارجی، به‌سمت رفتارهای ناایمن میل می‌کنند. به همین ترتیب، پژوهش «عامل‌های زامبی» (Yang et al، فوریه ۲۰۲۶) نشان می‌دهد که چگونه یک تزریق مخرب واحد می‌تواند در صورتی که سیستم به حافظه ذخیره‌شده خود اعتماد مطلق داشته باشد، به یک تخریب دائمی در تمامی جلسات تبدیل شود.
قانون جدید مهندسی
استقرار حرفه‌ای هوش مصنوعی اکنون نیازمند جداسازی سخت‌گیرانه نقش‌ها است: مدل زبانی پیشنهاد می‌دهد، اما کد تصمیم می‌گیرد. استفاده از مدل زبانی به‌عنوان داور (LLM-as-a-judge) ابزاری قدرتمند برای ارزیابی‌های دسته‌ای آفلاین، امتیازدهی به کیفیت ذهنی یا لحن بر اساس یک معیار است؛ اما هرگز نباید دروازه‌بان نهایی در مسیر عملیاتی نوشتن داده‌ها باشد.
اگر داده‌ای قرار است به عنوان «حقیقت» در یک ذخیره‌ساز برداری، حافظه یا پایگاه‌داده نوشته شود، باید از یک سد مهندسی سخت عبور کند. چه تهدید یک توهم داخلی باشد و چه یک تزریق پرامپت خارجی، دفاع یکسان است: یک دیوار آتش قطعی در نقطه ذخیره‌سازی.
توسعه‌دهندگان باید تمرکز خود را از «کامل کردن پرامپت» به «کامل کردن حفاظ (Harness) پیرامون مدل» تغییر دهند. اگر بررسی خاصی را می‌توان با پایتون نوشت، نباید آن را به یک مدل زبانی سپرد.
گام بعدی شما
- اگر از RAG استفاده می‌کنید، هرگونه اعتبارسنجی که با مدل‌های زبانی انجام می‌دهید را به کدهای قطعی (مانند Pydantic یا Regex) منتقل کنید.
- یک لایه‌ی «قرنطینه» یا Staging Table قبل از ورود داده‌ها به Vector Store پیاده‌سازی کنید.
- هزینه‌های استنتاج خود را بررسی کنید تا ببینید آیا مدل‌های تکراری برای اعتبارسنجی، بودجه شما را می‌بلعند؟
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک اینکه چگونه تراشه‌های جدید مدیریت حافظه را تغییر می‌دهند، به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو