AI 驱动的搜索：1 介绍 AI 驱动的搜索

本章涵盖

对 AI 驱动的搜索的需求
用户意图的维度
构建 AI 驱动的搜索的基础技术
AI 驱动的搜索的工作原理

搜索框已迅速成为大多数现代应用程序中与数据交互的默认用户界面。如果您想到每天访问的每个主要应用程序或网站，那么每次访问时可能要做的第一件事就是键入或说出查询，以便找到当时与您最相关的内容或操作。

即使在未显式搜索的情况下，也可能使用针对特定品味和兴趣自定义的内容流。无论是视频推荐、购买项目、按优先级或新近度排序的电子邮件、新闻文章还是其他内容，您都可能仍在查看过滤或排名结果，并可以选择使用您自己的查询浏览或显式过滤内容。

虽然“搜索引擎”这个词对大多数人来说让人想到像谷歌、百度或必应这样的网站，它可以基于整个公共互联网的抓取进行查询，但现实情况是，搜索现在无处不在——它是一种工具，存在于我们每天使用的众多网站和应用程序中的几乎所有数字互动中。

此外，虽然不久前搜索框的预期响应可能只是返回“十个蓝色链接”——供用户调查以查找更多信息以响应其查询的排名文档列表——但近年来，对搜索技术智能水平的期望飙升。

今天的搜索功能预计将是：

域感知：了解每个特定用例和文档语料库的实体、术语、类别和属性，而不仅仅是对文本字符串利用通用统计。
上下文和个性化：能够获取用户上下文（位置，上次搜索，配置文件，以前的交互，用户推荐和用户分类），查询上下文（其他关键字，类似搜索）和域上下文（库存，业务规则，特定于域的术语），以便更好地理解用户意图。
对话式：能够以自然语言进行交互，并指导用户完成多步骤发现过程，同时学习和记住相关的新信息。
多模式：能够解决文本查询、语音查询、使用图像或视频进行搜索，甚至监控事件并发送基于事件的推送通知。
智能：能够提前提供预测输入，了解用户的意思（拼写更正、短语和属性检测、意图分类、概念搜索等），从而在正确的时间提供正确的答案并不断变得更智能。
辅助：超越仅仅提供链接，提供答案和可用操作。

人工智能搜索的目标是利用自动化学习技术来实现这些所需的功能。虽然许多组织从基本文本搜索开始，并花费多年时间尝试手动优化同义词列表、业务规则、本体、字段权重以及搜索配置的无数其他方面，但有些组织开始意识到此过程的大部分实际上可以自动化。

本书是一个示例驱动的指南，介绍了通常用于构建智能搜索系统的最适用的机器学习算法和技术。我们不仅将介绍关键概念，还将提供可重用的代码示例，以涵盖数据收集和处理技术，以及用于在当今领先组织中提供人工智能驱动的搜索功能的自学查询解释和相关性策略 - 希望很快包括您自己的！

1.1 搜索用户意图

为了提供 AI 驱动的搜索，我们必须预先建立对解释用户意图并随后返回与该意图匹配的内容所涉及的许多维度的有凝聚力的理解。在信息检索领域，搜索引擎和推荐引擎是两种最流行的技术，用于尝试为用户提供满足其信息需求所需的内容。许多组织认为搜索引擎和推荐引擎是解决不同用例的独立技术，事实上，同一组织内的不同团队（通常具有不同的技能）经常在不同的搜索引擎和推荐引擎上独立工作。在本节中，我们将深入探讨为什么将搜索和建议分离到单独的孤岛（独立的职能和团队）中通常会导致不太理想的结果。

1.1.1 搜索引擎

搜索引擎通常被认为是一种用于明确输入查询和接收响应的技术。它通常通过某种文本框向最终用户公开，用户可以在其中输入关键字或完整的自然语言问题，并且结果通常与允许进一步优化初始查询的其他过滤选项一起以列表中返回。使用此机制，搜索被用作定向发现相关内容的工具。但是，每当用户完成其搜索会话时，他们通常可以发出新查询并从空白开始，从而擦除上一个搜索中的任何上下文。

图 1.1.典型的搜索体验，用户输入查询并查看带有筛选选项的搜索结果，以支持进一步细化搜索结果

在软件工程领域，搜索引擎是现存最具跨功能的系统之一。大多数底层搜索引擎技术旨在以可大规模扩展的方式运行 - 扩展到数百万、数十亿或在特定情况下数万亿个文档，处理大量并发查询，并在数百毫秒或更短的时间内提供搜索结果。在许多情况下，还需要对新摄取的数据进行实时处理和近乎实时的搜索，所有这些都必须在众多服务器上大规模并行化，以便横向扩展以满足如此高的性能要求。

毋庸置疑，设计上述系统需要强大的后端开发人员，他们对分布式系统、并发性、数据结构、操作系统和高性能计算有深入的了解。

搜索引擎还需要大量工作来构建搜索特定的数据结构，如倒排索引、对线性代数和向量相似性评分的理解、文本分析和自然语言处理方面的经验，以及了解众多特定于搜索的数据模型和功能（拼写检查、自动建议、分面、文本突出显示等）。

此外，随着相关性变得越来越重要，搜索团队经常雇用相关性工程师，他们生活在公司的领域，并且从排名模型、A/B 测试、点击模型、特征工程以及查询解释和意图发现方面进行思考。

当然，有产品经理推动需求，数据分析师评估搜索质量和改进，DevOps工程师运行和扩展搜索平台，以及围绕生产搜索引擎实施的许多其他支持角色。

很难找到具有多种这些技能的人，更不用说所有这些技能了，这使得搜索成为一门高度跨职能的学科。但是，为了使搜索引擎能够完全解释用户意图，能够结合对您的内容，用户和域的透彻理解至关重要。在简要讨论推荐引擎的相关主题后，我们将重新审视为什么这很重要。

1.1.2 推荐引擎

