Yandex 代碼庫的“片段”上週在網上洩露。 與穀歌非常相似，Yandex 是一個具有許多方面的平台，例如電子郵件、地圖、出租車服務等。代碼洩漏包含所有這些方面的內容。

根據其中的文檔，Yandex 的代碼庫在 2013 年被合併到一個名為 Arcadia 的大型存儲庫中。洩露的代碼庫是 Arcadia 中所有項目的子集，我們在其中找到了幾個與“內核”、“庫”中的搜索引擎相關的組件”、“機器人”、“搜索”和“ExtSearch”存檔。

此舉是前所未有的。 自從 2006 年的 AOL 搜索查詢數據以來，還沒有與網絡搜索引擎相關的材料進入公共領域。

儘管我們缺少引用的數據和許多文件，但這是第一個切實了解現代搜索引擎如何在代碼級別工作的實例。

就個人而言，當我完成我的書“SEO 的科學”時，我無法忘記能夠真正看到代碼的時機是多麼美妙，我在其中談論信息檢索，現代搜索引擎的實際工作方式以及如何自己構建一個簡單的。

無論如何，自上週四以來我一直在分析代碼，任何工程師都會告訴您沒有足夠的時間來了解一切是如何工作的。 所以，我懷疑在我不斷修改的過程中還會有更多的帖子。

在我們開始之前，我想感謝 Ontolo 的 Ben Wills 與我分享代碼，為我指出好東西所在的初始方向，並在我們破譯事物時與我一起來回走動。 請隨時獲取電子表格，其中包含我們在此處編制的有關排名因素的所有數據。

另外，感謝 Ryan Jones 深入挖掘並通過 IM 與我分享一些重要發現。

好的，讓我們開始吧！

這不是 Google 的代碼，我們為什麼要關心它？

有些人認為審查此代碼庫會分散注意力，並且不會影響他們做出業務決策的方式。 考慮到這些人來自同一個 SEO 社區，他們使用 2006 年 AOL 數據中的 CTR 模型作為行業標準，在隨後的許多年中對任何搜索引擎進行建模，我覺得很好奇。

也就是說，Yandex 不是谷歌。 然而，這兩個都是最先進的網絡搜索引擎，一直保持在技術的最前沿。

兩家公司的軟件工程師參加相同的會議（SIGIR、ECIR 等），分享信息檢索、自然語言處理/理解和機器學習方面的發現和創新。 Yandex 在帕洛阿爾託也有業務，谷歌此前在莫斯科也有業務。

在 LinkedIn 上快速搜索會發現在這兩家公司工作過的數百名工程師，儘管我們不知道其中有多少人實際上在這兩家公司從事過搜索工作。

在更直接的重疊中，Yandex 還利用了谷歌的開源技術，這些技術對搜索領域的創新至關重要，例如 TensorFlow、BERT、MapReduce，以及在較小程度上的 Protocol Buffers。

所以，雖然 Yandex 肯定不是谷歌，但它也不是我們在這裡談論的一些隨機研究項目。 通過查看此代碼庫，我們可以了解很多關於如何構建現代搜索引擎的知識。

至少，我們可以摒棄一些仍然滲透在 SEO 工具中的過時概念，例如文本與代碼的比率和 W3C 合規性，或者人們普遍認為 Google 的 200 個信號只是 200 個單獨的頁上和頁外功能，而不是類別可能使用數以千計的單獨措施的綜合因素。

Yandex 架構的一些背景

如果沒有上下文或無法成功編譯、運行和單步執行它，源代碼就很難理解。

通常，新工程師會獲得文檔、演練並參與結對編程以加入現有代碼庫。 而且，在文檔存檔中有一些與設置構建過程相關的有限入門文檔。 然而，Yandex 的代碼也自始至終都引用了內部 wiki，但這些並沒有洩露，而且代碼中的註釋也相當稀疏。

