本章涵盖

揭示非结构化数据中的隐藏结构以搜索为中心的语言和自然语言理解理念探索分布语义和词嵌入对特定领域的知识进行建模应对自然语言理解和查询解释方面的挑战将自然语言学习技术应用于内容和信号

在第一章中，我们提供了构建人工智能搜索系统意味着什么的高级概述。在本书的其余部分，我们将探索和演示您的搜索应用程序可以从您的内容和用户行为信号中不断学习的多种方式，以便更好地了解您的内容、用户和您的域，并最终为用户提供他们需要的答案。我们将在第三章中获得更多实践，启动搜索服务器（Apache Solr），数据处理层（Apache Spark），并从第一个Jupyter笔记本开始，我们将在整本书中使用它来演练许多分步示例。

然而，在我们深入研究这些动手示例和具体实现（“什么”）之前，在本章中，重要的是我们首先为我们试图解决的更高层次的问题建立一个共享的心智模型。具体来说，当涉及到智能搜索时，我们必须处理自然语言中的许多复杂性和细微差别 - 无论是在我们搜索的内容中还是在用户的搜索查询中。我们必须处理关键字、实体、概念、拼写错误、同义词、首字母缩略词、歧义术语、概念之间的显式和隐含关系、分类法中常见的层次结构关系、本体中常见的高级关系，以及通常在高级知识图谱中找到的实体关系的特定实例。

虽然可能很容易立即深入研究一些特定问题，例如如何自动从内容中学习拼写错误或如何从挖掘用户搜索会话中发现同义词，但首先建立一个概念基础来解释我们在搜索和自然语言理解中必须处理的问题类型会更加谨慎。建立这一哲学基础将使我们能够在人工智能驱动的搜索系统中构建更好的端到端解决方案，其中所有部分都以有凝聚力和集成的方式协同工作。因此，本章将为我们如何在本书中解决自然语言理解问题提供哲学基础，并应用这些解决方案使我们的搜索应用程序更加智能。我们将首先讨论一些关于自由文本和其他非结构化数据源性质的常见误解。

2.1 非结构化数据的神话

术语“非结构化数据”多年来一直用于描述文本数据，因为它似乎没有以易于解释和查询的方式格式化。然而，人们普遍认为文本或任何其他不符合预定义模式（“结构”）的数据实际上是“非结构化的”，这是一个神话，我们将在本节中花时间重新考虑。

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

然而，短语“非结构化数据”确实是一个描述文本内容的糟糕术语。实际上，文本中存在的术语和短语编码了大量的含义，并且应用于文本以赋予其意义的语言规则充当它们自己的结构。调用非结构化文本有点像将收音机上播放的歌曲称为“任意音频波”。尽管每首歌曲都有独特的特征，但大多数歌曲通常表现出共同的属性（节奏、旋律、和声、歌词等）。尽管这些属性可能因歌曲而异或缺失，但它们符合共同的期望，从而使每首歌曲能够传达和提取意义。文本信息通常遵循类似的规则 - 句子结构、语法、标点符号、词性之间的交互等。图 2.1 显示了一个文本示例，我们将在接下来的部分中进一步探讨该文本，因为我们进一步研究此结构。

图 2.1.非结构化数据。此文本表示您可能在搜索引擎中找到的典型非结构化数据

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

2.1.1 非结构化数据类型

自由文本内容被认为是非结构化数据的主要类型，但搜索引擎也常用于索引许多其他类型的数据，这些数据同样不适合结构化数据库。常见示例包括图像、音频、视频和事件日志。图 2.2 扩展了图 2.1 中的文本示例，包括几种其他类型的非结构化数据，例如音频、图像和视频。

图 2.2.多种类型的非结构化数据。除了上一个示例中的文本外，我们现在还看到图像、音频和视频

音频与文本内容最相似，因为它通常只是对单词和句子进行编码的另一种方式。当然，音频可以包含的不仅仅是口语，还可以包括音乐和非语言声音，并且可以更有效地编码细微差别，例如情感，语气以及同时重叠的交流。

图像是另一种非结构化数据。正如单词形成句子和段落来表达想法一样，图像形成颜色网格，这些颜色一起形成图片。

因此，视频是另一种非结构化数据，因为它是随时间推移的多个图像的组合，以及与图像进展相吻合的可选音频。

