الخلفية التقنية لميزة الاهتزاز للتلخيص

بعد أن أصبحت ميزة الاهتزاز للتلخيص متاحة على كلا النظامين iOS و Android منذ عدة أشهر، قررت موزيلا التعمق في العمل النموذجي (Modeling) الذي يقف وراء هذه الميزة. في منشور سابق، ناقشت الشركة عملية اختيار النموذج اللغوي، لكن الهدف الحالي هو توضيح نهج تطوير الأوامر (Prompt Development) وتحديداً في حالة استخدام وصفات الطبخ عبر الإنترنت.

تحدّي دقة التلخيص في المحتوى المتخصص

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

تصميم أوامر مخصصة لكل نوع محتوى

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

اكتشاف المشكلة في تلخيص وصفات العدس

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

حل مشكلة التوجيه عبر البيانات المهيكلة

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

نتائج الاختبارات والدروس المستفادة

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

المصادر

• Mozilla BlogUnder the Hood: Prompt tuning Shake to Summarize for recipes