Jev 1.13 موضّحًا: لماذا يجيب النموذج بتسميات بدلًا من الجمل

Jev 1.13 (typesafe/jev-1.13) ليس نموذج محادثة، وأسرع طريقة لفهمه هي أن تتوقف عن قراءة ورقة مواصفاته بالطريقة التي تقرأ بها كل ورقة أخرى. أطلقته TypeSafe في 2026-09-15 كأول عضو في فئة تسميها الشركة نماذج System One: تسلّمها قطعة من الحالة ومجموعة من الأسئلة المسمّاة، فتعيد لك إجابة مُنمّطة واحدة لكل سؤال — تصنيفًا من قائمة قدّمتها، أو مستوى على مقياس حدّدته، أو صحيحًا/خطأ مع احتمال مرفق. لا نثر، لا شيفرة، لا شرح. هذه ليست مقالة إطلاق. النموذج نفسه من 2026-09-15، عمره خمسة عشر يومًا وهو خارج نافذة السبعة أيام التي تكتب هذه المدونة ضمنها، لذا لا يستحق صفحة عند إطلاقه بذاته. ما حدث داخل النافذة هو أن OrcaRouter أضاف typesafe/jev-1.13 إلى كتالوجه الخاص في 2026-09-24 وفتح بطاقة نموذج Jev 1.13 على https://www.orcarouter.ai/models/typesafe/jev-1.13 — أول مرة يصبح فيها Jev قابلًا للاستدعاء عبر بوابة طرف ثالث بدلًا من نقطة نهاية TypeSafe وحدها، وأول بيانات خدمة حيّة ينشرها أي شخص خارج TypeSafe عنه. هذا هو التغيير الجدير بالقراءة: أصبح النموذج قابلًا للتشغيل حيث لم يكن.

الشكل العملي لهذا التغيير صغير ومحدد. قبل 2026-09-24، كان تبنّي Jev يعني علاقة مع مورّد ثانٍ — حساب TypeSafe، ومفتاح TypeSafe، وفاتورة TypeSafe، وشكل طلب مخصّص للكتابة مقابله. بعده، يقع Jev على المفتاح نفسه الذي تستخدمه بقية المنظومة: واجهة برمجة تطبيقات واحدة تدعم أكثر من 200 نموذج، بهامش ربح 0% (سعر قائمة المزوّد يُمرَّر كما هو، لذا تسري تخفيضات أسعار المورّدين هنا في اليوم نفسه)، والنموذج متاح على typesafe/jev-1.13 عبر POST /v1/systemone. ما زلت تستدعيه بشكله الخاص — فنقطة النهاية ليست مسار OpenAI chat-completions، وافتراض غير ذلك سيُنتج 404 بدلاً من قرار — لكن العقد الذي توقّعه والمفتاح الذي تدوّره هما نفسهما اللذان لديك بالفعل.

ما نوع الموديل الذي يمثله Jev؟

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

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

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

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

"Typed" هو المنتج بأكمله

تنشر بطاقة نموذج OrcaRouter ثلاث بدائيات، والأهم من ذلك، الحدود المفروضة على كل منها. كل سؤال تطرحه على Jev هو واحد من ثلاثة أشكال بالضبط:

• noul — حكم صواب/خطأ، يُعاد مع احتمالية معايَرة بدلًا من قيمة منطقية خام، بحيث تكون "صواب على الأرجح" و"صواب بالتأكيد" قيمتين قابلتين للتمييز.

• {{1}}choice{{/1}} — اختر واحدًا من ما يصل إلى 255 خيارًا مُسمّى، {{2}}كل خيار يحمل نص {{3}}المعايير{{/3}} الخاص به حتى يعرف النموذج ما يميّز تسمياتك.{{/2}}

• {{1}}النتيجة{{/1}} — قيّم على مقياس مُرتَّب من {{2}}2–10{{/2}} مستويات، مع تعريفات المستويات المقدمة كمعايير.

