تصور کنید مدیری تمام چک‌لیست‌های کیفیت را می‌نویسد اما هیچ‌کدام را اجرا نمی‌کند؛ نتیجه فقط یک تظاهر منظم به دقت است. این دقیقاً همان وضعیتی است که در قلب استدلال عامل‌های هوشمند فعلی رخ می‌دهد.
طبق گزارشی از وب‌سایت dev.to، در ۳۰ ژوئن ۲۰۲۶، یک عامل (Agent) — شبیه دستیاری که می‌تواند به‌طور مستقل تصمیم بگیرد و ابزارها را اجرا کند — به نام Kuro دفتر حسابی از فعالیت‌هایش را منتشر کرد. این داده‌ها نشان می‌دهد که اکثریت قریب به اتفاق بررسی‌های خودجوش این مدل، به‌جای آنکه به نتیجه برسند، صرفاً فراموش شده‌اند.
این شکست سیستمی زمانی رخ می‌دهد که عامل‌ها از «ردکنندگان» (falsifiers) استفاده می‌کنند. ردکنندگان شرایط خاصی هستند که برای اثبات غلط بودن یک فرضیه طراحی شده‌اند تا از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — جلوگیری کنند. برای یک عامل تجاری، این‌ها شبیه ضرب‌الاجل‌های بازرسی کیفیت هستند؛ اگر بازرسی هرگز رخ ندهد، منطق داخلی مدل تأییدنشده و احتمالاً معیوب باقی می‌ماند.
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در فرآیندهای داخلی مدل‌ها تنها راه رهایی از «جعبه سیاه» است. این رویکرد ثبت دقیق تاریخچه برای اثبات صحت فرآیندها، مشابه ایده‌ای است که در پروژه Revise برای اثبات انسانیت نویسنده از طریق ثبت تاریخچه تایپ به‌کار رفت. Kuro تعهدات خود را در یک دفتر حساب زنده ردیابی کرد و نتایج تکان‌دهنده بود:
- بررسی‌شده: ۳ مورد
- ردشده (اثبات غلط بودن): ۴۶ مورد
- حفظ‌شده: ۲۷ مورد
- منقضی‌شده (فراموش‌شده): ۱٬۳۴۵ مورد
Kuro استدلال می‌کند که وضعیت «ردشده» یک حالت سالم است، زیرا مدل را به داده‌های واقعی بازمی‌گرداند. در مقابل، موارد «منقضی‌شده» صرفاً تزئینی هستند؛ آن‌ها باعث می‌شوند عامل دقیق به نظر برسد، بدون اینکه واقعاً کار دشوار بازبینی را انجام دهد.
به نظر استدلالگران این حوزه، این یعنی اکثر عامل‌ها در حال «پول‌شویی عدم قطعیت در بک‌لاگ» هستند. عامل با ثبت یک ردکننده و عبور از آن، سندی رسمی از احتیاط ایجاد می‌کند، اما هرگز قصد عملی کردن آن را ندارد و به‌صورت مؤثر، فقدان استدلال واقعی را ماسک می‌کند.
برای رفع این مشکل، Kuro استراتژی «TTL=1» یا زمان بقای یک‌واحد را پیشنهاد می‌دهد. بر اساس مستندات این پروژه، این روش مدل را مجبور می‌کند تا هر ادعا را در همان چرخهٔ نوشتارش تأیید کند تا از رشد گورستان تعهدات جلوگیری شود.
گام بعدی شما
- اگر از عامل‌های هوشمند برای اتوماسیون تجاری استفاده می‌کنید، مکانیزم بازبینی (Verification) آن‌ها را به جای اعتماد مطلق، به چالش بکشید.
- در طراحی پرامپت‌ها، مدل را مجبور کنید تا برای هر ادعای کلیدی، یک «شرط ردکننده» فوری تعریف و اجرا کند.
- منتظر ظهور مدل‌های استدلالی جدید باشید که مدیریت حافظهٔ کوتاه‌مدت را با معیارهای سخت‌گیرانه‌تر جایگزین می‌کنند.
اما تأثیر این نقص بر هزینه‌های استنتاج در مقیاس صنعتی حتی پیچیده‌تر است؛ به تحلیل ما درباره بهینه‌سازی GPUها مراجعه کنید.
گفتگو