تسربت "شظايا" من قاعدة بيانات Yandex عبر الإنترنت الأسبوع الماضي. مثل Google ، يعد Yandex نظامًا أساسيًا به العديد من الجوانب مثل البريد الإلكتروني والخرائط وخدمة سيارات الأجرة وما إلى ذلك.

وفقًا للوثائق الواردة فيه ، تم طي قاعدة بيانات Yandex في مستودع واحد كبير يسمى Arcadia في عام 2013. قاعدة الكود المسربة هي مجموعة فرعية من جميع المشاريع في Arcadia ونجد فيها العديد من المكونات المتعلقة بمحرك البحث في "Kernel" ، و "Library" أرشيفات "روبوت" و "بحث" و "ExtSearch".

هذه الخطوة غير مسبوقة على الإطلاق. ليس منذ أن بيانات استعلام بحث AOL لعام 2006 تحتوي على شيء لذلك دخلت المواد المتعلقة بمحرك بحث الويب إلى المجال العام.

على الرغم من أننا نفتقد البيانات والعديد من الملفات المشار إليها ، فإن هذا هو المثال الأول لإلقاء نظرة ملموسة على كيفية عمل محرك بحث حديث على مستوى الكود.

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

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

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

أيضًا ، صرخ إلى Ryan Jones للتنقيب عن بعض النتائج الرئيسية ومشاركتها معي عبر المراسلة الفورية.

حسنًا ، دعنا ننشغل!

إنه ليس رمز Google ، فلماذا نهتم؟

يعتقد البعض أن مراجعة قاعدة البيانات هذه هي مصدر إلهاء وأنه لا يوجد شيء سيؤثر على كيفية اتخاذهم لقرارات العمل. أجد أنه من الغريب النظر إلى هؤلاء الأشخاص من نفس مجتمع مُحسّنات محرّكات البحث الذين استخدموا نموذج CTR من بيانات AOL لعام 2006 كمعيار صناعي للنمذجة عبر أي محرك بحث لسنوات عديدة لمتابعة.

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

يذهب مهندسو البرمجيات من كلتا الشركتين إلى نفس المؤتمرات (SIGIR ، ECIR ، إلخ) ويتبادلون النتائج والابتكارات في استرجاع المعلومات ، ومعالجة اللغة الطبيعية / فهمها ، وتعلم الآلة. تمتلك Yandex أيضًا وجودًا في بالو ألتو ، وكان لشركة Google وجودًا سابقًا في موسكو.

يكشف البحث السريع على LinkedIn عن بضع مئات من المهندسين الذين عملوا في كلتا الشركتين ، على الرغم من أننا لا نعرف عددهم الذين عملوا بالفعل على البحث في كلتا الشركتين.

في تداخل أكثر مباشرة ، يستخدم Yandex أيضًا تقنيات Google مفتوحة المصدر التي كانت ضرورية للابتكارات في البحث مثل TensorFlow و BERT و MapReduce ، وبدرجة أقل بكثير ، Protocol Buffers.

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

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

بعض السياق في هندسة Yandex

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

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

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

• طريقة ونظام يتم تنفيذهما بواسطة الكمبيوتر للبحث في فهرس مقلوب يحتوي على قوائم ترحيل متعددة
• مرتبة نتيجة البحث

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

تناقش وثائق Yandex نظام الزاحف الموزع المزدوج. أحدهما للزحف في الوقت الفعلي يسمى "Orange Crawler" والآخر للزحف العام.

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

يختلف Yandex و Google في هذا الصدد ، ولكن الفكرة العامة للزحف المقسم مدفوعة بفهم تكرار التحديث.

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

يناقش التوثيق أيضًا بنية قاعدة بيانات مجزأة تقسم الصفحات إلى فهرس مقلوب وخادم مستندات.

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

يختلف هذا عن Google في أنها انتقلت إلى الفهرسة القائمة على العبارات ، مما يعني أن n-grams يمكن أن تكون أطول بكثير من الأشكال ثلاثية الأبعاد منذ وقت طويل.

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

