人工智能驱动的搜索（AI-Powered Search）——处理自然语言

本章内容包括：

• 非结构化数据中的隐藏结构
• 以搜索为中心的语言哲学
• 探索分布式语义学和基于向量的嵌入
• 建模领域特定的知识
• 自然语言和查询中的挑战
• 将自然语言理解技术应用于内容和信号

在第一章中，我们提供了构建人工智能驱动的搜索系统的高层次概述。在本书的其余部分，我们将探索并演示多种方式，帮助您的搜索应用程序不断学习内容和用户行为信号，以更好地理解您的内容、用户和领域，并最终为用户提供他们需要的答案。在第三章中，我们将更为实际地操作，启动您选择的搜索服务器和数据处理层（Apache Spark），并开始使用我们全书都会用到的第一个Jupyter笔记本，通过一步一步的示例进行讲解。

然而，在深入这些实际操作示例和具体实现之前，本章首先要建立一个共享的思维模型，帮助我们理解我们试图解决的更高层次的问题。具体来说，在智能搜索方面，我们需要处理自然语言中的许多复杂性和细微差别——无论是我们要搜索的内容，还是用户的搜索查询。我们需要处理关键词、实体、概念、拼写错误、同义词、缩写、首字母缩略词、模糊词汇、概念之间的显式和隐式关系、通常出现在分类法中的层次关系、通常出现在本体中的更高级关系，以及通常出现在综合知识图谱中的实体关系的特定实例。

虽然直接深入一些具体问题，如如何自动从内容中学习拼写错误或如何从挖掘用户搜索会话中发现同义词，可能会让人感到诱惑，但首先建立一个概念性的基础，解释我们在搜索和自然语言理解（NLU）中需要处理的各种问题，更为谨慎。建立这一哲学基础将使我们能够在人工智能驱动的搜索系统中构建更好的端到端解决方案，其中所有部分能够协同工作、紧密集成。因此，本章将为我们在本书中如何解决自然语言理解的问题提供哲学基础，并阐述我们如何将这些解决方案应用于使搜索应用程序更加智能。

我们将首先讨论关于自由文本和其他非结构化数据源的一些常见误解。

2.1 非结构化数据的误区

“非结构化数据”这个术语多年来一直用来描述文本数据，因为它看起来并没有以一种可以直接解读和查询的方式进行格式化。然而，广泛流传的观点认为，文本或任何不符合预定义模式（“结构”）的数据实际上是“非结构化的”，这一观点是一个误区，我们将在本节中花时间重新审视它。

如果你在维基百科上查找非结构化数据，它的定义是：“信息要么没有预定义的数据模型，要么没有按照预定义的方式组织”。该条目继续说，“非结构化信息通常以文本为主，但也可能包含日期、数字和事实等数据”。

然而，“非结构化数据”这一说法并不适合用来描述文本内容。实际上，文本中出现的术语和短语承载了大量的意义，而应用于文本的语言规则为其赋予了结构。将文本称为非结构化数据，就像把收音机里播放的歌曲称为“任意的音波”一样。尽管每首歌都有独特的特征，但大多数歌曲展示了共同的属性（节奏、旋律、和声、歌词等等）。尽管这些属性可能会有所不同或缺失，但它们仍然符合共同的预期，使得每首歌能够传达和提取意义。文本信息通常遵循类似的规则——句子结构、语法、标点、词性之间的互动等等。图2.1展示了我们将在接下来的部分中进一步探讨的文本示例，帮助我们研究这些结构。

虽然文本是最常见的被认定为非结构化数据的类型，但还有其他几种具有相似特征的非结构化数据类型，我们将在下一节中看到。

2.1.1 非结构化数据的类型

自由文本内容被认为是非结构化数据的主要类型，但搜索引擎也常常索引许多其他类型的数据，这些数据同样无法整齐地纳入结构化数据库中。常见的例子包括图像、音频、视频和事件日志。图2.2扩展了我们在图2.1中的文本示例，并包含了其他几种非结构化数据类型，如音频、图像和视频。

音频是与文本内容最相似的类型，因为它通常只是另一种编码单词和句子的方式。当然，音频不仅限于口语，它还可以包含音乐和非语言声音，并且能够更有效地编码诸如情感、语调以及重叠的交流等细微差别。

图像是另一种非结构化数据。就像单词组成句子和段落来表达思想一样，图像通过颜色的网格组合形成图画。

视频则是另一种非结构化数据，它是多幅图像随时间变化的组合，以及与图像进展同步的可选音频。

当非结构化数据与结构化数据混合时，我们通常称之为半结构化数据。日志数据就是这种半结构化数据的一个很好的例子。通常，日志消息包含结构化的事件日期、结构化的事件类型（例如警告与错误，或搜索与点击），然后是某种类型的自由文本的非结构化消息或描述。

从技术角度讲，几乎任何类型的文件都可以被视为非结构化数据，但我们主要处理上述几种类型。搜索引擎通常负责处理这些非结构化数据类型，因此我们将在本书中讨论如何处理它们的策略。

2.1.2 传统结构化数据库中的数据类型

为了更好地处理非结构化数据，首先将其与SQL数据库中的结构化数据进行对比可能会很有帮助。这将使我们以后能够在查询非结构化数据表示与结构化数据表示时进行类比。

SQL数据库中的一条记录（行）被分割成多个列，每一列可以具有特定的数据类型。其中一些数据类型表示离散值——来自枚举列表的值，如ID、名称或文本属性。其他列可能包含连续值，如日期/时间范围、数字以及其他表示范围但没有有限值数量的列类型。

