پشت‌صحنه توهمات هوش مصنوعی: وقتی طراحی اطلاعات جایگزین وزن‌های مدل می‌شود

اگر امروز در حال توسعه یک عامل هوش مصنوعی (AI Agent) هستید، بزرگ‌ترین ریسک شما هوش مدل نیست، بلکه محیط اطلاعاتی است که دور آن ساخته‌اید. ممکن است عامل شما را ده‌ها بار در محیط توسعه (Dev Environment) آزمایش کنید و آن را بی‌نقص بیابید، اما اولین کاربر واقعی ممکن است باعث تحریک یک پاسخ ساختگی، یک فراخوانی اشتباه ابزار، یا اقدامی شود که عامل هرگز نباید انجام می‌داد.

طبق راهنمای فنی منتشر شده در ۶ ژوئن ۲۰۲۶ در وب‌سایت dev.to، این شکست‌ها به‌ندرت به وزن‌های مدل مربوط می‌شوند و تقریباً همیشه ریشه در طراحی کانتکست (Context Design) دارند. غریزه بسیاری از توسعه‌دهندگان این است که برای حل مشکل، GPT-4 را با Claude تعویض کنند، Gemini را امتحان کنند یا تلاش کنند مدل را تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — کنند؛ اما علت اصلی معمولاً اطلاعاتی است که مدل در لحظه تصمیم‌گیری دریافت کرده است.

تصور کنید عامل شما کارمندی بسیار ماهر است که حافظه کوتاه‌مدت بسیار ضعیفی دارد. اگر به او یک دفترچه راهنمای ۵۰ صفحه‌ای بدهید اما فقط اجازه دهید نگاهی به دو صفحه آخر بیندازد، او برای اینکه شما را راضی کند، بقیه مطالب را حدس می‌زند. این هسته اصلی مشکل توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — در محیط عملیاتی است. این یک باگ یا نقص فنی نیست؛ بلکه مدل شکاف اطلاعاتی را با محتمل‌ترین گزینه آماری پر می‌کند چون داده درست در لحظه تصمیم‌گیری در دسترس نبوده است.

سه حالت شکست (The Three Failure Modes)

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زبانی اشاره کردیم، مدیریت ورودی‌ها کلید کنترل خروجی‌هاست. گزارش dev.to سه الگوی متمایز از توهم را شناسایی کرده است که هر کدام نیاز به اصلاح فنی متفاوتی دارند:

• ساختگی‌های واقعی (Factual Fabrication): عامل جملاتی می‌سازد که منطقی به نظر می‌رسند اما هیچ ریشه‌ای در کانتکست ارائه شده ندارند. مثال‌هایی از این مورد عبارتند از: یک عامل پشتیبانی مشتری که یک سیاست بازگشت کالا را از خودش ابداع می‌کند، یا یک عامل پژوهشی که به مقاله‌ای استناد می‌کند که اصلاً وجود ندارد.
• سوءاستفاده از ابزار (Tool Misuse): مدل تابعی را با پارامترهای غلط فراخوانی می‌کند، یا کلاً تابع اشتباهی را صدا می‌زند، و یا حتی فراخوانی تابعی را برای ابزاری تصور می‌کند که وجود ندارد. این اتفاق به‌ویژه زمانی رایج است که توصیفات ابزار مبهم باشند یا چندین ابزار اهداف هم‌پوشان داشته باشند.
• انحراف از دستورالعمل (Instruction Drift): با رشد گفتگو، دستورات اولیه که در موقعیت صفر (Position 0) پنجره متنی قرار داشتند، توسط نوبت‌های متوالی گفتگو رقیق و کمرنگ می‌شوند. در نوبت بیستم، مدل عملاً به عاملی تبدیل شده که با تنظیمات اولیه شما متفاوت است. این پنجره متنی (Context Window) همان میزان متنی است که مدل هم‌زمان در ذهن نگه می‌دارد، شبیه میز کاری که فقط برای تعداد محدودی ورق جا دارد.

علل ساختاری شکست

این خطاها از سه نقص ساختاری در نحوه مدیریت کانتکست ناشی می‌شوند.

