بضع كلمات عن أنظمة الاقتراحات
بالتأكيد ، التقى بهم الجميع أكثر من مرة. أنظمة التوصية هي برامج وخدمات تحاول التنبؤ بما قد يكون مثيرًا للاهتمام / مطلوبًا / مفيدًا لمستخدم معين ، وتبين له ذلك. "هل تحب أحذية الجري هذه؟ قد تحتاج أيضًا إلى سترة واقية وجهاز مراقبة معدل ضربات القلب و 15 عنصرًا رياضيًا آخر " . في السنوات الأخيرة ، كانت العلامات التجارية نشطة للغاية في إدخال أنظمة التوصية في عملها ، حيث "يستفيد" البائع والمشتري من هذا القرار. يحصل المستهلكون على أداة تساعدهم على الاختيار في مجموعة لا حصر لها من السلع والخدمات في وقت قصير ، وينمو النشاط التجاري المبيعات والجمهور.
ماذا أعطي لنا؟
لقد عملت في مشروع لشركة عالمية كبيرة توفر لعملائها حل تبادل شحن SaaS أو منصة تبادل شحن.
يبدو الأمر غير مفهوم ، ولكن كيف يحدث ذلك بالفعل: من ناحية ، يتم تسجيل المستخدمين على المنصة الذين لديهم بضائع ويحتاجون إلى إرسالها إلى مكان ما. يضعون تطبيقًا مثل "هناك مجموعة من مستحضرات التجميل للزينة ، يجب أخذها غدًا من أمستردام إلى أنتويرب"وينتظرون إجابة. من ناحية أخرى ، لدينا أشخاص أو شركات مع شاحنات - ناقلات شحن. لنفترض أنهم قاموا بالفعل برحلتهم الأسبوعية القياسية ، حيث قاموا بتوصيل اللبن الزبادي من باريس إلى بروكسل. إنهم بحاجة إلى العودة ، ولكي لا يذهبوا بشاحنة فارغة ، يجب أن يجدوا نوعًا من البضائع لنقلها في طريق العودة. للقيام بذلك ، تذهب شركات الشحن إلى منصة عملائي وتجري بحثًا (من البحث باللغة الإنجليزية) ، مع الإشارة إلى الاتجاه وربما نوع الشحنة (أو الشحن من الشحن الإنجليزي) ، وهو مناسب لشاحنة. يقوم النظام بجمع الطلبات من الشاحنين وعرضها على شركات الشحن.
في مثل هذه المنصات ، يكون التوازن بين العرض والطلب مهمًا. هنا ، هناك طلب على البضائع من ناقلات البضائع والشاحنات من الشاحنين ، وكعرض ، العكس هو الصحيح: سيارات من شركات نقل وبضائع من شركات. يصعب الحفاظ على التوازن لعدد من الأسباب ، على سبيل المثال:
- اتصال مغلق بين الناقل والعميل. عندما يعمل السائق غالبًا مع عميل معين فقط ، فإنه لا يعمل بشكل جيد على النظام الأساسي. إذا غادر الشاحن السوق ، فقد تفقد الخدمة شركة النقل أيضًا ، لأنها تصبح عميلًا لشركة لوجستية أخرى.
- وجود بضاعة لا يريد أحد نقلها. يحدث هذا عندما تقدم الشركات الصغيرة طلبات النقل ، ثم لا يتم تحديثها ، وبالتالي ، تترك بسرعة عدد الشركات النشطة.
أرادت الشركة تحسين وظائف منصة تبادل الشحن الخاصة بها وزيادة تجربة المستخدم للمستخدمين حتى يتمكنوا من رؤية جميع إمكانيات النظام ومجموعة واسعة من البضائع ، وأيضًا عدم فقدان الولاء. يمكن أن يمنع هذا الجمهور المستهدف من التحول إلى خدمة تنافسية ويظهر لشركات الشحن أنه يمكن العثور على الطلبات المناسبة ليس فقط من الشركات التي اعتادوا العمل معها.
مع الأخذ في الاعتبار جميع الرغبات ، واجهت مهمة تطوير نظام توصية والذي سيُظهر على الفور عند مدخل المنصة لشركات النقل البضائع ذات الصلة المتاحة حاليًا وتخمين ما يريدون نقله وأين. كان من المقرر دمج هذا النظام في منصة تبادل الشحن الحالية.
كيف "نخمن"؟
يعمل نظام التوصيات لدينا ، مثل الآخرين ، على تحليل بيانات المستخدم. وهناك عدة مصادر يمكنك العمل عليها:
- أولاً ، افتح المعلومات حول طلبات نقل البضائع.
- ثانيًا ، توفر المنصة بيانات حول الناقل. عندما يبرم المستخدم عقدًا مع عملائنا ، يمكنه تحديد عدد الشاحنات التي يمتلكها ونوعها. ولكن ، للأسف ، بعد عدم تحديث هذه البيانات. والشيء الوحيد الذي يمكننا الاعتماد عليه هو بلد الناقل ، لأنه على الأرجح لن يتغير.
- ثالثًا ، يخزن النظام محفوظات عمليات بحث المستخدم لعدة سنوات: كل من أحدث الطلبات وقبل عام.
في التطبيق حيث قرروا تنفيذ نظام التوصية ، كانت هناك بالفعل آلية للبحث عن البضائع حسب الطلبات السابقة. لذلك ، قررنا التركيز على تحديد الأنماط أو الأنماط التي يبحث المستخدم من خلالها عن سلع للنقل. أي أننا لا نوصي بالتحميل ، ولكن حدد الاتجاه الأكثر ملاءمة لهذا المستخدم اليوم. وسنجد بالفعل البضائع باستخدام محرك البحث القياسي.
بشكل عام ، تستند عمليات البحث الشائعة إلى المعلومات الجغرافية والمعلمات الإضافية مثل نوع الشاحنة أو العنصر الذي يتم نقله. من السهل تتبع ذلك ، لأن هذه التفضيلات بالكاد تتغير. لقد قدمت أدناه بيانات طلبات أحد المستخدمين لمدة 3 أيام. ترتيب الملء كما يلي: عمود واحد - بلد المغادرة ، 2 - بلد المقصد ، 3 - منطقة المغادرة ، 4 - منطقة الوجهة.
يمكنك أن ترى أن هذا المستخدم لديه تفضيلات محددة في البلدان والمقاطعات. لكن هذا ليس هو الحال بالنسبة للجميع وليس دائمًا. في كثير من الأحيان يشير الناقل فقط إلى بلد المقصد أو لا يشير إلى منطقة المغادرة ، على سبيل المثال ، هو في بلجيكا ويمكنه القدوم إلى أي مقاطعة لاستلام الشحنة. بشكل عام ، هناك أنواع مختلفة من الاستعلامات: "بلد إلى بلد" أو "بلد إلى منطقة" أو "منطقة إلى بلد" أو "منطقة-منطقة" (الخيار الأفضل).
عينات الخوارزمية
كما تعلم ، تنقسم استراتيجيات إنشاء أنظمة التوصية بشكل أساسي إلى تصفية تعتمد على المحتوى وتصفية تعاونية. في هذا التصنيف ، بدأت في بناء الحلول.
أخذت الصورة من hub.forklog.com
تقول العديد من المصادر أن التصفية التعاونية تعمل بشكل أفضل. الأمر بسيط: نحن نحاول العثور على مستخدمين مشابهين لمستخدمينا ، ولديهم أنماط سلوك مماثلة ، ونوصي مستخدمينا بنفس الطلبات مثل طلباتهم. بشكل عام ، كان هذا الحل هو الخيار الأول الذي قدمته للعملاء. لكنهم اختلفوا معه وقالوا إنه لن ينجح. بعد كل شيء ، كل شيء يعتمد إلى حد كبير على مكان وجود الشاحنة الآن ، والمكان الذي نقلت فيه الحمولة ، والمكان الذي تعيش فيه ، والمكان الأكثر ملاءمة لها للذهاب. لا نعرف كل هذا ، ولهذا من الصعب الاعتماد على سلوك المستخدمين الآخرين ، حتى لو كانوا متشابهين للوهلة الأولى.
الآن حول الأنظمة القائمة على المحتوى. إنها تعمل على النحو التالي: أولاً ، يتم تحديد ملف تعريف المستخدم وإنشاءه ، ثم يتم إجراء مجموعة من التوصيات بناءً على خصائصه. إنه خيار جيد تمامًا ، ولكن في حالتنا هناك بعض الفروق الدقيقة. أولاً ، يمكن لمستخدم واحد إخفاء مجموعة كاملة من الأشخاص الذين يبحثون عن بضائع للعديد من الشاحنات وتسجيل الدخول من عناوين IP مختلفة. ثانيًا ، من البيانات الدقيقة لدينا فقط بلد الناقل ، والمعلومات حول عدد الشاحنات وأنواعها تقريبًا "معروضة" فقط في الطلبات التي يقدمها المستخدم. أي ، من أجل بناء نظام قائم على المحتوى لمشروعنا ، تحتاج إلى النظر في طلبات كل مستخدم ومحاولة العثور على الأكثر شعبية بينهم.
لم يستخدم نظام التوصية الأول لدينا خوارزميات معقدة. حاولنا ترتيب الاستعلامات والعثور على أعلى القلوب للتوصية بها. لاختبار المفهوم ، عمل فريقنا مع مستخدمين حقيقيين: أرسل إليهم التوصيات ، ثم جمع التعليقات. من حيث المبدأ ، أعجبت النتيجة. ثم قارنت توصياتنا بما كانت تبحث عنه شركات النقل هذه الأيام ، ورأيت أن النظام يعمل بشكل جيد جدًا للمستخدمين الذين لديهم أنماط سلوك مستقرة. ولكن لسوء الحظ بالنسبة لأولئك الذين قدموا مجموعة واسعة من الطلبات ، لم تكن دقة التوصيات عالية جدًا - فالنظام بحاجة إلى التحسين.
واصلت اكتشاف ما نتعامل معه هنا. في الواقع ، إنه نموذج ماركوف المخفي حيث يمكن أن تكون مجموعة من الأشخاص وراء كل مستخدم. علاوة على ذلك ، يمكن أن يكون المستخدمون في حالات مخفية مختلفة: لا توجد بيانات عن المكان الذي يمتلكون فيه شاحنة حاليًا ، وعدد الأشخاص الموجودين في حساب واحد ، ومتى سيحتاجون في المرة القادمة للذهاب إلى مكان ما. في ذلك الوقت ، لم أكن أعرف الحلول الجاهزة لإنتاج نموذج ماركوف المخفي ، لذلك قررت أن أجد شيئًا أبسط.
تلبية PageRank
لذلك لفتت الانتباه إلى خوارزمية PageRank ، التي أنشأها مؤسسا Google ، Sergey Brin و Larry Page ، والتي لا يزال محرك البحث هذا يستخدمها لتوصية المستخدمين بالمواقع. يمثل PageRank مساحة الإنترنت بأكملها في شكل رسم بياني ، حيث تكون كل صفحة ويب هي العقدة الخاصة بها. يمكن استخدامه لحساب "الأهمية" (أو الترتيب) لكل عقدة. يختلف نظام ترتيب الصفحات اختلافًا جوهريًا عن خوارزميات البحث التي كانت موجودة قبله ، نظرًا لأنه لا يعتمد على محتوى الصفحات ، بل على الروابط الموجودة بداخلها. أي أن ترتيب كل صفحة يعتمد على عدد وجودة الروابط التي تشير إليها. أثبت برين وبيج تقارب هذه الخوارزمية ، مما يعني أنه يمكننا دائمًا حساب رتبة أي عقدة في الرسم البياني الموجه والوصول إلى القيم التي لن تتغير.
لنلقِ نظرة على صيغته:
- PR(P) – rank
- N –
- i –
- O –
- d – . -, , - . , . 0 ≤ d ≤ 1 – d 0,85. .
الآن ، هذا مثال بسيط لحساب PageRank لرسم بياني بسيط بثلاث عقد. من المهم أن تتذكر أنه في البداية يتم إعطاء جميع العقد نفس الوزن الذي يساوي 1 / عدد العقد.
يمكنك أن ترى أن الأهم هنا هو العقدة A ، على الرغم من حقيقة أن عقدتين فقط تشير إليها ، مثل C. لكن رتبة العقد التي تشير إلى A أعلى من العقد المؤدية إلى C.
الافتراضات والحلول
لذا يصف نظام ترتيب الصفحات عملية ماركوف بدون حالات مخفية. باستخدامه ، سنجد دائمًا الوزن النهائي لكل عقدة ، لكننا لن نتمكن من تتبع التغييرات في الرسم البياني. الخوارزمية جيدة حقًا ، تمكنا من تكييفها وتحسين دقة النتائج. للقيام بذلك ، قمنا بإجراء تعديل على PageRank - خوارزمية PageRank المخصصة ، والتي تختلف عن الخوارزمية الأساسية في أن الانتقال يتم دائمًا إلى عدد محدود من العقد. أي أنه عندما يتعب المستخدم من "السير" في الروابط ، فإنه لا ينتقل إلى عقدة عشوائية ، بل إلى عقدة من مجموعة معينة.
في حالتنا ، ستكون عُقد الرسم البياني هي طلبات المستخدم. نظرًا لأنه من المفترض أن تقدم الخوارزمية الخاصة بنا توصيات لليوم التالي ، فقد قمت بتقسيم جميع الطلبات لكل شركة نقل حسب اليوم. نقوم الآن ببناء رسم بياني: العقدة A تتصل بالعقدة B ، إذا كان البحث عن النوع B يتبع البحث عن النوع A ، أي أن البحث عن النوع A تم تنفيذه من قبل المستخدم قبل اليوم الذي كانوا يبحثون فيه عن المسار B. على سبيل المثال: "Paris - Brussels" يوم الثلاثاء (A) ، و يوم الأربعاء "بروكسل - كولونيا" (ب). ويقوم بعض المستخدمين بإجراء الكثير من الطلبات يوميًا ، لذلك ترتبط عدة عقد ببعضها البعض في وقت واحد ، ونتيجة لذلك ، نحصل على رسوم بيانية معقدة نوعًا ما.
لإضافة معلومات حول أهمية الانتقال من قلب إلى آخر ، أضفنا أوزان حواف الرسم البياني. وزن الحافة A-B هو عدد المرات التي بحث فيها المستخدم عن B بعد البحث A. ومن المهم أيضًا مراعاة عمر الاستعلامات ، لأن المستخدم يغير قالبه: يمكنه نقل أو إعادة تنظيم نوع النقل الرئيسي ، وبعد ذلك لا يريد الذهاب بشاحنة فارغة. لذلك ، تحتاج إلى مراقبة محفوظات المسارات - نضيف متغير reency ، والذي سيؤثر أيضًا على وزن العقدة.
يجدر النظر في الموسمية: قد نعرف ، على سبيل المثال ، في سبتمبر ، يسافر الناقل غالبًا إلى فرنسا ، وفي أكتوبر - إلى ألمانيا. وعليه ، يمكن إعطاء وزن أكبر للقلوب "الشعبية" في شهر معين. بالإضافة إلى ذلك ، فإننا نعتمد على المعلومات المتعلقة بآخر مرة بحث فيها المستخدم. هذا يساعد على تخمين مكان الشاحنة بشكل غير مباشر.
نتيجة
يتم تنفيذ كل شيء على منصة Google. لدينا تطبيق OLTP ، حيث تأتي البيانات الخاصة بطلبات البحث وتنتقل إلى BigQuery ، حيث يتم تكوين طرق عرض وجداول إضافية تحتوي على معلومات تمت معالجتها بالفعل. تم استخدام مكتبة DASK لتسريع معالجة كميات كبيرة من البيانات وموازنتها. في حلنا ، يتم نقل جميع البيانات إلى Cloud Storage ، لأن DASK يعمل معها فقط ولا يتفاعل مع BigQuery. تم إنشاء وظيفتين في Kubernetes ، أحدهما ينقل البيانات من BigQuery إلى التخزين السحابي ، والثاني يقدم توصيات. يعمل على النحو التالي: يأخذ Job بيانات حول أزواج القلوب من Cloud Storage ، ويعالجها ، وينشئ توصيات لليوم القادم ، ويرسلها مرة أخرى إلى BigQuery. من هناك ، وبالفعل بتنسيق .json ، يمكننا إرسال توصيات إلى تطبيق OLTP ، حيث سيراها المستخدمون.يتم تقييم دقة التوصيات في Tableau ، حيث تتم مقارنة توصياتنا بما يبحث عنه المستخدم بالفعل ، بالإضافة إلى رد فعله (سواء أعجبه ذلك أم لا).
بالطبع ، أود مشاركة النتائج. على سبيل المثال ، هنا مستخدم يصنع 14 قلبًا من بلد إلى بلد كل يوم. كما أوصينا بنفس المقدار:
اتضح أن خياراتنا تتوافق تمامًا مع ما كان يبحث عنه. يتكون الرسم البياني لهذا المستخدم من حوالي 1000 طلب مختلف ، لكننا تمكنا من تخمين ما قد يثير اهتمامه بدقة.
يقوم المستخدم الثاني ، في المتوسط ، بتقديم 8 طلبات مختلفة كل يومين ، ويقوم بالبحث في كل من تنسيق "البلد - البلد" ومع الإشارة إلى منطقة المغادرة المحددة. بالإضافة إلى ذلك ، فإن بلدان المنشأ والتسليم مختلفة تمامًا. لذلك ، لم نتمكن من "تخمين" كل شيء واتضح أن دقة النتائج كانت أقل:
لاحظ أن المستخدم لديه رسمان بيانيان بأوزان مختلفة. في إحداها ، وصلت الدقة إلى 38٪ ، مما يعني أنه في مكان ما 3 من أصل 8 خيارات موصى بها من قبلنا تبين أنها ذات صلة. وربما إذا وجدنا أحمالًا في هذه الاتجاهات ، فسيختارها المستخدم.
المثال الأخير والأبسط. يقوم الشخص بحوالي عمليتي بحث كل يوم. لديها أنماط مستقرة للغاية ، وليس الكثير من التفضيلات ، ورسم بياني بسيط. نتيجة لذلك ، تبلغ دقة تنبؤاتنا 100٪.
الأداء في الحقائق
- تعمل خوارزمياتنا على 4 وحدات معالجة مركزية قياسية وذاكرة 10 جيجابايت.
- تصل أحجام البيانات إلى 1 مليار سجل.
- يستغرق الأمر 18 دقيقة لإنشاء توصيات لجميع المستخدمين البالغ عددهم حوالي 20000.
- تُستخدم مكتبة DASK للتوازي ، وتُستخدم مكتبة NetworkX لخوارزمية PageRank.
أستطيع أن أقول إن عمليات البحث والتجارب التي أجريناها أسفرت عن نتائج جيدة للغاية. يتيح لنا عرض سلوك مستخدمي منصة تبادل الشحن في شكل رسم بياني واستخدام PageRank تخمين تفضيلاتهم المستقبلية بدقة عالية ، وبالتالي بناء أنظمة توصية فعالة.