Perplexity Decider

نطلق Decider v1.3 وDecider Flash v1.3، وهما الإصداران اللذان يخلفان نماذج القرار السابقة لدينا: v1، وv1.1، وv1.2، وFlash v1.2.

Decider Flash v1.3 هو نموذج أصغر مُقطَّر من Decider v1.3. ويتوفر كلا النموذجين على Hugging Face بموجب ترخيص Apache، ومن خلال OpenRouter، وPerplexity Decisions API.

استُلهم Perplexity Decider من Jev، وهو System One Model من TypeSafe AI. ويدعم التصنيف الثنائي ومتعدد الفئات بتسميات مرتبة أو غير مرتبة، ويُرجع احتمالات يمكن للتطبيقات استخدامها لتصنيف المدخلات وتوجيهها وترتيبها وتقييمها.

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

في هذه المقالة، نشرح كيف ندرّب Decider ونقيّمه، ونشارك كيف نستخدمه داخليًا في Perplexity.

ما هو نموذج القرار؟

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

• نعم / لا: قرارات ثنائية.
• الاختيار من متعدد: تسميات مخصصة متعددة الفئات.
• الدرجة: مستويات مرتبة.

تدعم نماذج القرار مجموعة واسعة من مهام التصنيف والتقييم بالدرجات:

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

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

التدريب

تحويل نموذج لغوي كبير توليدي إلى نموذج قرار

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

على سبيل المثال، بالنظر إلى مستند وملخصه، يمكن لطلب واحد أن يسأل عمّا إذا كان الملخص يمثّل المستند بأمانة، وما إذا كان موجّهًا إلى خبير أو إلى جمهور عام. وبعد الحالة، تحتوي كل كتلة أسئلة على سؤال وإجاباته المحتملة، ويُسنَد إلى كل إجابة رمز تسمية محدد مسبقًا مثل A أو B أو C. ويشير رمز <|marker|> الخاص إلى الموضع الذي يُقرأ منه تنبؤ النموذج. وفي هذا الموضع، تحوّل طبقة إخراج خطية مُتعلَّمة (رأس القرار) الحالة المخفية إلى درجات لخيارات الإجابة عن السؤال، ثم تُحوَّل هذه الدرجات إلى احتمالات.

تكبير

نُهيّئ طبقة الإخراج من النموذج الأساسي، التي تُقيّم عادةً الرمز التالي من المفردات بأكملها، ونحتفظ فقط بالصفوف المقابلة لرموز الخيارات المحددة مسبقًا مثل A أو B أو C. ثم تُدرَّب هذه الطبقة المُقلَّصة على تحويل الحالة المخفية لـ <|marker|> إلى درجات للإجابات. ويغطي هذا النهج جميع أسئلة التصنيف لأنه يمكن صياغتها جميعًا كأسئلة اختيار من متعدد.

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

في الإصدار v1.3، نقدّم locate، التي تستخرج النص من الحالة بدلًا من الاختيار من بين خيارات محددة مسبقًا. يصف سؤال locate ما يجب العثور عليه، باستخدام إما تسمية قصيرة مثل «الموقع» أو تعليمات مثل «استخرج اسم المدينة التي تقع فيها الوظيفة.» ويُرجع النموذج النص المطابق تمامًا من الحالة، إلى جانب موضعي حرفي البداية والنهاية. وإذا لم يعثر على أي تطابقات، فإنه يُرجع قائمة فارغة.

تكبير

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

الانتباه ثنائي الاتجاه: تمكين النموذج من القراءة في الاتجاهين

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

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