幸運的是，Yandex 確實在其公開文檔中給出了對其架構的一些見解。 他們在美國也公佈了一些專利，有助於闡明一些問題。 即：

• 用於搜索具有多個發布列表的倒排索引的計算機實現的方法和系統
• 搜索結果排名

由於我一直在為我的書研究 Google，通過各種白皮書、專利和工程師針對我的 SEO 經驗發表的演講，我對其排名系統的結構有了更深入的了解。 我還花了很多時間來加強對 Web 搜索引擎的一般信息檢索最佳實踐的掌握。 毫不奇怪，Yandex 確實有一些最佳實踐和相似之處。

Yandex 的文檔討論了雙分佈式爬蟲系統。 一種用於實時爬行，稱為“Orange Crawler”，另一種用於一般爬行。

從歷史上看，據說谷歌將索引分為三個桶，一個用於實時抓取，一個用於經常抓取，一個用於很少抓取。 這種方法被認為是 IR 中的最佳實踐。

Yandex 和谷歌在這方面有所不同，但由對更新頻率的理解驅動的分段抓取的總體思路是成立的。

值得一提的是，Yandex 沒有單獨的 JavaScript 渲染系統。 他們在文檔中這樣說，雖然他們有基於 Webdriver 的視覺回歸測試系統，稱為 Gemini，但他們將自己限制在基於文本的爬行上。

該文檔還討論了將頁面分解為倒排索引和文檔服務器的分片數據庫結構。

就像大多數其他網絡搜索引擎一樣，索引過程會構建字典、緩存頁面，然後將數據放入倒排索引中，以便表示二元組和三元組及其在文檔中的位置。

這與 Google 的不同之處在於，他們轉向了基於短語的索引，這意味著很久以前 n-gram 的長度可能比 trigram 長得多。

然而，Yandex 系統也在其管道中使用了 BERT，因此在某些時候文檔和查詢被轉換為嵌入，並採用最近鄰搜索技術進行排名。

排名過程是事情開始變得更有趣的地方。

Yandex 有一個名為元搜索的層，在處理查詢後會提供緩存的流行搜索結果。 如果在那裡沒有找到結果，那麼搜索查詢將同時發送到基本搜索層中的一系列數千台不同的機器。 每個構建相關文檔的發布列表，然後將其返回到 MatrixNet，Yandex 用於重新排名的神經網絡應用程序，以構建 SERP。

根據谷歌工程師談論搜索基礎設施的視頻，該排名過程與穀歌搜索非常相似。 他們談到谷歌的技術處於共享環境中，在這種環境中，每台機器上都有各種應用程序，工作根據計算能力的可用性分佈在這些機器上。

其中一個用例就是這樣，將查詢分發到各種機器以快速處理相關的索引分片。 計算發帖列表是我們首先需要考慮排名因素的地方。

代碼庫中有 17,854 個排名因素

在洩密後的那個星期五，無與倫比的馬丁·麥克唐納 (Martin MacDonald) 熱切地分享了代碼庫中的一個名為 web_factors_info/factors_gen.in 的文件。 該文件來自代碼庫洩漏中的“內核”存檔，具有 1,922 個排名因素。

自然地，SEO 社區已經使用該數字和該文件來急切地傳播其中的見解新聞。 許多人已經翻譯了描述並構建了工具或 Google 表格和 ChatGPT 來理解數據。 所有這些都是社區力量的典範。 然而，1,922 只是代碼庫中眾多排名因素之一。

深入研究代碼庫會發現，Yandex 的查詢處理和排名系統的不同子集有許多排名因素文件。

梳理一下，我們發現實際上總共有17,854個排名因素。 這些排名因素包括與以下相關的各種指標：

• 點擊次數。
• 停留時間。
• 利用 Yandex 的 Google Analytics 等效項 Metrika。

