// tier: helix-primary · order 11

LLMsVerifier betalicense: TBD

GoGinSQLite + SQLCipherRedisRabbitMQ + KafkagRPC + Protocol BuffersQUIC / HTTP-3 (quic-go)JWT + LDAP/NTLMAngularPython + JavaScript SDKsDocker / Kubernetes / HelmPrometheus + Grafana

Source

• vasic-digital/LLMsVerifier

// architecture

تحقق. راقب. حسّن.

LLMsVerifier منصة على مستوى المؤسسات للتحقق من أداء نماذج اللغات الكبيرة ومراقبتها وتحسينها عبر عدة مزودين، وهي مبنية على اختبار تحقق إلزامي بعنوان "هل ترى شفرتي؟" بحيث لا تُعلَّم أي نماذج بأنها قابلة للاستخدام أو تُصدَّر إلا بعد إثبات فعاليتها الفعلية.

منصة LLMsVerifier التي تتحقق من نماذج اللغات الكبيرة وتقيس أدائها وتراقبها وتحسنها عبر عدة مزودين. يجب على كل نموذج اجتياز اختبار رؤية الشفرة الإلزامي قبل الاستخدام؛ بعدها يخضع لاختبارات زمن الاستجابة والبث المباشر واستدعاء الوظائف والرؤية والتضمين، ثم تُصدَّر التكوينات المُتحقَّق منها فقط لأدوات AI وCLI.

LLMsVerifier منصة شاملة للتحقق من أداء نماذج LLM ومراقبته وتحسينه عبر عدة مزودين. يقوم مبدأها الأساسي على *التحقق الإلزامي*، وهي لا تتساهل في ذلك: قبل أن يُعلَّم أي نموذج بأنه قابل للاستخدام — أو يُسمح بإدراجه في تكوينات مُصدَّرة — يجب أن يجتاز بنجاح اختبار "هل ترى شفرتي؟" الذي يرسل طلبات HTTP حقيقية إلى المزود ويحلل الاستجابة للتحقق من الفهم الحقيقي، وليس مجرد صدى يبدو معقولاً. النموذج الذي لا يستطيع إثبات رؤيته وفهمه لمدخلاتك ببساطة لا يحصل على علامة "قابل للاستخدام". بعد اجتياز هذا الحاجز، يقوم محرك التحقق بإجراء مجموعة كاملة من اختبارات القدرات — الوجود والاستجابة وزمن الاستجابة والبث المباشر واستدعاء الوظائف والرؤية وembeddings — ثم يحول محرك التقارير النتائج إلى تقارير بتنسيق ماركداون وJSON يمكنك التصرف بناءً عليها.

النظام معياري ويعمل بناءً على الأحداث، ويوفر واجهات CLI وواجهة المستخدم النصية والويب وREST وAPI فوق نواة تتكون من محرك التحقق ومحرك التقارير ومدير التكوينات، ولا يتوقف عند مرحلة التحقق. تضيف الطبقات المتقدمة نمط المشرف/العامل لتحليل المهام المدعومة بـLLM، وإدارة السياق عبر النوافذ المنزلقة وتلخيص LLM لضمان عدم انقطاع الجلسات الطويلة، بالإضافة إلى نقاط التحقق المدعومة بالسحابة ونظام التبديل الاحتياطي مع قواطع الدوائر والتوجيه بناءً على زمن الاستجابة. البنية التحتية المحيطة جاهزة للإنتاج: حافلة أحداث بنمط النشر/الاشتراك، وجدولة زمنية، وكشف التسعير والحدود، وقاعدة بيانات vector لـRAG، ونظام تصدير. تتبع المنصة اتفاقية تسمية مميزة تضيف لاحقة (llmsvd) إلى كل نموذج/مزود مُولَّد، بحيث يمكن تتبع المخرجات المُتحقَّق منها بنظرة سريعة ولا تُخلط أبداً مع تلك غير المُدقَّقة — ولا تُكتب سوى النماذج المُتحقَّق منها في التكوينات المُصدَّرة لأدوات AI وCLI مثل OpenCode وCrush وClaude Code. تأتي المنصة مزودة بأدوات التشغيل التي تحتاجها الفرق في بيئات الإنتاج: نشر Docker/Kubernetes/Helm، ومراقبة Prometheus/Grafana، ومصادقة LDAP/SSO، وتخزين مشفر بـSQLCipher.

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

المحتوى

