03-RAG主流搭建方案与技术选型：四大模式对比与选型决策
第 3 篇：RAG 主流搭建方案与技术选型——四大搭建模式对比与选型决策
本文为「从零到落地：RAG 检索增强生成实战系列」第 3 篇，完整系列持续更新中。
前言
本篇是选型决策篇，帮你解决一个关键问题：我该用什么方案来做 RAG？ 深度对比四大搭建模式，给出按场景的明确推荐，帮你避免”选错方案浪费一周”。
上一篇讲清楚了 RAG 的完整流程：索引阶段把文档变成向量存起来，推理阶段检索相关内容让大模型基于事实回答。原理搞懂了，下一步就是动手实现——但你会发现，市面上的 RAG 方案太多了：Dify、LangChain、LangGraph、LlamaIndex、RAGFlow、Kimi 知识库、FastGPT……每个都在说自己好用，到底该选哪个？
选型选错了的后果很严重：花了两周用 LangChain 搭完，才发现业务团队根本不会维护代码；或者用低代码平台上线了，结果深度定制需求实现不了，只能推倒重来。
本篇学完你将掌握：
- RAG 四大搭建模式的定义、代表产品、优缺点和适用场景
- 10 种 RAG 能力档位速览，知道”功能层面还有哪些选择”
- 按使用场景的选型决策表，直接告诉你”这个场景该用什么”
- Embedding 模型和 LLM 的选型原则
一、四大搭建模式总览
在深入每种模式之前，先看一张总览表快速建立全局认知：
| 搭建模式 | 核心特征 | 代表产品 | 技术门槛 | 上线速度 |
|---|---|---|---|---|
| 低代码可视化平台 | 零代码 / 少代码，拖拽搭建 | Dify（GitHub）、FastGPT（GitHub）、Coze | 低 | 极快（小时级） |
| 开源框架代码自研 | 代码实现，定制无上限 | LangChain、LangGraph、LlamaIndex | 中高 | 中等（天~周级） |
| 云端 SaaS 托管 | 零运维，即用即走 | Kimi 知识库、豆包、阿里百炼 | 极低 | 极快（分钟级） |
| 一体化私有化套件 | Docker 一键部署，数据自持 | RAGFlow（GitHub）、Dify 社区版（GitHub）、FastGPT（GitHub）、Open-WebUI | 中 | 快（半天~1天） |
下面逐个拆解。
二、模式一：低代码可视化平台
2.1 是什么
低代码平台把 RAG 的全流程（文档上传、分块配置、模型接入、Prompt 编辑、对话测试）全部封装成可视化界面，点点鼠标就能搭出一个 RAG 应用。你不需要写代码，也不需要理解向量数据库、Embedding 这些底层概念。
2.2 代表产品对比
| 产品 | 开源 | 部署方式 | 核心优势 | 核心局限 |
|---|---|---|---|---|
| Dify（GitHub） | 开源 | Docker 自部署 / 云端 | 生态最成熟，知识库 + Workflow + Agent 全能，社区活跃 | 深度定制受限，复杂逻辑需要 Workflow 编排 |
| FastGPT（GitHub） | 开源 | Docker 自部署 / 云端 | 知识库能力强，工作流灵活，中文生态好 | 社区规模比 Dify 小，插件生态较新 |
| Coze | 闭源 | 云端（字节跳动） | 上手极简，内置丰富插件和 Bot 模板 | 闭源不可私有化，深度定制受限 |
2.3 适用场景
- 业务团队 / 非技术人员：产品经理、运营、客服团队，需要快速上线一个知识库问答
- 原型验证：老板说”做个 demo 看看效果”，半天搭出来演示
- 中小企业快速上线：没有专职 AI 开发团队，但有明确的知识库需求
2.4 不适用场景
- 需要深度定制检索逻辑（自定义重排算法、多级检索策略）
- 需要和其他系统做复杂集成（自定义 API 编排、异步任务链）
- 对底层分块、检索过程需要完全控制的研究型项目
💡 建议：如果你的团队没有专职 AI 开发，且需求是”标准知识库问答”，低代码平台是最优选。本系列第 5 篇会用 Dify 完整实战演示。
三、模式二：开源框架代码自研
3.1 是什么
用开源的 RAG 框架写代码实现整个流程。你拥有全部控制权——从分块策略到检索逻辑、从 Prompt 设计到后处理，每一行代码都是你写的。
3.2 框架分类
这个模式内部还可以细分成三类：
基础线性框架
代表：LangChain、LlamaIndex
把 RAG 的标准流程封装成一套 API，按顺序调用就行——加载文档、切分、向量化、检索、生成。适合标准 RAG 场景，上手快，生态丰富。
| 框架 | 核心定位 | 优势 | 局限 |
|---|---|---|---|
| LangChain | 通用 LLM 应用框架 | 生态最大，组件最多，社区活跃 | 抽象层太多，调试困难，简单场景过度封装 |
| LlamaIndex | RAG 专用框架 | API 简洁，RAG 场景开箱即用，分块和检索策略丰富 | 非 RAG 场景支持有限，生态不如 LangChain 大 |
状态机编排框架
代表：LangGraph
把 RAG 流程拆成一个个节点（Node），用图（Graph）来编排节点之间的流转逻辑。支持条件分支、循环、状态管理，适合需要复杂决策逻辑的场景——比如”检索结果不够好就自动改写 Query 重新检索”。
| 框架 | 核心定位 | 优势 | 局限 |
|---|---|---|---|
| LangGraph | 状态机 + 图编排 | 流程可控，支持复杂分支和循环，和 Agent 天然融合 | 学习曲线陡峭，简单场景过度设计 |
轻量化原生自研
直接用向量数据库 SDK + LLM API，不依赖任何框架，全部自己写。代码量不大（几十行），但你对每一行都有完全的理解和控制。
| 方案 | 核心定位 | 优势 | 局限 |
|---|---|---|---|
| 向量库 SDK + LLM SDK | 极简自研 | 零依赖，完全透明，学习价值极高 | 生产级功能（分块策略、重排、记忆）需要自己实现 |
3.3 适用场景
- AI 开发工程师：需要深度定制检索逻辑、对接复杂业务系统
- 复杂流程需求：多轮对话 + 条件分支 + Agent 融合
- 学习和研究：想彻底理解 RAG 底层，不被框架黑盒化
3.4 不适用场景
- 团队没有 Python 开发能力
- 需要快速上线（1-2 天内）
- 需求是标准的知识库问答，不需要定制
💡 建议：代码自研路线，本系列安排了 4 篇实战——第 4 篇原生 Python（入门）、第 6 篇 LangGraph（编排）、第 7 篇 LlamaIndex（RAG 专用），按需求挑读。
四、模式三：云端 SaaS 托管
4.1 是什么
直接用第三方平台提供的”知识库”功能，上传文档就能用，不需要部署任何服务、不需要写任何代码。平台帮你搞定一切：文档解析、向量化、检索、生成。
4.2 代表产品对比
| 产品 | 背后厂商 | 核心优势 | 核心局限 | 计费方式 |
|---|---|---|---|---|
| Kimi 知识库 | 月之暗面 | 长上下文能力强，中文效果好 | 数据托管在平台，功能定制受限 | 按量付费 |
| 豆包 | 字节跳动 | 集成在飞书生态，上手极简 | 闭源，不可私有化 | 按量付费 |
| 阿里百炼 | 阿里云 | 云生态整合，支持多种模型 | 绑定阿里云生态 | 按量付费 |
| 百度千帆 | 百度 | 文心大模型生态，企业级支持 | 绑定百度生态 | 按量付费 |
4.3 适用场景
- 个人用户 / 小团队：临时需要一个知识库问答，不想折腾部署
- 非涉密数据：数据可以放在第三方平台
- 短期使用 / 一次性任务：比如分析一批公开报告、做竞品调研
4.4 不适用场景
- 涉密数据、企业内部文档（数据不能出网）
- 需要深度定制（自定义分块策略、检索算法）
- 长期高用量使用（按量计费的成本会超过自建方案）
⚠️ 注意：云端 SaaS 的核心风险是数据安全和长期成本。你的文档会上传到第三方服务器，如果涉及商业秘密或用户隐私，这个方案直接排除。长期大量使用时，API 调用费用会持续增长，不如自建方案经济。
五、模式四：一体化私有化部署套件
5.1 是什么
一套开源系统，通过 Docker 一键部署到你自己的服务器上。系统内置了文档解析、向量检索、大模型调用、可视化管理的全部能力，相当于一个”即插即用”的私有 RAG 平台。
和模式一（低代码平台）的区别在于：低代码平台侧重“应用搭建”，私有化套件侧重“深度文档处理和检索精度”。和模式二（代码自研）的区别在于：私有化套件不需要写代码，但你有全部源码控制权。
💡 提示：Dify 同时出现在模式一和模式四——它的云端版 / SaaS 版属于低代码平台（模式一），而社区版（开源免费）可以通过 Docker Compose 部署到你自己的服务器上，数据完全自持，本质上就是一套私有化 RAG 平台。这也是 Dify 相比其他低代码平台的核心优势：既能用云端版快速上手，也能用社区版私有化部署，灵活度很高。
5.2 代表产品对比
| 产品 | 核心优势 | 核心局限 |
|---|---|---|
| RAGFlow（GitHub） | 深度文档解析（PDF 布局分析、表格 OCR），模板化分块，混合检索 + Rerank，支持 RAPTOR 层次化索引 | 服务器配置要求较高（建议 16GB+ 内存） |
| Dify 社区版（GitHub） | 知识库 + Workflow + Agent 全能，生态最成熟，社区活跃，模型接入丰富 | 文档解析深度不如 RAGFlow，复杂知识库场景需要搭配外部工具 |
| FastGPT（GitHub） | 知识库 + 工作流双引擎，中文生态好，社区活跃 | 文档解析深度不如 RAGFlow |
| Open-WebUI | 轻量级，Ollama 生态集成好，上手简单 | RAG 能力相对基础，高级功能少 |
5.3 适用场景
- 企业内网 / 涉密场景：数据不能出网，但又不想全量自研
- 需要深度文档解析：大量 PDF、扫描件、表格类文档
- 中等技术团队：有运维能力但没有专职 AI 开发
5.4 不适用场景
- 没有服务器资源、不想运维
- 只需要简单的知识库问答，低代码平台就够了
- 需要高度定制的检索逻辑（虽然有源码，但改造成本不低）
💡 建议：私有化场景首选 RAGFlow（文档解析深度和检索精度最好，本系列第 8 篇有完整实战），如果你的团队更需要知识库 + Workflow + Agent 全能型平台，Dify 社区版也是优秀的私有化选择（本系列第 5 篇有完整实战）。
六、RAG 能力档位速览
搞清楚了搭建模式，再看一下 RAG 在功能层面有哪些”能力档位”。这张表帮你建立一个全局认知——知道 RAG 能做到什么程度，具体实现在后续实战篇和高阶篇中逐个展开。
6.1 基础能力（本系列实战篇覆盖）
| 能力档位 | 说明 | 典型场景 | 对应实战篇 |
|---|---|---|---|
| 基础单轮 RAG | 最经典的文档问答：提问→检索→回答 | 简单知识库 | 第 4-8 篇 |
| 多轮对话 RAG | 带历史记忆的连续问答，支持追问和上下文衔接 | 客服、对话助手 | 第 6-7 篇 |
| 混合检索 RAG | 向量检索 + 关键词检索融合，提升召回率 | 生产环境标配 | 第 7-8 篇 |
| 上下文压缩 RAG | 精简检索内容，剔除冗余，节省 Token | 长文档、大知识库 | 第 9 篇 |
6.2 高阶变种（本系列拓展篇覆盖）
| 能力档位 | 说明 | 典型场景 | 对应拓展篇 |
|---|---|---|---|
| GraphRAG | 知识图谱 + 向量检索融合 | 实体关系强的专业库（法律、医学） | 拓展篇 |
| 多模态 RAG | 图文、表格、PDF 混合检索 | 图纸、报表、扫描件 | 拓展篇 |
| Agentic RAG | Agent 自主决定检索策略 | 复杂任务、工具联动 | 拓展篇 |
| AutoRAG | 全链路自动化调优 | 持续迭代的大型知识库 | 拓展篇 |
| 实时 RAG | 数据增量更新 + 流式问答 | 动态业务数据 | 拓展篇 |
| Code RAG | 代码分词、语法感知检索 | 代码仓库、技术文档 | 拓展篇 |
💡 提示：基础能力（前四行）覆盖了 80% 的实际场景。高阶变种在特定领域有显著提升，但复杂度也更高，建议先跑通基础 RAG 再按需学习。
七、选型决策表
这是本篇最核心的部分。按你的实际场景，直接查表找答案。
7.1 按场景推荐方案
| 使用场景 | 推荐搭建模式 | 推荐工具 | 配套向量库 | Embedding 建议 | LLM 建议 |
|---|---|---|---|---|---|
| 个人学习、原型验证 | 原生 Python 自研 | 手写代码（第 4 篇） | Chroma / FAISS | bge-large-zh-v1.5（本地） | DeepSeek API |
| 中小企业快速上线 | 低代码平台 | Dify（第 5 篇） | 平台内置 / Milvus 轻量部署 | 平台内置或自配 | DeepSeek / Qwen API |
| 定制化开发、Agent 联动 | 代码编排框架 | LangGraph（第 6 篇） | Milvus / Weaviate | bge-large-zh-v1.5 | GPT-4o / Qwen-Max |
| RAG 专用、开箱即用 | RAG 专用框架 | LlamaIndex（第 7 篇） | Chroma / Qdrant | bge-large-zh-v1.5 | DeepSeek / GPT-4o |
| 企业内网私有化 | 私有化套件 | RAGFlow（第 8 篇）/ Dify 社区版（第 5 篇） | 系统内置（Elasticsearch） | 系统内置或自配 | 本地 Ollama + Qwen2.5 |
| 个人临时使用、非涉密 | 云端 SaaS | Kimi 知识库 | 平台内置 | 平台内置 | 平台内置 |
7.2 按团队能力推荐
| 团队情况 | 推荐方案 | 理由 |
|---|---|---|
| 无开发人员 | 低代码平台 / 云端 SaaS | 零代码上手，快速上线 |
| 1-2 个 Python 开发 | LangGraph / LlamaIndex 自研 | 有代码能力，可以做定制化 |
| 有运维无 AI 开发 | RAGFlow / Dify 社区版私有化部署 | Docker 部署即可，不需要写 AI 代码 |
| AI 专业团队 | 原生自研 + LangGraph | 完全控制，性能优化空间最大 |
7.3 决策流程图
如果你还是不确定，按这个流程走一遍：
1 | 你的数据涉密吗？ |
八、Embedding 模型选型
搭建模式选好了，还需要确定两个核心组件：Embedding 模型和 LLM。先说 Embedding。
8.1 选型要点
| 考量维度 | 说明 |
|---|---|
| 开源 vs 商用 | 开源模型可本地部署、免费、数据不出网；商用 API 开箱即用但有持续费用 |
| 中文适配度 | 中文场景必须选中文优化的模型，通用多语言模型在中文上效果会打折扣 |
| 向量维度 | 维度越高表示能力越强，但存储和检索成本也越高。768~1024 是性价比区间 |
| 最大 Token 数 | 决定了单个文本块的最大长度，512 Token 是常见限制 |
8.2 推荐方案
| 场景 | 推荐模型 | 维度 | 类型 | 理由 |
|---|---|---|---|---|
| 中文场景首选 | bge-large-zh-v1.5 | 1024 | 开源本地 | 智源出品，中文效果最好，社区广泛使用 |
| 多语言场景 | bge-m3 | 1024 | 开源本地 | 支持 100+ 语言，一个模型覆盖多语种 |
| 省事用 API | text-embedding-3-small | 1536 | 商用 API | OpenAI 出品，稳定可靠，按量计费 |
| 轻量级 | m3e-base | 768 | 开源本地 | 模型小、速度快，适合资源有限场景 |
| Jina 生态 | jina-embeddings-v3 | 1024 | 开源本地 | 支持多语言，可本地部署，Late Interaction 模式 |
💡 建议：中文 RAG 项目无脑选
bge-large-zh-v1.5，效果、社区、文档都是最优解。如果项目涉及多语言（比如英文+中文混合文档），用bge-m3。
九、LLM 选型
9.1 核心决策：API 调用 vs 本地部署
| 维度 | API 调用 | 本地部署 |
|---|---|---|
| 代表方案 | DeepSeek API、GPT-4o、Qwen-Max | Ollama + Qwen2.5、vLLM + Llama |
| 上手难度 | 极低，注册拿 Key 就能用 | 需要 GPU 服务器 + 运维 |
| 数据安全 | 数据经过第三方 | 数据不出网 |
| 成本结构 | 按量计费（Token 数） | 一次性硬件投入 + 电费 |
| 回答质量 | 顶级（大参数量模型） | 取决于硬件（小模型效果有差距） |
| 适用场景 | 非涉密、快速验证、中小企业 | 涉密、长期运行、高频调用 |
9.2 按场景推荐
| 场景 | 推荐 LLM | 理由 |
|---|---|---|
| 性价比优先 | DeepSeek-V3 API | 效果接近 GPT-4o，价格只有 1/10 |
| 效果优先 | GPT-4o / Claude 3.5 Sonnet | 综合能力最强 |
| 涉密 + 本地部署 | Ollama + Qwen2.5-7B | 开源中文模型首选，7B 参数单卡可跑 |
| 涉密 + 高质量 | vLLM + Qwen2.5-72B | 大参数量本地模型，需要多卡 GPU |
| 轻量快速 | Ollama + Qwen2.5-1.5B | 极轻量，CPU 也能跑，适合原型验证 |
💡 建议：RAG 场景对 LLM 的核心要求是”基于给定上下文准确回答”，这是一个相对简单的任务（比开放域对话简单），所以不需要最贵的模型。DeepSeek API 或本地 Qwen2.5-7B 在大多数 RAG 场景下效果就够用了。
踩坑记录：选了 LangChain 但团队不会维护
现象：
一个 3 人的产品团队用 LangChain 搭了一个 RAG 知识库，上线后运行正常。两个月后需要调整分块策略和检索参数，但当初写代码的同事已经离职，剩下的人看不懂 LangChain 的链式调用和回调机制，改了两天改出了更多 bug。
原因：
LangChain 的抽象层较多（Chain、Agent、Tool、Callback），代码可读性对非 AI 开发者不友好。团队没有 Python 开发储备的情况下，选代码框架路线本身就是错误决策。
解决方案：
最终用 Dify 重新搭建，知识库配置、Prompt 编辑、检索参数调整全部在可视化界面完成，产品团队自己就能维护。
避坑建议：
选型时不要只看”技术上能做什么”，还要看”团队能维护什么”。如果团队没有专职 Python 开发，优先选低代码平台或私有化套件，不要为了”灵活性”选代码框架。
总结与回顾
| 知识点 | 关键要点 |
|---|---|
| 四大搭建模式 | 低代码平台（快速上线）、代码自研（深度定制）、云端 SaaS（零运维）、私有化套件（数据自持） |
| 选型核心原则 | 按团队能力和数据安全需求选模式，按场景选工具 |
| 能力档位 | 基础四档（单轮/多轮/混合/压缩）覆盖 80% 场景，高阶六档按需学习 |
| Embedding 选型 | 中文首选 bge-large-zh-v1.5，多语言用 bge-m3，省事用 OpenAI API |
| LLM 选型 | 性价比选 DeepSeek API，涉密选 Ollama + Qwen2.5，不需要最贵的模型 |
| 选型避坑 | 不只看技术能力，还要看团队维护能力和长期成本 |
下篇预告
第 4 篇：原生 Python 手写最简 RAG —— 不用任何框架，5 步手写一个完整 RAG，代码逐行注释讲解。先理解底层，再用框架事半功倍。
参考资料
| 产品 / 工具 | 官网 | 代码仓库 |
|---|---|---|
| Dify | dify.ai | langgenius/dify |
| FastGPT | fastgpt.in | labring/FastGPT |
| Coze | coze.com | — |
| LangChain | langchain.com | langchain-ai/langchain |
| LangGraph | langchain.com/langgraph | langchain-ai/langgraph |
| LlamaIndex | llamaindex.ai | run-llama/llama_index |
| RAGFlow | ragflow.io | infiniflow/ragflow |
| Open-WebUI | openwebui.com | open-webui/open-webui |
| Kimi | kimi.moonshot.cn | — |
| 豆包 | doubao.com | — |
| 阿里百炼 | bailian.console.aliyun.com | — |
| 百度千帆 | qianfan.cloud.baidu.com | — |
| DeepSeek | deepseek.com | deepseek-ai |
| OpenAI | openai.com | — |
| Ollama | ollama.com | ollama/ollama |
| Qwen | qwenlm.github.io | QwenLM |
| vLLM | vllm.ai | vllm-project/vllm |
| Chroma | trychroma.com | chroma-core/chroma |
| FAISS | — | facebookresearch/faiss |
| Milvus | milvus.io | milvus-io/milvus |
| Qdrant | qdrant.tech | qdrant/qdrant |
| Weaviate | weaviate.io | weaviate/weaviate |
| Elasticsearch | elastic.co | elastic/elasticsearch |
本文为「从零到落地：RAG 检索增强生成实战系列」第 3 篇，完整系列持续更新中。