Jev هو أول نموذج System One تقدمه TypeSafe AI، صُمّم للتطبيقات التي تحتاج إلى قرارات مُهيكلة بدلاً من نثر مُولَّد. يقوم بتقييم المعلومات المُقدَّمة مقابل أسئلة محددة بوضوح ويُرجع إجابات مُنَمَّطة، وتوزيعات احتمالية، وعند الاقتضاء درجات ثقة.

على عكس نموذج اللغة الكبير التقليدي، لا يُقصد من Jev الدردشة أو كتابة الشيفرة أو إنشاء محتوى طويل. غايته إصدار أحكام محدودة النطاق يمكن للبرمجيات استخدامها فوراً للتصنيف، والتوجيه، والتقييم، والتحقق، وإعطاء الأولوية، والتحكم في سير العمل.

تمت مراجعة معلومات النموذج في 21 سبتمبر 2026.

المواصفات التقنية لـ Jev

قد تتغير الأسعار والأسماء المستعارة وحدود المعدّل. ينبغي على المطورين التحقق من أحدث المعلومات قبل نقل عبء عمل إلى الإنتاج.

ما هو Jev؟

Jev هو نموذج قرارات طورته TypeSafe AI. بدلاً من توليد تسلسل مفتوح من الرموز، يختار قيماً من فضاءات إجابات يحددها المطور.

يحتوي طلب Jev على مكوّنين رئيسيين:

• State: المعلومات التي ينبغي على النموذج تقييمها، مثل تذكرة دعم، أو سجل معاملة، أو أثر وكيل، أو وصف منتج، أو حالة تطبيق منسّقة بصيغة JSON.
• Questions: تعريفات منمطة للأحكام التي يجب إجراؤها على تلك الحالة.

المخرجات الناتجة مخصصة للاستخدام المباشر من قبل البرمجيات. يمكن للتطبيق أن يتفرع بناءً على الفئة المختارة، أو يقارن الدرجات، أو يفحص الاحتمالات، أو يطبق عتبة ثقة، أو يرسل الحالات غير المؤكدة إلى مراجع بشري.

لذلك يعمل Jev كطبقة قرارات احتمالية بين بيانات التطبيق والمنطق الحتمي للأعمال. يعالج أحكاماً يصعب التعبير عنها عبر قواعد ثابتة مع السماح لشيفرة التطبيق بالاحتفاظ بالتحكم في العتبات والأذونات والإجراءات.

كيف يعمل Jev

ثلاث بدائيات للقرار

يدعم Jev ثلاثة أنواع من الأسئلة مصممة لأنواع مختلفة من قرارات البرمجيات.

Choice يختار خياراً واحداً من مجموعة محددة مسبقاً. وهو مناسب لمهام مثل تصنيف النية، وتوجيه التذاكر، وتصنيف السياسات، واختيار النموذج. يتضمن الرد الخيار المحدد، والاحتمال المخصص لكل خيار، ودرجة الثقة.

Score يقيّم الحالة وفق مقياس مرتب. يمكنه قياس صفات مثل الإلحاح، والمخاطر، والملاءمة، والإحباط، وجودة المحتوى. يتضمن الرد درجة، واحتمالات لكل مستوى في المقياس، ودرجة ثقة.

Noul يقدّر احتمال صدق عبارة ما. يُرجع قيمة بين 0 و1 ويكون مفيداً للتحقق، وفحوص السياسات، وقرارات الأهلية، وبوابات الإكمال. وعلى خلاف Choice وScore، لا يُرجع Noul حقلاً منفصلاً للثقة لأن مخرجه في الأصل احتمال.

تقييم الأسئلة بالتوازي

يمكن أن يحتوي طلب واحد على أسئلة متعددة من نوع Choice وScore وNoul. يُقيّم Jev هذه الأسئلة بشكل مستقل وبالتوازي على الحالة نفسها.

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

لا يمكن أن تعتمد الأسئلة داخل الطلب نفسه على إجابات بعضها البعض. ينبغي تنفيذ القرارات التسلسلية عبر استدعاءات منفصلة موصولة بمنطق التطبيق.