اول، «پوسیدگی کانتکست» (Context Rot) است؛ جایی که نسبت سیگنال به نویز در پنجره متنی عامل با گذشت زمان کاهش می‌یابد. شما با یک پرامپت سیستمی دقیق و یک وظیفه شفاف شروع می‌کنید، اما با پیشرفت جلسه، ابزارها نتایج JSON طولانی برمی‌گردانند و کاربر نظرات پراکنده اضافه می‌کند. استدلال‌های میانی نیز انباشته می‌شوند. تا زمانی که عامل نیاز به یک تصمیم حیاتی داشته باشد، دستورات مرتبط ممکن است ۸۰۰۰ توکن عقب‌تر در یک کانتکست ۱۶۰۰۰ توکنی باشند. چون مدل‌ها دچار «سوگیری تازگی» (Recency Bias) هستند، بیشتر به توکن‌های اخیر توجه می‌کنند. دستوری که در اعماق یک کانتکست طولانی دفن شده است، با هر چیزی که بعد از آن آمده رقابت می‌کند؛ اگر دوباره لنگر نشود، عملاً ضعیف می‌شود.

دوم، ابهام در توصیف ابزارها (Tool Description Ambiguity) است. این مورد، دست‌کم گرفته‌شده‌ترین علت شکست عامل‌ها در محیط عملیاتی است. توصیفات ابزار بخشی از کانتکست هستند. مدل نام تابع، توصیف و طرح‌واره (Schema) پارامترها را می‌خواند تا یک قضاوت احتمالی کند. یک توصیف ابزار ۴۰ کلمه‌ای که در ۵ دقیقه در ساعت ۱۱ شب نوشته شده است، در سیستم عملیاتی شما بار شناختی زیادی را بر دوش می‌کشد. وقتی توصیفات مبهم باشند (مثلاً «کمکی برای عملیات داده‌ها»)، مدل شروع به درون‌یابی و حدس زدن می‌کند. وقتی توصیف پارامترها محدودیت‌ها را حذف می‌کند — مثلاً می‌گوید «شناسه کاربر را اینجا وارد کنید» بدون اینکه فرمت یا منبع آن را مشخص کند — مدل هر چه را که معقول به نظر برسد پر می‌کند.

سوم، «شکاف حافظه در نقاط تصمیم» (Memory Gap at Decision Points) است. بسیاری از شکست‌ها زمانی رخ می‌دهند که عامل به اطلاعاتی نیاز دارد که در ابتدای گفتگو وجود داشت اما دیگر به صورت بازیابی‌پذیر در دسترس نیست. برای مثال، کاربر ممکن است در پیام سوم به نوع حساب خود اشاره کند، اما عامل در پیام پانزدهم برای تصمیم‌گیری درباره اینکه کدام ابزار را فراخوانی کند، به آن جزئیات خاص نیاز داشته باشد. این موضوع با تولید تقویت‌شده با بازیابی (RAG) که دانش خارجی را می‌گیرد متفاوت است. شکاف حافظه مربوط به وضعیت کاری (Working State) خود عامل است. بدون یک مکانیسم حافظه صریح، عامل یا دوباره از کاربر می‌پرسد — که تجربه کاربری (UX) را خراب می‌کند — یا حدس می‌زند که این ریسک توهم را افزایش می‌دهد.

پنج تکنیک زمینه‌سازی در محیط عملیاتی (Production Grounding)

برای رفع این مشکلات، راهنمای مذکور پنج الگوی مهندسی خاص را پیشنهاد می‌کند تا اطمینان حاصل شود که مدل اطلاعات درست را در زمان درست دریافت می‌کند:

