نحن نسعى جاهدين لضمان أنه بعد طلب سيارة أجرة للمستخدم ، ستأتي إلى المستخدم سيارة نظيفة صالحة للخدمة من حيث اللون واللون الذي يظهر في التطبيق. ولهذا نستخدم مراقبة الجودة عن بعد (DCC).
سأخبر اليوم قراء هبر عن كيفية استخدام التعلم الآلي لتقليل تكلفة مراقبة الجودة في خدمة سريعة النمو مع مئات الآلاف من الآلات وعدم وضع آلة على الخط الذي لا يتوافق مع قواعد الخدمة.
كيف تم ترتيب DCC قبل التعلم الآلي
مخطط عملية DCC
في عملية DCC ، نتحقق من صور السيارة ونتخذ قرارًا بشأن ما إذا كان من الممكن تنفيذ الطلبات على مثل هذه السيارة أو ، على سبيل المثال ، يجب غسلها من قبل. كل شيء يبدأ بحقيقة أنه من خلال تطبيق برنامج التشغيل Taximeter ندعو السائق على DCC. يحدث هذا عادة مرة واحدة كل 10 أيام ، ولكن في بعض الأحيان أقل كثيرًا أو أكثر - وفقًا لمدى نجاح السائق في اجتياز الاختبارات السابقة. مباشرة بعد مكالمة إلى DCC ، يتلقى السائق رسالة تدعوهم للخضوع للتحكم الضوئي. بمجرد قبول السائق للدعوة ، يقوم في نفس التطبيق بتصوير الجزء الخارجي والداخلي للسيارة من زوايا مختلفة وإرسال الصور إلى Yandex.Taxi. يمكن للسائق تلقي الطلبات أثناء تشغيل DCC.
DCC بدء الشاشة في تطبيق عداد التاكسي
شاشة لتصوير سيارة في تطبيق Taximeter
تندرج الصور الناتجة في Yandex.Toloka - وهي خدمة ، يمكنك من خلالها استخدام مهام التعهيد الجماعي بسرعة وبسيطة ولكنها كبيرة الحجم. حول كيفية عمله ولماذا هناك حاجة إلى Yandex.Tolok ، كتبنا على مدونتنا .
في Yandex.Tolok ، خلال عملية فحص واحدة ، يجيب ثلاثة فنانين على الأقل على أسئلة حول حالة السيارة ، وإذا وافق فناني الأداء على إجاباتهم ، يتم اتخاذ قرار بشأن ما إذا كان السائق يمكنه قبول الطلبات أم لا. الشيكات في Yandex.Tolok لها نتيجتان:
- إذا كان كل شيء على ما يرام بصريا مع السيارة ، يستمر السائق في تلقي الأوامر.
- إذا كانت السيارة متسخة أو تالفة أو لا يتطابق لونها أو رقمها مع الأرقام المبينة على بطاقة السائق ، فإن Yandex.Taxi يحد مؤقتًا من قدرة السائق على قبول الطلبات.
في حالة عدم التوصل إلى توافق في الآراء ، يتم إرسال الصور إلى موظفي Yandex.Taxi - المقيمين الذين يقومون بفحص السيارة بدقة أكبر ثم يتخذون القرار النهائي. يخضع المقيمون لبرنامج تدريبي خاص ولديهم المزيد من الخبرة.
لذلك يرى المنفذ DCC Yandex.Tolki
التحدي
مع نمو Yandex.Taxi ، يتزايد عدد عمليات تفتيش DCC أيضًا ، مما يعني أن تكاليف tolkers والمقيمين في تزايد. بالإضافة إلى ذلك ، تنخفض سرعة فحص السيارة. بينما DCC قيد التقدم ، يمكنك إما السماح للسائقين بقبول الطلبات أم لا. كلا الخيارين لهما عيوب: في الحالة الأولى ، سيتاح للسائق عديمي الضمير وقت لقبول العديد من الطلبات على سيارة لا تفي بالمعايير ، في الحالة الثانية - لن يتمكن جميع السائقين المطلوبين للتحكم في الصور من العمل حتى يكتمل الفحص. لذلك ، من المهم فحص السيارات بسرعة حتى لا يواجه المستخدمون والسائقون أي إزعاج.
عند مشاهدة كيفية نمو الرسوم البيانية للتكاليف ومتوسط وقت الفحص ، أدركنا أننا نريد خفض تكلفة Toloka ، وإفراغ المقيِّمين وتقليل متوسط وقت الفحص ، بمعنى آخر ، أتمتة جزء من عمليات الفحص. وبطبيعة الحال ، لم نكن نريد التضحية بجودة الخدمة وتفويت المزيد من السيارات التي لا تفي بمعايير الجودة للخط ، كما أننا لم نرغب في الحد من قبول الطلبات من قبل سائقي bona fide. نحن بحاجة إلى أتمتة DCC وفي الوقت نفسه لا تزيد من حصة الأخطاء في التدفق الكلي للشيكات.
كيف قمنا بتنفيذ التعلم الآلي في DCC
مخطط عملية DCC مع ML داخل
بادئ ذي بدء ، قررنا بيان المشكلة: لأتمتة أكبر عدد ممكن من عمليات التحقق ، مع عدم زيادة معدل الخطأ في التدفق الكلي.
دعونا معرفة ما هي الأخطاء في مهمتنا. أنها تأتي في شكلين: كاذبة إيجابية وسلبية كاذبة . في المصطلحات الخاصة بنا ، السلبي هو نتيجة لفحص يمكن للسائق مواصلة العمل به ، والإيجابية هي النتيجة التي تتطلب مهلة زمنية لاستلام الطلبات. إذن ، الكاذب السلبي هو الحالة التي أجبرنا فيها على السماح للسائق بسيارة سيئة بأخذ الأوامر ، والإيجابية الخاطئة - على العكس من ذلك ، عندما لم نسمح للسائق بالعمل مع سيارة بخير. اتضح أن معدل الخطأ السلبي (FNR) هو حصة السائقين الذين لديهم سيارات "سيئة" سمح لنا بقبول الطلبات ، وأن معدل الخطأ الإيجابي (FPR) هو نسبة السائقين الذين لم يسمح لنا بالعمل معهم ، على الرغم من أنهم بخير مع السيارات. وبالتالي ، منذ إدخال التعلم الآلي في النظام ، أردنا ما يلي: أتمتة أكبر عدد ممكن من الاختبارات ، دون زيادة FPR و FNR مقارنة مع نظام بدون تعلم آلي.
علاوة على ذلك ، كان من الضروري فهم المقاييس التي يجب الاسترشاد بها عند اختيار النماذج والعتبات لاتخاذ القرارات بناءً على تنبؤاتها. من الواضح من خلال ظروف المشكلة أننا مهتمون بثلاثة كميات:
- جزء الخيط الذي يمكن أن تجيبه نماذج التعلم الآلي تلقائيًا.
- أنظمة FNR.
- أنظمة FPR.
نعمل على زيادة القيمة الأولى مع مراعاة القيود المفروضة على الثاني والثالث.
قد يثير هذا السؤال: لماذا لا تزيد مدخرات المال إلى الحد الأقصى أو تقلل متوسط وقت الفحص مباشرة ، وليس من خلال حصة الشيكات الآلية؟ يعد تحسين الأموال فكرة جذابة للغاية ، ولكن عادة ما يكون من الصعب تنفيذها. في حالتنا ، تتكون المدخرات من عاملين: الأول هو المدخرات من كل شيك تلقائي ، لأن كل شيك على المقيمين أو في Yandex.Tolok يكلف المال ؛ الثاني - إنقاذ من تقليل عدد الأخطاء ، لأن كل خطأ يكلف Yandex.Taxi المال. حساب موضوعي كم من الأخطاء يكلفنا مهمة صعبة للغاية ، لذلك نحن يقتصر على حساب المدخرات فقط من خلال العامل الأول. تزيد هذه القيمة بشكل رتيب في نسبة عمليات الفحص الآلية ، بحيث يمكن تعظيم هذا الكسر بدلاً من التوفير. ينطبق نفس المنطق على متوسط وقت DCC ، كما أنه ينخفض بشكل رتيب وفقًا لحصة الاختبارات الآلية.
اختيار النموذج
يمكننا أن نقول أن فحص DCC قد تم اختياره لاختيار خيارات الإجابة لعدد من الأسئلة حول حالة السيارة من صورها ، وهذا يبدو وكأنه مهمة تصنيف الصورة. يتم حل هذه المهام عن طريق رؤية الكمبيوتر ، وفي عصرنا - أداة محددة ، والشبكات العصبية التلافيفية. قررنا استخدامها لأتمتة DCC.
الحل الأول أو نهج "كل مرة واحدة"
الآن وقد فهمنا ما الذي يجب تحسينه ولماذا ، فقد حان الوقت لجمع البيانات وتدريب النماذج عليها. كان من السهل جمع البيانات ، لأن جميع عمليات تدقيق DCC يتم تسجيلها وتخزينها في شكل مناسب. في الإصدار الأول من الحل ، تم استخدام صور المظهر الخارجي والداخلي للسيارة من أربع زوايا ، وصناعة السيارة وطرازها ولونها ، بالإضافة إلى نتائج 10 عمليات تفتيش سابقة لـ DCC. كمتغيرات مستهدفة ، أخذنا الإجابات على جميع أسئلة التحقق ، على سبيل المثال: "هل السيارة تالفة؟" أو "هل يتناسب لون السيارة مع اللون الموجود على بطاقة السائق؟" كان المتغير الرئيسي الهدف هو الإجابة على السؤال الرئيسي: "هل من الضروري الحد من قدرة السائق على تلقي الطلبات؟" قمنا بتدريس نموذج واحد كبير ، يشبه إلى حد كبير VGG مع اهتمام SENet ، للإجابة على جميع الأسئلة في نفس الوقت ونتيجة لذلك واجهنا العديد من المشاكل.
الكل في واحد النهج
مشاكل نهج "الكل في وقت واحد":
- لم نتمكن من الإجابة على سؤال حول مراسلات رقم السيارة في الصورة المشار إليها في بطاقة السائق. تعذر على شبكة كبيرة لتصنيف الصور التعامل مع هذه المهمة ، ولهذا نحن بحاجة إلى نموذج خاص للتعرف على الأحرف البصرية (OCR) ، تم توضيحه للتعرف على لوحات الترخيص.
- كان المتغير الهدف غير مكتمل وصاخب. لإيجاد خلل خطير في مظهر السيارة ، وهو ما يكفي لاتخاذ قرار ، غالبًا ما ينسى المقيمون الإجابة على أسئلة أخرى. لذا ، إذا كانت السيارة الموجودة في الصورة متسخة ومكسورة ، فلربما لاحظنا إحتمالًا واحدًا فقط من العلامات: "سيارة قذرة" أو "سيارة بها أضرار" ، في حين كان كلا النموذجين مطلوبين لطرازنا.
- لم يكن هناك تفسير من الحل النموذجي. يمكن أن يجيب النموذج على سؤال التحقق الرئيسي بدقة أعلى من العشوائية ، ولكن هذه الإجابة مرتبطة بشكل ضعيف بالإجابات عن الأسئلة الأخرى. بمعنى آخر ، إذا كان الجواب: "من الضروري الحد من القدرة على تلقي الطلبات" ، فلم نر مطلقًا سبب هذا القرار في الإجابات المتبقية للنموذج. بشكل عام ، كانت دقة الإجابات على جميع الأسئلة ، باستثناء السؤال الرئيسي ، قريبة من العشوائية. لم نتمكن من شرح ما يحتاجه السائق بالضبط لإصلاح الطلبات مرة أخرى ، مما يعني أنه لا يمكننا تقييد قدرة السائق على تلقي الطلبات.
- عدد الأخطاء السلبية الخاطئة في إجابة السؤال: "هل من الضروري الحد من قدرة السائق على تلقي الطلبات؟" - كان أكبر من اللازم لبدء الموافقة على الشيكات تلقائيًا. لم نتمكن من توفير نفس FNR كما هو الحال في نظام يعمل بدون تعلم الآلة ، وكان هذا أحد المتطلبات في مهمتنا.
معًا ، لم تسمح لنا هذه الأسباب الأربعة بوضع الحل الأول موضع التنفيذ ، لكننا لم نفقد قلوبنا وتوصلنا إلى الحل الثاني.
الحل الثاني ، أو نهج "الكل ولكن تدريجيا"
قررنا التركيز على فحص السطح الخارجي للسيارة ، لأنها تشكل حوالي 70٪ من إجمالي التدفق. بالإضافة إلى ذلك ، قررنا تقسيم المهمة العامة إلى مهام فرعية ومعرفة كيفية الإجابة على جميع أسئلة DCC بشكل منفصل.
نهج "كل شيء ، ولكن تدريجيا"
ذات مرة ، كانت خدمتنا تعمل بالفعل في أتمتة DCC وتمكنت من تقديم نموذج يتيح لك تصفية الصور المظلمة وغير ذات الصلة. واصلنا استخدام هذا الطراز بشكل أكبر للإجابة على السؤال: "هل الصور الحقيقية التالية للسيارة موجودة: الأمام ، الجانب الأيسر ، الجانب الأيمن ، الخلف؟".
بدأ عملنا على الحل الثاني بحقيقة أننا استخدمنا Yandex. ابحث في نموذج خدمة رؤية الكمبيوتر (من الأشخاص الذين قاموا بعمل DeepHD ) للتعرف على لوحات الترخيص على السيارات. لذلك تمكنا من الإجابة على السؤال: "هل يتوافق رقم ورمز منطقة السيارة تمامًا مع الرقم الموضح في بطاقة السائق؟" إذا تحدثنا عن هذا بمزيد من التفصيل ، قارنا نتيجة التعرف مع الرقم المشار إليه على بطاقة السائق ، واعتمادًا على المسافة بين ليفينشتاين بينهما ، اخترنا أحد خيارات الإجابة: "الرقم متطابق" أو "الرقم غير متطابق" أو "لا يمكن الإجابة عن السؤال بالضبط".
بعد ذلك ، قمنا بتدريب مصنّفي السيارات على التعرف على الماركات والموديلات ، فضلاً عن الألوان. من هذه اللحظة ، يمكننا الإجابة على السؤال: "هل السيارة وطرازها ولونها مبينة على بطاقة السائق؟"
في الختام ، قمنا بتدريب المصنفين على العثور على السيارات التالفة والقذرة ، مما سمح لنا بإغلاق الأسئلة: "هل هناك أي أضرار أو عيوب في جسم السيارة؟" و "كيف القذرة هو جسم السيارة؟"
لقد سمح لنا نهج "الكل ولكن تدريجيا" بحل مشكلة التحقق من رقم لوحة السيارة. كنا أيضًا قادرين على التخلص من عدم اكتمال وصوت المتغير المستهدف ، لأن لدينا الآن مجموعة من الأشياء التي كانت فيها العناصر السالبة كانت اختبارات ناجحة تمامًا ، وفحص الكائنات فئة موجبة حيث وجد المقيِّم أو جميع منفذي Yandex الثلاثة خللاً معينًا ، على سبيل المثال ، تلف في الحالة . بعد حل المشكلتين الأوليين ، أصبحت نماذجنا قابلة للتفسير ، ويمكننا أن نوضح للسائق سبب القيد ، بحيث أنه في الاختبار التالي سيصحح العيوب. كما نمت الجودة الشاملة للإجابات على الأسئلة بشكل كبير ، وانخفضت FPR و FNR لبعض مجموعات عتبات الثقة بالنموذج إلى مستوى Yandex.Tolki ، مما سمح بعرض النماذج في الإنتاج.
التنفيذ في الإنتاج
كان لدينا خيار: بدء عملية منتظمة تطبق النماذج على عمليات الفحص المتراكمة في قائمة الانتظار ، أو لتقديم خدمة منفصلة حيث يمكنك الذهاب عبر واجهة برمجة التطبيقات وتلقي استجابات نموذجية في الوقت الفعلي. نظرًا لأنه من المهم بالنسبة لنا العثور بسرعة على السيارات "السيئة" ، فقد اخترنا الخيار الثاني. بمجرد كتابة الجزء الرئيسي من الخدمة وتمكّن من دعم الوظيفة الضرورية ، بدأنا في إضافة نماذج إليها.
للموافقة الكاملة على الشيك ، يجب أن تكون قادرًا على الإجابة على جميع أسئلة التعليمات ، ولكن من أجل الحد من وصول السائقين عديمي الضمير إلى الخدمة ، يكفي في بعض الحالات أن تكون قادرًا على الإجابة على سؤال واحد على الأقل. لذلك ، قررنا عدم الانتظار حتى تكون جميع الطرز جاهزة ، ولكن لإضافتها عند توفرها. يبدو خط الأنابيب المعمم لإضافة نموذج كما يلي:
- اجمع العينة.
- تدريب النموذج.
- قم بقياس الجودة واختر العتبات في وضع عدم الاتصال.
- أضف نموذجًا للخدمة في الخلفية وقياس الجودة عبر الإنترنت.
- قم بتضمين النموذج في الإنتاج وابدأ في اتخاذ القرارات بناءً على تنبؤاته.
لم يسمح لنا هذا النهج بالعثور على المزيد من السيارات "السيئة" فورًا بمجرد طرح طرازات جديدة ، ولكن أيضًا لقياس الجودة على الإنترنت دون تكاليف وقت إضافية أثناء عمل النماذج في الخلفية.
في النهاية ، جاءت اللحظة التي أضفنا فيها الخدمة واختبرنا أحدث طراز. الآن يمكننا الإجابة على جميع أسئلة عمليات التفتيش ، مما يعني أنه سيتم الموافقة عليها تلقائيًا. نظرًا لوجود عدد أكبر من السيارات "الجيدة" في Yandex.Taxi مقارنة بالسيارات "السيئة" ، فقد أدت الموافقة التلقائية على عمليات التفتيش إلى زيادة حادة في القياس الرئيسي لدينا - جزء من مجموعة عمليات التفتيش الآلية. لا يمكننا سوى اختيار العتبات الصحيحة التي من شأنها زيادة حصة الشيكات الآلية إلى أقصى حد ، مع الحفاظ على إجمالي FPR و FNR للنظام بأكمله في نفس المستوى. لتحديد العتبات ، استخدمنا عينة تم تمييزها بشكل مستقل من قبل المديرين التنفيذيين في Yandex.Tolkey والمقيمين وموظف Yandex.Taxi الذي قام بتدريب المقيّمين لفحص السيارات. استخدمنا العلامات كقيم حقيقية للمتغير المستهدف.
النتائج
بمجرد تضمين النماذج في الإنتاج ، كان من الضروري قياس جودة القرارات المتخذة عبر الإنترنت بناءً على إجاباتهم. وهنا الأرقام التي رأيناها:
- تلقى 30 ٪ من الشيكات الخارجية للسيارة الآن استجابة تلقائية.
- بقي FNR على نفس المستوى ، في حين انخفض FPR ، وبدأنا في كثير من الأحيان تقييد الوصول إلى الخدمة لأولئك الذين لا يستحقون ذلك.
- انخفض الحمل على المقيّمين بنسبة 14٪ ، وتمكّنوا من تخصيص مزيد من الوقت للاختبارات المعقدة التي لم تتمكن خدمة التعلم الآلي من إجرائها.
- تم تقليل وقت الكشف عن السيارات ذات العيوب الخطيرة أثناء الفحص من بضع ساعات إلى بضع ثوان.
وبالتالي ، لم يساعد إدخال التعلم الآلي في توفير المال فحسب ، بل جعل الخدمة أكثر أمانًا وراحة للمستخدمين. ومع ذلك ، هذا أبعد ما يكون عن نهاية القصة. سيستمر فريقنا سريع النمو في العمل بنشاط لأتمتة المزيد من الفحوصات وجعل Yandex.Taxi أكثر راحة وراحة وأمان.
أخلاق التاريخ
أثناء العمل على أتمتة DCC في Yandex.Taxi ، واجهنا العديد من المشكلات ، ووجدنا العديد من الحلول الناجحة وتوصلنا إلى ستة استنتاجات مهمة:
- ليس من الممكن دائمًا حل المشكلة بشكل مباشر (حتى إذا كان لديك تعلم عميق).
- النموذج جيد مثل البيانات التي تم تدريبه عليها (يبدو مبتذلًا ، لكنه).
- في حل أي مشكلة ، من المهم البناء على الاحتياجات الحقيقية للعمل ، وليس على التقليل من الانتروبيا.
- في حل بعض المشكلات ، لا يزال الأشخاص مهمين ، على الرغم من إدخال التعلم الآلي (مرحبًا ، Yandex.Toloka!).
- قد لا يتم اتخاذ القرارات بناءً على تنبؤات نماذج التعلم الآلي في جميع الحالات ، ولكن فقط في هذا الجزء حيث تكون النماذج واثقة جدًا في إجاباتها. في حالات أخرى ، قد يكون من المفيد اتخاذ القرارات بالطريقة القديمة - بمساعدة الأشخاص.
- بالإضافة إلى اختيار الهندسة المعمارية والتدريب النموذجي ، هناك العديد من المراحل الإضافية للمشروع التي يمكن أن تؤثر بشكل كبير على كيفية حل مشكلة العمل. هذه المراحل هي: جمع البيانات ، واختيار مقاييس الجودة ، وخيارات تنفيذ النموذج ، ومنطق اتخاذ القرار في المنتج استنادًا إلى تنبؤات النماذج ، وأكثر من ذلك بكثير.
أكثر من اهتمام حول التكنولوجيا تاكسي
التسعير الديناميكي ، أو كيف تتوقع Yandex.Taxi ارتفاع الطلب .
كيف تتنبأ Yandex.Taxi بأوقات توصيل السيارات باستخدام التعلم الآلي .