文章摘要
近期,Anthropic围绕多智能体系统的知识图谱工程举办技术研讨会并发布指南。多智能体协作存在上下文窗口不足问题,知识图谱可解决多跳问题,与RAG互补。官方方案降低领域适配成本,采用双模型策略。文章还介绍了实体抽取、消解、图谱组装等流程,阐述知识图谱在多场景的应用、评估优化及适用边界。

近期,智能体开发领域的头部厂商Anthropic公开了一场2小时的内部技术研讨会,同时发布了一份12页的官方指南文档,核心围绕多智能体系统的知识图谱工程展开。据官方透露,团队内已有80%的工程师正在使用自优化循环流程进行智能体开发,当前行业内的智能体架构已经从单纯的模型优化转向了智能体图的构建方向。

多智能体系统的上下文瓶颈

在多智能体协作场景中,上下文窗口不足是最突出的痛点之一。我们可以通过一个竞品情报系统的例子直观理解:这套系统的调度器下挂载了5个独立工作节点,分别负责定价分析、产品调研、财务复盘、营销趋势和战略综合。其中战略综合节点需要关联三条关键事实:降价15%的竞争对手、申请专利暗示新产品线的企业、季报中披露研发投入翻倍的公司是同一家主体。但现实是没有任何一个单一工作节点能掌握全部三条信息。

如果仅依靠调度器的上下文窗口实现节点间通信,窗口大小会随着工作节点数量线性膨胀,很快就会达到模型的上下文上限。而如果让每个工作节点将发现的信息转化为实体和关系存入共享知识图谱,战略综合节点就可以直接通过图遍历快速找到关联关系,完全不需要依赖中间的上下文传递。

这也是当前行业热议的"知识图谱工程"的底层逻辑:大模型工程的重心正在不断向外延伸,从最初的提示词工程,到上下文窗口优化,再到流程框架构建、自优化循环,最终落地到知识图谱的结构化管理。

相比传统的检索增强生成(RAG)技术,知识图谱有更突出的多跳问题解决能力。RAG依靠语义相似度检索文本片段,只能回答单跳问题,但多跳问题的答案往往分散在语义不相关的段落中,无法通过简单的相似度匹配找到关联。知识图谱中的实体连接是显式存在的,图遍历过程不需要依赖表面语义相似度,能够真正实现跨文档的事实关联。两者可以形成互补:RAG负责直接的文本检索,而知识图谱负责结构化的推理过程。

全流程的Claude API实现方案

传统的知识图谱构建流程需要训练命名实体识别模型、关系分类器,手写实体消解规则,每个阶段都需要大量标注数据,更换业务领域时需要重新进行全套流程,成本极高。而Anthropic的官方方案将整个管线压缩为一系列结构化的API调用,仅需要通过Pydantic Schema定义输出格式,就可以完成全流程处理,将领域适配成本从"数周的标注与训练"降低到"数小时的提示词调整"。

在模型选择上,团队采用了双模型策略:实体抽取阶段使用Haiku模型,凭借其高吞吐量和schema约束能力,优先保障速度与成本控制;实体消解、摘要和查询阶段则使用Sonnet模型,依靠其更强的上下文理解和跨文档综合能力,保障推理质量。

实体抽取的四大核心原则

实体抽取阶段的核心在于通过结构化输出API返回校验通过的强类型对象,避免了传统的正则匹配、JSON解析错误和防御性检查,大幅提升了管线的鲁棒性。整个抽取过程需要遵循四大规则:

  1. 只抽取对当前文档重要的实体,用于控制召回率并降低噪声,提升抽取精准度
  2. 为每个实体撰写基于当前文档的描述文本,作为下游实体消解阶段的消歧依据,比如区分"阿姆斯特朗——首位登月宇航员"和"阿姆斯特朗——爵士小号手"这类同名不同主体的实体
  3. 实体关系的谓语使用简短的动词短语,避免使用"涉及"这类模糊表述,确保后续推理的准确性
  4. 每条关系必须连接两个已经抽取完成的实体,防止产生悬空的无效边

