RAG 技术选型 — 传统 RAG、GraphRAG、LlamaIndex、RAGFlow 怎么选？

导语

RAG（Retrieval-Augmented Generation）已经成了 LLM 应用落地的标配方案。但真正动手做的时候你会发现，“RAG” 这个词覆盖的范围太广了——从最简单的"切 chunk + 向量检索 + 拼 prompt"，到用知识图谱做全局推理，再到开箱即用的全栈引擎，都叫 RAG。

问题是：你的场景到底该用哪种方案？

这篇文章把目前主流的四种 RAG 技术方案放在一起对比：传统 RAG、GraphRAG、LlamaIndex、RAGFlow。不是为了分高下，而是帮你搞清楚每种方案的甜区和边界，选对了少走半年弯路。

---

一、先给结论

把结论放前面，省得你看完一整篇还不知道该选什么：

你的情况	推荐方案
刚接触 RAG，想快速验证想法	传统 RAG（手写或 LlamaIndex 几行代码）
需要跨文档综合分析、全局性问题	GraphRAG
需要高度定制 RAG 流水线，团队有开发能力	LlamaIndex
文档格式复杂（PDF/表格/PPT），想快速上线	RAGFlow
需要复杂 Agent 编排	LlamaIndex + LangChain/LangGraph
非技术人员要搭建 RAG 应用	RAGFlow 或 Dify

当然，现实中的方案往往不是四选一，而是混搭。比如用 RAGFlow 做文档解析，用 LlamaIndex 做检索策略定制，用 GraphRAG 处理需要全局理解的数据集。但混搭的前提是你清楚每个组件的边界。

---

二、四种方案的本质区别

先搞清楚一个关键区别：这四个东西不在同一个层面上。

方案	本质	类比
传统 RAG	一种技术模式	相当于"开手动挡"
GraphRAG	一种增强技术（微软提出）	相当于"给车装了涡轮增压"
LlamaIndex	开发框架（组件级）	相当于"一套汽车零件"
RAGFlow	全栈产品（引擎级）	相当于"一辆整车"

传统 RAG 是一种模式——任何人都可以用任何工具实现它。GraphRAG 是在传统 RAG 基础上加了知识图谱这层"涡轮"。LlamaIndex 是帮你组装 RAG 的零件箱。RAGFlow 是一辆开箱即用的车。

这就好比：你问"我该用手动挡还是用涡轮增压还是用某品牌的零件还是买某品牌的整车？"——这几个选项不在同一个维度上，但可以组合使用。

---

三、维度化对比

3.1 核心能力对比

维度	传统 RAG	GraphRAG	LlamaIndex	RAGFlow
文档解析	简单切分（按 token/段落）	简单切分（切块作为 LLM 输入）	依赖外部工具（LlamaParse 可选）	内置 11 种切块模板，按类型适配
索引结构	向量 embeddings	知识图谱 + 社区摘要	多种索引类型（向量/树/关键词/知识图谱）	向量 + 全文混合索引
检索方式	向量相似度	图遍历 + 社区摘要聚合	向量/关键词/混合/子问题分解	向量 + 关键词混合检索
全局理解	弱	强（社区摘要是天然全局视角）	中（需配合知识图谱索引）	中（支持 GraphRAG 辅助）
多跳推理	弱	强（图结构天然支持）	中（需配合 Knowledge Graph Index）	中（支持知识图谱辅助检索）
Agent 能力	无	无	有（ReAct Agent + Workflows）	有（画布式 DSL 编排）
前端 UI	无	无	无	自带 Web UI
可解释性	低（只给原文片段）	高（可追溯实体和关系链路）	中（支持 Citation Query Engine）	中（支持引用来源）

3.2 工程维度对比

