Jev ما بقى براهو. تختار ياتو موديل للقرارات؟

المصادر مراجعة بتاريخ 8 أكتوبر 2026.

الحاجة اللافتة في Jev كانت الشغل الما محتاج يعملو. التطبيق عايز يختار مسار، والموديل ما لازم يكتب فقرة كاملة عشان يديهو الاختيار. دي كانت الفكرة في مقال Jev السابق في فِكرة. [1] لمن الناتج المطلوب قيمة الكود يشتغل بيها، تكلفة توليد الكلام بتبقى سؤال يستاهل الوقفة.

هسع الخيارات زادت. Strands نزلت Decider 2B يوم 1 أكتوبر، وOpenAI عندها Decisions API في public beta. [3][4] السؤال للمطوّر بقى أدق: ياتو واحد مناسب للقرار دا، في التطبيق دا، وبالتكلفة البتترتب على الغلط؟ ترتيب عام للموديلات ما حيختار ليك.

إنت بتختار طريقة تشغيل كمان

Strands ناشرة الأوزان وبيانات التدريب والـ scripts كمان. دا بيديك مساحة تفحص وتعدّل، وبضيف ليك خدمة لازم تشغّلها وتتابعها. [4] المقايضة دي بتناسب فرق وبتتعب فرق تانية. التشغيل المحلي عندو قيمة لمن إنت محتاج السيطرة دي؛ لكن لازم يكون في زول مسؤول من الخدمة بعد ما التجربة تبقى جزء من المنتج.

الجدول بيقارن طريقة تشغيل كل خيار، وما بيرتّب جودتهم. كون الإجابة جات بالنوع الصحيح معناهو إن الكود بيقدر يقراها؛ لسه ممكن تكون اختارت التصنيف الغلط.

أدي الثلاثة نفس الشغلة الصغيرة

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

قبل تختار الموديل، اتفق على معنى التصنيفات. الميزة الناقصة بتتحسب bug ولا feature request؟ والرسالة الفيها مشكلتين تمشي وين؟ المراجعة العامة معناها معلومات ناقصة، لغة ما متأكدين منها، ولا موضوع خارج التصنيفات؟ لو الإجابة الصحيحة بتتغيّر أثناء التجربة، المقارنة حتطلع ملخبطة حتى لو الكود شغال تمام.

// Application contract, not vendor SDK syntax
input:   "Offline notes disappeared after the update."
options: [bug_report, feature_request, account_question, other]
output:  one supplied option + uncertainty information
action:  apply the application's routing rules

دا شكل مقترح للعقد بين أجزاء التطبيق، ما كود SDK جاهز للتشغيل. ممكن تعمل adapter صغير لكل مزوّد، عشان باقي النظام يستقبل نفس الحقول. احتفظ بالرد الأصلي للفحص، وافهم حقول عدم اليقين عند كل مزوّد. اسم confidence المتشابه ما بكفي عشان تتعامل مع الأرقام كأنها نفس الحاجة.

حسبة سعر ممكن تراجعها بنفسك

وقت مراجعة الأسعار، Jev كاتب 42 دولار لكل مليار input tokens، وOpenAI Decisions كاتب 0.10 دولار لكل مليون. [3][5] افترض عندك 100 ألف قرار، وكل واحد بيستهلك 2,000 token محسوبة في الفاتورة. المجموع 200 مليون. تكلفة المدخلات بتطلع 8.40 دولار مع Jev، و20 دولار مع OpenAI Decisions. دي حسبتي من الأسعار المعلنة، وما في تجربة اتعملت.

تساوي حجم المدخلات المحسوبة افتراض مهم. الـ tokenisation وحجم الأسئلة وتجهيز النص ممكن يغيّروا الفاتورة الفعلية. الحسبة ما شاملة إعادة المحاولات، استدعاء موديل أكبر، البنية التحتية، الزيادات الإقليمية أو أي معاملات سعر إضافية. وبرضو ما بتقول إن القرارين بنفس الجودة.

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

فرق سعر المدخلات هنا 11.60 دولار. قبل تصرف أسبوع عشان توفّرو، احسب تكلفة تصحيح التصنيف الغلط، وشوف كم رسالة بتمشي لموديل أغلى بعد أول محاولة. الطلب الرخيص ممكن يكون جزء صغير من مسار شغل مكلف.

النسبة بتفضل ثابتة لمن الحجم يزيد، فالفرق بيكبر معاهو: حوالي 116 دولار في مليون قرار، و1,160 دولار في عشرة مليون، بنفس الحسبة.

المقارنة المفيدة بتبدأ من بياناتك

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

اختار حدود التصرف التلقائي على validation set منفصلة. بعدين في الاختبار، وريّنا كم من الرسائل الموديل بيقدر يوجّهها تلقائياً عند نسبة الغلط المقبولة عندك. وافصل الأخطاء حسب النوع. طلب ميزة مشى لفريق الأعطال ما بالضرورة عندو نفس تكلفة عطل مهم اتفهم غلط. رقم accuracy واحد بيخفي الفرق دا.

راجع الـ calibration كمان. لو جمعت قرارات احتمالاتها قريبة من 0.8، هل الحدث المتوقع بيحصل في حوالي 80% منها؟ العلاقة دي محتاجة قياس على بيانات الاستخدام. وجود فاصلة عشرية في الرد ما بيضمنها.

قِس الزمن من دخول الطلب لحدي المسار النهائي، بعدد الطلبات المتزامنة المتوقع، ومع الـ timeouts. أرقام Strands المحلية مرتبطة بجهاز وحجم مهمة محددين؛ وحتى رسم الزمن المنشور خاص بـ v18، بينما الإصدار المذكور في الإعلان v19. [4] ما بنقدر نحطو جنب زمن API بعيد ونعلن فائز. الـ p95 في تطبيقك أنفع للاختيار دا.

بعدها حط كل المرشحين على نفس المحاور. الرسم تحت دا نموذج بس: المرشحين افتراضيين والدرجات مخترعة عشان توضّح شكل المقايضة. المرشح الكسبان في سعر المدخلات ممكن يخسر في المحاور البتحدد تكلفة مسار الشغل كلو.

ابدأ من الحاجة الداير تكون مسؤول منها

لو التطبيق أصلاً مربوط بـ Jev، أبدأ بسؤال: النقل حيحل مشكلة شنو؟ لو محتاج قرار من صورة، دعم OpenAI الموثق للصور سبب يدخل القائمة. ولو محتاج تشغّل وتفحص الموديل محلياً، Strands مرشح منطقي للتجربة. دي أسباب للاختبار، وما بتعفيك منو.

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

المصادر

• [1] Fkra: Jev answers in half a second and cannot write a sentence

• [2] TypeSafe: Introduction

• [3] OpenAI: Decisions API guide

• [4] Strands: Introducing Strands Decider 2B

• [5] TypeSafe: Jev pricing