通常，非结构化数据可能会与结构化数据混合在一起，我们通常将其称为“半结构化”数据。日志数据是此类半结构化数据的一个很好的例子。通常日志最终是半结构化的，例如，具有事件日期、事件类型（例如警告与错误或搜索与单击）以及某种日志消息或自由文本描述。

从技术上讲，几乎任何类型的文件都可以被视为非结构化数据，但我们将在本书中主要处理上述类型。

搜索引擎通常负责处理每一种非结构化数据，因此我们将在整本书中讨论处理它们的策略。

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

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

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

一般来说，当想要将不同的行关联在一起或将它们与其他数据库表中的行相关联时，将对离散值执行“连接”。联接利用共享值（通常是 ID 字段）将两条或多条记录链接在一起，以形成将每条记录关联在一起的复合记录。

例如，如果某人有两个数据表，一个表示“员工”，另一个表示“公司”，则“公司”表上可能会有一个“ID”列，员工表上可能会有一个相应的“公司”列。雇员表上的公司字段称为外键，它是在两个表之间共享的值，用于根据共享标识符将记录链接在一起。图 2.3 演示了此示例，显示了离散值、连续值和使用外键跨表的连接的示例。

图 2.3.典型数据库中的结构化数据

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

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

虽然数据库中的结构化数据已经是一种易于查询的形式，但现实情况是，非结构化数据较少受到缺乏结构的影响，而更多的是将大量信息打包到非常灵活的结构中。在本节中，我们将通过一个具体示例来揭示非结构化数据中的这种隐藏结构，并演示如何类似地利用它来查找和联接文档之间的关系。

非结构化数据中的外键

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

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

图 2.4.非结构化数据中的外键

第一个实例指示正在发言的会议，而第二个文本块包含有关该事件的一般信息。出于示例的目的，假设每条信息（文本块、图像、视频和音频剪辑）在我们的搜索引擎中都表示为一个单独的文档。因此，在数据库表中有两行，每行都包含一列值为“激活”，而在我们的搜索引擎中具有单独的文档，每个文档都包含“激活”的值，两者在功能上几乎没有区别。在这两种情况下，我们都可以将这些文档视为由外键相关。

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

然而，对于非结构化数据，我们比传统的结构化数据建模拥有更大的功能。例如，在图 2.5 中，请注意，现在链接了两个文档，它们都提到了我 - 一个使用我的全名“Trey Grainger”，另一个只是使用我的名字“Trey”。

图 2.5.模糊外键。在此示例中，使用不同的术语序列引用同一实体

这是实体解析的一个示例，其中实体有两种不同的表示形式，但它们仍然可以解析为相同的含义，因此仍可用于联接两个文档之间的信息。您可以将其视为“模糊外键”，因为它仍然是外键，但不是严格的标记匹配意义上的，因为它需要额外的自然语言处理和实体解析技术才能解析。

当然，一旦我们为实体解析打开了高级文本处理的大门，现在我们可以从非结构化信息中学到更多。

例如，不仅这些文档中的名称和引用同一实体，而且单词 和 也引用，如图 2.6 所示。

图 2.6.模糊外键。在此示例中，视频中的专有名词、代词、图像和引用

您还会注意到，在图 2.6 中，我的图像（在左下角，以防您不知道我长什么样）和包含对我名字的引用的视频都被标识为相关并连接回文本引用。我们基本上依赖于所有这些非结构化信息中存在的隐藏结构来理解含义，将文档关联在一起，并更多地了解这些文档中每个引用的实体。

处理含糊不清的术语

到目前为止，一切顺利，但在现实世界的内容中，假设多个地方的相同术语具有相同的含义，甚至我们的实体解析总是正确解析实体并不总是合适的。具有多个潜在含义的单词和短语的相同拼写问题称为多义词，处理这些歧义术语在搜索应用程序中可能是一个巨大的问题。

您可能已经注意到前面图的右上角有一个奇怪的图像，在我们的示例中似乎有点不合适。这张照片是一个相当可怕的男人拿着砍刀。显然，如果你去谷歌搜索，这个图像回来了。如果你进一步挖掘，你会在图 2.7 中看到有一个 Twitter 用户也叫 ，这张图片是他的个人资料图片。

图 2.7.多义性。这张图片显示了谷歌搜索短语“Trey Grainger”。返回多个不同人的图片

这张照片显然是罗伯特·肖（他在 1975 年的电影《大白鲨》中扮演昆特）的，但这绝对不是您希望人们在网上搜索您时首先遇到的那种东西！