استجابات آمنة من حيث النوع

تُحدَّد البنى الممكنة لاستجابات Jev قبل الاستدلال. يمنع ذلك ظهور JSON غير صالح، أو حقول غير متوقعة، أو نصوص توضيحية في أماكن يُتطلب فيها فئة أو قيمة رقمية.

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

احتمالية وثقة بصيغة صريحة

يفصح كل من Choice وScore عن توزيع الاحتمال وراء كل إجابة. تُلخّص قيمة الثقة مقدار انحياز ذلك التوزيع نحو نتيجة بعينها.

يمكن للتطبيقات استخدام الثقة لأتمتة القرارات الواضحة، وطلب تأكيد حين تكون حالة عدم اليقين متوسطة، وتوجيه الحالات الغامضة إلى إنسان أو نموذج بديل.

تعتمد العتبة المناسبة على المخاطر. وسم تذكرة دعم يمكنه تحمل مزيد من عدم اليقين مقارنةً بالموافقة على معاملة أو تنفيذ إجراء لا يمكن التراجع عنه.

استدلال منخفض الكمون

تفيد TypeSafe بأن أزمنة الاستجابة من طرف إلى طرف تبلغ تقريباً 70 إلى 500 مللي ثانية. هذا يجعل Jev مناسباً للتوجيه التفاعلي، وفحوص الوكيل المتكررة، وغيرها من تدفقات العمل كثيفة القرارات حيث قد يؤثر اتصال نموذج توليدي أبطأ على الاستجابة.

يعتمد الكمون الفعلي على حجم الحالة، وحمل الخدمة، وظروف الشبكة، ومنطقة النشر.

تخصيص على مستوى الطلب

لا يُخصص Jev عبر ضبط دقيق خاص بالحساب أو عبر محولات LoRA. يكيّفه المطورون من خلال تزويده بحالة ذات صلة، وكتابة تعليمات دقيقة، وتعريف معايير واضحة، ودمج قرارات ذرّية في شيفرة التطبيق.

يحافظ هذا النهج على وضوح قواعد العمل ويسمح للفرق بتغيير منطق سير العمل دون إعادة تدريب النموذج.

نماذج بإصدارات وأسماء مستعارة مستقرة

توفر TypeSafe معرّفات نماذج ثابتة وأسماء مستعارة متحركة. يعرّف jev-1.13.0 إصداراً محدداً، بينما يشير jev-latest إلى أحدث إصدار مستقر. قد ينتقل jev-preview إلى إصدار معاينة أحدث عند توفره.

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

أداء Jev في الاختبارات المعيارية

لم يُصمَّم Jev للمعايير العامة التي تركز على الكتابة أو البرمجة أو الاشتقاقات الرياضية أو الاستدلال المطول. تشمل القياسات الأكثر صلة جودة القرار، ومعايرة الاحتمال، والكمون، والتكلفة، وموثوقية المخرجات.

تفيد TypeSafe بما يلي:

• أزمنة استجابة من طرف إلى طرف بين 70–500 مللي ثانية
• تنفيذ أسرع بنحو 40–200× في مهام System One القابلة للمقارنة
• نتائج تدفق عمل قصوى بسرعة أعلى بمقدار 193.6×
• تحسينات تكلفة قصوى مُبلّغ عنها بمقدار 444.6×

هذه نتائج مذكورة من البائع ولا ينبغي التعامل معها كضمانات أداء شاملة. تُقارن تقييمات TypeSafe لتدفقات العمل النماذج على رسوم قرارات مُهيكلة وتستخدم متوسط تنبؤات نماذج خارجية مختارة رفيعة المستوى كاحتمالات مرجعية.

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

Jev مقابل LLM بمخرجات مُهيكلة مقابل المصنّف الكلاسيكي مقابل محرك القواعد

يكون Jev مفيداً على نحوٍ خاص عندما تكون القواعد الثابتة هشة جداً، ويكون إنشاء مصنّف مخصص مكلفاً، ولا يحتاج التطبيق إلى نص مُولّد.