虽然搜索引擎传统上被认为是需要明确的用户驱动查询的技术，但相比之下，大多数人认为推荐引擎是不接受用户输入的系统，并且只根据对用户的了解向用户推送内容，并认为最符合他们计算的兴趣。正如我们将在 1.1.3 节中看到的那样，这两者都过于简单化，但它们仍然是搜索引擎和推荐引擎通常被区分的流行方式。如果您经常访问 Amazon.com 或任何其他主要电子商务网站，那么您无疑熟悉推荐引擎部分，指出“基于您对这个项目的兴趣，您可能也喜欢......”或者只是根据您的集体浏览和购买历史记录推荐项目列表，类似于图 1.2。这些建议通常会为公司带来可观的收入，并帮助客户发现相关、个性化和相关的内容，这些内容通常与他们明确寻找的内容相辅相成。

图 1.2.基于对类似商品感兴趣的用户的购买模式的建议

推荐引擎，通常也称为推荐系统，有多种形状和大小。他们采用可以接受输入（用户偏好、用户行为、内容等）的算法，并利用这些输入自动匹配最相关的内容。推荐算法大致可以分为三类：基于内容的推荐器、基于行为的推荐器和多模式推荐器。

基于内容的推荐器

这些算法根据不同实体之间共享的属性（通常在用户和项目之间、项目和项目之间或用户和用户之间）共享的属性推荐新内容。例如，想象一个求职网站。工作可能具有“职位”、“行业”、“薪资范围”、“经验年限”和“技能”等属性，用户在其个人资料或简历/简历上也将具有类似的属性。基于此，基于内容的推荐算法可以确定哪些功能最重要，然后可以根据该工作与用户所需属性的匹配程度对任何给定用户的最佳匹配工作进行排名。这就是所谓的用户项目（或“用户到项目”）推荐器。

同样，如果用户喜欢特定作业，则可以利用相同的过程根据这些作业与已知良好的第一个作业的属性匹配程度来推荐类似的其他作业。这种类型的推荐在产品详细信息页面上很受欢迎，用户已经在查看项目，可能需要帮助他们探索其他相关项目。这种推荐算法称为项目-项目（或“项目到项目”）推荐器。

图 1.3 演示了基于内容的推荐器如何利用用户以前与之交互的项目的属性来匹配该用户的类似项目。在这种情况下，我们的用户查看了“洗涤剂”产品，然后推荐算法根据它们在同一类别字段（“洗衣”类别）中的匹配并在其产品描述中包含与“洗涤剂”产品相似的文本来建议“织物柔软剂”和“烘干床单”产品。

图 1.3.基于内容的推荐，基于用户感兴趣的项目的匹配属性，例如类别和文本关键字。

也可以将用户与其他用户匹配，或者将任何实体与任何其他实体进行匹配。在基于内容的推荐器的上下文中，所有推荐都可以被视为“项-项”建议，其中每个项只是一个任意实体，与被推荐的其他实体共享属性。

基于行为的推荐器

这些算法利用用户与项目（文档）的交互来发现项目组之间的相似兴趣模式。此过程称为协作筛选，指的是使用多人（协作）投票过程将匹配项筛选为具有最高相似性的匹配项，通过与相同项目交互的重叠用户数来衡量。这里的直觉是，相似的用户（即具有相似偏好的用户）倾向于与相同的项目进行交互，并且当用户与多个项目交互时，他们更有可能寻找并与类似的项目进行交互，而不是不相关的项目。

协同过滤算法的一个惊人特征是，它们将相关性评分过程完全众包给最终用户。事实上，不需要项目本身的功能（名称、品牌、颜色、文本等） - 所需要的只是每个项目的唯一 ID，以及哪些用户与哪些项目交互的知识。此外，您拥有的用户和交互（称为“行为信号”或“信号”）越多，这些算法往往就越智能，因为您有更多的人不断投票并告知您的评分算法。这通常会导致协同过滤算法明显优于基于内容的算法。

图 1.4 演示了如何使用多个用户之间的重叠行为信号来推动协作建议

图 1.4.基于协同过滤的建议，协同过滤是一种利用多个用户行为信号之间重叠的技术。

不幸的是，对用户行为信号的依赖使协作过滤如此强大，也被证明是他们的致命弱点。当与特定项目只有几次交互（或者可能根本没有交互）时会发生什么？答案是，该项目要么永远不会被推荐（当没有信号时），要么可能会产生糟糕的推荐或显示为其他项目的不匹配（当信号很少时）。这种情况被称为冷启动问题，对于基于行为的推荐者来说是一个主要挑战。

多模态推荐器

有时，你也可以吃你的蛋糕。多模态推荐器就是这种情况，它试图结合基于内容和基于行为的推荐器方法的优点。由于协同过滤往往最适合具有许多信号的项目，但在存在信号很少或没有信号时效果不佳，因此最有效的方法是使用基于内容的特征作为基线，然后基于行为信号在顶部分层模型。这样，如果存在很少的信号，则基于内容的匹配器仍将返回结果，而如果存在许多信号，则协同过滤匹配将更加突出。我们将在第 6 章中介绍组合方法的方法，但很容易推断出，包括两种方法的一些结果可以为您提供两全其美的结果：高质量的众包匹配，同时避免更新和不太知名的内容的冷启动问题。图 1.5 展示了这在实践中是如何工作的。

图 1.5.多模式推荐，将基于内容的匹配和协同过滤结合到混合匹配算法中

您可以在图 1.5 中看到，用户可以与钻头（没有信号，因此只能通过基于内容的匹配器在推荐中使用）或螺丝刀（具有来自其他用户的先前信号以及内容）进行交互，并且在这两种情况下，用户都会收到建议。这提供了可以使用基于信号的协同过滤的好处，同时还可以为当前可用信号不足的项目启用基于内容的匹配，例如本示例中的演练。与仅利用基于内容或基于行为的推荐相比，这种多模式推荐算法提供了显着的灵活性和优势。

1.1.3 信息检索连续体