这里有两个关键的教训可以带走。首先，永远不要谷歌自己（你可能会对你发现的东西感到害怕！其次，更严重的是，多义词是搜索和自然语言理解中的一个主要问题。假设一个术语具有单一的含义，甚至是在不同上下文中具有一致的含义是不安全的，重要的是我们的人工智能搜索引擎能够利用上下文来区分这些不同的含义。

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

在前面的部分中，我们已经看到非结构化数据不仅包含丰富的信息（实体及其关系），而且还可以通过将它们连接到共享实体来将不同的文档关联在一起，类似于外键在传统数据库中的工作方式。然而，典型的非结构化数据包含如此多的这种关系，因此，我们将在本节中探讨的那样，将数据集合视为一个巨大的关系图可能更有用，而不是从行和列的角度来思考。

在这一点上，应该清楚的是，隐藏在非结构化数据中的结构比大多数人想象的要多得多。非结构化信息实际上更像是“超结构化”信息——它是一个比典型的“结构化数据”包含更多结构的图形。

图 2.8.巨大的关系图。即使只是几个相关的文档，也会出现一个丰富的关系图

图 2.8 展示了这个巨大的关系图，即使是我们示例中的少数文档中也存在这种关系图。您可以查看名称、日期、事件、位置、人员、公司和其他实体，还可以利用跨文档的实体之间的联接来推断它们之间的关系。您还会注意到图像已正确消除歧义，因此砍刀家伙现在与图形断开连接。

如果所有这些都可以从几个文档中学到，想象一下可以从你自己的搜索引擎中的数千、数百万或数十亿个文档中学到什么。

人工智能搜索平台的一部分是能够从您的数据中学习这样的见解。问题是，你如何利用这个庞大的语义知识图来驱动这种智能？

幸运的是，搜索引擎中倒排索引的固有结构使得遍历此图变得非常容易，而无需任何额外的显式数据建模。我们将在第 5 章中深入探讨如何利用隐藏在数据中的语义知识图。

2.2 自然语言的结构

在上一节中，我们讨论了文本和非结构化数据通常如何包含一个巨大的关系图，该关系图可以通过查看不同记录之间的共享术语来得出。如果您已经构建搜索引擎一段时间了，那么您习惯于根据这些字段中的“文档”、“字段”和“术语”来考虑您的内容。但是，在解释内容的语义时，还需要考虑几个级别。

图 2.9.编码为自由文本内容的语义数据

图 2.9 介绍了这些额外的语义含义级别。在最基本的层面上，您有字符，它们是单个字母、数字或符号，例如图中的字母“e”。然后将一个或多个字符组合在一起以形成字符序列，例如“e”，“en”，“eng”，...“工程师”，“工程师”。某些字符序列形成术语，这些术语是具有可识别含义的完整单词或标记，例如“工程师”、“工程师”、“工程”或“软件”。然后可以将一个或多个术语组合在一起形成术语序列 - 当术语都是连续的时，通常称为“短语”。其中包括“软件工程师”、“软件工程师”和“高级软件工程师”。为了简单起见，在本书中，我们还将单个术语视为“术语序列”，因此每当我们提到“短语”时，这也包括单术语短语。

术语序列与短语

您可能会查看这些定义，并想知道“术语序列”和“短语”之间的区别是什么。很简单，短语是一个术语序列，其中所有术语都按顺序出现。例如，“首席执行官”既是一个短语又是一个术语序列，而“首席官员”~2（意思是“首席”两个位置内的“官员”或编辑距离）只是一个术语序列，因为它指定了一个不一定是连续的术语序列。在绝大多数情况下，您只会处理连续的术语序列，因此，为了简单起见，我们将在整本书中主要使用“短语”一词，包括单个和多个术语的顺序术语序列。

当然，我们知道多个术语序列一起可以形成句子，多个句子可以形成段落，然后段落可以汇总成更大的文本组。但是，出于搜索引擎的目的，我们通常关注上述术语序列的下一个分组级别只是一个字段。可以使用文本分析器以多种方式分析文本字段，其中通常包括拆分空格和标点符号、将所有术语小写以使其不区分大小写、去除干扰（停用词和某些字符）、词干提取或词形还原以将术语简化为基本形式以及删除重音等技术。如果您不熟悉文本分析过程，或者您想复习一下，我建议您查看Solr in Action的第6章。