• كل شيء يرى كل شيء (v1.2): تُعالَج الحالة وجميع الأسئلة معًا باستخدام انتباه كامل ثنائي الاتجاه. وتكون الحسابات على الحالة مشتركة، لكن الإجابة عن سؤال ما قد تتغير تبعًا للأسئلة الأخرى المطروحة.
• أسئلة معزولة (v1.3): تنتبه الحالة إلى جميع الأسئلة، بينما ينتبه كل سؤال إلى الحالة ورموزه فقط. ولا يزال بإمكان الأسئلة التأثير بعضها في بعض بشكل غير مباشر عبر الحالة المشتركة، لكن النتائج تكون أكثر استقرارًا.
• قابل للتخزين المؤقت بالكامل: تنتبه الحالة إلى نفسها فقط، بينما ينتبه كل سؤال إلى الحالة وإلى رموزه الخاصة. الحالة مستقلة عن الأسئلة ويمكن إعادة استخدامها عبر الطلبات للاستفادة من التخزين المؤقت للمطالبات. لا نستخدم هذا الوضع افتراضيًا، لأن السماح للحالة برؤية الأسئلة مهم جدًا لعدد من المهام، لكن ضبطًا دقيقًا بسيطًا يمكنه تحويل النموذج إليه.

في النهاية، اخترنا الأسئلة المعزولة لأدائها القوي واستقرارها.

تكبير

وصفة التدريب

يمر التدريب بثلاث مراحل لكلا حجمَي النموذج. ندرّب أولًا النموذج الأكبر، المبني على Qwen3.8-27B، باستخدام الإنتروبيا المتقاطعة على مجموعات بيانات كبيرة، ثم نقطّره في النموذج الأصغر Qwen3.5-4B.

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

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

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

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

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

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

إضافة القدرة على استخراج المعلومات

ميزة locate تستخرج المعلومات، مثل الكيانات المسماة، من النص دون تغيير طريقة إجابتها عن الطلبات العادية. ولتحقيق ذلك، نضيف مرحلة تدريب إضافية: نضيف إلى Decider رمزًا خاصًا جديدًا، <|locate|>، ورأس نطاق (span head)، ومحوّل LoRA.

نُهيّئ تضمين <|locate|> انطلاقًا من <|marker|> الذي جرى تعلّمه في مراحل التدريب السابقة. ونُدرّب هذا التضمين الجديد ورأس النطاق ومحوّلات LoRA فقط، مع إبقاء أوزان البنية الأساسية الأصلية ورأس القرار مُجمَّدة. ويحصل كل حقل مطلوب على رمز <|locate|> خاص به.

يستخدم رأس المقاطع تمثيلَ <|locate|> مع تمثيلات رموز الحالة لتقييم مواضع بداية المقاطع المطابقة ونهايتها، وتحديد أزواج البداية والنهاية التي تنتمي إلى بعضها. ويستخدم أيضًا تمثيلَ الرمز <|locate|> للتنبؤ بعتبات خاصة بكل حقل لهذه الدرجات. تُعاد المقاطع المحددة على هيئة مواضع أحرف في النص الأصلي.

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

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

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

التقييم

نقيّم Decider v1.3 وDecider Flash v1.3 على مقاييس معيارية خارجية من Hugging Face Decision Index، وClaimBench من Vals AI، وArtificial Analysis Decision Index.

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

داخليًا، أنشأنا مجموعة تضم أكثر من 200 مهمة تشمل مجالات متنوعة ومهام مثل التصنيف، والتقييم بالدرجات، وإعادة الترتيب، واستخراج الكيانات. ولتقييم أداء Decider في العالم الحقيقي بنزاهة، تُجرى جميع التقييمات بأسلوب التعلّم الصفري (zero-shot)، دون ضبط دقيق خاص بالمهام، مما يمنحنا مؤشرًا واضحًا على الجوانب التي ينبغي تحسينها في النموذج.

تصنيف الاستعلامات

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

عبر 63 مهمة تصنيف أُعيد تصنيف مراجعها بشكل مستقل بواسطة نموذج لغوي كبير متقدم، يحقق Decider v1.3 متوسط دقة يبلغ 91.6%، متجاوزًا مصنفات الإنتاج لدينا بفارق 6.54 نقطة مئوية. كما يتفوق Decider Flash v1.3 على نموذج الإنتاج المرجعي، بينما يتفوق Decider v1.3 على Jev 1.14.

