你是否有过这样的困惑？

明明记得某个知识点在某篇文章里，可当你需要它的时候，搜索引擎只能给你一堆关键词匹配的碎片。传统RAG（检索增强生成）就像一个"记性不好"的助手——你问什么，它从海量文档中找最相似的段落，但它不懂知识之间的关系。

而这恰恰是Graph RAG要解决的问题。

⚠️ 特别说明：本文是对 Graph RAG 概念的解读，源自对 AST-ASG-Graph-RAG 项目 README 的研究。该项目主要在探讨概念本身，而非一个完整的产品解决方案。

传统RAG的困境

让我们先理清一个问题：为什么传统RAG处理复杂知识效果不好？

传统RAG的工作流程是：

用户问题 → 向量检索（找相似段落） → 塞给LLM → 生成答案

问题在于：知识不是孤立的碎片。

你的知识库可能是这样的结构：

📁 公司知识库
├── 📁 人事制度
│   ├── 离职管理办法.md
│   └── 考勤管理制度.md
├── 📁 财务制度
│   └── 报销流程.md
└── 📁 技术文档
    ├── API接口规范.md
    └── 代码审查规范.md

当用户问"员工离职时，年假怎么算？“时：

• 传统RAG：搜索"离职”+“年假”，找到《离职管理办法》中提到年假的那段话
• 问题：它不知道年假的计算公式在《考勤管理制度》里

这就是所谓的"信息茧房"——模型只看到搜索结果，看不到知识之间的关联。

突破点：从"树"到"图"

想象一下，如果知识不是存储在"文件夹"里，而是存储在一张网上，会怎样？

当你问"年假怎么算"时，系统不仅能找到《离职管理办法》，还能顺着关系找到《考勤管理制度》里的计算公式，甚至追踪到财务结算的相关规定。

这正是Graph RAG的核心思想：让知识从"孤岛"变成"网"。

核心概念迁移

在之前的文章中，我们介绍了AST-ASG-Graph-RAG如何用代码结构增强RAG。其实这个思路完全可以迁移到通用知识库：

1. “AST"对应"文档结构”

就像代码有函数和类，一个长文档也有自己的结构：

• 标题层级
• 定义与案例
• 章节之间的逻辑

通过解析这个结构，检索时不会只截取半句话，而是抓取一个完整的"知识单元"。

2. “ASG"对应"概念关联”

现实中，知识点之间的关系是多维的：

三种层级的关联检索

利用Graph RAG的思路，你可以在三个维度上寻找"相关知识"：

维度一：结构关系（AST思维）

同一章节下的上下游段落，或同一目录下的其他文档。

例子：用户问"如何申请年假"，不仅返回"年假申请流程"，还要返回"审批权限"、“假期类型说明"等同章节内容。

维度二：引用关系（ASG思维）

文档中的超链接、Obsidian/Notion中的Backlinks。

例子：《离职管理办法》引用了《考勤管理制度》中的年假折算公式，检索时自动关联。

维度三：语义重叠（向量思维）

两个知识点虽然目录不同，但讨论的是同一个底层原理。

例子：虽然"股票期权"和"绩效考核"在不同目录，但AI发现它们都涉及"员工激励”，可以自动关联。

实际效果对比

以"公司规章制度"知识库为例：

如何构建自己的知识图谱？

根据2025年最新技术趋势，有三条路径：

路径一：自动化提取实体

利用LLM扫描你的文档，自动识别核心概念（Entity），比如：

• “年假”、“离职”、“结算” → 实体
• “年假属于考勤制度” → 关系

路径二：结构化关系入库

将现有目录树直接转化为图数据库（如Neo4j）的节点和边。

路径三：隐性链接

利用向量相似度 + LLM分析，自动给文档打上"相关概念"标签。

“知识图谱通过节点与边的语义关系可以直接构建出更精准的上下文子图，避免仅用向量相似度’碰运气’。” —— ELE-yufo

总结

传统RAG容易导致"只见树木不见森林"——模型只能看到检索到的碎片，看不到知识之间的联系。

Graph RAG的核心价值，就是让AI像人脑一样进行联想推理：

• 不是找"包含关键词的文档"
• 而是理解"这个知识背后关联着哪些知识"

当你下次再问"年假怎么算"时，系统能给的不仅是一段话，而是一整个知识网络。

参考资料：CSDN、博客园 NebulaGraph、ELE-yufo、腾讯新闻

• RAG
• AI
• 知识图谱
• 知识管理
• Graph RAG