然后将一个或多个字段组合成一个文档，多个文档形成一个语料库或数据集合。每当针对搜索索引执行查询时，它都会将语料库筛选为文档集，文档集是专门关联相关查询的语料库的子集。

这些语言级别中的每一个 - 字符序列、术语、术语序列、字段、文档、文档集和语料库，都为理解您的内容及其在特定领域内的独特含义提供了独特的见解。

2.3 分布语义和词嵌入

分布语义学是自然语言处理领域的一个研究领域，它侧重于基于分布假设的术语和短语之间的语义关系。分布假说是，在相似上下文中出现的单词往往具有相似的含义。流行的话很好地总结了它：“你应该知道它所保留的公司的一个词”。[1]

提示

“你一定知道它所保留的公司一句话。”

-约翰·鲁珀特·弗斯

当将机器学习方法应用于文本时，这些分布语义变得越来越重要，搜索引擎使得为语料库中存在的任何语言表示派生上下文变得非常容易。例如，如果要查找有关 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 美元的房子，面积为 1000 平方英尺，还有 2 间卧室，这可以表示为 向量 .这些属性（价格、大小和卧室数量）通常称为维度，特定的维度集合称为向量空间。如果可以在向量空间的维度内为任何其他项目（如其他房屋、公寓或住宅）赋值，则可以在同一向量空间中表示任何其他项目。如果我们考虑同一向量空间内的其他向量（例如，一个房子和另一个房子，我们可以对向量执行数学运算来学习趋势并比较向量。例如，您可以直观地查看这三个向量，并确定“房价随着房间数量的增加而增加”或“房间数量随着房屋面积的增加而增加”。我们还可以对向量执行相似性计算，以确定，例如，120，000 平方英尺和 1400 间卧室的 3，100 美元房屋与 000，1000 平方英尺和 2 间卧室的 1，000 美元房屋更相似，而不是 000，9850，12 美元的房屋，<> 平方英尺和 <> 间卧室。如果您以前没有使用过这样的向量，或者需要快速复习数学，我们提供了附录 B，以确保您快速熟悉这些概念。在你阅读本书的过程中，向量运算的基本理解将非常重要。pricesizenumber of bedrooms[100000, 1000, 2][1000000, 9850, 12][120000, 1400, 3]

近年来，分布假说已被应用于通过所谓的词嵌入来创建术语和术语序列的语义理解。词嵌入是一个数字向量（通常是浮点数列表），旨在表示给定术语序列（通常是单词或短语）的语义含义。例如，术语序列被编码为一个缩小维向量，该向量可以与语料库中所有其他词嵌入的向量进行比较，以便找到语义最相关的文档。

为了理解这个过程，考虑搜索引擎如何开箱即用可能是有用的。假设每个术语都有一个向量，其中包含语料库中每个单词的值（维度）。它可能类似于图 2.10。

图 2.10.倒排索引中每项具有一维的向量

图 2.10 演示了默认情况下，文档匹配和相似性评分在大多数搜索引擎中通常如何工作。对于每个查询，都存在一个向量，其中包含倒排索引中每个术语的维度。如果查询中存在该术语，则该维度的向量中的值为“1”，如果查询中不存在该值，则该维度的值为“0”。倒排索引中的每个文档都存在类似的向量，“1”值表示文档中出现的索引中的任何术语，而所有其他术语则为零。

执行查询时，将在索引中对任何匹配的术语进行精确查找（文本后分析），然后根据查询的向量与相对于查询进行评分的文档的向量的比较来计算相似性分数。我们将在第 3 章中进一步介绍具体的评分计算，但现在这种高层次的理解就足够了。

这种方法有明显的缺点。虽然它非常适合查找具有精确关键字匹配的文档，但当您想要查找“相关”内容时会发生什么？例如，您会在图 2.10 中注意到术语“soda”出现在查询中，但从未出现在索引中。即使有其他种类的饮料（苹果汁、水、卡布奇诺和拿铁），搜索引擎也总是返回零结果，因为它不明白用户正在搜索饮料。同样，您会注意到，即使索引中存在术语咖啡因，对“拿铁”、“卡布奇诺”和“绿茶”的查询也永远不会与术语咖啡因匹配，即使它们是相关的。

由于这些原因，现在通常的做法是使用称为词嵌入的东西来为索引和查询中的术语序列建模语义。术语的词嵌入是特征向量，它表示术语在语义空间中的概念含义。图 2.11 演示了现在映射到可用作词嵌入的降维向量的项。