تكبير

التصنيف الخاص بالمجال

جمعنا مجموعة تقييم خاصة بالمجالات من مجموعات بيانات عامة لتقييم أداء نماذج القرار في التصنيف عبر سبعة مجالات: التحقق من الادعاءات (6 مهام)، والرعاية الصحية (7)، والأمن السيبراني (8)، والبرمجة (16)، والحكومة (7)، والقانون (9)، والمالية (9).

على سبيل المثال، «تقييم التعقيد الزمني لبرنامج Python»، أو «استخدام تقرير مالي سنوي لتحديد ما إذا كان النقد غير المقيد لدى الشركة يغطي أصل الدين المستحق خلال الاثني عشر شهرًا القادمة». يتصدر Decider v1.3 جميع المجالات السبعة، متفوقًا على Jev 1.14 بما يصل إلى 12.9 نقطة مئوية في المالية و9.3 نقطة في القانون. ويتأخر Decider Flash v1.3 عن Jev 1.14 في المالية والبرمجة والقانون، ويقدّم أداءً مماثلًا في المجالات الأخرى.

تكبير

الاسترجاع وإعادة الترتيب

البحث هو جوهر Perplexity. ونحتفظ بمجموعة واسعة من مهام الاسترجاع لتقييم أداء نماذجنا في إعادة الترتيب. ولكل مهمة، نستخدم أولًا مجموعة من نماذج التضمين لاسترجاع أفضل 50 مستندًا مرشحًا من كل مجموعة نصوص. ثم نعيد ترتيب هذه المستندات المرشحة باستخدام Decider ونقارن أداءه بنموذج مرجعي قوي لإعادة الترتيب، هو Qwen3-Reranker-8B.

نقيّم Decider في إعداد نقطي (pointwise) بأسلوب التعلّم الصفري، إذ نستخدم النموذج لتقييم كل زوج من الاستعلام والمستند بالدرجات مباشرةً وبشكل مستقل، ثم نرتب المستندات حسب الصلة. وعبر 72 مهمة استرجاع، يحقق Decider v1.3 متوسط nDCG@10 قدره 83.99، متفوقًا على Qwen3-Reranker-8B بفارق 1.81 نقطة وعلى Jev 1.14 بفارق 2.24 نقطة.

على معيار BEIR، يتفوق كلا النموذجين على Qwen3-Reranker-8B بفارق 8.78 و7.05 في nDCG@10 على التوالي. وبالمقارنة مع Jev 1.14، يتفوق Decider v1.3 بفارق 1.33 نقطة، بينما يقل إصدار Flash عنه بفارق 0.4 نقطة.

تكبير

التصنيف متعدد اللغات

لتقييم نماذج القرار بما يتجاوز اللغة الإنجليزية، جمعنا معيارًا لتقييم التصنيف متعدد اللغات يضم 19 مهمة خاصة بلغات محددة من 8 مجموعات بيانات عامة، مع 46,484 مثالًا عبر ثماني لغات: الألمانية، والإسبانية، والفرنسية، والإيطالية، والروسية، واليابانية، والكورية، والصينية. ويغطي المعيار اكتشاف النية، وتصنيف الموضوعات، وتحليل المشاعر، والاستدلال باللغة الطبيعية، واكتشاف إعادة الصياغة، واكتشاف اللغة المسيئة، والمقبولية النحوية.

نُبلغ عن متوسط الدقة عبر المهام ضمن كل لغة، مع منح كل مهمة وزنًا متساويًا. يتفوق Decider v1.3 على Jev 1.14 في جميع اللغات الثماني، ويحقق Decider Flash v1.3 ذلك في ست لغات، بمتوسط دقة للمهام يبلغ 88.16% لـ Decider v1.3 و86.50% لـ Decider Flash v1.3، مقارنةً بنسبة 85.41% لـ Jev 1.14.

