「A 公司的负责人是张三，张三还担任 B 公司的董事」——这类信息用表格存很别扭，用一张「网」存却很自然。知识图谱就是把事实组织成点与线的技术：实体是点，关系是线。它不是新概念，但大模型时代它重新变得重要，因为它补的正是 AI 缺的两样东西：有据可依，和多跳推理。
事实是点，关系是线
知识图谱用「实体—关系—实体」的三元组组织信息：人是点，公司是点，「任职于」「持股」「供货给」是线。一个个事实连起来，形成一张可以沿着边走的关系网。查「张三任职的公司」，顺着一条边就能到；查「A 公司的合作伙伴的负责人」，沿着两条边走两步就能到。这种「顺藤摸瓜」的查询方式，是图谱区别于其他存储形态的核心。
和表格数据库的分工
表格擅长存结构固定的数据：订单、库存、名单，回答「有多少」「哪些满足条件」这类筛选统计问题。图谱擅长存关系复杂、层级深的数据：组织架构、产业链、人物关系，回答「它们之间是什么关系」「从 A 到 B 隔了几层」这类路径问题。一句话区分：表格按行找数据，图谱沿着关系走数据。
| 存储形态 | 擅长回答的问题 | 短板 |
|---|---|---|
| 关系型表格 | 有多少、按条件筛选、汇总统计 | 深层关系要写多层查询，结构一变就得改 |
| 纯文本 RAG | 找一段相关描述、定位原文说法 | 需要串联多个事实的推理容易断链 |
| 知识图谱 | 多跳关系问题、路径与关联分析 | 构建费人力，事实变了要持续更新 |
和 RAG 的配合方式
大模型本身的知识停在训练截止日，也不了解企业内部信息，所以需要外挂知识源。普通 RAG 检索的是文本片段，适合「找一段相关描述」；图谱 RAG 检索的是关系路径，适合「回答需要串联多个事实的问题」。两者互补而非替代：客服查一条退款政策，普通 RAG 足够；分析「某供应商的上游是否受某事件影响」，图谱才有优势。企业知识库问答的整体思路可以参考知识库问答的搭建逻辑。
实际项目里两者经常混合使用：文档原样进普通 RAG，从文档里抽取的高价值事实（组织关系、产品线、审批流程）进图谱，查询时先判断问题类型再路由。这条混合路线的好处是增量可做——图谱不必一次建全，先覆盖最高频的关系链条，剩下的靠文本检索兜底。
对 AI 意味着什么
两个层面的价值。第一是减少编造：把事实以结构化方式交给模型，让它基于明确的实体和关系作答，比让它从一堆文本里自己拼要可靠。第二是补推理短板：问「A 公司持股的公司的负责人是谁」，需要沿关系走两步，纯文本检索经常在第二步断掉，图谱天然擅长。模型本身的能力边界与规模有关，可参考参数量与能力的对应关系；自建图谱问答系统时，不少团队会搭配开源权重模型私有化部署，路径见开源权重模型的说明。
什么场景不该上图谱
图谱的代价必须先算清楚。构建成本高：把非结构化文档整理成实体和关系，目前仍依赖大量人工抽核，自动化抽取的结果需要校验。维护成本持续：现实在变，图谱不更新就会变成错误的源头。性价比门槛：简单问答和文档检索，普通 RAG 的成本只有图谱的零头。判断标准一句话：问题里如果总是出现「A 的 B 的 C」这种链条，图谱才值得；只是「找相关内容」，不上。
知识图谱速查
- 三元组组织事实：实体—关系—实体
- 表格回答「有多少」，图谱回答「什么关系」
- 普通 RAG 找片段，图谱 RAG 走路径
- 问题带关系链条才值得上图谱
- 构建靠人工抽核，不更新就会误导
三个常被问到的问题
- 知识图谱和大模型的参数知识冲突怎么办？：把图谱数据作为明确来源写进提示词，并要求模型只依据给定的实体和关系作答，冲突时以图谱为准。
- 图谱必须人工构建吗？：可以用模型辅助抽取实体和关系，但抽取结果必须人工抽核，尤其是金额、日期、任职这类关键字段。
- 多跳推理具体指几步？：两步以上就算。比如「供应商的上游的所在地」是两跳。步数越多，纯文本检索的断链概率越高，图谱优势越大。
