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 工程师会继续挖掘，甚至可能会填补足够的缺失来编译这个东西并让它工作。 我也相信不同搜索引擎的工程师也在研究和解析他们可以从中学习并添加到他们的系统中的创新。

同时，谷歌律师可能正在起草与所有抓取相关的积极停止和终止函。

我渴望看到我们空间的演变，这种演变是由好奇的人推动的，他们将最大限度地利用这一机会。

但是，嘿，如果从实际代码中获得洞察力对您没有价值，欢迎您回去做一些更重要的事情，比如争论子域与子目录。