تصور کنید یک عامل هوش مصنوعی تایر ماشین مسابقه‌ای را با تایر دوچرخه اشتباه بگیرد، صرفاً چون هر دو «تایر» هستند. این نتیجهٔ اجتناب‌ناپذیر «انحراف مدل» (Model Drift) است، زمانی که یک سیستم سخت‌گیرانه برای فیلتر کردن آنچه عامل می‌بیند و به خاطر می‌سپارد وجود نداشته باشد. در نهایت، یک عامل هوش مصنوعی با کارایی بالا، تنها به اندازهٔ مرزهایی که دور دانش آن کشیده شده، قابل اعتماد است.
این چالش، نقطهٔ مرکزی درگیری فعلی در استقرار هوش مصنوعی در سازمان‌هاست. در حالی که بسیاری از تیم‌ها روی خودِ مدل تمرکز می‌کنند، گلوگاه واقعی محیط اطراف مدل است. متخصصان Stack Overflow، از جمله داگ ویتلی و اش زاده، با جزئیات توضیح می‌دهند که چرا «معماری زمینه» (Context Architecture) همان حلقهٔ گمشده‌ای است که یک چت‌بات دمدمی‌مزاج را به یک عامل آماده برای محیط تولید (Production-ready) تبدیل می‌کند.
برای درک این موضوع، باید لایه‌های پشتهٔ هوش مصنوعی را تفکیک کنیم. داگ ویتلی توضیح می‌دهد که مرز بین این مفاهیم اغلب کمرنگ است، اما هر کدام کارکرد متفاوتی دارند:
- زیرساخت زمینه (Context Infrastructure): این لایه به «چگونگی» تحویل داده می‌پردازد. این بخش شامل نحوهٔ ذخیره، بازیابی و ارائه بستر به عامل است. نمونه‌های آن شامل کتابخانه‌های زمینه و زیرساخت‌های مخصوص تولید بازیابی‌افزا (RAG) — مانند ایندکس‌گذاری یا تنظیمات پرس‌وجوی با کارایی بالا است. در واقع، این لایه مکانیسم تحویل و سازماندهی داده‌هایی است که عامل برای حل یک مسئله به آن‌ها نیاز دارد.
- مهندسی زمینه (Context Engineering): اینجا جایی است که «تئوری به عمل تبدیل می‌شود». این لایه شامل فرآیند ساخت واقعی است و انتخاب الگوریتم‌های خاص یا زبان‌های برنامه‌نویسی — مانند .NET، پایتون یا Rust — برای پیاده‌سازی یک قابلیت را بر عهده دارد. مهندسی در واقع عمل ساخت سیستم بر اساس طراحی است. این لایه در واقع گلوگاه اصلی در مسیر تبدیل ابزارهای هوش مصنوعی به عامل‌های خودکار محسوب می‌شود زیرا پیوند میان تئوری و اجرا را مدیریت می‌کند.
- معماری زمینه (Context Architecture): این لایه به «چرایی» می‌پردازد. معماری، همان طراحی فلسفی و مجموعه‌ای از الگوهای استاندارد است که تعیین می‌کند سیستم چگونه به اهدافش برسد. این لایه تصمیم می‌گیرد که ما یک «ماشین» بسازیم یا یک «قایق» یا یک «دوچرخه». معماری می‌پرسد که چرا اجزا به روش‌های خاصی کنار هم قرار گرفته‌اند تا نتایج مشخصی حاصل شود.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دسترسی به داده‌ها کلید پایداری سیستم است. معماری موثر، ابهام را از تصمیم‌گیری عامل حذف می‌کند. طبق گفته‌های اش زاده، هدف حذف متغیرهایی است که منجر به نتایج غیرقابل‌پیش‌بینی می‌شوند. به‌جای اینکه با یک پرامپت به عامل بگوییم «مراقب باش»، معماری محدودیت‌های سختی برای داده‌هایی که عامل حتی می‌تواند به آن‌ها دسترسی داشته باشد، ایجاد می‌کند.
در این ساختار، سه رکن اصلی وجود دارد:
- حفاظ‌ها (Guardrails): این‌ها محدودیت‌هایی هستند که به عامل می‌گویند: «فقط به این داده‌های خاص نگاه کن و با توجه به آن داده‌ها، تنها این سه اقدام را انجام بده. اگر به بن‌بست خوردی، این دو کار را انجام بده». این کار مانع از آن می‌شود که عامل وقتی وظیفه‌اش به‌طور خاص درباره ماشین‌هاست، به سراغ داده‌های نامرتبط مثل تایر دوچرخه برود. با کنترل دسترسی، عامل نمی‌تواند دچار انحراف شود چون اطلاعات نامرتبط اصلاً در دسترس او نیست.
- حافظهٔ عامل (Agent Memory): این قابلیت اجازه می‌دهد عامل تاریخچهٔ جلسات را در طول زمان حفظ کند. چون کارهای پیچیده — مانند ساخت یک ماشین مسابقه‌ای — در یک روز تمام نمی‌شوند، عامل باید به خاطر بیاورد که چه چیزهایی را قبلاً بررسی کرده است (مثلاً تایر ون در مقابل تایر کامیون) و چه اطلاعاتی را منتقل کرده است. این موضوع هنگام مقیاس‌دهی به ۱۰ یا ۱۰۰ عامل که به‌طور موازی کار می‌کنند حیاتی است، زیرا به سیستم اجازه می‌دهد روی کارهای قبلی بنا شود، نه اینکه هر بار از صفر شروع کند.
- انسان در حلقه (Human-in-the-Loop): وقتی عامل به بن‌بست می‌رسد، معماری باید یک مسیر شکست (Failure Path) مشخص تعیین کند، نه اینکه اجازه دهد هوش مصنوعی حدس بزند یا بر اساس داده‌های ناقص قضاوت کند. این امر تضمین می‌کند که عامل دقیقاً همان کاری را انجام دهد که از او انتظار می‌رود، حتی زمانی که با مشکل مواجه می‌شود.
Stack Internal این مدل را از طریق یک سیستم اعتماد پیاده کرده است. دانش به سه سطح «بالا»، «متوسط» یا «پایین» امتیاز می‌گیرد. اگر امتیاز متوسط یا پایین باشد، عامل اکیداً منع شده است که فرض کند اطلاعات درست است؛ در عوض، یک جریان «تأیید توسط متخصص موضوع» (Subject Matter Expert Validation Flow) فعال می‌شود و کاربر به‌طور خودکار به یک انسان ارجاع داده می‌شود تا داده‌ها را اعتبارسنجی کند یا جاهای خالی را پر کند.
بسیاری از شرکت‌ها داده‌های خود را در محیط‌های پراکنده‌ای مثل Slack، MS Teams، گوگل درایو، SharePoint, Confluence, GitHub و Jira ذخیره می‌کنند. اتصال سادهٔ یک عامل به این منابع، مشکل «نویز» شدیدی ایجاد می‌کند. حریم خصوصی و امنیت لایه پیچیده‌تری را اضافه می‌کنند. مثلاً عامل ممکن است در یک کانال Slack مربوط به «نوآوری»، حقیقتی درباره محصولی پیدا کند که هنوز ساخته نشده است و آن ایده‌های خام و طوفان فکری داخلی را به‌عنوان حقایق تثبیت‌شده گزارش دهد. این موضوع نشان می‌دهد چرا معماری حیاتی است: مسئله فقط این نیست که عامل «چه چیزی را می‌تواند» ببیند، بلکه این است که «چه چیزی را باید» در کار خود بگنجاند.
Stack Internal این آشوب را با دو لایه مدیریت می‌کند:
۱. مجوزهای منبع: عامل دقیقاً همان مجوزهای کاربر را به ارث می‌برد. اگر کاربر عضو یک کانال خصوصی در Slack نباشد، عامل هم نمی‌تواند به آن کانال دسترسی داشته باشد. مجوزهای دسترسی کاربر مستقیماً به سیستم منتقل می‌شود.
۲. محدوده‌ها (Scopes): کاربران می‌توانند دسترسی عامل را محدودتر کنند. حتی اگر مدیری به کل دایرکتوری شرکت دسترسی داشته باشد، می‌تواند یک «محدوده» — شبیه به یک دسته یادداشت چسبان روی میز — تعریف کند تا عامل فقط روی یک حوزه محصولی خاص تمرکز کند. این به کاربران اجازه می‌دهد زیرمجموعه‌ای از دانشی را که به آن دسترسی دارند، گلچین کنند.
این محدوده‌ها همچنین کنترل می‌کنند که عامل چگونه دانش را به سیستم بازگرداند. کاربر می‌تواند دستور دهد که عامل کارهایش را ثبت کند، اما اجازه ندهد این اطلاعات تا زمان بازبینی توسط انسان، با تیم یا مخزن دانش عمومی به اشتراک گذاشته شود. این امر تضمین می‌کند که زمینه‌های شخصی یا حساس ایجاد شده توسط عامل، خصوصی باقی بماند.
طراحی این سیستم شبیه به انداختن تور ماهیگیری است. یک معماری ضعیف، همه چیز (ماهی، صدف و زباله) را می‌گیرد. اما معماری خوب، ابتدا توری پهن می‌اندازد اما سپس چندین مرحله فیلترینگ را اعمال می‌کند: ابتدا صدف‌ها را حذف می‌کند، سپس برای گونه‌ای خاص از ماهی فیلتر می‌کند و در نهایت فقط ماهی‌هایی با اندازه مشخص را انتخاب می‌کند. در عمل، این فرآیند شامل مراحل فنی زیر است:
- ایندکس‌گذاری و برچسب‌گذاری: سازماندهی داده‌ها برای بازیابی سریع بر اساس پرس‌وجوی ورودی.
- جست‌وجوهای برداری: استفاده از الگوریتم‌ها برای یافتن داده‌های مرتبط بر اساس سؤال ورودی و جریان کاری فعلی.
- نگاشت زمینه: متصل کردن تکه‌های پراکنده اطلاعات، شبیه به تخته‌ای که با پین و نخ مفاهیم مرتبط را به هم وصل کرده است. برای تسهیل این فرآیند، ابزارهایی مانند ContextForge اتوماسیونِ بستر‌سازی برای رفع باگ‌های AI را ممکن کرده‌اند تا نیاز به تنظیمات دستی کاهش یابد.
- بازرتبه‌بندی (Re-ranking): تعیین اینکه کدام تکه‌های بازیابی‌شده برای آن عامل و کاربر خاص اولویت دارند تا مرتبط‌ترین داده‌ها در اولویت قرار گیرند.
- امتیازدهی اعتماد: استفاده از امتیازات بالا/متوسط/پایین برای تعیین اینکه آیا عامل می‌تواند به‌طور ایمن بر اساس آن اطلاعات عمل کند یا خیر.
بسیاری از شرکت‌ها سعی می‌کنند «تور» خودشان را بسازند چون کدنویسی فنی آن ساده به نظر می‌رسد. اما هزینه واقعی، فلسفی است. ساخت سیستم سفارشی یعنی حل «مشکل تضاد». وقتی دو سند معتبر اطلاعات متناقضی می‌دهند، سیستم باید روشی سیستماتیک برای شناسایی و حل این تضاد داشته باشد. این امر مستلزم گفتگوهای عمیق درباره نحوه رتبه‌بندی و انتخاب اطلاعات صحیح است، زمانی که داده‌ها در پلتفرم‌های مختلفی مثل Jira و GitHub پراکنده شده‌اند.
علاوه بر این، معماری درست، هزینه توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — و زمان را بهینه می‌کند. اگر یک عامل مجبور باشد کل یک کتابخانه را جست‌وجو کند، مقدار عظیمی توکن و زمان مصرف می‌شود. با محدود کردن زمینه از یک کتابخانه به یک کتاب خاص، سپس به یک صفحه و در نهایت به یک پاراگراف درباره فشار باد تایر ماشین مسابقه‌ای، سیستم صورت‌حساب عملیاتی و مصرف منابع را به‌شدت کاهش می‌دهد.
در نهایت، هدف معماری زمینه، «ثبات» است. اگر سه کاربر مختلف یک سؤال را بپرسند، باید پاسخی پیش‌بینی‌پذیر دریافت کنند. این ثبات است که به توسعه‌دهندگان اعتماد می‌دهد تا عامل را بدون نظارت مداوم روی یک وظیفه رها کنند.
اعتماد، جزء مرکزی این پیش‌بینی‌پذیری است. پژوهش‌های Stack Overflow نشان می‌دهد متخصصان زمانی به هوش مصنوعی اعتماد می‌کنند که خروجی با انتظارات درونی آن‌ها بر اساس تجربه مطابقت داشته باشد. برای مثال، کاربری که برای بیستمین بار یک گزارش مشتری تهیه می‌کند، دقیقاً می‌داند خروجی باید چگونه باشد. اما برای کسانی که تجربه ندارند — مانند کسانی که به سبک Vibe Coding (کدنویسی بر اساس حس و حال، بدون تسلط کامل بر ساختار) کار می‌کنند — معماری باید مکانیسم اعتماد را فراهم کند چون کاربر نمی‌تواند خروجی را خودش اعتبارسنجی کند.
این الگوهای معماری مستقل از مدل (Model-agnostic) هستند. چه از پروتکل زمینهٔ مدل (MCP) استفاده کنید و چه از مدل‌های پیشرو جدید، ارزش اصلی در زمینهٔ پاک و سازمان‌یافته‌ای است که به سیستم داده می‌شود. داگ ویتلی اشاره می‌کند که ما در زندگی روزمره هم معماری زمینه را اجرا می‌کنیم؛ مثلاً فقط وسایل ضروری را روی میز می‌گذاریم تا تمرکز کنیم. معماری زمینه در AI، همین رفتار طبیعی را به یک ابزار تبدیل می‌کند.
خودِ MCP یک تصمیم معماری است — یک پروتکل تعریف شده با الزامات مشخص. اما پیاده‌سازی آن — مثلاً اینکه از چه زبانی استفاده شود یا چه ویژگی‌های سروری پشتیبانی شود — یک تصمیم مهندسی است. به همین ترتیب، RAG ترکیبی از هر سه است: زیرساخت (ایندکس‌ها و ذخیره‌سازهای زمینه)، مهندسی (ساخت با پایتون یا Rust) و معماری (الگوهای طراحی دنبال شده).
برای کسانی که سیستم‌های داخلی می‌سازند، خطر «معماری تونلی» وجود دارد؛ یعنی سیستمی چنان خاص برای یک مورد باشد که نتواند با موارد دیگر سازگار شود. سیستمی با دید تونلی ممکن است پیشنهاد دهد تایر ماشین را روی یک چرخ‌دستی بیندازید، صرفاً چون فقط تایر ماشین را می‌شناسد. موفق‌ترین سیستم‌ها آن‌هایی هستند که انعطاف‌پذیری لازم برای پرس‌وجوهای متنوع را دارند، اما در عین حال برای جلوگیری از انحراف، سخت‌گیرانه عمل می‌کنند. با خرید یک معماری اثبات‌شده، شرکت‌ها از دانش تعمیم‌یافته و حل حدود ۲۰ دسته از مشکلات رایج روزمره در زمینه زمینه (Context) بهره‌مند می‌شوند که قبلاً برای مشتریان دیگر حل شده است.
گام بعدی شما
- اگر در حال استقرار عامل‌های AI هستید، به‌جای بهبود پرامپت، روی تعریف «محدوده‌های دسترسی» (Scopes) برای داده‌ها تمرکز کنید.
- برای هر منبع داده‌ای، یک سیستم امتیازدهی اعتماد (بالا/متوسط/پایین) تعریف کنید تا نقاط حساس را به تایید انسانی ارجاع دهید.
- بررسی کنید که آیا عامل شما در مواجهه با داده‌های متناقض، استراتژی حل تضاد دارد یا صرفاً یکی را به‌صورت تصادفی انتخاب می‌کند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو