// tier: helix-primary · order 10

HelixTranslate betalicense: TBD

GoGinQUIC / HTTP/3 (quic-go)gRPC + Protocol BuffersGorilla WebSocketPostgreSQLSQLiteRedisunidoc/unioffice + unipdfCobraLLMsVerifier bridgeDocker / Podman

Source

• HelixDevelopment/HelixTranslate
• HelixDevelopment/HelixConstitution

// architecture

ترجمة كتب بنموذج موثّق — مصممة لتكون صادقة، ولا تعتمد أبداً على التراجع الصامت.

HelixTranslate منصة ترجمة كتب إلكترونية عالية الأداء مبنية على Go، تترجم الكتب بين أكثر من 100 لغة باستخدام مزودي ترجمة موثّقين من LLM، مع مراقبة WebSocket في الوقت الفعلي وسياسة صارمة بعدم التراجع الصامت، حيث تفشل بوضوح بدلاً من التدهور بصمت.

أداة ترجمة كتب إلكترونية شاملة مبنية على Go. تترجم صيغ FB2، وEPUB، وTXT، وHTML، وPDF، وDOCX عبر أكثر من 100 لغة باستخدام أقوى نماذج LLM الموثّقة (عبر جسر LLMsVerifier)، مع واجهات برمجة التطبيقات REST/HTTP-3 وgRPC، ومعالجة موزعة ولوحة تحكم لمراقبة WebSocket في الوقت الفعلي.

HelixTranslate نظام على مستوى المؤسسات مبني على Go لترجمة الكتب الكاملة بين اللغات باستخدام مزودي LLM — ليس فقرات أو مقتطفات فحسب، بل أعمال كاملة من البداية إلى النهاية. يقوم النظام بتحليل وإعادة توليد عدة صيغ للكتب الإلكترونية (FB2، وEPUB، وTXT، وHTML، وPDF، وDOCX)، ويدعم أكثر من 100 لغة مع الكشف التلقائي، ويوفر أدوات CLI وخوادم API (REST عبر HTTP/3، وgRPC، وتدفق أحداث WebSocket) بحيث يتناسب سواء مع سير عمل طرفي أو بنية خدمات موزعة. أما السمة المميزة له فهي *كيفية اختيار النموذج*: فبدلاً من ترميز مزود معين على أمل أن يبقى فعالاً، يفوّض HelixTranslate كل سلطة النماذج إلى جسر LLMsVerifier (pkg/bridge)، الذي يختار أقوى نموذج API *الموثّق* ويعيد سلسلة احتياطية مرتبة حسب الدرجات بشكل حتمي. يتم تحديد أهلية النموذج بناءً على درجة مرجحة تشمل الاستجابة، والكود، وغنى المزايا، والموثوقية — وبذلك فإن النموذج الذي يقوم بترجمتك قد حصل على مكانه من خلال إثبات كفاءته، وليس لمجرد وجوده في ملف الإعدادات.

الأهم من ذلك أن النظام يفرض مبدأ "عدم التراجع الصامت" مباشرة في الكود: فإذا لم يكن مفتاح مزود API موجوداً، أو طلب المشغل صراحةً مزوداً غير متاح، فإن خط الأنابيب يعيد خطأ صريحاً بدلاً من التحول بصمت إلى مزود آخر أو الرجوع إلى بيئة تشغيل محلية والتظاهر بأن كل شيء على ما يرام — وهي قاعدة تُطبق عبر بوابة مخصصة قبل البناء واختبار تحور مزدوج. تم إزالة بيئات التشغيل المحلية (Ollama، وllama.cpp) عن قصد من المسار الافتراضي حتى لا يحل محرك أضعف محل نموذج موثّق بصمت. حول نواة الترجمة، يوجد نظام مراقبة WebSocket في الوقت الفعلي: حيث يرسل أداة الترجمة CLI أحداثاً محددة إلى خادم المراقبة الذي يدير لوحة تحكم ويب مباشرة، بينما تقوم عمّال SSH البعيدون بتوزيع عبء العمل لترجمة موزعة. فوق ذلك، تُضاف طبقات متعددة من التنقيح لضمان الاتساق، وتحليل جودة في مرحلة الإعداد، وتخزين مؤقت للترجمة للتحكم في التكاليف عند المدخلات الطويلة، وضمان جودة مدفوع بالرؤية. يستجيب النظام بأكمله لدستور هندسي ضد التضليل: يجب أن تثبت الاختبارات نتائج حقيقية ومرئية للمستخدم، مدعومة باختبارات التحور الإلزامية بدلاً من علامات الاختيار الخضراء التي لا تثبت شيئاً.