我们刚刚讨论了两种不同类型的信息检索系统：搜索引擎和推荐引擎。两者之间的关键区别在于，搜索引擎通常由用户引导并匹配他们明确输入的查询，而推荐引擎通常不接受直接的用户输入，而是根据已知或推断的知识推荐用户接下来可能想要看到的内容。

然而，现实情况是，这两种系统实际上只是同一枚硬币的两面。在这两种情况下，目标都是了解用户正在寻找什么，并提供相关结果以满足用户的信息需求。在本节中，我们将讨论搜索和推荐系统之间的信息检索连续体中的各种功能。

个性化搜索

让我们想象一下运行一个餐厅搜索引擎。我们的用户米歇尔（Michelle）在纽约午餐时间使用手机，她输入关键字搜索“蒸百吉饼”。她在格林维尔、南卡罗来纳州（美国）、哥伦布、俄亥俄州（美国）和伦敦（英国）看到了顶级的蒸百吉饼店。

这些搜索结果有什么问题？好吧，在这种情况下，答案相当明显——米歇尔在纽约寻找午餐，但搜索引擎正在数百到数千英里之外显示她的结果。但米歇尔从未告诉搜索引擎她只想在纽约看到结果，也没有告诉搜索引擎她正在附近寻找午餐地点，因为她现在想吃饭......

考虑另一种情况 - 米歇尔在长途飞行后在机场，她在手机上搜索“司机”。返回的最高结果是高尔夫球杆从发球台上击球，然后是打印机驱动程序的链接，然后是螺丝刀。如果搜索引擎知道米歇尔的位置，它不应该能够推断出她的意图吗？

使用我们前面的求职示例，让我们假设米歇尔去她最喜欢的求职搜索引擎并输入“护理工作”。与我们前面的餐厅示例类似，如果纽约的护理工作出现在列表的顶部，这不是很理想吗？如果她后来输入“西雅图的工作”怎么办？如果不是在西雅图看到随机工作（医生、工程师、厨师等），那不是很理想吗？— 护理工作现在出现在列表的顶部，因为引擎之前知道她是一名护士？

以上每个都是个性化搜索的示例 - 将显式用户输入和对每个用户的特定意图和偏好的隐式理解组合到一个查询中，该查询可以返回一组专门针对该用户的结果。做好这一点是一个棘手的主题，因为您必须仔细平衡利用您对用户的理解，而不会覆盖他们明确想要查询的任何内容。我们将在第9章后面深入探讨如何优雅地平衡这些问题。

用户指导型建议

正如可以在搜索中加入隐式和特定于用户的属性以生成个性化搜索一样，也可以启用用户引导的建议。

推荐引擎允许用户查看和编辑其推荐首选项变得越来越普遍。这些首选项通常包括用户以前与之交互过的项目列表，例如电影推荐引擎的观看电影和评级，或者电子商务网站以前查看或购买的项目列表。在广泛的用例中，这些偏好还可能包括服装尺码、品牌亲和力、最喜欢的颜色、首选的本地商店、最喜欢的菜单项、所需的职位和技能、首选的工资范围等。从本质上讲，这些推荐首选项构成了用户配置文件 - 它们定义了有关客户的已知内容，并且您可以为用户提供查看，调整和改进此配置文件的控制权越多，您就越能更好地了解您的用户，他们可能会越快乐。

搜索与推荐：错误的二分法

我们已经看到，在尝试为最终用户查找内容时，个性化配置文件信息可以忽略（传统关键字搜索）、隐式与其他显式用户输入一起使用（个性化搜索）、显式使用用户调整功能（用户引导的建议），或者显式使用而不允许用户调整（传统建议）。图 1.6 显示了这种个性化范围。

图 1.6.个性化范围，将传统关键字搜索和传统推荐简单地显示为更大连续体的两端

虽然这种个性化范围的两端（传统的关键字搜索和传统的推荐）代表了极端，但它们也是最常见的两个。不幸的是，我在许多组织中看到的最大错误之一是围绕搜索和推荐是独立问题的信念建立团队和组织。这通常会导致数据科学团队构建复杂的个性化和细分模型，这些模型只能推荐内容，根本无法进行搜索，并且工程团队构建大规模关键字匹配引擎，无法轻松利用推荐团队构建的强大个性化模型。通常情况下，推荐团队由具有最少信息检索背景的数据科学家组成，而搜索团队通常由具有最低数据科学背景的工程师组成。由于康威定律（“设计系统的组织......被限制为生产设计，这些设计是这些组织的沟通结构的副本“），这最终导致解决这种个性化范围内（特别是在中间）的问题的挑战，这些问题需要两个团队都做到最好。在这种情况下，搜索和推荐引擎通常会自然演变成单独的系统，这些系统无法在整个个性化范围内轻松最大化相关性需求。在本书中，我们将重点介绍通过统一方法使搜索变得更加智能并使建议变得更加灵活的共享技术，因为人工智能驱动的搜索平台需要能够不断从您的用户和您的内容中学习，并使您的用户能够这样做。

1.1.4 语义搜索与知识图谱

虽然我们在图 1.6 中将搜索和推荐呈现为个性化范围，但个性化搜索和用户引导的推荐介于两者之间，但还有一个维度对于构建良好的 AI 驱动的搜索系统至关重要——对给定领域的深刻理解。仅仅匹配关键字并根据用户与不同文档的集体交互方式推荐内容是不够的。要构建一个真正智能的搜索系统，引擎必须尽可能多地了解域名。这包括学习所有重要的特定于领域的短语、同义词和相关术语，以及识别文档和查询中的实体，生成与这些实体相关的知识图谱，消除特定领域术语所表示的许多细微含义的歧义，并最终能够有效地解析、解释和概念上匹配域内用户的细微意图。图 1.7 显示了查询的语义解析示例，目标是搜索“事物”（已知实体）而不是“字符串”（只是文本匹配）。

图 1.7.查询的语义解析，演示对查询词表示的实体（“事物”）的理解