图 2.11.具有缩小维度的词嵌入。在这种情况下，现在存在更高级别的维度

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

图 2.12.词嵌入之间的相似性

如图 2.12 所示，由于每个术语序列现在都编码为一个向量，该向量根据更高级别的特征表示其含义，因此该向量（或词嵌入）现在可用于对该术语序列与任何其他类似向量的相似性进行评分。您将在图底部看到三个向量相似性列表：一个用于“绿茶”，一个用于“奶酪披萨”，一个用于“甜甜圈”。

通过比较“绿茶”与所有其他术语序列的向量相似性，我们发现最相关的项目是“水”、“卡布奇诺”、“拿铁”、“苹果汁”和“苏打水”，最不相关的是“甜甜圈”。这很直观，因为“绿茶”与列表中较高的项目共享更多属性。对于“奶酪披萨”向量，我们看到最相似的其他单词嵌入是“奶酪面包棒”，“肉桂面包棒”和“甜甜圈”，“水”位于列表的底部。最后，对于查询“甜甜圈”，我们发现顶部项目是“肉桂面包棒”、“奶酪面包棒”和“奶酪披萨”，其中“水”再次位于列表底部。这些结果在查找与我们的原始查询最相似的项目方面做得很好。

值得注意的是，此向量评分仅用于计算项目之间的相似性。在您的搜索引擎中，通常有一个两阶段的过程，您首先执行关键字搜索，然后对生成的文档进行评分。除非您要跳过第一步并相对于查询向量对所有文档进行评分（这可能是时间和处理密集型的），否则您仍然需要初始关键字或文档集筛选的某种组合。我们将在第 13 章中深入探讨这些成功实现词嵌入和向量搜索的机制。

我们讨论过的这些更高级别的属性向量可能表示查询中的其他术语序列，或者它们可能是文档中的术语序列，甚至可以是整个文档。将术语和术语序列编码为单词嵌入是很常见的，但句子嵌入（为整个句子编码向量）、段落嵌入（为整个段落编码向量）和文档嵌入（为整个文档编码向量）也是常用技术。维度本身比我们这里的例子更抽象也是很常见的。例如，可以应用深度学习模型，从字符序列中提取看似单一的特征，以及文档在语料库中聚集在一起的方式。我们无法在嵌入向量中轻松标记这些维度，但只要它提高了模型的预测能力以增加相关性，这对大多数搜索团队来说通常不是一个大问题。

最终，结合多个模型来利用分布语义和词嵌入的力量往往会产生最佳结果，我们将在本书的其余部分进一步探讨许多基于图和向量的方法，以利用这些技术。

[1] 约翰·鲁珀特·弗斯 （1957）.“语言理论概要1930-1955。”在语言学会特刊中。牛津：牛津大学出版社。

2.4 特定领域知识的建模

在第1章中，我们讨论了搜索智能进展（参见图1.9），即组织从基本的关键字搜索开始，并在最终实现完全的自学系统之前，经历了几个额外的改进阶段。搜索智能进展的第二阶段是构建分类法和本体，第三阶段（“查询意图”）包括知识图谱的构建和使用。不幸的是，业内从业者有时会对“本体论”、“分类学”、“同义词列表”、“知识图谱”、“替代标签”等关键术语的正确定义和使用产生重大混淆，因此，我们提供一些定义供本书使用，以防止任何歧义。具体来说，我们将列出“知识图谱”、“本体”、“分类”、“同义词”和“替代标签”等关键术语的定义。图 2.13 显示了它们如何关联的高级图。

图 2.13.特定领域知识建模的水平。知识图谱扩展了本体，本体扩展了分类法

我们定义这些知识建模技术中的每一种如下：

替代标签（或替代标签）：替换具有相同含义的术语序列。

Examples: CTO => Chief Technology Officer specialise => specialize同义词：替换可用于表示相同或非常相似的事物的术语序列。

Examples: human => homo sapiens, mankind food => sustenance, meal分类法：将事物分类为类别。

Examples: human is mammal mammal is animal本体论：事物类型之间关系的映射

Examples: animal eats food human is animal知识图谱：本体的实例化，也包含相关的事物

Examples: John is human John eats food

创建替代标签是这些技术中最直接理解的。首字母缩略词（RN =>注册护士）几乎总是用作替代标签，拼写错误和替代拼写也是如此。有时，将这些映射存储在单独的列表中很有用，特别是如果您使用算法来确定它们，并且您希望允许人工修改它们和/或计划稍后重新运行算法。