عملية الترتيب هي المكان الذي تبدأ فيه الأمور في أن تصبح أكثر إثارة للاهتمام.

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

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

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

يوجد 17854 عامل ترتيب في قاعدة الشفرة

في يوم الجمعة الذي أعقب التسريب ، شارك مارتن ماكدونالد الفذ بشغف ملفًا من قاعدة الكود يسمى web_factors_info / factor_gen.in. يأتي الملف من أرشيف "Kernel" في تسريب قاعدة التعليمات البرمجية ويضم 1922 عامل ترتيب.

بطبيعة الحال ، فإن مجتمع مُحسّنات محرّكات البحث يعمل بهذا الرقم وهذا الملف لنشر أخبار الأفكار الواردة فيه بشغف. قام العديد من الأشخاص بترجمة الأوصاف والأدوات المبنية أو جداول بيانات Google و ChatGPT لفهم البيانات. وكلها أمثلة رائعة على قوة المجتمع. ومع ذلك ، فإن 1922 يمثل واحدًا فقط من العديد من مجموعات عوامل الترتيب في قاعدة البيانات.

يكشف الغوص العميق في قاعدة الشفرة عن وجود العديد من ملفات عوامل الترتيب لمجموعات فرعية مختلفة من أنظمة معالجة وترتيب الاستعلام في Yandex.

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

• نقرات.
• اسكن الوقت.
• الاستفادة من برنامج Metrika المكافئ لـ Yandex's Google Analytics.

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

توضح وثائق Yandex أيضًا أن لديهم ثلاث فئات من عوامل الترتيب: ثابت ، وديناميكي ، وتلك المتعلقة تحديدًا ببحث المستخدم وكيف تم إجراؤه. بكلماتهم الخاصة:

في قاعدة الشفرة ، يشار إلى هذه في ملفات عوامل الترتيب ذات العلامات TG_STATIC و TG_DYNAMIC. تحتوي العوامل المتعلقة بالبحث على علامات متعددة مثل TG_QUERY_ONLY و TG_QUERY و TG_USER_SEARCH و TG_USER_SEARCH_ONLY.

بينما اكتشفنا عوامل تصنيف محتملة 18 ألفًا للاختيار من بينها ، تشير الوثائق المتعلقة بـ MatrixNet إلى أن التسجيل مبني من عشرات الآلاف من العوامل ومخصص بناءً على استعلام البحث.

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

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

على سبيل المثال ، أظن أن هناك ارتباطًا أكبر بـ DSSM في الدليل / semantic-search /.

الترجيح الأولي لعوامل الترتيب

لقد عملت أولاً على افتراض أن قاعدة الشفرة لا تحتوي على أي أوزان لعوامل الترتيب. ثم صُدمت عندما رأيت أن ملف nav_linear.h في / search / relibility / directory يعرض المعاملات الأولية (أو الأوزان) المرتبطة بعوامل الترتيب على الشاشة الكاملة.

يسلط هذا القسم من الكود الضوء على 257 من أكثر من 17000 عامل ترتيب قمنا بتحديده. ( نصيحة القبعة لريان جونز لسحبها واصطفافها مع أوصاف عامل الترتيب.)

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

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

ثم يتم تسليم قوائم النشر الناتجة إلى MatrixNet مع ميزات الاستعلام للمقارنة معها. لذلك ، بينما لا نعرف تفاصيل العمليات النهائية (حتى الآن) ، لا تزال هذه الأوزان ذات قيمة لفهمها لأنها تخبرك بمتطلبات الصفحة لتكون مؤهلة لمجموعة الاعتبارات.

ومع ذلك ، فإن هذا يطرح السؤال التالي: ماذا نعرف عن MatrixNet؟

يوجد كود تصنيف عصبي في أرشيف Kernel وهناك العديد من الإشارات إلى MatrixNet و "mxnet" بالإضافة إلى العديد من الإشارات إلى النماذج الدلالية ذات الهيكلية العميقة (DSSM) في جميع أنحاء قاعدة الكود.

يشير وصف أحد عوامل الترتيب FI_MATRIXNET إلى تطبيق MatrixNet على جميع العوامل.