许多公司花费了大量资金来建立大型团队来手动创建字典和知识图谱，试图了解用户查询中实体之间的关系，从而使他们的搜索更加智能。然而，本书将侧重于一种更具可扩展性的方法 - 构建一个人工智能驱动的搜索引擎，可以连续自动学习上述所有内容。我们将在第 5、6 和 7 章中进一步介绍语义搜索时，深入探讨自动生成这种特定于领域的智能的主题。我们还将在第13章和第14章中深入探讨其他新兴的概念搜索技术，例如密集向量搜索和神经搜索。

1.1.5 理解用户意图的维度

我们已经讨论了传统关键字搜索、推荐以及介于两者之间的个性化范围的重要作用。我们还讨论了语义搜索（利用知识图谱）的必要性，以便能够为您的内容和用户的查询提供特定于领域的理解。然而，所有这些都是一个单一的、更大的目标的关键支柱：充分理解用户的意图。图 1.8 提供了一个全面的模型，展示了用户意图的每个关键支柱之间的相互作用。

图 1.8.用户意图的维度，内容理解、用户理解和领域理解的组合

图 1.8 中左上角的圆圈表示“内容理解”，即利用关键字和属性匹配查找任意内容的能力。右上角的圆圈代表“用户理解”——理解每个用户的特定偏好并利用这些偏好返回更个性化的结果的能力。最后，下面的圆圈代表“领域理解”——在您自己的领域特定上下文中解释单词、短语、概念、实体以及细微解释和它们之间的关系的能力。

仅在“内容理解”圈子中的查询代表传统的关键字搜索，支持关键字匹配，但不利用任何特定于域或用户的上下文。仅在“用户理解”圈中的查询将从协作过滤中生成建议，用户无法覆盖输入，也无法理解域或基础文档的内容。仅在“域理解”存储桶中的查询可能是仅针对已知标记、类别或实体的结构化查询，甚至是类似浏览的界面，该界面允许探索这些特定于域的实体及其关系的知识图谱，但没有任何用户特定的个性化或查找任意术语、短语和内容的能力。

当传统的关键字搜索和推荐重叠时，我们会获得个性化搜索或引导式推荐（如前所述）。当传统的关键字搜索和知识图谱重叠时，我们会得到语义搜索（前面在第 1.1.3 节中也讨论过）：一种智能的、特定于领域的搜索体验。最后，当推荐和知识图谱重叠时，我们会得到更智能的多模态推荐，这些推荐不仅与用户在类似文档中的众包交互相匹配，而且还与对这些文档的重要属性的特定领域理解相匹配。

然而，人工智能搜索的圣杯是利用所有三个类别的交叉点：个性化搜索、语义搜索和多模式推荐。也就是说，为了真正理解用户意图，我们需要对用户正在搜索的领域有专家的理解，对用户及其偏好有专家的理解，需要对任何内容进行任意查询匹配和排名的专家能力。AI 驱动的搜索从用户意图的三大支柱（内容、领域和用户）开始，然后利用智能算法在这些领域不断自动学习和改进。这包括自动学习排名标准（见第10-11章）、自动学习用户偏好（见第9章）和自动学习所表示领域的知识图谱（见第5-6章）等技术。归根结底，这些方法中的每一种组合 - 并适当地平衡它们 - 为最佳理解用户及其查询意图提供了关键，这是我们人工智能驱动的搜索系统的最终目标。

1.2 人工智能搜索的关键技术

本书是读者将他们的搜索应用程序提升到一个新的水平并构建高度相关的自学搜索系统的指南。然而，为了达到“下一个层次”，这假设读者已经有经验或已经熟悉传统关键字搜索引擎和现代数据处理平台背后的关键概念。

虽然本书中的技术广泛适用于大多数开源和商业搜索引擎，但我们选择在本书中的示例中采用以下关键技术：

编程语言：蟒蛇
数据处理框架：Spark（PySpark）
交付机制：码头工人容器
代码设置和演练：Jupyter 笔记本
搜索引擎： Apache Solr

在本节中，我们将介绍这些技术，以及除了Apache Solr之外的以下其他搜索引擎，它们也可能是应用本书中介绍的技术的不错选择：Lucene，Elasticsearch，Open Search，Lucidworks Fusion，Milvus和Vespa。

1.2.1 编程语言：Python

选择Python作为本书的编程语言有几个原因。首先，鉴于本书针对的是软件工程师和数据科学家，我们需要选择一种在这两个职业中流行且广泛使用的语言。由于Python是迄今为止数据科学家中最常用的编程语言，并且是软件工程中最常用的三大编程语言（仅次于C和Java），因此Python是这里的明显领跑者。

此外，许多适用于我们将在本书中解决的问题的最突出的数据科学框架都是用python编写的或包含python绑定，使其成为一个务实的选择。

最后，对于那些没有经验的人来说，Python 是最易读和平易近人的编程语言之一，即使是那些没有经验的人，这也是教授概念的绝佳选择。

1.2.2 数据处理框架：Spark（PySpark）

Apache Spark是当今大规模数据处理的首选技术之一。它可以在单个服务器上轻松运行，也可以扩展到大型集群以进行生产分布式数据处理作业。由于搜索引擎经常处理大量数据，特别是人工智能驱动的搜索技术通常比你能提供的最多数据效果更好，我们希望展示可以根据需要轻松扩展的实现，这些实现建立在Apache Spark上提供。

此外，由于我们希望读者使用许多不同的搜索引擎和其他技术，通过演示使用与任何特定搜索引擎无关的技术进行数据处理，这样可以最大程度地重用您将在本书中学到的技术。Spark 使用数据帧的通用思想，它可以从任意数据源中提取数据，处理数据，然后保存回任何数据源。这意味着即使是HDFS也可以根据需要更换为更快的数据平台。例如，Apache Solr和Elasticsearch都可以用作Spark作业的数据源和数据目标，使Spark能够直接在搜索平台上运行，以处理和增强搜索数据（内容增强，用户行为分析，机器学习模型生成等），并在适当的时候利用利用搜索索引的速度。

1.2.3 交付机制：Docker容器

