// tier: helix-primary · order 3
HelixAgent betalicense: MIT
Source
المحتوى لا تختر نموذجًا واحدًا — دعهم يتناقشون، وقدّم الإجابة التي يتفقون عليها.
HelixAgent هو خدمة LLM تجميعية جاهزة للإنتاج، مدعومة بنظام AI في Go، تجمع بين استجابات عدة نماذج لغوية — بما في ذلك نظام مناظرات AI متعدد الجولات واختيار مقدمي الخدمة ديناميكيًا بناءً على التحقق — لإنتاج المخرجات الأكثر دقة وموثوقية.
HelixAgent هي خدمة LLM تجميعية قائمة على Go تجمع بين عدة مقدمي خدمة في إجابة واحدة دقيقة. تعمل بنظام مناظرات AI متعددة الجولات، وتقيّم مقدمي الخدمة ديناميكيًا عبر LLMsVerifier، وتوجّه الطلبات باستراتيجيات موزونة بالثقة، وتوفر ميزات إنتاجية: التخزين المؤقت، والمراقبة، وضوابط الأمان، وواجهات برمجة تطبيقات على نمط OpenAI.
HelixAgent هي خدمة LLM تجميعية جاهزة للإنتاج، مدعومة بنظام AI (ترخيص MIT)، تعامل إجابة النموذج الواحد كفرضية، لا حكمًا نهائيًا. بدلًا من المراهنة على مقدم خدمة واحد قد يكون مخطئًا أو متحيزًا أو غير متاح مؤقتًا، تجمع الخدمة بين استجابات عدة نماذج لغوية لتتقارب نحو المخرجات الأكثر دقة وموثوقية — وعندما يكون السؤال معقدًا بما يكفي، تخضع النماذج لمناظرة منظمة متعددة الجولات. تضم القائمة مجموعة واسعة: يوثّق ملف README العديد من مقدمي خدمة LLM ضمن internal/llm/providers/، بما في ذلك Claude، وDeepSeek، وGemini، وMistral، وQwen، وxAI/Grok.
الأهم من ذلك أن اختيار مقدم الخدمة ليس قائمة تفضيلات ثابتة، بل يُكتسب في الوقت الفعلي. تقود درجات التحقق المباشرة من نظام LLMsVerifier المدمج توجيه الطلبات والعودة التدريجية إلى أفضل مقدم أداء، مع تقارير الأخطاء المصنفة عند تدهور أداء أحدهم. يحول منظم مناظرات AI الخلاف إلى إشارة: يدعم عدة بنيات (شبكة، نجمية، سلسلة) وبروتوكول مراحل منضبط — الاقتراح → النقد → المراجعة → التركيب — مع تعلم مشترك بين المناظرات لتحسين قدرة النظام على التوفيق بين النماذج بمرور الوقت. تشمل استراتيجيات التوجيه الاختيار الموزون بالثقة، وإجماع الأغلبية، والكشف عن القصد الدلالي، كلها مع بث مباشر للاستجابات بحيث تصل الإجابات رمزًا برمجيًا تلو الآخر بدلًا من انتظار استقرار المجموعة بأكملها.
صُممت الخدمة لتعمل في بيئات الإنتاج، لا لمجرد العرض التوضيحي: يشكل PostgreSQL وRedis طبقة بيانات عالية التوافر، بينما يوفر Prometheus وGrafana وOpenTelemetry المقاييس ولوحات التحكم والتتبع، وتحيط JWT المصادقة، وتحديد المعدل، ومحركات الضوابط، وكشف PII بالتجميع لضمان التحكم الذي تتطلبه النشر الفعلي. تنظم الخدمة في نحو عشرين وحدة مستقلة (EventBus، والمراقبة، والمصادقة، والتخزين، وقواعد البيانات المتجهية، والتضمينات، وRAG، والذاكرة، وMCP، وغيرها)، كل منها مسؤولية منفصلة، وتوفر إطار عمل تحسين LLM (التخزين المؤقت الدلالي، والمخرجات المنظمة، والبث المحسن) مع تكاملات لـ SGLang، وLlamaIndex، وLangChain، وGuidance، وLMQL. ولأن نقاط نهاية الإكمال والتجميع متوافقة مع OpenAI، يمكن للعميل الحالي توجيه طلباته إلى HelixAgent للحصول على استدلال تجميعي دون الحاجة لإعادة كتابة الكود.
المحتوى
قد تخطئ أي LLM واحدة، أو تكون متحيزة، أو غير متاحة. تم بناء HelixAgent لتمكين التطبيقات من استشارة عدة نماذج في آن واحد، وتقييم إجاباتها بناءً على موثوقيتها المقاسة، والعودة إلى بدائل بشكل سلس—مما يحول الاعتماد الهش على مزود واحد إلى مجموعة مرنة ذات تقييم ذاتي.
تعمل على إضفاء الطابع العملي على توافق النماذج المتعددة—نقل عملية "اسأل عدة نماذج وصالح بينها" من نصوص برمجية مؤقتة إلى خدمة إنتاجية. فبدلاً من ترميز مزود واحد والتمني للأفضل، تحصل الفرق على توجيه ديناميكي مدفوع بنتائج التحقق الفوري، وبروتوكول منظم للنقاش في الأسئلة التي لا تكفيها محاولة واحدة، ومرونة إنتاجية عالية (طبقة بيانات عالية التوفر، ومراقبة كاملة، وضوابط أمان)—كل ذلك خلف واجهة متوافقة مع OpenAI وAPI. الميزة الحقيقية هي التبني دون تعطيل: يتحول الاعتماد الهش على مزود واحد إلى مجموعة مرنة ذات تقييم ذاتي، ويمكن للعملاء الحاليين التبديل إليها بتغيير نقطة النهاية بدلاً من تعديل الكود.
- نقاش منظم متعدد الجولات لـ AI يعامل الخلاف بين النماذج كمورد: طوبولوجيات قابلة للاختيار (شبكة/نجمة/سلسلة)، وبروتوكول منضبط للمراحل (اقتراح → نقد → مراجعة → تركيب)، وتعلم عبر النقاشات يتراكم مع الوقت.
- اختيار ديناميكي للمزودين بناءً على درجات LLMsVerifier الحية بدلاً من قائمة تفضيلات ثابتة—فالمجموعة توجه الطلبات إلى من يؤدي بشكل أفضل في الوقت الحالي، وتعود إلى بدائل بشكل سلس عند تراجع الأداء.
- إطار عمل أصلي لتحسين Go وLLM (ذاكرة تخزين دلالية، إخراج منظم، بث محسّن) قائم بذاته، مع إمكانية إضافة محسنات خارجية اختيارية (SGLang، LlamaIndex، LangChain، Guidance، LMQL) عند الحاجة بدلاً من اشتراطها.
- بنية معيارية مكونة من نحو عشرين وحدة منفصلة تحافظ على فصل الاهتمامات وتفتح الباب أمام ميزات البيانات الضخمة مثل الذاكرة الموزعة وبث الرسوم البيانية المعرفية.
- اختيار بين مزودين غير متساوين. يختلف المزودون في الجودة ويتغير أداؤهم مع الوقت، لذا فإن أي ترتيب ثابت يصبح غير صالح بحلول الغد. حللنا هذه المشكلة بجعل الاختيار خاضعاً للقياس المستمر: فدرجات LLMsVerifier تغذي توجيه الطلبات بناءً على ثقة مرجحة وتصويت الأغلبية، مع عودة سلسة إلى البدائل بحيث يتم تجنب المزود المتدهور بدلاً من الوثوق به.
- الحصول على إجابة موثوقة للأسئلة الصعبة حقاً. النموذج الواحد، عند سؤاله مرة واحدة، لا يملك آلية لاكتشاف خطأه. يوفر منظم النقاش حلاً لذلك—من خلال نقاش متعدد الطوبولوجيات ومراحل متسلسلة (اقتراح → نقد → مراجعة → تركيب) يجبر النماذج على تحدي بعضها وتحسين الإجابات قبل تركيب الإجابة النهائية.
- تشغيل مجموعة في الإنتاج، وليس فقط في دفتر الملاحظات. توزيع الطلبات على عدة مزودين يضاعف فرص الفشل. احتويناه بطبقة بيانات عالية التوفر PostgreSQL+Redis، ومراقبة Prometheus/Grafana/OpenTelemetry لكشف أي خلل في المزود أو المسار، وحاجز أمني يشمل مصادقة JWT، وتحديد معدلات الطلبات، ومحرك ضوابط، وكشف PII.
المحتوى
- Go — اختيرت لأن إرسال طلب واحد إلى عدة مقدمي خدمات بشكل متزامن هو بالضبط ما صُممت من أجله الـغوروتينات، كما أن النشر في ملف ثنائي واحد يبقي الخدمة المكونة من نحو 20 وحدة بسيطة في النشر؛ وهي تشكل الأساس الذي تعتمد عليه الخدمة بأكملها وكل وحدة داخلية فيها.
- Gin (ويب API) — اختيرت لتوفير واجهة HTTP سريعة ومنخفضة العبء؛ فهي تقدم نقاط النهاية المتوافقة مع OpenAI للإكمال
/v1والدردشة والبث والتجميع، مما يسمح للعملاء الحاليين باعتماد التجميع دون تغيير. - PostgreSQL — اختيرت لتكون المخزن الدائم للجلسات والتحليلات وسجلات المناقشات، بحيث تكون قرارات التوافق وسجل المناقشات قابلة للتدقيق؛ وهي تشكل ركيزة طبقة البيانات عالية التوفر.
- Redis — اختيرت للتخزين المؤقت منخفض الكمون وإدارة قوائم المهام؛ فهي تدعم التخزين المؤقت للاستجابات وطبقة التخزين الدلالي التي تسمح بتجاوز الاستدلال المتكرر أو شبه المتكرر عند تكرار الطلبات أو تشابهها.
- LLMsVerifier (المدمجة) — اختيرت لتحويل موثوقية مقدمي الخدمات إلى كمية قابلة للقياس بدلاً من افتراضها؛ حيث تصنف درجاتها مقدمي الخدمات للتوجيه وتدير التراجع عند تدهور أداء أحدهم.
- Prometheus + Grafana + OpenTelemetry — اختيرت لضمان قابلية مراقبة التجميع الذي يشمل العديد من مقدمي الخدمات؛ فهي تعرض مقاييس
helixagent_*ولوحات التحكم وتتبع الطلبات من البداية إلى النهاية عبر التوزيع المتزامن. - محولات Model Context Protocol (MCP) — اختيرت لتمكين قابلية التوسع عبر بروتوكول مفتوح؛ حيث يسرد ملف README العديد من محولات MCP لربط الأدوات الخارجية والسياقات.
- Neo4j / ClickHouse / Kafka (البيانات الضخمة) — اختيرت للتجاوز حدود العقدة الواحدة: حيث يدعم Neo4j وClickHouse الذاكرة الموزعة وميزات الرسم البياني للمعرفة، بينما يقوم Kafka ببث تلك البيانات البيانية وبيانات الأحداث على نطاق واسع.
- عمليات التكامل لتحسين الأداء (SGLang، LlamaIndex، LangChain، Guidance، LMQL) — اختيرت لإضافة التخزين المؤقت للبادئات والاسترجاع وتحليل المهام والتوليد المقيد كخدمات اختيارية، بحيث يكون التحسين الأكثر تعقيداً متاحاً دون أن يكون إلزامياً.
- الحالة: تجريبية. تُوصف الخدمة بأنها جاهزة للإنتاج، لكن أرقام الأداء والتغطية المذكورة في ملف README (مثل "أكثر من 1000 طلب في الثانية"، "أقل من 500 مللي ثانية للمخزن المؤقت"، وعدد مقدمي الخدمات ونصوص التحقق) هي ادعاءات المشروع الذاتية وغير مدققة بشكل مستقل، وقد تم الاحتفاظ بها هنا بشكل نوعي عن قصد.
- يتفاوت عدد مقدمي الخدمات داخل ملف README نفسه؛ حيث يستخدم النص صياغة نوعية هي "العديد من مقدمي الخدمات".
درجة الأولوية: Helix-أساسية.