تكبير

التعرّف على الكيانات المسماة (NER)، وPII، والإجابة الاستخراجية عن الأسئلة

نقيّم ميزة locate على 17 مهمة خارج النطاق تختبر قدرتها على الاستخراج عبر مجالات متنوعة، وتنسيقات إدخال مختلفة (نصوص، وجداول، ومستندات منظمة)، وتعليمات متنوعة (تسميات قصيرة، وأسئلة، وأوصاف مفصلة). وتتراوح المجالات من Wikipedia إلى الأوراق العلمية، وتقارير التهديدات السيبرانية، والدعم الفني، وسياسات الخصوصية، والسير الذاتية، والعقود القانونية. وتتراوح الطلبات من أسماء تسميات قصيرة مثل «شخص» أو «عنوان البريد الإلكتروني»، مرورًا بأسئلة حول جدول أو تذكرة دعم، وصولًا إلى أوصاف حقول مفصلة للاستخراج المنظم، مثل أطراف اتفاقية عدم الإفصاح (NDA) أو الإجمالي في فاتورة.

نقيّم NER وPII باستخدام مقياس F1 للمقاطع المطابقة تمامًا، الذي يتطلب أن تطابق المقاطع المتوقعة حدود المرجع تمامًا. وتستخدم الإجابة الاستخراجية عن الأسئلة مقياس F1 على مستوى الأحرف، مما يمنح درجة جزئية لنص الإجابة المتداخل، بينما يستخدم الاستخراج المنظم دقة الحقول، أي نسبة الحقول المستخرجة بشكل صحيح. ولتحليل السير الذاتية، نحسب متوسط درجات F1 للمقاطع المطابقة تمامًا في NER وPII.

نقارن نماذجنا بنماذج استخراج متعددة الأغراض بأحجام مختلفة: GLiNER large v2.5 (0.5B)، وLiquid d1 (2B)، وClairic من Cloudflare (حجم غير مُعلَن). يصل Decider v1.3 إلى متوسط درجة يبلغ 69.0 (باستخدام المقياس الأساسي لكل مهمة)، ويصل Decider Flash v1.3 إلى 63.6، مقارنةً بـ 43.3 لـ Liquid d1، و41.5 لـ Clairic، و33.6 لـ GLiNER large v2.5. ويتصدر كلا نموذجي Decider في كل فئة.

تكبير

تصنيف الصور

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

يحقق Decider v1.3 متوسط دقة يبلغ 76.99% عبر المهام المرئية الخمس، متفوقًا على Jev 1.14 بفارق 1.47 نقطة مئوية. ويحقق Decider Flash v1.3 نسبة 72.77%، مما يُظهر قدرات التصنيف المرئي في نموذج أصغر.

تكبير

طلبات القرار الواقعية

أخذنا عينة من مليون طلب أُزيلت منها التكرارات وأُخفيت فيها بيانات PII، قُدِّمت إلى Perplexity Decision API خلال أول 18 يومًا من إتاحتها. ولأن كل طلب قد يحتوي على أسئلة متعددة حول الحالة نفسها، فإن العينة تضم 2,318,887 سؤالًا فرديًا. وقد أُدرجت جميع الطلبات بإذن صريح من المستخدمين لأغراض البحث.

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

توزيع المهام غير متكافئ: يستحوذ استخراج المعلومات على 425,402 سؤالًا، وتصنيف المجالات على 409,564، وتحليل المشاعر على 344,158. وتشكّل هذه الفئات الثلاث معًا 50.8% من الأسئلة في العينة.