一般来说，当需要将不同的行关联在一起，或者将它们与其他数据库表中的行关联时，通常会对离散值进行“连接”（joins）。连接使用共享值（通常是ID字段）将两个或更多记录关联在一起，从而形成复合记录。

例如，如果有人有两张数据表，一张表示员工，另一张表示公司，那么公司表可能会有一个id列，员工表则有一个对应的company_id列。员工表中的company_id字段被称为外键，它是一个在一张表中引用另一张表中实体的值，基于共享标识符将记录关联起来。图2.3展示了这一点，显示了离散值、连续值的示例以及使用外键跨表连接的示例。

基于已知关系（主键和外键）将不同记录连接起来的这一概念，是处理显式关系数据的一种强大方式。

基于已知关系（主键和外键）将不同记录连接起来的这一概念，是处理显式建模表数据的一种强大方式，但正如我们将在下一节中看到的，非常相似的技术也可以应用于自由格式的非结构化数据。

2.1.3 非结构化数据中的连接、模糊连接和实体解析

尽管数据库中的结构化数据已经以易于查询的形式存在，但实际上，非结构化数据面临的并非缺乏结构的问题，而是将大量信息打包进一个非常灵活的结构中。本节中，我们将通过一个具体示例揭示非结构化数据中的隐藏结构，并展示如何类似地利用它来查找和连接文档之间的关系。

非结构化数据中的外键

我们已经讨论了如何基于两个记录之间的共享标识符，在数据库中使用外键将两行记录连接在一起。在本节中，我们将展示如何使用文本数据实现相同的目标。

例如，我们可以轻松地将SQL表中使用的外键概念映射到我们在图2.2中探索的非结构化信息中。注意图2.4中，两个不同的文本部分都包含了单词“Haystack”，它指代一个专注于搜索相关性的技术会议。

第一个实例表示一个会议的发言内容，而第二段文本则包含关于该事件的一般信息。为了方便我们的示例，假设每一条信息（文本块、图像、视频和音频片段）都作为一个单独的文档在我们的搜索引擎中表示。在功能上，数据库表中有两行记录，每行包含值“Haystack”的列，与在搜索引擎中有两个单独的文档，每个文档包含值“Haystack”之间几乎没有区别。在这两种情况下，我们都可以将这些文档视为通过外键相关联。

非结构化数据中的模糊外键

然而，在非结构化数据中，我们比在传统结构化数据建模中拥有更强大的能力。例如，在图2.5中，可以看到现在两个文档被关联在一起，并且它们都指向本书的主要作者——一个使用了我的全名“Trey Grainger”，另一个则只使用了我的名字“Trey”。

这是一个实体解析的例子，其中有两个不同的实体表示，但它们仍然可以被解析为相同的意义，因此仍然可以用来连接两个文档之间的信息。你可以把它看作是一个“模糊外键”，因为它仍然是外键，但不是严格的标记匹配，而是需要额外的自然语言处理和实体解析技术来解析。

一旦我们打开了进行实体解析的高级文本处理的这扇大门，我们就能从非结构化信息中学到更多。例如，不仅“ Trey”和“Trey Grainger”在这些文档中指代相同的实体，词语“he”和“his”也是如此。

你还会注意到，我的图片（位于左下角，如果你不知道我长什么样的话）和包含我名字的一个视频被识别为相关，并与文本引用关联在一起。我们依赖于所有这些非结构化数据中存在的隐藏结构来理解意义，关联文档，并进一步了解文档中提到的每个实体。

处理歧义词汇

到目前为止，一切顺利，但在实际内容中，并不总是适合假设同一术语在多个地方具有相同的含义，或者即使我们进行实体解析，也并不总是能正确解析实体。这个问题，即同一个单词和短语的拼写可能有多重含义，称为多义性，处理这些歧义词汇在搜索应用程序中可能是一个巨大的挑战。

你可能注意到在之前的图像右上角有一张看起来有些不合适的奇怪图片。这张图片展示的是一个拿着砍刀的相当吓人的男人。显然，如果你在Google上搜索“Trey Grainger”，这张图片就会出现。如果你进一步深入，你会在图2.6中看到，x.com（前身为Twitter）上也有一个叫“Trey Grainger”的用户，而这张图片是他的个人资料照片。

这张图片显然是罗伯特·肖（Robert Shaw）的照片，他在1975年电影《大白鲨》中饰演Quint，但这显然不是你希望人们在网上搜索你时首先看到的东西！

这里有两个关键的教训。首先，也许永远不要在Google上搜索自己（你可能会被发现的东西吓到！）。其次，更严肃的一点是，多义性在搜索和自然语言理解中是一个主要问题。不能假设一个术语只有单一的含义，或者即使在不同的上下文中也有一致的含义，因此我们的AI驱动的搜索引擎需要利用上下文来区分这些不同的含义。

非结构化数据作为一个巨大的关系图

在前面的部分中，我们看到非结构化数据不仅包含丰富的信息（实体及其关系），还发现通过在共享实体上连接不同文档，类似于传统数据库中的外键工作方式，确实可以将文档关联起来。然而，典型的非结构化数据包含了如此多的这些关系，以至于与其将其视为行和列的集合，更有意义的是将其视为一个巨大的关系图，正如我们在本节中将要探讨的那样。

此时，应该很清楚，非结构化数据中隐藏的结构比大多数人所理解的要多得多。非结构化信息实际上更像是“超结构化”的信息——它是一个图，包含了比典型“结构化数据”更多的结构。

