كلما طُلب من وكيل ذكاء اصطناعي تصنيف رسالة دعم فني عاجلة، أو التحقق من سلامة أمر برمجي، تبدأ آلة ضخمة في الدوران: نموذج لغوي كبير يحسب احتمالات الرموز كلمةً تلو الأخرى، يستهلك ثوانٍ ثمينة وميزانية معتبرة، فقط ليخبرنا في النهاية "نعم" أو "لا".
هذا التناقض بين حجم الأداة وطبيعة المهمة قاد مختبر TypeSafe AI إلى طرح مفهوم مختلف كلياً عبر نموذجهم الجديد Jev: نموذج ذكاء اصطناعي لا يتحدث، ولا يكتب مقالات، بل يتخذ قرارات برمجية دقيقة وقابلة للاستهلاك المباشر من قِبل الشيفرات المصدرية.
ما هو Jev؟
ينطلق مفهوم Jev من التمييز المعرفي الشهير لعالم النفس دانيال كانمان بين "النظام الأول" (System 1) المسؤول عن القرارات البديهية السريعة، و"النظام الثاني" (System 2) المخصص للتفكير التحليلي البطيء. يكتب كانمان في كتابه Thinking, Fast and Slow:
النظام الأول يعمل تلقائياً وبسرعة، بجهد قليل أو بلا جهد، ودون أي إحساس بالتحكم الإرادي."
وبينما صُممت كل نماذج اللغة الكبرى الحالية لتقليد النظام الثاني حيث التفكير المطوّل خطوة بخطوة عبر توليد النص بينما يعمل Jev في الاتجاه المعاكس تماماً: فهو نموذج بُني خصيصاً ليكون النظام الأول لا الثاني. تسميه TypeSafe له ب System One Models، بالحروف لا بالرقم، لكنها إشارة مباشرة لنفس مفهوم كانمان أعلاه: أول نموذج عام من هذه الفئة، مخصص للمستهلك الآلي (Machine-Native) لا للحوار البشري.
لا يولّد النموذج نصوصاً، بل يستقبل "حالة" برمجية محددة (State)، ويجيب على تساؤلات صريحة حولها بنتائج ذات أنواع برمجية محددة (Typed Decisions) ونسب احتمال دقيقة، مما يجعله أشبه بوحدة برمجية موثوقة وسريعة بدلاً من كونه روبوت محادثة.
الهندسة المعمارية: قرارات منضبطة وتدريب معاير
تختلف بنية Jev عن النماذج التوليدية في ثلاثة جوانب جوهرية:
١ - التقييم المتوازي للأسئلة (Parallel Evaluation). في النماذج التقليدية، تتراكم الأسئلة وتزيد مدة الاستجابة خطياً مع كل سؤال إضافي. أما في Jev، فتُرسل الحالة مع مصفوفة من الأسئلة المستقلة، ليعالجها النموذج بالتوازي دون زيادة تُذكر في زمن الاستجابة، وفق ثلاثة أنماط رئيسية كما توضح وثائق Cloudflare AI Docs:
Noul: تسمية خاصة بالشركة لنمط الأسئلة المنطقية الثنائية (نعم/لا)، حيث يُرجع النموذج احتمالية رقمية محددة لصدق العبارة.
Choice: للاختيار بين تصنيفات محددة، مع توزيع احتمالي لكل خيار ونسبة ثقة كلية، حتى ٢٥٥ خياراً.
Score: للتقييم على مقياس مدرج مستمر، مثل منخفض ومتوسط ومرتفع.
٢ - خوارزمية التدريب RLCD مقابل RLHF
تُبنى النماذج العامة على التعلم المعزز عبر التغذية البشرية (RLHF)، وهو أسلوب يُعلّم النموذج إرضاء المستخدم، وغالباً ما ينتج عنه ثقة زائفة (Overconfidence) وهلوسة. أما Jev فيستند إلى خوارزمية مختلفة جذرياً تُدعى RLCD (Reinforcement Learning for Calibrated Decisions)، تدرّبه على قياس درجة يقينه بدقة: فلا يكتفي بإعطاء النتيجة، بل يرفق معها تقديراً رياضياً معاكساً لنسبة الشك؛ فكلما ارتفعت نسبة الثقة، ارتفعت دقة القرار فعلياً.
٣ - الفارق عن مخرجات JSON التقليدية
محاولة إجبار نموذج لغوي توليدي على إخراج صيغة JSON لا تغير من طبيعته كنموذج بطيء يولّد الرموز رمزاً بعد رمز. أما Jev فنموذج غير توليدي بالأساس، ومخرجاته مهيكلة بنيوياً على مستوى طبقات الاستنتاج الأخيرة، لا كوصفة إخراج مفروضة على نموذج مصمم لشيء آخر. وبما أن مساحة الإجابات الممكنة محصورة ومحددة سلفاً في أنواع برمجية ثابتة، تنتفي هنا الهلوسة اللفظية تماماً، وينحصر هامش الخطأ في دقة التصنيف التي تُقاس وتُضبط رياضياً عبر مؤشر الثقة المعاير.
التحليل الاستراتيجي: تفكيك تكلفة "الذكاء الفائض"
من منظور استراتيجي واقتصادي، تعاني الكثير من منتجات الذكاء الاصطناعي اليوم من معضلة "الذكاء الزائد عن الحاجة" (Over-Intelligence)، إذ يُستخدم نموذج توليدي باهظ لإنجاز مهام فرز أو توجيه بسيطة داخل حلقة عمل الوكيل (Agent Loop).
توضح مؤشرات الأداء التي نشرتها TypeSafe أن استدعاء Jev يُكلف نحو ٤٢ دولاراً لكل مليار رمز إدخال، بزمن استجابة يقارب ٠.١١ ثانية، ما يعني سرعة تتجاوز النماذج الكبرى بنحو ٢٠٠ ضعف، وتكلفة تقل بأكثر من ٤٠٠ ضعف في مهام التصنيف. استراتيجياً، يتيح هذا النموذج للمؤسسات خفض فاتورة البنية التحتية السحابية بشكل جذري، وتحرير النماذج التوليدية المعقدة لتركز فقط على المهام الإبداعية والتحليلية المفتوحة.
هذه الأرقام مذهلة، لكنها تستحق قراءة بعين ناقدة قبل أي حماس: فكلها صادرة من اختبارات أجرتها TypeSafe نفسها على سير عمل صممته هي، والشركة تعترف صراحة أنها "لا تستطيع إثبات أن السعر غير مدعوم". النموذج ما زال في مرحلة وصول مبكر (Early Access) بقائمة انتظار، والتقييم المستقل على بيانات إنتاج حقيقية لم يحدث بعد.
التطبيق العملي من منظور الإدارة التقنية
للمهندسين ومديري التقنية الذين يديرون أنظمة وكلاء ومسارات تشغيل آلية، يمكن دمج Jev عملياً في ثلاثة مواقع رئيسية:
توجيه النماذج (Model Routing Middleware). بدلاً من استقبال كل طلب عبر النموذج الأغلى، يعمل Jev كطبقة تصنيف أولية فائقة السرعة تقيّم صعوبة السؤال وتوجهه تلقائياً: الاستفسارات البسيطة تُحال لنماذج مصغّرة، بينما تُحوّل المهام المعقدة لنماذج الاستدلال الكبرى، كما بيّنت تجارب LangChain.
حواجز الأمان والحماية التلقائية (Guardrails & Auto Mode). قبل أن ينفذ الوكيل البرمجي أداة حساسة، مثل استدعاء Bash أو إصدار أمر دفع، يقوم Jev بفحص سياق الأمر وقياس درجة خطورته في أجزاء من الثانية لحظر أي سلوك شاذ قبل التنفيذ.
إدارة عتبات الثقة (Confidence Thresholding). استناداً إلى المعايرة الحقيقية التي توفرها خوارزمية RLCD، تصبح نسب الاحتمال أرقاماً معبّرة عن الواقع الإحصائي وليست مؤشرات اعتباطية. تستطيع الفرق الهندسية حينها صياغة منطق تحكم رقمي واضح: إذا كانت ثقة النموذج تتجاوز ٩٠٪، يتم الإجراء ذاتياً وبشكل فوري؛ وإن كانت بين ٧٠٪ و٩٠٪ يمر الإجراء بمستوى تدقيق إضافي؛ أما دون ذلك فيُصعّد تلقائياً للمراجعة البشرية. هذا النهج يقلل العبء التشغيلي على المراجعين البشريين ويضمن دقة العمليات الحرجة.
لمن أراد تجربة الفكرة عملياً قبل تبنّيها في سير عمل حقيقي: مستندات TypeSafe AI تحتوي أمثلة كود جاهزة لبدء اختبار صغير.
ما شدّني في Jev ليس الأرقام وحدها، بل الفكرة التي يقوم عليها: الذكاء الاصطناعي ليس أداة واحدة تصلح لكل شيء، بل طيف من الأدوات. بعضها مخصص للتفكير العميق البطيء، وبعضها للقرار اللحظي السريع. أي فريق أتمتة يخلط بين الاثنين اليوم يدفع فاتورة ذكاء لا يحتاجه في معظم قراراته اليومية.
وهذا فيديو يشرح المودل الجديد و بعض من استخداماته
