Yandex は、ソースコードリークから Google やその他の SEO の教訓をかき集めます

公開: 2023-01-31

先週、Yandex のコードベースの「フラグメント」がオンラインで流出しました。 Google と同じように、Yandex は電子メール、地図、タクシーサービスなど、さまざまな側面を持つプラットフォームです。コードリークは、そのすべてのチャンクを特徴としていました。

そこにある文書によると、Yandex のコードベースは 2013 年に Arcadia と呼ばれる 1 つの大きなリポジトリに折りたたまれていました。リークされたコードベースは、Arcadia のすべてのプロジェクトのサブセットであり、「カーネル」、「ライブラリ」の検索エンジンに関連するいくつかのコンポーネントが見つかりました。、「ロボット」、「検索」、および「ExtSearch」アーカイブ。

この動きはまったく前例のないものです。 2006 年の AOL 検索クエリデータには、Web 検索エンジンに関連する資料がパブリックドメインに入ったようなものがあります。

参照されているデータと多くのファイルが不足していますが、これは、最新の検索エンジンがコードレベルでどのように機能するかを具体的に示した最初の例です。

個人的には、情報検索、最新の検索エンジンが実際にどのように機能し、どのように機能するかについて話している著書「The Science of SEO」を読み終えるときに、コードを実際に見ることができるタイミングがどれほど素晴らしいかを理解することはできません。簡単なものを自分で構築する。

いずれにせよ、私は先週の木曜日からコードを解析してきましたが、どのエンジニアも、すべてがどのように機能するかを理解するのに十分な時間ではないと言うでしょう。ですから、いじり続けているので、さらにいくつかの投稿があると思います。

本題に入る前に、コードを共有してくれた Ontolo の Ben Wills 氏に感謝したいと思います。コードを共有し、良いものがどこにあるかという最初の方向性を教えてくれました。ここでランキング要因についてまとめたすべてのデータを含むスプレッドシートを自由に入手してください.

また、重要な調査結果を IM で掘り下げて共有してくれた Ryan Jones に声をかけてください。

よし、忙しくしよう！

これは Google のコードではありません。

このコードベースをレビューすることは気を散らすものであり、ビジネス上の意思決定に影響を与えるものは何もないと信じている人もいます. これらが、2006 年の AOL データの CTR モデルを、その後何年にもわたってあらゆる検索エンジンでのモデリングの業界標準として使用してきた同じ SEO コミュニティの人々であることを考えると、興味深いと思います。

つまり、Yandex は Google ではありません。それでもこの 2 つは最先端の Web 検索エンジンであり、テクノロジーの最先端に留まり続けています。

両社のソフトウェアエンジニアは同じカンファレンス (SIGIR、ECIR など) に参加し、情報検索、自然言語処理/理解、機械学習に関する調査結果とイノベーションを共有します。 Yandex はパロアルトにも存在し、Google は以前はモスクワに存在していました。

LinkedIn をすばやく検索すると、両社で働いたことのある数百人のエンジニアが見つかりますが、実際に両社で検索に携わったエンジニアの数はわかりません。

より直接的な重複として、Yandex は、TensorFlow、BERT、MapReduce などの検索の革新に不可欠な Google のオープンソーステクノロジも利用していますが、プロトコルバッファもそれほどではありません。

したがって、Yandex は確かに Google ではありませんが、ここで話しているランダムな研究プロジェクトでもありません。このコードベースを確認することで、最新の検索エンジンがどのように構築されているかについて、多くのことを学ぶことができます。

少なくとも、テキスト対コードの比率や W3C 準拠などの SEO ツールにまだ浸透している時代遅れの概念や、Google の 200 のシグナルは単に 200 個の個別のオンページおよびオフページの機能であるという一般的な考えを、私たちは自分自身から解放することができます。潜在的に何千もの個別の測定値を使用する複合要因。

Yandex のアーキテクチャに関するいくつかのコンテキスト

コンテキストがなく、ソースコードを正常にコンパイル、実行、ステップ実行する機能がなければ、ソースコードを理解するのは非常に困難です。

