LangChain Blog来源发布时间

使用 OpenWiki 和图谱构建有证据支撑的智能体记忆

在企业政策、手册、维基、工单和代码之间工作的智能体必须 navigating 分散在各个系统和团队中的知识。找到相关段落只是开始。

要点速览

  • 一个已编译的 wiki 为智能体提供领域上下文,而仅靠检索必须重新构建这些上下文。 在跨多个来源的问题上,使用OpenWiki作为记忆层的代理比仅使用grep工具的代理准确率高5倍。
  • 添加证据图谱可帮助智能体通过维基追溯回支持性证据。 我们将引用和文档参考转化为智能体可循的显式图边。与仅使用维基相比,这使智能体引用相同证据的一致性翻倍,准确率提高了27%,每个正确答案的成本降低了58%。
  • 保存编译后的记忆,用于重复的跨来源推理。 该维基捕获了领域知识和复杂关系。添加证据图谱提高了准确性和检索一致性。然而,对于简单的查询,没有记忆的智能体同样准确且速度更快。

在企业政策、手册、维基、工单和代码之间工作的智能体必须 navigating 分散在各个系统和团队中的知识。找到相关段落只是开始。它们还需要确定哪些规则适用、哪些内容发生了变化,以及一个来源如何影响另一个来源。

持久化记忆层为智能体保存知识和关系,以便在不同任务中复用。没有它,智能体往往需要在每个问题上都重新构建这种理解,使其工作成本高昂且容易出错。这在银行和保险领域尤为棘手,因为政策和准则经常相互修订或取代。

我们测试了 OpenWiki——我们的开源wiki编译器——作为这一记忆层。在需要跨来源建立联系的问题上,wiki使智能体的准确率比仅用搜索提高了大约5倍。添加一个将wiki陈述与支持段落相连并链接相关来源的证据图谱,使准确率再提高27%,并使引用一致性翻倍。

为什么选择编译型维基?

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

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

OpenWiki,我们基于 深度智能体,创建这些带回源引用的维基。我们最初构建它是为了让编码代理不必在每次任务中都重新发现架构和代码行为。

每条 OpenWiki 陈述都基于一个 主张,即一个与支持它的源代码行及其哈希值相链接的断言。当这些行发生变化时,哈希值也会变化,使 OpenWiki 无需调用模型即可标记受影响的主张,从而节省 token 成本并使过时检测更具确定性。只有这些主张会被送到模型进行确认、修订或撤回,使记忆层能够随着其来源的变化进行自我修正。我们在 Building self-correcting memory in OpenWiki.

构建测试文档库

我们构建了一个包含 111 份长篇文档的合成保险文档库. 我们选择保险,是因为保单和批单经常 相互引用、修订和覆盖 彼此;这正是那种使检索变得困难的跨文档依赖。

为了给基准评分,我们创建了一个 包含972个事实的清单 ,并控制每个事实应出现的位置、文档之间如何相互引用,以及版本之间发生了什么变化。我们用大语言模型生成周围的正文,并运行自动化检查以确保所需的事实存在。

最后,我们故意让语料库变得混乱,混入了 过时版本、矛盾内容、间接引用链、多样化的措辞以及非常长的文档 ,以更好地匹配智能体在真实企业文档库中所面临的情况。

我们如何配置实验

我们在两种条件下评估了同一个检索智能体: Search (对原始文档的关键词搜索)和 Wiki (同一个智能体,但可访问由 OpenWiki 编译的、带来源链接的维基)。底层模型、指令、文档和问题保持不变——唯一改变的是智能体对编译后记忆的访问。

我们测试了 80个简单查找问题 和 50个关联问题 ,后者需要跨文档追踪依赖关系(例如,识别哪些内容依赖某项条款,或该条款变更时会受影响的部分)。我们将每个问题 提问三次 以测量运行之间的差异。

评估指标(“更好”的含义):

  • 准确率(0–1): 评分员根据来自972条事实账本的清单检查答案并引用证据(奖励必需事实,惩罚矛盾之处)。
  • 一致性(0–1): 三次运行中所引用证据的重叠程度(引用集合的平均两两Jaccard相似度)。这衡量的是智能体是否可靠地将其答案建立在 相同 的来源之上,而不是答案是否正确。
  • 成本 + 延迟: 模型花费(美元)和每个问题的实际耗时。

Wiki 的助益之处与局限之处

OpenWiki 将这111份文档的库编译成一个约为原始大小十分之一的 wiki,成本为4.15美元。之后添加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 文件中的文本引用。该图谱通过将这些引用实体化为带类型的边,使其变得持久。这为智能体提供了一条稳定的路径,而不必再用搜索重新发现相同的链接。

我们分两步构建了这个图谱:

  1. 将每个段落存储为一个新的基本单元。 一个确定性过程将每个文档切分为段落,并为每个段落分配唯一标识符。这些段落成为原子化的信息单元,将声明链接到确切的支持段落,而不是整个文档。
  2. 用带类型的边连接这些段落。 我们用带类型的边连接段落、声明和 wiki 页面:声明 cite 段落,较新的文档 supersede 较旧的文档,以及章节 refers_to 其他文档。每条边都标识了关系的类型,而不仅仅是连接。我们以两种方式构建边。有些是从文档引用中确定性提取的。由于 wiki 声明已经带有文本引用,我们可以直接实体化诸如 refers_to 和 supersedes 之类的带类型边,而无需额外的模型调用。

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

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

两个工具让智能体能够在这张地图上导航: locate 找到一个与问题匹配的起点,然后 expand 沿着它的连接追踪到支持性段落和相关文档。当只有一条路径时, expand 会自动沿着它走;当路径分叉时,代理自行选择下一步去向。这种定位相关节点并收集关联上下文的模式也出现在诸如 微软的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."""
    ...

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

这样的GraphRAG系统中。添加显式证据路径使所有指标相比仅有维基时都有所改善。准确率提高了27%,引用一致性翻倍,回答时间中位数下降了40%,每个正确答案的成本下降了58%。证据图以更有针对性的检索补充了维基的上下文,在不使代理完全确定性的情况下同时提高了准确率和一致性。

什么时候添加记忆才值得付出成本?

构建编译式维基最有力的理由是重复性的跨来源推理。在我们的实验中,维基帮助代理运用领域关系,而不是通过搜索重新构建它们。但仅靠记忆层并不能使证据检索保持一致。添加显式图边在减少检索工作量的同时提高了引用一致性和准确率。

维基为一个轻量级证据图提供了坚实基础,该证据图是从其现有的引用和文档引用中确定性地推导出来的。这使我们能够在不需要额外模型调用、也无需对组织所知的一切进行建模的情况下,添加显式的证据路径。

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

当多个智能体反复回答涉及同一批相互断开的来源的问题时,这种权衡就会改变。共享的wiki保留了这些来源之间的关系,而图边则引导智能体找到支持性证据。在我们的测试中,这种组合以更低的每个正确答案成本产生了更准确的答案。只要复用足够多,避免重复上下文重建所节省的成本就能抵消构建和维护记忆的成本。

下一步

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

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

想把wiki加入你的智能体中?查看我们的OpenWiki资源:

致谢

感谢 Colin Francis 和 Nick Hollon 对 OpenWiki 和评估工作提出的宝贵意见!

原始出处

LangChain Blog

内容说明

原始发布及相关权利归来源方。

机器翻译 · 请以原文为准