ما وراء الـ RAG: هندسة محرك السياق (Context Engine) باستخدام خوادم MCP مخصصة

خلال الأشهر القليلة الماضية، كنت مهووساً بمشكلة واحدة: فجوة السياق (The Context Gap).

لقد رأينا جميعاً ذلك. أنت تعمل مع نموذج لغوي كبير (LLM) من الفئة الأولى — مثل Claude 3.5 Sonnet أو GPT-4o — وهو بارع في الاستنتاج، لكنه في الأساس "عقل في وعاء". لا يعرف شيئاً عن تذاكر Jira الخاصة بفريقي، أو مخططات الـ API الداخلية لدينا، أو تلك المشكلة الغريبة في قاعدة بياناتنا القديمة (Legacy database).

تقنية الـ RAG (Retrieval-Augmented Generation) التقليدية رائعة للوثائق الثابتة، ولكن بالنسبة لسير العمل المعتمد على الـ Agents والبيانات اللحظية، فهي بطيئة جداً ومنفصلة عن الواقع. لهذا السبب بدأت في بناء ما أسميه محرك السياق (The Context Engine) باستخدام بروتوكول سياق النموذج (Model Context Protocol - MCP).

لماذا يعد MCP القطعة المفقودة؟

عندما أطلقت Anthropic مواصفات الـ MCP، استوعبت الأمر فوراً. بدلاً من كتابة كود ربط (Glue code) مخصص لكل مشروع، يمنحنا MCP طريقة معيارية لعرض الأدوات والموارد للذكاء الاصطناعي.

فكر فيه كأنه تعريف (Driver) متخصص لبياناتك. يصبح الذكاء الاصطناعي هو نظام التشغيل (OS)، وخادم الـ MCP المخصص هو التعريف الذي يسمح لنظام التشغيل بالتحدث إلى الأجهزة (بياناتك والـ APIs الخاصة بك).

الهندسة المعمارية: كيف أقوم ببنائها

من خلال خبرتي، لا يعد خادم MCP الجاهز للإنتاج مجرد غلاف حول الـ API. يجب أن يكون قوياً، آمناً، والأهم من ذلك، منخفض التأخير (Low-latency).

أقوم عادةً ببناء خوادمي باستخدام TypeScript و Node.js، مع الاعتماد على @modelcontextprotocol/sdk. إليكم النموذج الذهني الذي أتبعه:

1. طبقة النقل (Transport Layer): عادةً Stdio لأدوات التطوير المحلية أو SSE (Server-Sent Events) لعمليات النشر عن بعد.
2. طبقة المخطط (Schema Layer): تحديد الأدوات التي يمكن للذكاء الاصطناعي "استدعاؤها" فعلياً.
3. طبقة التنفيذ (Execution Layer): حيث يحدث العمل الحقيقي (جلب البيانات من Postgres، الاستعلام من GitHub، إلخ).

لحظة الإدراك: تعريف الأدوات (Tool Definition)

إليك مقتطف من كيفية تعريفي لأداة لربط سجل الخدمات الداخلي لدينا. السر يكمن في الوصف (description) — أنت لا تكتب لمجمع كود (Compiler)؛ أنت تكتب لنموذج لغوي كبير (LLM).

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "get_service_logs",
      description: "Fetches real-time logs for a specific microservice. Use this when the user asks about system errors or deployment status.",
      inputSchema: {
        type: "object",
        properties: {
          serviceName: { type: "string" },
          lines: { type: "number", default: 50 },
          environment: { enum: ["prod", "staging", "dev"] }
        },
        required: ["serviceName"]
      }
    }
  ]
}));

دروس من أرض الواقع

1. "هندسة الأوامر" للمخططات (Schemas)

تعلمت بالطريقة الصعبة أنه إذا كان الـ inputSchema غامضاً، فسيقوم الـ LLM بتأليف (Hallucinate) مدخلات من عنده. بدأت في إضافة حقول description لكل خاصية. إنها ليست مجرد بيانات وصفية؛ بل هي تعليمات لمنطق استدعاء الأدوات في الذكاء الاصطناعي.

2. التعامل مع الحالة (State)

بروتوكول MCP عديم الحالة (Stateless) بطبيعته، لكن سير عملك ليس كذلك. وجدت نجاحاً في تمرير session_id عبر وسائط الأداة للحفاظ على السياق عبر محادثة متعددة الأطوار مع قاعدة البيانات.

3. الأمن لا يقبل المساومة

منح الـ LLM القدرة على تشغيل كود أو الاستعلام من قاعدة بيانات أمر مرعب. أطبق سياسة "القراءة فقط أولاً". تستخدم خوادم الـ MCP الخاصة بي مفاتيح API محدودة الصلاحيات لا يمكنها حرفياً القيام بأي إجراءات تدميرية. إذا احتاج الذكاء الاصطناعي لإجراء DELETE أطلب موافقة يدوية خارج النظام (Out-of-band).

الأثر: من باحث إلى فاعل

قبل بناء محرك السياق المخصص لدينا، كان المساعدون الأذكياء مجرد محركات بحث متطورة. الآن، أصبحوا مشاركين فاعلين.

عندما أسأل: "لماذا تفشل خدمة الدفع؟"، لا يكتفي الذكاء الاصطناعي بالتخمين. بل يقوم باستدعاء أداة get_service_logs في MCP، ويحدد خطأ 500 في حاوية (Pod) معينة، ثم يستدعي أداة github_get_recent_commits ويخبرني بالضبط أي طلب سحب (PR) تسبب في تعطل البناء.

هذه هي قوة سير العمل المدرك للسياق. لم نعد نتحدث فقط إلى النماذج؛ بل نحن ندير الأنظمة.

ماذا بعد؟

أقوم حالياً بالتجربة في التواصل بين خوادم MCP (MCP-to-MCP communication)، حيث يقوم "خادم رئيسي" بتوجيه الطلبات إلى خوادم فرعية متخصصة. إذا كنت تبني في هذا المجال، فتوقف عن التفكير في الأوامر (Prompts) وابدأ في التفكير في البروتوكولات.

مستقبل هندسة البرمجيات لا يقتصر فقط على كتابة الكود؛ بل في بناء الواجهات التي تسمح للذكاء الاصطناعي بفهم عالمنا.