التسعير الديناميكي ، أو كيف تتوقع Yandex.Taxi ارتفاع الطلب



في السابق ، لاستدعاء سيارة أجرة ، كان عليهم الاتصال بأرقام مختلفة من خدمات الإرسال والانتظار حتى يتم تسليم السيارة لمدة نصف ساعة أو أكثر. الآن أصبحت خدمات سيارات الأجرة مؤتمتة بشكل جيد ، ويبلغ متوسط ​​وقت تسليم سيارة Yandex.Taxi في موسكو حوالي 3-4 دقائق. لكن الأمر يستحق أن تمطر أو تنهي حدثًا جماهيريًا ، ومرة ​​أخرى قد نواجه نقصًا في السيارات المجانية.

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


تحدي التسعير الديناميكي


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

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

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

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



دعونا صياغة المشكلة: نحن بحاجة إلى قراءة القيم الآنية للآلات والدبابيس في وقت ما في المستخدم.

نحسب عدد الدبابيس والسيارات حولها


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

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

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



تم إنشاء ذاكرة تخزين مؤقت ساخنة بمؤشر التجزئة الجغرافية . نقوم بتجميع كل المسامير حسب geohash ، ثم نجمع المسامير لنصف القطر المطلوب حول نقطة الطلب.

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

لذلك نحن نعتبر القيم الآنية للمعامل.



التخزين المؤقت


الحالة : أنت تقف في Garden Ring في موسكو وتريد حجز سيارة. في الوقت نفسه ، يقفز السعر في كثير من الأحيان وهذا أمر مزعج.

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

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

نجح هذا ، ولكن هناك حالات أخرى.

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

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

تنعيم


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

قررنا استعارة طريقة الجيران الأقرب من التعلم الآلي لمشكلة الانحدار من أجل تحديد مدى اختلاف قيمة الطفرة الفورية عما يحدث حولنا.

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

لذلك نحصل على نظام باستجابة سريعة للأحداث ونسمح لك بقراءة قيمة المعامل المتزايد بسرعة.

بطاقة القيادة السريعة


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



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

لدينا خدمة منفصلة تلتقط بشكل دوري مجموعات من الدبابيس من الخدمة الدقيقة لـ Surger وتحسب جميع المعلومات الوصفية اللازمة لعرض الشبكة السداسية: أين هي السداسي وأي زيادة في كل منها.

الخلاصة


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

إذا كنت مهتمًا بمعرفة جزء من هذا الموضوع الكبير بمزيد من التفاصيل ، فاكتب في التعليقات. نرحب بالملاحظات والأفكار!

ملاحظة: في المنشور التالي ، سيتحدث زميلي عن استخدام التعلم الآلي للتنبؤ بالوقت المتوقع لوصول سيارة أجرة.

Source: https://habr.com/ru/post/ar429226/


All Articles