正如我们在之前的帖子中看到的，函数调用提供的一致性不仅仅是一种不错的优化手段，它还是至关重要的。一旦我们从评估循环中消除了结构性错误，标准场景（例如第 4 层数据集中的场景）的结果便有了显著提升。

然而，有一个显而易见的问题需要回答：

当情况变得真正复杂时，这种方法还管用吗？

现实中的实体解析很少因简单情况而失败。当名称跨越语言、文化、书写系统、时间段和组织边界时，它就会失效。当人们用头衔而非名字称呼，公司更改名称，音译不一致，且尝试仅凭上下文（而非拼写）提及现实实体时，这种方法就失败了。

因此，在本系列的最后一篇文章中，我们对该系统进行了所谓的终极挑战。

是什么让这成为终极挑战？

在之前的评估中，我们使用越来越复杂的数据集对该系统进行了测试。当我们达到上一篇帖子中所讨论的第 4 层时，我们已经要应对昵称、头衔、多语言名称以及语义引用的混合情况了。这些测试表明，架构本身是可靠的，但可靠性问题，特别是不规范的 JSON 格式抑制了召回率。

有了函数调用，我们终于有了稳定的基础。这让我们有机会提出一个更有趣的问题：

一个统一的管道能否同时处理多种不同类型的实体解析问题？

终极挑战数据集的设计正是为了推动这一层面的发展。

该数据集并未专注于单一难点（如昵称或音译），而是结合了 50 多种不同的挑战类型，包括：

• 文化命名惯例。

• 基于标题的引用。

• 业务关系和历史名称变更。

• 多语言和跨脚本提及。

• 复合挑战融合了上述多种元素。

关键是，这并不是针对某个狭窄的用例进行优化。这是要测试当规则从一个实体变更到另一个实体时，设计模式是否成立。

数据集概览

终极挑战数据集包含：

• 50个实体，涵盖个人、组织和机构。

• 约 60 篇文章，结构和语言复杂程度各不相同。

• 51 个不同的挑战类别，大致分为以下几类：

  • 文化命名惯例。

  • 标题和专业背景。

  • 商业关系与组织关系。

  • 多语言和音译挑战。

  • 综合场景和边缘情况场景。

在本系列的前几篇文章中，我们看到使用生成式 AI (GenAI) 创建数据集可谓喜忧参半。如果没有它，要收集足够多、足够多样化的测试数据将极其困难。但如果不加以控制，这种模式往往会让事情变得过于简单。

例如，在早期的一次生成过程中，我们发现模型将“俄罗斯总统”等短语作为弗拉基米尔·普京 (Vladimir Putin) 的明确别名。这在今天看来可能是合理的，但却违背了测试上下文解析的目的。如果文章讨论的是 20 世纪 90 年代的俄罗斯，会发生什么情况？系统应根据上下文推断出正确的实体，而不是依赖于硬编码的别名。

因此，我们特意设计了这个数据集，以避免使用捷径。当系统能够推断出含义时，则不明确列出别名。描述性短语没有预先链接到实体。正确的匹配通常取决于文章层面的上下文，而不仅仅是局部文本。

重要说明：尽管我们展示了系统在各种场景下的能力，但这仍是一个具有教育意义的原型。处理真实世界受制裁实体监控的生产系统需要额外的验证、合规性检查、审计跟踪，以及针对敏感用例的专门处理。

为什么这些场景很难应对

在本系列的第一篇文章中，我们介绍了一个简单但含义模糊的示例：“新的 Swift 更新来了！”挑战在于，“Swift”可以根据上下文解析为现实世界中的多个实体。这个示例反映了一个更广泛的事实：自然语言本质上是模棱两可的。

因此，实体解析不仅仅是字符串匹配的问题。人们经常依赖共享知识、文化规范和情境背景来解析引用，我们甚至很少注意到我们正在这样做。

考虑以下几个常见案例：

• 没有地缘政治和时间背景，“总统”这样的头衔就毫无意义。

• 公司名称可能指母公司、子公司或之前的品牌，具体取决于文章的撰写时间。

• 一个人的名字可能会以不同的顺序、书写系统或音译方式出现，这取决于语言和文化。