图2.7展示了即使在我们示例中的少量文档中，也存在的这个巨大的关系图。你可以看到名字、日期、事件、地点、人、公司和其他实体，你可以推断它们之间的关系，使用跨文档的实体连接进行连接。你还会注意到，这些图片已经被正确地消歧，以至于持砍刀的人现在已经从图中断开。如果仅仅从几个文档中就能学到这些，想象一下从你搜索引擎中的成千上万、百万甚至亿万文档中可以学到什么。

AI驱动的搜索平台的价值之一是能够从数据中学习到像这样的见解。问题是，如何利用这个庞大的语义知识图来推动智能？

利用文本数据图的一种最强大的方式是通过大型语言模型（LLM），例如第1.3.4节中介绍的Transformer模型。这些模型使用深度学习，从海量数据集（如互联网上的大部分内容）中学习数十亿个参数，建立对语言的详细理解。这种理解包括单词在不同上下文中的含义，以及单词之间的语言和概念联系。这些模型内部表示了它们所训练的所有数据中的巨大关系图，这些数据通常比你的数据集更为通用，因此这些模型必须经过微调，才能从你的数据中学习任何领域特定的关系。由于LLM本身有些像黑箱，这种微调的需求可能会带来一些挑战，因为它们否则无法最佳地表示你的数据集，并且它们返回的信息可能是错误的。

幸运的是，你搜索引擎中倒排索引的固有结构使得无需任何额外的显式数据建模，就可以非常容易地遍历你数据中庞大的关系图。倒排索引是用于词汇搜索的主要数据结构，它将文档字段中的每个关键词或术语映射到包含这些关键词的所有文档的列表（称为帖子列表）。倒排索引使得查找包含任何给定术语（或术语序列，在考虑位置匹配和通过集合操作实现的布尔逻辑时）文档集合变得非常快速。通过这些查找，可以利用它们共享的文档在不同的术语序列之间进行遍历，计算图中的加权边。在第5章中，我们将深入探讨如何利用你数据中隐藏的这个语义知识图。

2.2 自然语言的结构

在上一节中，我们讨论了文本和非结构化数据通常包含一个巨大的关系图，这些关系图可以通过查看不同记录之间共享的术语来推导出来。如果你已经在构建搜索引擎一段时间了，你可能习惯于从“文档”、“字段”和“字段中的术语”这些角度来看待内容。然而，在解释内容的语义意义时，还有几个更深的层次需要考虑。

图2.8展示了这些额外的语义层次。在最基本的层次上，你有字符，它们是单个字母、数字或符号，例如图中的字母“e”。一个或多个字符随后组合形成字符序列，如“e”、“en”、“eng”、……“engineer”和“engineers”。一些字符序列形成术语，这些术语是完整的单词或标记，具有可识别的意义，如“engineer”、“engineers”、“engineering”或“software”。一个或多个术语可以进一步组合成术语序列——通常当这些术语是连续排列时，我们称其为短语。这些包括“software engineer”、“software engineers”和“senior software engineer”等。为了简便起见，本书中我们也将单个术语视为“术语序列”，因此每当我们提到“短语”时，这也包括单个术语。

术语序列与短语

你可能会想知道“术语序列”和“短语”之间有什么区别。简单来说，短语是一个术语序列，其中所有术语都按顺序出现。例如，“chief executive officer”既是一个短语，也是一个术语序列，而“chief officer”~2（意思是“officer”在“chief”之后的两个位置内，或者是编辑距离为2的情况）则只是一个术语序列，因为它指定了一个不一定是顺序排列的术语序列。在绝大多数情况下，你只会处理顺序的术语序列，因此为了简便起见，本书中我们通常会用“短语”一词，包含单个术语和多个术语按顺序排列的序列。为了避免混淆，请注意，单词“术语”是用来指代“搜索引擎中某个字段中的唯一值”的。因此，我们有时也会将搜索引擎中未分割的包含多个单词的字符串称为“术语”，尽管在语言学上它们被视为“短语”或“术语序列”。

当然，我们知道，多个术语序列可以组合成句子，多个句子可以组成段落，段落可以进一步汇聚成更大的文本组。然而，对于搜索引擎来说，通常在术语序列之后我们会关注的下一个更高层次的分组是字段。搜索引擎中的字段是文档的一个分区和标签化部分，通常用于搜索或作为文档的独立部分返回。包含文本的字段可以通过文本分析器以多种方式进行分析，文本分析器通常包括分割空格和标点符号、将所有术语转换为小写以便不区分大小写、去除噪声（停止词和某些字符）、词干提取或词形还原以将术语还原为基本形式，以及去除重音等技术。如果你对文本分析过程不熟悉，或者需要复习，我们建议查阅Trey Grainger和Timothy Potter的《Solr in Action》第6章（Manning，2014）。

一个或多个字段随后会组合成一个文档，多个文档组成一个语料库或数据集合。每当执行针对搜索索引的查询时，它会将语料库过滤成一个文档集，文档集是与查询特定相关的语料库的一个子集。

这些语言学层次——字符序列、术语、术语序列、字段、文档、文档集和语料库——为理解你的内容及其在特定领域中的独特意义提供了独特的见解。

2.3 分布式语义学与嵌入

分布式语义学是自然语言处理领域的一个研究方向，关注基于分布假设的术语和短语之间的语义关系。分布假设认为，在相似的上下文中出现的单词往往具有相似的意义。这个假设通过一句流行的名言很好地总结：“你可以通过一个词所处的环境来知道它的意思。”

