Jev والـ System One Models: نموذج ذكاء اصطناعي ما بيكتب ولا كلمة

بتاريخ ١٥ أيلول ٢٠٢٦ طلع نموذج ذكاء اصطناعي اسمه Jev، وأول ميزة فيه إنه ما بيكتب ولا كلمة.

هذا مش نقص فيه — هذا التصميم. بتعطيه حالة، وبيرجّعلك قرار من قائمة إنت حدّدتها مسبقاً، ومعه نسبة احتمال لكل خيار. خلال ٠.٤ ثانية تقريباً. سمّوا هذا النوع System One Model، وهو تصنيف جديد كلياً — مش LLM أصغر ولا أسرع، شيء ثاني تماماً.

الفكرة مسروقة من كتاب، وهذا أفضل شيء فيها

إذا قرأت Thinking, Fast and Slow لـ Daniel Kahneman، بتعرف الفكرة أصلاً.

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

هذا System 1: سريع، تلقائي، بلا شرح.

وبعدين بنفس اليوم قعدت تحسب ضريبة الدخل على ورقة. هذا System 2: بطيء، واعي، خطوة خطوة.

وهون بيت القصيد: كل نموذج ذكاء اصطناعي تعاملت معه لليوم هو System 2. يعني ChatGPT و Claude و Gemini — كلهم بيفكّروا بصوت عالي، وبيكتبوا كلمة ورا كلمة، وبياخدوا وقتهم. وهذا ممتاز لما تكون بدك مقال أو كود أو تحليل.

بس ٩٠٪ من القرارات اللي برنامجك بياخدها كل يوم مش من هذا النوع. «هذا الـ Bug report تبع أي فريق؟» مش سؤال فلسفي — هو ضغطة بريك.

ليش الـ LLM بطيء أصلاً؟

السبب مش إنه «النموذج كبير». السبب معماري، واسمه Autoregression.

الـ LLM بيولّد token واحد كل مرة، وكل token لازم يستنى اللي قبله حتى يبدأ. فإذا الجواب طوله ٢٠٠ token، النموذج عمل ٢٠٠ دورة متسلسلة. ما بتقدر تسرّعها بالتوازي، لأنه الخطوة رقم ٥٠ حرفياً بتحتاج نتيجة الخطوة ٤٩.

Jev بيكسر هذا القيد: بيولّد كل الإجابات بتمريرة وحدة متوازية. ما في سلسلة، فما في انتظار.

طيب، وشو بيرجّع بالضبط؟

إنت بتحدّد الأسئلة قبل ما ترسل، وعندك ثلاثة أنواع بس:

خلينا نشوفها على مثال بتعرفه: Bug report واصلك، وبدك تفرزه.

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const report = `Login button does nothing on Safari 17.
Happens every time. Console: Uncaught TypeError: undefined is not a function.
Started right after yesterday's release.`;

const result = await client.systemOne({
  state: { bugReport: report },
  questions: {
    area: choice("Which team owns this bug?", {
      frontend: "UI, rendering, browser-specific behaviour",
      backend: "API, database, server errors",
      infra: "Deploy, environment, CI",
    }),
    regression: noul("This looks like a regression from a recent release"),
  },
});

result.answers.area.choice;      // "frontend"
result.answers.area.confidence;  // 0.94
result.answers.regression.noul;  // 0.88

لاحظ شيء: ما في JSON.parse، وما في تحقّق إذا النموذج نسي قوس.

هاي أهم نقطة بالموضوع كله، وسهل تمرق عليها بسرعة. لما تطلب من LLM «رجّعلي JSON»، إنت عم ترجّى نص يطلع بالشكل الصحيح. مع Jev الأنواع محدّدة قبل الإرسال، فالخطأ البنيوي مستحيل — مش نادر، مستحيل.

الأرقام

هاي المقارنة اللي نشرتها TypeSafe على أربع مهام قرار:

اقرأ السطر الأول والثاني مع بعض: نفس الدقة تقريباً، بجزء من ٧٦ من التكلفة، وأسرع ٢٥ مرة.

والأوضح: تصنيف ٥٠ مليون صف بيكلّفك حوالي ٢٠ دولار بدل آلاف.

