«تلاقی لایه‌ها»؛ RAG و MCP به جای رقابت، پشته‌ای واحد می‌سازند

اگر امروز برای مدیریت دانش عامل‌های هوش مصنوعی خود فقط به گسترش پنجره متنی تکیه کرده‌اید، احتمالاً با پدیده‌ی «گم‌شدن در میانه» (Lost in the Middle) روبرو هستید. باید بدانید که هوشمندتر شدن یک عامل، در گروی افزودن ابزارهای بیشتر نیست، بلکه در گروی انضباط در دسترسی به زمینه (Context) است. وقتی پیش‌بینی مدل بر اساس زمینه درست در لحظه درست استوار باشد، نرخ موفقیت پاسخ‌ها به شدت افزایش می‌یابد.

به نقل از راهنمای فنی منتشر شده در ۵ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، بسیاری از توسعه‌دهندگان به اشتباه تولید بازیابی‌افزا (RAG)، پروتکل زمینهٔ مدل (MCP) و تنظیم دقیق (Fine-tuning) را گزینه‌های جایگزین یا رقیب می‌بینند. ادعای اصلی این راهنما این است که این‌ها فناوری‌های رقیب نیستند، بلکه لایه‌های متمایزی از یک سیستم (Harness) هستند که برای ارائه زمینه هدفمند در لحظه پرس‌وجو طراحی شده‌اند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، دقت مدل‌ها بیش از آنکه به اندازهٔ پارامترها وابسته باشد، به کیفیت داده‌های ورودی در لحظه استنتاج بستگی دارد.

در دنیای امروز، بسیاری از تیم‌ها در محیطی فعالیت می‌کنند که «گسترش پنجره متنی» را به عنوان درمان همه دردها می‌بینند. این منجر به این می‌شود که تیم‌ها کل مخازن کد (Monorepos) را در یک پنجره چت می‌ریزند. این رویکرد باعث می‌شود مدل حتی با وجود دسترسی به داده، منطق یا هندلر مورد نیاز را پیدا نکند و دچار اثر «گم‌شدن در میانه» شود. طبق این گزارش، پرسش از اینکه «RAG، تنظیم دقیق یا MCP؟» اساساً غلط است، زیرا هر کدام در لایه‌ای متفاوت عمل می‌کنند.

لایه دانش: RAG

تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — به عنوان پایگاه دانش عمل می‌کند. این مکانیزم برای بازیابی تکه‌های کوچک و مشخص از منابعی مانند Logseq، Notion، Confluence یا فایل‌های README تیمی طراحی شده است. RAG در واقع تابع «پایگاه دانش + جست‌وجو» را ایفا می‌کند. وقتی کاربر درباره یک سیاست خاص، یک قرارداد، یک دفترچه راهنمای عملیاتی (Runbook) یا محدودیت‌های تکرار یک وب‌هوک می‌پرسد، RAG متن مرتبط را می‌یابد و آن را به عنوان منبع ارائه می‌دهد.

نکته حیاتی این است که RAG برای حقایقی است که تغییر می‌کنند. اگر یک تیم سیاست تکرار درخواست (Retry Policy) را از ۳ به ۵ مورد تغییر دهد، شما سند را در پایگاه دانش به‌روز می‌کنید، نه مدل را. این راهنما تأکید می‌کند که RAG درباره «آموزش» مدل روی اسناد نیست، بلکه درباره ارائه تکه متن درست در لحظه درست است.

• کاربرد RAG: روشی برای دستیابی به حقایقی که بدون نیاز به آموزش مجدد به‌روز می‌شوند. این لایه به مدل اجازه می‌دهد به یک فایل خاص به عنوان منبع اشاره کند. RAG مسئول مدیریت ADRها (سندهای تصمیمات معماری)، Runbookها و کامنت‌های موجود در هندلرها است.
• محدودیت RAG: ابزاری برای وضعیت‌های لحظه‌ای (Real-time status) نیست. برای مثال، وضعیت فعلی GitHub Actions با هر Push تغییر می‌کند؛ ایندکس کردن این وضعیت باعث می‌شود مدل «با ادب دروغ بگوید» زیرا داده‌ها منقضی شده‌اند. RAG همان دستور gh pr view در لحظه جاری نیست. تلاش برای جست‌وجوی یک ADR از طریق API گیت‌هاب، یک خطای بنیادین در درک این لایه است.
• موازنه: شما دسترسی به حقایق به‌روز را به دست می‌آورید، اما هزینه نگهداری ایندکس‌ها بالا می‌رود. اگر یک یادداشت مربوط به ژانویه در ایندکس باقی بماند در حالی که سیاست جدید در ماه مارس توسط بخش حقوقی تغییر کرده است، مدل با یک «ارجاع زیبا» یک قانون مرده را نقل می‌کند.

