كيفية تعلمنا للتنبؤ بطلب أحد المستخدمين وتسريع تحميل نتائج البحث

لا تعتبر اقتراحات البحث (sjest) خدمة مستخدم فحسب ، بل هي أيضًا نموذج لغة قوي للغاية يخزن مليارات من استعلامات البحث ، ويدعم البحث الغامض والتخصيص وغير ذلك الكثير. لقد تعلمنا كيفية استخدام sujest من أجل التنبؤ بالاستعلام النهائي للمستخدم وتحميل نتائج البحث قبل النقر فوق الزر "بحث".

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

1. هل ستنجح الفكرة؟

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

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

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

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

لم يتم ترتيب مقاييس مقدم العرض بالكامل تمامًا كما في التصنيف الثنائي المعتاد. اثنين فقط من المعلمات مهمة ، ولكن هذا ليس دقة أو اكتمال.

سمح $$$ص$- إجمالي عدد الطلبات ، $$$ع$- العدد الإجمالي لجميع المتسابقين ، $$$ep$- العدد الإجمالي للطلبات التمهيدية الناجحة ، أي تلك التي تطابق في نهاية المطاف إدخال المستخدم. ثم يتم حساب خاصيتين مهمتين على النحو التالي:

$$

$$overhead = \ frac {p + r - ep} {r} - 1$$

$$

على سبيل المثال ، إذا تم تقديم طلب مسبق واحد بالضبط لكل طلب ، ونجاح نصف طلبات التقديم ، فعندئذ ستكون كفاءة العرض 50٪ ، وهذا يعني أنه كان من الممكن تسريع عملية تحميل نصف الطلبات. في الوقت نفسه ، بالنسبة للطلبات التي نجح فيها مقدم العرض بنجاح ، لم يتم إنشاء حركة مرور إضافية ؛ لتلك الطلبات التي فشل فيها العرض ، يجب تعيين طلب إضافي واحد ؛ وبالتالي ، يكون إجمالي عدد الطلبات أكبر من الطلب الأصلي مرة واحدة ونصف ، ويطلب "إضافي" 50٪ من الرقم الأصلي $$ .

في هذه الإحداثيات ، وجهت أول مؤامرة مبعثر. بدا مثل هذا:

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

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

margin prefix candidate -180.424   -96.096    -67.425    -198.641    -138.851    -123.803    -109.841    -96.805    -146.568     -135.725     -125.448     -58.615      31.414     -66.754      1.716         

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

2. التنفيذ الأول

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

في تلك اللحظة ، اكتسب المصنف عوامل جديدة ، ولم يعد النموذج الانحدار اللوجستي ، بل CatBoost . في البداية ، طرحنا عتبات متحفظة إلى حد ما بالنسبة إلى المصنف ، ولكن حتى سمحت لنا بتحميل حوالي 10٪ من نتائج البحث على الفور. لقد كان إصدارًا ناجحًا جدًا ، لأنه لقد نجحنا في تحويل الكميات البسيطة من سرعة تنزيل SERP بشكل ملحوظ ، وقد لاحظ المستخدمون ذلك وبدأوا في العودة إحصائياً بشكل كبير إلى البحث: أثر تسريع كبير في البحث على تواتر المستخدمين الذين يقومون بجلسات البحث!

3. مزيد من التحسينات

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

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

   
   

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

   
   

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

   
   

بالطبع ، كان ترك عارض بهذه العيوب عارًا ، حتى لو كان مفيدًا. لقد شعرت بالإهانة بشكل خاص بسبب مشكلة أدلة الكلمات. أنا أعتبر إدخال مطالبات كلمة الكلمة في بحث Yandex mobile واحدًا من أفضل تطبيقاتي طوال الوقت الذي عملت فيه في الشركة ، ولكن هنا لا يعرف prerender كيفية العمل معهم! عار ، ليس غير ذلك.

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

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

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

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

4. ما هي النتيجة

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

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

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

في الفيديو أدناه ، يمكنك رؤية كيفية عمل التطبيق المسبق الآن على هاتفي.