نموذج Jev للذكاء الاصطناعي صُمم للقرارات لا للنثر

تصف TypeSafe AI نموذج Jev بأنه نموذج جديد قائم على المحولات، لكنه ليس نموذجًا لغويًا كبيرًا. بدلًا من توليد tokens نصية، يعيد احتمالات على مخرجات يحددها المطورون مسبقًا. تقول TechCrunch إن TypeSafe تسمي هذه المخرجات «قرارات معايرة».

وفقًا للتقرير، لهذا التصميم ثلاث نتائج فورية.

أولًا، يجري تقديم النموذج بوصفه أرخص وأسرع من استخدام نموذج LLM عام لأعمال شبيهة بالتصنيف. وتفيد TechCrunch بأن tokens المخرجات في Jev مجانية، وأن tokens المدخلات تُقاس بالمليار لا بالمليون.

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

ثالثًا، ذلك الاحتمال جزء من المنتج، وليس تفصيلًا لاحقًا. قال Armin Ronacher، المدير التقني في Earendil، لـ TechCrunch إن Jev «يفوّض مشكلة الهلوسة قليلًا إلى المستخدم». إذا عادت نتيجة بنسبة 50%، فقد يتجاهلها التطبيق. وإذا عادت بنسبة 95%، فقد يتخذ التطبيق إجراءً.

هذا الفرق مهم. كثير من أتمتة الذكاء الاصطناعي لا تفشل لأن النموذج ليس مفيدًا أبدًا، بل لأن البرمجيات لا تستطيع معرفة متى يكون النموذج مجرد مُخمّن. يحاول المطورون غالبًا استعادة الثقة عبر مطالبة نموذج LLM بأن يشرح نفسه، أو يصوّت مع نفسه، أو يُصدر JSON منظمًا. يُسوَّق Jev كنموذج تكون فيه درجة الثقة هي جوهر الفكرة.

تفيد TechCrunch بأن اهتمام المطورين كان مرتفعًا بما يكفي لأن تفقد TypeSafe AI مؤقتًا القدرة على خدمة المستخدمين عبر API الخاصة بها. ويضع المقال جاذبية Jev المبكرة في إطار أتمتة البرمجيات: مطورون يستخدمون الذكاء داخل الشيفرة، لا كواجهة دردشة.

يعرض مثالان في التقرير شكل هذا الطلب.

قال Pranit Sharma، مهندس برمجيات في Vercel، لـ TechCrunch إن Vercel استخدمت نموذجًا من OpenAI لتشغيل مصنّف يراجع الأوامر من ناحية السلامة. وعندما استبدلت Vercel نموذج Luna من OpenAI بـ Jev، قال Sharma إنها حصلت على نتائج أسرع بخمس إلى 18 مرة وبدقة أعلى.

اختبر Nikhil Mudholkar، المدير التقني في Bryo AI، نموذج Jev مقابل Gemini لتصنيف رسائل البريد الإلكتروني التجارية، وفقًا لـ TechCrunch. في اختباره، كان Gemini أدق قليلًا، لكنه أغلى من 10 إلى 20 مرة. وأبرز Mudholkar درجات الثقة في Jev، قائلًا إنه «الوحيد الذي يعيد احتمالًا حقيقيًا»، ما جعله مفيدًا لأتمتة سير العمل.

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

تشمل الأمثلة:

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

إذا صمدت ادعاءات Jev المبكرة خارج الأمثلة التي أوردتها TechCrunch، فإنه يندرج في مساحة التصميم العملية نفسها مثل استدعاء الأدوات والمخرجات المنظمة: تحويل سلوك النموذج إلى عقود يمكن للبرمجيات استهلاكها.

أحد أكثر الاستخدامات إثارة للاهتمام في تقرير TechCrunch ليس استبدال نماذج LLM، بل تحديد متى ينبغي استخدامها.

قال Ronacher لـ TechCrunch إن Jev قد يكون مفيدًا لتوجيه النماذج: التنبؤ بما إذا كان عبء عمل معين يحتاج إلى نموذج محدد. استخدام نموذج LLM لاتخاذ ذلك القرار قد يكون مكلفًا. يمكن لنموذج أرخص وأسرع يعيد درجة معايرة أن يقف أمام حزمة نماذج ويقرر إلى أين ينبغي أن يذهب كل طلب.

هذه مشكلة مألوفة لأي شخص يبني باستخدام نماذج متعددة. أقوى نموذج ليس ضروريًا دائمًا. أرخص نموذج ليس آمنًا دائمًا. بعض prompts تحتاج إلى استدلال بسياق طويل؛ وأخرى تحتاج إلى مصنّف سريع؛ وأخرى تحتاج إلى صورة أو صوت أو أداة استرجاع. يجب على الموجّه تقدير المهمة قبل إنفاق الميزانية.

وهنا أيضًا تصبح صيغة Jev مهمة. لا يحتاج الموجّه إلى مقالة عن سبب صعوبة prompt. إنه يحتاج إلى قرار مثل:

• الإرسال إلى نموذج صغير؛
• الإرسال إلى نموذج frontier؛
• استرجاع المستندات أولًا؛
• طلب موافقة بشرية؛
• الرفض باعتباره غير آمن.

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

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

