如果你在企业里落地过 RAG 系统，大概率踩过这个坑：知识库里明明有答案，但 AI 给的要么不完整，要么牛头不对马嘴。根本原因不是模型不够强，而是传统分块检索天然有信息断裂的问题。这篇文章讲清楚这件事的来龙去脉，以及知识图谱增强检索（GraphRAG）是怎么解决它的。
一、传统 RAG 的核心缺陷：分块之后上下文断了
标准 RAG 流程大家都熟悉：把文档切成 chunk，向量化，存进向量数据库，查询时计算相似度，取 Top-K 片段拼进 prompt，让模型生成答案。
这个流程在文档结构简单、问题直接的场景下工作得还不错。但企业文档不是这种：
· 一份合同可能在第 3 条定义了某个术语，但在第 17 条才用到它——两者切成了不同 chunk，检索时只拿到了第 17 条，模型不知道定义
· 物业手册里「报修流程」分散在工单流程、部门职责、响应时效三个章节——向量相似度只能找到其中一个
· 财务规定里「报销上限」依赖「员工级别」的定义，但两段物理位置相距很远
这就是「分块检索导致的上下文断裂」问题。本质原因是：向量相似度衡量的是语义接近，但文档中大量知识依赖的是结构关系和逻辑引用，向量检索对这类关系是盲的。
二、 GraphRAG 的思路：把关系显式存储出来
知识图谱增强检索的核心思想很简单：在文档解析阶段，不只做向量化，同时自动抽取实体和实体之间的关系，构建成图谱结构存储。
以物业手册为例，图谱抽取后大概长这样：
| 节点：报修申请 → 工单创建 → 维修部门 → 响应时效边：报修申请 --触发--> 工单创建工单创建 --分派给--> 维修部门工单类型:水电 --对应响应时效--> 4小时工单类型:电梯 --对应响应时效--> 2小时维修部门 --负责人--> 张工 |
|---|
检索的时候，不只是向量相似度匹配，还会沿着图谱的边做「图遍历」：找到「报修」节点之后，自动沿边拉取「工单创建」「响应时效」「负责部门」等关联节点的内容。即使这些内容在原文里物理位置相距很远，依然能被完整召回。
三、工程实现要点
3.1 实体抽取与关系识别
实体抽取可以用 NER 模型，也可以用大模型（few-shot prompt + 结构化输出）。对于企业文档，推荐用大模型，原因是企业专有术语多，通用 NER 模型识别率差。
| # 用大模型做实体关系抽取的 prompt 示意EXTRACT_PROMPT = """从以下文本中抽取实体和关系，以 JSON 格式输出：格式：{'entities': [{'name': str, 'type': str}],'relations': [{'from': str, 'to': str, 'label': str}]}文本：{text}""" |
|---|
3.2 图谱存储方案选型
图谱存储有几个主流选择：
· Neo4j ： 生产级图数据库，Cypher 查询语言，社区成熟，适合关系复杂的场景。缺点是运维成本相对高
· NebulaGraph： 分布式图数据库，性能好，适合大规模节点。社区相对小
· 轻量方案： 如果图谱规模不大（< 百万节点），直接用 NetworkX 在内存里跑也够用，存储用 SQLite 持久化
3.3 混合检索：向量 + 图遍历
GraphRAG 不是替换向量检索，而是在向量检索之上加一层图遍历。典型流程：
| def hybrid_retrieve(query, top_k=5):# Step 1: 向量检索，找相关 chunkvector_results = vector_store.search(query, top_k=top_k)# Step 2: 从命中 chunk 中识别实体entities = extract_entities(vector_results)# Step 3: 在图谱中以这些实体为起点做 N 跳遍历graph_context = graph_store.traverse(start_nodes=entities,max_hops=2,relation_filter=['触发', '分派给', '对应'])# Step 4: 合并，去重，按相关性排序return merge_and_rerank(vector_results, graph_context) |
|---|
四、实际效果对比
| 传统分块 RAG问：「电梯故障报修后多久有人来？」答：「请提交报修工单，工作人员会及时处理。」（没拿到响应时效） | GraphRAG 增强检索问：「电梯故障报修后多久有人来？」答：「电梯类故障响应时效为 2 小时，工单派发至电梯维护组，负责人张工。」（完整） |
|---|
在我们实际测试中，针对关联型问题（需要跨段落推理的问题），GraphRAG 相比纯向量检索召回率从约 70% 提升到 99%+ 。当然，这个数字依赖文档质量和图谱构建的准确率。
五、适用场景与不适用场景
GraphRAG 不是银弹，有它适合的场景：
· 流程类文档：SOP、合同、规章制度——关系密集，图谱能发挥最大价值
· 多文档关联查询：需要跨多个文档找到一致答案的场景
· 实体属性查询：「XX 负责人是谁」「XX 政策适用于哪些部门」
不适合的场景：
· 非结构化的长文本理解（如文学分析）——关系稀疏，图谱收益低
· 实时性要求极高的场景——图谱构建有额外延迟
· 文档规模极小（< 50 页）——直接全文塞进 context 更省事
| 延伸阅读GraphRAG 的概念由微软研究院在 2024 年的论文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》中正式提出。原始实现见 github.com/microsoft/graphrag。本文介绍的是适合企业实际落地的轻量化版本，与原论文侧重点不同。 |
|---|