عامل {

الفهرس: 160

CppName: "FI_MATRIXNET"

الاسم: "MatrixNet"

العلامات: [TG_DOC، TG_DYNAMIC، TG_TRANS، TG_NOT_01، TG_REARR_USE، TG_L3_MODEL_VALUE، TG_FRESHNESS_FROZEN_POOL]

الوصف: "يتم تطبيق MatrixNet على جميع العوامل - الصيغة"

}

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

ما هو واضح على الفور هو أن هناك مستويات متعددة للترتيب (L1 ، L2 ، L3) وهناك مجموعة متنوعة من نماذج الترتيب التي يمكن اختيارها في كل مستوى.

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

في الوقت الحالي ، دعنا نلقي نظرة على بعض عوامل الترتيب المثيرة للاهتمام.

أهم 5 عوامل تصنيف أولية مرجحة سلبًا

فيما يلي قائمة بأعلى عوامل الترتيب الأولية ذات الترجيح السلبي مع أوزانها وشرح موجز بناءً على أوصافها المترجمة من الروسية.

1. FI_ADV: -0.2509284637 - يحدد هذا العامل أن هناك إعلانًا من أي نوع على الصفحة ويصدر أكبر عقوبة مرجحة لعامل تصنيف واحد.
2. FI_DATER_AGE: -0.2074373667 - هذا العامل هو الفرق بين التاريخ الحالي وتاريخ المستند الذي تحدده دالة التاريخ. القيمة هي 1 إذا كان تاريخ المستند هو نفسه تاريخ اليوم ، 0 إذا كان المستند 10 سنوات أو أكبر ، أو إذا لم يتم تحديد التاريخ. يشير هذا إلى أن Yandex لديه تفضيل للمحتوى الأقدم.
3. FI_QURL_STAT_POWER: -0.1943768768 - هذا العامل هو عدد مرات ظهور عنوان URL من حيث صلته بالاستعلام. يبدو أنهم يريدون خفض ترتيب عنوان URL الذي يظهر في العديد من عمليات البحث لتعزيز تنوع النتائج.
4. FI_COMM_LINKS_SEO_HOSTS: -0.1809636391 - هذا العامل هو النسبة المئوية للروابط الواردة مع نص الربط "التجاري". يعود العامل إلى 0.1 إذا كانت نسبة هذه الروابط أكثر من 50٪ ، وإلا فسيتم ضبطها على 0.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 - هذا العامل هو المصادفة الجغرافية للمستند والبلد الذي بحث المستخدم منه. هذا ليس منطقيًا تمامًا إذا كان الرقم 1 يعني أن المستند والبلد متطابقان.

باختصار ، تشير هذه العوامل إلى أنه للحصول على أفضل نتيجة ، يجب عليك:

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

كل شيء آخر في هذه القائمة خارج عن إرادتك.

أهم 5 عوامل تصنيف أولية مرجحة إيجابياً

للمتابعة ، إليك قائمة بأعلى عوامل الترتيب الإيجابية المرجحة.

1. FI_URL_DOMAIN_FRACTION: +0.5640952971 - هذا العامل هو تداخل إخفاء غريب للاستعلام مقابل مجال عنوان URL. المثال المعطى هو يانصيب تشيليابينسك الذي يختصر بـ chelloto. لحساب هذه القيمة ، يجد Yandex ثلاثة أحرف مغطاة (che ، hel ، lot ، olo) ، انظر إلى نسبة جميع المجموعات المكونة من ثلاثة أحرف في اسم المجال.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 - وصف هذا العامل هو أنه "يجمع بذكاء بين FRC و Pseudo-CTR." لا يوجد مؤشر فوري لما هو FRC.
3. FI_MAX_WORD_HOST_CLICKS: +0.3451158835 - هذا العامل هو إمكانية النقر فوق الكلمة الأكثر أهمية في المجال. على سبيل المثال ، لجميع الاستفسارات التي تحتوي على كلمة "ويكيبيديا" ، انقر فوق صفحات ويكيبيديا.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 - يوضح وصف العامل "أكثر كلمة استعلام مميزة تتوافق مع الموقع ، وفقًا للشريط." أفترض أن هذا يعني الكلمة الرئيسية الأكثر بحثًا عنها في شريط أدوات Yandex المرتبطة بالموقع.
5. FI_IS_COM: +0.2762504972 - العامل هو أن المجال هو COM.