لایه اتصال: MCP

اگر RAG را یک کتابخانه بدانیم، پروتکل زمینهٔ مدل (MCP) نقش کتابدار را ایفا می‌کند. MCP رابطی میان محیط توسعه (IDE) یا سیستم مدیریت (Harness) و سیستم بازیابی است. در این ساختار، سیستم از سرور MCP یک تکه متن (Snippet) درخواست می‌کند؛ بدون این رابط، توسعه‌دهنده مجبور است یادداشت‌ها را دستی کپی و در چت جای‌گذاری کند، اما با MCP، ابزار بازیابی به‌طور خودکار در چرخه گفتگو وارد می‌شود.

MCP همچنین می‌تواند ابزارهایی برای تغییر داده‌ها (Mutate data) ارائه دهد، مانند فعال کردن یک استقرار (Deployment)، ادغام یک PR یا انجام یک پرداخت. با این حال، این راهنما هشدار می‌دهد که عملیات خواندن (Read) و نوشتن (Write) باید کاملاً مجزا باشند. کانکتوری که به یک عامل اجازه دهد همزمان در دفترچه راهنما جست‌وجو کند و بدون نظارت انسانی (HITL) پرداختی را اجرا کند، یک ریسک امنیتی و عملیاتی بزرگ است. این تغییر در نحوه تعامل مدل با ابزارها، شباهت زیادی به رویکرد رابط‌های کاربری زاینده دارد که در آن کنترل صفحه از برنامه‌نویس به مدل منتقل می‌شود تا تجربه کاربری پویا‌تر شود.

• ارزش افزوده: MCP زمانی ضروری می‌شود که یک پایگاه RAG مشترک بخواهد در چندین IDE مختلف نمایش داده شود و نیاز نباشد برای هر محیط، کانکتور را از ابتدا اختراع کنیم.
• ریسک: هر ابزار اضافی که به یک کانکتور اضافه می‌شود، «سطح حمله» برای خطاهای دنیای واقعی را افزایش می‌دهد. سروری که فقط RAG انجام می‌دهد اما اجازه Force Push بدون حضور انسان را می‌دهد، در واقع یک حادثه در انتظار وقوع است. نشستی (Session) که برای مشورت با دفترچه راهنما استفاده می‌شود، نباید همان نشستی باشد که پرداخت را فعال می‌کند.
• تمایز: اگر شما یک میزبان (Host) و دو ابزار دارید، فراخوانی توابع بومی (Native function calling) کافی است. MCP پلی به مجموعه داده‌ها (Corpus) است، نه خودِ مجموعه داده. MCP، Logseq نیست؛ بلکه روشی است که IDE از طریق آن به Logseq می‌رسد. اگر سرور سبز (فعال) است اما تاریخچه گفتگو همچنان با ۱۰ دستور Read شروع می‌شود، یعنی شما فقط کانکتور را نصب کرده‌اید و RAG را به درستی لینک نکرده‌اید.

لایه رفتار: تنظیم دقیق

تنظیم دقیق (Fine-tuning) — از جمله روش‌های LoRA — اغلب به اشتباه برای آموزش حقایق جدید (مانند مشخصات OpenAPI) به مدل استفاده می‌شود. تحلیل dev.to این کار را یک خطای بنیادین می‌داند. حقایق متعلق به RAG هستند و رفتار متعلق به تنظیم دقیق. تنظیم دقیق درباره «شیوه» نوشتن — لحن، فرمت و الگوها — است، نه کاتالوگی از داده‌ها.

تنظیم دقیق باید تنها برای اصلاح لحن، فرمت یا برچسب‌ها، پس از آنکه RAG و MCP به درستی مستقر شدند، استفاده شود. برای مثال، اگر یک عامل با وجود داشتن کد صحیح در زمینه، باز هم در خروجی یک یافته امنیتی را در قالب یک اسکیمای JSON خاص ارائه نمی‌دهد، تنظیم دقیق می‌تواند آن الگو را تحمیل کند. اما اگر اصلاح مورد نیاز این است که «README را به‌روز کن»، تنظیم دقیق ابزار غلطی است.