同义词是下一个最常见的技术，因为几乎每个搜索引擎都会有一些同义词列表的实现。备用标签是同义词列表的子集，是最明显的同义词类型。大多数人认为“高度相关”的术语序列也是同义词。例如，“软件工程师”和“软件开发人员”通常被认为是同义词，因为它们通常可以互换使用，即使两者之间在含义上有一些细微差别。有时，您甚至会看到语言之间的单词翻译以双语搜索用例的同义词显示。

替代标签和更通用的同义词之间的一个主要区别是，替代标签可以被视为原始标签的“替换”术语，而同义词更常用作“扩展”术语，与原始标签一起添加。实现可能差异很大，但这最终归结为您是否确信两个术语序列具有完全相同的含义（并希望对其进行规范化），或者您是否只是尝试包含其他相关术语序列，以免错过其他相关结果。

分类法是同义词的下一步。分类法不太关注替换词或扩展词，而是侧重于将内容分类到层次结构中。分类信息通常用于驱动网站导航、更改搜索结果子集的行为（例如，根据父产品类别显示不同的分面或筛选选项），或基于查询映射到的类别应用动态筛选。例如，如果有人在家装网站上搜索“范围”，该网站可能会自动过滤到“电器”，以消除其他产品在其产品描述中包含“属于范围”等短语的噪音。然后，同义词作为指向分类中特定项的指针映射到分类中。

分类法倾向于指定类别之间的父子关系，然后将事物映射到这些类别中，而本体提供了定义域内事物（术语序列、实体）之间更丰富的关系的能力。本体通常定义更抽象的关系，试图对域中各种事物之间的关系进行建模 - 例如，“员工向老板报告”，“CMO的老板是CEO”，“CMO是员工”。这使得本体对于从已知事实中获取新信息非常有用，方法是将事实映射到本体中，然后根据本体中可以应用于这些事实的关系得出逻辑结论。

知识图谱是知识管理领域的新手。本体定义了适用于事物类型的高级关系，而知识图谱往往是本体的完整实例化，其中还包括属于这些类型的每个特定实体。使用我们前面的本体示例，知识图谱中还会有“Michael 是 CMO”、“Michael 向 Marcia 报告”和“Marcia 是 CEO”作为关系。在知识图谱出现之前，将这些更详细的关系建模到本体中是很常见的，今天许多人仍然这样做。因此，您经常会看到术语知识图谱和本体可以互换使用，尽管随着时间的推移，这变得越来越不常见。

在本书中，我们将主要将讨论重点放在替代标签、同义词和知识图谱上，因为分类法和本体大多被归入知识图谱中。

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

在最后几节中，我们讨论了嵌入在非结构化数据和文本中的丰富含义图，以及如何利用分布语义和单词嵌入来派生和评分查询和文档中术语序列之间的语义关系。我们还介绍了知识建模的关键技术，并定义了我们将在本书中使用的关键术语。在本节中，我们将讨论与自然语言理解相关的一些关键挑战，我们将在接下来的章节中寻求克服这些挑战。

2.5.1 歧义的挑战（多义词）

在第 2.1.3 节中，我们引入了多义词或歧义术语的概念。在那一节中，我们处理的是一张标有“Trey Grainger”的图片，但它指的是与本书作者不同的人。然而，在文本数据中，我们也有同样的问题，它可能会变得非常混乱。

考虑一个像“司机”这样的词。驾驶员可以广义地指“车辆驾驶员”，一种用于从发球台上击球的高尔夫球杆，使硬件设备能够工作的软件，一种工具（螺丝刀）或推动某事前进的动力（“成功的关键驱动力”）。显然，这个词有很多潜在的含义，但实际上你可以潜入并探索许多更精细的含义。例如，在“车辆司机”类别中，它可能意味着出租车司机、优步司机或 Lyft 司机，也可能意味着专业卡车司机，如 CDL 司机（持有商业驾驶执照的人），也可能意味着公共汽车司机。在公交车司机的子集中，它可能意味着校车司机、公共城市公交车的司机、旅游巴士的司机等。该列表至少可以继续细分为数十个其他类别。

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

提示

每个术语都具有独特的含义，该含义基于其使用的特定上下文。

支持无限数量的潜在含义通常并不实用，尽管我们将在第5章中讨论用语义知识图来近似这一点的技术。然而，无论你是支持每个短语的多种含义还是只支持几个含义，重要的是要认识到能够为用户可能遇到的任何给定短语生成准确（通常是细微差别）的解释的明确需求。