بعبارات أخرى:

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

هناك الكثير من عوامل الترتيب الأولية غير المتوقعة

الأكثر إثارة للاهتمام في عوامل الترتيب المرجحة الأولية هي العوامل غير المتوقعة. فيما يلي قائمة من سبعة عشر عاملاً برزت.

1. FI_PAGE_RANK: +0.1828678331 - PageRank هو العامل السابع عشر الأعلى وزنًا في Yandex. لقد قاموا سابقًا بإزالة الروابط من نظام التصنيف الخاص بهم تمامًا ، لذلك ليس من الصادم مدى انخفاضه في القائمة.
2. FI_SPAM_KARMA: +0.00842682963 - تم تسمية كرمة البريد العشوائي باسم "مضادات البريد العشوائي" وهو احتمال أن يكون المضيف بريدًا عشوائيًا ؛ بناءً على معلومات Whois
3. FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 - ما مدى تطابق الاستعلام والوثيقة بشكل موضوعي. هذا هو التاسع عشر أعلى عامل مرجح.
4. FI_REG_HOST_RANK: +0.1567124399 - لدى Yandex عامل ترتيب مضيف (أو مجال).
5. FI_URL_LINK_PERCENT: +0.08940421124 - نسبة الروابط التي يكون نص رابطها عنوان URL (وليس نصًا) إلى العدد الإجمالي للروابط.
6. FI_PAGE_RANK_UKR: +0.08712279101 - هناك تصنيف صفحات أوكراني محدد
7. FI_IS_NOT_RU: +0.08128946612 - إنه أمر إيجابي إذا لم يكن المجال .RU. على ما يبدو ، فإن محرك البحث الروسي لا يثق بالمواقع الروسية.
8. FI_YABAR_HOST_AVG_TIME2: +0.07417219313 - هذا هو متوسط ​​وقت الإقامة كما ورد بواسطة YandexBar
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 - هذا ارتباط يعتمد على جودة كل رابط
10. FI_NUM_SLASHES: +0.05057609417 - عدد الشرطات في عنوان URL هو عامل ترتيب.
11. FI_ADV_PRONOUNS_PORTION: -0.001250755075 - نسبة أسماء الضمائر على الصفحة.
12. FI_TEXT_HEAD_SYN: -0.01291908335 - وجود كلمات [استعلام] في الرأس ، مع مراعاة المرادفات
13. FI_PERCENT_FREQ_WORDS: -0.02021022114 - النسبة المئوية لعدد الكلمات ، وهي 200 كلمة الأكثر شيوعًا في اللغة ، من عدد كل كلمات النص.
14. FI_YANDEX_ADV: -0.09426121965 - للحصول على مزيد من التحديد مع النفور من الإعلانات ، تعاقب Yandex الصفحات التي تحتوي على إعلانات Yandex.
15. FI_AURA_DOC_LOG_SHARED: -0.09768630485 - لوغاريتم عدد القوباء المنطقية (مناطق النص) في المستند غير الفريدة.
16. FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 - لوغاريتم عدد القوباء المنطقية التي يتم التعرف على مالك المستند عليها كمؤلف.
17. FI_CLASSIF_IS_SHOP: -0.1339319854 - على ما يبدو ، ستمنحك Yandex حبًا أقل إذا كانت صفحتك عبارة عن متجر.

تتمثل النتيجة الأساسية من مراجعة عوامل التصنيف الفردية هذه ومجموعة تلك المتوفرة عبر قاعدة بيانات Yandex البرمجية في أن هناك العديد من الأشياء التي يمكن أن تكون عاملاً للترتيب.

أظن أن "200 إشارة" المبلغ عنها من Google هي في الواقع 200 فئة من الإشارات حيث تكون كل إشارة مركبة من العديد من المكونات الأخرى. بنفس الطريقة التي يحتوي بها Google Analytics على أبعاد مع العديد من المقاييس المرتبطة ، من المحتمل أن يحتوي بحث Google على فئات من إشارات الترتيب تتكون من العديد من الميزات.