当将机器学习方法应用于文本时，这些分布式语义变得越来越重要，搜索引擎使得从语料库中推导出大多数语言表示的上下文变得异常简单。例如，如果某人想查找关于C级高管的所有文档，他们可以发出如下查询：

c?o

这个查询会匹配“CEO”、“CMO”、“CFO”或任何其他CXO类型的职称，因为它要求匹配以“c”开头并以“o”结尾，中间有一个字符的任意字符序列。

同样的自由度也存在于查询任意复杂的术语序列：

"VP Engineering"~2

这个查询会匹配“VP Engineering”、“VP of Engineering”、“Engineering VP”，甚至“VP of Software Engineering”，因为它要求查找“VP”和“Engineering”在两个位置（编辑距离）之内。

当然，搜索引擎的倒排索引的性质也使得支持任意布尔查询变得非常简单。例如，如果某人搜索术语“Word”，但我们希望确保任何匹配的文档中也包含“Microsoft”或“MS”中的任意一个，我们可以发出以下查询：

(Microsoft OR MS) AND Word

搜索引擎支持在整个语料库中对字符序列、术语和术语序列进行任意复杂组合的查询，返回作为该查询的内容匹配上下文的文档集。例如，如果你运行一个关于披萨的查询，返回的文档更可能是餐馆而不是汽车租赁公司；如果你运行一个关于机器学习的查询，返回的文档更可能是数据科学家或软件工程师的职位，而不是会计、食品服务工作者或药剂师的职位。这意味着你可以推断出“机器学习”和“软件工程”之间有很强的关系，而“机器学习”和“食品服务工作者”之间有很弱的关系。如果你深入挖掘，你还可以看到在机器学习文档集中与语料库其余部分相比，哪些术语和短语最常同时出现，从而更好地理解“机器学习”这一短语的意义和用法。我们将在第5章中深入探讨如何使用这些关系的实际示例。

引入向量

基本理解向量操作将对你在本书中的学习非常重要。向量是描述某个物品一些属性的值列表。例如，如果你的物品是房屋，你可能有一组属性，如价格、大小和卧室数量。如果你有一套房子，价格为$100,000，大小为1,000平方英尺，卧室数量为2，那么这可以表示为向量 [100000, 1000, 2]。

这些属性（如价格、大小和卧室数量）称为维度或特征，特定的维度集合称为向量空间。如果你能在向量空间的维度中为其他物品（如其他房屋、公寓或住宅）分配值，你就可以在同一向量空间内表示这些物品。

如果我们考虑在同一向量空间内的其他向量（例如，一套房子 [1000000, 9850, 12] 和另一套房子 [120000, 1400, 3]），我们可以对向量进行数学运算，以发现趋势和比较向量。例如，你可能直观地查看这三个示例向量，并确定“房屋价格通常随着房间数量的增加而增加”，或者“房间数量通常随着房屋大小的增加而增加”。我们还可以对向量进行相似性计算，以确定，$120,000的房子，拥有1,400平方英尺和3个卧室，更类似于$100,000的房子，1,000平方英尺和2个卧室，而不是$1,000,000的房子，9,850平方英尺和12个卧室。

近年来，分布假设已被应用于通过所谓的嵌入（embeddings）创建术语和术语序列的语义理解。嵌入是一组在向量空间中的坐标，我们将一个概念映射（或“嵌入”）到这些坐标中。更具体地说，这组坐标是一个数值向量（一个数字列表），旨在表示你数据（文本、图像、音频、行为或其他数据模态）的语义含义。基于文本的嵌入可以表示任意长度的术语序列，但当表示单个单词或短语时，我们称这些嵌入为词嵌入（word embeddings）。

术语序列通常会被编码成一个降维嵌入，可以与语料库中所有其他嵌入的向量进行比较，以找到最语义相关的文档。

为了理解这一过程，思考搜索引擎如何“开箱即用”可能会有所帮助。让我们假设每个术语都有一个向量，其中包含语料库中每个单词的一个值（维度）。它可能看起来像图2.9所示。

图2.9 从概念上展示了默认情况下词汇搜索引擎中文档匹配的工作原理。词汇搜索是根据文档中包含的实际关键词或查询中指定的其他属性的程度来匹配和排名文档的搜索。在每个关键词查询中，存在一个向量，该向量包含倒排索引中每个术语的维度。如果该术语在查询中存在，那么该维度的值为1；如果该术语在查询中不存在，则该维度的值为0。每个文档在倒排索引中也有一个类似的向量，对于文档中出现的任何来自索引的术语，其对应的值为1，而所有其他术语的值为0。

当执行查询时，系统会在索引中查找任何匹配的术语，然后基于查询向量和相对于查询的文档向量的比较来计算相似度分数。我们将在第3章中详细讲解具体的评分计算，但目前这一高层次的理解已经足够。

这种方法有明显的缺点。虽然它对于找到完全匹配关键词的文档非常有效，但当你想查找“相关”的东西时会发生什么呢？例如，你会注意到查询中出现了“soda”这个术语，但它在索引中从未出现。即使存在其他种类的饮料（如“apple juice”、“water”、“cappuccino”和“latte”），搜索引擎总是会返回零结果，因为它无法理解用户在搜索一种饮料。类似地，尽管“caffeine”这个术语存在于索引中，但对“latte”、“cappuccino”和“green tea”的查询将永远不会与“caffeine”匹配，尽管它们是相关的。