• 同一个短语在不同的语境中可以合法地指代不同的实体，系统必须能够像接受匹配短语一样自信地拒绝匹配短语。

没有单一的规则集可以高效地处理所有这些情况。这就是为什么这款原型如此激进地将关注点分开：

• Elasticsearch 高效而透明地缩小了候选空间。

• LLM 仅在需要判断且必须自行解释的情况下使用。

• 检索和推理仍然是两个不同步骤。

随着挑战类型多样性的增加，这种区分变得更加重要。

系统如何在无特殊处理的情况下应对多样性

这次评估最有趣的结果之一是没有改变的内容：

• 我们没有针对日语名字添加特殊逻辑。

• 我们没有为阿拉伯语父名添加自定义规则。

• 我们没有添加历史公司名称的硬编码映射。

相反，该系统依赖于系列早期引入的相同核心要素：

• 为语义搜索编制索引的上下文丰富实体。

• Elasticsearch 中的混合检索（精确检索、别名检索和语义检索）。

• 一组数量少且定义明确的候选匹配项。

• 受函数调用和最小模式约束的 LLM 判断。

这表明系统的灵活性来自表征和架构，而非不断增长的规则集合。

当系统成功时，是因为检索到了正确的候选对象，且 LLM 有足够的上下文来解释为什么某个引用会（或不会）映射到某个特定实体。

结果：它的表现如何？

在最终挑战数据集上，系统得出了以下总体结果：

• 精度：约 91%

• 召回： ~86%

• F1 分数：约 89%

• LLM 接受率：约 72%

在各类挑战中的表现

按挑战类型细分结果可以揭示优势和局限性：

在以下领域的表现最为突出（100% F1 分数）：

• 跨脚本匹配（西里尔字母、韩文、中文企业实体）。

• 希伯来语场景（父名、职业头衔、宗教头衔、音译）。

• 企业层级（航空航天、多元化制造、多部门公司）。

• 专业头衔（学术、军事、政治、宗教）。

• 涉及多种书写系统的综合日语场景。

表现优异（80–99% F1 分数）包括：

• 国际政治人物（98%）。

• 历史名称变更 (90%)。

• 复杂的业务层次结构（89%）。

• 日本公司名称（93%）。

• 跨脚本音译（86%）。

• 阿拉伯语父名（86%）。

更具挑战性的领域包括：

• 高级音译（中文、韩文）：0% F1。

• 某些日本场景（敬语、姓名顺序、书写系统变化）：~67% F1。

• 一些阿拉伯语场景（公司名称、机构引用）：约 40% F1。

这里重要的是为什么系统在这些情况下会遇到困难。这些失败并非由于整体方法的崩溃，而是由于特定组件的局限性，尤其是在某些多语言场景中用于语义搜索的密集向量模型。

由于检索和判断是完全分离的，因此提高性能无需重写系统。更换功能更强大的多语言嵌入模型、丰富实体上下文或改进检索策略，都能在不改变核心架构的情况下改善这些类别的结果。

从架构的角度来看，这才是真正的成功指标。

这告诉我们关于设计的启示

回顾整个系列，有几个模式尤为突出：

• 准备工作比巧妙搭配更重要。预先为实体添加上下文信息可以显著减少以后可能出现的歧义。

• LLM 作为评判者最有价值，而非检索者。让他们解释为什么某个匹配是有意义的，比要求他们进行搜索要有效得多。

• 可靠性确保准确性。函数调用不仅清理了 JSON，还释放了检索步骤中已存在的召回能力。

• 通用性胜过专业化。少量经过精心挑选的抽象概念无需自定义逻辑即可处理数十种挑战类型。

这就是为什么原型有意采用 Elasticsearch 原生架构，并在 LLM 的使用上有意采取保守策略的原因。目标不是取代搜索；而是在意义至关重要的情况下，使搜索变得可解释。

总结

最终的挑战并非追求完美的指标，而是回答一个更根本的问题：

一个透明、搜索优先、LLM 辅助的架构能否处理现实世界中的实体歧义，而不陷入规则或黑箱的情况？