المحتوى

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

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

• توجيه النماذج عبر بوابة التحقق LLMsVerifier — يتم اختيار أقوى نموذج *موثق* تلقائياً، فيحدد المشغلون الغرض وليس أسماء الموردين، ولا يختارون مزوداً قد يكون غير متاح.
• ضمان عدم التراجع الصامت عبر الكود — أربعة مسارات توجيه صريحة (نموذج تجريبي / مُتحقق صريح / مزود صريح / افتراضي عبر البوابة)، كل منها يؤدي إلى خطأ صريح بدلاً من التحول الصامت، بالإضافة إلى إزالة البيئات المحلية من المسار الافتراضي بحيث لا يوجد خيار أضعف للتراجع *إليه*.
• التنفيذ الآلي — بوابة ما قبل البناء CM-NO-LOCAL-RUNTIME بالإضافة إلى اختبار تحور مزدوج يؤكد، أثناء البناء، أنه لا يتم إنشاء أي عميل بيئة محلية على المسار الافتراضي: لا يمكن أن يتآكل الضمان لأن البناء يفشل إذا حدث ذلك.
• سلسلة تراجع حتمية ومرتبة حسب الأداء — يُسمح بالانتقال بين النماذج *الموثقة* في حال الفشل، وهو أمر شفاف بالكامل، ويمثل تمييزاً مبدئياً عن التراجع الصامت الممنوع: أنت تعرف دائماً أي نموذج قادر تولّى المهمة.
• مراقبة WebSocket في الوقت الفعلي — أحداث الترجمة المُحددة تُبث مباشرة إلى لوحة التحكم، مع عمال SSH موزعين بحيث تكون مهمة ترجمة كتاب طويلة مرئية ومتوازية، لا صندوقاً أسود.
• نظام اختبار مضاد للخداع — اختبار التحور، التأكيدات السلبية، تشغيل الأنظمة الحقيقية، وضمان الجودة المدفوع بالرؤية تضمن جميعاً أن "اجتياز الاختبارات" لا يمكن أن يخفي خلسة "عدم عمل الميزة فعلياً".

• ضمان مسار ترجمة صادق (دون تدهور صامت). تم التغلب عليه من خلال تركيز كل سلطة النماذج في بوابة LLMsVerifier بحيث يكون هناك نقطة قرار واحدة للمراقبة، وترميز أربعة مسارات توجيه صريحة تفشل بصوت عالٍ بدلاً من التخمين، وإزالة خيارات التراجع المحلية بالكامل من المسار الافتراضي، وتثبيت القاعدة عبر بوابة بناء واختبار تحور يفشل البناء إذا تم إزالة الضمان.
• "الاختبارات ناجحة، لكن الميزات معطلة." يعترف الدستور بهذا النمط من الفشل ويواجهه بنظام اختبار مضاد للخداع: تأكيدات ملموسة ومرئية للمستخدم بدلاً من تفاصيل التنفيذ، وأنظمة حقيقية في الحلقة (النماذج التجريبية تقتصر على اختبارات الوحدة)، واختبار التحور الإلزامي (إحداث خلل متعمد في الميزة ويجب أن يفشل الاختبار)، وضمان الجودة المدفوع بالرؤية الذي يتفحص المخرجات فعلياً.
• الجودة في النصوص الطويلة والمتعددة الصيغ. تضغط المدخلات الطويلة على الاتساق والميزانية؛ تم التغلب على ذلك من خلال التنقيح متعدد المراحل الذي يعيد النظر في النص، وتحليل مسبق لحجم المهمة، وتخزين الترجمة لتجنب الدفع مرتين لنفس المقطع.