تتخلص Yandex من Google و Bing و YouTube و TikTok

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

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

هناك رمز آخر يشير إلى أن Yandex يستخدم بعض بيانات Google كجزء من حسابات DSSM ، لكن عوامل الترتيب 83 التي تحمل اسم Google التي تحمل اسم Google توضح أن Yandex قد استند إلى نتائج Google بشكل كبير.

من الواضح أن Google لن تسحب أبدًا حركة Bing لنسخ نتائج محرك بحث آخر ولن تعتمد على واحدة في حسابات الترتيب الأساسية.

تمتلك Yandex حدودًا عليا لمكافحة تحسين محركات البحث لبعض عوامل الترتيب

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

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

تعزز Yandex "المضيفين الأساسيين"

لدى Yandex سلسلة من آليات التعزيز عبر قاعدة بياناتها البرمجية. هذه تحسينات مصطنعة على مستندات معينة لضمان حصولها على درجات أعلى عند النظر في التصنيف.

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

هناك عدة أنواع من التعزيزات ؛ لقد رأيت دفعة واحدة مرتبطة بالروابط وشاهدت أيضًا سلسلة من "HandJobBoosts" والتي لا يمكنني إلا أن أفترض أنها ترجمة غريبة للتغييرات "اليدوية".

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

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

هيكل خادم المستندات

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

توضح لقطة الشاشة أدناه مجموعة فرعية من تلك الميزات المثيرة للاهتمام بشكل خاص. تشير الملفات الأخرى التي تحتوي على استعلامات SQL إلى أن خادم المستند يحتوي على ما يقرب من 200 عمود بما في ذلك شجرة DOM وأطوال الجملة ووقت الجلب وسلسلة من التواريخ ودرجة مكافحة البريد العشوائي وسلسلة إعادة التوجيه وما إذا كان المستند مترجمًا أم لا. القائمة الأكثر اكتمالا التي صادفتها موجودة في /robot/rthub/yql/protos/web_page_item.proto.

الأكثر إثارة للاهتمام في المجموعة الفرعية هنا هو عدد simhashes المستخدمة. Simhashes هي تمثيلات رقمية للمحتوى وتستخدمها محركات البحث للمقارنة السريعة لتحديد المحتوى المكرر. هناك حالات مختلفة في أرشيف الروبوت تشير إلى خفض مستوى المحتوى المكرر بشكل صريح.

أيضًا ، كجزء من عملية الفهرسة ، يتميز مصدر الشفرة بـ TF-IDF و BM25 و BERT في خط أنابيب معالجة النصوص الخاص به. ليس من الواضح سبب وجود كل هذه الآليات في الكود نظرًا لوجود بعض التكرار في استخدامها جميعًا.

عوامل الارتباط وتحديد الأولويات

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

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

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

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

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

ما الذي يمكننا تطبيقه من Yandex على ما نعرفه عن Google؟

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

ومع ذلك ، هذا هو السؤال الخطأ.

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

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

على سبيل المثال ، قد يكون قياس تشابه جيب التمام بين الاستعلامات والمستندات التي تستخدم زخارف BERT مفيدًا لفهم الصفحات المنافسة لأنها شيء تفعله محركات البحث الحديثة بأنفسها.

في الكثير من الطريقة التي نقلتنا بها سجلات بحث AOL من تخمين توزيع النقرات على SERP ، تنقلنا قاعدة بيانات Yandex بعيدًا عن الملخص إلى الملموس ويمكن أن تكون عبارات "يعتمد عليها" مؤهلة بشكل أفضل.

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

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

في الوقت نفسه ، من المحتمل أن يقوم محامو Google بصياغة خطابات وقف وإيقاف عدوانية تتعلق بكل عمليات الكشط.

أنا متحمس لرؤية تطور مساحتنا مدفوعًا بالأشخاص الفضوليين الذين سيضاعفون هذه الفرصة.

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