2.5.2 理解上下文的挑战

我想说的是，你遇到的每个术语（单词或短语）都是一个“与上下文相关的意义集群，标签模糊”。

提示

每个单词或短语都是“具有模糊标签的上下文相关含义集群”

也就是说，有一个标签（术语的文本表示）被应用于某个概念（意义集群），这取决于它被发现的上下文。根据此定义，如果不了解找到术语的上下文，就不可能解释该术语，因此，创建无法考虑上下文的固定同义词列表可能会为用户创建次优搜索体验。

但是，正如我们在第 1 章中所讨论的，查询的上下文不仅包括搜索关键字和文档中的内容。它还包括对您的域的了解，以及对用户的理解。查询可以具有完全不同的含义，具体取决于您对用户的了解以及您可能拥有的任何特定于域的理解。此上下文对于检测和解决我们在上一节中讨论的歧义类型以及确保用户获得最智能的搜索体验是必需的。

在本书中，我们的重点将放在根据每个查询被使用的独特上下文自动学习每个查询的上下文解释的技术上。

2.5.3 个性化的挑战

仅仅因为上下文很重要并不意味着它总是很容易正确应用。始终有必要能够执行基本关键字搜索作为系统无法理解查询时的后备，并且几乎总是有用的预构建域理解，同样可以依赖这些域理解来帮助解释查询。然后，这种预先构建的域理解最终会覆盖一些默认的基于关键字的匹配行为（例如将单个关键字合并到短语中、注入同义词和更正拼写错误）。

但是，一旦您开始更好地了解您的用户，如何在预先存在的内容和特定于域的评分之上应用特定于用户的个性化并不总是很明显。例如，假设您了解到某个特定用户真的很喜欢苹果这个品牌，因为他们一直在搜索iPhone。这是否意味着苹果在搜索手表、电脑、电视流媒体盒、键盘、耳机和音乐播放器时也应该得到提升？可能是用户只喜欢Apple品牌的手机，并且通过在其他类别中提升品牌，您实际上可能会让用户感到沮丧。例如，即使用户之前确实搜索过iPhone，你怎么知道他们不只是试图将iPhone与他们正在考虑的其他手机进行比较？

在用户意图的所有维度中（图1.8），个性化是最容易绊倒的，因此它是现代人工智能驱动的搜索应用程序中最不常见的一个（当然，在推荐引擎之外）。我们将在第9章中详细解决这些问题，以重点介绍如何在推出个性化搜索体验时取得适当的平衡。

2.5.4 解释查询与文档的挑战

当工程师和数据科学家第一次开始使用搜索时，我看到的一个常见问题是倾向于将标准自然语言处理技术（如语言检测、词性检测、短语检测和情绪分析）应用于查询。所有这些技术都被设计为对较长的文本块进行操作 - 通常在文档，段落或至少句子级别。

文档往往更长，并为周围的文本提供更多的上下文，而在大多数用例中，查询往往很短（只有几个关键字），即使它们更长，它们也倾向于将多个想法组合在一起，而不是提供更多的语言上下文。

因此，在尝试解释查询时，需要尽可能多地利用外部上下文来解释查询。例如，您可以尝试在文档语料库中查找查询中的查询中的短语，以查找最常见的特定于域的解释，而不是使用通常依赖于句子结构来解释查询的自然语言处理库。同样，您可以通过挖掘用户行为信号，在以前的用户搜索会话中利用查询中术语的共存。这使您能够从类似的用户那里了解真正的意图，这对于在一致的基础上从标准自然语言处理库中准确派生是非常具有挑战性的。

简而言之，查询需要特殊的处理和解释，因为它们倾向于简短，并且通常暗示比明确声明的更多，因此充分利用以搜索为中心的数据科学方法来查询将产生比传统自然语言处理方法更好的结果。

2.5.5 解释查询意图的挑战

虽然分析查询以了解其包含的术语和短语的过程很重要，但查询背后通常有一个更高级别的意图 - 查询类型，如果你愿意的话。例如，让我们考虑以下查询之间的固有差异：

who is the CEO?supportiphone screen blacked outiphoneverizon silver iphone 8 plus 64GBsalerefrigeratorspay my bill