• خطر حقایق مبتنی بر وزن: اگر مدل را روی یک مشخصه OpenAPI آموزش دهید و فردا یک Endpoint تغییر کند، مدل در وزن‌های خود به نسخه قدیمی گیر می‌کند. در اینجا مدل «توهم» نزده است؛ بلکه حقیقتی را به یاد می‌آورد که اکنون غلط شده است. برای مثال، مدل ممکن است POST /v1/subscriptions/cancel (مشخصه ژوئن) را پیشنهاد دهد در حالی که کد از ماه اوت به POST /v2/billing/cancel تغییر کرده است. ایندکس کردن سورس‌کد در مجموعه داده‌های آموزشی همین خطا است؛ شما در نهایت یک Readme.bak گران‌قیمت خواهید داشت که نمی‌توانید آن را grep کنید.
• ترتیب صحیح اجرا: ابتدا از یک پرامپت شفاف استفاده کنید $
  ightarrow$ سپس دو نمونه خوب (Few-shot) ارائه دهید $
  ightarrow$ سپس یک اسکیمای سخت‌گیرانه JSON پیاده کنید. تنها اگر فرمت خروجی پس از هزاران بررسی همچنان دچار «نشت» (Leak) بود، باید به تنظیم دقیق فکر کنید.
• موارد استفاده درست:
  1. طبقه‌بندی مسائل (باگ در برابر ویژگی) در جایی که برچسب‌ها به ندرت تغییر می‌کنند. در اینجا یک مدل کوچک‌تر ارزان‌تر از یک مدل بزرگ است که باید متون طولانی را بخواند.
  2. حفظ لحن خاص تیم در مقیاس بالا بدون استفاده از یک پرامپت سیستمی ۸۰۰۰ توکنی.
  3. تحمیل این قانون که هر «یافته» (Finding) باید حتماً شامل ارجاع به فایل:خط باشد، در حالی که فرضیات در یک فیلد JSON مجزا نگه داشته شوند.

بودجه زمینه و انتخاب مدل

پنجره‌های متنی بزرگ جایگزینی برای نقشه کد (Code Map) نیستند. ریختن کل مخزن در پنجره متنی اغلب باعث می‌شود مدل به جای کد واقعی ماه اوت، یک README از ماه ژانویه را نقل کند. یک ساختار درست از یک گراف یا پرس‌وجوی LSP برای یافتن فراخواننده (Caller) خاص استفاده کرده و سپس تنها ۱ یا ۲ فایل را می‌خواند.

به عنوان مثال، برای یافتن اینکه چه کسی applyTimeout را فراخوانی می‌کند، رویکرد «ریختن داده‌ها» ممکن است مدل را به README برساند که نوشته «۳۰ ثانیه، ۳ تلاش». اما رویکرد «نقشه» زنجیره را دنبال می‌کند: applyTimeout $
ightarrow$ PaymentHttpClient $
ightarrow$ WebhookController و مستقیماً به کد در src/http/client.ts می‌رسد که تایم‌اوت ۵ ثانیه را نشان می‌دهد. مدل احمق نیست؛ بلکه صرفاً تکه متنی را خوانده که جست‌وجو تحویل داده است و جست‌وجو به یک فایل مرده رفته بود. ایندکس‌های برداری (Vector indexes) با ۴۰,۰۰۰ تکه فقط چیزهایی را می‌یابند که «شبیه» پرس‌وجو هستند؛ اما یک نقشه به شما می‌گوید چه کسی واقعاً هندلر را فراخوانی می‌کند.

علاوه بر این، پیشنهاد می‌شود مدل‌ها بر اساس مهارت‌های خاص انتخاب شوند، نه اینکه از یک LLM برای همه کارها استفاده شود. درخواست «اصلاح احراز هویت» (Fix the auth) می‌تواند یک غلط تایپی ساده باشد (کدنویسی در چرخه)، یک نقص معماری پیچیده در ۶ ماژول (بازسازی چندفایلی)، یا یک حفره امنیتی در یک PR (بررسی امنیتی). هر کدام توانایی متفاوتی می‌طلبد:

• کدنویسی در چرخه (Ship): مدل Grok (توانایی بالای عامل‌محور و کارهای دانشی).
• معماری چندفایلی/ADRها: مدل Claude Opus (برای کدنویسی عامل‌محور پیچیده و بازسازی‌های طولانی).
• بررسی کد و امنیت: مدل Claude Fable (توانایی کلاس Mythos؛ سقف توانایی برای بررسی سورس‌کد). استفاده از یک مدل روزمره برای بررسی امنیتی، باعث ایجاد سوگیری به سمت Diff می‌شود؛ اما Fable سقف توانایی برای یافتن حفره‌ها در سورس است. مدل Mythos 5 همان وزن را دارد اما دسترسی به آن محدود است.

گردش‌کار تشخیص خطا

برای تشخیص اینکه کدام لایه شکست خورده است، توسعه‌دهندگان باید به اولین ابزاری که عامل در تاریخچه گفتگو استفاده می‌کند نگاه کنند. این یک «تشخیص در کد» است.

