使用 Elasticsearch 和 LLMs 进行实体解析，第 1 部分：为智能实体匹配做准备

了解什么是实体解析，以及如何为实体解析方程的两端做准备：你的监控列表和你想要搜索的文章。

Elasticsearch 原生集成了行业领先的 Gen AI 工具和提供商。查看我们的网络研讨会，了解如何超越 RAG 基础，或使用 Elastic 向量数据库构建可用于生产的应用。

为了为你的使用场景构建最佳的搜索解决方案，现在开始免费的云试用，或立即在你的本地机器上试用 Elastic。

"新的 Swift 更新已经发布！"

当你看到这个标题时，你会想到什么？对于一名开发者来说，这是一个行动号召，是时候深入研究 Swift 编程语言的新语法、并发模型和 bug 修复。对于一名音乐迷来说，这是一个完全不同的故事，意味着 Taylor Swift 刚刚发布了一张新专辑，或正在进行一次重要的公告。

你的大脑在极短的时间内完成了一项非凡的自然语言处理（ natural language processing - NLP ）能力。它不仅仅读取 " Swift " 这个单词，而是利用周围的上下文（标题的来源、你的个人兴趣等），将这个含糊的单词解析为一个唯一的、真实世界中的实体。

在 NLP 中，我们将这种对命名实体进行消歧的能力称为命名实体解析（named entity resolution - NER ），而人类一直在做这件事。自然语言本身就具有歧义，因此我们需要能够将像 " Bill Gates " 映射到 " Microsoft 的创始人 "，以及将 " The Eras Tour " 映射到 " Taylor Swift 的巡回演唱会 "。对人类来说，这些联系非常容易；但对计算机来说，却并非如此。想象一下，当一名 Swift 粉丝发现他们的智能助手推荐的文章实际上是关于编程的，那会是多么失望。

当你在监控新闻文章中是否提及特定人物或组织时，同样的挑战就变得至关重要。想象一下，你正在跟踪受制裁的实体，或监控对特定公司的提及。你的监控列表中有 " Sakura Shipping Group "，你想知道什么时候文章提到了这家公司。很简单，对吧？但如果文章使用的是 " Sakura Shipping " 而不是完整的法定名称，会发生什么？或者使用了像 " SSG " 这样的缩写？或者间接描述为 " 一家主要的日本海事物流公司 "？又或者用日语提到这家公司，比如 " さくら海運グループ "？你的简单文本匹配将无法找到这些提及，尽管它们都指向同一个组织。对于合规和风险监控用例来说，漏掉一次提及都可能带来严重后果。你需要捕获每一种变体、每一个别名、以及实体可能被提及的每一种方式。

这就是实体解析的问题：识别文本中不同的提及是否指向同一个真实世界中的实体，并确定具体是哪一个实体。为了解决这个问题，我们需要一个能够处理语义搜索（理解含义，而不仅仅是关键词）、命名实体识别（从文本中抽取实体），以及在数百万文档中进行快速、可扩展匹配的系统。这就是为什么我们在 Elasticsearch 上构建了这个原型。它提供了内置的语义搜索能力、集成的 NER 模型，以及实体解析所需的可扩展性。

在本系列中，我们展示了一个用于智能实体解析的教学型原型，该原型有意将检索与判断和解释分离。Elasticsearch 被用来通过结合关键词、别名和语义（混合）搜索，高效地缩小搜索空间。一旦识别出可能的实体候选项，就会使用大型语言模型（ LLM ）来判断候选项是否指向同一个真实世界实体，并以自然语言给出模型的判断依据。

这种职责划分避免将 LLMs 作为黑盒检索器来使用，保留了对敏感用例至关重要的可解释性，并展示了一种可复用的设计模式，用于构建透明、原生于 Elasticsearch 的系统。我们将分析为什么这种模式在实体解析中特别有效，因为歧义在这里很常见，而可解释性至关重要。目标不是提供一个可直接用于生产的解决方案，而是讲解构建透明实体解析 systems 背后的架构原则。

