向量检索解决了找相似的问题但企业里更多的问题是找关系——而这正是知识图谱的主场。一、一个向量检索解决不了的问题假设你是一家制造企业的 IT 负责人员工向知识库提问“零件 A 的尺寸变更会影响哪些下游工序涉及哪些岗位需要重新培训”这个问题有几个特点它不是在找语义相似的文档而是在追踪一条关系链——零件 → 工序 → 岗位 → 培训制度。任何一个环节的文档单独拿出来都回答不了这个问题。纯 RAG 在这里会失败它会召回若干看起来相关的文档片段拼凑出一个缺乏结构的答案遗漏中间的关联节点。这就是知识图谱Knowledge Graph进入 Agent 架构的核心动机它不替代向量检索而是补充向量检索天然缺失的关系推理能力。二、知识图谱的基本结构知识图谱本质上是一张有向图由三元组构成(实体 A) --[关系]-- (实体 B) 例如 (零件-A) --[用于]-- (工序-冲压) (工序-冲压) --[需要岗位]-- (冲压工-二级) (冲压工-二级) --[需通过]-- (培训课程-设备操作规程V3) (培训课程-V3) --[依据]-- (制度文件-设备管理规范2024)将这张图构建出来之后上面那个问题就变成了一次图遍历从零件 A出发沿关系边向下追溯直到覆盖所有受影响的节点。实体类型可以非常多样——人、物、流程、制度、系统、表单、工单……只要两者之间存在可定义的关系就可以进图。三、图谱构建从文档到结构化关系网络构建知识图谱最大的工程挑战是从非结构化文档中自动抽取实体和关系。这一步的质量决定了图谱能否真正可用。3.1 实体与关系抽取NER RE命名实体识别NER负责识别文本中的实体关系抽取RE负责识别实体间的语义关系。传统方案依赖规则或小模型LLM 的引入让这一步的泛化能力大幅提升# 基于 LLM 的实体关系抽取示意importjsondefextract_entities_and_relations(text:str,llm_client)-dict:promptf 从以下企业文档中抽取实体和关系以 JSON 格式返回。 实体类型人员、岗位、流程、制度、系统、设备、产品 关系类型负责、依据、触发、影响、包含、需要、产出 文档内容{text}输出格式 {{ entities: [ {{id: e1, type: 岗位, name: 质检工程师}}, ], relations: [ {{source: e1, relation: 依据, target: e2}}, ] }} 只返回 JSON不要其他内容。 responsellm_client.complete(prompt)returnjson.loads(response.text)但 LLM 抽取的结果并不总是可信的——实体边界模糊、关系方向错误、同义实体未合并“设备操作规程和设备规程指同一文件。这就需要人工校正机制业务人员通过可视化界面对自动抽取的结果进行审查和补录让图谱逐步从基本可用走向精准可用”。3.2 实体消歧与合并同一实体在不同文档里可能有不同表述。如果不做消歧图谱里会出现大量孤立节点关系链断裂。常见策略字符串归一化去除空格、统一全半角、处理缩写、嵌入相似度合并向量化后相似度超过阈值则视为同一实体、规则约束同类型同上级组织的实体名称编辑距离小于 N 则合并。fromsentence_transformersimportSentenceTransformerimportnumpyasnp modelSentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2)defdeduplicate_entities(entities:list,threshold:float0.92)-list:基于语义相似度合并重复实体names[e[name]foreinentities]embeddingsmodel.encode(names)merged,visited[],set()fori,entityinenumerate(entities):ifiinvisited:continuegroup[entity]forjinrange(i1,len(entities)):ifjinvisitedorentities[j][type]!entity[type]:continuesimnp.dot(embeddings[i],embeddings[j])/(np.linalg.norm(embeddings[i])*np.linalg.norm(embeddings[j]))ifsimthreshold:group.append(entities[j])visited.add(j)# 取出现频次最高的名称作为标准名merged.append(max(group,keylambdae:e.get(freq,1)))visited.add(i)returnmerged四、图谱增强检索向量 图的混合查询图谱构建完成后如何融入 Agent 的检索链路4.1 两阶段检索架构用户问题 │ ▼ [Stage 1] 向量检索 找到最相关的 Top-K 文档片段 识别片段中出现的关键实体 │ ▼ [Stage 2] 图谱扩展 以识别到的实体为起点在知识图谱中做 N 跳遍历 扩展召回关联实体及其所在的文档片段 │ ▼ [Merge Rerank] 合并两路结果按相关性重排序 │ ▼ [LLM 生成] 基于扩展后的上下文生成答案标注来源路径Stage 2 中的N 跳遍历是关键参数。跳数太少关联信息覆盖不全跳数太多引入大量无关噪声。实践中通常从 2 跳开始根据业务场景调整并结合关系类型做剪枝参考关系的权重低于依据关系。4.2 推理路径的价值图谱检索还能输出推理路径即 Agent 是怎么一步步从问题出发找到答案的问题质量问题 QC-2024-0312 的根因是什么涉及哪些责任岗位 推理路径 质量问题-QC-2024-0312 └─[发生于]─ 产线-B3-封装段 └─[设备]─ 封装机-#07 └─[维保记录]─ 维保工单-2024-09-15超期未维保 └─[负责岗位]─ 设备工程师-王某 └─[所属部门]─ 设备管理部 结论根因为封装机-#07 超期未完成预防性维保 责任岗位为设备管理部设备工程师。这条推理路径可以直接附在答案后面作为溯源依据让 Agent 的回答从说了什么变成怎么得出的——在合规要求高的行业医药、金融、政府尤为重要。五、知识图谱在企业 Agent 中的典型场景合同影响分析大型企业里一份框架合同下面挂着几十个子合同、补充协议、对应的采购订单。某条款发生变更时人工排查影响范围往往需要数天。图谱将合同之间的引用关系、条款与业务流程的绑定关系显式化变更发生时 Agent 沿图谱追溯秒级输出影响清单。SOP 合规核查制造业的 SOP 文件之间存在大量引用——操作规程引用设备规格、引用安全标准、引用培训要求。当设备升级或国标更新时需核查哪些 SOP 需要同步修订。将引用关系建入图谱后Agent 可自动生成需修订文件清单 修订建议 依据条款的结构化报告。多跳知识问答我们公司采购 X 类物料需要经过哪几级审批最终审批人是谁依据的是哪个制度文件第几条这类问题跨越物料分类、审批流程、人员组织、制度文档四个知识域纯 RAG 几乎无法准确回答图谱将这四个域串联后Agent 可以沿链路完整推理。国内已有企业级 Agent 平台在此方向做了较深的工程化。以国产智能体服务商上海比孚的 AgentCore为例其知识图谱模块支持从文档自动抽取实体关系、业务人员可视化校正补录并将制度—流程—系统—岗位—表单—工单等业务要素串联成可查询的关系网络支持影响分析“故障根因链路”政策条款引用链等应用化输出图谱检索与 RAG 混合方案在私有化部署环境中完整运行。六、工程落地的几个注意点图谱冷启动从核心业务文档制度汇编、流程手册、组织架构开始构建不要试图一次覆盖所有文档。先建一个小而准的图比建一个大而乱的图更有价值。图谱与文档的同步文档更新时图谱需要同步维护否则会出现图谱里的关系指向已失效文档版本这类隐性错误。理想状态是图谱节点直接绑定文档的版本标识文档变更时触发关联节点的审查流程。查询性能图遍历在数据量大时可能成为瓶颈。常用优化手段包括对高频查询路径做缓存、限制单次遍历的最大节点数、对边的类型和权重做索引。图数据库的选型Neo4j、NebulaGraph、TuGraph 等也会影响大规模场景下的查询延迟。知识图谱的边界图谱不是万能的。适合用图谱的场景是实体关系复杂、需要多跳推理、答案需要可溯源、知识域相对稳定。如果知识以非结构化叙述为主或业务变化极快导致图谱维护成本远高于收益纯 RAG 可能是更务实的选择。一个务实的起点先用纯 RAG 跑通业务识别出哪些问题 RAG 持续答错再判断是否值得引入图谱补充这部分能力。七、向前看Agent 与图谱的深度融合当前图谱增强 RAG 的主流模式是把图谱作为检索的一个数据源。更进一步的方向是让 Agent 具备图谱推理能力不只是查已有的关系而是能根据已知事实和规则推断出图谱中尚未显式存在的新关系。这与知识推理、因果推断的研究方向正在逐步融合。另一个值得关注的方向是动态图谱随着 Agent 的运行图谱本身持续更新——Agent 处理的每一个案例、每一次异常都可以作为新的节点和关系写入图谱让图谱随业务运转而自动生长。这两个方向都还在工程化早期但已经有团队在法律、医药、工业等垂直领域做出了有说服力的原型。对于正在规划企业 AI 基础设施的团队来说现在是一个好时机去理解这条技术路线——即使暂时不实施。欢迎在评论区交流你在企业知识图谱落地中遇到的问题。