الجزء الممتع: Jev بيلعب Doom

أحلى عرض قدّموه مش جدول — إنهم خلّوا النموذج يلعب Doom.

بياخد حالة اللعبة كمدخل، وبيقرّر عشر مرات في الثانية، بكلفة حوالي ٧ دولار للساعة. جرّب تعمل هذا الشي بـ LLM بياخد ١٠ ثواني للرد — بتكون متّ ٣٠ مرة قبل ما يرجع الجواب الأول. 🎮

وهون بتفهم الفكرة: في تطبيقات القرار الحيّ، السرعة مش رفاهية — هي شرط الوجود.

وين بيفيدك إنت كمهندس جودة؟

هون بصير الموضوع عملي. أي شغلة بتعملها بالمئات أو بالآلاف، وجوابها من قائمة معروفة مسبقاً، هي مرشّحة:

1. فرز الـ Bug reports. واصلك ٣٠٠ تقرير هذا الأسبوع — أي فريق، أي خطورة، وهل هو مكرّر؟ هذا بالضبط شكل المسألة.
2. تصنيف فشل الاختبارات. الـ CI طلّع ٤٠ فشل. أي واحد فيهم Flaky وأي واحد Regression حقيقي؟ إنت عم تعمل هذا القرار يدوياً كل صباح.
3. ترتيب أولوية الـ Regression suite. قبل ما تشغّل ٢٠٠٠ اختبار، أي مئة منهم الأكثر ارتباطاً بالتغيير اللي صار؟
4. بوابة ثقة (Confidence Gate). وهاي أذكى استعمال: خلّي القرارات اللي فوق ٠.٩ تمشي لحالها، واللي تحت هيك ترجع لإنسان أو لـ LLM أبطأ وأذكى. الاحتمال مش زينة — هو أداة توجيه.

لحظة — شو الأشياء اللي ما بيعملها؟

قبل ما تتحمّس زيادة، هاي الحدود، وهي حقيقية:

• ما بيكتب نص. أبداً. لا كود، لا إيميل، لا تلخيص، لا شرح. إذا مخرجك المطلوب جملة، هذا مش النموذج.
• ما بيعطيك سبب. بيعطيك رقم. بتعرف إنه صنّف التقرير frontend باحتمال ٠.٩٤، بس ليش؟ ما في جواب. وهذا وجع حقيقي وقت الـ Debugging، وأوجع في المجالات المنظّمة اللي بتطلب تبرير كل قرار.
• الخيارات لازم تكون معروفة من البداية. إذا ما بتقدر تكتب القائمة، ما بتقدر تستعمله.
• ما بيعدّ ولا بيحسب تواريخ. هاي شغلة الكود، والنموذج مش المكان إلها.

القاعدة البسيطة: إذا الكود بيقدر يحسبها بالضبط — خليها للكود. وإذا بدها حكم بشري متكرّر من قائمة مغلقة — هون بيدخل System One. وإذا بدها كتابة أو تفكير مفتوح — ارجع للـ LLM.

والسؤال اللي لازم يخطر ببال مهندس الاختبار

هلأ انتبه، لأنه هون بيت القصيد بالنسبة إلنا.

كيف بدك تختبر نموذج ما بيرجّع نص؟

كل ما تعلّمته عن مقارنة النصوص صار بلا معنى. ما في string تقارنه. الجواب رقم واحتمال.

المقياس الصح هنا اسمه Calibration: لما النموذج يقول «٠.٨»، لازم يطلع صح ٨٠٪ من المرات — مش ٩٥٪ ومش ٦٠٪. نموذج دقته ٧٠٪ ومعايرته صادقة أنفع من نموذج دقته ٨٥٪ بس بيقول ٠.٩٩ على كل شي، لأنه الأول بتقدر تبني عليه بوابة ثقة، والثاني بيكذب عليك بثقة.

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

إذا حابب تدخل فيها جدّياً — من فكرة LLM as a judge، لمقاييس زي Faithfulness و Task Completion، لبناء مقاييسك الخاصة — هاي بالضبط مادة دورة تقييم تطبيقات الذكاء الاصطناعي مع DeepEval.

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