作者来自 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 Smith7 篇文章头衔和尊称 Dr. Sarah Williams → Sarah Williams5 篇文章语义上下文 Russian author → Leo Tolstoy8 篇文章多语言名称处理不同书写体系的名称6 篇文章商业实体公司名称变体7 篇文章高管引用 Microsoft CEO → Satya Nadella5 篇文章政治领导人基于头衔的引用5 篇文章首字母 J. Smith → John Smith3 篇文章姓名顺序变化不同的姓名排序规则3 篇文章截断姓名部分姓名匹配3 篇文章姓名拆分文本中拆分的姓名3 篇文章缺失空格/连字符格式变化2 篇文章音译跨书写体系的名称匹配2 篇文章组合挑战一篇文章中包含多种挑战6 篇文章复杂商业层级业务关系5 篇文章让我们看看基于 prompt 的实体解析表现如何。整体表现结果显示LLM 驱动的匹配评估具有很大潜力但也揭示了显著的可靠性问题。由于每个候选对都必须由 LLM 评估即使检索效果良好结构化输出失败也可能抑制接受率 和 召回率。指标值Precision83.8%Recall62.6%F1 score71.7%总匹配数344LLM 接受率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 驱动的推理判断 来匹配实体。请记住这是一个教学原型旨在讲解概念。在构建生产系统时需要考虑额外因素如模型选择、成本优化、延迟要求、质量验证、错误处理 和 监控这些在该学习型原型中未涵盖。说明这些数据集是合成的、为教学设计它们近似真实挑战但不代表任何单一生产领域。原文https://www.elastic.co/search-labs/blog/elasticsearch-entity-resolution-llm-semantic-search