通常、新人エンジニアはドキュメントやウォークスルーを入手し、ペアプログラミングに参加して既存のコードベースに慣れます。また、ドキュメントアーカイブには、ビルドプロセスの設定に関連する限定的なオンボーディングドキュメントがいくつかあります。ただし、Yandex のコードは内部の wiki も参照していますが、それらは漏洩しておらず、コード内のコメントもかなりまばらです。

幸いなことに、Yandex はその公開ドキュメントでそのアーキテクチャに関する洞察を提供しています。彼らが米国で公開したいくつかの特許もあり、少し光を当てるのに役立ちます. すなわち：

複数のポスティングリストを有する転置インデックスを検索するためのコンピュータで実行される方法およびシステム
検索結果ランカー

著書のために Google を研究しているうちに、さまざまなホワイトペーパー、特許、および私の SEO 経験に反するエンジニアからの講演を通じて、Google のランキングシステムの構造をより深く理解することができました。また、Web 検索エンジンの一般的な情報検索のベストプラクティスの把握に多くの時間を費やしました。 Yandex にいくつかのベストプラクティスと類似点があることは当然のことです。

Yandex のドキュメントでは、デュアル分散クローラーシステムについて説明しています。 1 つは「Orange Crawler」と呼ばれるリアルタイムクロール用で、もう 1 つは一般的なクロール用です。

歴史的に、Google は 3 つのバケットに階層化されたインデックスを持っていたと言われています。このアプローチは、IR のベストプラクティスと見なされます。

この点で Yandex と Google は異なりますが、更新頻度の理解によって駆動されるセグメント化されたクロールの一般的な考え方は保持されます。

注目すべきことの 1 つは、Yandex には JavaScript 用の個別のレンダリングシステムがないことです。彼らはドキュメントでこれを述べており、Gemini と呼ばれるビジュアルリグレッションテスト用の Webdriver ベースのシステムを持っていますが、テキストベースのクロールに限定しています。

このドキュメントでは、ページを逆インデックスとドキュメントサーバーに分割するシャードデータベース構造についても説明しています。

他のほとんどの Web 検索エンジンと同様に、インデックス作成プロセスは辞書を作成し、ページをキャッシュしてから、逆インデックスにデータを配置して、バイグラムとトライガム、およびそれらのドキュメント内での配置を表します。

これは、フレーズベースのインデックス作成に移行したという点で Google とは異なります。つまり、ずっと前のトリグラムよりもはるかに長くなる可能性のある n グラムを意味します。

ただし、Yandex システムはパイプラインでも BERT を使用するため、ある時点でドキュメントとクエリが埋め込みに変換され、最近傍検索手法がランキングに使用されます。

ランキングプロセスは、物事がより面白くなり始めるところです.

Yandex にはMetasearchと呼ばれるレイヤーがあり、キャッシュされた人気のある検索結果がクエリの処理後に提供されます。そこに結果が見つからない場合、検索クエリは、基本検索レイヤー内の一連の数千の異なるマシンに同時に送信されます。それぞれが関連ドキュメントの投稿リストを作成し、それを Yandex のニューラルネットワークアプリケーションである MatrixNet に返し、再ランキングして SERP を作成します。

Google のエンジニアが検索のインフラストラクチャについて話しているビデオに基づくと、そのランキングプロセスは Google 検索と非常によく似ています。彼らは、さまざまなアプリケーションがすべてのマシンにあり、コンピューティング能力の可用性に基づいてそれらのマシンにジョブが分散されている共有環境にある Google の技術について語っています。

ユースケースの 1 つは、まさにこれです。関連するインデックスシャードをすばやく処理するために、さまざまなマシンにクエリを分散します。投稿リストの計算は、ランキング要因を考慮する必要がある最初の場所です。

コードベースには 17,854 のランキング要素があります

リークに続く金曜日に、比類のない Martin MacDonald が web_factors_info/factors_gen.in というコードベースのファイルを熱心に共有しました。このファイルは、コードベースリークの「Kernel」アーカイブからのもので、1,922 のランキング要素を備えています。

当然のことながら、SEO コミュニティはその数とそのファイルを使用して、そこにある洞察のニュースを熱心に広めてきました。多くの人が説明を翻訳し、ツールや Google スプレッドシート、ChatGPT を構築して、データを理解しています。これらはすべて、コミュニティの力を示す素晴らしい例です。ただし、1,922 は、コードベースの多数のランキング要素セットの 1 つにすぎません。