نتيجة هذا القيد هي أنه لا يوجد شيء يمكن استخراجه من النثر، ولا شيء يمكن التحقق منه مقابل مخطط كنت تأمل أن يتبعه النموذج. منشور إطلاق TypeSafe مباشر بشكل غير معتاد بشأن الضمان: رقم عدم تطابق المخطط «0%» في رسومه البيانية «ليس تجريبيًا. مطابقة المخطط مضمونة، لذا يمكننا أن نضيف بثقة 0% إلى الرسوم البيانية». عندما تكون مساحة إجابتك مجموعة مغلقة زوّدتها أنت، فإن القيمة المُعادة إما أن تكون داخل المجموعة أو أنها لم تأتِ من النموذج — فلا توجد نتيجة ثالثة يكتب فيها النموذج شيئًا معقولًا في شكل خاطئ ثم يقبله تعبيرك النمطي (regex) بصمت.

الأنواع الثلاثة هي أيضًا السبب في أن المراجع لا يستطيع تقييم Jev بالطريقة التي يقيّم بها نموذج دردشة. فلا توجد نتيجة MMLU-Pro للمقارنة، ولا عيّنة كتابة لقراءتها، ولا مسار استدلال لفحصه. والسؤال الوحيد الذي له معنى هو ما إذا كانت الإجابة المكتوبة صحيحة، وما إذا كان الاحتمال المرتبط بها صادقًا. وكلاهما قابل للقياس، لكن فقط مقابل بياناتك وتسمياتك.

هناك اختلاف موثّق جدير بالإشارة إليه بدلًا من تسويته: تُظهر وثائق TypeSafe الخاصة مثالًا على Score مُفهرَسًا بدءًا من الصفر، بينما تنشر بطاقة OrcaRouter المقياس على هيئة 2–10 مستويات. المورّد يوثّق المستويات؛ أما بطاقتنا فتنشر 2–10. إذا كنت تبني معيارًا تقييميًا فوق Score، فاقرأ تعريفات المستويات في استجابتك الخاصة بدلًا من افتراض فهرس.

لماذا لا توجد رموز إخراج لفوترتها؟

التسعير هو أنقى تعبير عن المعمارية. يكلّف Jev مبلغ $0.042 لكل مليون رمز إدخال على OrcaRouter، أما سعر الإخراج فهو $0.000000 لكل مليون — ليس خصمًا ولا عرضًا ترويجيًا للإطلاق، بل غياب كمية قابلة للقياس. يُحاسَب النموذج التوليدي على النص الذي يكتبه؛ أما Jev فلا يكتب أي نص. إنه يعيد وسمًا ومستوى واحتمالًا. لا يوجد ما يمكن عدّه في جانب الإخراج، لذلك لا يُفرض هناك أي رسم.

يذكر TypeSafe الرقم نفسه من الاتجاه المعاكس على صفحته الرئيسية — «42 دولارًا لكل مليار رمز إدخال» — ويضيف إليه ادعاء مقارنة: «سعر الإدخال أقل بمقدار 238 مرة من Claude Fable 5.1». تلك المقارنة، مثل كل شيء آخر على الصفحة الرئيسية، هي ادعاء البائع نفسه، ولم يكرره أحد. لكن الحساب الذي تقوم عليه سهل على القارئ أن يتحقق منه مقابل فاتورته الخاصة، وهذا هو الجزء المفيد. إن حجم عبء عمل اتخاذ القرار يتحدد بالكامل تقريبًا بمقدار الحالة التي تُدخلها، والحالة رخيصة على نحو لا تكون عليه الرموز المولَّدة.

الأرقام الرئيسية للمورّد أكبر من سطر السعر وتستحق التوسيم نفسه. تعلن TypeSafe عن «أسرع بـ193.6x، وأرخص بـ444.6x» مع حاشية تقصر ذلك على «سير العمل الخاصة بمهام System One»، وتنشر مثالًا محلولًا أسفله: TypeSafe AI بتكلفة $0.000081 أكمل المهمة في 0.114 ثانية مقابل نماذج اللغة الكبيرة بتكلفة $0.013880 أكملت في 8.566 ثانية. ويعترف منشور الإطلاق نفسه بمخاطر التأطير — إذ يُوصف الرقمان 193.6x و444.6x بأنهما يقعان على الأرجح «في الطرف الأعلى من المكاسب الواقعية» — ويشير إلى أن العرض التوضيحي المقارن جنبًا إلى جنب استخدم استعلامًا «مبسطًا للغاية» بمفاتيح قابلة للقراءة البشرية اختارها المورّد لكي «يُظهر نموذجنا في ضوء مؤاتٍ». لم يُعِد أحد إنتاج أي من هذه الأرقام بشكل مستقل، ولا تزال بطاقة المعايير الخاصة بالمورّد نفسه تحمل علامة «قيد الانتظار».

