TL;DR
Jev هو نموذج قرارات طوّرته TypeSafe AI. قدّمت TypeSafe نموذج Jev في 15 سبتمبر 2026 بوصفه أول نموذج System One لديها، مصمّمًا لإرجاع قرارات مُهيكلة واحتمالات يمكن للبرمجيات استخدامها مباشرة. يعتمد هذا الدليل أساسًا على وثائق TypeSafe الرسمية، ودليل البدء السريع، والمرجع الخاص بالنموذج، والإعلان الرسمي عن Jev من الشركة.
لا يقوم Jev بكتابة نثر أو توليد أكواد أو إجراء محادثة. إنه يقيّم حالة نصية مقابل أسئلة ذات نوع محدد ويُرجع إجابات مُهيكلة يمكن للتطبيق استخدامها مباشرة.
هذا الفارق مهم لتدفّقات عمل البرمجيات. فالنموذج اللغوي التقليدي ينتج رموزًا نصية (tokens) حتى عندما لا يحتاج التطبيق سوى فئة أو درجة أو حكم بنعم/لا. صُمّم Jev حول القرار نفسه. واجهته تقبل حالة وأسئلة واحدة أو أكثر، ثم تُرجع قيَمًا مُعلّمة النوع وتوزيعات احتمالية. إجابات Choice وScore تتضمن أيضًا قيمة للثقة.
Jev مُخصّص للتصنيف، والتوجيه، وإسناد الدرجات، والتحقق، والحواجز (guardrails)، وغيرها من القرارات المحصورة. إنه ليس بديلًا عامًا لـ GPT أو Claude أو Gemini أو غيرها من النماذج التوليدية. في وكيل ذكاء اصطناعي، يمكن للنموذج التوليدي التخطيط أو إنشاء المحتوى بينما يتولى Jev القرارات المتكررة مثل اختيار المسار، وفحص المخاطر، أو تقرير ما إذا كانت النتيجة بحاجة إلى مراجعة.
النقاط الأساسية
- Jev من تطوير TypeSafe ويُقدَّم حاليًا كنموذج System One الرائد لديها.
- يقبل النموذج حالة نصية بالإضافة إلى أسئلة مُحددة النوع. ويُرجع قرارات مُهيكلة بدلًا من نثر مولّد.
- يدعم Jev ثلاثة أنواع من الأسئلة تُسمّى Choice وScore وNoul.
- يمكن تقييم أسئلة متعددة بشكل مستقل وبالتوازي مقابل الحالة نفسها ضمن طلب واحد.
- تُدرّب TypeSafe Jev باستخدام التعلم المعزز من أجل قرارات مُعايرة (RLCD).
- تُظهر الصفحة الرسمية الحالية للنموذج الإصدار Jev 1.13 بحد 64,000 رمز طلب وإدخال نصي فقط.
- التسعير الرسمي هو 0.042$ لكل مليون رمز إدخال. رموز الإخراج مُدرجة مجانًا.
- المخرجات الآمنة النوعًا تمنع عدم تطابق المخطط. لكنها لا تضمن صحة كل قرار تجاري.
- تُبلغ TypeSafe عن زمن استجابة بين 70 و500 مللي ثانية ومكاسب كبيرة على تقييمات تدفّقات عملها. هذه أرقام من البائع وتُنطبق على مهام بهيئة System One.
ما هو Jev؟
Jev هو نموذج قرارات بَنَته TypeSafe AI. تصفه الوثائق الرسمية على أنه النموذج الرائد للشركة وأول نموذج System One. لمدخلاته جزآن رئيسيان.
الجزء الأول هو الحالة. الحالة هي المعلومات التي ينبغي على Jev فحصها، مثل رسالة عميل، أو تقرير حادث، أو مجموعة سجلات، أو كائن JSON يحتوي سياق التطبيق.
الجزء الثاني هو مجموعة من الأسئلة مُحددة النوع. كل سؤال يعرّف الحكم المطلوب وشكل الإجابة المسموح به. يقيّم Jev الأسئلة مقابل الحالة ويُرجع نتائج يمكن للكود أن يتشعّب عليها، أو يرتّبها، أو يمنحها درجات، أو يوجّهها.
خذ مثلًا طلب دعم يُفيد بأن تكامل الدفع فشل لمدة ثلاثة أيام. قد لا يحتاج نظام الدعم إلى فقرة تصف الوضع. قد يحتاج بدلًا من ذلك إلى ثلاثة قرارات ضيّقة:
- أي فريق يجب أن يتلقى التذكرة؟
- ما مدى إحباط العميل الظاهر؟
- هل تتطلب الرسالة اهتمامًا عاجلًا؟
يمكن لـ Jev تمثيل هذه كأسماء أسئلة من الأنواع Choice وScore وNoul ضمن طلب واحد. يحتوي الرد على الفئة المختارة أو الدرجة، وتوزيع الاحتمالات ذي الصلة، والثقة حيثما كانت مدعومة. ثم يقرر التطبيق ما الذي سيفعله بهذه القيم.
هذا التقسيم في المسؤوليات مقصود. يقدّم النموذج حكمًا غير يقيني بتنسيق ثابت. يحتفظ كود التطبيق بالتحكم في العتبات، والأذونات، والآثار الجانبية، وسلوك التراجع.
ما هو نموذج System One؟
تستخدم TypeSafe مصطلح نموذج System One لفئة من النماذج المصمّمة لاتخاذ قرارات سريعة ومُهيكلة يمكن للبرمجيات استهلاكها. يستلهم الاسم التمييز بين التفكير السريع والبطيء المرتبط بعمل Daniel Kahneman. إنه يصف الدور المقصود للنموذج، لا ادعاءً بأن نموذجًا برمجيًا يعيد إنتاج الإدراك البشري.
مهمة System One لها هدف مقيّد. ينبغي للمراجع الخبير أن يكون قادرًا على اتخاذ الحكم سريعًا عند توفر سياق كافٍ. الأمثلة تشمل اختيار نية، وتقييم العجلة على مقياس محدد، والتحقق مما إذا كان الادعاء مدعومًا، أو تقرير ما إذا كان ينبغي تصعيد الطلب.
المهام التي تتطلب بحثًا ممتدًا، أو استدلالًا متعدد الخطوات، أو شرحًا مطوّلًا، أو إنشاء محتوى ليست مناسبة بطبيعتها. توصي TypeSafe بتفكيك الأحكام العريضة إلى أسئلة ذرّية ودمج نتائجها في الكود.
على سبيل المثال، "قيّم هذا العرض التقديمي لشركة ناشئة" واسع جدًا لإنتاج قرار يمكن فحصه. يمكن تقييم حجم السوق، والجدوى التقنية، والتميّز كسؤال منفصل لكل منها. يمكن للتطبيق دمج هذه الدرجات بصيغة صريحة. وإذا تغيّرت أولويات الأعمال، يمكن تغيير الأوزان في الكود دون تحويل مُوجّهات النموذج إلى منطق أعمال خفي.
كيف يعمل Jev؟
يمكن كتابة عقد تشغيل Jev على النحو التالي:
الحالة + أسئلة مُحددة النوع -> قرارات مُحددة النوع + احتمالات
وهذا يختلف عن التدفق المعتاد لنموذج لغوي:
مُوجِّه -> رموز مولّدة -> تحليل وتحقق -> قرار التطبيق
التمييز ليس مجرد تنسيق استجابة مختلف. فالمخرجات المُهيكلة التقليدية ما تزال تطلب من نموذج توليدي إنتاج سلسلة من الرموز المطابقة لمخطط. صُمّم Jev لإرجاع قيم من فضاءات إجابة مُعرّفة مسبقًا.
واجهة البرمجة الحالية تقبل الحالة كسلسلة نصية، أو كائن JSON، أو مصفوفة قيم نصية. الإدخال نص فقط. يجب تحويل الصور والصوت والفيديو والمستندات الثنائية إلى نص أو حقول مُهيكلة قبل الإرسال.
يُقيّم كل سؤال في الطلب بشكل مستقل مقابل الحالة نفسها. ووفقًا لوثائق TypeSafe، فإن إضافة أسئلة بالكاد تغير وقت الاستجابة لأن الأسئلة تُقيّم بالتوازي. كما أن الاستقلالية تمنع إجابة سؤال من أن تصبح سياقًا لسؤال آخر في الاستدعاء نفسه.
لهذا السلوك نتيجة تصميم مهمة. إذا كان قرار ما يعتمد حقًا على آخر، فإن الاعتمادية تنتمي إلى سير عمل التطبيق. شغّل التقييم الأول، ثم حدّث الحالة أو تشعّب في الكود، وبعدها نفّذ التقييم التالي. الطلب الواحد مناسب للأسئلة التي تشترك في الأدلة ولا تعتمد إجاباتها على بعضها البعض.
الأنواع الثلاثة لأسئلة Jev
يُظهر Jev ثلاث بدائيات. كل واحدة تطابق نوعًا مختلفًا من قرارات البرمجيات.
| نوع السؤال | الغرض | ما الذي يُرجَع | أمثلة مناسبة |
|---|---|---|---|
| Choice | اختيار خيار واحد من مجموعة مُعرّفة | الخيار المختار، احتمالات الخيارات، الثقة | تصنيف النية، توجيه الفرق، اختيار النموذج |
| Score | تقييم الحالة على سُلّم مُرتّب | درجة، احتمالات المستويات، الثقة | العجلة، الجودة، المخاطر، نية الشراء |
| Noul | تقدير ما إذا كان تصريح ما صحيحًا | قيمة من 0 إلى 1 | فحص السياسات، فحص الاكتمال، الأهلية الثنائية |
Choice
يختار سؤال Choice خيارًا واحدًا من معايير يحددها التطبيق. قد يقدّم سير عمل دعم فني خيارات billing وtechnical وsales مع وصف لكل فئة. يُرجع Jev الخيار المحدد، والاحتمال المُسنَد لكل خيار، وقيمة ثقة مشتقة من شكل ذلك التوزيع.
تصميم الفئات يؤثر على فائدة النتيجة. فالخيارات المتداخلة تخلق التباسًا. والخيارات الناقصة تدفع النموذج نحو إجابة قد لا تلائم. يجب أن تتضمن التصنيفات الإنتاجية مسارًا مثل insufficient_evidence أو human_review عندما يحتاج سير العمل إلى الحفاظ على حالة عدم اليقين.
يجب أن يطابق الصياغة القرار الفعلي أيضًا. "أي فريق يجب أن يحقق أولًا" يطلب مسارًا مبدئيًا. "أي فريق تسبب في الفشل" يطلب تشخيصًا. قد يستخدمان قائمة الفرق نفسها، لكنهما لا يطرحان السؤال نفسه.
Score
يضع سؤال Score الحالة على سُلّم مُرتّب. قد تصف المعايير مستويات مثل هادئ، محبط، وغاضب، أو تعرّف مقياس أعمال أكثر تفصيلًا. يتضمن الرد درجة رقمية، و"مفتاح" يربط الأرقام بالمستويات، وتوزيعًا احتماليًا عبر تلك المستويات، وثقة.
وصف سُلم Score المفيد فروقًا قابلة للملاحظة. الملصقات دون تعريفات تترك النموذج والمراجعين البشريين ليستنتجوا معايير مختلفة. ينبغي لمقياس المخاطر أن يوضح ما الذي يفصل كل مستوى. ينبغي لمقياس الجودة أن يوضح أي المتطلبات متوفر أو مفقود.
إذا خلطت الدرجة شواغل مستقلة، فمن الأفضل تفكيكها. الملاءمة، والدعم الواقعي، والنبرة، والامتثال للسياسة يمكن أن تكون أسئلة منفصلة. يمكن لكود التطبيق احتساب درجة مركبة باستخدام أوزان تبقى مرئية وقابلة للاختبار.
Noul
Noul هو بدائية القرار الثنائي من TypeSafe. يقدّر احتمال أن يكون تصريح ما صحيحًا ويُرجع رقمًا من 0 إلى 1. تمثل قيمة 0.9 احتمالًا أعلى لصحة التصريح من قيمة 0.6.
لا يُرجع Noul الحقل المنفصل confidence المستخدم في Choice وScore. فخرجه في الأصل احتمال لصدق التصريح المُقيَّم. ينبغي لذلك أن يُصاغ السؤال كتصريح قابل للاختبار، مثل "الرسالة تُعبّر عن عجلة" أو "الإجابة مدعومة بالمصدر المزوَّد".
Noul مفيد للتحقق والبوابات، لكن العتبة تعود للتطبيق. قد يتحمل اقتراح واجهة منخفض المخاطر عتبة أقل من إجراء مالي أو إداري لا رجعة فيه.
أسئلة ذرّية وتراكيب سير العمل
يعمل Jev بصورة أفضل عندما يسأل كل سؤال شيئًا ضيقًا واحدًا. يجعل هذا التصميم المخرجات أسهل للفحص ويتيح للبرمجيات امتلاك السياسة النهائية.
افترض أن وكيلًا يحتاج أن يقرر ما إذا كان يجب تنفيذ استدعاء أداة. قد يجمع سؤال واسع مثل "هل يجب تشغيل هذا الإجراء" بين الإذن، والقابلية للعكس، وحساسية البيانات، ونية المستخدم، والمخاطر التشغيلية. سير عمل أكثر قابلية للفحص يُقيّم هذه الأبعاد بشكل منفصل:
- هل استدعاء الأداة متسق مع طلب المستخدم؟
- هل ينقل معلومات حسّاسة؟
- هل الإجراء مُخرّب أو يصعب التراجع عنه؟
- هل يؤثر على حساب خارجي؟
- هل تتطلب السياسة تأكيدًا إضافيًا؟
بعد ذلك يمكن لإطار التشغيل دمج الإجابات بقواعد حتمية. يمكن أن يتطلب إجراء مُخرّب تأكيدًا بغض النظر عن الثقة الكلية للنموذج. يمكن أن يتبع إجراء القراءة فقط مسارًا أقل تقييدًا. يحافظ هذا الترتيب على الأذونات في الكود ويستخدم Jev فقط للأحكام التي لا يمكن التعبير عنها بشكل موثوق كقواعد ثابتة.
Jev مقابل النماذج اللغوية التقليدية
يخدم Jev ونماذج اللغة الكبيرة أدوارًا مختلفة.
| البُعد | Jev | LLM تقليدي |
|---|---|---|
| المخرج الرئيسي | قرارات مُعلّمة النوع واحتمالات | نص مولّد، كود، أو رموز مُهيكلة |
| فضاء الإجابة | مُعرّف قبل الاستدلال | مفتوح ما لم يُقيَّد |
| التوليد/العينة | تُقيّم الأسئلة بالتوازي | تُولَّد الرموز تسلسليًا |
| عبء العمل الطبيعي | تصنيف، توجيه، إسناد درجات، تحقق | محادثة، استدلال، كتابة، ترميز |
| اللايقين | توزيعات احتمالية؛ ثقة لـ Choice وScore | يعتمد على المزوّد والطريقة |
| سلوك المخطط | المخرجات تُطابق أنواع الأسئلة المدعومة | يتطلب الإخراج المُهيكل توليدًا مُقيّد المخطط |
| أفضل دور للنظام | طبقة قرارات داخل البرمجيات | طبقة التخطيط والتوليد |
لا ينبغي وصف Jev بأنه "روبوت محادثة أصغر". لم تنشر TypeSafe عدد المعاملات أو تفاصيل معمارية كافية لتصنيف النموذج بالحجم. تمييزه العام يستند إلى هدف تدريبه وطريقة التوليد وواجهته.
كما لا يحل Jev محل الكود الحتمي. تبقى القواعد الثابتة الأداة المناسبة عندما تكون الشروط صريحة ومستقرة. لا ينبغي أن يصبح حساب ضريبي، أو قائمة أذونات، أو حد حجم ملف استدعاء نموذج احتمالي. يفيد Jev حيث تكون القواعد اليدوية هشة جدًا لكن يمكن ما يزال حصر الإجابة المرجوّة.
Jev مقابل إخراج LLM مُهيكل
يتيح الإخراج المُهيكل للنموذج اللغوي إرجاع JSON أو قيم تُطابق مخططًا. وهو مفيد حين يحتاج سير العمل إلى استدلال توليدي ونتيجة قابلة للقراءة الآلية معًا. يعالج Jev مشكلة أضيق.
مع LLM، يقيّد المخطط شكل الاستجابة المُولّدة. مع Jev، تمثل الأسئلة وفضاءات الإجابة واجهة النموذج. يُرجع Jev توزيعات احتمالية مُصمّمة للمشاركة في منطق التطبيق، وتُقيَّم الأسئلة المستقلة بشكل منفصل مقابل حالة مشتركة.
تطابق أشكال JSON لا يؤسس سلوكًا متطابقًا. قد يُرجع نظامان حقلًا باسم department كلاهما، لكن يختلفان في الكمون، والمعايرة، والتعامل مع الغموض، واستقرار الاستجابة. على الفرق التي تقارن Jev بإخراج LLM مُهيكل الحفاظ على مخطط التطبيق ثابتًا واختبار النظامين على البيانات الموسومة نفسها.
RLCD والقرارات المُعايرة
تقول TypeSafe إن Jev مُدرّب عبر التعلم المعزز من أجل قرارات مُعايرة. يختلف RLCD في الهدف عن RLHF وRLVR.
يحسّن RLHF الاستجابات باستخدام إشارات تفضيل بشرية وقد استُخدم على نطاق واسع لمساعدين محادثيين. يستخدم RLVR مكافآت قابلة للتحقق ويرتبط بالمهام التي يمكن التحقق من صحتها برمجيًا. يدرب RLCD نماذج TypeSafe على إرجاع قرارات واحتمالات مُعايرة بدلًا من نص مولّد.
تتعلق المعايرة بمجموعات التنبؤات. إذا كان النموذج مُعايرًا جيدًا، فينبغي أن تكون النتائج المُسنَدة باحتمال قريب من 0.8 صحيحة حوالي 80 بالمئة من الوقت عبر مجموعة مناسبة من الحالات. لا يضمن ذلك أن يكون تنبؤ بعينه باحتمال 0.8 صحيحًا.
لا ينبغي معاملة الاحتمال والثقة على أنهما قابلان للاستبدال. تعرض Choice وScore توزيعات احتمالية كاملة. تستمد TypeSafe الثقة من شكل كل توزيع. يفضي توزيع مُتركّز على خيار واحد إلى ثقة أعلى؛ بينما يشير توزيع مسطّح إلى غموض. يمكن للفرق استخدام الثقة المقدمة أو حساب إحصائية أخرى من الاحتمالات.
لا يحتوي Noul على حقل ثقة منفصل. فقيمته هي الاحتمال المُقدّر لصدق التصريح.
مواصفات نموذج Jev وتسعيره
التفاصيل التالية مأخوذة من وثائق نموذج TypeSafe الرسمية التي تمت مراجعتها في 21 سبتمبر 2026.
| البند | القيمة الموثّقة رسميًا |
|---|---|
| النموذج المستقر الحالي | Jev 1.13 |
| معرّف النموذج المُرقّم | jev-1.13.0 |
| الاسم المستقر المستعار | jev-latest |
| الإدخال | نص؛ سلسلة، كائن JSON، أو مصفوفة قيم نصية |
| حد سياق الطلب | 64,000 رمز عبر الحالة وجميع الأسئلة |
| قاعدة سياق إضافي | 32,000 رمز للحالة إضافة إلى أطول سؤال |
| سعر الإدخال | $0.042 لكل مليون رمز، أو $42 لكل مليار رمز |
| سعر الإخراج | مجاني |
| حدود المعدل المنشورة | 250,000 رمزًا في الثانية و1,200 طلب في الدقيقة |
| لغة التدريب الأساسية | الإنجليزية |
| إدخال غير نصي | غير مدعوم مباشرة |
تشير TypeSafe إلى أن حدود المعدّل تتعدل ديناميكيًا وقد تتغير دون إشعار. ينبغي التحقق من الحدود والأسعار الحالية قبل النشر الإنتاجي.
وتذكر الوثائق أيضًا أن الإنجليزية هي لغة التدريب الأساسية وتوفر أفضل دقة حاليًا. اللغات الأخرى، بما فيها نصوص الصينية واليابانية والكورية، مدعومة ولكن ليس بنفس الجودة. ينبغي تقييم مهام الصينية أو اليابانية أو الكورية على بيانات ممثلة قبل تمكين القرارات الآلية.
تقول TypeSafe إن Jev ليس مُضبطًا بدقة أو مُكيَّفًا باستخدام LoRA لكل عميل على حدة. تخدم أوزان النموذج نفسها كل حساب. يتشكل سلوك المجال عبر الحالة، والتعليمات، والمعايير، والتركيب على جانب التطبيق. وتذكر الشركة أيضًا أن طلبات العملاء واستجاباتهم لا تُستخدم لتدريب Jev. يمكن لعملاء المؤسسات الرجوع إلى مستندات TypeSafe القانونية لشروط عدم الاحتفاظ بالبيانات.
ما مدى سرعة Jev؟
تُبلغ TypeSafe عن أزمنة استجابة شاملة من 70 إلى 500 مللي ثانية. يقارن منشور الإطلاق هذا النطاق بـ 3 إلى 329 ثانية لاتصالات مختارة مع نماذج متقدمة رائدة، ويصف Jev بأنه أسرع 40 إلى 200 مرة عند مستويات ذكاء قابلة للمقارنة في استفسارات بهيئة System One.
وتبلغ الشركة أيضًا عن مكاسب قصوى قدرها 193.6 مرة في السرعة و444.6 مرة في التكلفة على تقييمات تدفّقات عملها. تتطلب هذه الأرقام سياقًا.
فهي تأتي من إطار التقييم الخاص بـ TypeSafe. تقارن تدفّقات العمل النماذج على رسوم قرارات مُهيكلة وتستخدم متوسط توقعات نماذج خارجية متقدمة مختارة كاحتمالات مرجعية. تقول TypeSafe إن المكاسب المُبلغ عنها تُحتمل أن تكون قريبة من الحد الأعلى للتحسينات الواقعية وتُقر بإمكانية التحيز لأن أعضاء فريق قدرات النموذج لديهم أنشأوا هذه التدفقات.
لا ينبغي قراءة هذه النتائج على أنها ادعاء عام بأن Jev أسرع بمئات المرات من كل LLM في كل مهمة. يتخلى Jev عن توليد النص ويستهدف قرارات محصورة. ينبغي أن تستخدم المقارنة العادلة مهامًا يمكن للنظامين القيام بها، وأن تقيس جودة القرار بالإضافة إلى الكمون، وأن تشمل تكلفة التحقق، وإعادة المحاولة، والمراجعة البشرية.
أفضل استخدامات Jev
Jev مناسب بشكل أفضل لتدفّقات العمل عالية الحجم ذات فضاء إجابة مُعرّف وحاجة لتقديرات عدم اليقين.
- دعم العملاء وتوجيه التذاكر: تصنيف التذكرة حسب القسم، والعجلة، والإحباط، ومخاطر التخلي، أو الحاجة إلى مراجعة بشرية.
- توجيه النية والنموذج: تحديد نوع الطلب وتوجيهه إلى الأداة أو سير العمل أو الوكيل أو النموذج المناسب. يمكن أن تحدد الثقة ما إذا كان التوجيه تلقائيًا.
- فحوص مخاطر أدوات الوكيل: تقييم استدعاءات الأدوات المقترحة بحثًا عن الإجراءات المُخرّبة أو البيانات الحسّاسة أو عدم الاتساق مع طلب المستخدم قبل التنفيذ. يبقى كود التطبيق مسؤولًا عن الأذونات.
- تقييم مخرجات LLM: التحقق مما إذا كان رد LLM مدعومًا بالسياق المقدم، ويتبع التنسيق المطلوب، أو يحتاج إلى مراجعة بشرية.
- مراقبة المحتوى: استخدم Choice لفئات السياسة، وScore للشدة، وNoul للتحقق من القواعد الثنائية. يمكن إرسال الحالات منخفضة الثقة إلى المُشرفين.
- معالجة البيانات عالية الحجم: معالجة السجلات أو الرسائل أو المراجعات أو العملاء المحتملين أو الإعلانات أو مقاطع المستندات عندما يمكن تقييم كل سجل بشكل مستقل ويكون الإخراج فئة أو درجة أو احتمالًا.
موضع Jev ضمن وكيل ذكاء اصطناعي
عادة ما يجمع وكيل الذكاء الاصطناعي بين نموذج توليدي، وأدوات، وحالة تطبيق، وقواعد تتحكم في التنفيذ. يلائم Jev هذا النظام كطبقة قرارات مُهيكلة حول النموذج التوليدي الرئيسي.
يمكن للنموذج التوليدي التعامل مع المهام المفتوحة مثل تفسير الطلب، وتخطيط سير العمل، وكتابة المحتوى، أو توليد الكود. يمكن لـ Jev التعامل مع قرارات أضيق يجب أن تحدث بشكل متكرر أثناء سير العمل:
- أي أداة أو نموذج يجب استخدامه؟
- هل الإجراء المقترح محفوف بالمخاطر أو غير متسق مع الطلب؟
- هل يجب على الوكيل المتابعة أو إعادة المحاولة أو التوقف أو طلب توضيح؟
- هل تستوفي النتيجة متطلبًا محددًا؟
- هل ينبغي تصعيد المهمة إلى إنسان؟
يبقى التطبيق مسؤولًا عن الأذونات والعتبات والآثار الجانبية. يقدّم Jev قرارًا واحتماله المرتبط، بينما يحدد كود التطبيق ما الذي يلي ذلك.
يخلق هذا تقسيمًا للمسؤوليات. تتعامل النماذج التوليدية مع الاستدلال المفتوح، ويتعامل Jev مع التقييمات المحصورة، ويُطبّق الكود الحتمي السياسة، وتنفذ الأدوات الإجراءات الخارجية. لذا يعمل Jev مكملًا لوكيل الذكاء الاصطناعي بدلًا من أن يحل محل نموذج الاستدلال الرئيسي لديه.
قيود Jev
لا يُولّد Jev نثرًا أو كودًا أو شروحًا مفتوحة. إنه مُصمّم لأسئلة مركّزة ذات فضاءات إجابة مُعرّفة.
ما يزال بالإمكان أن يحتوي الرد الآمن النوعًا على قرار غير صحيح، لذا يجب تقييم دقة الأعمال ببيانات حقيقية. النص هو صيغة الإدخال المدعومة حاليًا، وتوفر الإنجليزية أقوى أداء موثق. تتطلب اللغات الأخرى اختبارات منفصلة.
تأتي نتائج سرعة Jev وتكلفته من تقييمات TypeSafe الخاصة، ولا ينبغي معاملتها كضمانات أداء عامة.
Jev وCometAPI
وقت المراجعة في 21 سبتمبر 2026، لم يكن Jev مدرجًا كنموذج متاح عمومًا في كتالوج CometAPI العام. تخطط CometAPI لتقييم ودمج Jev بمجرد توفر الوصول وفتح الاتصال المطلوب. يجب على المطورين التحقق من دليل نماذج CometAPI لأحدث حالة التوافر.
يمكن الوصول إلى Jev حاليًا عبر وحدة تحكم TypeSafe وواجهة البرمجة الرسمية. كما توفر TypeSafe حِزم SDKs رسمية للغات Python وJavaScript. تستخدم واجهة البرمجة الحالية state وأسئلة مُحددة النوع questions، مع اعتبار jev-latest الاسم المستقر المستعار.
بمجرد أن يصبح Jev متاحًا عبر CometAPI، سيتمكن المطورون من العثور على معرّف النموذج، ونقطة النهاية المدعومة، والتسعير، وتنسيق الطلب في وثائق API الخاصة بـ CometAPI ودليل النماذج.
الأسئلة الشائعة
ما هو Jev AI؟
Jev هو النموذج الرائد لدى TypeSafe وأول نموذج System One لديها. يقيّم حالة نصية مقابل أسئلة مُحددة النوع ويُرجع قرارات مُهيكلة واحتمالات بدلًا من نص مولّد.
هل Jev نموذج لغة كبير؟
لا تقدّم TypeSafe Jev كنموذج LLM تقليدي. تصفه كنموذج System One مبني للقرارات المُهيكلة. لم تنشر الشركة عدد المعاملات، لذا لا ينبغي تصنيف النموذج كبيرًا أو صغيرًا بناءً على المعلومات العامة.
ما هي Choice وScore وNoul؟
تختار Choice خيارًا من مجموعة مُعرّفة وتُرجع احتمالات + ثقة. تقيّم Score الحالة على سُلّم مُرتّب وتُرجع أيضًا احتمالات + ثقة. تُرجع Noul قيمة من 0 إلى 1 تمثل احتمال أن يكون التصريح صحيحًا.
هل يُولّد Jev نصًا أو كودًا؟
لا. يُرجع Jev قرارات مقيّدة. يتطلب سير العمل نموذجًا توليديًا عندما يحتاج إلى نثر أو حوار أو شفرة مصدرية أو شرح مفتوح.
هل يمكن لـ Jev أن يحل محل GPT أو Claude أو Gemini؟
لا. يتناول Jev مهام القرارات المحصورة، بينما تتعامل النماذج العامة مع التوليد والاستدلال المطوّل. يمكن لنظام إنتاجي استخدام كلا النوعين في مراحل مختلفة من سير العمل نفسه.
هل يدعم Jev الصور أو الصوت أو الفيديو؟
ليس مباشرة. يقبل النموذج الحالي النص كسلسلة أو كائن JSON أو مصفوفة قيم نصية. يجب تحويل المدخلات غير النصية إلى نص أو حقول مُهيكلة أولًا.
هل تضمن المخرجات الآمنة النوعًا قرارًا صحيحًا؟
لا. تضمن آمنة النوع أن المخرج يطابق البنية المدعومة. ما يزال Jev قادرًا على اختيار خيار صحيح البنية لكنه غير صحيح فعليًا أو إسناد احتمال غير دقيق. يجب قياس دقة الأعمال على بيانات ممثلة.
هل Jev مفتوح المصدر؟
لم تُصدر TypeSafe أوزان نموذج Jev علنًا. تنشر الشركة وثائق وSDKs وأمثلة وأكواد تكامل ذات صلة، لكن هذه الموارد لا تجعل النموذج نفسه مفتوح الأوزان.
الخلاصة
يقدم Jev واجهة نموذج مبنية حول القرارات بدلًا من توليد اللغة. يقبل حالة مشتركة وأسئلة ذرّية مُحددة النوع، ثم يُرجع فئات ودرجات واحتمالات ثنائية ومقاييس عدم يقين يمكن للبرمجيات استخدامها مباشرة.
دوره الأكثر مصداقية ليس استبدال النماذج العامة. بل تولّي الأحكام المتكررة والمحصورة حولها. توجيه دعم العملاء، اختيار النموذج، فحوص مخاطر الأدوات، التحقق من المخرجات، الإشراف، وتصنيف تدفّقات العمل كلها تلائم هذا النمط عندما يكون فضاء الإجابة مُعرّفًا مسبقًا.
تعتمد القيمة الإنتاجية على أكثر من الكمون المنخفض أو مخطط صالح. تحتاج الفرق إلى تقييمات ممثلة، وعتبات مُعايرة، وقواعد أذونات صريحة، وضوابط لإصدار النماذج، ومسارات مراجعة بشرية. تجعل أرقام السرعة والتكلفة المنشورة من TypeSafe Jev جديرًا بالاختبار للأعباء كثيفة القرارات، لكن تبقى الادعاءات مرتبطة بطريقة تقييم الشركة ويجب التحقق منها على بيانات تطبيق حقيقية.
بالنسبة للفرق التي تستخدم بالفعل عدة نماذج توليدية عبر CometAPI، يجسّد Jev معمارية أوسع تكون فيها التوليد، والحكم الاحتمالي، والسياسة الحتمية، وتنفيذ الأدوات مكونات منفصلة. يجعل هذا الفصل كل جزء أسهل للاختبار ويمنح كود التطبيق التحكم النهائي في ما يحدث تالياً.