還有一系列 Jupyter notebooks，在核心代碼之外還有額外的 2,000 個因素。 據推測，這些 Jupyter notebooks 代表了工程師正在考慮將其他因素添加到代碼庫中的測試。 同樣，您可以通過此鏈接使用我們從代碼庫中收集的元數據來查看所有這些功能。

Yandex 的文檔進一步闡明了它們具有三類排名因素：靜態因素、動態因素以及與用戶搜索及其執行方式相關的因素。 用他們自己的話說：

在代碼庫中，這些在排名因素文件中用標籤 TG_STATIC 和 TG_DYNAMIC 指示。 搜索相關因素有多個標籤，如TG_QUERY_ONLY、TG_QUERY、TG_USER_SEARCH、TG_USER_SEARCH_ONLY。

雖然我們發現了可供選擇的潛在 18k 排名因素，但與 MatrixNet 相關的文檔表明評分是根據數万個因素構建的，並根據搜索查詢進行定制。

這表明排名環境是高度動態的，類似於 Google 環境。 根據谷歌的“評估評分函數的框架”專利，他們長期以來一直有類似的東西，可以運行多個函數並返回最佳結果集。

最後，考慮到文檔引用了數以萬計的排名因素，我們還應該記住，代碼中引用的許多其他文件在存檔中缺失。 因此，可能還有更多我們看不到的事情發生。 通過查看入職文檔中的圖像進一步說明了這一點，該文檔顯示了存檔中不存在的其他目錄。

例如，我懷疑 /semantic-search/ 目錄中有更多與 DSSM 相關的內容。

排名因素的初始權重

我首先假設代碼庫沒有任何排名因素的權重。 然後我震驚地看到 /search/relevance/ 目錄中的 nav_linear.h 文件具有與完整顯示的排名因素相關的初始係數（或權重）。

這部分代碼突出顯示了我們已確定的 17,000 多個排名因素中的 257 個。 （向 Ryan Jones 致敬，因為他提取了這些內容並將它們與排名因素描述對齊。）

為清楚起見，當您想到搜索引擎算法時，您可能會想到一個長而復雜的數學方程式，每個頁面都根據一系列因素進行評分。 雖然這過於簡單化，但以下屏幕截圖是此類等式的摘錄。 係數表示每個因素的重要性，計算得出的分數將用於對選擇器頁面的相關性進行評分。

這些值是硬編碼的，這表明這肯定不是唯一發生排名的地方。 相反，此功能最有可能用於完成初始相關性評分，以便為考慮排名的每個分片生成一系列發布列表。 在上面列出的第一項專利中，他們將此作為查詢獨立相關性 (QIR) 的概念進行討論，然後在審查文檔的查詢特定相關性 (QSR) 之前限製文檔。

然後將生成的發布列表傳遞給具有查詢功能的 MatrixNet 以進行比較。 因此，雖然我們（還）不知道下游操作的具體細節，但了解這些權重仍然很有價值，因為它們告訴您頁面符合考慮集的要求。

然而，這帶來了下一個問題：我們對 MatrixNet 了解多少？

內核存檔中有神經排名代碼，整個代碼庫中有大量對 MatrixNet 和“mxnet”的引用以及對深度結構化語義模型 (DSSM) 的許多引用。

FI_MATRIXNET 排名因素之一的描述表明 MatrixNet 應用於所有因素。

