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

عن المسابقة

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

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

يمكنك قراءة المزيد عن المسابقة هنا .

تحدي المنافسة

مهمة المسابقة كلاسيكية بالنسبة لأنظمة التوصية: قم بإنشاء توصيات من الدرجة الأولى للمستخدم ومعرفة تاريخ تصرفاته ، ولكن بدلاً من عنصر المستخدم المعتاد ، يظهر مسار التشغيل هنا. بعبارات أكثر رسمية ، تم تقديم أجزاء من قوائم التشغيل (المشار إليها فيما بعد باسم البذور) في بيانات الاختبار ، وكانت هناك عدة طرق مختلفة لتكوينها. بالنسبة إلى K = (5 ، 10 ، 25 ، 100) كانت هناك بذور مع أول مسارات K ومسارات K تم اختيارها عشوائيًا. كانت هناك أيضًا بذور ذات المسار الأول وفقط باسم قائمة التشغيل. يجب توقع المسارات التي لم يتم تضمينها في عمليات التعليق. لكل قائمة تشغيل ، كانت هناك حاجة إلى 500 تنبؤات بالضبط.

المقاييس

كانت إحدى ميزات المسابقة هي أن المقياس لم يكن واحدًا ، كما هو معتاد في معظم المسابقات ، ولكن العديد منها. أدناه سأقول عن كل واحد منهم.

R الدقة

يوضح هذا المقياس نسبة المسارات التي خمناها.

$$$R-precision = \ frac {| G \ cap {} R_ {1: | G |} |} {| G |}$

NDCG

هذا مقياس جودة تصنيف كلاسيكي ، يمكنك أن تقرأ عنه ، على سبيل المثال ، هنا

النقرات

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

بعد ذلك ، يتم تعيين الفرق لكل تصنيف من المقاييس. ثم يتم تجميع الرتب وفقًا لمخطط بوردا لاستراتيجية الانتخابات. إذا $$$ع$هو عدد المشاركين ، ثم يحصل فريق برتبة 1 $$$ف -1 دولا$نقاط ، يتلقى فريق برتبة 2 $$$ف -2 دولا$نقاط وهلم جرا.

الحل

مخطط التحقق من الصحة

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

اختيار المرشحين

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

اختيار المرشحين باستخدام عامل المصفوفة

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

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

WARP الخسارة

وظيفة الخسارة هذه أفضل من غيرها في ترتيب المهام. إنه يعمل مع ثلاثة أضعاف (user ، positive_item ، negative_item) ولديه ميزة واحدة مهمة للغاية - لا يحدث اختيار الأمثلة السلبية عن طريق الصدفة ، ولكن بطريقة تجعل الأمثلة السلبية المحددة "تكسر" التصنيف الحالي للنموذج ، أي كانت أعلى من مثال إيجابي.

وبالتالي ، فإن إجراء تدريب نموذج باستخدام خسارة WARP سيكون على النحو التالي:

1. للزوجين $$$(مستخدم ، موجب \ _ عنصر)$سنختار مثالًا سلبيًا عشوائيًا بين جميع العناصر الأخرى (من المهم أن نفهم أن هذا الأمر يستحق القيام به فقط إذا كان احتمال اختيار مثال سلبي ، والذي سيكون إيجابيًا بالفعل ، صغيرًا جدًا). حساب التنبؤ الزوج $$$(مستخدم ، موجب \ _ عنصر)$و $$$(مستخدم ، سلبي \ _ عنصر)$وإذا لم يكن هناك أي اضطراب (وهذا يعني أن النموذج توقع درجة أعلى لمثال إيجابي) ، فسوف نستمر في أخذ عينات سلبية حتى حدوث الانتهاك.
2. إذا تلقينا انتهاكًا في المحاولة الأولى ، فيمكننا اتخاذ خطوة تدرج كبيرة ، لأن هذا يعني أن النموذج في الوقت الحالي يضع في كثير من الأحيان أمثلة سلبية أعلى من الأمثلة الإيجابية ويجب علينا تحديث أوزانه بقوة. إذا اضطررنا إلى البحث عن مثال سلبي مناسب لفترة طويلة ، فإننا نخطو خطوة صغيرة - النموذج مدربين بالفعل جيدًا.

