如何在 Multi-Agent RAG 中实现可审计的实体解析与引用完整性？

建议采用“摄取阶段建立实体链接、查询阶段补充消歧、独立实体服务统一管理身份”的架构。NER 和候选排序可以使用模型，最终是否链接应由明确的接受规则决定，并保存证据、版本和决策记录。无法确认身份时，应保留未决状态，不强行分配已有实体 ID。

这里有两个不同的目标：确定性是指在输入、候选集、模型输出和规则版本固定时，决策可以复现；引用完整性是指链接指向有效的实体记录。二者都不能单独证明身份判断正确。

先区分实体识别、实体链接和实体合并

三个步骤各有不同的职责：

• NER：找出文本中的实体提及及其类型，例如人名、机构名。
• NEL：将一次实体提及关联到知识库中的具体实体 ID。
• Entity Resolution：判断不同记录是否代表同一实体，并管理重复记录、合并和拆分。

J. Doe 与 John Doe 可能是同一个人，也可能是不同的人。Doe Corp 则可能是机构，不能因为名称相似就与人名合并。人员与公司的任职、持股等关系也不能记录为身份相同。

向量相似度适合用于生成候选。判断是否为同一实体，还需要类型、上下文、时间以及可验证标识符等证据。若档案中的实体不在公共知识库中，应建立内部实体注册表，并保存经过验证的外部 ID 映射。

NER 应放在摄取阶段，检索后处理作为补充

主要处理流程可以安排为：

原始档案与文档版本
  → 文本解析与原文位置映射
  → NER / 文档内共指解析
  → 候选实体生成
  → 类型、时间与身份冲突检查
  → 候选排序与链接决策
  → 实体注册表、证据记录及检索索引

摄取阶段可以批量处理文档，让不同 Agent 使用同一套已发布的实体链接结果。NER 可以使用带重叠的文本窗口，但必须保留文档级上下文和原文偏移，以免切块后丢失简称解释、跨句指代或证据位置。

查询阶段再处理以下情况：

1. 解析用户问题中的实体名称。
2. 根据实体 ID、别名和语义信息组合检索。
3. 对未决提及补取相邻段落或关联文档。
4. 将新证据提交给实体服务重新评估。

Agent 可以提出链接建议，但应通过统一服务验证和提交。若只在检索后做 NEL，每次查询接触的材料不同，容易产生互相矛盾的临时身份判断。

用独立实体注册表维护全局状态

全局 Entity Graph 应存放在持久化存储中，通过查询接口访问。LLM 上下文只需要包含当前任务涉及的实体、证据和少量关系。

可以从以下数据模型开始：

实体 ID 应独立于名称生成。名称会变化，同名也很常见，直接对标准化名称取 hash 无法解决身份问题。

一种可行的实现是用关系数据库保存权威记录，通过外键约束保证链接目标存在。如果业务需要频繁执行多跳关系查询，再维护图数据库投影。这是架构建议，并不意味着百万级文档必须同时使用两类数据库。

多个 Agent 可通过类似以下的服务接口按需读取：

resolve_mentions(mentions, snapshot_id)
get_entity(entity_id, snapshot_id)
get_evidence(entity_id, cursor, limit, snapshot_id)
get_neighbors(entity_id, relation_types, limit, snapshot_id)

这些是建议的应用接口，不是某个框架的现成 API。查询结果应包含证据引用和状态，并限制条数、分页及图遍历深度。

实时查询也需要版本边界。一次调查任务可以固定 snapshot_id，新摄取的材料产生后续快照；需要切换快照时显式记录。这样既能查询新数据，也能复现先前结论。实体合并或拆分时，应保留历史 ID 和决策，不覆盖旧证据。

如何选择 NEL 工具和工作流框架

可以按职责分别选型，无需寻找一个包承担整个系统。

GLiNER 官方仓库将其定位为 Named Entity Recognition 模型。用它提取人名或机构名之后，仍需另外实现到内部实体 ID 的映射。