ما معنى "calibrated"، وما هو RLCD؟

تسمّي TypeSafe طريقة تدريبها بنفسها: "Reinforcement Learning for Calibrated Decisions (RLCD)". إن RLCD مصطلح خاص بـ TypeSafe، وليس اختصارًا عامًا في تعلّم الآلة يسبق الشركة، ويُذكر هدف تحسينه في جدول المقارنة في منشور الإطلاق على أنه "قرارات معايَرة: إجابات باحتمالات صادقة معرفيًا في مهام System One". التباين الذي يرسمه الجدول نفسه هو مع RLHF، الذي يحسّن من أجل التفضيل البشري — الكتابات واستجابات الدردشة التي يفضّلها المقيّمون — وRLVR، الذي يحسّن من أجل مخرجات يمكن التحقق منها برمجيًا. يحسّن RLCD من أجل أمر ثالث: الاحتمال المرفق بكون الإجابة بيانًا دقيقًا لعدم يقين النموذج نفسه.

عملياً، إنّ "المعايَر" ادّعاء عن درجات الثقة، وليس ضماناً بأن الإجابات صحيحة. النموذج المعايَر الذي يقول 0.8 على مجموعة من الأسئلة ينبغي أن يكون مصيباً نحو 80% من الوقت عبر تلك المجموعة؛ لكنه قد يظل مخطئاً في أي سؤال فردي منها. هذا التمييز هو الطريقة الصادقة لقراءة سطر الصفحة الرئيسية لـ TypeSafe: "صفر هلوسات — كل قرار Jev يأتي مع تقدير ثقة، بحيث يمكن لبرمجتك أن تتصرف عندما تكون الثقة عالية وأن تُصعّد عندما لا تكون كذلك." إنه ادّعاء تقدير ثقة، وليس دليلاً على انعدام الأخطاء، والثقل الموازن هو بياناتنا نحن: على مدى الأيام السبعة المنتهية في 2026-09-30، تقيس بطاقتنا معدل خطأ 0.49% على حركة Jev عبر OrcaRouter — وهو رقم كان قد بلغ 0.57% في وقت سابق من النافذة نفسها، لأنه يُحتسب على مدى سبعة أيام متدحرجة من حركة مرور حية في ساحة التجربة بدلاً من مجموعة اختبار ثابتة. تنتمي الحقيقتان معاً إلى الفقرة نفسها: فدرجات الثقة هي جوهر النموذج، ومع ذلك يظل النموذج يفشل في نحو استدعاء واحد من كل مئتي استدعاء على حركة المرور لدينا.

قصة المعايرة تشرح أيضًا سلوكًا في زمن الاستجابة كان سيبدو لولا ذلك كخلل. يقول منشور إطلاق TypeSafe: "بالنسبة للخيارات ذات التعددية الأعلى، نعتمد نظامًا من مرحلتين: التقييم بشكل مستقل ثم اتخاذ اختيار صريح، ومن هنا يحدث التباطؤ العرضي." اختيار من 255 خيارًا ليس مقارنة أمامية واحدة؛ إذ يقوم المورّد بالتقييم ثم يختار. إذا رأيت طلبًا على مجموعة تسميات كبيرة يستغرق وقتًا أطول بشكل ملحوظ من noul، فهذه هي الآلية الموثقة، وليست ازدحامًا.

كيف تسميه اليوم؟

على OrcaRouter، النموذج هو typesafe/jev-1.13، واسمه "TypeSafe: Jev 1.13" في الكتالوج، بطول سياق context_length يبلغ 65,536 توكنًا ونوع نقطة نهاية واحد مدعوم فقط: systemone. تستدعيه عبر POST /v1/systemone باستخدام مفتاح OrcaRouter الخاص بك، وترسل حقل model، وحقل state (سلسلة نصية أو كائن أو مصفوفة)، وخريطة questions يحمل كل مدخل فيها نوعًا (noul أو choice أو score)، وتعليماته، ومعاييره. الاستجابات هي حمولة JSON واحدة منظمة ولا تُبثّ تدفقيًا — لا يوجد وضع بث للاشتراك فيه.