يجعل أساطيل LLM *موثوقةً* — وهي صفة نادراً ما تُكتسب في فضاء مليء بالتكوينات التي تكذب بالتقصير. فبدلاً من الأمل في أن يعمل النموذج المُكوَّن كما ينبغي، تحصل الفرق على ضمان قابل للاختبار يُفرض بقوة، يثبت أن كل نموذج قيد الاستخدام قد اجتاز تحققاً حقيقياً، مع مراقبة مستمرة وآليات تجاوز للفشل والتصدير المُتحقق منه فقط، ليُغلق الحلقة من الإثبات إلى الإنتاج. داخل نظام Helix البيئي، يصبح المصدر الوحيد للحقيقة بشأن نماذج LLM وموفريها وبيانات التحقق: فخدمات أخرى (من بينها HelixTranslate) تتوجه إليه، وبذلك يرث النظام بأكمله إجابة واحدة صادقة عن سؤال "أي النماذج تعمل بالفعل الآن؟" بدلاً من أن تحتفظ كل فرقة بتخمينها المتفائل الخاص.

• التحقق الإلزامي "هل ترى شفرتي؟" — بوابة فهم حقيقية مدعومة ببروتوكول HTTP يجب على النموذج اجتيازها قبل أن يصبح قابلاً للاستخدام؛ إنها السمة المميزة للمنتج والسبب وراء عدم تسرب أي شيء غير مُثبت.
• تصدير التكوينات المُتحقق منها فقط — التكوينات المولدة لأدوات AI وCLI تحتوي *فقط* على النماذج التي اجتازت التحقق، وبذلك لا يمكن للتكوين الذي تُصدره أن يعيد خلسةً نموذجاً معطوباً.
• نظام لاحقة العلامة التجارية (llmsvd) — يحمل كل موفر/نموذج مولد لاحقة قابلة للتتبع، مما يجعل مصدر التحقق المرئي في كل مكان ينتقل إليه الناتج.
• كشف القدرات عبر العديد من وكلاء CLI والموفرين — إذ يُحدد بصمات أنواع البث (SSE، WebSocket، JSONL، EventStream)، والضغط، وسلوكيات التخزين المؤقت بدلاً من افتراضها.
• تجاوز الفشل المتين — قواطع الدوائر، والتوجيه القائم على زمن الاستجابة الذي يعيد التوجيه عند تجاوز زمن الوصول لأول رمز حداً معيناً، ومسابر الصحة، وتقسيم حركة المرور الموزون يحافظ على استجابة الأسطول عندما تتذبذب الموفرين الفرديين.
• الاستقلالية طويلة الأمد — نمط تفكيك المشرف/العامل مع نقاط التحقق والتكامل مع الذاكرة يدعم الجلسات الممتدة التي قد تستنفد السياق لولا ذلك.
• تكامل RAG / vector-DB لتعزيز السياق المُستند إلى الواقع.

• إثبات أن النموذج يعمل بالفعل، وليس مجرد كونه مُكوَّناً. هذه هي الفكرة الأساسية، وهي الجزء الأصعب. تم التغلب عليها باختبار رؤية الشفرة الإلزامي الذي يجري مكالمات API حقيقية ويحلل الاستجابات للتحقق من الفهم الإيجابي، مدعوماً بمجموعة واسعة من اختبارات القدرات — ثم برفض تصدير أي شيء لم يجتز الاختبار، وبذلك يكون الإثبات وليس التكوين هو ما يحدد الإنتاج.
• الموثوقية عبر العديد من الموفرين الخارجيين غير المستقرين. تم التغلب عليها بمنظم تجاوز الفشل الذي يتعامل مع عدم استقرار الموفرين كحالة طبيعية: قواطع الدوائر تضع علامة على الموفر باعتباره متدهوراً بعد N إخفاقات خلال M ثانية، والتوجيه القائم على زمن الاستجابة يبتعد عن نقاط النهاية البطيئة، ومسابر الصحة الدورية تتحقق من التعافي، والتوجيه الموزون يوازن بين النماذج الاقتصادية والمتميزة.
• دعم الجلسات الطويلة المستقلة. تم التغلب عليها بنمط تفكيك المشرف/العامل الذي يقسم العمل الكبير إلى أجزاء قابلة للإدارة، مع نقاط تحقق دورية للتخزين السحابي لضمان بقاء التقدم حتى بعد الانقطاع، وإدارة السياق متعددة الطبقات (نافذة منزلقة + تلخيص LLM + RAG) ليحافظ النموذج على خيط الحديث دون أن يغرق في الرموز.
• انتشار الموفرين. تم التغلب عليه بإخفاء العديد من محولات Go الخاصة بكل موفر خلف واجهة مشتركة واحدة، مع تعداد نقاط النهاية الحقيقية مركزياً — وبذلك يصبح إضافة موفر تغييراً محصوراً، لا موجة تنتشر عبر قاعدة الشفرة.