对于这个具有教育意义的原型，答案是肯定的，但需要明确注意生产环境的强化、合规性、监控以及数据质量等方面的问题。如果您正在构建的系统需要说明为什么要进行实体匹配，那么这种模式值得认真考虑。我希望这个系列能告诉人们，实体解析其实并不神秘。只要合理地进行关注点分离，就可以对问题进行推理、评估和优化。

这项工作还提出了一种更广泛的架构模式。由此出现了经典检索增强生成 (RAG) 的一次细微但重要的演变。我们没有让检索直接为生成提供信息，而是引入了一个明确的评估步骤。首先使用 LLM 对检索到的候选结果进行判断和合理性检查，只有通过审核的结果才允许用于增强生成。您可以将其视为“生成增强型检索增强生成与评估”，或者简称为“GARAGE”，毕竟谁不喜欢一个好听的缩写词呢。

还有哪些其他用例可以从这种模式中受益？需要信任、透明和可辩护推理的系统是当然的候选者。未来在这一领域的工作应该会像我们在这里看到的结果一样引人注目，我很期待看到社区接下来会有什么新的发展。

下一步：亲自试用

想看看终极挑战的实际操作吗？请查看终极挑战笔记本，它通过实际实现、详细解释和动手示例，提供了完整的实践指南。

完整的实体解析管道展示了生产使用所需的核心概念和架构。您可以将其用作构建系统的基础，这些系统可以监测新闻文章、跟踪实体提及情况，并回答有关哪些实体出现在哪些文章中的问题，同时还能保持透明度和可解释性。

1. 新的 Swift 更新来了！开发人员迫不及待地想要尝试新功能。

2. 新的 Swift 更新来了！新专辑将于下个月发布。

有了这些增加的上下文，我们应该能够将名称“Swift”解析到正确的实体。

在上一篇文章中，我们设置了观察清单，并用额外的上下文丰富了实体信息。看上面的例子，我们需要在清单中至少包含以下两个实体：Taylor Swift 和 Swift 编程语言。我们还介绍了如何从文本中提取实体提及。这两个例子都能提取“Swift”。有了这些要素——丰富的观察清单和提取出的实体——我们终于可以介绍本次的主角了：实体匹配。

请记住：这是一个教育原型，旨在教授实体匹配概念。生产系统可能会使用不同的大型语言模型 (LLM)、自定义匹配规则、专门的判断管道或结合多种匹配策略的集成方法。

问题：为何匹配如此困难

人类语言是一种非凡的事物。它最有趣的特性之一是其无限的创造力。我们可以生成并理解无数的新句子。那么，在实体解析中完全精确的匹配极为罕见，这还奇怪吗？作者们在可能的情况下都力求创新。如果每次提到某个实体时，我们都必须书写和阅读完整名称，那将会变得非常乏味。因此，尽管精确匹配很简单，但现实情况是我们需要一种更复杂的方法来进行实体解析：这种方法必须足够强大，以处理人类作者无限创造力中的至少一部分挑战。这就是我们将问题分解为两个步骤的原因：使用 Elasticsearch 大规模检索可能的候选实体，然后使用 LLM 来判断这些候选实体是否真正指向同一个现实世界中的实体。

解决方案：三步匹配与透明的 LLM 判断

我们正处于使用计算机方式的范式转变之中。正如互联网的兴起将我们从本地计算带入全球互联网络一样，生成式 AI (GenAI) 正在从根本上改变内容、代码和信息的创建方式。事实上，伴随本系列的教育型原型几乎完全是作者通过精心设计提示词，使用 LLM “vibe coded” 出来的。这并不是说 LLM 已经或将要达到人类语言所固有的那种生产力，但这确实意味着我们现在拥有一个强大的资源来帮助进行实体解析。

我们在使用生成式 AI 时的一个常见模式是检索增强生成 (RAG)。在这里，检索检索意味着检索实体候选（而不是生成答案），LLM 严格用于匹配评估和解释。虽然我们可以要求 LLM 帮助我们进行端到端的实体解析，但这在时间和金钱上都是一种成本高昂的方法。RAG 通过使用更高效的方式为 LLM 提供上下文，从而帮助 LLM 完成工作，进而使 LLM 能够有效地协助实体解析。