实体消解:突破字符串匹配的局限

在原始抽取结果中,同一个实体往往存在多种表面形式,比如"NASA"和"美国国家航空航天局"、"尼尔·阿姆斯特朗"和"尼尔·奥尔登·阿姆斯特朗",甚至像"埃德温·奥尔德林"和"巴兹·奥尔德林"这种完全没有字符重叠的同一主体,传统的编辑距离、Jaccard相似度等匹配方法完全失效。

官方的解决方案是将实体按类型分组后,使用Sonnet模型进行聚类,将抽取阶段生成的实体描述作为消歧上下文。通过这种方式,原本24种不同的实体表面形式可以被压缩为22个规范实体。在实际应用中需要注意两类失败模式:一是漏配,即部分实体名称没有被归入任何集群,需要在生产环境中设置兜底策略,将未匹配的名称单独作为单元素集群;二是过合并,即将原本独立的实体错误归为一类,比如将"双子座12号"并入"双子座计划",既会丢失节点信息,也会降低整体精度。

白皮书特别强调,实体消解的消歧能力完全来自抽取阶段生成的实体描述,省略描述会让消解流程退化为简单的表面形式匹配,直接落入原本想要规避的陷阱中。

图谱组装与智能摘要

完成实体别名映射清洗后,需要将所有关系端点替换为规范实体名称,然后存入NetworkX MultiDiGraph图数据库。选择MultiDiGraph的原因有两个:一是支持两个实体之间存在多种关系谓语,二是关系方向具有重要意义,比如"阿姆斯特朗指挥阿波罗11号"和反向表述完全不是同一事实。每条边都需要附带具体的谓语类型和来源文档信息,确保后续可追溯。

以阿波罗计划相关的图谱为例,最终构建的图谱包含22个节点、34条边,边节点比为1.55,处于健康区间,且整体为单连通分量,这也证明实体消解的效果良好,如果出现碎片孤岛则说明存在未正确合并的实体。其中枢纽节点为"阿波罗计划"和"阿波罗11号",度数均为9。

智能摘要阶段仅针对度数大于等于3的高连接节点开展,将该节点的所有提及内容和图邻域信息喂给Sonnet模型,生成2-3段综合画像、3-5条可追溯的关键事实以及对应的时间范围。以"阿波罗计划"节点为例,其完整画像是综合6篇文档的信息得到的,没有任何单一文档包含全部这些内容,真正实现了从零散标签到结构化知识的转化。

基于图谱的多跳查询

基于知识图谱的多跳查询机制非常直观:提取种子实体的k跳邻域,将其序列化为(source)--[predicate]-->(target)格式的三元组,再提交给Claude进行推理。经过实测,k=2是大多数多跳问题的最优值,当k≥3时会导致子图快速膨胀,超出模型上下文窗口上限。

接地查询与非接地查询的对比非常能体现图谱的价值:不依赖图谱的模型可以依靠预训练知识给出关于阿波罗11号宇航员的漂亮答案,包括出生地、教育背景、军事经历等信息;而基于图谱的查询结果则严格限制在已抽取的三元组范围内,比如只能返回"尼尔·阿姆斯特朗→踏上→月球"这一条明确的人地关系。后者虽然看起来不够全面,但优势在于完全可溯源、严格基于输入语料的实际内容,还能明确标注图谱中不存在的信息,在私有语料场景中具有不可替代的价值。

知识图谱在五大智能体模式中的应用

白皮书详细说明了知识图谱在五种主流智能体架构中的集成场景,这也是全文最具实践价值的部分:

智能体模式 图谱角色 核心价值
增强型大模型 检索源 用图遍历替代向量检索,解决多跳问题
提示词链式调用 门控信号 在链式步骤间校验新实体与已有节点的冲突
任务路由 分类器输入 根据实体类型和连接度数路由到对应专家,减少LLM调用
调度器-工作节点 共享内存 工作节点直接读写图谱,保持调度器上下文窗口简洁
评估器-优化器 事实接地层 对照带来源的图谱边核查生成内容的真实性

