كيف نبني توجيه LLM وضوابط الحماية؟ مثال على تعاون Jev مع النماذج اللغوية الكبيرة

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

يمكن بناء توجيه LLM على هذا النحو: أولاً، اجعل Jev يحدد نوع الطلب ومدى خطره، ثم يقرر الكود ما إذا كان سيُسلّم إلى دالة عادية، أو LLM متخصص، أو مراجعة بشرية. يمكن أيضاً وضع Jev بين الاسترجاع والتوليد لتصفية الأدلة، أو بعد مخرجات LLM لفحص النتيجة. ما يعيده هو خيارات مغلقة ودرجات واحتمالات؛ أما الإجابات المفتوحة وتوليد الكود والاستدلال الطويل فلا تزال من مهام LLM. ويوضح شرح TypeSafe عن وكلاء البرمجة صراحةً أن Jev لا يمكن أن يحل مباشرة محل نموذج المحادثة وراء Claude Code أو Codex.

تشرح هذه المقالة، عبر طلب دعم عملاء، وخط أنابيب أسئلة وأجوبة RAG، وسجل معايرة Agent الخاص بنا، أين تتقاطع فئتا النماذج بالضبط، ولماذا يجب أن تكون للنتائج منخفضة الثقة وجهة واضحة.

ما الذي يستطيع Jev الحكم فيه، وما الذي يظل LLM مسؤولاً عنه؟

حتى 23 سبتمبر 2026، كان النموذج المستقر المدرج في صفحة نماذج TypeSafe هو jev-1.13.0. تقبل API قيمة state ومجموعة questions، وتعيد عبر POST /v1/systemone قيم answers المهيكلة المقابلة. في ذلك اليوم كان jev-latest يشير إلى 1.13.0، لكن الأسماء البديلة تتغير مع الإصدارات؛ يُستحسن للأنظمة التي عايرت عتباتها تثبيت الإصدار وتسجيل معرّف النموذج الفعلي في الاستجابة.

لا يملك Noul حقل confidence مستقلاً؛ لا يمكن كتابة احتمال Noul مباشرةً على أنه «ثقة النموذج». كما لا ينبغي استخدام Score لحساب مبالغ دقيقة. يجب إبقاء المبالغ ومقارنات التواريخ والحصص وفحوص الصلاحيات في برامج حتمية، وقد أدرجت الوثائق الرسمية هذه الحدود في Jev 1.13.

أصغر شكل لاستدعاء واحد

شكل الطلب التالي متوافق مع مرجع API الرسمي، وأسئلة المثال هي إعداد توضيحي أنشأناه لهذه المقالة، ولم تُجرَ عليه قياسات مباشرة في هذه المقالة:

يستخدم ملف JSON أدناه رسالة عميل بالإنجليزية، وفي العربية سيقول العميل: “تم خصم المبلغ مرتين على الطلب، يرجى مساعدتي في استرداد المبلغ.”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

ينبغي للنظام الفعلي أيضاً أن يتحقق أولاً بالكود مما إذا كانت سجلات الخصم تخص الطلب نفسه، وما إذا كان الاسترداد مسموحاً. المثال أعلاه مخصص فقط لاستنتاج نية المستخدم؛ طلب المستخدم للاسترداد لا يعني أن أهلية الاسترداد قد أُثبتت، كما لا يشكل تفويضاً بتنفيذ الاسترداد مباشرة.

استخدام Jev لتوجيه LLM: ثلاثة مسارات للتسليم

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

عند التنفيذ، يمكن التصميم بالترتيب التالي بدلاً من ترك النموذج يقرر كل الإجراءات بحرية:

