HOSTKEY تكتب pipe لبوت الدعم: Gemma 4 تجيب خلال 5–7 ثوانٍ وQwen 3 خلال 30–40 ثانية

روت شركة الاستضافة HOSTKEY لماذا تعذّر بناء بوت الدعم الفني Remote Hands Request (RHR، أي طلبات الخدمة الفعلية للخوادم) بالإعدادات الجاهزة في OpenWebUI. استبدل الفريق هذه الإعدادات بـ pipe، وهو إضافة بلغة Python تعترض الطلب قبل إرساله إلى النموذج وتمرره عبر سلسلة ثابتة من الخطوات. وسبب اختيار Gemma 4 هو زمن الاستجابة: فمع تعطيل وضع التفكير تجيب خلال 5–7 ثوانٍ على بطاقتي A4000 بسعة 16 غيغابايت لكل منهما. أما Qwen 3 فيفكر على العتاد نفسه مدة 30–40 ثانية، بينما تتأخر Gemma 4 عنه في الجودة بفارق ضئيل جدًا. كاتب التحليل هو ألكسندر كازانتسيف، رئيس قسم التوثيق والمحتوى في HOSTKEY.

لماذا لم تكن إعدادات النموذج كافية

افترضت HOSTKEY في البداية أن نموذجًا مخصصًا مبنيًا على نموذج مفتوح، مع أدوات متصلة وقاعدة معرفة، سيكفي للبوت. وللتوضيح يأخذ الكاتب نموذج hostkeyrurhr المبني على gemma4:26b-a4b-it-qat. في إعداداته جرى تفعيل Function Calling بوضع Legacy، وضبط temperature على 0,2، وتعطيل التفكير في Ollama، وربط مجموعة المعرفة hostkey_ru الخاصة بوثائق العملاء. أما الأدوات فهي status_ru_mcp وdocs_url_ru: فحص عمل الموقع وInvapi ومراكز البيانات في روسيا، إضافة إلى طلب MCP لاستعلام تكوينات VPS والخوادم المخصصة وحركة الشبكة.

عند السؤال عن VPS رخيص في ألمانيا لم يلجأ النموذج إلى الأداة get_vps_list التي تعيد قائمة VPS مع الأسعار حسب الموقع. جاءت الإجابة معقولة الشكل، لكنها كانت إعادة صياغة لتعليمات من الوثائق، لا بيانات من النظام. وجعل وضع Native الصورة أسوأ: إذ توقف حتى RAG عن العمل. وعند الطلب عبر API، مثلًا عبر CURL، يصل tool_call مجرد بمحتوى content فارغ، ويتعين على العميل نفسه استدعاء الأداة وإعادة سؤال النموذج. ولا توجد ضمانات بأن الأداة ستُستدعى، وأن البيانات ستصل إلى الإجابة ولن تختلط بـ RAG، وأن الإجابة ستكون بالروسية.

في وضع Legacy تُدمج بيانات الأدوات في السياق العام، وغالبًا في system prompt. وتعمل هذه الطريقة مع أي نموذج، لكن النموذج قد يعقّد الاستدعاء أكثر من اللازم، أو ينتج JSON غير صالح، أو يتجاهل الأداة. أما في وضع Native فلا يُمرَّر إلى النموذج سوى قائمة الأدوات عبر معامل API خاص. يعمل Qwen3 جيدًا في الوضعين، بينما تتطلب Gemma 4 في Native معالجة خاصة حتى في نسخة it (Instruction-Tuned). ويتولى الـ pipe هذه المعالجة.

وأضيفت إلى ذلك مآخذ بنيوية:

• نموذج واحد بـ system prompt كبير واحد ودرجة temperature واحدة هو الذي يختار الإجراء وهو الذي يجيب.
• ترتيب الاستدعاءات غير خاضع للتحكم، مع أن المطلوب كان: بحث بالكلمات المفتاحية، ثم أدوات توافر الخادم وMCP Invapi، ثم إجابة مع RAG.
• لا يمكن تعطيل RAG أثناء استدعاء الأدوات، ولذلك تختلط البيانات.
• لا توجد معالجة لاحقة: فحص اللغة، وقص الذيول الخدمية، واستبعاد الردود الجاهزة الفارغة، وfallback.
• يرى المستخدم واجهة «معلّقة» بينما تجري عدة طلبات إلى LLM وMCP.

ما هو الـ pipe وكيف يعمل hostkeyru_rhr_pipe