因此，现在通常采用减少维度的稠密嵌入（dense embeddings）来为索引和查询中的术语序列建模语义含义。稠密嵌入（也称为稠密向量嵌入）是一个包含更多抽象特征的向量，用于在语义空间中编码输入的概念意义。图2.10展示了现在映射到一个降维向量的术语，这个向量可以作为一个稠密嵌入。

现在，对于图2.10最左侧列中的每个术语序列，我们都有了新的嵌入向量，我们可以使用它们的向量之间的相似度来对每对术语序列之间的关系进行评分。在线性代数中，我们使用余弦相似度函数（或其他相似度度量）来对两个向量之间的关系进行评分。余弦相似度是通过对两个向量执行点积运算，并将结果按每个向量的大小（长度）进行缩放来计算的。我们将在下一章详细讨论数学部分，但目前，图2.11展示了对这些向量之间的相似度进行评分的结果。

正如你在图2.11中所看到的，由于每个术语序列被编码为表示其在更高层次特征中的意义的向量，因此现在可以使用这个嵌入向量来对该术语序列与任何其他相似向量的相似度进行评分。你会在图的底部看到三个向量相似度列表：一个是“green tea”（绿茶），一个是“cheese pizza”（芝士披萨），还有一个是“donut”（甜甜圈）。

通过比较“green tea”（绿茶）与所有其他术语序列的向量相似度，我们发现与它最相关的项是“water”（水）、“cappuccino”（卡布奇诺）、“latte”（拿铁）、“apple juice”（苹果汁）和“soda”（苏打水），而与之最不相关的是“donut”（甜甜圈）。这在直观上是有意义的，因为“green tea”与列表中较高位置的项共享更多属性。对于“cheese pizza”（芝士披萨）向量，我们看到最相似的其他嵌入是“cheese bread sticks”（芝士面包棒）、“cinnamon bread sticks”（肉桂面包棒）和“donut”（甜甜圈），而“water”（水）排在列表的底部。最后，对于术语“donut”（甜甜圈），我们发现最相关的项是“cinnamon bread sticks”（肉桂面包棒）、“cheese bread sticks”（芝士面包棒）和“cheese pizza”（芝士披萨），而“water”（水）再次排在列表的底部。这些结果非常好地找到了与原始查询最相似的项。

值得注意的是，这种向量评分仅用于计算项之间的相似性。在你的搜索引擎中，通常有一个两阶段的过程，首先是过滤出一组文档（匹配阶段），然后对这些文档进行评分（排名阶段）。除非你跳过第一步，直接对所有文档相对于查询向量进行评分（这可能非常耗时和处理资源），否则你仍然需要某种形式的初步匹配，在排名阶段之前过滤查询，筛选出一个合理数量的文档进行评分。我们将在第3章、第9章、第13章、第14章和第15章中深入探讨成功实施嵌入和向量搜索的机制。

嵌入可能代表查询、文档部分，甚至是整个文档。将术语和术语序列编码为词嵌入（word embeddings）是很常见的，但句子嵌入（encoding a vector with the meaning of a sentence，编码一个表示句子意义的向量）、段落嵌入（encoding a vector with the meaning of a paragraph，编码一个表示段落意义的向量）和文档嵌入（encoding a vector with the meaning of an entire document，编码一个表示整个文档意义的向量）也是常见的技术。

维度通常比我们这里的示例更加抽象也是很常见的。例如，像LLM（大型语言模型）这样的深度学习模型可能会从字符序列和文档在语料库中聚集的方式中检测出看似无法理解的特征。我们可能无法轻松地为这些嵌入向量中的维度应用人类可读的标签，但只要它能提高模型的预测能力并增加相关性，通常对于大多数搜索团队来说，这不是问题。实际上，由于向量通过不同的抽象数字特征编码“意义”，因此也可以创建并搜索表示不同类型（或模态）数据的向量，例如图像、音频、视频，甚至是信号和活动模式。我们将在第15.3节中讨论多模态搜索（针对不同数据模态的搜索）。

最终，结合多个模型来利用分布式语义学和嵌入的力量通常能创造出最佳的结果，接下来我们将在本书的其余部分深入探讨多种基于图和向量的方法，使用这些技术。

2.4 建模领域特定知识

在第一章中，我们讨论了搜索智能的进展（参见图1.8），组织从基本的关键词搜索开始，并通过几个改进阶段，最终实现完全自学习的系统。在这一搜索智能进展的第二阶段是构建分类法和本体，而第三阶段（“查询意图”）则包括构建和使用知识图谱。不幸的是，在行业中，实践者在“本体”、“分类法”、“同义词列表”、“知识图谱”、“替代标签”等术语的定义和关键术语上，有时会产生相当大的混淆。因此，为了避免任何歧义，本书将提供一些定义。具体来说，我们将为“知识图谱”、“本体”、“分类法”、“同义词”和“替代标签”这些关键术语提供定义。图2.12展示了它们之间的高层次关系图。

我们将这些知识建模技术定义如下：

替代标签（Alternative labels，或alt. labels） —具有相同意义的替代术语序列。 示例： CTO => Chief Technology Officer specialise => specialize

同义词（Synonyms） —可以用来表示相同或非常相似事物的替代术语序列。 示例： human => homo sapiens, mankind food => sustenance, meal

分类法（Taxonomy） —将事物分类到不同类别中的方法。 示例： human 是 mammal mammal 是 animal

本体（Ontology） —事物类型之间关系的映射。 示例： animal 吃 food food 含有 ingredients

