更多互联网精彩资讯、工作效率提升关注【飞鱼在浪屿】（日更新）

问软件工程师：“如何为产品添加搜索功能？可能会立即听到类似这样的话：“哦，我们刚刚启动了一个 ElasticSearch 集群。现在搜索很容易。” 但是是吗？许多现有的产品仍 具有 不理想的 搜索 体验。任何真正的搜索专家都会告诉您，很少有工程师对搜索引擎的工作原理有非常深入的了解，而这些知识通常是提高搜索质量所必需的。

❗ “严重” 问题：无知的后果可能是致命的 特别值得注意的想法或技术 ☁️️云/SaaS 开源/免费软件 JavaScript Python ☕ Java C/C++为什么要读这个？

一些最流行的方法、算法、技术和工具。❗️不重视或不了解搜索问题的范围和复杂性会导致糟糕的用户体验、浪费工程工作和失败产品。

搜索本质上是一个混乱的问题：

• 查询是高度可变的。搜索问题根据产品需求变化很大。
• Facebook 搜索人。YouTube 搜索单个视频。谷歌地图搜索地理空间数据。

• 没有灵丹妙药（如 PageRank），也没有神奇的排名公式可以作为一种好的方法。过程总是不断发展的技术和过程的集合。❗️换句话说，搜索不仅仅是构建对特定域进行排名或检索的软件。
• 搜索关键是建立评估和调整到产品和开发周期的过程。搜索系统架构师应该考虑流程和指标，而不仅仅是技术。

• 与大多数工程问题一样，不要自己重新发明轮子。请使用现有服务或开源工具。如果现有的 SaaS（例如Algolia或托管 Elasticsearch）负担得起，请使用它。

每个产品的搜索都不同，选择取决于需求的许多技术细节。关键参数：

1. 大小：语料库 （需要搜索的完整文档集）有多大？是数千份还是数十亿份文件？
2. 媒体：搜索文本、图像、图形关系还是地理空间数据？
3. C orpus 控制和质量：文件的来源是在自由数据源，还是来自第三方？是否所有文档都准备好进行索引或需要清理和选择？
4. 索引速度：需要实时索引，还是批量构建索引好？
5. 查询语言：查询是结构化的，还是需要支持非结构化的？
6. 查询结构：查询是文本、图像还是声音？街道地址、记录 ID、人脸？
7. 上下文相关性：结果是否取决于用户是谁、他们使用产品的历史、地理位置、一天中的时间等？
8. 建议支持：是否需要支持不完整的查询？
9. 延迟：服务延迟要求是什么？100 毫秒还是 100 秒？
10. 访问控制：它是完全公开的还是应该用户只能看到文档的一个受限子集？
11. 合规性：是否存在合规性或组织限制？
12. 国际化：是否需要支持多语言字符集或 Unicode 的文档？（提示：除非您真的知道自己在做什么，否则始终使用UTF-8。）您需要支持多语言语料库吗？多语言查询？

现在让我们来看看搜索子问题的列表。这些通常由管道的单独子系统解决。下一个子系统消耗先前子系统的输出，并为后续子系统产生输入。

这导致了生态系统的一个重要属性：一旦你改变了上游子系统的工作方式，你需要评估改变的影响，并可能改变下游的行为。以下是需要解决的最重要的问题：

给定一组文档（例如整个互联网、所有 Twitter 帖子、Instagram 上的所有图片），选择一个可能值得考虑作为搜索结果的可能较小的文档子集，并且只将那些包含在索引中，丢弃其余的部分。这样做是为了保持索引紧凑，并且几乎与选择要显示给用户的文档正交。未进行剪切的特定类别文档的示例可能包括：

• 垃圾邮件：很好的网络垃圾邮件分类概述。http://airweb.cse.lehigh.edu/2005/gyongyi.pdf

• 不需要的文件：域限制需要过滤：色情、非法内容等。这些技术类似于垃圾邮件过滤，可能有额外的启发式方法。

• 重复：接近重复和冗余的文件可以使用局部敏感的散列、相似性度量、聚类技术甚至点击数据来完成。

• 低效文件：效用的定义在很大程度上取决于问题域，因此很难推荐固定方法。一些想法是：可以为文档构建一个实用函数；启发式方法可能有效，或者例如仅包含黑色像素的图像不是有用的文档；效用可以从用户行为中学习。