يبقى نموذج LLM التقليدي الخيار الأفضل عندما تتطلب المهمة بحثاً أو شرحاً أو إنشاء محتوى أو تخطيطاً أو استدلالاً متعدد الخطوات. ويظل محرك القواعد مفضلاً عندما يكون الشرط الصحيح صريحاً وحتمياً بالفعل.

حالات الاستخدام الموصى بها

Jev مناسب بصورة أفضل للقرارات المتكررة ذات فضاء إجابات مُعرّف مسبقاً.

• التوجيه والفرز: تصنيف الطلبات، اختيار الطوابير أو الأدوات، وإعطاء الأولوية للحالات العاجلة.
• التحكم بالوكيل: التحقق من إتمام المهام، تقييم الإجراءات المقترحة، وتحديد الحالات التي تتطلب تأكيداً.
• تقييم LLM: تقييم الصلة، دعم الأدلة، الامتثال للسياسات، أو جودة الاستجابة.
• الإشراف: تصنيف انتهاكات السياسات، تسجيل شدة المخالفة، وتصعيد الحالات غير المؤكدة.
• إثراء البيانات: تحويل الرسائل، والمراجعات، والعملاء المحتملين، والسجلات إلى فئات ودرجات وميزات احتمالية.
• قرارات آنية: دعم سلوك التطبيق منخفض الكمون حيث لا تكون الاستجابة التوليدية الكاملة ضرورية.

قيود Jev

Jev متخصص عمداً، ويؤدي تصميمه الضيق إلى عدة قيود مهمة.

• لا يمكنه توليد نثر أو شيفرة أو ملخصات أو إجابات محادثية.
• ليس موجهاً للبحث المطول أو الاستدلال متعدد الخطوات.
• الإخراج الآمن من حيث النوع لا يضمن قراراً تجارياً صحيحاً.
• يجب تحويل الصور والصوت والفيديو والملفات الثنائية إلى نص أو بيانات مُهيكلة قبل الإرسال.
• الإنجليزية هي اللغة الأقوى توثيقاً.
• أحمال العمل بغير الإنجليزية وبلغات CJK تتطلب تقييماً مستقلاً.
• تُقيَّم الأسئلة ضمن طلب واحد بشكل مستقل.
• لا يستطيع النموذج بناء سلسلة استدلال تسلسلية عبر تلك الأسئلة.
• لم تفصح TypeSafe عن عدد معاملات النموذج ولم تُصدر أوزانه.
• يُجرى التخصيص عبر الطلب لا عبر ضبط دقيق خاص بالعميل.
• التحسينات المنشورة في الأداء تأتي من إطار التقييم الخاص بـ TypeSafe.
• قد تؤدي الأسماء المستعارة المتحركة إلى تغييرات سلوكية دون تغيير في شيفرة التطبيق.

لا ينبغي أن يحل Jev محل الشيفرة الحتمية لأذونات الوصول، أو الحسابات المالية، أو المتطلبات القانونية، أو حدود أحجام الملفات، أو سياسات الإجراءات غير القابلة للعكس. النماذج الاحتمالية مفيدة للأحكام غير المؤكدة، لا للشروط التي تستطيع البرمجيات تقييمها بدقة بالفعل.

كيف توفر CometAPI الوصول إلى واجهة Jev API؟

لا يتوفر Jev حالياً في فهرس النماذج العام لدى CometAPI. تخطط CometAPI لتقييم ودمج Jev بمجرد توفر الوصول إلى النموذج وفتح أذونات الاتصال المطلوبة.

بعد التكامل، سيتمكن المطورون من مراجعة دليل نماذج CometAPI ووثائق API لمعرفة معرّف النموذج المدعوم، وصيغة الطلب، والتسعير، وحدود المعدّل، وتوفر نقاط النهاية.

إلى أن يُعلن التكامل رسمياً، ينبغي على المطورين استخدام وحدة تحكم TypeSafe، أو واجهة API الأصلية، أو حِزم SDKs الرسمية للوصول إلى Jev. لا يجوز اعتبار تكامل CometAPI متاحاً إلا بعد ظهور Jev في فهرس النماذج العام مع معلومات API مُتحقق منها.