LangChain 如何用 OpenWiki 与证据图构建有据可依的 Agent 记忆

当智能体需要处理组织内的政策、手册、wiki、工单和代码时，它们必须应对散落在各个系统和团队中的知识。找到相关段落只是第一步。它们还需要判断哪些规则适用、哪些内容已经变更，以及一个来源如何影响另一个来源。

持久化记忆层会保存知识与关系，供智能体在不同任务之间复用。如果没有这一层，智能体往往不得不在每个问题上重新构建这种理解，导致工作成本高昂且容易出错。这在银行和保险领域尤其具有挑战性，因为政策和指南经常相互修订或取代。

我们测试了 OpenWiki——我们的开源 wiki 编译器——作为这一记忆层。在需要跨来源建立关联的问题上，wiki 使智能体的准确率比仅使用搜索时高出约 5 倍。加入证据图（将 wiki 陈述与支撑段落连接起来，并关联相关来源）后，准确率进一步提升 27%，引用一致性提高了一倍。

为什么选择编译式 wiki？

RAG 流水线通常使用语义搜索或混合搜索来检索孤立的文本块，让智能体自行拼凑这些文本块之间的关系。我们探索过用 agentic RAG 和基于图的元数据过滤来改进检索，但找到相关段落只是工作的一部分。跨来源问题需要追踪引用、解决冲突规则并理解依赖关系。记忆层会保存这种理解，这样智能体就不必在每个问题上重新构建它。

编译式 wiki 通过将源材料综合成相互链接的页面来解释关键概念及其关系，从而提供这一记忆层。随着来源变化，wiki 会更新，为智能体提供可复用的上下文。

OpenWiki 是我们基于 Deep Agents 构建的开源 CLI，它创建这些 wiki，并附带回溯到来源的引用。我们最初构建它，是为了让编码智能体不必在每个任务中重新发现架构和代码行为。

OpenWiki 的每条陈述都基于一个声明，即与支撑来源行及其哈希值相关联的断言。当这些行发生变化时，哈希值也会变化，使 OpenWiki 无需调用模型即可标记受影响的声明，从而节省 token 成本，并使陈旧性检测更加确定。只有这些声明会被发送给模型进行确认、修订或撤回，使记忆层能够随着来源变化而自我修正。我们在 Building self-correcting memory in OpenWiki 中对此进行了说明。

构建测试文档库

我们构建了一个包含 111 份长文档的合成保险文档库。我们选择保险领域，是因为保单和批单经常相互引用、修订和覆盖；这正是使检索变得困难的跨文档依赖关系。

为了对基准进行评分，我们创建了一个包含 972 条事实的台账，并控制了每条事实应出现的位置、文档之间如何相互引用，以及版本之间发生了什么变化。我们用 LLM 生成周围的文本，并运行自动检查以确保所需事实存在。

最后，我们有意让语料库变得杂乱，混入过时版本、矛盾内容、间接引用链、不同措辞和超长文档，以更好地匹配智能体在真实企业文档库中面临的情况。

我们如何配置实验

我们在两种条件下评估了同一个检索代理：Search（对原始文档进行关键词搜索）和 Wiki（同一个代理，但可以访问由 OpenWiki 编译、带来源链接的 wiki）。底层模型、指令、文档和问题均保持不变——只有代理对编译记忆的访问方式发生了变化。

我们测试了 80 个简单的查找问题和 50 个关联问题，后者需要跨文档追踪依赖关系（例如，识别哪些内容依赖于某项条款，或在该条款变更时受到影响）。每个问题我们询问了三次，以衡量运行间的波动。

指标（“更好”意味着什么）：

准确率（0–1）：评分者依据 972 条事实台账生成的检查清单，核对答案和引用的证据（对必需事实给予奖励，对矛盾之处进行扣分）。
一致性（0–1）：三次运行中引用证据的重叠程度（引用集合的平均两两 Jaccard 相似度）。这衡量的是代理是否可靠地将其答案建立在相同的来源上，而非答案是否正确。
成本 + 延迟：模型花费（美元）和每个问题的实际耗时。

wiki 在哪些方面有帮助，在哪些方面表现不佳

OpenWiki 以 4.15 美元将包含 111 份文档的库编译成一个约为原始大小十分之一的 wiki。之后添加 17 份文档，每份约花费 0.09 美元。以下分析排除了编译和更新成本，仅报告检索和回答成本。

我们使用简单查找作为对照。这些单段落问题几乎不需要跨文档的保险上下文，因此我们并不期望 wiki 能带来多大帮助。搜索和 wiki 的结果分别相似（准确率 0.84 对 0.83；引用重叠 0.72 对 0.74；每个正确答案花费 0.020 美元对 0.021 美元），而延迟从 9 秒增加到 12 秒。

关联问题需要利用领域特定的关系跨来源进行推理。在这里，wiki 将准确率提升了约 5 倍，从仅使用搜索时的 0.10 提升到 0.52。其编译的上下文帮助代理应用领域知识，并以更少的工具调用找到相关关系，将每个正确答案的成本从约 0.55 美元降至 0.19 美元。