对于大多数搜索系统，文档检索是倒排索引——简称为索引。

• 索引是搜索词到文档的映射。搜索词可以是一个词、一个图像特征或任何其他对查询到文档匹配有用的文档派生词。给定搜索词的文档列表称为发布列表。它可以按某些指标进行排序，例如文档质量。
• 是否需要实时索引数据。
• 对于文本文档，术语提取通常涉及使用 NLP 技术，例如停止列表、词干提取和实体提取；对于图像或视频，使用计算机视觉方法等。
• 此外，挖掘文档以获取统计和元信息，例如对其他文档的引用（用于著名的PageRank排名信号）、主题、术语出现次数、文档大小、提及的实体 A 等。这些信息可以稍后用于排序信号构建或文档聚类。一些较大的系统可能包含多个索引，例如用于不同类型的文档。
• 索引格式。索引的实际结构和布局可以通过多种方式进行优化。例如，发布列表压缩方法，可以用mmap() 数据表示或使用LSM 树来持续更新索引。

大多数流行的搜索系统允许非结构化查询。这意味着系统必须从查询本身中提取结构。在倒排索引的情况下，需要使用NLP技术提取搜索词。

提取的术语可用于检索相关文档。大多数查询都不是很好地的搜索词，因此进行额外的查询扩展和重写，例如：

• 期限重新加权。
• 拼写检查。历史查询日志作为字典非常有用。
• 同义词匹配。
• 命名实体识别。一个好的方法是使用基于 HMM 的语言建模。
• 查询分类。检测特定类型的查询。例如，Google 搜索会检测包含地理实体的查询、色情查询或有关新闻中某些内容的查询。然后，检索算法可以决定要查看哪些语料库或索引。
• 通过个性化或本地环境进行扩展。对诸如“我周围的加油站”之类的查询很有用。

给定文档列表、处理后的查询，为这些文档创建最佳排序（排名）。

最初，大多数排名模型都是手动调整所有文档的加权组合。包括 PageRank、点击数据、时事性信息等。许多这些信号（例如 PageRank 或由统计语言模型生成的信号）极大地影响参数。这些也必须手动调整。

获得排名，判别监督方法变得越来越流行。LtR 的一些流行示例是 Microsoft 的M cRank和 L ambdaRank，以及来自 Yandex 的M atrixNet。

一种新的基于向量空间的语义检索和排序方法最近越来越受欢迎。这个想法是学习单个低维向量文档表示，然后构建一个模型，将查询映射到相同的向量空间。

然后，检索只是找到几个最接近查询向量的度量（例如欧几里德距离）的文档。排名就是距离本身。如果文档和查询两种映射是建立好了，文件是由一些简单的模式（如文字）的存在的事实，选择不，但文件有多接近查询的意思。

通常，必须定期操作每个管道，以保持搜索索引和搜索体验的最新状态。

❗️操作搜索管道可能很复杂，并且涉及很多移动的部分。不仅数据在管道中移动，而且每个模块的代码以及数据中嵌入的格式和假设都会随着时间而改变。一些复杂的搜索引擎（如谷歌）有几层在不同时间尺度上运行的管道，经常变化的页面（如cnn.com）的索引频率高于多年未变化的静态页面.

最终，搜索系统的目标是接受查询，并使用索引返回适当排名的结果。

• 性能：用户会注意到他们与之交互的系统何时滞后。❗️Google 进行了广泛的研究，他们注意到，当服务速度降低 300 毫秒时，搜索数量下降了 0.6%。https://services.google.com/fh/files/blogs/google_delayexp.pdf。他们建议为大多数查询提供 200 毫秒以下的结果。关于该主题的好文章。http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it。这是困难的地方：系统需要从可能多台计算机中收集文档，而不是将它们合并成一个可能的很长的列表，然后按照排名顺序对该列表进行排序。更复杂的是，排名可能取决于查询，因此，在排序时，系统不仅仅是比较 2 个数字，而是执行计算。
• C aching结果：通常需要获得不错的性能。❗️但是缓存只是一个大问题。当索引更新或某些结果被列入黑名单时，可能会显示过时的结果。清除缓存本身就是一种蠕虫：搜索系统可能没有能力为整个查询流提供空（冷）缓存，因此需要在查询开始之前预热缓存。总的来说，缓存使系统的性能配置文件复杂化。选择缓存大小和替换算法也是一种挑战。
• 可用性：通常由正常运行时间/（正常运行时间 + 停机时间）指标定义。当索引分布时，为了服务于任何搜索结果，系统通常需要查询所有分片以获取它们的结果份额。❗️这意味着，如果一个分片不可用，则整个搜索系统都会受到损害。参与服务索引的机器越多——其中一台机器失效并导致整个系统瘫痪的可能性就越大。
• 管理多个索引：大型系统的索引可能分为碎片（片段）或按媒体类型或索引节奏（新鲜与长期索引）划分。然后可以合并结果。
• 合并不同类型的结果：例如 Google 显示来自地图、新闻等的结果。