• اولین ابزار گران‌قیمت: اگر عامل با ۱۰ دستور Read شروع می‌کند تا «فقط مطمئن شود»، شما با کمبود نقشه کد یا RAG مواجه هستید. این نشانه فقدان یک لایه است.
• اولین ابزار ارزان: جست‌وجو در README یا یک بررسی سریع git run، اولین حرکت درست است. برای مثال، بررسی اینکه آیا خط لوله اصلی از طریق XML/JUnit در یک بردار پاس شده است، ارزان‌تر از خواندن کل مخزن است.
• خطای فرمت: اگر مدل با وجود داشتن فایل درست، «یافته‌ها» را با «حدسیات» مخلوط می‌کند، مشکل در لایه رفتار (پرامپت/اسکیما) است، نه کمبود حقایق. اگر فایل در زمینه (Context) هست اما JSON خراب است، شما به داده بیشتر نیاز ندارید، بلکه به اسکیمای بهتری نیاز دارید.

پیاده‌سازی و معماری

برای انتقال از تئوری به عمل، این راهنما یک مدل ذهنی خاص برای معماری عامل پیشنهاد می‌کند. هدف این است که «ماهی‌گیری» در وب عمومی متوقف شود و تصمیم‌گیری بر اساس زمینه داخلی تیم آغاز گردد. این به معنای پیاده‌سازی یک سلسله‌مراتب سخت‌گیرانه است: پایه (Logseq/Notion) $
ightarrow$ جست‌وجو (RAG) $
ightarrow$ فراخوانی IDE (MCP) $
ightarrow$ فرمت (تنظیم دقیق).

هنگام طراحی این ساختار، قوانین زیر اعمال می‌شود:

• حداقل دسترسی (Least Privilege): ابزارهای خواندن نباید ابزارهای نوشتن باشند. اقداماتی مانند git push، merge، migrate یا deploy باید حتماً نظارت انسانی (HITL) داشته باشند. هیچ شل (Shell) بدون محدودیتی نباید صرفاً برای اینکه یک دمو کار کند، ایجاد شود.
• سیاست حافظه: صرفاً ارائه remember() یا recall() به عنوان یک ابزار، به معنای داشتن یک «سیاست حافظه» نیست.
• آگاهی از ابزار: عامل باید بداند چه زمانی باید از طریق RAG در مستندات جست‌وجو کند و چه زمانی ابزارهای git یا CI را فراخوانی نماید.

این تغییر دیدگاه به این معناست که هدف دیگر هوشمندتر کردن مدل نیست، بلکه دقیق‌تر کردن سیستم مدیریت (Harness) است. وقتی اولین حرکت یک عامل بر اساس IDE مورد استفاده شما تغییر می‌کند، شما یک لایه نساخته‌اید، بلکه یک میان‌بر برای یک اپلیکیشن خاص ساخته‌اید. برای پیاده‌سازی این موضوع، توسعه‌دهندگان باید با ممیزی استفاده از اولین ابزار عامل خود شروع کنند. اگر عامل شما سعی می‌کند مسیر یک API را که هفتگی تغییر می‌کند «به یاد آورد»، آن مسیر را از وزن‌های مدل خارج کرده و به یک مشخصه ایندکس‌شده در RAG منتقل کنید.

جمع‌بندی نهایی دستاوردها

با پیروی از این رویکرد لایه‌ای، تیم‌ها مدل هوشمندتری به دست نمی‌آورند، بلکه سیستمی می‌سازند که دیگر حدس نمی‌زند. پایگاه دانش وارد چرخه می‌شود، کانکتور تکه متن دقیق را بازیابی می‌کند و پنجره متنی دیگر یک «زباله‌دان» برای ریختن داده‌ها نیست.

در یک محیط حرفه‌ای، این بدان معناست که مدل دیگر پاسخ‌ها را بر اساس داده‌های آموزشی عمومی تکمیل نمی‌کند و بر اساس زمینه خاص تیم تصمیم می‌گیرد. توکن‌ها ذخیره می‌شوند زیرا جایگزین آن‌ها دیگر ریختن کل Monorepo یا ۱۰ دستور Read اکتشافی نیست. پایگاه دانش بدون نیاز به آموزش مجدد به‌روز می‌شود و هر پاسخ می‌تواند به یک فایل خاص اشاره کند. چه از Kiro، Cursor، Claude Code یا Codex استفاده کنید، منطق یکسان است: پایگاه دانش، کانکتور، رفتار و پنجره متنی. اگر این تشخیص را نادیده بگیرید، با ریسک ارجاعات منقضی‌شده، Force-pushهای تصادفی و مدلی روبرو هستید که نسخه‌ای از API شما را از ۶ ماه پیش به یاد دارد.

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