对于 RAG 中的检索部分，我们再次求助于 Elasticsearch。我们首先使用精确匹配、别名匹配以及结合了关键词和语义搜索的混合搜索来寻找潜在的匹配项。一旦找到这些潜在匹配项，我们就将它们发送给 LLM 进行判断。LLM 充当最终的匹配评估器。我们还让 LLM 解释其推理过程，这是与其他实体解析系统的一个重要区别。没有这些解释，实体解析就是一个黑匣子；有了它们，我们可以亲眼看到为什么某个匹配是合理的。

关键概念：三步匹配、混合搜索和透明 LLM 判断

什么是三步匹配？在项目开始时，我们假设语义搜索将是系统的一个关键部分，但并非每个匹配都需要如此复杂的搜索。为了有效地找到匹配项，我们采用了渐进式的方法。首先，我们使用关键词搜索检查完全精确的匹配。如果找到这样的匹配，我们的工作就完成了，可以继续下一个。如果精确匹配失败，我们转向别名匹配。为简化起见，在原型中，别名匹配也是使用关键词进行精确匹配完成的。在生产环境中，您可能会通过标准化、音译规则、模糊匹配或精心管理的别名表来扩展这一步。如果在前两步之后仍未找到潜在的匹配项，那么是时候通过 Elasticsearch 的混合搜索（结合了倒数排序融合）来引入语义搜索了。

什么是混合搜索？在 Elasticsearch 中，我们可以使用语义搜索来找到将上下文考虑在内的有意义的匹配。Elasticsearch 广泛用于向量搜索和混合检索。语义相似性对于理解含义非常强大，但它不能替代结构化过滤（例如，按时间范围、位置或标识符过滤），并且在存在精确匹配时通常是不必要的。Elasticsearch 以其词汇搜索而闻名，这在不适合语义搜索的任务中表现出色。为了充分利用这两种方法，我们在单个混合查询中将词汇搜索与语义搜索结合使用。然后，我们使用 RRF 合并结果，以找到最可能的匹配项。在原型中，排名前两位的结果成为可以发送给 LLM 进行判断的潜在匹配项。

为什么需要 LLM 判断？LLM 的判断和解释使得我们的系统能够透明地处理歧义和上下文。这对于像“the president”这样可能根据上下文指代多个实体的情况至关重要，但它也使昵称和文化差异等情况在系统中能够很好地处理。最后，当我们考虑关键任务，例如识别制裁名单中的实体时，我们需要知道匹配被接受的原因，才能信任该系统。至关重要的是，LLM 并不搜索整个语料库；它只评估 Elasticsearch 返回的那一小部分候选集。

实际结果：通过 LLM 推理进行匹配

任何自然语言处理任务的一个主要挑战是创建一份黄金文档，一份告诉我们预期结果是什么的“答案”。没有它，几乎不可能判断一个系统在某个任务上表现如何，但创建这样一份文档可能是一个费力且费时的过程。对于实体解析原型，我们再次求助于生成式 AI 来帮助建立我们可以用来测试的数据。

我们首先定义了几种挑战类型，例如昵称和音译，然后要求 LLM 创建一个分层的数据集集合，这些数据集将逐渐变大，对系统来说也更具挑战性。数据集的创建并不像人们希望的那样简单。LLM 有一种强烈的“作弊”倾向，使得获取正确答案变得过于容易。例如，其中一种挑战类型侧重于语义上下文。这种类型包括将“Russian author”解读为“Leo Tolstoy”。LLM 错误地将“Russian author”作为“Leo Tolstoy”的一个别名，这就没有必要通过混合搜索来寻找匹配项了。

在进行了几次重构以修复此类问题后，我们有了五个可供使用的数据集层级。第 1-4 层规模逐渐增大，包含的挑战类型也更多。第 5 层是“终极挑战”数据集，由所有挑战类型中最棘手的例子组成。所有测试数据都可以在全面评估目录中找到。

