Jev وصعود نماذج القرار: ماذا يعني ذكاء اصطناعي «نظام واحد» لأدوات الأمن

في 25 سبتمبر 2026، أعلنت TypeSafe AI عن Jev، أول نموذج فيما تسميه فئة «النظام واحد» (System One): ليس روبوت محادثة، وليس مجرد نموذج لغوي أكبر، بل ما تصفه الشركة بأنه نموذج قرار — شيء بُني للإجابة عن سؤال محدود بإجابة مُنظَّمة ومعايرة بدلًا من فقرة نثرية. الإعلان مليء بأرقام محددة، لذا يستعرض هذا المقال ما زُعم بالضبط، ويوضح بصراحة ما تمكنّا من التحقق منه وما لم نتمكن، وينظر في سبب أهمية الفكرة الكامنة وراءه — أن يقرر النموذج بدل أن يولّد نصًا — بالنسبة لبرمجيات الأمن على وجه الخصوص.

ما الذي أعلنته TypeSafe فعليًا

أسّس TypeSafe AI ديوغو ألميدا، الذي يكتب في الإعلان أنه «في OpenAI، ساعدت في بناء الأساليب التي جعلت النماذج اللغوية مفيدة في اتباع التعليمات والتحدث مع الناس». ويُروَّج لـ Jev، الذي وُصف بأنه «أول نموذج عام» للشركة، على أنه مهمة مختلفة تمامًا: إنتاج ما تسميه TypeSafe قيمًا مُنظَّمة آمنة النوع (type-safe) باحتمالات ودرجات ثقة معايرة، تُولَّد عبر ما تسميه أخذ عيّنات متوازيًا (parallel sampler) بدلًا من فك الترميز المعتاد رمزًا تلو الآخر، ومُدرَّبة بطريقة تسميها الشركة التعلم المعزَّز للقرارات المعايَرة (Reinforcement Learning for Calibrated Decisions)، أو RLCD.

• تُبلغ TypeSafe عن زمن استجابة كامل يتراوح بين «70 و500 مللي ثانية»، مقابل ما قاسته على أنه «من 3 إلى 329 ثانية» بالنسبة لنماذج اللغة المتقدمة التي قارنت Jev بها.
• تسعّر TypeSafe رموز المُدخلات عند «0.042 دولار لكل مليون رمز»، مع إدراج رموز المُخرجات كمجانية.
• في اختبارات سير عملها الخاصة، تُبلغ TypeSafe عن أن Jev يعمل «بسرعة أكبر بمقدار 193.6 ضعفًا، وبتكلفة أقل بمقدار 444.6 ضعفًا» مقارنة بالسياسات التي قِيس بها.
• تصف TypeSafe خطأ النوع في مخرجات Jev بأنه، على حد تعبيرها، «مستحيل رياضيًا».
• يخضع Jev حاليًا لوصول مبكر؛ وتقول TypeSafe إنها تُدخل المطورين «من قائمة الانتظار بأسرع ما يمكننا».

التوليد مقابل القرار

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

يستحق ادّعاءان هنا الفصل بينهما، لأنهما ليسا الشيء نفسه: مُنظَّم (typed)، ومعاير (calibrated). المخرج المُنظَّم يقيّد شكل الإجابة — سؤال من نوع «اختيار» يُعيد أحد الخيارات المدرجة في القائمة، وسؤال من نوع «درجة» يُعيد رقمًا داخل نطاق مُعلَن، لا جملة شاردة أو حقلًا مُختلَقًا أبدًا. أما المعايرة فهي فكرة أقدم بكثير ومنفصلة تمامًا. إنها خاصية إحصائية لا أسلوبية: تعني أنه حين يذكر النظام احتمالًا قدره 0.62، يكون محقًا بهذا القدر عبر تنبؤات كثيرة مشابهة، بحيث يمكن لبرنامج لاحق أن يضع فعليًا عتبة على ذلك الرقم بدلًا من معاملته كزخرفة.

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

ما الذي يمكن، وما لا يمكن، أن تعنيه عبارة «لا يمكنه أن يهلوس»

ادّعاء TypeSafe بأن خطأ النوع «مستحيل رياضيًا» يصف فك ترميز مقيَّد (constrained decoding)، وهي تقنية موجودة بالفعل في أماكن أخرى. يقدّم دليل Structured Outputs الخاص بـ OpenAI ضمانًا مشابهًا: تقول إن الميزة «تضمن أن النموذج سيولّد دائمًا استجابات تلتزم بمخطط JSON الذي قدّمته، بحيث لا داعي للقلق من إغفال النموذج لمفتاح مطلوب، أو اختلاقه لقيمة تعداد غير صالحة». هذا الضمان حقيقي ومفيد. لكنه أيضًا أضيق مما يبدو عليه: فهو يقيّد شكل الإجابة، لا صحتها. سؤال من نوع «اختيار» بثلاثة خيارات سيُعيد دائمًا أحد الخيارات الثلاثة — بما في ذلك، إن أساء النموذج تقدير المُدخل، إجابة واثقة ومُنظَّمة بصلاحية لكنها خاطئة.