维度	传统 RAG	GraphRAG	LlamaIndex	RAGFlow
上手难度	低	中（需要理解图谱概念）	中（概念多，但文档齐全）	低（产品化，Docker 一拉就跑）
定制灵活性	高（完全自己写）	低（微软方案，定制空间有限）	高（组件可自由组合替换）	中（产品化程度高）
索引构建成本	低（只需 embedding）	高（大量 LLM 调用做抽取和摘要）	低~中（取决于索引类型）	中（文档解析 + embedding）
部署复杂度	低（pip install）	中（pip install，但依赖多）	低（pip install）	中（Docker Compose 微服务）
运维成本	低	中	低	中（微服务需要维护）
社区生态	—	小（微软项目，更新较慢）	大（GitHub 37k+ stars）	中（国内团队，社区发展中）
适用团队	任何有开发能力的团队	有数据分析需求的团队	有开发能力、需要定制的团队	想快速上线、减少开发量的团队

3.3 成本对比

方案	索引构建成本	查询成本	基础设施成本	总体 TCO
传统 RAG	低（embedding 费用）	低（向量检索 + LLM 调用）	低（向量数据库即可）	⭐ 最低
GraphRAG	高（LLM 抽取实体/关系/摘要）	中（社区摘要 + LLM 调用）	低~中	⭐⭐⭐⭐ 最高
LlamaIndex	低~中	低	低	⭐⭐ 低
RAGFlow	中（文档解析 + embedding）	低	中（Docker 微服务）	⭐⭐⭐ 中

🔴 重点：GraphRAG 的索引构建成本是一个容易被忽视的坑。一份 200 页的文档，传统 RAG 可能只需要几分钟和几块钱的 embedding 费用；GraphRAG 可能需要调用几百次 LLM（抽取实体、关系、生成社区摘要），时间和费用都会高出一个数量级。

---

四、按场景推荐：你属于哪一类？

场景 1：企业内部知识库问答

典型需求：公司内部文档（PDF、Word、Confluence）散落在各处，员工需要通过问答系统快速查找信息。

• 如果文档格式简单（纯文本为主）→ 传统 RAG 或 LlamaIndex 就够了
• 如果文档格式复杂（大量 PDF 表格、PPT、扫描件）→ RAGFlow（深度文档解析是刚需）
• 如果需要跨文档关联分析（比如"这批项目之间的关联是什么"）→ GraphRAG

场景 2：行业报告 / 研究文献分析

典型需求：大量行业报告、研究论文需要综合分析，提取趋势和洞察。

• 如果只需要"某篇报告里说了什么" → 传统 RAG 足够
• 如果需要"这批报告整体揭示了什么趋势" → GraphRAG（全局理解是它的甜区）
• 如果文档格式复杂（学术论文有公式、图表、多栏排版）→ LlamaIndex + LlamaParse 或 RAGFlow

场景 3：法律 / 金融合规分析

典型需求：大量法律文书、合同、监管文件需要交叉引用和关联分析。

• GraphRAG 的知识图谱能力在这里很有优势——法律实体之间的关系天然适合图结构
• 如果文档格式是标准法律文书 → RAGFlow 的 Laws 切块模板可以直接用
• 实际项目中经常是 RAGFlow（解析）+ GraphRAG（关联分析） 的组合

场景 4：客服 / FAQ 系统

典型需求：基于产品文档、常见问题的自动问答。

• 传统 RAG 完全够用，不需要杀鸡用牛刀
• 如果想快速上线有 UI 的系统 → RAGFlow 省事
• 没必要上 GraphRAG——客服场景不需要全局理解

场景 5：多数据源整合

典型需求：数据散落在数据库、API、Notion、Slack 等多个系统中，需要统一检索。

• LlamaIndex 是首选——LlamaHub 150+ 数据连接器覆盖了大部分常见数据源
• RAGFlow 也支持部分数据源接入，但不如 LlamaIndex 丰富

场景 6：需要复杂 Agent 能力

典型需求：不只是问答，还需要 LLM 调用工具、执行多步骤推理、做决策。