1. حدد المسارات أولاً:ذكر بوضوح الطلبات التي يمكن للدوال العادية، وLLM المتخصصة، والمراجعة البشرية معالجتها، واترك لـ Choice خيار other أو خياراً احتياطياً مماثلاً.
2. ضع الحقائق في state: كلام المستخدم الأصلي، وحالة الحساب، وسجلات الطلب حقول منفصلة؛ لا تعامل نص صفحة ويب مجهول المصدر كتعليمات نظام.
3. اسأل أسئلة ضيقة في كل مرة: استخدم Choice للنية، وScore للمخاطر أو الإلحاح، وNoul لحقيقة واحدة تحتاج تأكيداً. توصي الوثائق الرسمية بأن الأسئلة المستقلة المتعددة التي تشترك في state نفسه يمكن تقييمها بالتوازي في الطلب نفسه.
4. اجعل الكود هو من يوجه نهائياً: افحص الصلاحيات والقواعد الصارمة أولاً، ثم انظر إلى احتمالات Jev والعتبات المعايرة لعملك؛ أما الطلبات منخفضة الثقة أو الناقصة الأدلة فتذهب إلى مراجعة بشرية أو سؤال إضافي.
5. سجّل النتائج وراجعها: احفظ إصدار النموذج، وإصدار الأسئلة، والاحتمالات، والوجهة النهائية، ونتائج التصحيح البشري، حتى تستطيع الحكم على ملاءمة العتبات.

المصدر: TypeSafe AI «Introducing System One Models & Jev»، 2026-09-15. مسارات العمل الأربعة من بناء TypeSafe، والمؤشرات مجمعة بأوزان متساوية بحسب سير العمل؛ انظر منهجية التقييم في TypeSafe workflow evals.

يساعد هذا الرسم الرسمي في فهم سبب تشديده على «وضع أحكام ضيقة متعددة داخل سير عمل برمجي». يستخدم المحور الرأسي في الرسم تسمية المورّد «accuracy»، لكن مرجعه في الإجابات يأتي من توافق احتمالات التنبؤ لنموذجين كبيرين، وليس إجابة صحيحة وحيدة مدققة بشرياً؛ كما تعتمد التكاليف والمؤشرات على مسارات العمل الأربعة هذه وعلى منهجية تقييم المورّد، ولا يمكن تحويلها إلى «كم يمكن التوفير في أي سيناريو».

التوليد المعزز بالاسترجاع: Jev يصفّي الأدلة قبل إجابة LLM

يقدم دليل وصفات TypeSafe لتصنيف مقاطع RAG مثالاً أكثر تحديداً متعدد النماذج: يستدعي OpenAI embedding المقاطع أولاً، ثم يسأل Jev عن كل «سؤال + مقطع» أربعة أسئلة Noul — هل هو ذو صلة، وهل يحتوي دليلاً يمكن استخدامه للإجابة، وهل يعارض الفرضية في السؤال، وهل يحاول إعطاء تعليمات لنموذج الإجابة. يعالج الكود الاحتمالات الأربعة بالترتيب، ويقرر وضع المقطع في منطقة الأدلة، أو منطقة الأدلة المتعارضة، أو تجاهله؛ وأخيراً يكتب Claude Sonnet 5 الإجابة.

تحل هذه الخطوة مشكلة شائعة: المقاطع ذات التشابه المتجهي العالي ليست بالضرورة قابلة للاستخدام. فقد تكون استخدمت كلمات متشابهة فقط، أو قد تحمل منشور منتدى حقناً توجيهياً يقول «تجاهل ما سبق». يضع مثال cookbook فحص الحقن في مقدمة قواعد التوجيه، وينبّه في الوقت نفسه إلى أن العتبات نقطة بداية مختارة لتلك المجموعة اللغوية، وليست القيم الافتراضية لكل تطبيقات RAG. أما أرقامه التوضيحية فتعود إلى jev-1.12 بتاريخ 2026-08-27، ولا يجوز اعتبارها نتائج تقييم جديدة للنموذج الحالي jev-1.13.0.

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

معايرة Agent لدينا: أين تتعطل عمليات التصعيد منخفض الثقة؟

في مستودع PandaNpc، يستخدم عميل Jev وبنك الأسئلة والمنسّق Jev في التعرف على نية Agent، وتقييم التعديلات المرشحة، والتحقق من شروط الإكمال، وحكم الإرسال. كما يقوم العميل بإعادة محاولات محدودة عند المهلات و429 و5xx، ويضع حدوداً لميزانية الطلبات والنتائج المنتهية؛ أما صلاحيات التنفيذ فيمسكها المنسّق وطبقة الأدوات المضبوطة، ولا يمنحها حكم واحد من Jev مباشرة.