重要说明：本系列展示的是一个教学型原型，用于讲解使用 LLM 判断的 Elasticsearch 原生实体解析。为了便于学习，我们做了一些简化选择（例如使用 Wikipedia 进行实体丰富）。生产系统可能会使用不同的数据源、额外的验证步骤，或更复杂的丰富流水线。这里的目标是展示核心概念和架构，而不是提供一个可直接用于生产的系统。

本系列展示了在 100% Elasticsearch 原生架构下，我们如何帮助计算机建立这些必要的关联。我们将探索三项主要创新：

使用上下文信息增强实体。
使用全面的 NER 识别基础和复杂实体。
通过 Elasticsearch 候选匹配和 LLM 驱动的解释，提供透明的推理。

我们还将评估该系统，并识别一个能够提升该教学型原型整体性能的重要优化。

在这个由四部分组成的系列的第一篇文章中，我们将重点介绍如何准备实体解析方程的两端：你的监控列表以及你想要搜索的文章。

问题：为什么实体解析需要准备

实体解析很难，因为在匹配方程的两端都存在挑战。一方面，实体可以以许多不同的方式被提及。一家公司可能会被称为 " Microsoft "、" Microsoft Corporation "、" MSFT "，甚至在不同的上下文和写作风格下被描述为 " 总部位于雷德蒙德的科技巨头 "。另一方面，我们需要在文章中找到这些提及，即使它们并不明显。

为什么我们不能只直接匹配名称：如果没有适当的准备，匹配就会变得不可靠。你可能会想：" 但我可以直接在文本中搜索 ' Tim Cook '，对吗？"嗯，是的，如果文章总是用这个完全相同的名字来提及他。但如果写成 " Apple CEO " 呢？或者 " Timothy D. Cook "（他的全名）呢？你的简单文本搜索将无法找到这些提及，尽管它们都指向同一个人。

如果没有实体准备，我们无法将 " J.R.R. Tolkien " 匹配到 " John Ronald Reuel Tolkien "，因为我们不知道它们是同一个人的别名。我们无法将 " Apple CEO " 匹配到 " Tim Cook "，因为我们无法理解其中的语义关系。没有索引，寻找匹配意味着必须对监控列表中的每一个实体逐一检查。这无法扩展：当实体达到数千个时，每一次匹配都会变得缓慢且成本高昂。对于受制裁个人的监控来说，这意味着可能会漏掉使用别名或不同拼写的关键提及，而这种失败可能带来严重后果。

为什么我们不能只直接搜索文本：实体抽取之所以困难，原因与实体解析相同：实体可以以许多不同的方式被提及。同一个人可能会被称为 " J.R.R. Tolkien "、" The Lord of the Rings 的作者 "，或者仅仅是 " Tolkien "，这取决于上下文。如果没有适当的抽取，我们无法在文本中找到这些提及。我们将不得不手动识别每一个实体提及，这同样无法扩展。我们还会漏掉以非标准方式提及的实体（例如头衔或缩写）。同时，我们也无法捕获实体提及周围的上下文，而这些上下文对于准确匹配至关重要。

解决方案是一个两阶段的系统，用于同时准备你的监控列表以及你想要搜索的文章。

解决方案：两阶段准备系统

为了解决实体解析，我们需要准备匹配方程的两端。首先，我们丰富并索引我们的监控列表实体，以支持语义搜索。其次，我们使用混合技术从文章中抽取实体提及，捕获显性和隐性引用。这两个阶段共同为智能实体匹配奠定基础。

阶段 1：准备你的监控列表

准备实体的解决方案是为它们添加有意义的上下文。这使我们的实体匹配系统能够有效工作。我们稍后会解释上下文如何提供帮助，但首先让我们了解原型的简单实现。