AI 驱动的搜索包含数百个库和依赖项，在新计算机上或跨不同操作系统无缝设置它们可能是一项非常耗时且容易出错的任务。因此，我们选择将本书的所有代码作为 Docker 文件和 Docker 容器发布。Docker 是一个平台，用于运行具有所需的所有操作系统配置和依赖项的虚拟机映像，使您能够启动并运行，无需特殊配置，也无需发生版本或操作系统冲突。

1.2.4 代码设置和演练：Jupyter 笔记本

我们希望您尽可能轻松地运行和试验本书中的代码示例。Jupyter 笔记本允许将所有代码作为演练教程提供，您可以在其中查看代码示例、更改代码，只需在 Web 浏览器中单击“运行”即可查看正在运行和正在运行的代码。

这些笔记本的设计都使您可以根据需要多次运行它们并获得相同的结果，使您能够专注于阅读和理解每一章，并遵循并运行所有相应的代码，而不必担心配置管理或运行系统级命令来运行代码。

1.2.5 选择合适的搜索引擎技术

尽管本书是提供人工智能搜索的实用指南，无论底层搜索引擎如何，但不幸的是，针对每种可用的搜索引擎技术创建重复的代码示例是不切实际的。因此，我们选择将本书的代码示例基于开源的Apache Solr搜索引擎。

在Python或Apache Spark中实现的大多数数据处理和机器学习代码几乎可以针对任何搜索引擎，只需进行微小的配置更改，并且大多数直接的搜索引擎交互（例如查询）可以通过使用略有不同的引擎特定配置和查询语法来实现。

关于特定于搜索的功能，实现本书中技术所需的绝大多数功能存在于大多数主要的参考搜索引擎中。也就是说，本书所需的一些功能仅在Solr中可用 - 例如Solr用于实体提取的文本标记器，Solr的语义知识图功能，Solr的查询时间图遍历，以及Solr的一些排名和查询解析器功能，因此其他引擎的用户在尝试实现这些功能时可能会有一些额外的工作。

由于 Elasticsearch 和 Solr 分别排名第一和排名第二的全文搜索引擎，Elasticsearch 自 2021 年起不再开源，并且 Elasticsearch 缺少实现本书中技术所需的一些关键功能，因此选择使用 Solr 是一个明确的选择。Solr基于Apache Lucene，它是为Elasticsearch（非开源）和OpenSearch（一个即将到来的分支或开源的Elasticsearch）提供支持的底层搜索引擎库。由于我们预计绝大多数读者会使用基于 Lucene 的搜索引擎（Elasticsearch、Solr、OpenSearch 或直接使用 Lucene），因为它们在市场上占据主导地位，因此我们选择了最受欢迎的开源搜索引擎，并期望这些概念能够很好地映射到使用这些引擎中的任何一个的从业者。

无论您是为您的人工智能搜索应用程序选择上述搜索引擎之一，还是已经拥有自己的引擎并且只是希望增强它，或者可能希望尝试新的和尖端的东西，很高兴知道您的选择。接下来的部分将提供每个引擎的高级摘要，以及您可能还需要考虑的其他一些引擎，具体取决于您的用例。

Apache Lucene：支持Apache Solr，Elasticsearch和OpenSearch的核心搜索库

Apache Lucene是一个开源的Java框架，用于构建丰富的搜索应用程序。Lucene 不提供搜索“引擎”，而是提供了广泛的 Java 库，您可以将这些库集成到您自己的软件中，以构建倒排索引、执行文本分析和标记化、将数据转换为用于搜索的高效数据类型，并管理执行大多数搜索操作（查询解析、分面、索引更新和段合并、索引和查询等）。

Lucene在内部使用的搜索应用程序比当今任何其他搜索技术都多，但通常不直接使用。也就是说，虽然Lucene是一个搜索库，但其他软件项目已经在Lucene之上发展，以公开功能齐全的搜索服务器，这些服务器可以作为可扩展的分布式系统跨大型计算集群运行（相比之下，Lucene仅在每个节点上本地运行）。这些搜索服务器公开 API（REST 和其他协议）以及开箱即用的客户端库。虽然有些人仍然直接在Lucene之上构建应用程序，但大多数组织已经转向使用在Lucene之上构建的流行的生产就绪搜索服务器之一，例如Apache Solr，Elasticsearch或OpenSearch。

Apache Solr：开源、社区驱动、以相关性为中心的搜索引擎

Solr是开源的，实际上是Apache Lucene项目的一部分，直到2021年成为Apache软件基金会自己的顶级项目。

虽然我们不会在本书中深入探讨Solr的所有功能（Solr in Action花了638页，这是在2014年写的！），但足以说Solr支持世界上许多最先进的搜索应用程序，并且它功能非常丰富，非常适合构建AI驱动的搜索应用程序。

它的受欢迎程度仅次于Elasticsearch，但Solr历来更多地用于信息检索和对日志和数据分析（Elasticsearch的核心重点）用例进行排名，为Solr提供了一些独特的相关性功能，我们将在整个旅程中使用这些功能。

在数据处理方面，Solr还维护了一个流表达式框架，该框架在许多方面可与Sparks分布式处理能力相媲美。虽然我们可以在示例中利用此框架来减少依赖关系，但我们将选择将 Spark 用于大多数离线数据处理和机器学习任务，以使我们的示例更普遍地适用于不同的搜索平台。这将使所有示例在所有其他引擎中轻松重用。

最终，我们在本书中的目标是教你可重用的技术，无论你的底层搜索技术如何，你都可以应用这些技术，因此在可能的情况下利用开源Solr来满足搜索特定需求和与引擎无关的技术将帮助我们最好地实现与引擎无关的目标。

Elasticsearch：最常用的、以分析为重点的全文搜索引擎

Elasticsearch是当今开发人员下载次数最多，最知名的搜索引擎技术，除了Apache Lucene，它在内部支持Solr，Elasticsearch和OpenSearch。

由于 Elasticsearch 的受欢迎程度和思想份额以及相对易用性，它通常是新开发人员开始使用搜索的首选搜索应用程序。