コードベースを深く掘り下げると、Yandex のクエリ処理およびランキングシステムのさまざまなサブセットに多数のランキングファクターファイルがあることがわかります。

それらを総合すると、実際には合計で 17,854 のランキング要素があることがわかります。これらのランキング要因には、以下に関連するさまざまな指標が含まれます。

クリック。
滞留時間。
Yandex の Google Analytics に相当する Metrika を活用します。

また、コアコード以外に 2,000 個の要素を追加した一連の Jupyter ノートブックもあります。おそらく、これらの Jupyter ノートブックは、エンジニアがコードベースに追加する要素を検討しているテストを表しています。繰り返しになりますが、このリンクでコードベース全体から収集したメタデータを使用して、これらすべての機能を確認できます。

Yandex のドキュメントでは、ランク付け要因の 3 つのクラスがあることをさらに明確にしています。静的、動的、およびユーザーの検索とその実行方法に特に関連するものです。彼ら自身の言葉で：

コードベースでは、これらはタグ TG_STATIC および TG_DYNAMIC を持つランク係数ファイルで示されます。検索関連の要素には、TG_QUERY_ONLY、TG_QUERY、TG_USER_SEARCH、TG_USER_SEARCH_ONLY などの複数のタグがあります。

18,000 のランキング要素から選択できる可能性があることを明らかにしましたが、MatrixNet に関連するドキュメントは、スコアリングが何万もの要素から構築され、検索クエリに基づいてカスタマイズされていることを示しています。

これは、Google の環境と同様に、ランキング環境が非常に動的であることを示しています。 Google の「スコアリング関数を評価するためのフレームワーク」特許によると、複数の関数が実行され、最良の結果セットが返されるという類似の機能が以前からありました。

最後に、ドキュメントが何万ものランキング要因を参照していることを考慮すると、アーカイブから欠落しているコードで参照されている他の多くのファイルがあることにも留意する必要があります. そのため、私たちが見ることができないことがさらに進行している可能性があります。これは、アーカイブに存在しない他のディレクトリを示すオンボーディングドキュメントの画像を確認することでさらに説明されます。

オンボーディングドキュメントディレクトリがありません Yandex 800x503

たとえば、/semantic-search/ ディレクトリには DSSM にもっと関連するものがあるのではないかと思います。

上位 5 つの負の加重の初期ランキング要因

以下は、最大の負の加重の初期ランキング要因のリストと、その加重およびロシア語から翻訳された説明に基づく簡単な説明です。

FI_ADV: -0.2509284637 - この要素は、ページにあらゆる種類の広告があることを判断し、1 つのランキング要素に対して最も重いペナルティを課します。
FI_DATER_AGE: -0.2074373667 – この係数は、現在の日付と日付関数によって決定されたドキュメントの日付との差です。ドキュメントの日付が今日と同じ場合は 1、ドキュメントが 10 年以上前の場合、または日付が定義されていない場合は 0 です。これは、Yandex が古いコンテンツを優先していることを示しています。
FI_QURL_STAT_POWER: -0.1943768768 – この係数は、クエリに関連する URL インプレッション数です。結果の多様性を促進するために、多くの検索で表示される URL を降格させたいようです。
FI_COMM_LINKS_SEO_HOSTS: -0.1809636391 – この係数は、「商用」アンカーテキストを含むインバウンドリンクの割合です。そのようなリンクの割合が 50% を超える場合、係数は 0.1 に戻り、それ以外の場合は 0 に設定されます。
FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – この要因は、ドキュメントとユーザーが検索した国の地理的な一致です。 1 がドキュメントと国が一致することを意味する場合、これはあまり意味がありません。

要約すると、これらの要因は、最高のスコアを得るには次のことを行う必要があることを示しています。

広告を避けます。
新しいページを作成するのではなく、古いコンテンツを更新します。
ほとんどのリンクに、ブランド化されたアンカーテキストが含まれていることを確認してください。

このリストの他のすべては、あなたの制御を超えています。

上位 5 つの正の加重の初期ランキング要因

フォローアップとして、最も加重された正のランキング要因のリストを次に示します。