我们的监控列表实体可能以多种格式提供。美国外国资产控制办公室（Office of Foreign Assets Control - OFAC ）提供的列表包括名字和姓氏、地址以及身份证明信息，如护照号、出生日期和地点，以及国籍信息 [1]。虽然这些提供了相当多的上下文，但在实践中，当给定实体的值未知时，许多字段会被省略。有些列表可能只是名称集合。对于我们的目的，最有用的列表通常是开箱即用且附带丰富描述的，就像商业或策划的数据集常见的情况。

原型中使用的三组件系统从管理实体并组织其元数据开始。由于实体列表包含的信息量可能不同，我们的原型设计为能够处理收到的任何数据。JSON 格式支持信息最少的实体（仅有名称和类型）或完整信息的实体（包括别名、描述、元数据等）。例如，一个实体可能简单到如下形式：

复制代码

{
  "name": "J.R.R. Tolkien",
  "entity_type": "person"
}

或者它可能包含额外的上下文：

复制代码

{
  "name": "J.R.R. Tolkien",
  "entity_type": "person",
  "description": "English writer and philologist, author of The Lord of the Rings",
  "aliases": ["John Ronald Reuel Tolkien", "J.R.R. Tolkien", "Tolkien"],
  "priority": "medium"
}

系统在丰富过程中能够优雅地处理这两种情况。对于原型，丰富过程为没有上下文的实体添加了来自 Wikipedia 的上下文（具体为实体 Wikipedia 页面的第一段）[2]。这些 Wikipedia 上下文有助于语义匹配，但不会添加其他字段，如别名或全名；这些必须来自原始数据集。（在生产环境中，你可能会使用其他方法进行丰富，包括一个 agentic system 来确定为给定实体获取上下文信息的来源。这超出了我们原型的范围，但这是一个我们未来可以添加的令人兴奋的功能。）最后，我们将实体索引到 Elasticsearch 中，并启用语义搜索能力，从而创建一个理解意义而不仅仅是文本的可搜索索引。

关键概念：语义搜索和索引

什么是语义搜索？语义指的是单词和短语的意义。理解意义对人类来说通常很容易，但对计算机来说就困难得多，因为它需要很深的理解能力，而这很难编程实现。语义搜索通过将这个挑战转化为数学问题来工作，这是计算机非常擅长的 [3]。

把语义搜索想象成意义的地图坐标。就像纬度和经度告诉你地图上某物的位置一样，语义嵌入告诉你某物在"意义空间"中的位置。传统关键词搜索需要精确匹配，而语义搜索依赖于在多维向量空间中描述那个"位置"。例如，你可能有一个特定的 " big red building " 的坐标。当你搜索 " small red building " 时，语义搜索会在向量空间的"邻域"中寻找相似概念。你的 big red building 可能会出现为最近邻，但相关性得分会较低，因为部分意义不匹配。

回到我们的例子，当你搜索 " Apple CEO " 时，语义搜索可以找到 " Tim Cook "，因为语义嵌入捕捉到了两者指向同一个人的意义，即使它们使用了完全不同的词。这种能力在监控受制裁的个人时非常宝贵，因为可能会使用别名或代号来规避检测。

为什么使用 Elasticsearch 进行实体索引？Elasticsearch 内置了使用嵌入模型（如 bidirEctional Encoder rEpresentations (E5) 的 EmbEddings）进行语义搜索的能力 [4]。这意味着我们可以创建一个理解意义而不仅仅是文本的索引。当我们索引丰富后的实体时，Elasticsearch 会创建捕捉每个实体意义的语义嵌入，从而在后续实现智能匹配。

什么是映射 schema？映射 schema 定义了我们在 Elasticsearch 中如何结构化实体数据。我们的 schema 包含多种字段类型，以优化不同的搜索策略，包括：

关键词字段（id、name.keyword、aliases.keyword）：用于实体名称和别名的精确匹配。
文本字段（name、name_lower、context、aliases）：用于传统的、大小写标准化的全文搜索，配合 BM25 评分。
语义文本字段（name_semantic、context_semantic）：用于基于向量的相似性搜索，使用 multilingual-e5-small 模型。