尽管在准确率和成本上有所改善，wiki 代理的证据检索仍然不一致。引用重叠从简单查找的 0.74 降至关联问题的 0.25。引用稳定性并不衡量正确性，但证据的变化可能会改变答案，尤其是在来源冲突时。对于关键业务功能，团队需要的是可复现、可审计的答案，而不仅仅是更高的平均准确率。

wiki 帮助代理跨来源应用领域知识。剩下的挑战是让通往支持证据的路径更加可重复。

添加证据图

为了使检索更加一致，我们添加了一个轻量级的证据图：一张将 wiki 引用转化为声明、wiki 页面、段落和主题之间显式类型化边的映射。OpenWiki 的引用是 Markdown 文件中的文本引用。该图通过将它们具体化为类型化边，使其变得持久。这为代理提供了一条稳定的路径可供遵循，而不是通过搜索重新发现相同的链接。

我们分两步构建了这个图：

将每个段落存储为新的原语。一个确定性流程将每份文档拆分为段落，并为每个段落分配唯一标识符。这些段落成为信息的原子单元，将论断链接到确切的支撑段落，而不是整份文档。
用类型化边连接段落。我们用类型化边连接段落、论断和 wiki 页面：论断 cite 段落，较新的文档 supersede 较旧的文档，章节 refers_to 其他文档。每条边标识的是关系，而不仅仅是连接。我们以两种方式构建边。有些是从文档引用中确定性提取的。由于 wiki 论断已经带有文本引用，我们可以直接物化出 refers_to 和 supersedes 这样的类型化边，而无需再调用模型。

构建该图耗时不到一秒，并解析了测试库中所有显式交叉引用，因此智能体可以沿着链接前进，而不必在每个问题上重新发现连接。

该图的职责是证据导航，而不是对组织所知的一切进行建模。wiki 仍然提供综合。与提取密集型知识图谱流水线不同，这一层复用现有的引用和引文，而不是用模型提取并对齐实体。构建过程不需要额外的模型调用，不过从 wiki 派生的边仍依赖于其模型生成引文的准确性。

两个工具让智能体可以导航这张地图：locate 找到与问题匹配的起点，expand 沿其连接前往支撑段落和相关文档。当只有一条路径时，expand 会自动跟随；当路径分叉时，智能体选择下一步前往何处。这种定位相关节点并收集相连上下文的模式也出现在 GraphRAG 系统中，例如 Microsoft 的 GraphRAG。

@tool(parse_docstring=True)
async def locate(terms: str, within: str | None = None) -> dict:
    """Find where to start: match the question's words against document titles,
    section headings, wiki pages, and claim statements."""
    ...

@tool(parse_docstring=True)
async def expand(node: str, edges: list[str] | None = None, hops: int = 1) -> dict:
    """Open one node and list its typed edges (cites, refers_to, supersedes,
    amends, attaches_to, and their inverses). With hops > 1 and one edge type,
    walk that edge while there is a single path, and stop at a branch."""
    ...

更高的准确率、更低的成本、更快的回答

添加显式证据路径在每一项指标上都优于仅使用 wiki。准确率提升了 27%，引文一致性翻倍，回答时间中位数下降了 40%，每个正确答案的成本下降了 58%。证据图通过更有针对性的检索补充了 wiki 的上下文，在不使智能体完全确定性的情况下同时提升了准确率和一致性。

何时添加记忆才值得付出成本？

编译式 wiki 最有力的场景是重复的跨来源推理。在我们的实验中，wiki 帮助智能体应用领域关系，而不是通过搜索重建它们。但仅靠记忆层并不能使证据检索保持一致。添加显式图边提升了引文一致性和准确率，同时减少了检索工作。

wiki 为轻量级证据图提供了坚实基础，该图从其现有引文和文档引用中确定性派生而来。这让我们能够添加显式证据路径，而无需额外的模型调用，也无需对组织所知的一切进行建模。

wiki 是否值得投入取决于复用。我们报告的答案成本不包括编译，添加文档每份约花费 $0.09。对于简单查询，摄取和持续维护的成本可能超过检索节省，因为仅靠搜索同样准确且更快，尤其是在企业规模下。

当多个智能体反复回答跨越相同离散来源的问题时，这种权衡会发生变化。共享 wiki 保留了这些来源之间的关系，而图边则引导智能体找到支撑证据。在我们的测试中，这种组合以更低的每个正确答案成本产生了更准确的答案。随着复用次数足够多，避免重复重建上下文所带来的节省可以抵消构建和维护记忆的成本。

下一步是什么

接下来，我们希望更动态地构建 wiki，只编译和保留智能体回答跨来源问题所需的上下文，而不是整个仓库。

我们还希望探索将声明和类型化边作为其他类型智能体记忆的基础。将知识与证据关联起来，并检测其何时发生变化，有助于为语义记忆（事实）、情景记忆（发生了什么）和程序性记忆（如何做事）奠定基础。

想把 wiki 加入你的智能体吗？查看我们的 OpenWiki 资源：

致谢

感谢 Colin Francis 和 Nick Hollon 对 OpenWiki 及其评估的思考！