随着时间的推移，Elasticsearch在部署数量和整体开发人员份额方面已经超过了Solr，这主要是由于ELK堆栈（Elasticsearch + Logstash + Kibana）的普及，它已成为摄取，搜索和分析日志数据的行业标准。虽然日志和事件搜索是Elasticsearch的主要用例，但它也是一个非常强大的文本搜索引擎，为传统搜索用例提供了与Solr的高度功能对等（以及Solr中不可用的一些附加功能）。

不幸的是，Elasticsearch 不再是开源的（截至 2021 年），这使得它现在成为许多组织风险更大的选择。也就是说，除了许可问题之外，Elasticsearch是一项非常适合应用本书中技术的技术，我们希望Elasticsearch用户能够轻松地遵循并应用本书中的大多数技术。

OpenSearch：Elasticsearch的开源分支

OpenSearch 项目是亚马逊于 2021 年 2021 月推出的 Elasticsearch 的开源分支，此前 Elastic 宣布他们将在 <> 年 <> 月放弃对 Elasticsearch 的开源许可。OpenSearch是否会作为Elasticsearch和Solr的开源替代品占据重要的市场份额还有待观察，但OpenSearch提供了与Elasticsearch相同的大部分功能，而没有许可问题。随着时间的推移，Elasticsearch和OpenSearch项目几乎肯定会越来越分化，因此在亚马逊管理下的OpenSearch的发展轨迹尚未确定。

Lucidworks Fusion：开箱即用的人工智能搜索引擎

有时，购买所需的功能比在内部构建它们更方便。虽然Apache Solr，Elasticsearch和OpenSearch提供了坚实的核心搜索引擎功能，但它们都没有提供本书中发现的许多AI驱动的搜索功能和管道。

像Lucidworks这样的商业供应商可以提供开箱即用的端到端AI搜索功能，而Solr和Elasticsearch是核心匹配引擎，但缺乏AI驱动的搜索所需的扩展基础设施。Lucidworks使用“开放核心”模型提供Fusion，其中Fusion所依赖的核心技术（Apache Solr，Apache Spark）是完全开源的，因此客户完全有能力查看，调试和修改他们的系统，而不会被黑匣子系统所困，该系统限制了对核心技术，算法和代码的访问。

Milvus

自然语言模型的大规模改进催生了新的搜索和排名机制，这些机制基于将查询和文档映射到密集的向量空间。这有时被称为“神经搜索”，具体取决于所利用的模型。我们将在第13-14章中介绍所有这些，但一些新兴的搜索技术完全依赖于这些密集的矢量搜索方法。

Milvus 是一个开源矢量数据库，在这方面处于领先地位。它可以有效地索引向量，通过称为近似最近邻搜索的技术查询向量，并对向量相似性进行评分。

一些商业载体数据库也开始出现，如松果矢量相似性搜索引擎。这些引擎为高性能自然语言搜索和问答系统打开了新的大门，但它们也缺乏为传统搜索引擎提供动力的大多数自由文本搜索功能。因此，虽然这些可能对专门的用例有好处，但它们将无法实现我们将在本书中介绍的所有人工智能驱动的搜索技术。

Vespa

Vespa搜索引擎是传统的关键字搜索引擎，但具有一流的支持张量，可以索引向量，矩阵和其他类型的多维数据。这意味着Vespa支持两全其美，即基于富文本和属性的搜索和排名，以及基于丰富密集矢量的搜索和排名。

Vespa是雅虎收购和开发的搜索引擎技术，为雅虎搜索提供动力，后来被Verizon Media收购并开源。这意味着它有多年的开发、投资和大规模生产硬化。Vespa于2017年<>月开源，远远早于Solr和Elasticsearch获得其当前大部分市场份额。Vespa并不广为人知或使用，但它包含独特的组合功能，使其成为实施AI驱动的搜索引擎的人的有趣选择。随着时间的推移，Solr，Elasticsearch和OpenSearch可能会在密集矢量搜索方面赶上Vespa，但截至目前，Vespa在功能方面处于非常令人羡慕的位置，拥有竞争性的文本搜索和排名，以及比任何基于Lucene的搜索引擎更复杂的密集矢量搜索功能。

Jina

Jina 是一个用于构建神经搜索系统的开源框架。它为开发文档和查询处理管道提供了一个灵活且功能丰富的框架。Jina AI专注于集成尖端AI模型，以实现下一代搜索功能，如语义搜索，问答，聊天机器人，多模态搜索（图像，音频，视频，文本组合）等。Jina更像是一个基于python的框架，用于构建和运行搜索工作流程，而不是传统意义上的搜索引擎（所以我们不会在本书中使用它），但它提供了一个非常强大的构建块工具包，用于组装你自己的人工智能驱动的搜索工作流程，所以它可能是一项有趣的技术，可以考虑集成本书中的许多技术。

1.3人工智能搜索的目标受众

本书假定了搜索引擎机制的某些先决条件知识。如果您之前没有使用Solr或Elasticsearch等技术的经验，您可以通过阅读Solr in Action或Elasticsearch in Action两本书来快速上手。

1.3.1 目标技能和职业

本书主要面向搜索工程师、软件工程师和数据科学家。本书还将为不具备这些技能的产品经理和业务领导者提供人工智能搜索的相关概念理解，但为了让读者充分利用本书，他们需要能够遵循Python代码示例，并且需要基本了解搜索和相关性如何利用Solr或Elasticsearch等技术工作。

1.3.2 运行代码示例的系统要求

为了舒适地运行本书中的所有示例，您将需要一台Mac，Linux或Windows计算机，我们建议至少8GB的RAM才能运行一些更繁重的Spark作业。您需要确保计算机上安装了 Java 8+，但我们将根据需要引导您完成所有其他依赖项的配置。您还需要安装 Docker 并为本书拉取或构建 Docker 容器（附录 A 中的说明）。Docker 容器和数据集非常大，因此我们建议至少 25GB 的可用磁盘空间来提取和处理本书中的所有示例。