这种混合映射支持多种搜索策略：对精确名称进行精确匹配，对别名进行关键词搜索，以及对意义进行语义搜索。更棒的是，Elasticsearch 支持混合搜索，使我们能够同时使用关键词搜索和语义搜索。

关键概念：语义搜索和索引

什么是语义搜索？语义指的是单词和短语的意义。理解意义对人类来说通常很容易，但对计算机来说就困难得多，因为它需要很深的理解能力，而这很难编程实现。语义搜索通过将这个挑战转化为数学问题来工作，这是计算机非常擅长的 [3]。

把语义搜索想象成意义的地图坐标。就像纬度和经度告诉你地图上某物的位置一样，语义嵌入告诉你某物在 "意义空间" 中的位置。传统的关键词搜索需要精确匹配，而语义搜索依赖于在多维向量空间中描述那个 "位置"。例如，你可能有一个特定的 " big red building " 的坐标。当你搜索 " small red building " 时，语义搜索会在向量空间的"邻域"中寻找相似概念。你的 big red building 可能会出现为最近邻，但相关性得分会较低，因为部分意义不匹配。

**为什么使用 Elasticsearch 进行实体索引？**Elasticsearch 内置了使用嵌入模型（如 bidirEctional Encoder rEpresentations (E5) 的 EmbEddings）进行语义搜索的能力 [4]。这意味着我们可以创建一个理解意义而不仅仅是文本的索引。当我们索引丰富后的实体时，Elasticsearch 会创建捕捉每个实体意义的语义嵌入，从而在后续实现智能匹配。

**什么是映射 schema？**映射 schema 定义了我们在 Elasticsearch 中如何结构化实体数据。我们的 schema 包含多种字段类型，以优化不同的搜索策略，包括：

关键词字段（id、name.keyword、aliases.keyword）：用于实体名称和别名的精确匹配。
文本字段（name、name_lower、context、aliases）：用于传统的、大小写标准化的全文搜索，配合 BM25 评分。
语义文本字段（name_semantic、context_semantic）：用于基于向量的相似性搜索，使用 multilingual-e5-small 模型。

实体准备前后

在实体准备之前，你只有一个简单的列表，几乎没有上下文，可能仅有一个名字：" J.R.R. Tolkien "。仅此而已。你只能匹配完全相同的文本，这意味着你会漏掉 " John Ronald Reuel Tolkien "、" Tolkien " 以及任何其他变体。对于受制裁的个人，这意味着可能会漏掉使用别名或不同拼写的关键提及。

在实体准备之后，你拥有一个丰富的、可搜索的索引。

阶段 2：从文章中抽取实体

既然我们有了可搜索的监控列表，我们需要从文章中抽取实体提及。这就是文章处理的作用所在。

记住：这是一个教学型原型，用于讲解实体抽取概念。生产系统可能会使用不同的 NER 模型、自定义抽取规则，或针对特定领域或语言的专用抽取流水线。

我们使用混合 NER 方法从文章中抽取实体，将机器学习与基于模式的抽取结合。首先，我们处理文章以准备进行抽取。然后，我们使用混合抽取方法抽取实体，将 Elasticsearch 中执行的 NER（使用部署的 XLM-RoBERTa 模型）与基于模式的抽取结合，以捕获 NER 可能遗漏的实体。

这种混合抽取方法提供了多个好处。NER 可以自动在文本中找到实体提及，即使它们不明显。基于模式的抽取捕获 NER 可能遗漏的实体，如头衔和复合实体。我们保留每个实体提及周围的上下文，这有助于后续匹配决策。该方法可很好地扩展，使我们能够自动处理数千篇文章，而不仅仅是手动处理几篇。

关键概念：NER、基于模式的抽取和混合抽取方法

**什么是 NER？**命名实体识别是一种机器学习技术，用于识别文本中的命名实体。当我们在文章中运行 NER 时，它会找到像 " Microsoft "、" Seattle " 和 " Washington " 这样的提及，并将它们标注为组织、地点或人实体。

