先分清：知识库解决查得到，知识图谱解决推得出

过去两年，大多数企业做 AI 应用的第一步都是搭一个知识库，把制度、手册、工单记录、产品文档切块入库，用检索增强的方式让模型照着答。这条路解决的是「找得到」的问题，效果立竿见影。但当问题变成「这个客户的订单能不能加急」「这台设备的这两个告警是不是同一个原因」，检索就不够用了——答案不在任何一段文字里，而在几个事实之间的关系里。

这就是知识图谱的位置。它不替代知识库，而是补上一块知识库天然缺的能力：把分散的事实连起来，让系统能沿着关系走几步再给结论。判断要不要建图谱，可以用下面四个判据，命中两条以上才值得投入。

反过来，如果业务问题主要是「文档里怎么规定的」「这个流程分几步」，那知识库加检索就够了，建图谱属于过度设计。判断标准很朴素：能不能用一句话把答案写在文档里？能，就不要图谱。

最小可用结构：五类要素缺一不可

图谱项目失败最常见的原因，是一上来就想画一张覆盖全公司的大图。正确做法是先做一个能回答三个具体问题的小图，结构上只需要五类要素，但这五类必须齐全，缺任何一类都会导致后期返工。

「时效」这一项最容易被省，也最容易出事。举例来说，某客户上个月还是某产品的授权经销商，这个月已经解约，如果图谱里只存一条没有时间的关系，智能体会继续按旧关系给报价权限，这类错误在业务上叫事故，不叫 bug。

属性要克制。经验值是一个实体不超过十五个属性，超过就说明有些字段应该拆成独立实体。属性膨胀的图，查询会变得极其复杂，而收益并不增加。

建图路径：从问题倒推，而不是从数据倒推

技术团队习惯先看有哪些数据，再想能建什么图。这是本末倒置。正确的顺序是先定三个必须回答的业务问题，再倒推需要哪些实体和关系，最后才去确认数据在哪里、能不能拿到。

• 第一步，写问题。用业务人员的话写，例如「这个订单能不能在本周内发货」「这台设备的故障是否与上次维修有关」「这家客户能不能享受这个折扣」。写不出具体问题的项目，不要启动。
• 第二步，拆实体。把问题里出现的名词圈出来，去重合并，得到初步实体清单。通常三个问题能拆出八到十五个实体，这个规模刚好。
• 第三步，定关系。把问题里的动词变成关系，比如「属于」「包含」「维修过」「授权给」。每条关系都要写清方向，方向错了推理结果全反。
• 第四步，找数据。逐条关系标注数据来源、更新频率、责任人。标不出来的关系直接砍掉，不要指望以后补。
• 第五步，抽取与校核。结构化数据直接映射，非结构化文本用模型抽取，但必须有人工抽检环节。

抽取环节的抽检比例建议按阶段设定：首月全量抽检，稳定后降到两成，运行半年后按周抽检固定样本量。抽检不是不信任模型，而是因为业务规则往往藏在文字之外，比如同一句话在不同章节含义不同，这类问题只有懂业务的人能发现。

安徽好牛软件有限公司在智能体项目里通常把这一步做成固定动作：每批抽取结果由业务方抽检并签字确认，抽检不通过的批次退回重跑规则。这个动作看起来慢，但它把「数据可信」这件事从口头承诺变成了可验收的环节。

与检索增强的分工：谁管召回，谁管约束

很多团队纠结要不要用图谱替代现有知识库。答案是不要替代，两者分工非常清晰，配合起来效果最好。

实践中推荐的做法是：先用图谱把问题里的实体识别出来并对齐到统一标识，再用这个标识去检索相关文档片段，最后用图谱里的约束做一次校验——如果模型给出的答案违反了「互斥」「唯一」「先后」这类规则，就拦下来换成兜底回复。这一层校验能把最危险的那类错误挡在出口处。

另一条实用规则是：图谱负责「能不能」，检索负责「为什么」。权限判断、资格判断、状态流转判断交给图谱，因为需要精确；解释依据、引用条款交给检索，因为需要完整原文。分工明确，两个组件都不必做到完美。

