RAG 技术选型 — 传统 RAG、GraphRAG、LlamaIndex、RAGFlow 怎么选导语RAGRetrieval-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 核心能力对比维度传统 RAGGraphRAGLlamaIndexRAGFlow文档解析简单切分按 token/段落简单切分切块作为 LLM 输入依赖外部工具LlamaParse 可选内置 11 种切块模板按类型适配索引结构向量 embeddings知识图谱 社区摘要多种索引类型向量/树/关键词/知识图谱向量 全文混合索引检索方式向量相似度图遍历 社区摘要聚合向量/关键词/混合/子问题分解向量 关键词混合检索全局理解弱强社区摘要是天然全局视角中需配合知识图谱索引中支持 GraphRAG 辅助多跳推理弱强图结构天然支持中需配合 Knowledge Graph Index中支持知识图谱辅助检索Agent 能力无无有ReAct Agent Workflows有画布式 DSL 编排前端 UI无无无自带 Web UI可解释性低只给原文片段高可追溯实体和关系链路中支持 Citation Query Engine中支持引用来源3.2 工程维度对比维度传统 RAGGraphRAGLlamaIndexRAGFlow上手难度低中需要理解图谱概念中概念多但文档齐全低产品化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 能力五、组合拳实际项目中的混搭策略别被四选一的思维限制了。实际项目中这些方案经常混着用是否是否数据源文档格式复杂?RAGFlow / LlamaParse深度解析传统切分需要全局理解?GraphRAG知识图谱 社区摘要LlamaIndex / 传统 RAG向量索引 混合检索Agent 编排LLM 生成回答几个典型的混搭组合组合 1RAGFlow 解析 LlamaIndex 检索用 RAGFlow 的深度文档解析处理复杂 PDF解析结果喂给 LlamaIndex 做定制化的检索策略。适合文档格式复杂但检索逻辑也需要定制的场景。组合 2LlamaIndex 索引 GraphRAG 全局分析用 LlamaIndex 做日常的局部检索快速回答具体问题同时用 GraphRAG 构建知识图谱处理全局性问题。两套系统并行按问题类型路由。组合 3RAGFlow 全栈 GraphRAG 增强用 RAGFlow 作为主引擎解析 检索 UI对需要全局理解的数据集额外启用 GraphRAG。RAGFlow 本身已经内置了知识图谱构建能力可以直接用use_kgTrue启用。六、常见误区误区 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“这些方案只能选一个”前面已经说了实际项目中混搭很常见。搞清楚每个组件的边界和优势按需组合才是正道。七、决策流程图如果你还是拿不准试试这个决策路径是否是否是否是否是否是否你的需求是什么?需要全局理解?跨文档综合分析?GraphRAG文档格式复杂?PDF/表格/PPT?需要高度定制?RAGFlowLlamaIndex LlamaParse需要 Agent 能力?LlamaIndex LangChain需要快速上线有 UI?传统 RAG手写或 LlamaIndex同时需要日常检索?GraphRAG LlamaIndex双系统并行八、小结传统 RAG是基础——简单、便宜、够用适合大部分 QA 场景。别因为它传统就看不上。GraphRAG解决的是全局理解和多跳推理——代价是索引构建成本高。适合需要看全局的分析场景不适合简单 QA。LlamaIndex是 RAG 领域最灵活的开发框架——组件丰富、生态完善、可深度定制。适合有开发能力、需要定制流水线的团队。RAGFlow是开箱即用的 RAG 引擎——深度文档解析是核心优势自带 UI 和 Agent 编排。适合想快速上线、文档格式复杂的团队。没有银弹。实际项目中经常混搭使用关键是搞清楚每个组件的甜区和边界。文档解析质量是 RAG 效果的瓶颈。不管用什么方案这一步处理不好后面全白搭。参考资源GraphRAG 官方文档GraphRAG 论文From Local to GlobalLlamaIndex 官方文档LlamaIndex GitHub 仓库RAGFlow 官方文档RAGFlow GitHub 仓库