spaCy 提供 EntityLinker 组件，结合 KnowledgeBase、候选生成和上下文模型，为实体提及预测知识库 ID，并支持通过阈值拒绝低分预测。使用自有档案时，需要提供适配的知识库和训练或评估数据；添加组件本身不会自动获得调查领域的消歧能力。参见 spaCy EntityLinker 文档。

LangGraph 的节点可以运行普通函数，因此可以调用独立 NEL 服务，再把实体 ID 和证据引用写回任务状态。LangGraph 的工作流图与业务 Entity Graph 应分别管理。参见 LangGraph Graph API 文档。

LlamaIndex 提供摄取转换流程，EntityExtractor 用于提取节点中的实体名称；这并不代表已经完成到唯一知识库 ID 的链接。可以在摄取链路中增加自己的链接步骤。参见 Ingestion Pipeline 和 Metadata Extraction。

这些文档支持组件化集成方案，但不足以确认存在即插即用的原生插件，能够同时满足实时性能、自有知识库消歧和高精确率要求。具体延迟和准确率需要用档案样本评估。

如何设置保守的链接决策

先生成候选，再用明确规则决定是否接受：

1. 优先核对来源可靠、命名空间明确的身份标识符，同时检查类型和时间冲突。
2. 使用别名、编辑距离、全文搜索和向量搜索补充候选。
3. 对候选排序，并检查首位得分、与次位的差距以及证据是否充分。
4. 存在冲突或证据不足时返回未决状态，进入补证或人工复核流程。

下面的 Python 代码只演示排序后的接受门槛，不包含 NER、候选检索或模型推理：

def decide_link(candidates, *, min_score, min_margin):
    if not candidates:
        return {"status": "UNRESOLVED", "entity_id": None}

    ranked = sorted(
        candidates,
        key=lambda item: (-item["score"], item["entity_id"]),
    )
    best = ranked[0]

    if best["has_conflict"] or not best["evidence_sufficient"]:
        return {"status": "REVIEW", "entity_id": None}

    if best["score"] < min_score:
        return {"status": "UNRESOLVED", "entity_id": None}

    if len(ranked) > 1:
        margin = best["score"] - ranked[1]["score"]
        if margin <= min_margin:
            return {"status": "REVIEW", "entity_id": None}

    return {"status": "ACCEPTED", "entity_id": best["entity_id"]}

调用前应按 entity_id 去重，并验证候选字段和分数的有效性。evidence_sufficient 与 has_conflict 必须来自可审计的证据检查。min_score 和 min_margin 需要通过领域标注数据确定，模型分数不能直接解释为正确概率。即使只有一个候选，也不能跳过证据检查。

未找到候选只说明当前候选生成没有结果，不能直接证明这是一个新实体。新建实体同样需要明确流程。

百万级文档的扩展与验证

规模化处理需要减少重复工作和无约束比较：

• 按文档版本增量处理，采用批量推理、任务队列、重试和幂等写入。
• 通过类型、名称索引和可靠属性进行 blocking，限制每个提及的候选数，避免全量两两比较。
• 缓存键包含实体库、模型和规则版本；实体更新后使相关缓存失效。
• 保存实际候选集、模型输出、证据与决策版本。仅固定随机种子不足以保证跨环境完全复现。
• 记录数据库与检索索引之间异步更新的版本，查询时检查链接状态，避免使用过期实体映射。

评估时应分别测量候选召回率、已接受链接的 precision、覆盖率、未决比例和人工复核量，并单独检查同名、缩写、OCR 错误及跨类型案例。不要仅用整体 accuracy 掩盖少量高影响误链接。

原始材料没有给出文档长度、实体密度、更新频率或延迟目标，因此无法据此承诺具体硬件配置、吞吐量或某个库的百万级处理性能。可以先用代表性档案校准链接策略，再做端到端容量测试。

备注：内容仅供参考。