المحتوى

• Go — اختيرت كلغة المنصة الأساسية لقدرتها على التعامل المتزامن؛ فهي تشغل محرك التحقق متعدد الخيوط القادر على فحص العديد من النماذج بالتوازي، بالإضافة إلى الخدمات المحيطة.
• Gin — اختيرت كخادم REST API، حيث تتولى مصادقة JWT، وتحديد معدلات الطلب، ونقاط نهاية WebSocket/SSE.
• SQLite + SQLCipher — اختيرا للتخزين المدمج مع تشفير على مستوى قاعدة البيانات، لأن بيانات التحقق (المفاتيح والنتائج) حساسة ويجب تشفيرها افتراضياً أثناء التخزين.
• Redis — اختيرت كطبقة تخزين مؤقت للحفاظ على سرعة عمليات التحقق والاستعلامات الوصفية الساخنة.
• RabbitMQ + Kafka — اختيرا لتشغيل البنية المعتمدة على الأحداث: الرسائل والبث الذي يفصل بين المنتجين والمستهلكين عبر المنصة.
• gRPC + Protocol Buffers — اختيرا للاتصال بين الخدمات ونقل الأحداث بنظام كتابة قوي بين المكونات.
• QUIC / HTTP-3 (quic-go) — اختيرا لدعم النقل الحديث (تشير وثائق المستودع إلى محدودية توفر مزودي HTTP/3 — وهي ميزة مقدمة وليست ادعاء عاماً).
• JWT + LDAP/NTLM — اختيرا لمصادقة المؤسسات بحيث تندمج المنصة مع هوية الشركات الحالية (تدعم الوثائق SSO/SAML/OIDC).
• Viper (الإعدادات)، Logrus (التسجيل)، Brotli/compress (الضغط) — البنية التشغيلية الأساسية: إعدادات مرنة، سجلات منظمة، وضغط الحمولة.
• Angular — اختيرت لتطبيق الويب أحادي الصفحة، واجهة العرض الأمامية للتحقق والمراقبة.
• Python + SDKs الخاصة بـ JavaScript — اختيرا لمنح فرق العملاء وصولاً مميزاً، موثقاً عبر OpenAPI/Swagger.
• Docker، Kubernetes، Helm — اختيرت للنشر الإنتاجي مع مراقبة الحالة والتوسيع التلقائي، بحيث تتوسع مجموعة التحقق مثل أي خدمة حديثة.
• Prometheus + Grafana — اختيرا لقياس الأداء ولوحات التحكم، مما يجعل صحة المنصة قابلة للرصد مثل النماذج التي تراقبها.
• Testify (Go) + node --test/jsdom (الويب) — اختيرا للاختبار متعدد الطبقات عبر نواة Go وواجهة الويب الأمامية.

• الحالة: تجريبية. ينفذ مصدر Go تحقق HTTP حقيقياً (إحدى الوثائق القديمة التي تصف التحقق بأنه مجرد إعداد هي وثيقة طموحة وقديمة — الشفرة هي المرجعية الرسمية).
• الترخيص: لم يحدد بعد. تذكر ملفات README ترخيص MIT بينما يشير ملصق Dockerfile إلى Apache-2.0 — يجب حسم الأمر قبل النشر.
• عدد المزودين: تذكر ملفات README "12 محولاً"، لكن دليل المزودين يسرد حوالي 26 — تعامل على أنها "12+ / المزيد قيد التطوير". توجد العديد من الملفات الطموحة التي تحمل حالة "نهائي/مكتمل"؛ الشفرة والوثائق وملف go.mod هي المرجعية الرسمية.
• يقع المستودع ضمن منظمة vasic-digital لكنه عملياً يشكل طبقة الثقة لبنية Helix LLM الأساسية.

درجة الأولوية: Helix-أساسية (بنية LLM الأساسية؛ المصدر الوحيد للحقيقة بالنسبة لبيانات LLM/المزود/التحقق). تأتي في المرتبة التالية بعد HelixTrack.