共享内存:破解多循环协调难题

多智能体循环之间的协调问题可以通过知识图谱作为共享内存来解决,但这种模式也存在共享状态污染的风险,比如某个节点的错误写入会被其他节点当作可靠信息使用。官方给出的解决方案与行业通用思路一致:通过类型化Schema定义数据结构、明确各节点的写入权限、添加检查点机制保障数据一致性。

事实接地层:从主观判断到客观核查

没有知识图谱的评估者只能依靠主观判断"内容看起来是否合理",而接入图谱的评估者可以直接校验三元组是否存在于图谱中。比如生成器声称"阿姆斯特朗指挥了双子座12号",虽然听起来符合常识,但通过图谱核查可以发现这条关系并不存在,实际正确的关系是"巴兹·奥尔德林乘坐了双子座12号"和"尼尔·阿姆斯特朗指挥了阿波罗11号"。

白皮书还提出了一个关键设计:对于图谱中不存在的声明,既不静默接受也不静默拒绝,而是直接升级给人工审核,真正实现基于事实的校验而非主观推测。

持久世界模型:让记忆跨会话存活

长期运行的自优化智能体循环需要能够跨会话保存的记忆,传统的上下文窗口无法满足这一需求。基于知识图谱的解决方案流程清晰:新文档进入系统后,先进行实体抽取,再对照已有的规范实体集进行消解,仅添加新的关系边;只有当来源文档集发生实质性变化时,才会重新对实体进行摘要。正如白皮书原文所述:"智能体会遗忘,但图谱不会。"

抽取质量评估与成本优化

通过对照黄金标准数据集进行评估,Haiku模型在实体抽取阶段的精确率达到了满分,说明其抽取结果全部准确可靠,但召回率相对偏低。主要存在两类漏检情况:一是文档中顺带提及的次要实体,会被prompt规则自动过滤;二是跨文档范围错配的实体,比如土星五号在阿波罗11号文档中提及程度不够核心,不会被抽取,但在专门的文档中可以被正确识别。

在成本控制方面,双模型策略发挥了关键作用:实体抽取阶段使用Haiku控制批量处理成本,查询阶段使用Sonnet保障复杂推理质量。整体成本结构呈现线性与次线性结合的特点:抽取成本随语料量线性增长,1万篇2000token的文档仅需要个位数美元的成本;消解阶段按类型批量处理,先通过确定性规则分组再进行模型仲裁;摘要阶段仅针对高连接节点开展,属于次线性增长;查询成本则取决于子图的大小。

在存储层面,NetworkX可以轻松支持几十万条边的规模,当数据量更大时,可以切换到Neo4j、Neptune等专业图数据库,或者使用三张Postgres表分别存储实体、关系和别名,配合递归CTE实现图查询功能,整个管线的代码不需要做任何修改,仅需要更换持久层实现。

知识图谱的适用边界

并非所有场景都适合使用知识图谱,官方给出了清晰的场景判断标准:

  • 单文档问答场景:直接使用RAG或原生上下文窗口即可满足需求,答案通常集中在单个文本片段中
  • 多文档单跳问题:使用RAG结合重排序技术就可以高效解决,不需要复杂的结构推理
  • 简单分类与路由任务:单Agent架构就可以完成,不需要引入图结构增加复杂度
  • 当需要跨源链接事实、共享结构化状态、基于可追溯证据进行决策时,知识图谱才是最优的基础设施选择

总结来说,当你的智能体系统需要突破上下文窗口限制、实现跨文档的事实关联、保存长期记忆或者进行可溯源的事实核查时,知识图谱工程是值得投入的技术方向;而对于简单的检索或分类任务,更轻量的工具就足够满足需求。

以上内容不代表本平台立场,仅供读者参考