作者：来自 Elastic Jessica Moszkowicz
在一个高度多样化、旨在防止走捷径的 “终极挑战” 数据集中，解决并评估实体解析挑战。
Elasticsearch 与行业领先的 Gen AI 工具和提供商具有原生集成。查看我们关于 Beyond RAG Basics 的网络研讨会，或了解如何使用 Elastic 向量数据库构建可用于生产环境的应用。
要为你的使用场景构建最佳搜索解决方案，可以现在开始免费的云试用，或在本地机器上尝试 Elastic。
现在我们已经看到了两种实现智能实体解析的方法。这两种方法的起点相同：实体准备与提取，然后使用 Elasticsearch 进行候选实体检索。接下来，我们使用 large language model ( LLM ) 对这些候选实体进行评估，要么通过基于 prompt 的 JSON 生成，要么通过 function calling，并要求模型为其判断提供透明的解释。
正如我们在上一篇文章中看到的，function calling 提供的一致性不仅仅是一个不错的优化；它是必不可少的。一旦我们从评估流程中移除了结构性错误，在标准场景（例如 tier 4 数据集中的情况）上的结果显著改善。
然而，还有一个明显的问题需要回答：
当事情真正变得复杂时，这种方法仍然有效吗？
现实世界中的实体解析很少因为简单情况而失败。它通常在以下情况下失败：名称跨越语言、文化、书写系统、时间时期和组织边界；当人们用头衔而不是姓名被提及时；当公司更改名称时；当音译不一致时；以及当唯一能够将一个提及与现实世界实体联系起来的是上下文而不是拼写时。
因此，在这个系列的最后一篇文章中，我们让系统面对我们称之为 “终极挑战” 的测试。
是什么让它成为 “终极挑战”？
在之前的评估中，我们使用越来越复杂的数据集来测试系统。当我们到达上一文章讨论的 tier 4 时，已经在处理昵称、头衔、多语言姓名以及语义引用的混合情况。这些测试表明架构本身是可靠的，但可靠性问题（尤其是格式错误的 JSON）正在压低召回率。
随着 function calling 的引入，我们终于拥有了一个稳定的基础。这让我们能够提出一个更有趣的问题：
一个统一的 pipeline 是否能够同时处理多种不同类型的实体解析问题？
“终极挑战” 数据集正是为测试这一点而设计的。
与只关注某一种困难（例如昵称或音译）不同，这个数据集结合了 50 多种不同的挑战类型，包括：
-
不同文化的命名规则
-
基于头衔的引用
-
企业关系和历史名称变更
-
多语言和跨书写系统的提及
-
组合型挑战（同时包含多种问题）
关键在于，这并不是为了针对某一个狭窄用例进行优化，而是为了测试：当规则在不同实体之间不断变化时，这种设计模式是否仍然有效。
数据集概览
“终极挑战” 数据集包括：
-
50 个实体，涵盖人物、组织和机构
-
约 60 篇文章，结构和语言复杂度各不相同
-
51 个不同的挑战类别，大致分为：
-
文化命名规则
-
头衔与职业语境
-
企业与组织关系
-
多语言与音译挑战
-
组合型与边缘案例场景
-
在本系列之前的文章中，我们已经看到使用 生成式 AI（GenAI） 创建数据集既有优势也有问题。如果没有它，构建足够大且多样化的测试数据会非常困难；但如果不加控制，模型往往会把问题变得过于简单。
因此，这个数据集被刻意设计成 无法通过捷径解决：
-
当系统需要推断含义时，不会显式列出别名
-
描述性短语不会提前绑定到实体
-
正确匹配往往依赖 整篇文章的上下文，而不仅仅是局部文本
重要说明
尽管本文展示了系统在多种场景下的能力，但它仍然是一个教学原型。在真实世界的受制裁实体监控等生产系统中，还需要额外的验证、合规检查、审计追踪，以及针对敏感场景的专门处理。
为什么这些场景很难
在本系列的第一篇文章中，我们介绍了一个简单但含糊的例子：“The new Swift update is here!” 问题在于，“Swift” 可能对应多个现实世界中的实体，具体取决于上下文。这个例子揭示了一个更普遍的事实：自然语言本质上是模糊的。
因此，实体解析不仅仅是一个字符串匹配问题。人类在解析引用时，通常会依赖共享知识、文化规范和情境背景，而且我们往往甚至没有意识到自己正在这样做。
来看几个常见情况：
-
像 “the president” 这样的头衔，如果没有地缘政治和时间背景，就没有明确含义。
-
一个公司名称可能根据文章撰写的时间不同，指代母公司、子公司或曾经的品牌。
-
一个人的名字可能根据语言和文化不同，以不同顺序、书写系统或音译形式出现。
-
同一个短语在不同语境中可能合理地指向不同实体，系统不仅需要能够确认匹配，也必须能够同样自信地拒绝不匹配的情况。
没有一套单一规则可以干净地处理所有这些情况。这也是为什么这个原型系统对职责进行了严格分离：
-
Elasticsearch 负责高效且透明地缩小候选实体范围。
-
LLM 只在需要判断时使用，并且必须解释其决策。
-
检索（retrieval） 与 推理（reasoning） 保持为两个独立步骤。
随着挑战类型的多样性增加，这种分离变得更加重要。
系统如何在没有特殊规则的情况下处理多样性
这次评估中最有趣的结果之一，是有些东西并没有改变：
-
我们没有为 日语姓名 添加特殊逻辑。
-
我们没有为 阿拉伯父名（patronymics） 添加自定义规则。
-
我们没有为 历史公司名称变化 编写硬编码映射。
相反，系统仍然依赖本系列之前介绍的核心要素：
-
为语义搜索建立 上下文增强的实体索引
-
在 Elasticsearch 中进行 混合检索（精确匹配、别名匹配、语义匹配）
-
使用 规模较小且明确的候选集合
-
使用 function calling 和最小化 schema 来约束 LLM 的判断
这表明系统的灵活性来自于表示方式（representation）和架构设计（architecture），而不是不断增加的规则集合。
当系统成功时，原因通常是：
-
正确的候选实体被检索出来
-
LLM 拥有足够的上下文来解释为什么某个引用应该或不应该映射到某个实体
结果：系统表现如何？
在 “终极挑战” 数据集上，系统整体表现如下：
-
Precision（精确率）：约 91%
-
Recall（召回率）：约 86%
-
F1 Score：约 89%
-
LLM 接受率：约 72%
不同挑战类型的表现
按挑战类型细分结果，可以看到系统的优势与局限：
表现最强（F1 = 100%）的领域包括：
-
跨书写系统匹配（西里尔文、韩文、中文企业实体）
-
希伯来语场景（父名、职业头衔、宗教头衔、音译）
-
企业层级结构（航空航天、多元化制造、多事业部公司）
-
职业头衔（学术、军事、政治、宗教）
-
包含多种书写系统的日语组合场景
**表现较强（F1 = 80–99%）**的领域包括：
-
国际政治人物：98%
-
历史名称变化：90%
-
复杂企业层级：89%
-
日本公司名称：93%
-
跨书写系统音译：86%
-
阿拉伯父名：86%
更具挑战性的领域包括：
-
高级音译（中文、韩文）：F1 = 0%
-
某些日语场景（敬语、姓名顺序、书写系统变化）：约 67%
-
一些阿拉伯语场景（公司名称、机构引用）：约 40%
重要的是要理解系统在这些情况下困难的原因。失败并不是因为整体方法失效，而是由于某些组件的限制，最明显的是用于语义搜索的密集向量模型在某些多语言场景中的能力不足。
由于检索（retrieval）与判断（judgment）被清晰地分离，提升性能并不需要重写整个系统。例如：
-
替换为更强的 多语言 embedding 模型
-
增强实体上下文信息
-
优化检索策略
这些改进都可以在不改变核心架构的情况下提升系统表现。
从架构角度来看，这才是真正的成功指标。
这对系统设计说明了什么
回顾整个系列，可以看到几个明显的模式：
-
准备阶段比聪明的匹配更重要。 提前用上下文丰富实体信息，可以在后续大幅减少歧义。
-
LLM 最适合作为 “裁判”，而不是检索器。 让模型解释为什么一个匹配合理，比让它直接搜索要更有价值。
-
可靠性带来准确性。 function calling 不只是清理了 JSON 结构问题；它释放了原本就存在于检索步骤中的召回能力。
-
通用化优于专用化。 少量精心设计的抽象就能处理几十种挑战类型，而不需要定制逻辑。
这也是为什么这个原型系统刻意以 Elasticsearch 为核心，并且在使用 LLM 时保持谨慎。目标不是替代搜索，而是在语义真正重要的场景中，让搜索具备可解释性。
最终思考
“终极挑战” 的目标并不是追求完美指标，而是回答一个更根本的问题：
一个透明、以搜索为核心、并由 LLM 辅助的架构，能否在不依赖大量规则或黑箱模型的情况下处理现实世界中的实体歧义？
对于这个教学原型来说，答案是可以。当然，前提是需要进一步进行生产级强化，例如：
-
生产环境的稳定性与可靠性
-
合规性与审计
-
监控机制
-
数据质量管理
如果你正在构建需要解释实体匹配原因的系统，这种架构模式值得认真考虑。希望这个系列表明：实体解析并不一定是神秘或不可理解的。 通过正确的职责分离，它可以被分析、衡量并持续改进。
这一工作也暗示了一种更广泛的架构模式。它实际上是对经典 RAG（Retrieval Augmented Generation） 的一个小但重要的演进：
传统 RAG：
检索 → 直接用于生成
新的模式：
检索 → 评估 → 生成
也就是说，LLM 首先用来评估和验证检索到的候选结果，只有通过验证的结果才会用于生成内容。作者将这种模式称为：
GARAGE（Generation-Augmented Retrieval-Augmented Generation with Evaluation）
简单说就是：
带评估步骤的 RAG。
哪些场景适合这种模式？
需要信任、透明度和可辩护推理的系统都是天然候选，例如：
-
实体解析与知识图谱构建
-
合规与风险监控
-
新闻或文档中的实体追踪
-
需要可解释答案的问答系统
未来在这一方向的研究和实践很可能会非常有价值，我也很期待看到社区如何继续发展这些思路。
下一步：亲自尝试
如果你想看看 “终极挑战” 如何运行，可以查看 Ultimate Challenge notebook。其中包含完整的演示，包括：
-
实际实现代码
-
详细解释
-
可操作的示例
完整的实体解析 pipeline 展示了构建生产系统所需的核心概念和架构。你可以在此基础上构建系统，例如：
-
监控新闻文章
-
跟踪实体提及
-
回答哪些文章中出现了哪些实体
同时仍然保持透明性和可解释性。