知识图谱（Knowledge graph） —本体的实例化，也包含与之相关的事物。 示例： John 是 human John 吃 food

创建替代标签是最容易理解的技术之一。首字母缩略词（例如“RN” => “Registered Nurse”）和缩略词几乎总是作为替代标签使用，拼写错误和替代拼写也是如此。有时，将这些映射存储在单独的列表中是有用的，特别是当你使用算法来确定它们时，并且预计允许人类修改它们，或者计划以后重新运行这些算法时。

同义词是第二常见的技术，因为几乎每个搜索引擎都会有某种同义词列表的实现。替代标签是同义词列表的一个子集，并且是最明显的同义词类型。大多数人也认为“高度相关”的术语序列是同义词。例如，“software engineer”（软件工程师）和“software developer”（软件开发者）通常被认为是同义词，因为它们通常可以互换使用，尽管两者之间存在一些含义上的细微差别。有时，你甚至会看到不同语言之间的词汇翻译出现在同义词中，用于双语搜索用例。

替代标签和更一般的同义词之间的一个关键区别是，替代标签可以看作是原始术语的替换词，而同义词则更常用作扩展词，与原始术语一起使用。实现方法可以有所不同，但归根结底，这取决于你是否确信两个术语序列完全具有相同的含义（并且你希望将它们归一化），或者你只是想包括更多相关的术语序列，以避免错过其他相关结果。

分类法是同义词之上的下一步。分类法不那么关注替代词或扩展词，而是侧重于将你的内容分类到一个层级结构中。分类信息通常用于推动网站导航、为一部分搜索结果改变行为（例如，根据父产品类别显示不同的分面或筛选选项），或根据查询映射到的类别应用动态筛选。例如，如果有人在家居改进网站上搜索“range”（范围），该网站可能会自动筛选到“appliances”（家电）类别，以去除其他包含“fall within the range”（在范围内）等描述词的产品的噪音。同义词随后映射到分类法中，指向分类法中的特定项。

分类法通常指定类别之间的父子关系，然后将事物映射到这些类别中，而本体则提供了在领域内定义更加丰富的事物之间关系的能力。本体通常定义更抽象的关系，试图建模领域内事物之间的关系，例如“employee reports to boss”（员工向老板汇报）、“CMO’s boss is CEO”（CMO的老板是CEO）、“CMO is employee”（CMO是员工）。这使得本体非常有用于通过将事实映射到本体中，然后根据本体中可以应用于这些事实的关系得出逻辑结论，从而推导出新的信息。

知识图谱是知识管理领域的相对新兴技术。虽然本体定义了适用于事物类型的高层次关系，但知识图谱往往是本体的完整实例化，同时还包括属于这些类型的具体实体。使用我们之前的本体示例，知识图谱将额外包含“Michael 是 CMO”，“Michael 向 Marcia 汇报”和“Marcia 是 CEO”作为图谱中的关系。在知识图谱成为主流之前，这些更详细的关系通常会被建模到本体中，许多人今天仍然这么做。因此，你经常会看到“知识图谱”和“本体”这两个术语交替使用，尽管这种做法随着时间的推移逐渐减少。

在本书中，我们将主要讨论替代标签、同义词和知识图谱，因为分类法和本体通常已被归纳到知识图谱中。我们将在第5章更深入地探讨知识图谱。

2.5 搜索中的自然语言理解挑战

在之前的几节中，我们讨论了嵌入在非结构化数据（如文本）中的丰富意义图，以及如何利用分布式语义学和嵌入来推导和评分查询和文档中术语序列之间的语义关系。我们还介绍了知识建模的关键技术，并定义了本书中将使用的相关术语。在本节中，我们将讨论与自然语言理解相关的几个关键挑战，这些挑战是我们将在接下来的章节中力求克服的。

2.5.1 歧义性挑战（多义性）

在2.1.3节中，我们介绍了多义性（polysemy）或歧义词的概念。在那一节中，我们讨论了一个带有“Trey Grainger”标签的图像，但它指的是与本书作者不同的人。然而，在文本数据中，我们也面临同样的问题，并且可能变得非常复杂。

考虑一下“driver”这个词。它可以广泛指代“驾驶员”，即驾驶交通工具的人；也可以指一种高尔夫球杆，用于击打球；还可以指使硬件设备正常工作的软件；或者是推动某物向前的动力（“成功的关键驱动因素”）。这个词有很多潜在的意义，你甚至可以探索更具体的含义。例如，在“车辆驾驶员”类别中，它可能指的是出租车司机、Uber司机、Lyft司机、专业卡车司机（如CDL司机，即持有商业驾驶证的人），甚至可能是公交车司机。在公交车司机这个子集内，它还可以指学校公交车司机、公共城市公交车司机、旅游巴士司机等等。我们可以继续将这个列表细分为至少几十个附加类别。

在构建搜索应用时，工程师常常天真地创建静态同义词列表，并假设术语具有单一的意义，可以普遍应用。然而，现实情况是，每个术语（单词或短语）都会根据其使用的具体上下文赋予独特的意义。

提示 每个术语都会根据其使用的具体上下文赋予独特的意义。

尽管我们在第5章中会讨论如何通过语义知识图来近似支持无穷无尽的潜在意义，但实际上，很难在实践中支持无限数量的潜在意义。无论你是为每个短语支持多个意义还是仅支持几个意义，重要的是要认识到，必须能够为用户可能遇到的任何短语生成准确（且往往是细致入微的）解释。