المحتوى

• Go — تم اختياره لقدراته المتزامنة التي تتوافق بشكل طبيعي مع تحليل وترجمة وبث العديد من الفصول في وقت واحد؛ الواجهة الخلفية عالية التزامن، الوحدة digital.vasic.translator.
• Gin — تم اختياره كموجه HTTP سريع وبسيط لخدمة واجهة REST API.
• QUIC / HTTP/3 (quic-go) — تم اختياره لمنح واجهة REST API نقلاً حديثاً منخفض الكمون يتحمل الشبكات غير المثالية.
• gRPC + Protocol Buffers — تم اختياره لواجهة خدمة قوية الكتابة وعالية الأداء تعمل جنباً إلى جنب مع REST للمتصلين البرمجيين.
• Gorilla WebSocket — تم اختياره لنقل دفق أحداث الترجمة اللحظية والمكتوبة الذي يغذي لوحة المراقبة مباشرة.
• PostgreSQL، SQLite، Redis — تقسيم متعمد على ثلاث طبقات: PostgreSQL للبيانات العلائقية الدائمة، SQLite للحالة المضمنة/المحلية (يدعم أيضاً مخزن النماذج الموثقة للجسر، data/verified_models.db)، وRedis كذاكرة تخزين مؤقتة ساخنة.
• unidoc/unioffice + unipdf — تم اختيارهما للتعامل مع التنسيقات المعقدة: تحليل وإعادة توليد DOCX وPDF لضمان دورة تحويل موثوقة للكتب الإلكترونية متعددة التنسيقات.
• Cobra — تم اختياره كإطار عمل CLI الذي يشغل أداة unified-translator وأدواتها المصاحبة.
• golang-jwt (JWT HS256) — تم اختياره لمصادقة API عديمة الحالة، مقترناً بتحديد معدل الرموز لكل عنوان IP وتأمين النقل عبر TLS/QUIC للحفاظ على صلابة الواجهة.
• جسر LLMsVerifier (pkg/bridge) — العنصر المحوري: يستمد أقوى نموذج موثق بالإضافة إلى سلسلة الاحتياط الحتمية، ويعمل كنقطة تنفيذ واحدة لضمان عدم اللجوء إلى الاحتياط بصمت.
• Testify — تم اختياره لمجموعة اختبارات Go، بما في ذلك ملف الاختبار المخصص provider_routing_test.go وبوابات التعديل التي تحافظ على قواعد النزاهة سليمة.
• Docker / Podman (بدون صلاحيات الجذر) + Compose — تم اختيارهما للنشر الموزع والحاوياتي (docker-compose.distributed.yml)، مع Podman بدون صلاحيات الجذر لتعزيز الوضع الأمني.

• الحالة: تجريبية. المنصة وظيفية؛ لكن رقم الإصدار غير متسق بين ملفات VERSION/Makefile/AGENTS.md، لذا يُعتبر غير مستقر.
• الرخصة: لم تُحدد بعد. ملف README يذكر رخصة MIT لكن هذا لم يُؤكد بوجود ملف LICENSE — يجب التحقق قبل التأكيد.
• نقاط نهاية لوحة المراقبة/المراقبة محلية فقط وليست عامة. أرقام أداء WebSocket المذكورة في الوثائق هي أهداف مستهدفة وليست مؤكدة. لا يزال ملف ARCHITECTURE.md يسرد محركات Ollama/المحلية التي أُزيلت (معلومات قديمة).

طبقة الأولوية: Helix-الرئيسية (مجموعة LLM للبنية التحتية). تأتي ضمن عائلة منصة Helix بعد HelixTrack.