1.4 何时考虑人工智能搜索

如图 1.9 所示，AI 驱动的搜索为手动相关性调优提供了一种更复杂的替代方案。对于那些从更好的搜索相关性中受益匪浅的组织，并且正在投资或正在考虑对其搜索平台进行大量投资，从长远来看，部署人工智能驱动的搜索应该可以显着提高质量，同时显着减少工作量。

话虽如此，安装 Elasticsearch/OpenSearch、Solr 或 Vespa 并摄取文档相对容易，如果你只需要基本的关键字匹配，或者无法投入资源来构建和维护人工智能驱动的搜索平台，那么你可能会谨慎地实施本书中的太多技术，因为它肯定会增加更多的组件和复杂性你的搜索引擎整体。

然而，对于非常需要优化其搜索相关性投资的组织来说，本书中的技术是这方面的极好指南。

1.5 人工智能驱动的搜索如何工作？

我们已经制定了通过内容理解、用户理解和领域理解来匹配用户意图的最终目标。我们还列出了我们将利用的关键技术平台以及实现这一目标所需的先决条件知识。建立该背景后，现在让我们通过概述实际提供AI驱动的搜索平台所需的组件来结束本章。搜索智能不是非黑即白的，搜索要么是“基本的”，要么是“人工智能驱动的”。相反，搜索智能通常沿着可预测的进展成熟，如图 1.9 所示。

图 1.9.典型的搜索智能进展，从基本的关键字搜索到完整的自学搜索平台

在这个过程中，组织几乎总是从基本的关键字搜索开始，以便启动和运行。投入生产后，他们意识到需要提高搜索相关性，此时他们开始手动调整字段权重、提升、文本和语言分析，并引入其他特性和功能来提高搜索结果的总体相关性。

最终，他们意识到他们需要将域理解注入到他们的搜索功能中，此时组织开始投资于同义词列表、分类法、已知实体列表和特定于域的业务规则。虽然这些都有帮助，但他们最终也发现相关搜索在很大程度上依赖于成功解释用户查询和理解用户意图，因此他们开始投资查询分类、语义查询解析、知识图谱、个性化和其他正确解释用户查询的尝试技术。

由于这些任务成功地产生了改进，因此这种成功通常会导致创建大型团队，投入大量时间手动调整列表和参数，最终组织可能会意识到，通过从用户信号、用户测试（A/B、多臂老虎机和离线相关性模拟）中学习，尽可能多地自动化该过程是可能的（并且更方便）。以及构建机器学习的相关性模型。最终目标是在搜索智能过程中完全自动化每个步骤，并使引擎能够自学习。然而，大多数人需要一段时间才能到达那里，所以从坚实的基础开始是很重要的。

1.5.1 核心搜索基础

构建搜索平台的第一步几乎总是让传统的关键字搜索正常工作（图 1.8 中的“内容理解”部分）。许多人和团队花费了数年甚至十年甚至更长时间来调整和改进这一步，并且出现了一个名为相关性工程的整个学科，该学科历来将大量精力集中在理解内容、改进搜索内容、调整提升、查询参数和查询功能，以及尝试最大化传统搜索体验的相关性。随着相关性工程师变得越来越复杂，他们的工作通常会渗透到用户理解和建议领域，以及领域理解和语义搜索领域。

我们在人工智能驱动的搜索方面的重点将是自动化学习过程和优化搜索相关性，使其具有连续性和自动化性，但深入了解如何像相关性工程师一样思考并自己调整搜索引擎将对您作为背景非常有帮助。对于相关性工程世界的背景和调整传统的关键字搜索相关性，我强烈推荐Doug Turnbull和John Berryman的《相关搜索》（Manning，2016）一书。

那么，经过良好调整的搜索引擎和人工智能驱动的搜索引擎究竟有什么特征可以区分呢？经过良好调整的搜索引擎显然是构建 AI 驱动的搜索的基础，但 AI 驱动的搜索远远超出了经过良好调整的范围，它还提供了通过反射智能不断学习和改进的能力。反射智能是利用用户输入、内容更新和用户与内容交互的持续反馈循环的想法，以便不断学习和提高搜索应用程序的质量。

1.5.2 通过反馈循环反映智能

反馈循环对于构建 AI 驱动的搜索解决方案至关重要。想象一下，如果你的整个中学、中学和可能的中学后教育只不过是你阅读教科书：没有老师提问，没有考试来测试你的知识并提供反馈，没有同学或其他人与之互动、学习或合作。你可能会碰到无穷无尽的墙壁，在那里你无法完全掌握某些概念，甚至无法理解正在阅读的内容，你可能会错误地理解许多想法，甚至没有机会实现或调整你的假设。

搜索引擎通常以相同的方式运行。聪明的工程师将数据推送到搜索引擎并调整某些功能和功能权重，但随后引擎只是读取这些配置和内容，并在每次重复用户查询时以相同的方式静态操作。然而，搜索引擎是交互式学习的完美系统，通过使用反馈循环。图1.10显示了搜索引擎反馈循环的想法。

图 1.10.通过反馈循环反映智能

在图 1.10 中，您可以看到通过搜索反馈循环的典型信息流。首先，用户发出查询。此查询执行搜索，将结果返回给最终用户，例如特定答案或答案列表或指向页面的链接列表。显示列表后，用户将执行一个或多个操作。这些操作通常从单击文档开始，但这些单击最终可能导致将项目添加到购物车并购买（电子商务），为项目竖起大拇指或竖起大拇指（媒体消费网站），喜欢或评论结果（社交媒体网站），或任何其他特定于上下文的操作。

但是，用户执行的每个操作都可能提供有关搜索结果与该用户的感知相关性的线索。竖起大拇指或竖起大拇指提供明确的正面和负面相关性判断，就像添加到购物车、购买、喜欢和书签一样。点击提供的信号不太明确，但通常表明某些合适的搜索结果。