• تعریف فضای منفی صریح (Explicit Negative Space): فقط به عامل نگویید چه کند. عامل‌های با قابلیت اطمینان بالا، صریحاً توصیف می‌کنند که عامل «نباید» چه کاری انجام دهد، چه چیزهایی را نمی‌داند و وقتی به مرز عدم قطعیت می‌رسد چه بگوید. به جای تکیه بر استنباط، مستقیماً بیان کنید: «اگر اطلاعات صریحی درباره X در کانتکست ارائه شده ندارید، با [عبارت جایگزین خاص] پاسخ دهید.» این کار جایگزینی حدس‌های احتمالی با یک دستور قطعی است.
• تزریق با اولویت‌بندی (Priority-Weighted Injection): همه کانتکست‌ها اهمیت یکسانی ندارند. یک سلسله‌مراتب صریح تعریف کنید: دستورات وظیفه اصلی (بالاترین اولویت) > ورودی کاربر در نوبت فعلی > نتایج ابزار > تاریخچه گفتگو > دانش پس‌زمینه (پایین‌ترین اولویت). وقتی فشار کانتکست زیاد می‌شود، به جای استفاده از کوتاه کردن یکنواخت و ساده (Naive Truncation)، موارد را از پایین این سلسله‌مراتب حذف کنید.
• لنگر انداختن دستورات (Instruction Anchoring): یادآورهای کوتاه دو یا سه جمله‌ای از محدودیت‌های اصلی را دقیقاً قبل از هر فراخوانی ابزار یا مرحله تولید متن دوباره تزریق کنید. الگو باید اینگونه باشد: [یادآور وظیفه اصلی] + [وضعیت فعلی] + [درخواست تصمیم یا تولید خاص]. این یک مکانیسم فنی برای مقابله با سوگیری تازگی و پوسیدگی کانتکست است.
• اشیاء وضعیت ساختاریافته (Structured State Objects): از تکیه بر مدل برای استخراج حقایق از تاریخچه قبلی گفتگو فاصله بگیرید. یک شیء وضعیت (State Object) فشرده و صریح را نگه دارید و آن را به عنوان کانتکست ساختاریافته تزریق کنید. برای مثال: وضعیت فعلی: - کاربر: {{name}}، پلن: {{plan_type}} - وظیفه: {{active_task}} - محدودیت‌ها: {{active_constraints}} - آخرین حقیقت تأیید شده: {{last_confirmed_fact}}. این شیء بدون ابهام است و در برابر فشار پنجره کانتکست دوام می‌آورد.
• دروازه اطمینان (Confidence-Gating): برای اقدامات حساس مانند نوشتن، حذف یا فراخوانی APIهای خارجی، یک دروازه اطمینان اضافه کنید. قبل از اجرا، عامل باید یک استدلال کوتاه و یک سیگنال اطمینان «بله/خیر» تولید کند: «آیا اطلاعات کافی برای اجرای مطمئن این کار را دارم؟» مدل اغلب زمانی که مستقیماً از او پرسیده شود، عدم قطعیت خود را آشکار می‌کند و باعث می‌شود فراخوانی‌های غلط قبل از وقوع شناسایی شوند.

اثر ترکیبی چند-عاملی (The Multi-Agent Compound Effect)

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

برای جلوگیری از این اتفاق، هر انتقال (Handoff) بین عامل‌ها باید مانند یک طرح‌واره (Schema) سخت‌گیرانه باشد. این امر مستلزم انضباط شدید در کانتکست است: استفاده از فیلدهای صریح، علامت‌گذاری اطلاعات غایب به عنوان null (به جای حذف آن‌ها) و گنجاندن سیگنال‌های اطمینان صریح برای تمام حقایق مشکوک.

تحلیل تحریریه

این تغییر دیدگاه، تمرکز توسعه‌دهنده را از «مهندسی پرامپت» (Prompt Engineering) به «مهندسی کانتکست» (Context Engineering) منتقل می‌کند. اصل اساسی این است که مدل یک موتور استدلال همه‌منظوره است و کیفیت خروجی‌های آن توسط کیفیت ورودی‌هایی که در لحظه تصمیم‌گیری دریافت می‌کند، محدود می‌شود. توهمی که شبیه به نقص در قابلیت مدل به نظر می‌رسد، تقریباً همیشه یک نقص اطلاعاتی است.

این موضوع نشان می‌دهد که وسواس صنعت روی پنجره‌های کانتکست بزرگ‌تر (مثلاً ۱ میلیون توکن یا بیشتر) ممکن است در واقع یک عامل پرت باشد. اگر مدل‌ها همچنان از سوگیری تازگی و پوسیدگی کانتکست رنج ببرند، یک پنجره بزرگتر فقط فضای بیشتری برای نویز فراهم می‌کند تا سیگنال را غرق کند. مهندسی کانتکست، تمرین طراحی آگاهانه محیط اطلاعاتی است — شامل توصیفات ابزار، مدیریت وضعیت، استراتژی‌های فشرده‌سازی و زمان‌بندی تزریق اطلاعات.

برای متخصصان، این بدان معناست که اثرگذارترین دستاوردها از تعویض GPT-4 با Claude یا تنظیم دقیق مدل حاصل نخواهد شد. در عوض، پیروزی‌ها در لوله‌کشی (Plumbing) سیستم است. قابلیت اطمینان، ویژگی معماری سیستم است، نه وزن‌های مدل. اگر می‌خواهید از پرامپت‌های ساده فراتر بروید، با بازبینی توصیفات ابزارهای خود و پیاده‌سازی یک شیء وضعیت ساختاریافته برای ردیابی ویژگی‌های کاربر در طول نوبت‌های گفتگو شروع کنید.

گام بعدی شما

• توصیفات ابزارهای خود را بازبینی کنید و هرگونه عبارت مبهم را با محدودیت‌های دقیق جایگزین کنید.
• یک شیء وضعیت (State Object) برای ردیابی ویژگی‌های کاربر در طول گفتگو پیاده‌سازی کنید.
• برای عملیات حساس، لایه «دروازه اطمینان» را اضافه کنید تا مدل قبل از اجرا، تردید خود را اعلام کند.

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