أسطول السَيدكار والـ RLM: جمع الأدلة قبل الإجابة

هناك نمط فشل في أنظمة الاسترجاع المعزَّز لا يضعه أحد في العرض التوضيحي. تطرح سؤالًا، فيُضمِّن النظام السؤال، ويسحب أفضل عشرة مقاطع، ويحشرها في مُوجّه، ثم يكتب النموذج إجابة سلسة مبنية على أي عشرة مقاطع صادف أنها حصلت على أعلى درجة.

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

الحل ليس مُضمِّنًا أفضل. الحل هو السماح لشيء ما بأن ينظر مجددًا — وهذا بالضبط ما يفعله الـ RLM.

مكوّنان، منفصلان بوضوح

السَيدكار وكيل أسطول. يعمل حيث توجد قدرة الحوسبة، ويبلّغ عمّا لديه، ويخدم طلبات الاستدلال. ويسجّل خادم Fantom MCP نفسه كأحد الأسياد الذين يبلّغهم السَيدكار.

الـ RLM نموذج لغوي للاسترجاع — نموذج مخصَّص ليست مهمته كتابة النثر بل الجمع. يستدعي أدوات البحث في الكود بشكل تكراري حتى يحصل على الكود الدقيق اللازم للإجابة، ثم يعيد الأدلة التي جمعها مع مسودة موجزة. وتتولى خطوة تركيب منفصلة تحويل ذلك إلى الإجابة النهائية الموثّقة بالمصادر.

الفصل مهم. نموذج الجمع مُحسَّن لاستخدام الأدوات ويمكن أن يكون صغيرًا وسريعًا. ونموذج التركيب مُحسَّن للكتابة. أما مطالبة نموذج واحد بالقيام بالأمرين فهي الطريق إلى إجابة إمّا رديئة البحث أو رديئة الصياغة.

كيف يبلّغ الأسطول

السَيدكار هو من يبدأ الاتصال، لا الخادم — وهذا هو الاتجاه الصحيح حين تكون قدرة الحوسبة موجودة على محطات عمل تظهر وتختفي.

بروتوكول الاتصال صغير عن قصد. يفتح السَيدكار اتصال WebSocket ويرسل register مع عنوانه واسم مضيفه وحاوياته. بعد ذلك يرسل إطارات heartbeat تحمل الحاويات وأعداد الطلبات النشطة وكتلة حالة. ويرد السيد بـ registered، ويمكنه دفع إطارات command وconfig في الاتجاه المعاكس. وإذا لم يكن WebSocket متاحًا، يجري التبادل نفسه عبر نقاط نهاية HTTP للنبضة والاستقصاء والنتيجة.

لا يُصدر Fantom MCP حاليًا أوامر عمل عبر هذه القناة — فاستدعاءات الاستدلال الفعلية تمر عبر HTTP. أما ما يفعله بالفعل فهو التنقيب في كل نبضة بحثًا عن بيانات القدرات، بحيث تعرف طبقة التوجيه دائمًا أي الأدوار تُخدَم فعليًا في هذه اللحظة.

تفصيل واحد يستحق الذكر لأننا تعلّمناه بالطريقة الصعبة: يُعاد كتابة ذلك السجل عند كل نبضة، قراءة-تعديل-كتابة، في ملف إعداد يحتوي أيضًا على إعدادات البحث. وكانت نسخة سابقة تُرجع كائنًا فارغًا عند قراءة مبتورة، فكانت قراءة تالفة واحدة كافية لحفظ قائمة السَيدكار فقط ومحو كل ما عداها — بما في ذلك النسخة الاحتياطية. أما الآن فتتعافى القراءات من نسخة احتياطية شقيقة، والكتابات ذرّية. كود الأسطول يلمس ملف الإعداد أكثر بكثير مما يتوقع أي أحد.

حلقة الجمع

إليك ما يحدث فعليًا عند وصول سؤال.