صياغة البطاقة نفسها للعقد هي "نص مُدخل، JSON منظم مُخرج"، والحدود المنشورة هي التي يجب التصميم وفقًا لها: غير متدفق، حتى حوالي 64 ألف رمز إدخال عبر الحالة والأسئلة المجمعة، مع رفض الطلبات التي تتجاوز هذا الحد قبل وصولها إلى النموذج. يُدرج إدخال الكتالوج سعر القائمة على أنه 0.042 دولار لكل مليون رمز إدخال ويُظهر معدل الإكمال كصفر. تلك هي أرقام البائع التي تم تمريرها دون تغيير — الشكل التناسبي لكيفية تسعيرنا: هامش ربح 0% على أسعار قائمة المزود.

تنتشر ميزانيتان للتوكنات لهذا النموذج، وهما ليستا في تعارض، لذا افصل بينهما. الرقم 65,536 هو context_length الخاص بالبطاقة، وموثّق بأنه نحو 64K من الإدخال عبر الحالة والأسئلة مجتمعة. أما «نحو 32,000 توكن» الذي اقتبسته مقالات OrcaRouter السابقة، فهو ميزانية الحالة وحدها — أي المساحة التي تحصل عليها مادتك قبل أن تأخذ الأسئلة نصيبها. إذا كنت تضع ميزانية لطلب، فإن ميزانية الحالة هي الرقم الذي يقيّد الحمولة التي تبنيها؛ أما الرقم المجمّع فهو السقف للاستدعاء بأكمله.

ما لا يستطيع Jev فعله، بصراحة.

لا يمكنه كتابة النثر، أو التلخيص، أو الترجمة، أو المحاورة. هذا هو التصميم، وليس قيدًا ينبغي الاعتذار عنه: يقول منشور الإطلاق إن Jev "يتخلى عن توليد السلاسل"، وتُدرج صفحة TypeSafe الخاصة بـ jaggedness "التوليد" كوضع فشل مُسمّى مع تعليمات "استخدم نموذجًا توليديًا" بجانبه. التوليد القسري بطيء وضعيف. إذا كانت خط أنابيبك تحتاج إلى ملخص مكتوب، فإن Jev هو المكوّن الخاطئ، ولا تغيّر ذلك أي كمية من براعة صياغة المطالبات.

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

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

قراءة الأرقام بصدق

كل رقم من أرقام الخدمة على بطاقتنا يأتي من حركة المرور الخاصة بنا عبر بيئة OrcaRouter التجريبية خلال نافذة متدحرجة مدتها سبعة أيام، وليس من معيار البائع، وقد تحركت النافذة أثناء كتابة هذا المقال — فاعتبر ذلك قراءةً لا مواصفة. بالنسبة للأيام السبعة المنتهية في 2026-09-30: وسيط الزمن اللازم للوصول إلى أول رمز 151 مللي ثانية، وp95 عند 247 مللي ثانية، وإنتاجية المخرجات نحو 349 رمزًا في الثانية، ومعدل الأخطاء 0.49%، وتم تقديم 76.2 مليون رمز. وتأتي قيم p50 اليومية عبر النافذة على النحو الآتي: 175، و170، و163، و161، و170، و147، و143 مللي ثانية — خط يتحسّن برفق. إن قيمة p95 ليوم 09-28 البالغة 2,448 مللي ثانية هي قيمة شاذة حقيقية في يوم واحد تقع داخل تلك السلسلة، والاستشهاد بها كقاعدة سيكون خطأً بالطريقة نفسها التي سيكون فيها حذفها بالكامل غير أمين.

تحذير إضافي بشأن رقم حركة البيانات: تبدو 349 من رموز الإخراج في الثانية وكأنها معدل إنتاجية نموذج توليدي، حتى تتذكر أن Jev لا ينتج أي نص مُولَّد. العداد يقيس ما تحتسبه منصة التجارب لدينا على جانب الاستجابة لحمولة منظمة، وهو مفيد لرصد التدهور بين يوم وآخر بدلًا من مقارنة Jev بنموذج محادثة.