接下来，需要围绕持续的搜索质量评估和改进构建一组流程。事实上，这实际上是必须解决的大部分工作和最困难的问题。什么是质量？首先，质量意味着：

• 自我报告的用户满意度（包括 UX）
• 返回结果的感知相关性（不包括 UX）
• 相对于竞争对手的满意度
• 上一版搜索引擎的满意度相对表现（例如上周）
• 用户参与

指标：其中一些概念很难量化。另一方面，能够用一个数字（质量指标）来表达搜索引擎的表现非常有用。

以下是一些量化质量的经典方法：

• 准确率 和召回率衡量检索到的文档集与期望看到的文档集的对应程度。
• F score（特别是F1 score）是一个单一的数字，它很好地代表了精度和召回率。
• 平均平均精度( MAP ) 允许量化最高返回结果的相关性。
• N标准化折扣累积增益(n DCG)类似于 MAP，但通过其位置对结果的相关性进行加权。
• 长短点击——允许量化结果对真实用户的有用程度。
• 一个很好的详细概述。

人工评估：质量指标可能看起来像统计计算，但它们不能全部通过自动计算来完成。最终，指标需要代表主观的人工评估。

❗️跳过人工评估可能是低于标准的搜索体验传播最广的原因。通常，在早期阶段，开发人员自己手动评估结果。稍后，人类评估者（或评估者）可能会参与其中。评分者通常使用自定义工具查看返回的搜索结果并提供有关结果质量的反馈。

随后，使用反馈信号来指导开发，帮助做出发布决策，甚至将它们反馈到索引选择、检索或排名系统中。以下是一些其他类型的人工评估的列表，可以在搜索系统上完成：

• 基本用户评价：用户对整体体验的满意度排名
• 对比评价：与其他搜索结果进行比较（与系统早期版本或竞争对手的搜索结果进行比较）
• 检索评估：查询分析和检索质量通常使用手动构建的查询文档集进行评估。向用户显示查询和检索到的文档列表。然后，标记与查询相关的所有文档以及不相关的文档。结果对 (query, [relevant docs]) 被称为“黄金集”。一方面，工程师可以使用这些集合设置自动检索回归测试。来自黄金集合的选择信号也可以作为地面实况反馈给术语重新加权和其他查询重写模型。
• 排名评估：评估者会看到一个查询和两个并排的文档。评估者必须选择更适合查询的文档。这会为给定查询的文档创建部分排序。该排序稍后可以与排名系统的输出进行比较。通常使用的排名质量度量是 MAP 和 nDCG。

搜索引擎获得足够多的用户后，可能希望开始对部分流量进行实时搜索实验。基本思想是为一组人开启一些优化，然后将结果与“控制”组的结果进行比较 - 一个类似的用户样本，没有为他们打开实验功能。您将如何衡量结果再次与产品相关：可能是点击结果、点击广告等。 评估周期时间：提高搜索质量的速度与完成上述周期的速度直接相关测量和改进。否需要几天、几小时、几分钟或几秒钟来进行更改并查看它们是否会提高质量？❗️对于工程师来说，运行评估也应该尽可能简单，不应该花费太多的动手时间。

1. 如果负担得起 - 只需购买现有的 SaaS（下面列出了一些好的）。现有服务适用于：

• 服务或应用程序有互联网连接。
• 它是否支持开箱即用的所有功能？至少要考虑：支持搜索媒体；实时索引支持；查询灵活性，包括上下文相关查询。
• 考虑到语料库的大小和预期的QpS，能负担得起未来 12 个月的费用吗？
• 该服务能否在所需的延迟限制内支持预期流量？如果从应用程序查询服务，请确保可以从用户所在的位置足够快地访问给定的服务。