الـ pipe هو صنف Python له الدالة pipe. يتلقى جسم الطلب ويعيد سلسلة نصية أو JSON أو تدفقًا، ويستطيع في داخله أن يتوجه إلى LLM أي عدد من المرات، ويستدعي أدوات MCP، ويغيّر الـ prompt، ويفعّل RAG أو يعطّله. وفي واجهة OpenWebUI يظهر الـ pipe كنموذج مستقل: يمكن منحه صلاحيات واستدعاؤه عبر API، وفي العملاء الخارجيين يكفي استبدال اسم النموذج المخصص باسم الـ pipe. تُنشأ الـ pipes في Admin Panel، قسم Function. أما Valves، وهي معاملات قابلة للضبط للـ pipe تُخزَّن في قاعدة البيانات وتظهر في لوحة الإدارة، فلا تستخدمها HOSTKEY إطلاقًا: فإعادة كتابة الـ prompts والقيم في الشيفرة أسهل.

يخدم الـ pipe المسمى hostkeyru_rhr_pipe الدعم الناطق بالروسية. يجري التوليد النهائي في النموذج المخصص hostkeyrurhr مع تفعيل RAG، بينما ينفذ الـ pipe كل التحضير قبل ذلك. يتلقى الـ pipe body (الرسائل والنموذج والأعلام وtool_ids وfeatures)، وtools (قاموس أدوات MCP المتاحة)، و__event_emitter__ وهي القناة التي تُرسل عبرها الحالات إلى الدردشة. وبدلًا من شريط ثابت لا يتحرك يرى المستخدم تسلسلًا من الرسائل: «أحلل الطلب»، «أستخرج الكلمات المفتاحية»، «أبحث في الوثائق»، «أستخدم أداة»، «أُكوّن الإجابة النهائية». ومن دون هذا التسلسل كثيرًا ما يغادر المستخدمون الدردشة قبل انتظار النتيجة.

يُستخرج نص الطلب من آخر رسالة للمستخدم بالشيفرة، دون شبكات عصبية، مع مراعاة الرسائل متعددة الوسائط، أي قائمة الكتل «نص + صورة».

المرحلة −1: تسلسل من ثلاث طبقات

لم يكن في الـ pipe السابق فحص «هل هذا طلب RHR؟»، ولذلك كان يصل رد واحد على «أصدروا لي فاتورة» و«ssh لا يعمل»، وكان الحمل على القسم الذي يخدم الخوادم يتزايد. وفي الـ pipe الجديد ظهر تسلسل لا تعمل فيه كل طبقة تالية إلا إذا لم تعطِ السابقة إجابة قاطعة.

الطبقة 1 هي keyword guard (_keyword_prefilter) بلغة Python الخالصة. تبحث عن مجموعتين من المؤشرات: RHR_KEYWORDS (ssh، перезагруз، raid، сеть، dns، не отвеч) وCLIENT_SOFTWARE_SIGNALS (код сайта، конфиг nginx، wordpress، laravel). إذا وُجدت مفاتيح RHR فقط، تكون النتيجة in_scope=True, edge, 0,9. وإذا وُجدت إشارات البرمجيات فقط، تكون in_scope=False, client_software, 0,9. وإذا وُجدت المجموعتان معًا أو لم توجد أي منهما، يُعاد None ويمضي الطلب إلى الطبقة التالية.

الطبقة 2 هي مصنِّف LLM (_classify_rhr_scope) على gemma4nothink، وهو نموذج أساسي مع تعطيل التفكير، عند temperature تساوي 0. وتتضمن الـ prompt لائحة RHR_REGULATION، وخمس قواعد حرجة، وثمانية أمثلة few-shot، وصيغة صارمة لرد JSON. وعند أي إخفاق يُعاد in_scope=True, unknown, 0,0، أي أن العميل لا يُستبعد.

الطبقة 3 هي recheck (_recheck_rhr_scope) وتحمي من الاستبعاد الخاطئ. لا تعمل إلا إذا أعاد التمرير الأول in_scope=False أو الفئة client_software أو unknown، ووقعت قيمة confidence ضمن المجال [0,7; 0,85]. أما فئات billing وclient_area وlegal وsales وabuse، وكذلك edge، فلا إعادة فحص لها.

أمثلة من جدول الكاتب: «ssh لا يعمل» يُحسم في الطبقة الأولى، و«أريد استرداد الأموال» يُحسم في الثانية بوصفه billing بقيمة 0,95 ويحصل على تحذير، أما «شيء غريب في الخادم» فيذهب إلى fail-open برد عادي.

المرحلة 0: البحث في الوثائق

يتوجه أول طلب قصير إلى gemma4nothink ويحوّل سؤال المستخدم إلى 2–3 كلمات مفتاحية للبحث في الوثائق.