FI_URL_DOMAIN_FRACTION: +0.5640952971 – この要因は、クエリと URL のドメインの奇妙なマスキングの重複です。与えられた例は、チェロトと略されるチェリャビンスクの宝くじです。この値を計算するために、Yandex は対象となる 3 文字 (che、hel、lot、olo) を見つけ、すべての 3 文字の組み合わせのうちドメイン名に含まれる割合を確認します。
FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – この要因の説明は、「FRC と疑似 CTR を巧みに組み合わせたもの」です。 FRC とは何かをすぐに示すものはありません。
FI_MAX_WORD_HOST_CLICKS: +0.3451158835 – この要素は、ドメイン内で最も重要な単語のクリック可能性です。たとえば、「ウィキペディア」という単語が含まれるすべてのクエリについて、ウィキペディアのページをクリックします。
FI_MAX_WORD_HOST_YABAR: +0.3154394573 – 要因の説明には、「バーによると、サイトに対応する最も特徴的なクエリワード」と記載されています。これは、サイトに関連付けられた Yandex ツールバーで最も検索されたキーワードを意味すると思います。
FI_IS_COM: +0.2762504972 – 要因は、ドメインが .COM であることです。

言い換えると：

あなたのドメインで言葉遊びをしましょう。
ドットコムであることを確認してください。
Yandex バーでターゲットキーワードを検索するよう人々に勧めます。
クリックを促進し続けます。

予想外の初期ランキング要因がたくさんあります

初期の重み付けされたランキング要因でさらに興味深いのは、予想外のものです。以下は、際立った17の要因のリストです。

FI_PAGE_RANK: +0.1828678331 – PageRank は、Yandex で 17 番目に高い加重係数です。彼らは以前にランキングシステムからリンクを完全に削除していたので、リストの低さはそれほど衝撃的ではありません.
FI_SPAM_KARMA: +0.00842682963 – スパムカルマは「スパム対策者」にちなんで名付けられ、ホストがスパムである可能性を示します。 Whois情報に基づく
FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – クエリとドキュメントがテーマ的にどの程度一致しているか。これは 19 番目に高い加重係数です。
FI_REG_HOST_RANK: +0.1567124399 – Yandex にはホスト (またはドメイン) ランキング係数があります。
FI_URL_LINK_PERCENT: +0.08940421124 – リンクの総数に対する、アンカーテキストが (テキストではなく) URL であるリンクの割合。
FI_PAGE_RANK_UKR: +0.08712279101 – 特定のウクライナの PageRank があります
FI_IS_NOT_RU: +0.08128946612 – ドメインが .RU でない場合、それはポジティブなことです。どうやら、ロシアの検索エンジンはロシアのサイトを信頼していないようです。
FI_YABAR_HOST_AVG_TIME2: +0.07417219313 – これは、YandexBar によって報告された平均滞留時間です。
FI_LERF_LR_LOG_RELEV: +0.06059448504 – これは、各リンクの品質に基づくリンクの関連性です。
FI_NUM_SLASHES: +0.05057609417 – URL のスラッシュの数はランキング要因です。
FI_ADV_PRONOUNS_PORTION: -0.001250755075 – ページ上の代名詞の割合。
FI_TEXT_HEAD_SYN: -0.01291908335 – 同義語を考慮した、ヘッダー内の [クエリ] 単語の存在
FI_PERCENT_FREQ_WORDS: -0.02021022114 – テキストの全単語数に対する、その言語で最も頻繁に使用される 200 の単語である単語数のパーセンテージ。
FI_YANDEX_ADV: -0.09426121965 – 広告に対する嫌悪感をより具体的にすると、Yandex は Yandex 広告のあるページにペナルティを課します。
FI_AURA_DOC_LOG_SHARED: -0.09768630485 – ドキュメント内の一意でないシングル (テキストの領域) の数の対数。
FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 – ドキュメントのこの所有者が作成者として認識されるシングル数の対数。
FI_CLASSIF_IS_SHOP: -0.1339319854 – どうやら、あなたのページがストアである場合、Yandex はあなたにあまり愛を与えないでしょう.

これらの奇妙なランキング要因と、Yandex コードベース全体で利用可能なそれらの配列を確認することから得られる主なポイントは、ランキング要因になり得るものがたくさんあるということです。