يمكن العثور على وصف أكثر رسمية لخسارة WARP في المقالة الأصلية أو في هذا المنشور .

Lightfm

استخدم الإصدار الأول من النموذج معلومات تعاونية فقط: وجود مسار track_id في قائمة التشغيل playlist_id ، تم تقديمها كمصفوفة متفرق ثنائي. يتوافق عدد من المصفوفات مع قائمة تشغيل ، عمود إلى مسار.

$$$score (p، t) = b_t + b_t + <q_p، q_t>$

ميزات النص LightFM +

يستخدم هذا النموذج زخرفة الكلمات من اسم قائمة التشغيل بدلاً من playlist_id. تضمين قائمة التشغيل هو مجموع زخارف كلماته.

$$$score (p، t) = b_p + b_t + <q_p، q_t>$
$$$b_p = \ sum_ {i \ in {f_p}} {b_i}$، $$$q_p = \ sum_ {i \ in {f_p}} {q_i}$،
اين $$$f_p$- هذه هي الكلمات من اسم قائمة التشغيل.

وبالتالي ، فإننا نحل مشكلة البداية الباردة - يمكننا تقديم توصيات أفضل لقوائم التشغيل التي ليس لها سوى اسم.

قدم منظمو المسابقة أيضًا معلومات حول عدد المسارات الموجودة في الجزء المخفي من قائمة التشغيل. إذا كان الجزء الخفي $$$ك$المسارات ثم نختار $$$كحد أقصى (ك * 15 ، ك + 700) دولا$المرشحين. طبيعة هذه الأرقام هي إرشادية بسيطة ، تم اختراعها من الاعتبارات التالية: نريد أن يكون لدينا عدد كافٍ من المرشحين لقوائم التشغيل الصغيرة (وبالتالي $$$ك + 700 دولا$) ، ونريد أيضًا أن تحتوي مجموعة البيانات النهائية على حوالي 10 ملايين صف لأسباب تتعلق بالأداء من حيث الوقت والذاكرة (وبالتالي ، k 15 ، وليس k 50 ، على سبيل المثال).

الترتيب

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

في مجموعة بيانات التدريب الخاصة بنا ، سيحتوي كل صف على علامات للزوج (قائمة التشغيل ، المسار) ، وستكون العلامة 1 إذا كان هناك مسار في قائمة التشغيل و 0 إذا لم يكن كذلك.

كعلامات ، تم استخدام عدة مجموعات مختلفة.

الميزات على أساس نموذج LightFM

كما هو موضح أعلاه ، في نموذج LightFM وصلنا المتجهات $$$q_p ، q_t$والقيم $$$b_p ، b_t$.
كما علامات سوف نستخدم $$$b_p ، b_t$، < $$$q_p ، q_t>$وترتيب المسار t بين جميع المرشحين لقائمة التشغيل p (تم حساب الترتيب بالمعادلة ). هذه السمات الأربعة مأخوذة من طرازي LightFM و LightFM Text.

علامات على أساس المسار المشترك

هيا $$$n_ {i، j}$هو عدد قوائم التشغيل التي تحتوي على مقطوعات $$$i$و $$$j$معا كذلك $$$n_i$- عدد قوائم التشغيل التي تحتوي على المسار $$$i$. تم حساب هذه القيم على مجموعة ثابتة من قوائم التشغيل التي تتكون من جميع أجزاء البذور.

دع قائمة التشغيل $$$ع$يتكون من المسارات $$$t_1 ، t_2 ، ... ، t_n$. للمسار $$$t$احسب القيم $$$n_ {t، t_1}، n_ {t، t_2}، ...، n_ {t، t_n}$ولهم سوف نحسب إحصاءات مختلفة: الحد الأدنى والحد الأقصى والمتوسط ​​والمتوسط. ثم نحسب نفس الإحصائيات للكميات $$$\ frac {n_ {t، t_1}} {n_ {t_1}} ، \ frac {n_ {t، t_2}} {n_ {t_2}}، ...، \ frac {n_ {t، t_n}} { n_ {t_n}}$. في الحالة الأولى ، نراقب فقط عدد المرات التي التقى فيها المسار المستهدف مع المسارات من قائمة التشغيل ، وفي الحالة الثانية ، قمنا أيضًا بتطبيع هذا إلى تردد المسارات الأخرى. يساعد التطبيع النموذج على عدم إعادة تدريب المسارات الشائعة واستخراج المعلومات بشكل أكثر دقة حول مقدار تشابه المسارات.