• LlamaIndex + LangChain/LangGraph 的组合最灵活
• RAGFlow 的画布式 Agent 编排适合简单场景，复杂逻辑可能不够用
• GraphRAG 和传统 RAG 本身不提供 Agent 能力

---

五、组合拳：实际项目中的混搭策略

别被"四选一"的思维限制了。实际项目中，这些方案经常混着用：

几个典型的混搭组合：

组合 1：RAGFlow 解析 + LlamaIndex 检索
用 RAGFlow 的深度文档解析处理复杂 PDF，解析结果喂给 LlamaIndex 做定制化的检索策略。适合文档格式复杂但检索逻辑也需要定制的场景。

组合 2：LlamaIndex 索引 + GraphRAG 全局分析
用 LlamaIndex 做日常的局部检索（快速回答具体问题），同时用 GraphRAG 构建知识图谱处理全局性问题。两套系统并行，按问题类型路由。

组合 3：RAGFlow 全栈 + GraphRAG 增强
用 RAGFlow 作为主引擎（解析 + 检索 + UI），对需要全局理解的数据集额外启用 GraphRAG。RAGFlow 本身已经内置了知识图谱构建能力，可以直接用 use_kg=True 启用。

---

六、常见误区

误区 1：“GraphRAG 一定比传统 RAG 好”

不是。GraphRAG 的优势在全局理解和多跳推理，但代价是索引构建成本高出一个数量级。如果你的场景只是简单的事实查询（“这个产品的退货政策是什么？”），传统 RAG 更快更便宜，效果也不差。

误区 2：“选了 LlamaIndex 就不需要关注文档解析了”

LlamaIndex 是框架，不是解析器。它的 SimpleDirectoryReader 只是把文件读进来，不会帮你处理表格错乱、图片丢失这些解析问题。文档解析质量是 RAG 效果的瓶颈，这一点不管用什么框架都绕不开。

误区 3：“RAGFlow 是产品就不能定制”

RAGFlow 的产品化程度确实高，但它也提供了 Python SDK 和完整的 HTTP API，很多环节可以通过 API 扩展。只是和 LlamaIndex 比，定制空间确实有限——这是产品化和灵活性之间的天然 trade-off。

误区 4：“传统 RAG 太简单，上不了生产”

很多生产环境的 RAG 系统就是传统 RAG——关键在于调优：chunk 策略、embedding 模型选择、混合检索权重、reranker、prompt 工程……这些细节做好了，传统 RAG 的效果完全能打。别被"传统"两个字误导了。

误区 5：“这些方案只能选一个”

前面已经说了，实际项目中混搭很常见。搞清楚每个组件的边界和优势，按需组合才是正道。

---

七、决策流程图

如果你还是拿不准，试试这个决策路径：

---

八、小结

1. 传统 RAG 是基础——简单、便宜、够用，适合大部分 QA 场景。别因为它"传统"就看不上。
2. GraphRAG 解决的是全局理解和多跳推理——代价是索引构建成本高。适合需要"看全局"的分析场景，不适合简单 QA。
3. LlamaIndex 是 RAG 领域最灵活的开发框架——组件丰富、生态完善、可深度定制。适合有开发能力、需要定制流水线的团队。
4. RAGFlow 是开箱即用的 RAG 引擎——深度文档解析是核心优势，自带 UI 和 Agent 编排。适合想快速上线、文档格式复杂的团队。
5. 没有银弹。 实际项目中经常混搭使用，关键是搞清楚每个组件的甜区和边界。
6. 文档解析质量是 RAG 效果的瓶颈。 不管用什么方案，这一步处理不好，后面全白搭。

---

参考资源

• GraphRAG 官方文档
• GraphRAG 论文：From Local to Global
• LlamaIndex 官方文档
• LlamaIndex GitHub 仓库
• RAGFlow 官方文档
• RAGFlow GitHub 仓库