Gre*_*reg 6 architecture search search-engine
Google 为何能够如此快速地执行搜索？
在花了一些时间思考搜索之后，我意识到它是多么复杂。
在查询方面： 如果人们输入的查询数量有限（例如1-2个单词），则可以预先计算所有网站的结果，然后进行查找。
如果查询长度为 1-2 个单词，这可能会很有效。然而，实际查询中的单词数量可能很大，因此唯一查询的数量几乎是无限的。这意味着虽然某些查询可能是预先计算的，但其余的几乎肯定不是。有趣的是，谷歌返回较长查询的时间并不比返回较短查询的时间明显长。
在文档方面：根据我的理解，谷歌从每个文档构建特征（例如词频、链接等），并通过算法（很可能是机器学习算法？）运行它。
假设某些特征对于所有查询都是相同的（例如排名靠前的网站的链接数量），而其他特征则更特定于查询（例如查询词在文档中出现了多少次），是否正确？
鉴于上述情况，这是否意味着每个查询都必须为 Google 索引中的每个文档生成特征？如果不是，谷歌如何缩小范围？如此之快的计算量是如何发生的？Google 基础设施的很大一部分是否用于每个查询来计算这些特征并并行预测相关性，或者他们是否以其他方式处理它？
请注意，虽然只能点击结果链接中的前 10-20 个，但 Google 仍然必须了解它们是整个库中的哪 10-20 个文档 - 这意味着所有文档都需要在某种程度上进行评估。
在用户方面：除上述之外，Google还会根据您之前的搜索历史/习惯定制结果。这是否意味着文档也具有基于每个用户的特征（例如您过去查看过的类似文档的数量）？或者Google是否使用聚类方法对其用户进行聚类，并为与您最相似的用户提供文档功能（例如，访问您访问过的网站的90％的用户都点击了此文档的链接）？
如果以上都不是，那么他们如何实现网络上如此多文档的搜索结果的定制？他们是如何在短短一秒内做到这一点的？
小智 3
从算法上考虑，字符串搜索速度很快。一般情况搜索是线性的，O(n)（“n 的 BigO”），但优化（例如 Boyer-Moore Horspool 算法）可以显着改进行为良好输入的典型字符串搜索。此外，搜索基本上可以并行化 - 如果您有 N 台计算机并且想要更快地搜索大型文档，只需将文档拆分为 N 个范围，然后让每台计算机搜索该范围即可。因此，搜索允许通过并行化实现线性加速。
当然，当您提交搜索查询时，网络搜索引擎无法进行字符串搜索 - 这样的搜索引擎会非常慢。关键是要认识到，没有必要在提交搜索查询时搜索文档，因为搜索的文档是静态的（网页通常不会经常更改）。此外，人们通常不会搜索“网页中的确切单词”，而是搜索在他们看来与某些搜索查询相关的互联网上的位置。因此，搜索引擎实际上是根据搜索查询返回网站位置。
Wiki在这里对搜索引擎的工作原理有很好的解释。爬网和索引是在“后台”完成的，因此不会影响搜索查询的服务速度。索引的目标是将爬行过程中收集到的信息整理成可以根据用户查询快速搜索的形式。
正如您所指出的，查询和文档都具有统计模式 - 可以利用任何类型的模式来加快搜索速度。雅虎最近开源了其名为Vespa 的搜索引擎。如果您想真正深入了解现代搜索引擎如何工作的细节，这将是一个很好的起点。请注意，Vespa 的高级架构实际上并不是关于搜索，而是关于在一组内容管理任务（其中之一是搜索）之间实现并行性。换句话说，快速网络搜索实际上是应用于通用内容管理的并行性的副产品。
排名是网络搜索成功的关键。用户希望查询与他们搜索的内容相关，而相关性基于排名。排名是在索引期间执行的，并且是内容、内容位置和用户反馈（点击率）的函数。正如您所指出的，尽管早期的系统（例如 Google 的PageRank）并非基于机器学习，但如今机器学习无疑已被用于此目的。
针对用户的搜索结果优化更为复杂。他们可能使用机器学习，但非机器学习算法可能同样快或更快。有两个考虑因素降低了复杂性。首先，特定于用户的偏好实际上只是默认排名系统的增量。在最坏的情况下（你不知道用户在问什么），你只需使用默认排名。由于这已经很快了，因此特定于用户的优化永远不会减慢搜索速度。其次，特定于用户的优化是模糊的——只要不是严重错误，优化就永远不会错。例如，假设一个重金属乐迷搜索“金属乐队”，并且您的搜索引擎自信地返回重金属乐队列表 - 但在这种情况下，他们确实碰巧在搜索用于运输的钢乐队。你的优化是错误的，但并没有错——只要你不是大错特错（例如，返回关于兔子的结果），犯错也没关系。对于此类模糊问题，有非常快速的经典算法（非机器学习）。
长话短说：