作者：来自 Elastic Jessica Moszkowicz
在 Elasticsearch 中使用语义搜索和透明的 LLM 判断 进行实体解析。
Elasticsearch与行业领先的 Gen AI 工具和提供商具有原生集成。欢迎查看我们的网络研讨会，了解如何超越 RAG 基础，或使用 Elastic 向量数据库构建可用于生产的应用。
为了为你的使用场景构建最佳搜索解决方案，现在即可开始免费 cloud 试用，或立即在你的本地机器上试用 Elastic。
在第 1 部分中，我们准备了观察列表并提取了实体提及。现在，我们已准备好回答一个困难的问题：一个提及实际上指向哪个实体？让我们回到本系列第一篇博客中的示例，它说明了为什么我们需要实体解析：“The Swift update is here!” 想象一下，这个标题伴随着更多上下文：
- The new Swift update is here! Developers are eager to try out the new features.
- The new Swift update is here! The new album will drop next month.
有了这些额外的上下文，我们就应该能够将 “Swift” 解析为正确的实体。
在上一篇文章中，我们设置了观察列表，并为实体添加了额外的上下文。结合上面的示例，我们至少需要在列表中包含以下两个实体：Taylor Swift 和 Swift 编程语言。我们还介绍了如何从文本中提取实体提及。这两个示例都会提取 “Swift”。在这些要素就位之后，包括丰富后的观察列表和提取出的实体，我们终于可以介绍本文的主角：实体匹配。
请记住：这是一个教学用原型，旨在讲解实体匹配的概念。生产系统可能会使用不同的大语言模型（LLMs）、自定义匹配规则、专用判断流水线，或结合多种匹配策略的集成方法。
问题：为什么匹配很难
人类语言是一件了不起的事。它最有趣的特性之一是无尽的创造力。我们可以生成并理解无限数量的新句子。那么，在实体解析中精确匹配罕见也就不足为奇了吧？作者在可能的情况下会力求创造性。如果每次提及实体都必须写出和读出完整名称，那将非常乏味。因此，虽然精确匹配很容易，但现实是我们需要一种更复杂的实体解析方法：它必须足够稳健，以应对人类作者至少部分无尽的创造力。这就是为什么我们将问题分为两个步骤：使用 Elasticsearch 大规模检索可能的候选实体，然后使用 LLM 判断这些候选实体是否真正指向同一个真实世界的实体。
解决方案：三步匹配与透明的 LLM 判断
我们正处于计算使用方式的范式转变中。正如互联网的兴起将我们从本地计算带入全球互联网络一样，生成式 AI (GenAI) 正从根本上改变内容、代码和信息的创建方式。实际上，伴随本系列的教学原型几乎完全是通过 LLM 在作者精心提示下进行 “vibe 编码” 的。这并不意味着 LLM 已经或将达到人类语言固有的生产力，但这确实意味着我们现在拥有一个强大的资源来帮助进行实体解析。
我们在 GenAI 中常用的一个模式是倒数排序增强生成 (RAG)。这里的检索指的是检索实体候选（而非生成答案），LLM 则严格用于匹配评估和解释。虽然我们可以让 LLM 帮助完成端到端的实体解析，但这种方法在时间和成本上都很高。RAG 通过提供更高效的上下文给 LLM 帮助 LLM 高效完成实体解析。
对于 RAG 的检索部分，我们再次使用 Elasticsearch。我们首先使用精确匹配、别名匹配 和 混合搜索（结合 keyword 和 语义搜索）找到潜在匹配。一旦找到这些潜在匹配，我们将它们发送给 LLM 进行判断。LLM 充当最终匹配评估者。我们还让 LLM 解释其推理，这是与其他实体解析系统的重要区别。有了这些解释，实体解析不再是黑箱；我们可以亲自看到为什么匹配是合理的。
关键概念：三步匹配、混合搜索和透明的 LLM 判断
**什么是三步匹配？**在这个项目开始时，我们假设 semantic search 将是系统的关键部分，但并非每个匹配都需要如此复杂的搜索。为了高效地找到匹配，我们采用渐进式方法。首先，我们使用 keyword search 检查精确匹配。如果找到匹配，我们的工作就完成，可以继续下一步。如果精确匹配失败，我们转向别名匹配。在原型中，别名匹配也使用 keyword 的精确匹配，为了简化。在生产中，你可能会扩展这一步，使用规范化、音译规则、模糊匹配或精心维护的别名表。如果在前两步中仍未找到潜在匹配，那么就需要通过 Elasticsearch 的 hybrid search 和 倒数排序融合 (RRF) 引入 semantic search。
**什么是混合搜索？**在 Elasticsearch 中，我们可以使用 semantic search 找到考虑上下文的有意义匹配。Elasticsearch 被广泛用于向量搜索和混合检索。语义相似性 对理解意义很强，但它不能替代结构化过滤（例如按时间范围、位置 或 标识符），而且当存在精确匹配时，通常也不必要。Elasticsearch 以词汇搜索闻名，它非常适合语义搜索不适用的任务。为了充分利用两种方法，我们在单个 hybrid query 中同时使用词汇搜索和语义搜索，然后使用 RRF 合并结果，找到最可能的匹配。在原型中，前两个结果成为可以发送给 LLM 判断的潜在匹配。
**为什么使用 LLM 判断？**LLM 的判断和解释让我们的系统能够透明地处理歧义和上下文。这对于像 “the president” 这样的情况至关重要，它可能根据上下文指向多个实体，同时也使昵称和文化差异在系统中有效。最后，当我们考虑关键任务，如从制裁名单中识别实体时，我们需要知道为什么匹配被接受，以便信任系统。关键是，LLM 并不搜索整个语料库；它只评估 Elasticsearch 返回的小集合候选。
现实世界结果：使用 LLM 推理进行匹配
对于任何自然语言处理任务，一个主要挑战是创建黄金文档，即告诉我们预期结果的 “答案键”。没有它，几乎不可能判断系统在任务上的表现，但创建这样的文档可能是一个繁琐的过程。对于实体解析原型，我们再次使用 GenAI 来帮助设置可以用于测试的数据。
我们首先定义了几种挑战类型，例如昵称和音译，然后让 LLM 创建一个分层数据集集合，数据集会逐渐增大并对系统提出更多挑战。数据集的创建比预期更复杂。LLM 有强烈的 “作弊” 倾向，会让正确答案过于容易获得。例如，其中一种挑战类型关注语义上下文。这类挑战包括将 “Russian author” 解析为 “Leo Tolstoy”。LLM 错误地将 “Russian author” 作为 “Leo Tolstoy” 的别名，这就消除了使用 hybrid search 找到匹配的必要性。
经过多次重构以修复此类问题后，我们有了五个数据集层次可供使用。第 1 – 4 层逐渐增大，包含更多挑战类型。第 5 层是 “终极挑战” 数据集，由所有挑战类型中最棘手的示例组成。所有测试数据均可在 comprehensive evaluation 目录中获取。
为了评估我们的基于 prompt 的实体解析方法，我们将注意力集中在第 4 层数据集。一个重要说明是，评估是以受控实验形式进行的，以便专注于实体匹配质量。观察列表数据已预先丰富了上下文，并提前从文章中提取了实体。这确保评估专注于匹配，而不是提取准确性。这使匹配质量得以隔离；端到端性能还会依赖于提取召回率和丰富质量。
评估数据集
第 4 层评估数据集提供了对系统能力的全面测试：[1]
- 观察列表实体：66 个实体，涵盖多种类型（people、organizations、locations）。
- 测试文章：69 篇文章，涵盖现实世界的实体解析场景。
- 预期匹配：所有文章中共有 206 个预期实体匹配。
- 挑战类型：15 种不同的挑战类型，用于测试实体解析的各个方面。
数据集中包含的挑战类型有：
- 昵称： "Bob Smith" → "Robert Smith"（7 篇文章）
- 头衔和尊称： "Dr. Sarah Williams" → "Sarah Williams"（5 篇文章）
- 语义上下文： "Russian author" → "Leo Tolstoy"（8 篇文章）
- 多语言名称：处理不同书写体系的名称（6 篇文章）
- 商业实体：公司名称变体（7 篇文章）
- 高管引用： "Microsoft CEO" → "Satya Nadella"（5 篇文章）
- 政治领导人：基于头衔的引用（5 篇文章）
- 首字母： "J. Smith" → "John Smith"（3 篇文章）
- 姓名顺序变化：不同的姓名排序规则（3 篇文章）
- 截断姓名：部分姓名匹配（3 篇文章）
- 姓名拆分：文本中拆分的姓名（3 篇文章）
- 缺失空格/连字符：格式变化（2 篇文章）
- 音译：跨书写体系的名称匹配（2 篇文章）
- 组合挑战：一篇文章中包含多种挑战（6 篇文章）
- 复杂商业：层级业务关系（5 篇文章）
让我们看看基于 prompt 的实体解析表现如何。
整体表现
结果显示，LLM 驱动的匹配评估具有很大潜力，但也揭示了显著的可靠性问题。由于每个候选对都必须由 LLM 评估，即使检索效果良好，结构化输出失败也可能抑制接受率 和 召回率。
| 指标 | 值 |
|---|---|
| Precision | 83.8% |
| Recall | 62.6% |
| F1 score | 71.7% |
| 总匹配数 | 344 |
| LLM 接受率 | 44.8% |
| 错误率 | 30.2% |
错误率问题
回想一下，在原型中我们采取的第一步是使用 Elasticsearch 创建潜在匹配对。每一个潜在匹配都需要由 LLM 评估。为了高效处理所有这些匹配，我们将 LLM 调用批量处理。这可以降低 API 成本和延迟，但也增加了输出中生成格式错误 JSON 的风险。随着批量大小增加，JSON 变得更长、更复杂，使得 LLM 更可能生成无效 JSON。这就是 30% 错误率的来源。在评估中，我们使用每次请求五个匹配的批量大小。即使使用这个保守的批量大小，我们仍然会看到 JSON 解析失败，这显著影响了评估结果。
接下来：优化 LLM 集成
现在我们已经使用语义搜索和 LLM 判断完成了实体匹配，拥有了完整的实体解析管道。然而，这种方法引入了一种新的失败模式：当模型的判断正确，但其输出不可用时。我们可以优化 LLM 集成，以提高可靠性和成本效率。在下一篇文章中，我们将探讨如何使用 function calling 获取结构化输出，这可以提供保证的结构和类型安全，同时减少错误和成本。
自己尝试
想要看到实体匹配的实际操作吗？查看 Entity Matching notebook，获得完整的演示，包括真实实现、详细解释 和 实操示例。该 notebook 将向你展示如何使用三步搜索、带 RRF 的 hybrid search，以及 LLM 驱动的推理判断 来匹配实体。
请记住：这是一个教学原型，旨在讲解概念。在构建生产系统时，需要考虑额外因素，如模型选择、成本优化、延迟要求、质量验证、错误处理 和 监控，这些在该学习型原型中未涵盖。
说明
这些数据集是合成的、为教学设计；它们近似真实挑战，但不代表任何单一生产领域。
