先说一个很常见的转折点。知识库刚上线的时候，把公司几十份文档切一切塞进向量库，问答效果挺惊艳。文档涨到几百上千篇之后，问题开始冒出来：单看某一段都对，但一旦问的是「谁和谁什么关系」「这事的前后顺序是什么」，Agent 就开始编。
典型提问长这样：「客户 A 用的那套方案，去年改过哪几个模块？」「这个型号的故障，通常是哪家供应商的哪批零件引起的？」「这份合同和我们标准模板，差在哪些条款？」
这类问题的答案从来不存在于任何单独一段文字里，它散落在十几篇文档的交叉关系上。加向量库解决不了——你加多少篇文档，都提高不了「把关系拼出来」的能力。
这时候要补的不是更多文字，而是结构。这篇讲清楚三件事：什么时候该给 Agent 上知识图谱、上的时候具体怎么做、以及最容易翻车的几个地方。（如果向量库的切片、召回、排序还没做扎实，先看 知识库检索怎么做才准确，那是地基。）
先分清：向量库和图谱管的是两件不同的事
向量检索的本质是语义相似度——把问题变成一串数字，找和它最像的几段文字。它极其擅长一件事：「关于 X，文档里怎么说的」。
它的短板也很明确：
- 关系问题。「A 和 B 之间是什么关系」这种问法，答案不在任何一段文字里。
- 多跳问题。要先找到 A，顺着 A 找到 B，再从 B 找到 C——向量检索只跳一步。
- 聚合问题。「一共有多少个客户用了这个方案」需要遍历全部，而不是按相似度排个序。
- 约束问题。「只看 2025 年之后、华东区、且已签约的」——这是结构化筛选，靠语义相似度做不准。
知识图谱换了个思路：它不存「文字片段」，存实体和它们之间的关系。客户是一个实体，方案是一个实体，「客户 A 采用了方案 B」是一条边，边上还能挂属性（时间、金额、状态）。
一旦这么存，上面四类问题的解法就变了：关系问题直接查边，多跳问题沿边遍历，聚合问题做统计，约束问题做过滤。这不是「更聪明的检索」，而是换了一种查询方式。
顺带说清两者的分工：向量库负责「找文」，图谱负责「找关系」。真正好用的系统通常是两个都有，怎么合后面会讲。
五个信号，出现两个以上就该考虑图谱
- 用户开始问关系型问题。不是「保修几年」，而是「A 的合同和我们标准模板差在哪」「这个零件出过问题的，都装在哪些型号上」。这类问题在向量库里答不好，是原理性的，不是调参能救的。
- 同一实体在不同文档里叫不同名字。客户在合同里叫全称、在工单里叫简称、在邮件里只剩缩写。向量检索会把它们当三件不同的事，而图谱的第一步就要求你把它们合并成一个节点——这个动作本身就是价值。
- 你需要答案带约束。要按时间、地区、状态、金额筛选，而不是只要「最相似的几段」。
- 你需要追溯链条。不只是要结论，还要能说清「这个结论是从哪几条关系推出来的」。
- 同样的关系要被反复查询。图谱的建设成本是前置的一次性投入，查询次数越多越划算。一年只问两次关系问题，就别做。
反过来，出现下面任一情况就先别碰图谱：文档只有几十篇（人脑加关键词搜索就够了）、问题全是事实型问答（向量库足够）、知识更新极频繁又没想好增量方案（图谱的更新比改文档麻烦得多）、没人能定义清楚实体和关系（这是最常见的失败原因）。
落地六步：从「想上图」到「能用」
顺序不能乱，尤其是前三步。
第一步，定实体和关系，而且只定最必要的。这一步是整件事成败的分水岭。最常见的错误是照着行业标准画一张几十种实体、上百种关系的完整本体——做三个月，一个能回答的问题都没有。正确做法是从问题反推：把用户最常问的十个关系型问题写下来，看回答它们需要哪些实体和边，只建这些。第一批控制在 5 到 8 类实体、10 条以内的关系类型。
第二步，抽取。让模型从文档里把实体和关系抽出来，输出成结构化三元组（谁—什么关系—谁）。这一步是「把非结构化文字变成结构」的关键，也是全部工作量的六成以上。选模型时要注意：抽取任务要的不是嵌入质量，而是能稳定输出固定结构，选型思路可以参考 嵌入模型和向量库怎么选 里那套按语言、成本、效果权衡的方法，只是评估指标要换成格式合规率与字段准确率。
第三步，消歧与合并。把「某某技术有限公司」「某某公司」「缩写」合并成同一个节点。这一步不做，图谱就是垃圾——同一个实体散成五个节点，关系全断。合并靠三招：名称归一化（去空格、全半角统一、公司后缀统一）、别名表（人工维护的映射，最有效）、以及用向量相似度做候选推荐。但合并动作必须留记录、可回滚，不能全自动。这套「入库—清洗—更新」的机制，站内 企业内部知识库怎么搭 里讲得很细，可以直接沿用。
第四步，存图。选图数据库时看三件事：查询语言是否成熟、能不能同时做属性过滤和全文检索、运维成本多大。中小规模场景（几十万节点以内）用支持图查询的扩展或轻量图库就够，别一上来就选重型分布式方案——你在解决的是知识组织问题，不是高并发问题。
第五步，查询。两种方式配合用：一是固定模板查询，把常见问题写成参数化查询，稳定、可解释、快，能覆盖八成高频问题；二是让模型生成查询语句，灵活，但必须加白名单和超时保护，否则它可能写出一条把整库扫一遍的语句。工程上建议先在模板查询上跑通，再逐步放开模型生成，并且把生成的查询语句留档，方便复盘——留痕的做法见 证据包怎么留。
第六步，接进 Agent。把图查询包装成一个工具，交给 Agent 判断什么时候用。这里有个关键点：工具描述必须写清「什么情况下用图谱、什么情况下用文档检索」，否则模型会在该查关系的时候去翻文档，效果还不如不上。工具怎么设计才好用 那份清单可以直接照用。
三个最容易翻车的地方
坑一，抽取不一致。同一份文档分两批抽，出来两套结果。原因是模型抽取本身有随机性、提示词不够严格、输出没做校验。解法是：固定模型版本与参数、把输出格式约束到最死、对结果做格式与类型校验，并且对抽取结果做抽样复核——抽检不是为了抓错，是为了知道「现在的错误率是多少」，比例和判定标准可以参考 人工复核抽检。判断整体效果好不好，还是要靠一套固定的评测集，方法见 Agent 评测怎么做。
坑二，时效和增量。文档改了、图谱没跟着改，就会出现「文档里已经作废的关系，图谱里还在被引用」。这块必须做两件事：给每条边记来源（哪篇文档、哪一版）；把溯源信息纳入定期巡检。什么时候该清、怎么标陈旧，知识库陈旧内容巡检 里那套机制可以直接搬过来用，只是巡检对象从文档段变成了边。
坑三，把图谱当万能药。它不解决「文档太多找不着」（那是检索的活），不解决「模型不会推理」（那是模型能力的活），也不解决「语气不对」（那是提示词的活）。它只解决一件事：关系型的、需要多跳和约束的问题。用在别处，投入产出比会很难看。
混合检索：不是二选一，而是分工
实际系统里两者是配合的，一条典型链路是这样：
- 先用向量检索找到相关文档片段，拿到「关于这个问题，原文怎么说」；
- 同时从问题里识别出关键实体；
- 拿这些实体去图里做一跳或两跳扩展，把关联的实体、关系、约束捞回来；
- 两边结果合并、去重、取舍，再塞进上下文。
最后一步的取舍很关键——图谱容易捞回一堆「结构正确但和问题无关」的关系，全部塞进上下文反而会干扰模型。上下文里放什么、放多少、怎么排，是独立的工程问题，站内 上下文管理怎么做 讲得更细。图谱给的是候选素材，不是答案。
另外别忘了，图谱本身也是「记忆」的一种形态。它和对话记忆、长期记忆的关系，以及怎么防止错误关系被反复引用变成「记忆污染」，和 记忆怎么设计 里那套治理逻辑是共通的。
优缺点与投入估算
优点：关系型和多跳问题从「答不了」变成「能答」；实体归一之后，同一个客户、同一款产品在不同系统里的信息能真正串起来；答案可溯源，能说清推理链；结构化查询比语义检索更稳定、更可复现。
缺点：前期投入明显比向量库重，主要是本体设计和抽取调优；更新链条长，文档改了要重新抽取、重新合并；抽取质量直接决定上限，而这一步很难做到百分之百；维护要人，本体和别名表需要持续迭代。
投入的粗略感受：一个中等规模场景（几百到几千篇文档、五到八类实体），从零到能回答前十个高频关系问题，通常是数周级别的工作量，其中抽取和消歧占大头。别指望一周上线。
适合人群
现在就该做：知识密集、且问题以关系为主的场景——法律（条款与案例的对应）、制造与器械（型号—零件—供应商—故障）、金融（客户—产品—账户—交易）、以及有大量工单、合同、图纸需要交叉查询的团队。
可以先放着的：客服知识库（问题多是事实型）、内部制度问答（文档少、更新频繁）、内容型站点（问和答都在同一段文字里）。这些场景把一个扎实的向量检索做好，收益远高于上图。
最后给一句判断标准：如果你的用户问的问题，答案能在某一段文字里找到，就继续做检索；如果答案必须靠「把几段信息连起来」才能得到，那才轮到图谱。图谱不是升级版的向量库，它是另一种工具。工具选对，比工具高级重要得多。