هذه هي أرقامنا. أما أرقام المورّد فهي 193.6x، و444.6x، والمثال العملي بقيمة $0.000081، ومقارنة 238x مع Claude Fable 5.1 — وكلها خاصة بـ TypeSafe، ولم يُكرّر أي منها بشكل مستقل، وكلها مقيّدة بموجب حواشيها الخاصة بسير مهام System One على وجه التحديد. إن ادعاء الأداء الوحيد الذي يقدّمه TypeSafe، والذي ليس معيار قياس على الإطلاق، ويستحق أكثر من المضاعفات، هو ادعاء بنيوي: لأن الإجابات محددة الأنواع، فإن التكامل لا يحتوي على خطوة تحليل ولا خطوة تحقق من المخطط، وهذه تكلفة لا تظهر في أي جدول زمن استجابة.

ما هو المفتوح، وما هو غير المفتوح؟

تم التحقق في 2026-09-30، ونشرت مؤسسة TypeSafe على GitHub أحد عشر مستودعًا. لا يحتوي أيٌّ منها على Jev. أما تلك التي تهم المطوّر الذي يدمج النموذج فهي جميعها بترخيص MIT أو Apache-2.0: skills ‏(MIT)، وsystem-one-adapter-python ‏(MIT، وُصِف بأنه «بديل مباشر لـ TypeSafeClient مدعوم بواجهات برمجة تطبيقات LLM»)، وtypesafe-sdk-js ‏(MIT)، وtypesafe-sdk-python ‏(MIT)، وdaggerverse ‏(Apache-2.0)، وWorkflowEvals ‏(Apache-2.0، مع نشر كود سير العمل على evals.typesafe.ai)، وn8n-nodes-typesafe-ai ‏(MIT)، وtypesafe-ai.github.io وpulumi-clickhouse. تتغير أعداد النجوم وتواريخ الدفع، لذا إذا كنت تقرأ هذا لاحقًا، فأعد التحقق بدلًا من الوثوق بالقائمة.

ثلاثة من الأحد عشر هي تفريعات (forks) لمشاريع غير ذات صلة ولا تُثبت شيئًا عن كيفية عمل Jev: تفريع vLLM كان آخر دفع له في مايو 2025، وتفريع LLaDA من يونيو 2025 — وLLaDA هو إصدار لنموذج لغة انتشاري غير ذي صلة — ومزوّد Pulumi لـ ClickHouse Cloud. من المُغري استنتاج البنية من قائمة التفريعات. لا تفعل ذلك: لا شيء يخص تصميم Jev يمكن استنتاجه من تلك الثلاثة، وعلى وجه الخصوص فإن Jev ليس نموذج انتشار، مهما كان وجود تفريع LLaDA قد يوحي بذلك.

الإجابة الصادقة في سطر واحد عن سؤال «هل Jev مفتوح المصدر؟» هي أن الأدوات مفتوحة أما النموذج فليس كذلك. وهذا ترتيب طبيعي لنموذج حدودي مستضاف، وهو الترتيب الذي ينبغي أن تفترضه عندما تخطط بناءً على Jev: واجهة برمجة تطبيقات بسعر معلن، وعقد موثّق، وعدد معاملات غير معلن.

حيث يقول البائع إن Jev غير موثوق

تنشر TypeSafe صفحتها الخاصة عن التفاوت في الأداء الخاصة بـ jev-1.13، وآخر مراجعة في 2026-09-17، وتسمّي المواضع التي يفشل فيها النموذج. وهي صريحة على نحو غير معتاد، وهي المكان المناسب لبدء قسم القيود، لأنها قائمة المورّد نفسه لا قائمة منافس:

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

• الرياضيات والأرقام — ليست آلة حاسبة، ولا تعدّ بشكل موثوق. أبقِ العمليات الحسابية في التعليمات البرمجية.

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

• الإشارة غير المباشرة — النفي المزدوج والاستدلال متعدد الخطوات يقللان الدقة. قلّل الخطوات وأشِر إلى الحالة ذات الصلة.

• حالة كبيرة مليئة بتفاصيل غير ذات صلة — المحتوى غير المرتبط يعمل كمُشتِّت، وتنخفض الدقة مع نمو الحالة. صفِّ أولًا.