علامات أخرى

يتم حساب جميع الخصائص للزوج. $$$(ع ، ر)$.

• عدد الفنانين الفريدين في قائمة التشغيل $$$ع$.
• عدد الألبومات الفريدة في قائمة التشغيل $$$ع$.
• عدد ونسبة المسارات في قائمة التشغيل $$$ع$مع نفس الألبوم / الفنان كما المسار $$$t$.
• كم مرة التقى المسار $$$t$في جميع قوائم التشغيل.
• كم مرة تتبع الفنان / الألبوم $$$t$في جميع قوائم التشغيل.
• عدد المسارات في أجزاء البذور والتعليق في قائمة التشغيل $$$ع$.

نموذج التوصية

لبناء التوصيات النهائية ، استخدمنا XGBoost . تم تدريب النموذج على $$$II_ {المرشحين}$، تم اختيار hyperparameters على $$$III_ {المرشحين}$بواسطة ROC AUC متري. تم اختيار هذا المقياس لأنه كلاسيكي لمشاكل التصنيف. ليست كل الميزات مفيدة على حد سواء ، لذلك سيكون من المثير للاهتمام أن ننظر إلى قيم أهمية الميزة للنموذج.

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

أخرى

الحديد

تم تدريب جميع الطرز على الخادم باستخدام Intel Xeon E5-2679 v3 (28 مركزًا و 56 موضوعًا) وذاكرة الوصول العشوائي 256 جيجابايت. استغرق التدريب النهائي على خط الأنابيب حوالي 100 ساعة واستهلك 200 جيجا بايت من الذاكرة في ذروته ، مع جزء كبير (حوالي 90٪) من الوقت الذي قضى في تدريب نموذج اختيار المرشحين. تم تدريب نموذج التصنيف بسرعة كبيرة - حوالي ساعتين (دون حساب اختيار المعلمات الفائقة).

فشل

ليس بدون فشل.

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

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

كود

تم تصميم حلنا على شكل أجهزة كمبيوتر محمولة Jupyter ويمكن إعادة إنتاجه (!) من خلال إطلاقها بالتتابع. لهذا الغرض فقط ، تحتاج إلى جهاز مزود بذاكرة الوصول العشوائي بسعة 200 جيجابايت + وبضعة أيام.

قرارات المشاركين الآخرين

يشارك الفريق الذي فاز بالمركز الأول بانتظام في تحدي RecSys ويحتل مراكز عالية. يشبه حلهم حلنا ، لكن يتم تنفيذه في Java .

لدى المتأهلين للنهائي الثاني مقاربة مثيرة للاهتمام - استخدموا Denoising Autoencoder لاستعادة قوائم التشغيل من أجزائها .

الخاتمة

إذا نظرت إلى لوحة المتصدرين النهائية ، فإن فريقنا يحتل المرتبة السادسة والرابعة في تصنيف المقاييس (R-Precision و NDCG) ، والأول في قياس النقرات. كيف حدث ذلك؟ وحدث ذلك بسبب وجود حل جيد لمشكلة البداية الباردة باستخدام نموذج نص LightFM. يفرض معيار النقرات غرامات أكبر عندما لا نتخيل مسارًا واحدًا من قائمة التشغيل. أدى استخدام نموذج نص LightFM إلى تحسين قياس متوسط ​​النقرات من 2.2 إلى 1.78.

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

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

إذا كان لديك أي أسئلة حول المقال ، فلا تتردد في طرحها في التعليقات :)

ملحوظة: لقد كتبنا مقالة أكثر تفصيلاً حول هذا الموضوع لورشة العمل في مؤتمر RecSys. الوصول إلى موادها على الموقع محدود ، لذا إذا كنت مهتمًا بمعرفة المزيد من التفاصيل حول حلنا ، فاكتب لي في PM.