في 2026-09-22 استخدمنا jev-1.13.0 لتشغيل 19 turn اصطناعياً مرة واحدة في shadow ومرة في enforce لكل منها، بإجمالي 38 تشغيلاً، وسجلنا 165 قرار Jev حقيقياً. يستخدم تقرير المعايرة الداخلي هذا والاستجابات الفعلية المحفوظة مزوّد LLM وهمياً مبرمجاً، لذلك لا تبيّن هذه البيانات إلا أداء القرارات في سيناريوهات مضبوطة. وهي لا تثبت معدل النجاح الإجمالي، ولا نسبة التوفير، ولا زمن الاستجابة من طرف إلى طرف لطلبات المستخدمين الحقيقية.

لم تكن أهم اكتشافاتنا هي السرعة المتوسطة، بل أن عتبة «تبدو آمنة» تسببت في انسداد: من بين 19 turn في وضع enforce، صُعّد 13 منها عند Q2 «هل المعلومات كافية لبدء التعديل»، لأن احتمال Noul وقع في نطاق عدم اليقين الأصلي 0.15–0.85؛ ولم يحصل LLM Worker على فرصة لتنفيذ الخطوات اللاحقة. تُظهر سجلات المعايرة أن كثيراً من الاحتمالات في 34 قرار Q2 موسوماً بأن المعلومات كافية جاءت في المنطقة الوسطى. ويوصي التقرير بتقسيم Q2 المعقد إلى أحكام أكثر ذرية، أو تعديل قواعد التصعيد؛ هذه توصيات، وليست عتبات نُشرت فعلاً.

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

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

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

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

يجب تصميم مسارات الفشل أيضاً. لا يعيد العميل المحاولة بشكل محدود إلا عند المهلة أو خطأ الشبكة أو 429 أو 5xx؛ أما الإجابات الملغاة أو التي تتجاوز الموعد النهائي للـ turn فتُهمل مباشرة. إذا لم يكن Jev متاحاً في وضع enforce، فلا يمكن المتابعة دون تفويض بالتخفيض؛ وعند السماح بمسار llm_only، يُقفل المنفّذ على القراءة فقط. وإذا فُقد Jev بعد أن حدث تعديل في الفرع، يعلّم المنسّق الدورة كاملة كفاشلة، بدلاً من ترك LLM اللاحق يكمل الكتابة في غياب طبقة القرار. لهذه المسارات كلفة على تجربة المستخدم، لكنها تمنع «تعذر النموذج مؤقتاً» من أن يتحول بهدوء إلى «صلاحية الكتابة كما هي».

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

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

أين ينبغي وضع ضوابط حماية LLM؟

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

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

متى يكون الاستخدام مناسباً، ومتى لا يكون؟

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

إذا أردت ملاحظة كيفية تعامل Agent حقيقي مع الصلاحيات واستدعاءات الأدوات، فيمكنك البدء من PandaNpc Agent؛ ولمعرفة حدود Agent البرمجة وحالات استخدامه، راجع أيضاً مقارنة Claude Code وCodex.

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

الأسئلة الشائعة FAQ

هل يمكن لـ Jev أن يحل محل Claude Code أو Codex أو نماذج المحادثة؟ لا. يصنّفه TypeSafe كنموذج قرارات مهيكلة داخل البرمجيات؛ أما المحادثة والكتابة وتوليد الكود فلا تزال بحاجة إلى LLM.

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

كم سؤالاً يمكن طرحه في الطلب نفسه؟ يمكن وضع عدة أسئلة مستقلة من نوع Choice وScore وNoul تشترك في state نفسه داخل طلب واحد. تُقيَّم الأسئلة كل على حدة، لكن الأحكام المعقدة ينبغي مع ذلك تقسيمها، ثم يجمعها الكود.

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