المعايرة هي الجزء الذي يجب التحقق منه، لا مجرد التأكيد عليه. الأداة القياسية هي مخطط الموثوقية: صنّف التنبؤات في مجموعات حسب ثقتها المذكورة، وارسم لكل مجموعة عدد المرات التي كانت فيها تلك التنبؤات صحيحة فعليًا؛ والفجوة بين الخط القطري والخط المُلاحَظ تُلخَّص عادة بخطأ المعايرة المتوقع. وهذا ليس سؤالًا جديدًا في تعلم الآلة — وجدت ورقة Guo وآخرون لعام 2017 بعنوان «حول معايرة الشبكات العصبية الحديثة» أن «الشبكات العصبية الحديثة... معايرة بشكل سيئ» افتراضيًا، وأن إصلاحًا بسيطًا بمعامل واحد يُسمى قياس الحرارة (temperature scaling) كان «فعالًا بشكل مفاجئ» في إصلاح ذلك. الدرس يتجاوز تلك الورقة الواحدة: المعايرة ليست خاصية يستطيع نموذج أن يعلنها عن نفسه. إنها شيء تتحقق منه، على بياناتك المُصنَّفة الخاصة، لأنها تميل إلى التدهور بالضبط حيث تحتاجها أكثر — على مُدخلات لا تشبه في شيء ما ضُبط عليه النموذج.

إطار تقييم بسيط (قالب)

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

# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests

def ask(state: str, question_id: str, question: dict) -> dict:
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
    )
    return resp.json()["answers"][question_id]

# 1. Shape check: does every response parse against the declared type, on your
#    own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
#    true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample:          # your own traffic, labeled by hand
    answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
    bucket = min(int(answer["noul"] * 10), 9)
    buckets[bucket]["n"] += 1
    buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)

for b, s in buckets.items():
    if s["n"]:
        stated = (b + 0.5) / 10
        observed = s["correct"] / s["n"]
        print(f"stated~{stated:.2f}  observed={observed:.2f}  n={s['n']}")  # the gap here is your calibration error

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

لماذا يهم هذا لأدوات الأمن

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

المفاضلة الخاصة بالخصوصية، بصراحة

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

اتخذ FireAI، جدار الحماية الخاص بـ HisnLabs لأجهزة Mac، الخيار المعاكس تمامًا بالنسبة لهذه الفئة تحديدًا من القرارات التي يتناولها هذا المقال. يعمل FireAI على macOS 14 أو أحدث على معالجات Apple Silicon، مقابل 49 يورو دفعة واحدة، وهو ليس برنامج مكافحة فيروسات صراحة ولا شبكة VPN. عندما يحاول تطبيق لم تره من قبل الوصول إلى الشبكة، يمكن لـ FireAI تشغيل نموذج صغير على الجهاز نفسه — تنزيل اختياري بحجم 1.5 جيجابايت — لمراجعة ذلك الاتصال وتنبيهك بسبب مكتوب بلغة بسيطة؛ ولا تُرسَل الحركة قيد المراجعة إلى أي مكان أبدًا. يصبح كل قرار من هذه القرارات المدعومة بالذكاء الاصطناعي قاعدة مرئية، مرتبطة بتوقيع الكود الخاص بالتطبيق، يمكنك رؤيتها والتراجع عنها، إلى جانب قوائم تهديدات تُطبَّق محليًا بدلًا من الاستعلام عنها من خادم بعيد.

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

أسئلة مفتوحة

• تقييمات مستقلة: لم ينشر أي طرف خارجي بعد إعادة إنتاج لمضاعفات السرعة أو التكلفة الواردة في إعلان TypeSafe، على بيانات لم تختَرها TypeSafe.
• المعايرة تحت تغيّر التوزيع — وهو بالضبط السيناريو الذي تتناوله ورقة Guo وآخرين، وهو الأهم أمام خصم يتكيف بمجرد أن تصبح طريقة الدفاع معلنة.
• ما إذا كان التسعير يصمد عند حجم إنتاج حقيقي، وما إذا كانت زمن الاستجابة المذكور يصمد تحت حمل مستمر لا مجرد طلب توضيحي واحد.
• كيف يتصرف النموذج أمام مُدخلات عدائية أو غامضة فعليًا، حيث يمكن لإجابة مُنظَّمة واثقة أن تكون أقل صدقًا من إجابة تقول «غير واضح».
• متى يُفتح الوصول المبكر لمن هم خارج قائمة الانتظار، ولمن، وبأي شروط بالنسبة للبيانات المُرسَلة كـ«حالة» (state).

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

دور FireAI وHisnLabs

We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.

FireAI هو منتج HisnLabs نفسها: جدار حماية بذكاء اصطناعي يعمل على جهاز Mac مباشرة. يعرض بلغة واضحة كل اتصال تجريه تطبيقاتك، ويترك لك القرار فيما يخرج من جهازك — ذكاؤه الاصطناعي يعمل محليًا، فلا يُرسَل ترافيكك إلينا ولا إلى أي جهة أخرى أبدًا. فريق أبحاث الأمن في HisnLabs هو من يحافظ على دقة هذه القرارات: يصنّف النطاقات بين قياس عن بُعد عادي وخدمة حقيقية، ويتتبّع بلد وشبكة كل اتصال، ويدرّب النموذج المحلي (ميزة Autopilot) على حركة اتصال حقيقية، دون أن يغادر أي شيء جهاز Mac.

يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على FireAI من HisnLabs.