然后，可以利用这些操作为将来的搜索生成改进的相关性排名模型。例如，如果给定查询的大多数用户总是更频繁地点击第三个结果，而不是结果一或两个，这是一个强有力的指标，表明第三个结果被认为是更好、更相关的结果。利用反馈循环，您的搜索应用程序可以在将来的搜索中自动调整该查询的结果顺序，从而为下一个用户的搜索提供更好的搜索体验。然后，这个反馈循环会无限期地继续，因为引擎不断自我调整。

来自用户信号的行为智能

搜索、点击、喜欢、添加到购物车、购买、评论以及用户可能与您的搜索应用程序进行的任何其他交互都是您的搜索应用程序需要捕获的非常有价值的数据。我们将这些数据点统称为信号。信号为您的搜索应用程序提供源源不断的反馈，记录与最终用户的每一次有意义的互动。这些数字时刻 - 无论是搜索，返回的搜索结果列表，点击，购买还是介于两者之间的任何内容，都可以被机器学习算法利用来生成各种模型，以增强用户理解，内容理解和领域理解。图 1.11 显示了典型 AI 驱动的搜索应用程序中用于收集和处理信号的数据流。

图 1.11.信号采集和处理数据流

在图 1.11 中，您将看到每次搜索收集的信号，以及由此产生的点击和购买，尽管也可以为任何其他类型的用户交互（添加到购物车、分面点击、书签、悬停甚至页面停留时间）记录唯一信号。

信号是驱动 AI 驱动的搜索应用程序的智能引擎的两种燃料之一，另一种类型是您的内容。

来自文档的内容智能

虽然信号为您的搜索应用程序提供源源不断的使用和反馈数据流，但您的内容也是可以在反馈循环中利用的丰富信息源。例如，如果有人搜索特定关键字，则返回的文档中的其他关键字和热门类别将用作有价值的数据点，可用于标记或分类查询。该数据可能会显示给最终用户（例如，作为分面），然后用户可能会与该数据进行交互，这些数据随后会生成一个信号，然后引擎可以从中学习。

此外，文档的内容包含您域的代表性文本模型。文档中包含的实体、特定于域的术语和句子充当表示数据域的丰富语义图。可以利用该图来驱动强大的概念和语义搜索，从而更好地了解您的域。我们将在第 2 章中更深入地理解您的内容，并在第 5 章中利用这个丰富的语义知识图来介绍这些语义搜索功能。

1.5.3 策划与黑盒AI

许多现代人工智能技术严重依赖基于人工神经网络的深度学习。不幸的是，在大多数情况下，由于学习模型的内部复杂性，人类要理解深度学习模型的任何特定预测或输出的特定因素是非常具有挑战性的。

这导致了一个“黑匣子AI”系统，其中的结果可能是正确的或令人印象深刻的，但是当模型做出错误的判断时，它们不容易被人调试 - 或者更重要的是，正确。整个可解释的AI（有时称为可解释AI或透明AI）的出现源于能够理解，管理和信任这些模型的需求。

在本书中，虽然我们将介绍几种深度学习的搜索方法（参见第13章和第14章关于密集向量搜索和问答），但我们将主要致力于创造可以用人类术语表达的智能，然后通过人类智能进行纠正和增强。你可以把它想象成“人工智能辅助的人类策展”，或者说是“人类辅助的人工智能”，但无论哪种方式，本书的首要理念都是使用人工智能来自动化搜索智能的过程，同时让人类保持循环，能够根据需要控制和注入自己的主题专业知识。

1.5.4 人工智能搜索引擎的架构

人工智能驱动的搜索引擎的架构需要将许多构建块组装在一起，以形成一个智能的端到端系统。你显然需要一个核心搜索引擎，如Solr，Elasticsearch/OpenSearch或Vespa。您需要将可搜索内容输入引擎，对其进行转换以使其更有用。这些转换可能包括以下更改：

对文档进行分类，将分类添加为字段
规范化字段值
从文本中提取实体，在单独的字段中添加实体
情绪分析
聚类内容，将聚类添加为字段
短语检测和注释
从知识图谱、外部 API 或其他数据源中提取其他数据
语音检测和其他自然语言处理步骤的一部分
事实提取（如RDF三元组）
垃圾邮件或 NSFW（不安全工作）内容检测
应用其他机器学习模型或 ETL 规则来丰富文档

数据进入引擎后，您的目标是使其可供搜索。这需要查询管道，它可以分析传入查询、同义短语和实体，扩展到相关术语/同义词和概念，更正拼写错误，然后重写查询，以便核心引擎可以找到最相关的结果。

但是，这种查询智能中的大部分都需要对您的域有深入的了解。这需要对内容和用户信号运行批处理作业，以便学习模式并获取特定于域的智能。用户最常见的拼写错误是什么，他们在多个候选者中选择什么作为正确的拼写（在第 6 章中介绍）？当用户搜索特定查询时，哪些文档应提升为最受欢迎的文档（在第 8 章中介绍）？对于未知查询，在所有可用于匹配的属性/特征中，理想的排名是什么（在第 10 章中介绍）？

我们需要在查询时以预先计算（或快速可计算）的方式访问其中的大多数答案，因为我们希望查询是实时的，并且通常在几毫秒内返回。这需要一个作业处理框架（我们将在本书中使用Spark）和一个工作流调度机制来保持作业按顺序运行。

您还将有源源不断的新数据流以用户信号的形式传入，因此您需要一种机制来捕获和存储这些数据（在前端应用程序上捕获，存储在核心引擎或其他后端数据存储中）。

然后，这些信号将用于生成各种模型 - 从流行查询的特定项目的信号增强，到生成适用于所有查询的广义学习对模型进行排名，再到为每个用户或用户群生成用户特定的建议和个性化偏好。

最终，您最终将得到一个系统，该系统接收源源不断的文档更改和用户信号流，不断处理这些更新以学习和改进模型，然后不断调整未来的搜索结果并衡量更改的影响，以不断提供更智能的结果。这就是人工智能搜索背后的关键：基于真实用户交互和不断发展的内容模式的持续学习和改进过程，以充分理解用户意图并提供不断改进的搜索体验。