Google が報告した「200 個のシグナル」は、実際には 200 クラスのシグナルであり、各シグナルは他の多くのコンポーネントから構成された複合体であると思われます。 Google アナリティクスに多くの指標が関連付けられたディメンションがあるのとほぼ同じように、Google 検索には、多くの機能で構成されるランキングシグナルのクラスがある可能性があります。

Yandex が Google、Bing、YouTube、TikTok をスクレイピング

コードベースは、Yandex が他の Web サイトとそれぞれのサービス用の多くのパーサーを持っていることも明らかにしています。西洋人にとって最も注目に値するのは、私が上記の見出しに挙げたものです. さらに、Yandex には、独自のサービスのパーサーだけでなく、私がよく知らなかったさまざまなサービスのパーサーがあります。

すぐにわかることは、パーサーの機能が完全であることです。 Google SERP のすべての意味のあるコンポーネントが抽出されます。実際、これらのサービスのいずれかをスクレイピングすることを検討している可能性がある人は、このコードを確認することをお勧めします。

Yandex が DSSM 計算の一部として Google のデータを使用していることを示すコードは他にもありますが、Google が指定した 83 のランキング要因自体から、Yandex が Google の結果にかなり依存していることは明らかです。

明らかに、Google は、別の検索エンジンの結果をコピーするという Bing の動きを決して引っ張ったり、コアランキングの計算を別の検索エンジンに依存したりすることはありません。

Yandex には、いくつかのランキング要素についてアンチ SEO の上限があります。

315 のランキング要素にはしきい値があり、それを超える計算値は、ページのその機能が最適化されすぎていることをシステムに示します。これらのランキング要素のうち 39 は、ページが最初の投稿リストに含まれない可能性がある最初に重み付けされた要素の一部です。これらは、上でリンクしたスプレッドシートで、ランク係数とアンチ SEO 列をフィルターすることで見つけることができます。

最新のすべての検索エンジンが、アンカーテキスト、CTR、キーワードスタッフィングなど、SEO が歴史的に悪用してきた特定の要因にしきい値を設定していると考えるのは、概念的には大げさではありません。たとえば、Bing は、メタキーワードの乱用をマイナス要因として利用しているとのことでした。

Yandexは「重要なホスト」を後押しします

Yandex には、コードベース全体に一連のブーストメカニズムがあります。これらは、特定のドキュメントを人為的に改良したもので、ランキングの対象となる際にスコアが高くなるようにします。

以下は「ブースティングウィザード」からのコメントで、小さなファイルほどブースティングアルゴリズムのメリットが大きいことを示唆しています。

ブーストにはいくつかの種類があります。リンクに関連するブーストを 1 つ見たことがあります。また、一連の「HandJobBoosts」も見ましたが、これは「手動」変更の奇妙な翻訳であるとしか思えません。

私が特に興味深いと思ったこれらのブーストの 1 つは、「Vital Hosts」に関連しています。重要なホストは、指定された任意のサイトにすることができます。変数で具体的に言及されているのは NEWS_AGENCY_RATING であり、Yandex が結果を特定の報道機関に偏らせるブーストを与えていると私は信じています。

地政学に立ち入らない限り、ランキングシステムにこのようなバイアスを導入しないことに固執しているという点で、これはGoogleとは大きく異なります.

ドキュメントサーバーの構造

コードベースは、ドキュメントが Yandex のドキュメントサーバーにどのように格納されているかを明らかにします。これは、検索エンジンが単にページのコピーを作成してキャッシュに保存するのではなく、さまざまな機能をメタデータとしてキャプチャして、下流のランキングプロセスで使用することを理解するのに役立ちます。

以下のスクリーンショットは、特に興味深い機能のサブセットを強調しています。 SQL クエリを含む他のファイルは、ドキュメントサーバーに、DOM ツリー、文の長さ、フェッチ時間、一連の日付、スパム対策スコア、リダイレクトチェーン、ドキュメントが翻訳されているかどうかなど、200 近くの列があることを示唆しています。私が見つけた最も完全なリストは、/robot/rthub/yql/protos/web_page_item.proto にあります。