تفيد TechCrunch أيضًا بأن Almeida يرى استخدام Jev لمراقبة آثار وكلاء LLM ومنع محاولات jailbreak. حجة التكلفة مباشرة. إذا كان لا بد من فحص كل إجراء من الوكيل بواسطة نموذج LLM كامل آخر، فقد تصبح طبقة السلامة مكلفة. وإذا استطاع نموذج قرارات أصغر أن يعلّم السلوك المريب بتكلفة منخفضة، فستتمكن تطبيقات أكثر من تحمل تكلفة المراقبة المستمرة.

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

لكن البنية نظيفة:

1. يقترح وكيل خطوة أو ينفذها؛
2. يقيم نموذج قرارات الخطوة؛
3. يحظر النظام أو يسمح أو يسجل أو يصعّد؛
4. يراجع الإنسان فقط الحالات التي تحتاج إلى مراجعة بشرية.

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

بالنسبة إلى الفرق التي تبني سير عمل مستقلًا، فالدروس ليست «استبدلوا عمل السلامة لديكم بـ Jev». بل إن السلامة يمكن فصلها عن التوليد. يمكنكم تصميم وكلاء يستخدمون نموذجًا للتصرف، ونموذجًا آخر أو مصنّفًا للمراقبة، وطبقة موافقة بشرية للإجراءات غير القابلة للتراجع. يظهر المبدأ نفسه في موافقات human-in-the-loop وفي الأنظمة متعددة الوكلاء حيث يتحقق مكوّن من مكوّن آخر قبل متابعة العمل.

ما زالت البنية غامضة جزئيًا. تقول TechCrunch إن Almeida «متحفظ» بشأن التفاصيل الداخلية لـ Jev، بينما يشتبه مراقبون خارجيون في أنه مبني فوق نموذج LLM مفتوح الأوزان. تسمي TypeSafe AI نموذج Jev «نموذج System One»: نموذج محسّن لقرارات سريعة شبيهة بالحدس بدلًا من الاستدلال الصريح، مع تصميم أضيق ملائم للمهمة.

قال Almeida لـ TechCrunch إن Jev يُدرّب حصريًا على بيانات اصطناعية باستخدام تقنية يسميها «التعلم المعزز من القرارات المعايرة». وقال أيضًا إن TypeSafe AI راهنت مبكرًا على صنع كل بياناتها بنفسها. ووصف جزءًا من الشركة بأنه مختبر يركز على «بيانات اصطناعية مفهومة إحصائيًا بصورة جيدة».

هناك ما يكفي لفهم فرضية المنتج، لكن ليس ما يكفي لتقييم طريقة التدريب تقييمًا مستقلًا. لا نعرف من تقرير TechCrunch كيف تُقاس المعايرة، ولا مدى متانتها خارج التوزيع، ولا كيف يتعامل النموذج مع المدخلات العدائية، ولا كيف يتغير الأداء عبر المجالات.

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

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

سُمّي Jev على اسم William Stanley Jevons، الاقتصادي في القرن التاسع عشر المرتبط بمفارقة Jevons: عندما يصبح استخدام مورد ما أكثر كفاءة، يمكن أن يرتفع إجمالي الاستهلاك بدلًا من الانخفاض. قال Almeida لـ TechCrunch إن TypeSafe AI تتوقع أن يؤدي الذكاء الأرخص إلى «برمجيات ذكية في كل مكان»، أقرب إلى الإنترنت المبكر منها إلى عالم تهيمن عليه «تطبيقات عملاقة» فقط.

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

سيكون هذا تحولًا مهمًا. كانت واجهة حقبة ChatGPT هي الدردشة. يشير Jev إلى الاستدلال المضمّن: قرارات غير مرئية، ضيقة، ومتكررة تجعل البرمجيات تتكيف في الوقت الفعلي.

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

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

الحقيقة المهمة ليست أن Jev «أفضل من نماذج LLM». لا يثبت تقرير TechCrunch ذلك، والأمثلة أضيق من أن تسمح بهذا الاستنتاج. الحقيقة المهمة هي أن المطورين يبدون اهتمامًا بنموذج مصمم لقرارات البرمجيات بدلًا من المحادثة البشرية.

ينبغي أن يغيّر ذلك طريقة صياغة الفرق لبنية الذكاء الاصطناعي.

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

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

الخلاصة العملية لا تتعلق كثيرًا باستبدال نماذج LLM، بل باختيار شكل النموذج الصحيح لكل قرار.

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

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

Jev هو نموذج من TypeSafe AI يوصف بأنه قائم على المحولات لكنه ليس نموذجًا لغويًا كبيرًا. بدلًا من كتابة النص، يعيد احتمالات على مخرجات يحددها المطورون مسبقًا.

يولّد نموذج LLM العام tokens لغوية، بينما صُمم Jev للاختيار بين مخرجات محددة مسبقًا وإرفاق احتمال. وهذا يجعله أنسب لقرارات البرمجيات من المحادثة المفتوحة النهاية.

يهتم المطورون به لأن كثيرًا من أعباء عمل الذكاء الاصطناعي تحتاج إلى فرع أو تسمية أو قرار سلامة موثوق بدلًا من فقرة. أوردت TechCrunch اختبارات مبكرة كان فيها Jev أرخص أو أسرع في حالات استخدام تصنيف محددة.

يناقش المقال حالات استخدام مثل مراجعة سلامة الأوامر، وتصنيف البريد الإلكتروني التجاري، ومراقبة الوكلاء، وتوجيه النماذج، وفرز سير العمل، وحواجز الأمان لوكلاء LLM.

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