第一个问题“谁是CEO？”的目的显然是找到一个事实答案，而不是一份文件清单。“支持”的第二个查询是尝试导航到网站的支持部分，或以其他方式联系支持团队。“iphone屏幕黑屏”的第三个查询也是寻求支持，但它是针对特定问题的，并且该人可能希望在联系实际支持团队之前找到可能存在的故障排除页面来帮助解决该特定问题。

接下来的两个查询“iphone”和“verizon silver iphone 8 plus 64GB”非常有趣。虽然它们都是针对iPhone的，但第一次搜索是一般搜索，表明可能的浏览或产品研究意图，而第二个查询是第一次搜索的更具体的变体，表明用户确切地知道他们在寻找什么，并且可能更接近做出购买决定。因此，对“iphone”的一般查询可能最好返回一个提供iPhone和可用选项概述的登录页面，而更具体的查询可能最好直接转到产品页面，并立即提供购买按钮。作为一般经验法则，查询越笼统，用户浏览的可能性就越大，而更具体的查询（尤其是当他们按名称引用特定项目时）通常表示购买意图或查找特定已知项目的愿望。

“sale”查询表示用户正在寻找可以以折扣价购买的商品，这将调用一些专门实现的过滤器或重定向到正在进行的销售事件的特定登录页面。对“冰箱”的查询指示用户想要浏览特定类别的产品文档。最后，“支付我的帐单”查询指示用户想要执行操作 - 对此查询的最佳响应不是一组搜索结果，甚至不是答案，而是重定向到应用程序的帐单审核和付款部分。

这些查询中的每一个都包含一组要匹配的关键字之外的意图。无论意图是重定向到特定页面，应用特定过滤器，浏览或购买项目，甚至采取特定于域的操作，关键是用户如何向搜索引擎表达其目标存在特定于域的细微差别。通常，很难自动自动派生这些特定于域的用户意图。企业实施特定的业务规则以将这些作为一次性请求处理是相当常见的。当然可以构建查询意图分类器来处理此问题的子集，但在构建自然语言查询解释功能时，成功解释每个可能的查询意图仍然具有挑战性。

2.6 燃料驱动人工智能搜索

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

如果您将此想法抽象到文档之外和用户的行为之外，您可能还期望查询搜索引擎的用户可能会表现出类似的查询行为，这也符合分布假设。具体来说，数据科学家或正在搜索数据科学家的人更有可能搜索或与有关“机器学习”的文档进行交互，食品服务人员或会计师搜索机器学习内容的可能性远低于软件工程做同样的事情的可能性。因此，我们可以应用这些相同的技术从查询日志中学习相关的术语和术语序列，而不是考虑映射到文档中字段的术语和术语序列，而是考虑查询中的术语和搜索结果中的点击映射到用户会话，然后映射到用户会话。

一些搜索应用程序内容丰富，但用户信号很少。其他搜索应用程序将具有大量的信号，但内容很少，或者从自动化学习的角度来看，这些内容会带来挑战。在理想情况下，您有很棒的内容和大量的用户信号可供学习，这允许将两全其美的优势组合到更智能的 AI 驱动的搜索应用程序中。无论处于哪种方案，请记住，您的内容和用户信号都可以作为应用程序的燃料，您应该尽最大努力最大限度地提高每个内容的收集和收集质量。

现在我们已经介绍了开始从自然语言内容中提取含义所需的所有背景，是时候卷起袖子动手了。在下一章中，我们将深入探讨大量示例，因为我们开始探索 AI 驱动的搜索应用程序中基于内容的相关性。

2.7 小结

非结构化数据用词不当 - 它实际上更像是超结构化数据，因为它代表了特定领域知识的巨大图。搜索引擎可以利用分布语义 - 基于分布假设解释术语和短语之间的语义关系 - 在字符序列，术语，术语序列（通常是短语），字段，文档，文档集和整个语料库的级别利用丰富的语义含义。分布语义方法使我们能够从更大的周围环境中学习查询和内容的细微含义。单词嵌入是一种强大的技术，用于基于短语的语义进行建模和评分，而不仅仅是纯文本匹配统计信息。特定领域的知识通常通过替代标签、同义词列表、分类法、本体和知识图谱的组合来建模。知识图谱通常将其他每种方法的输出建模为特定领域的统一知识表示。多义词（歧义术语）、上下文、个性化和特定于查询的自然语言处理方法代表了自然语言搜索中一些更有趣的挑战。内容和用户信号都是我们人工智能驱动的搜索应用程序在解决自然语言挑战时可以利用的重要燃料。