كيف يبحث Yandex.Taxi عن السيارات عندما لا تكون كذلك

صورة

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

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

قبل التاريخ


للاتصال بسيارة أجرة ، يأخذ المستخدم بضع خطوات بسيطة ، وماذا يحدث في الشجاعة للخدمة؟
المستخدممرحلةBackend Yandex.Taxi
يختار نقطة المغادرةدبوسنطلق بحثًا مبسطًا عن المرشحين - ابحث عن الرقم السري. بناءً على برامج التشغيل التي تم العثور عليها ، يتم توقع وقت الوصول - ETA في الدبوس. يتم احتساب عامل الزيادة في نقطة معينة.
يختار الوجهة ، التعريفة ، المتطلباتعرضنحن نبني طريقًا ونحسب الأسعار لجميع التعريفات ، مع مراعاة المعامل المتزايد.
يضغط على زر "Call taxi"ترتيبنطلق بحثًا كاملًا عن السيارة. نختار السائق الأنسب ونقدم له طلبًا.

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

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

هنا ما رأى المستخدم في التطبيق:



ابحث عن سيارات بدون سيارات


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

لاختبار هذه الفرضية ، أطلقنا تجربة: لقد توقفنا عن التحقق من وجود الآلات أثناء البحث عن مجموعة من المستخدمين ، أي أنها كانت لديهم الفرصة لإجراء "طلب بدون آلات". كانت النتيجة غير متوقعة: إذا لم تكن السيارة مثبتة على الدبوس ، فحينها حدث 29٪ من الحالات في وقت لاحق - عند البحث عن طلب شراء! علاوة على ذلك ، لم تختلف الطلبات التي لا تحتوي على سيارات كثيرًا عن الطلبات المعتادة من حيث معدلات الإلغاء والتصنيفات ومؤشرات الجودة الأخرى. كان عدد الطلبات بدون سيارات 5 ٪ من جميع الطلبات ، ولكن ما يزيد قليلا عن 1 ٪ من جميع الرحلات الناجحة.

لفهم من أين يأتي منفذي هذه الأوامر ، دعونا نلقي نظرة على أوضاعهم أثناء البحث على الدبوس:



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

إضافة الموثوقية


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

المخطط كما يلي:

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

في التطبيق ، بدا الأمر كما يلي:



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

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

لنفترض أننا نقوم بإجراء اختبار (مصنف) لبعض الأمراض النادرة والخطيرة. بناءً على نتائج الاختبار ، إما أن نرسل المريض لإجراء فحص أكثر تفصيلًا ، أو نقول: "بصحة جيدة ، عد إلى المنزل". بالنسبة لنا ، فإن إرسال شخص مريض إلى المنزل أسوأ بكثير من فحص الشخص السليم دون جدوى. وهذا يعني أننا نريد أن يعمل الاختبار لأكبر عدد ممكن من المرضى حقًا. هذه القيمة تسمى استدعاء =  fracnumber defined classifier sicknumber all sick. أذكر المصنف المثالي هو 100 ٪. الموقف المتدهور هو إرسال الجميع للفحص ، ثم الاستدعاء سيكون أيضًا 100٪.

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

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

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

هناك حالتان متطرفتان: عدم السماح لأي شخص بالطلب والسماح لكل شخص بالطلب. إذا لم تسمح لأي شخص ، فسيكون التذكير صفرًا: لن نقوم بإنشاء أوامر ، ولكن لن يفشل أي منها. إذا سمحت للجميع ، فسيكون التذكير 100٪ (سنتلقى جميع الطلبات الممكنة) ، والدقة - 29٪ ، أي أن 71٪ من الطلبات ستكون سيئة.


كعلامات ، استخدمنا المعلمات المختلفة لنقطة المغادرة:

  • الوقت / المكان.
  • حالة النظام (عدد السيارات المشغولة بجميع التعريفات والدبابيس في المنطقة المجاورة).
  • معلمات البحث (نصف القطر ، عدد المرشحين ، القيود).

تفاصيل عن الأعراض


من الناحية النظرية ، نريد التمييز بين حالتين:

  • "الغابة الميتة" - لا توجد سيارات هنا في هذا الوقت.
  • "سيئ الحظ" - هناك سيارات ، لكن لم تكن هناك سيارات مناسبة عند البحث.

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

لذلك ، اتضح أن العديد من ميزات النظام بالقرب من النقطة A هي ميزات جيدة:

  • إجمالي عدد السيارات.
  • عدد السيارات حسب الطلب
  • عدد الأجهزة غير متوفرة للطلب في حالة "مشغول".
  • عدد المستخدمين.

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

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

النتائج


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

في الوقت الحالي ، يتم إطلاق الآلية في جميع المدن والبلدان ، ومعها تحدث حوالي 1٪ من الرحلات الناجحة. علاوة على ذلك ، في بعض المدن ذات الكثافة المنخفضة للسيارات ، تصل حصة هذه الرحلات إلى 15 ٪.

وظائف تكنولوجيا سيارات الأجرة الأخرى


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


All Articles