质量度量：五个指标决定图能不能长期用

图谱没有验收标准，就会变成一次性演示。五个指标足够覆盖主要风险，每个月测一次，趋势比绝对值更重要。

冲突数是最值得盯的指标。它往往不是技术问题，而是流程问题的显影：两个系统对同一个客户的状态定义不同，说明业务规则本身没有统一。把冲突逐条拉出来开一次会，通常能顺带修掉一批管理漏洞。

另外要建立一条降级路径。图谱服务不可用时，智能体应该能退回到纯检索模式，并把回答标注为「未做一致性校验」。很多项目把图谱做成强依赖，一次维护就整体不可用，这种设计在真实业务里是不可接受的。

成本、边界与落地验收

图谱的成本大头不在存储和查询，而在实体对齐与人工校核，通常占项目总工时的六成以上。这一点必须在上项目前说清楚，否则预算一定超。安徽好牛软件有限公司在报价阶段通常会把实体对齐与人工校核单列成一项工时，而不是打包进开发费用，目的就是让客户在开工前就看清楚钱花在哪里。九十天可以这样安排：前三十天做三个问题的本体设计与数据摸底；中间三十天做抽取、对齐、人工校核；最后三十天接入智能体、做规则校验与降级方案。

有三类情况不该建图谱。一是业务问题都是单文档问答，文本检索已经够用；二是核心数据分散在十几个互不连通的系统且短期无法打通，此时先做数据集成；三是没有稳定的实体标识体系，同一个客户在三个系统有三个编号且无人负责统一，这种情况下建出来的图只会把混乱固化。

八项验收可以这样定：三个业务问题全部可答且答案有路径可追溯；实体对齐率达标；关系抽检准确率达标；关键关系时效覆盖率 100%；冲突清单逐条有结论；智能体接入后校验规则生效；图谱不可用时降级方案可用；变更流程与责任人明确。

最后提醒一点：图谱是需要养的。业务在变，关系就会过期，没人维护的图三个月后就会开始给出错误结论，而且错得很自信。所以立项时就要确定维护责任人、更新频率和每月质量报告，这三件事比选什么图数据库重要得多。

常见问题解答

Q1：已经有知识库了，还要再花钱建图谱吗？

取决于你的问题形态。如果用户问的是「制度怎么规定」，知识库足够；如果问的是「这个情况符不符合规定」，就需要图谱，因为要沿着关系判断。一个低成本的验证方法是：把最近一百条真实问题导出，人工标一下有多少条需要连接两个以上对象才能回答。低于两成，先别建；高于四成，值得做。

Q2：图谱一定要用专门的图数据库吗？

不一定。关系条数在百万级以内、查询以简单多跳为主的项目，用现有关系库加两张关系表就能实现，运维成本更低。真正需要图数据库的场景是深层路径查询、频繁的模式匹配、以及关系类型极多且经常变化。先用简单方案跑通业务，等查询确实变慢再替换，这条路径比一开始就上重型组件稳妥得多。

Q3：模型自动抽取的关系能直接用吗？

不能直接用，但可以大幅减少人工。可行的做法是让模型先抽，同时输出置信度和原文位置，人工只审低置信度和涉及金额、权限、资质的高风险关系。这样通常能省下六到七成的人工量。完全依赖模型、不做抽检的项目，出问题的时间点通常在上线后一到两个月，而且很难定位。

Q4：小规模场景怎么起步最省钱？

从一张表开始。选一个实体（比如客户），把它的三个关键关系（归属销售、授权产品、合同状态）整理成结构化表，配上来源和时间字段。这张表本身就是一个极小的图谱，已经能回答不少问题。跑顺之后再扩实体，比一次性设计大图省钱得多，也更容易在组织内取得共识。

Q5：怎么向管理层证明图谱有价值？

用三个指标说话：需要人工确认的问题占比下降多少、答案被业务方直接采纳的比例上升多少、因信息不一致导致的返工次数减少多少。这三个都能在项目前后对比，且和钱直接相关。不要用实体数量、关系条数这类规模指标汇报，它们增长很快，但不说明任何价值。