为什么在 Elasticsearch 中使用 NER？ 在 Elasticsearch 中使用 NER 保持了我们 100% Elasticsearch 原生架构，这简化了实体解析原型的设计。无需为实体抽取和搜索管理独立服务，所有操作都在一个系统中运行。你可以在文档摄取期间使用推理管道执行 NER，并且抽取的实体会立即可用于索引和搜索。这种统一的方法减少了复杂性，消除了服务间的网络调用，并简化了部署和管理。XLM-RoBERTa 模型经过训练，可以识别多种语言的实体，因此我们可以从不同语言的文章中抽取实体，而无需为每种语言使用独立模型。有关在 Elasticsearch 中部署 NER 模型的信息，请参见 Elasticsearch NER 文档。

**什么是基于模式的抽取？**基于模式的抽取使用规则和模式来找到 NER 可能遗漏的实体。例如，NER 可能无法将 " the author of The Lord of the Rings " 识别为实体提及，但基于模式的抽取可以捕获像 " the CEO " 或 " the President " 这样的头衔和角色。然而，基于模式的抽取是语言特定的。模式需要为你想支持的每种语言定义。这对于多语言系统来说是一个显著缺点，但对于我们的教学型原型是可以接受的，因为它专注于演示核心概念。生产系统可能会使用特定语言的模式集合或其他多语言支持方法。

**它们如何协同工作？**混合抽取方法结合了这两种技术。NER 找到明显的实体提及，如 " J.R.R. Tolkien "，而基于模式的抽取捕获 NER 可能遗漏的变体，例如 " the author of The Lord of the Rings "。两者结合，为文本中的实体提及提供全面覆盖。

当我们从一篇提到 " the author of The Lord of the Rings " 的文章中抽取实体时，我们得到：

文本： " author of The Lord of the Rings "
类型： PERSON（来自基于模式的抽取）
置信度： 0.85
上下文： " The author of The Lord of the Rings published a new edition "

实体抽取前后

仅使用 NER 抽取时，我们可能会在文章中找到 " J.R.R. Tolkien " 和 " The Lord of the Rings "，但会漏掉 " the author of The Lord of the Rings "，因为 NER 无法将描述性短语识别为实体提及。

使用混合抽取时，我们既能找到 " J.R.R. Tolkien "（来自 NER），又能找到 " the author of The Lord of the Rings "（来自基于模式的抽取）。这种全面覆盖在后续匹配中非常有用，因为我们可以将名字和描述性短语都匹配到我们的监控列表。

下一步：将实体匹配到我们的监控列表

现在我们已经准备好了实体解析方程的两端，我们拥有进行智能匹配所需的一切：

一个可搜索的监控列表，已丰富上下文并进行了语义搜索索引。
使用混合 NER 从文章中抽取的实体提及。

准备工作提供了原材料，但并不能告诉我们某个提及实际上指向哪个实体。在下一篇文章中，我们将探索如何使用语义搜索和 LLM 驱动的判断，将这些抽取的实体匹配到我们的监控列表，同时透明地处理歧义和上下文。

自己试试

想亲眼看看准备过程吗？查看这些 notebook 获取完整演示、详细解释和动手示例：

实体准备 notebook：展示如何使用 Wikipedia 上下文丰富实体，创建语义搜索索引，并为智能匹配准备你的监控列表。
文章处理 notebook：展示如何使用混合 NER 从文章中抽取实体，处理多语言内容，并处理复合实体。

记住：这是一个教学型原型，用于讲解概念。在构建生产系统时，需要考虑额外因素，如数据源可靠性、验证流水线、错误处理、监控、合规要求、特定领域的 NER 模型、自定义抽取规则以及学习型原型未涵盖的质量验证。

参考

原文：https://www.elastic.co/search-labs/blog/entity-resolution-llm-elasticsearch