このサブセットで最も興味深いのは、採用されている simhash の数です。 Simhash はコンテンツの数値表現であり、検索エンジンはそれらを使用して重複コンテンツを判断するための超高速比較を行います。ロボットアーカイブには、重複するコンテンツが明示的に降格されていることを示すさまざまなインスタンスがあります。

また、インデックス作成プロセスの一環として、コードベースのテキスト処理パイプラインに TF-IDF、BM25、および BERT が組み込まれています。これらすべてのメカニズムを使用すると冗長性が生じるため、これらすべてのメカニズムがコードに存在する理由は明らかではありません。

リンク要因と優先順位

Yandex がリンク要素をどのように処理するかは、以前は影響を完全に無効にしていたため、特に興味深いものです。コードベースは、リンク要素とリンクの優先順位に関する多くの情報も明らかにします。

Yandex のリンクスパム計算機には、89 の要因があります。 SF_RESERVED とマークされているものはすべて非推奨です。提供されている場合は、上記のリンク先の Google スプレッドシートでこれらの要素の説明を見つけることができます。

特に、Yandex にはホストランクといくつかのスコアがあり、サイトまたはページがスパムの評判を高めた後も長期間存続するように見えます。

Yandex が行うもう 1 つのことは、ドメイン全体のコピーを確認し、それらのリンクに重複するコンテンツがないかどうかを判断することです。これは、サイト全体のリンクの配置、重複したページへのリンク、または同じサイトからの同じアンカーテキストを持つ単純なリンクである可能性があります。

これは、同じソースからの複数のリンクを割り引くことがいかに簡単であるかを示しており、より多様なソースからのよりユニークなリンクをターゲットにすることがいかに重要であるかを明確にしています。

Yandex から Google について知っていることを適用するにはどうすればよいでしょうか?

当然のことながら、これは今でも誰もが頭に浮かぶ問題です。 Yandex と Google の間には確かに多くの類似点がありますが、正直なところ、検索に取り組んでいる Google ソフトウェアエンジニアだけがその質問に明確に答えることができます。

しかし、それは間違った質問です。

実際、このコードは、最新の検索についての考え方を広げるのに役立つはずです。検索に対する集合的な理解の多くは、SEO コミュニティが 2000 年代初頭にテストを通じて学んだことと、検索がそれほど不透明ではなかった時代の検索エンジニアの口から得られたものに基づいています。残念ながら、それはイノベーションの急速なペースに追いついていません。

Yandex リークの多くの機能と要因からの洞察は、Google でのランキングのためにテストおよび検討すべき事柄のより多くの仮説を生み出すはずです。また、SEO クロール、リンク分析、およびランキングツールによって解析および測定できるものをさらに導入する必要があります。

たとえば、BERT 埋め込みを使用したクエリとドキュメント間のコサイン類似度の測定は、最新の検索エンジン自体が行っていることであるため、競合他社のページと比較して理解するのに役立ちます。

AOL 検索ログが SERP 上のクリックの分布を推測することから私たちを動かしたのと同じように、Yandex コードベースは私たちを抽象的なものから具体的なものへと動かし、私たちの「依存する」ステートメントをより適切に修飾することができます.

そのために、このコードベースは贈り物であり続けます。まだ週末しか経っていませんが、このコードから非常に説得力のある洞察をすでに得ています。

私は、野心的な SEO エンジニアの中には、はるかに多くの時間を持てるものを掘り下げ続け、おそらく、これをコンパイルして機能させるために不足しているものを十分に埋めることさえあると予想しています。また、さまざまな検索エンジンのエンジニアも、システムから学び、システムに追加できるイノベーションを検討し、分析していると思います。

同時に、Google の弁護士はおそらく、すべてのスクレイピングに関連する攻撃的な停止通知書を起草しています。

この機会を最大限に活用しようとする好奇心旺盛な人々によって推進される、私たちのスペースの進化を楽しみにしています。

しかし、実際のコードから洞察を得ることに価値がない場合は、サブドメインとサブディレクトリについて議論するなど、もっと重要なことに戻ってもかまいません。

この記事で表明された意見はゲスト著者のものであり、必ずしも Search Engine Land ではありません。 スタッフの著者はここにリストされています。

Search Engine Land を Google ニュースフィードに追加します。

Yandex は、ソース コード リークから Google やその他の SEO の教訓をかき集めます