RAG（检索增强生成）领域正在经历一次技术路线的分化。FalkorDB 在 4 月底发布了 GraphRAG SDK 1.0，并用一组评测数据证明：当问题需要跨多个文档或数据源拼接信息时，图结构检索比向量检索更有效。
为什么需要 GraphRAG
传统向量检索的核心限制在于：它把文档切分为独立的 chunk，然后通过相似度逐一匹配。这对于单一事实查询（“某某公司的 CEO 是谁”）足够有效，但当问题需要连接多个概念时（“A 公司的投资如何影响了 B 项目的技术选型”），向量检索无法理解 chunk 之间的逻辑关系。
图结构 RAG 将文档中的实体和关系提取为图谱节点和边，查询时在图上执行多跳遍历，天然支持跨文档的推理。
SDK 1.0 核心改进
- 更少的 LLM 调用：通过图谱的预计算结构，减少运行时的 LLM 推理次数
- 可预测的成本：基于图的确定性查询路径，避免向量检索的反复试探
- Grounded Answer：回答直接锚定到图谱中的具体节点和关系，便于溯源
- Apache 2.0 许可证：允许商业使用
评测数据
FalkorDB 自研的 GraphRAG-Bench 对比了 8 个 RAG 系统，GraphRAG SDK 在多项指标上排名第一。虽然这是项目方自设的评测基准，但其测试方法（多跳问答、成本测量、答案可溯源性）反映了 RAG 落地的真实需求。
| 能力维度 | 向量检索 | GraphRAG SDK |
|---|---|---|
| 单跳事实查询 | 优秀 | 良好 |
| 多跳推理 | 弱 | 强 |
| 答案溯源 | 困难 | 直接对应图谱节点 |
| Token 成本 | 波动大 | 可预测 |
| 增量更新 | 需要重嵌入 | 图谱增量添加 |
社区中也有独立项目验证了这一趋势。CodeGraphContext（通过 MCP 将代码库映射为图数据库，接入 Claude Code/Cursor）在 GitHub 上获得了 2,000+ Star，说明开发者对图结构上下文的实际需求在增长。
与 Graphify 的关系
GraphRAG SDK 和 Graphify（本周 3.8 万星的热门项目）解决的是不同层面的问题：Graphify 是面向 AI 编码助手的”技能”，侧重代码库的知识图谱化；GraphRAG SDK 是面向 GenAI 应用开发的底层框架，侧重构建基于图数据库的 RAG 管道。两者在技术栈上互补。
快速上手
pip install graphrag-sdk
# 连接到 FalkorDB 实例
from graphrag_sdk import GraphRAG
rag = GraphRAG(db_url="falkordb://localhost:6379")
# 索引文档
rag.ingest_documents(["doc1.pdf", "doc2.md"])
# 查询
result = rag.query("多跳问题...")项目还提供 code-graph 演示仓库，展示了如何将代码库构建为知识图谱并用 GraphRAG SDK 查询。
观察点
- GraphRAG-Bench 是项目方自建基准，需要更多第三方评测验证
- 图数据库的运维复杂度高于向量数据库，对小型团队可能增加运维负担
- 对于纯单跳查询场景，向量检索仍然是更简单的选择