قبلاً چی گفتیم؟
تا اینجای سری، MCP رو از صفر یاد گرفتیم. مفاهیم پایه، ساخت سرور، اتصال به Claude، امنیت، پروداکشن و اتصال به دیتابیس. حالا وقتشه یه قدم جلوتر بریم: ترکیب MCP با RAG.
RAG یا Retrieval-Augmented Generation یکی از مهمترین تکنیکهای دنیای AI هست. ایدهش سادهست: به جای اینکه مدل AI فقط به حافظه خودش تکیه کنه، اول اطلاعات مرتبط رو از یه منبع خارجی پیدا میکنه و بعد جواب میده.
حالا وقتی MCP و RAG رو ترکیب کنی، یه چیز فوقالعاده به دست میاد: AI که میتونه از طریق ابزارهای استاندارد MCP به vector database وصل بشه، جستجوی معنایی کنه و جوابهای دقیقتری بده.
RAG به زبان ساده
فرض کن از Claude میپرسی: «سیاست مرخصی شرکت ما چیه؟» Claude نمیدونه — چون این اطلاعات توی آموزشش نبوده. اینجاست که RAG وارد میشه.
با RAG، قبل از اینکه Claude جواب بده، سیستم یه جستجو توی مستندات شرکت انجام میده، بخشهای مرتبط رو پیدا میکنه و به Claude میده. حالا Claude با داشتن اون اطلاعات، یه جواب دقیق و مبتنی بر مستندات واقعی میده.
اجزای RAG
یه سیستم RAG سه بخش اصلی داره:
۱. Embedding (تعبیه): هر قطعه متن رو به یه بردار عددی (vector) تبدیل میکنه. این بردار «معنی» متن رو نشون میده. متنهایی که معنی مشابه دارن، بردارهای نزدیک به هم دارن.
۲. Vector Database: جایی که این بردارها ذخیره میشن و میتونی توشون جستجوی «مشابهت» کنی. وقتی یه سوال میپرسی، سوال هم به بردار تبدیل میشه و نزدیکترین بردارها (= مرتبطترین محتواها) برگردونده میشن.
۳. Generation: مدل AI بخشهای پیدا شده رو به عنوان context (زمینه) دریافت میکنه و بر اساس اونها جواب میده.
چرا MCP + RAG؟
شاید بپرسی: «خب، RAG بدون MCP هم کار میکنه. چرا ترکیبشون کنم؟» سوال خوبیه. جوابش اینه:
بدون MCP: RAG معمولاً hardcode شده توی اپلیکیشنه. توسعهدهنده باید مشخص کنه کِی جستجو بشه، توی کدوم منبع و چطور نتایج به prompt اضافه بشن. هر تغییری یعنی تغییر کد.
با MCP: جستجوی RAG یه ابزار میشه. AI خودش تصمیم میگیره کِی ازش استفاده کنه. میتونه چند بار جستجو کنه، نتایج رو ترکیب کنه و حتی سوالش رو اصلاح کنه اگه نتایج اول خوب نبودن.
مهمتر از همه: وقتی RAG یه ابزار MCP باشه، هر کلاینت MCP (Claude Desktop، Claude Code، هر اپ دیگهای) میتونه ازش استفاده کنه. دیگه لازم نیست برای هر اپ جداگانه RAG پیادهسازی کنی.
RAG + MCP: AI تصمیم میگیره → جستجو → تحلیل → شاید جستجوی دوباره → جواب نهایی (پویا و هوشمند)
معماری ترکیبی
بذار معماری رو مرحله به مرحله ببینیم.
مرحله ۱: آمادهسازی دادهها (Ingestion)
قبل از هر چیز، باید مستنداتت رو آماده کنی:
- تکهتکه کردن (Chunking): مستندات بلند رو به قطعات کوچکتر (مثلاً ۵۰۰ کلمهای) تقسیم کن. هر قطعه باید یه مفهوم کامل رو پوشش بده.
- تبدیل به بردار (Embedding): هر قطعه رو با یه مدل Embedding (مثل text-embedding-3-small از OpenAI یا مدلهای رایگان مثل all-MiniLM-L6-v2) به بردار تبدیل کن.
- ذخیره (Storage): بردارها رو توی یه Vector Database ذخیره کن.
این مرحله یهبار انجام میشه (و هر وقت مستندات آپدیت شدن، دوباره اجرا میشه).
مرحله ۲: MCP Server
حالا یه MCP Server میسازی که ابزار جستجو رو ارائه میده. کاربر (یا AI) یه سوال میپرسه، سرور اون رو به بردار تبدیل میکنه، توی vector database جستجو میکنه و نتایج مرتبط رو برمیگردونه.
مرحله ۳: هوش AI
AI نتایج جستجو رو میخونه و بر اساس اونها جواب میده. ولی نکته جالب اینه که AI میتونه:
- اگه نتایج کافی نبودن، دوباره جستجو کنه با query متفاوت
- از چند منبع جستجو کنه و نتایج رو ترکیب کنه
- فیلتر کنه: مثلاً فقط مستندات سال ۲۰۲۶ رو بخواد
- نتایج رو ارزیابی کنه و بگه «مطمئن نیستم» اگه مستندات مرتبطی پیدا نشد
ابزارهای MCP برای RAG
حالا بریم سراغ عمل. یه MCP Server برای RAG معمولاً این ابزارها رو داره:
ابزار search
اصلیترین ابزار. یه query متنی میگیره و مرتبطترین قطعات رو برمیگردونه.
// Tool: search
{
name: "search_documents",
description: "Search the knowledge base using semantic search",
inputSchema: {
type: "object",
properties: {
query: {
type: "string",
description: "Natural language search query"
},
top_k: {
type: "number",
description: "Number of results (default 5)",
default: 5
},
filter: {
type: "object",
description: "Optional metadata filters",
properties: {
category: { type: "string" },
date_after: { type: "string" }
}
}
},
required: ["query"]
}
}
ابزار list_collections
مثل list_tables توی قسمت قبلی. به AI میگه چه مجموعههایی (collections) توی vector database هست. مثلاً «مستندات فنی»، «سیاستهای شرکت»، «راهنمای محصول».
// Tool: list_collections
{
name: "list_collections",
description: "List available document collections",
handler: async () => {
return [
{ name: "technical_docs", description: "Technical documentation", doc_count: 1250 },
{ name: "company_policies", description: "HR and company policies", doc_count: 89 },
{ name: "product_guides", description: "Product user guides", doc_count: 340 }
];
}
}
ابزار get_document
وقتی AI یه قطعه مرتبط پیدا کرد، ممکنه بخواد کل سند اصلی رو ببینه (نه فقط اون قطعه). این ابزار یه سند کامل رو بر اساس ID برمیگردونه.
// Tool: get_document
{
name: "get_document",
description: "Get the full content of a document by ID",
inputSchema: {
type: "object",
properties: {
document_id: { type: "string" }
},
required: ["document_id"]
}
}
Vector Databaseها
برای ذخیره و جستجوی بردارها، چند گزینه محبوب داری:
Pinecone: سرویس ابری. سادهترین برای شروع. خودش hosting و scaling رو انجام میده. ولی پولیه و دادهت روی سرور شخص دیگهای هست.
Weaviate: open-source و self-hosted. هم Cloud داره هم لوکال اجرا میشه. امکانات خوبی برای فیلتر و metadata داره.
ChromaDB: سبک و ساده. برای پروتوتایپ و پروژههای کوچک عالیه. توی Python خیلی راحت کار میکنه.
Qdrant: سریع و بهینه. نوشته شده با Rust. هم Cloud داره هم self-hosted. API سادهای داره.
pgvector: اگه از PostgreSQL استفاده میکنی، pgvector یه extension هست که قابلیت vector search رو به همون دیتابیس اضافه میکنه. نیازی به سرویس جدا نیست.
مثال عملی: پایگاه دانش شرکت
بذار یه مثال واقعی بزنم. فرض کن شرکتت ۵۰۰ صفحه مستندات داخلی داره — از راهنمای محصول تا سیاستهای منابع انسانی. کارمندها هر روز سوالهایی مثل اینا دارن:
- «فرآیند درخواست مرخصی چطوریه؟»
- «محدودیتهای API ورژن ۳ چیه؟»
- «چطور باگ حیاتی گزارش بدم؟»
بدون RAG، یا باید خودشون بگردن (زمانبر) یا از همکارها بپرسن (وقت دو نفر گرفته میشه). با MCP + RAG:
کارمند توی Claude مینویسه: «فرآیند درخواست مرخصی چطوریه؟»
Claude ابزار search_documents رو با query «فرآیند درخواست مرخصی» صدا میزنه. Vector database مرتبطترین قطعات رو برمیگردونه. Claude جواب رو بر اساس مستندات واقعی شرکت میده — با ذکر منبع.
اگه جواب کافی نبود، Claude میتونه دوباره با query متفاوت جستجو کنه یا از get_document استفاده کنه تا سند کامل رو ببینه.
Chunking: هنر تکهتکه کردن
یکی از مهمترین بخشهای RAG که خیلیها دستکم میگیرن، chunking هست — نحوه تقسیم مستندات به قطعات.
خیلی بزرگ: اگه قطعات بزرگ باشن (مثلاً کل یه صفحه)، جستجو دقت کمتری داره چون بخشهای نامرتبط هم شامل میشن.
خیلی کوچک: اگه خیلی کوچک باشن (مثلاً یه جمله)، context از دست میره و AI نمیتونه مفهوم کامل رو بفهمه.
بهینه: معمولاً ۳۰۰-۵۰۰ کلمه با ۵۰-۱۰۰ کلمه overlap (همپوشانی) بین قطعات. overlap باعث میشه مطالبی که مرز دو قطعه رو رد میکنن، گم نشن.
استراتژیهای Chunking
Chunking ثابت (Fixed-size): هر ۵۰۰ کلمه یه قطعه. ساده ولی ممکنه وسط جمله ببره.
Chunking معنایی (Semantic): بر اساس ساختار سند تقسیم میکنه — مثلاً هر بخش (heading) یه قطعه. دقیقتره ولی پیچیدهتر.
Chunking بازگشتی (Recursive): اول سعی میکنه از heading ها تقسیم کنه. اگه قطعه هنوز بزرگه، از پاراگرافها. اگه بازم بزرگه، از جملات. بهترین روش عمومی.
بهبود کیفیت جستجو
یه سری تکنیک هست که کیفیت نتایج RAG رو بالاتر میبره:
Hybrid Search: ترکیب جستجوی معنایی (vector) با جستجوی کلمهای (keyword). بعضی وقتا کاربر دنبال یه عبارت دقیقه (مثل شماره مدل محصول) که جستجوی معنایی پیداش نمیکنه.
Reranking: بعد از جستجوی اولیه، نتایج رو با یه مدل دیگه (reranker) مرتب کن. Reranker دقیقتر از vector search ساده هست ولی کندتره — برای همین فقط روی ۲۰-۵۰ نتیجه اول اجرا میشه.
Query Expansion: سوال اصلی کاربر رو به چند سوال مختلف تبدیل کن و همه رو جستجو کن. مثلاً «مرخصی» رو به «مرخصی استحقاقی»، «تعطیلات»، «leave policy» هم گسترش بده.
Metadata Filtering: از metadata برای فیلتر دقیقتر استفاده کن. مثلاً فقط مستندات بخش HR یا فقط مستندات آپدیتشده در ۶ ماه اخیر.
MCP و Embedding به عنوان ابزار
یه نکته جالب: خود عملیات embedding هم میتونه یه ابزار MCP باشه. فرض کن AI میخواد یه متن جدید رو به vector database اضافه کنه (مثلاً وقتی یه مستند جدید ایجاد میشه).
// Tool: add_document
{
name: "add_document",
description: "Add a new document to the knowledge base",
inputSchema: {
type: "object",
properties: {
title: { type: "string" },
content: { type: "string" },
collection: { type: "string" },
metadata: { type: "object" }
},
required: ["title", "content", "collection"]
}
}
البته این ابزار باید با احتیاط ارائه بشه. اضافه کردن محتوای نادرست به knowledge base میتونه کیفیت کل سیستم رو خراب کنه. حتماً یه لایه تایید انسانی بذار.
چالشها و راهحلها
ترکیب MCP و RAG چالشهای خاص خودش رو داره:
چالش ۱: Hallucination. حتی با RAG، AI ممکنه «توهم» بزنه و چیزی بگه که توی مستندات نیست. راهحل: از AI بخواه حتماً منبع رو ذکر کنه. اگه منبعی پیدا نکرد، بگه «اطلاعاتی در این مورد پیدا نکردم.»
چالش ۲: قدیمی بودن مستندات. اگه مستندات آپدیت نشن، AI جوابهای قدیمی میده. راهحل: تاریخ آخرین آپدیت رو به metadata اضافه کن و AI رو تنظیم کن که هشدار بده اگه مستند قدیمیه.
چالش ۳: زبانهای مختلف. اگه مستندات به چند زبان هستن، مدل embedding باید multilingual باشه. مدلهایی مثل multilingual-e5-large برای این کار مناسبن.
چالش ۴: مقیاس. وقتی تعداد مستندات زیاد میشه (مثلاً ۱ میلیون قطعه)، جستجو کندتر میشه. Vector databaseهای بهینهشده مثل Qdrant این مشکل رو حل میکنن.
چالش ۵: هزینه Embedding. تبدیل هر قطعه به بردار هزینه داره (اگه از API استفاده میکنی). برای مستندات حجیم، از مدلهای لوکال مثل all-MiniLM-L6-v2 استفاده کن که رایگانه.
یه معماری پیشرفته: Multi-Source RAG
قدرت واقعی MCP + RAG وقتی مشخص میشه که چند منبع داشته باشی:
{
"mcpServers": {
"internal-docs": {
"command": "node",
"args": ["servers/rag-server.js", "--collection=internal"]
},
"product-docs": {
"command": "node",
"args": ["servers/rag-server.js", "--collection=product"]
},
"database": {
"command": "node",
"args": ["servers/db-server.js"]
}
}
}
حالا AI هم به مستندات داخلی دسترسی داره، هم به مستندات محصول و هم به دیتابیس. میتونه یه سوال رو از چند زاویه جواب بده:
«چرا مشتری شماره ۴۵۲ از محصول ناراضیه؟»
AI از دیتابیس تاریخچه سفارشات مشتری رو میخونه، از مستندات محصول محدودیتهای شناختهشده رو پیدا میکنه و از مستندات داخلی باگهای گزارششده مرتبط رو جستجو میکنه. نتیجه: یه تحلیل جامع که ساعتها تحقیق دستی رو به چند ثانیه تبدیل میکنه.
جمعبندی
ترکیب MCP و RAG یکی از هیجانانگیزترین کاربردهای AI هست. خلاصهش:
- RAG = جستجو + بازیابی + تولید — AI قبل از جواب دادن، اطلاعات پیدا میکنه
- MCP = رابط استاندارد — جستجو یه ابزار میشه که AI خودش تصمیم میگیره کِی ازش استفاده کنه
- Vector Database = حافظه معنایی — متنها بر اساس معنی جستجو میشن نه فقط کلمات
- Chunking خوب = کلید کیفیت — نحوه تقسیم مستندات خیلی مهمه
- Multi-source = قدرت واقعی — AI از چند منبع اطلاعات ترکیب میکنه
با MCP، RAG دیگه یه قابلیت hardcode شده نیست — یه ابزار پویا و قابل استفاده مجدده که هر کلاینت AI میتونه ازش بهره ببره.
نظرات
هنوز نظری ثبت نشده. اولین نفر باشید!
نظر خود را بنویسید