• المحتوى العدائي — لا تُعامل الحالة كعدائية، لذا يمكن أن تؤدي التعليمات المُدسّة أو الصياغة المضللة إلى تغيير الإجابات.

• تعليمات ومعايير متناقضة — عندما يطلب الاثنان أشياء مختلفة، قد "يرتبك" النموذج.

• الثوابت البنيوية البديهية — ليس مضمونًا أن يكون P(noul) و‏1 − P(not noul) متسقين. اسأل عن كل قرار بطريقة واحدة، وافرض المتطابقات في الكود.

• التوليد — سبق تغطيته، ونصيحة المورّد نفسه هي استخدام نموذج توليدي.

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

ما الذي يلتزم به منشور الإطلاق، وما الذي لا يلتزم به

تكاد كل دعوى من دعاوى المورّد المقتبَسة في هذا المقال تعود إلى صفحة واحدة: إعلان TypeSafe نفسه، المُدرَج تحت أخبار الشركة والمؤرَّخ 2026-09-15، والموقَّع من المؤسِّس Diogo Almeida. وقراءته مباشرةً تستحق الدقيقتين، لأن صياغة سطر واحد منه تُرسي الشروط على كل ما جاء بعده. «نموذجنا العام الأول هو Jev، وهو متاح اليوم في وصول مبكر.» والوصول المبكر هو وصف المورّد نفسه لإتاحة النموذج على منصته الخاصة، وهو بيان أضيق مما يبدو — فهو يُلزم TypeSafe بتقديم النموذج إلى مستخدمين معتمدين، ولا يقول شيئًا عن أي جهة أخرى يجوز لها تقديمه. وهذه بالتحديد هي الفجوة التي سدّتها إضافة الكتالوج بتاريخ 2026-09-24، وهي السبب في أن بطاقة النموذج تكتسب أهمية أكبر من المنشور بالنسبة لأي شخص يقيّم Jev اليوم.

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

الأسئلة التي تطرحها هذه الواجهة

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

هل يعني سياق الـ 65,536 رمزًا أن هناك 65,536 رمزًا من الحالة؟ لا. الميزانية المنشورة تبلغ نحو 64 ألف رمز إجمالًا عبر الحالة وجميع الأسئلة معًا، ورقم "نحو 32,000 رمز" الذي يظهر في تغطية أقدم هو ميزانية الحالة وحدها. احسب حمولتك وفقًا لرقم الحالة، لا الرقم المجمّع، وتذكّر أن الطلبات التي تتجاوز الحد تُرفض قبل الوصول إلى النموذج.

ماذا نفعل بهذا؟

يستحق Jev 1.13 إلقاء نظرة عليه لسبب واحد محدد، لا لسبب عام. إذا كانت لديك خطوة في مسار المعالجة لديك تمثّل حالياً نموذج محادثة يُطلب منه إرجاع وسم، ويُفترض أنه يعيده بالشكل الصحيح — مثل موجه، أو مُقيّم، أو فحص سياسات، أو درجة مقياس تقييم تُطبّق على آلاف السجلات — فإن هذه الخطوة هي ما يستبدله هذا النموذج، بتكلفة 0.042 دولار لكل مليون رمز إدخال، مع عدم احتساب أي شيء على جانب الإخراج. أما إذا كانت لديك خطوة تحتاج إلى إجابة مكتوبة، فإن Jev ليس الأداة المناسبة، ويقول مورّد Jev نفسه ذلك.

الشيء الذي تغيّر في الأسبوع الماضي ليس النموذج. بل إن تجربته لم تعد تتطلب علاقة مع مورّد ثانٍ. قبل ثمانية أيام، كان تقييم Jev يعني حسابًا منفصلًا وتكاملًا منفصلًا؛ أما اليوم فهو مجرّد مُعرّف نموذج واحد على مفتاح يصل بالفعل إلى أكثر من 200 نموذج، مع تمرير سعر القائمة الخاص بالمورّد دون تغيير، وتأتي الإجابات المكتوبة من المكان نفسه الذي يأتي منه كل شيء آخر. وبالنسبة لنموذج بهذه الغرابة، فإن القدرة على اختباره مقابل تسمياتك الخاصة دون الالتزام بعقد جديد تمثل الجزء الأكبر من القرار.