يحقق Decider v1.3 أعلى نسبة اتفاق مع المُحكِّمين بلغت 93.98%، مقارنةً بنسبة 93.68% لـ Decider v1.2 و93.35% لـ Jev 1.14. ويتقارب Decider v1.3 وJev 1.14 بشدة في تصنيف المجالات وتحليل المشاعر، بفارق 0.34 و0.07 نقطة مئوية على التوالي. ويتقدم Jev بفارق 0.69 نقطة في ترتيب الصلة، بينما يتقدم Decider v1.3 بفارق 0.93 نقطة في استخراج المعلومات (المهمة الأكثر شيوعًا في العينة) وبفارق 1.21 نقطة في النية والتوجيه.

تكبير

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

تكبير

المتانة

قيّمنا الحساسية للتسميات على 372 سؤالًا متعدد الخيارات، بإجراء 4,788 طلبًا لكل نموذج. أعدنا ترتيب الخيارات، وأعدنا إسناد التسميات إلى نصوص الإجابات، وغيّرنا أسماء التسميات مع الحفاظ على معنى كل سؤال، ثم تحققنا مما إذا كانت الإجابة الدلالية للنموذج قد تغيرت. وتشير معدلات التبدّل الأقل إلى استقرار أكبر.

غيّر Decider v1.3 إجابته في 0.27% فقط من الأسئلة في ظل كل تحويل، مقارنةً بنسبة تتراوح بين 2.69% و4.84% لدى Jev 1.14. كما كررنا مدخلات متطابقة لقياس التباين أثناء تقديم الخدمة: لم يُظهر Decider v1.3 أي تغييرات، في حين تغيّرت إجابات Jev 1.14 في 1.88% من الأسئلة.

تكبير

كيف نستخدم Decider

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

قواعد أمان ذاتية التحسين

نستخدم Decider داخليًا بالفعل لتحسين سياسات الأمان لدينا.

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

في يوم واحد، قرأ Decider مليار رمز عبر 7,000 جلسة وكيل، وحدد عيوبًا أدت إلى 14 إصلاحًا للقواعد، تمت الموافقة على 6 منها وطرحها خلال يومين. وعند إعادة تشغيلها على سجلات أسبوع كامل، خفّضت الإصلاحات حجم ما تُطلقه القاعدة الأكثر نشاطًا لدينا بنسبة 52%، ورصدت القواعد الموسّعة نحو 40% من الإجراءات المشروعة الإضافية التي تستدعي التحقيق.

تكبير

مراقبة عمليات التنفيذ في التعلم المعزز

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

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

تكبير

تصفية الصفحات حسب الجودة

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

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

تكبير

إلى جانب هذه الاستخدامات الداخلية، يلائم Decider أيضًا أنواعًا من سير العمل مثل ما يلي.

الإجابة عن الأسئلة المرئية

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

تكبير

التنقل في المتصفح

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

تكبير

تخطيط المهام البحثية

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

تكبير

البدء

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

نوصي باستخدام Decider v1.3 للأحكام الدقيقة، ومعايير التقييم المفصلة، وسير العمل الذي تكون فيه الأخطاء مكلفة. اختر Decider Flash v1.3 للتوجيه والتصنيف والتصفية بكميات كبيرة حيث يكون زمن الاستجابة والتكلفة هما القيدين الرئيسيين. قيّم كلا النموذجين على أمثلة تمثيلية من عبء عملك، ثم اختر النموذج الذي يلبي متطلباتك من حيث الجودة وزمن الاستجابة والميزانية.

يتوفر كلا النموذجين كأوزان قابلة للتنزيل على Hugging Face بموجب ترخيص Apache، ومن خلال OpenRouter، وPerplexity Decisions API.

الاستشهاد

@online{perplexity2026PerplexityDecider,
  author = {{Perplexity} and Antoine Chaffin and Jonas Golde and Louis Milliken and Sarah Eslami and Markus Krimmel and Nandor Licker and Aleksandr Nikolenko and Ron Heichman and Bo Wang and Jarrod Bryan and Jeremy Yang and Denis Yarats},
  title = {{Perplexity Decider}},
  date = {2026-11-12},
  url = {https://www.perplexity.ai/hub/blog/perplexity-decider}
}