2.5.2 理解上下文的挑战

我常说，每个你遇到的术语（单词或短语）都是一个“上下文依赖的意义簇，带有模糊标签”。也就是说，存在一个标签（术语的文本表示），它应用于某个概念（意义簇），这个概念依赖于它所在的上下文。根据这个定义，若不了解上下文，就不可能精确地解释一个术语。因此，创建固定的同义词列表而不能考虑上下文，可能会为用户带来次优的搜索体验。

Transformer模型基本上基于这一前提运作，利用输入提示作为解释每个单词部分（或标记）的上下文。根据周围的标记及其与模型中学习到的表示的关系，Transformer会关注每个标记，而这种关系也是上下文相关的。我们将在第13章深入探讨Transformer的细节，并且在第14章微调一个Transformer模型来完成问答任务。

尽管上下文非常重要，但这并不意味着它总是容易正确应用。当搜索引擎无法理解查询时，通常需要执行基本的关键词搜索作为回退方案，并且几乎总是有用的，拥有预构建的领域理解，可以同样用于帮助解释查询。这种预构建的领域理解最终会覆盖一些默认的基于关键词的匹配行为（例如，将单个关键词连接成短语、注入同义词、纠正拼写错误）。

正如我们在第一章中讨论的，查询的上下文不仅包括搜索关键词和文档中的内容。它还包括对你所在领域的理解，以及对用户的理解。查询的含义可能会根据你对用户的了解以及你拥有的任何领域特定的理解而完全不同。这种上下文是必要的，不仅为了检测和解决我们在上一节中讨论的歧义问题，还为了确保你的用户获得最智能的搜索体验。在本书中，我们将重点介绍如何根据查询的独特上下文自动学习每个查询的上下文解释的技术。

2.5.3 个性化的挑战

当考虑用户特定的上下文作为增强查询理解的工具时，如何在现有的内容和领域特定评分基础上应用用户特定的个性化往往并不显而易见。例如，假设你发现某个用户非常喜欢Apple品牌，因为他们不断搜索iPhone。这是否意味着，当他们搜索手表、电脑、键盘、耳机和音乐播放器时，Apple品牌也应该被提高优先级？可能该用户只喜欢Apple品牌的手机，而在其他类别中提高该品牌的优先级反而可能让用户感到沮丧。例如，即使用户之前确实搜索过iPhone，你怎么知道他们不是在将iPhone与其他他们考虑的手机进行比较？

在所有用户意图的维度（图1.5）中，个性化是最容易出错的，因此它是现代AI驱动的搜索应用程序中最不常见的功能（当然，推荐引擎除外）。我们将在第9章详细讨论这些问题，突出我们如何在推出个性化搜索体验时找到正确的平衡。

2.5.4 解析查询与文档的挑战

当工程师和数据科学家刚开始进行搜索工作时，常见的问题之一是倾向于将标准的自然语言处理技术（如语言检测、词性检测、短语检测和情感分析）应用于查询。通常，这些技术是针对较长的文本块训练的——通常是在文档、段落或至少是句子层级。

文档通常较长，能为周围的文本提供显著更多的上下文，而查询在大多数使用场景中通常很短（通常只有几个关键词）。即便查询较长，它们也倾向于结合多个想法，而不是提供更多的语言学上下文。因此，在解析查询时，需要尽可能地利用外部上下文。

例如，不是使用依赖于句子结构的自然语言处理库来解析查询，你可以尝试在文档语料库中查找查询中的短语，找到它们最常见的领域特定解释。同样，你可以通过挖掘用户行为信号，利用查询中术语的共现信息来帮助理解。这使得你可以从类似用户那里学习真实的意图，而这在标准自然语言处理库中是很难可靠地得出的。

简而言之，由于查询通常较短并且往往隐含更多意义，因此需要特别的处理和解释。因此，充分利用以搜索为中心的数据科学方法来解析查询，会比传统的自然语言处理方法产生更好的结果。

2.5.5 解析查询意图的挑战

虽然解析查询以理解其包含的术语和短语是很重要的，但查询背后通常存在更高层次的意图——可以称之为查询意图。例如，考虑以下查询之间的内在差异：

• who is the CEO?（谁是CEO？）
• support（支持）
• iphone screen blacked out（iPhone屏幕变黑）
• iphone（iPhone）
• verizon silver iphone 8 plus 64GB（Verizon银色iPhone 8 Plus 64GB）
• sale（促销）
• refrigerators（冰箱）
• pay my bill（支付账单）

第一个查询“who is the CEO?”显然是为了找到一个事实性的答案，而不是一系列文档。第二个查询“support”则是试图导航到网站的支持部分，或以其他方式联系支持团队。第三个查询“iphone screen blacked out”也是在寻找支持，但它针对的是一个特定的问题，用户可能希望在联系实际支持团队之前，找到一些故障排除页面，以帮助解决这个特定问题。

接下来的两个查询“iphone”和“verizon silver iphone 8 plus 64GB”非常有趣。虽然它们都是关于iPhone的，第一个查询是一个一般性的搜索，可能表明用户在浏览或进行产品研究，而第二个查询是第一个搜索的更具体变体，表明用户明确知道自己在寻找什么，并且可能接近做出购买决定。对于“iphone”这一通用查询，更合适的做法是返回一个提供iPhone概览及可选项的着陆页，而对于更具体的查询，则可能更适合直接跳转到包含购买按钮的产品页面。作为一个普遍的经验法则，查询越通用，用户越有可能仅仅是在浏览。更具体的查询——特别是当它们提到特定的商品名称时——通常表示购买意图或寻找某个已知商品的愿望。

