知识图谱是把"实体"和"实体之间的关系"组织成一张网的知识表示方式。"张伟—在—某科技公司工作—职位是工程师"，这样的"主体—关系—客体"三元组连成片，就是一张图。和表格最大的区别：关系是一等公民，不用 join 就能直接查出关联。
先看懂它的样子
最直观的理解就是节点加连线：节点是人、公司、地点、事件这些实体，连线是"创办于""位于""收购了"这样的关系。关系自带名字，机器读到就能懂，不用靠列名去猜。搜索引擎的知识面板、百科词条的信息框，背后很多都是知识图谱的思路。
三条边界：什么不是知识图谱
第一，能做语义检索的不叫知识图谱，那是向量数据库：向量存的是"像什么"，知识图谱存的是"是什么关系"。第二，图数据库不等于知识图谱：前者是存储引擎，后者是知识的组织方式；引擎能装知识图谱，也能装别的图。第三，大模型本身不是知识图谱：参数里隐含的知识是概率性、可错的，图谱里的每条关系都是显式声明、可追溯的。
对比表：知识图谱、向量数据库、RAG 怎么分工
先用一句话讲清三者关系：RAG 是干活的流程，向量数据库和知识图谱是给这个流程供料的两种知识库。
| 对比维度 | 知识图谱 | 向量数据库 | | 存什么 | 实体和明确的关系 | 文本转成的向量 | | 强项 | 多跳推理、精确问答 | 模糊语义匹配 | | 典型问法 | "A 公司的创始人还创办了哪些公司" | "找一段意思相近的文档" | | 短板 | 构建成本高、更新慢 | 容易答非所问 |
RAG（检索增强生成）是把检索到的知识交给大模型再作答的完整流程：既可以去向量数据库做语义检索，也可以去知识图谱做关系查询，还能并用——学术界把这种做法叫 GraphRAG。
三个常见误解
误解一是"知识图谱过时了，被向量检索取代"。恰恰相反，关系型问答正是向量检索的短板：多跳问题（比如"某产品创始人的前公司被谁收购"）靠向量召回经常断链，得靠图谱补关系推理。误解二是"建知识图谱就是装个图数据库"。引擎只是容器，真功夫在本体设计和实体对齐——"北京"和"北京市"算不算同一个节点，比选什么数据库重要得多。误解三是"小公司用不上"。手工建全域图谱成本很高，务实做法是小而专：只做一个业务域，比如产品故障库或法规条款库，反而最容易出效果。
它真正擅长的场景
金融风控的关联方穿透、电商的商品知识问答、医疗的药物相互作用查询、客服的政策条款追溯，共同点是答案必须精确、可解释、能追溯到具体关系，而不是"看起来像"的文本。知识图谱回答的是"它到底是什么"：当业务容不得含糊答案，关系明确的知识网就是绕不开的基础设施。