2. 如果SaaS托管解决方案不适合，你可能希望使用开源库或工具之一。如果是连接的应用程序或网站，我会选择 ElasticSearch。对于嵌入式体验，下面有多种工具。

3. 你很可能希望在将文档上传到搜索索引之前进行索引选择并清理文档（例如从 HTML 页面中提取相关文本）。这将减小索引大小并使获得好的结果更容易。如果您的语料库适合一台机器，只需编写一个（或多个）脚本即可。如果没有，我会使用Spark。

☁️ A lgolia — 一种SaaS，可索引客户网站并提供 API 来搜索网站页面。他们提供 API 来提交您自己的文档，支持上下文相关搜索并非常快速地提供结果。如果我现在正在构建网络搜索体验并且负担得起，我可能会先使用 Algolia——然后为自己争取时间来构建类似的搜索体验。https://www.algolia.com/

• 各种 ElasticSearch 提供商：AWS (☁️ ElasticSearch Cloud )https://aws.amazon.com/cn/opensearch-service/，☁️ elastic.co，https://www.elastic.co/cn/，和来自 ☁️ Qbox。https://qbox.io/
• ☁️ Azure 搜索— 来自 Microsoft 的 SaaS 解决方案。可通过 REST API 访问，它可以扩展到数十亿个文档。有一个 Lucene 查询接口来简化从基于 Lucene 的解决方案的迁移。https://azure.microsoft.com/en-us/services/search/
• ☁️ Swiftype — 一种企业 SaaS，可为公司的内部服务（如 Salesforce、G Suite、Dropbox 和内部网站）编制索引。https://swiftype.com/

☕ L u cene是最受欢迎的 IR 库。实现查询分析、索引检索和排序。这两个组件中的任何一个都可以被替代实现替换。还有一个C口——Luc y。

• ☕Solr is是个基于Lucene的搜索服务器。它是 Ha doop e工具协同系统的一部分。
• ☕ H adoop是使用最广泛的开源 MapReduce 系统，最初是作为 Solr 的索引管道框架而设计的。作为用于索引的批处理数据处理框架，它已经逐渐被 Spa rk取代。☁️EMR是MapReduce 在 AWS 上的实现。
• ☕ El asticSearch同样基于 Lucene。和Hadoop和Sacal有很好的API支持。https://github.com/elastic/elasticsearch-hadoop。有开源版和企业版。ES在SaaS可以扩展到数十亿个文档。但扩展到十亿可能非常具有挑战性，典型场景将是数量级较小的语料库。
• Xa pian —基于 C++ 的 IR 库。非常适合嵌入式或移动应用程序。https://xapian.org/
• Sp hinx —全文搜索服务器。具有类似 SQL 的查询语言。也可以作为MySQL 的存储引擎或用作库。http://sphinxsearch.com/
• ☕ N utch — 网络爬虫。可以与 Solr 结合使用。它也是 Common Crawl背后的工具。https://nutch.apache.org/
• Lu nr — 一个用于客户端 Web 应用程序的紧凑型嵌入式搜索库。https://lunrjs.com/
• se archkit —与 ElasticSearch 一起使用的 Web UI 组件库。https://github.com/searchkit/searchkit
• No rch — Node.js 的 Le velDB-b ased搜索引擎库。https://github.com/fergiemcdowall/norch
• Wh oosh —一个用纯 Python 实现的快速、全功能的搜索库。
• OpenStreetMaps 有自己的deck搜索软件。

用数据集来尝试构建搜索引擎或评估搜索引擎质量：

• mmoncrawl -一个定期更新的开放网路检索资料。AWS 上有一个镜像，可在服务内免费访问。http://commoncrawl.org/
• Open enstreetmap data dump对于构建地理空间搜索引擎的人来说，这是一个非常丰富的数据来源。
• G oogle Books N-grams对于构建语言模型非常有用。http://commondatastorage.googleapis.com/books/syntactic-ngrams/index.html
• 维基百科转储是构建实体图的经典来源。有很多可用的辅助工具。https://dumps.wikimedia.org/
• IMDb dumps是一个有趣的数据集，可以为其构建一个小型玩具搜索引擎。https://www.imdb.com/interfaces/