“sale”查询表明用户正在寻找有折扣的商品，这会触发一些特别实现的过滤器或重定向到特定的促销页面。查询“refrigerators”表明用户想浏览特定类别的产品文档。最后，“pay my bill”查询表明用户希望采取某个行动——对这个查询最好的响应不是一组搜索结果甚至是一个答案，而是重定向到应用程序中的账单审核和支付部分。

这些查询每一个都包含一个超越简单关键词匹配的意图。无论这个意图是重定向到特定页面、应用特定过滤器、浏览或购买商品，还是采取领域特定的行动，关键是，用户表达目标的方式在搜索引擎中具有领域特定的细微差别。通常，自动推导这些领域特定的用户意图是困难的。企业通常会实施特定的业务规则来处理这些一次性的请求。当然，也可以构建查询意图分类器来处理这个问题的子集，但当构建自然语言查询解析功能时，成功地解析每一个可能的查询意图依然是一个挑战。

2.6 内容 + 信号：推动AI驱动搜索的燃料

在第一章中，我们介绍了反射智能的概念——利用反馈循环不断从内容和用户互动中学习。本章完全聚焦于理解嵌入在内容中的意义和智能，但同样重要的是要认识到，我们将在文档中的“非结构化数据”上应用的许多技术，也可以同样容易地应用于用户行为信号。例如，在第2.3节中，我们讨论了如何通过查找短语在语料库中最常出现的其他短语来推导短语的意义。我们注意到，“机器学习”更常与“数据科学家”和“软件工程师”一起出现，而不是与“会计师”、“食品服务人员”或“药剂师”一起出现。

如果将分布假设抽象到文档之外，并应用于用户行为，你可能会预期，查询你的搜索引擎的相似用户可能会表现出相似的查询行为。具体来说，数据科学家或者正在搜索数据科学家的用户，更有可能同时搜索或与关于机器学习的文档互动，而食品服务人员或会计师搜索机器学习内容的可能性要远低于软件工程师的可能性。因此，我们可以将这些相同的技术应用于从查询日志中学习相关术语和术语序列，在这种情况下，我们不是将术语和术语序列映射到文档中的字段，而是将查询中的术语和搜索结果中的点击映射到用户会话，然后映射到用户。我们将在第6章中使用这种方法，从用户查询日志中学习相关术语、同义词和拼写错误。

一些搜索应用内容丰富，但用户信号非常少。其他搜索应用拥有大量信号，但内容很少，或者内容在自动学习方面存在挑战。在理想情况下，你将拥有极好的内容和大量的用户信号，从中学习，这使你能够将两者的优点结合到一个更智能的AI驱动搜索应用中。无论你处于哪种情况，请记住，你的内容和用户信号都可以作为推动学习算法的燃料，你应该尽力最大化每个方面的收集和质量。

关于自然语言理解的最后一点：随着大型语言模型（LLMs）的崛起，这些深度神经网络是在大量人类知识（大部分互联网内容以及精选来源）上进行训练的，我们现在能够以前所未有的质量水平来解读常识问题的意义和意图。LLM在处理领域特定理解时通常表现较差，至少对于它们训练集之外的信息是这样，但通过在领域特定数据上微调LLM，这些模型通常可以迅速适应更封闭的领域数据。LLM代表了我们在学习自然语言的细微差别、根据这些细微差别解读任意文档和查询以及推动更相关搜索方面的巨大进步。

尽管LLM通常是大规模自然语言理解中最令人印象深刻的技术，但它们远不是我们AI驱动搜索工具箱中的唯一强大工具。我们将在第9章、第13章、第14章和第15章深入探讨如何将LLM应用于搜索。与此同时，我们还有许多其他关键算法和技术需要探索，涉及自然语言和领域理解、解析用户行为以及学习最佳的相关性排名模型。

现在，既然我们已经覆盖了开始从自然语言内容中提取意义所需的所有背景知识，是时候卷起袖子，动手实践了。在下一章中，我们将通过大量示例深入探讨如何在AI驱动的搜索应用中探索基于内容的相关性。

总结

• 非结构化数据是一个误用的术语——它更像是超结构化数据，因为它代表了一个巨大的领域特定知识图谱。

• 搜索引擎可以利用分布式语义学——根据分布假设解释术语和短语之间的语义关系——来在字符序列、术语、术语序列（通常是短语）、字段、文档、文档集和整个语料库的层面上利用丰富的语义意义。

• 分布式语义学方法使我们能够从更大的周围上下文中学习查询和内容的细微含义。

• 嵌入（Embeddings）是一种强大的技术，通过基于文本（及其他数据模态）的语义意义，而非仅仅依赖于特定关键词的存在与出现次数，来进行搜索结果排名。

• 领域特定知识通常通过替代标签、同义词列表、分类法、本体和知识图谱的组合来建模。知识图谱通常将其他方法的输出模型化为一个特定领域的统一知识表示。

• 多义性（歧义术语）、上下文、个性化和查询特定的自然语言处理方法是自然语言搜索中的一些有趣挑战。

• 内容和用户信号都是我们AI驱动的搜索应用在解决自然语言挑战时使用的重要燃料。

[1] John Rupert Firth, “A synopsis of linguistic theory, 1930–1955,” in J.R. Firth et al., Studies in Linguistic Analysis, Special Volume of the Philological Society (Oxford University Press, 1957).