因素 {

指數：160

CppName：“FI_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），並且可以在每個級別選擇各種排名模型。

selecting_rankings_model.cpp 文件建議在整個過程中的每一層都可以考慮不同的排名模型。 這基本上就是神經網絡的工作原理。 每個級別都是完成操作的一個方面，它們的組合計算產生重新排序的文檔列表，最終顯示為 SERP。 當我有更多時間時，我將繼續深入研究 MatrixNet。 對於那些需要先睹為快的人，請查看搜索結果排名器專利。

現在，讓我們來看看一些有趣的排名因素。

前 5 個負權重的初始排名因素

以下是負權重最高的初始排名因素及其權重的列表，以及基於從俄語翻譯而來的描述的簡要說明。

1. FI_ADV: -0.2509284637 - 該因素決定頁面上是否存在任何類型的廣告，並對單個排名因素發出最重的加權懲罰。
2. FI_DATER_AGE： -0.2074373667 – 該因子是當前日期與日期函數確定的文檔日期之間的差異。 如果文檔日期與今天相同，則值為 1；如果文檔為 10 年或更早，或者日期未定義，則值為 0。 這表明 Yandex 偏愛較舊的內容。
3. FI_QURL_STAT_POWER： -0.1943768768 – 這個因素是與查詢相關的 URL 印像數。 似乎他們想要降級出現在許多搜索中的 URL 以促進結果的多樣性。
4. FI_COMM_LINKS_SEO_HOSTS： -0.1809636391——這個因素是帶有“商業”錨文本的入站鏈接的百分比。 如果此類鏈接的比例超過 50%，則該因子恢復為 0.1，否則設置為 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和偽CTR的巧妙結合”。 沒有立即說明 FRC 是什麼。
3. FI_MAX_WORD_HOST_CLICKS: +0.3451158835 – 這個因素是域中最重要的詞的可點擊性。 例如，對於所有包含單詞“wikipedia”的查詢，請單擊 wikipedia 頁面。
4. FI_MAX_WORD_HOST_YABAR： +0.3154394573 - 因素描述為“根據欄，與站點相對應的最具特徵的查詢詞。” 我假設這意味著在與網站關聯的 Yandex 工具欄中搜索最多的關鍵字。
5. FI_IS_COM： +0.2762504972 – 因素是域是 .COM。

換句話說：

• 與您的域名玩文字遊戲。
• 確保它是.com。
• 鼓勵人們在 Yandex Bar 中搜索您的目標關鍵字。
• 繼續推動點擊。

有很多意想不到的初始排名因素

初始加權排名因素中更有趣的是意想不到的因素。 以下列出了 17 個突出的因素。

1. FI_PAGE_RANK： +0.1828678331 – PageRank 是 Yandex 中第 17 高的加權因子。 他們之前從他們的排名系統中完全刪除了鏈接，所以它在列表中的排名有多低並不令人震驚。
2. FI_SPAM_KARMA： +0.00842682963 – 垃圾郵件業力以“反垃圾郵件發送者”命名，表示主機是垃圾郵件的可能性； 基於 Whois 信息
3. FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – 查詢和文檔在主題上的匹配程度。 這是第 19 位最高的加權因素。
4. FI_REG_HOST_RANK: +0.1567124399 – Yandex 有一個主機（或域）排名因素。
5. FI_URL_LINK_PERCENT： +0.08940421124 – 錨文本為 URL（而不是文本）的鏈接佔鏈接總數的比率。
6. FI_PAGE_RANK_UKR: +0.08712279101 – 有一個特定的烏克蘭 PageRank
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 – 標題中存在 [query] 詞，同時考慮同義詞
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 代碼庫中可用的一系列因素的主要收穫是，有很多因素可能是排名因素。

我懷疑 Google 報告的“200 個信號”實際上是 200 個信號類別，其中每個信號都是由許多其他組件構成的組合。 與 Google Analytics（分析）的維度與許多指標相關聯的方式大致相同，Google 搜索可能具有由許多特徵組成的排名信號類別。

Yandex 抓取 Google、Bing、YouTube 和 TikTok

代碼庫還顯示，Yandex 有許多針對其他網站及其各自服務的解析器。 對於西方人來說，其中最值得注意的是我在上面的標題中列出的那些。 此外，Yandex 有針對我不熟悉的各種服務的解析器，也有針對它自己的服務的解析器。

顯而易見的是，解析器功能完備。 Google SERP 的每個有意義的組件都被提取出來。 事實上，任何可能正在考慮刪除這些服務中的任何一個的人都應該好好檢查一下這段代碼。

還有其他代碼表明 Yandex 正在使用一些谷歌數據作為 DSSM 計算的一部分，但 83 個谷歌命名的排名因素本身清楚地表明 Yandex 非常依賴谷歌的結果。

顯然，谷歌永遠不會像 Bing 那樣複製另一個搜索引擎的結果，也不會依賴某個搜索引擎進行核心排名計算。

Yandex 有一些排名因素的反 SEO 上限

315 排名因素有閾值，超過該閾值的任何計算值都會向系統表明頁面的該功能被過度優化。 這些排名因素中的 39 個是初始加權因素的一部分，可能會阻止頁面被包含在初始發布列表中。 您可以通過過濾排名係數和反 SEO 列在我上面鏈接的電子表格中找到這些。

從概念上講，期望所有現代搜索引擎都對 SEO 歷來濫用的某些因素（例如錨文本、點擊率或關鍵字堆砌）設置閾值並不牽強。 例如，據說 Bing 將濫用元關鍵字作為負面因素。

Yandex 提升“重要主機”

Yandex 在其代碼庫中有一系列提昇機制。 這些是對某些文檔的人為改進，以確保它們在考慮排名時得分更高。

下面是來自“提升嚮導”的評論，它建議較小的文件從提升算法中受益最大。

有幾種類型的提升； 我見過一個與鏈接相關的提升，我也見過一系列“HandJobBoosts”，我只能假設這是“手動”更改的奇怪翻譯。

我發現特別有趣的其中一項提升與“重要宿主”有關。 其中重要主機可以是指定的任何站點。 變量中特別提到的是 NEWS_AGENCY_RATING，這讓我相信 Yandex 提供了一種提升，使其結果偏向某些新聞機構。

在不涉及地緣政治的情況下，這與穀歌有很大不同，因為他們一直堅持不將這樣的偏見引入他們的排名系統。

文檔服務器的結構

代碼庫揭示了文檔是如何存儲在 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 和谷歌之間肯定有很多相似之處，但說實話，只有從事搜索工作的谷歌軟件工程師才能明確回答這個問題。

然而，這是一個錯誤的問題。

真的，這段代碼應該能幫助我們擴展對現代搜索的思考。 對搜索的大部分集體理解是建立在 SEO 社區在 2000 年代初期通過測試和搜索工程師口中學到的知識的基礎上的，當時搜索遠沒有那麼不透明。 不幸的是，這跟不上創新的快速步伐。

從 Yandex 洩漏的許多特徵和因素中獲得的洞察力應該會產生更多的事物假設來測試和考慮在谷歌中的排名。 他們還應該引入更多可以被SEO爬取、鏈接分析和排名工具解析和衡量的東西。

例如，使用 BERT 嵌入來衡量查詢和文檔之間的餘弦相似度對於理解競爭對手頁面可能很有價值，因為這是現代搜索引擎本身正在做的事情。

就像 AOL 搜索日誌讓我們不再猜測 SERP 上的點擊分佈一樣，Yandex 代碼庫讓我們從抽象轉向具體，我們的“視情況而定”的陳述可以得到更好的限定。

為此，該代碼庫是一份將繼續贈送的禮物。 這只是一個週末，我們已經從這段代碼中收集到了一些非常引人注目的見解。

我預計一些有更多時間的雄心勃勃的 SEO 工程師會繼續挖掘，甚至可能會填補足夠的缺失來編譯這個東西並讓它工作。 我也相信不同搜索引擎的工程師也在研究和解析他們可以從中學習並添加到他們的系統中的創新。

同時，谷歌律師可能正在起草與所有抓取相關的積極停止和終止函。

我渴望看到我們空間的演變，這種演變是由好奇的人推動的，他們將最大限度地利用這一機會。

但是，嘿，如果從實際代碼中獲得洞察力對您沒有價值，歡迎您回去做一些更重要的事情，比如爭論子域與子目錄。