يبني النموذج خطة، ويصدر استدعاءات الأدوات، وتُجمع النتائج بتزامن محدود. تُقسَّم كتل الأدلة وتُدمج وتُوزَّن ضمن ميزانية نافذة السياق — التي تُقرأ ديناميكيًا من نقطة نهاية الخدمة بدلًا من ترميزها بشكل ثابت، لأن الحلقة نفسها تعمل مع نماذج مختلفة ذات حدود مختلفة.

وإذا لم يكن ما عاد كافيًا، تُكرَّر المحاولة. هذا هو الفرق الكامل بين هذا النهج والاسترجاع بضربة واحدة: يُسمح للنظام بأن يلاحظ أن ما لديه غير كافٍ.

ثمة تحسين حديث يوضّح جيدًا أين تكمن التكلفة الحقيقية. فبدلًا من إعادة التضمين عند كل خطوة توسيع، يُضمَّن الاستعلام مرة واحدة ويتوسع البحث إلى المقاطع الشقيقة بالتوازي، مع تخطي مُعيد الترتيب في تمريرة التوسيع تلك. الجزء المكلف في "النظر مجددًا" لم يكن النظر قط — بل إعادة ترميز السؤال نفسه بشكل زائد عن الحاجة.

الفشل مسار من الدرجة الأولى

كل نقطة نهاية في هذه السلسلة تخص جهازًا قد يكون نائمًا أو في منتصف إعادة التشغيل أو مشغولًا. لذا فالقاعدة في مسار الـ RLM بأكمله صريحة وحاسمة: أي خطأ في نقطة نهاية يُرجع null ويتحول المستدعي إلى بديل احتياطي. ولا يرمي استثناءً أبدًا.

قد يبدو ذلك متواضع الطموح. لكنه عمليًا ما يجعل الميزة قابلة للاستخدام على أسطول حقيقي، حيث ينبغي أن يؤدي كون "مضيف الـ RLM غير متصل" إلى تدهور جودة الإجابة، لا إلى ظهور تتبّع مكدّس في محرر مهندس تحكّم. ووضع الاحتياط الافتراضي محلي بالكامل، وخطوة الجمع تحسين للاسترجاع لا اعتماد عليه.

طاقة بلا عتاد

القطعة الأخيرة تربط هذا كله بالسحابة. يمكن للسَيدكار توجيه دورٍ ما إلى OpenRouter بدلًا من نموذجه المحلي، ويتعامل Fantom MCP مع كل اقتران كهذا بوصفه حاوية افتراضية — مزوّدًا منطقيًا منفصلًا، يُسمّى وفق النمط <PCName>-OR-<Role>، يمثل طاقة خدمة حقيقية بلا GPU وبلا VRAM خلفه.

هكذا يتوزّع التضمين على وحدات GPU المحلية والسحابة في آن واحد، وهكذا تحصل إعادة الترتيب على واجهة خلفية من الأساس على أسطول تنشغل أجهزته بأعمال أخرى.

وثمة خاصيتان في هذا الترتيب تستحقان التصريح بهما بوضوح:

الاكتشاف يجري عبر HTTP لا عبر النبضة. تحمل النبضة لقطة مقلَّمة لا تتضمن بيانات الحاويات الافتراضية. والنظام الذي ينقّب عنها في النبضة لن يجد شيئًا بصمت، إلى الأبد، وسيبدو وكأنه يعمل.
مفتاح الـ API لا يلمس Fantom MCP أبدًا. السَيدكار هو من يحتفظ به. وFantom لا يذكر سوى اسم مزوّد واسم نموذج. لا شيء في مسار الاكتشاف يقرأ مفتاحًا أو يخزّنه أو يسجّله أو ينقله.

أما كيفية اختيار هؤلاء المزوّدين بعد ذلك وضبط بواباتهم وميزانياتهم فهي موضوع المنشور التالي.

خادم Fantom MCP متاح المصدر على github.com/Project-SandStar/FantomMcpServer.