为了评估我们基于提示的实体解析方法，我们将注意力集中在第 4 层数据集上。一个重要的说明是，评估是作为受控实验进行的，这样我们可以专注于实体匹配的质量。观察清单数据预先丰富了上下文，并且实体是提前从文章中提取出来的。这确保了评估的重点是匹配而非提取的准确性。这将匹配质量孤立出来；端到端的性能还将额外取决于提取的召回率和丰富数据的质量。

评估数据集

第 4 层评估数据集对系统的能力提供了一个全面的测试：[1]

• 观察清单实体：跨不同类型（人物、组织、地点）的 66 个实体。

• 测试文章：69 篇涵盖现实世界实体解析场景的文章。

• 预期匹配：所有文章中预期的 206 个实体匹配。

• 挑战类型：测试实体解析各个方面的 15 种不同挑战类型。

数据集中包含的挑战类型有：

• 昵称：“Bob Smith” → “Robert Smith”（七篇文章）。

• 头衔和尊称： “Dr. Sarah Williams” → “Sarah Williams”（五篇文章）。

• 语义上下文：“Russian author” → “Leo Tolstoy”（八篇文章）。

• 多语言名字：处理不同书写系统中的名称（六篇文章）。

• 商业实体： 公司名称变体（七篇文章）。

• 高管引用：“Microsoft CEO”→“Satya Nadella”（五篇文章）。

• 政治领导人：基于头衔的引用（五篇文章）。

• 名称首字母：“J.Smith” → “John Smith”（三篇文章）。

• 名称顺序变体：不同的名称顺序惯例（三篇文章）。

• 名称截断：部分名称匹配（三篇文章）。

• 名称拆分：名称在文本中拆分（三篇文章）。

• 缺少空格/连字符：格式变体（两篇文章）。

• 音译：跨书写系统的名称匹配（两篇文章）。

• 组合挑战：一篇文章中包含多个挑战（共六篇文章）。

• 复杂商业关系：分层商业关系（五篇文章）。

让我们看看基于提示的实体解析表现如何。

整体性能

结果显示，由 LLM 驱动的匹配评估前景广阔，但也揭示了一个显著的可靠性问题。因为每个候选对都必须由 LLM 进行评估，结构化输出的失败可能会抑制接受率和召回率，即使检索环节工作正常。

指标

值

精确率

83.8%

召回

62.6%

F1 分数

71.7%

找到的总匹配数

344

LLM 接受率

44.8%

错误率

30.2%

错误率问题

回顾一下，我们在原型中采取的第一步是使用 Elasticsearch 创建潜在的匹配对。每个这样的潜在匹配都需要由 LLM 进行评估。为了高效地处理所有这些匹配项，我们将 LLM 调用批量组合在一起。这降低了 API 成本和延迟，但也增加了在输出中得到格式错误 JSON 的风险。随着批量大小的增加，JSON 变得更长、更复杂，使得 LLM 更有可能生成无效的 JSON。这就是 30% 错误率的来源。在评估中，我们每个请求使用 5 个匹配项的批量大小。即使采用这个保守的批量大小，我们仍然遇到 JSON 解析失败的情况，这显著地影响了评估结果。

下一步：优化 LLM 集成

现在，我们已经使用语义搜索和 LLM 判断匹配了实体，我们拥有了一个完整的实体解析管道。然而，这种方法引入了一种新的故障模式：当模型的判断正确，但其输出却不可用时。我们可以优化 LLM 集成以获得更好的可靠性和成本效益。在下一篇文章中，我们将探讨如何使用函数调用来实现结构化输出，这可以在减少错误和成本的同时，提供有保障的结构和类型安全。

亲自试用

想亲眼看看实体匹配是如何运作的吗？请查看实体匹配笔记本，它通过实际实现、详细解释和动手示例，提供了完整的实践指南。该笔记本精确地向您展示了如何使用三步搜索、带有 RRF 的混合搜索以及由 LLM 驱动的带推理的判断来匹配实体。

请记住：这是一个教育原型，旨在教授这些概念。在构建生产系统时，需要考虑额外的因素，如模型选择、成本优化、延迟要求、质量验证、错误处理和监控等，而这些在本学习重点的原型中并未涵盖。

备注

1. 这些数据集是合成的，专为教育目的设计；它们模拟了真实的挑战，但不代表任何单一的生产环境领域。