RAG 平台选型决策树

调研日期：2025-06-22

基于 5 项目精读 + 横评综合

一句话定位

面对 5 个 RAG 开源项目，根据团队规模、文档类型、检索质量要求、部署环境、预算、可扩展性和生态，系统化地找到最适合的选型——不是”哪个最好”，而是”哪个最匹配”。

为什么需要决策树

选 RAG 平台不是选手机——不存在一个”综合最强”的万能选手。更像选交通工具：运货选卡车、赶时间选高铁、游山选越野，选错了不是”差一点”，而是根本到不了目的地。

5 个 RAG 项目各有明确的设计哲学差异：

• WeKnora 把检索质量推到极致，但代价是 Go 技术栈 + 多组件部署
• Dify 把开发体验做到最好，但检索本身只是中上水平
• RAGFlow 把文档解析做到最强，但 Agent 编排几乎为零
• AnythingLLM 把部署门槛降到最低，但检索能力天花板也最低
• FastGPT 把企业权限做得最完善，但生态和扩展性受限

选择悖论（Paradox of Choice）：选项越多，决策越难，反而容易做出”默认选最火的”这种偷懒决策。Dify 144K star 不代表它适合所有场景——一个只做 PDF 表格提取的项目用 Dify 就是南辕北辙。

决策树的价值在于：把隐性的取舍显性化。每个分支节点都是一个必须回答的问题，每个叶子节点都是一个不可再分的推荐。不用决策树，你会同时在 5 个选项之间犹豫；用了决策树，3-4 个问题就能定位到唯一答案。

选型全景见 RAG 知识库赛道总览，各项目精读见下方交叉引用。

决策维度

日常类比：选房子要看位置、面积、价格、学区、物业——选 RAG 平台也一样，关键是搞清楚自己最在意哪个维度，而不是每个维度都要满分。

1. 团队规模与技术能力

这是第一道分水岭。一个没有后端工程师的 3 人创业团队，和一个 20 人技术团队，面对同样的业务需求，最优选型完全不同。

关键判断：团队能否维护 3 个以上的外部依赖（向量数据库 + 图数据库 + LLM 网关）？如果不能，WeKnora 直接排除。

2. 文档类型与复杂度

文档是 RAG 的燃料。燃料品质不同，引擎的选择也不同——给拖拉机加航空煤油跑不起来，给喷气式飞机加柴油也飞不上天。

关键判断：文档中表格/图片/公式的占比超过 30%？如果是，RAGFlow 的 DeepDoc 是目前开源方案中解析能力最强的，没有之一。

3. 检索质量要求

检索质量是 RAG 的命门。但”高质量”是有代价的——就像精度的手表比普通手表贵 10 倍，但大多数场景不需要那 0.01 秒的精度。

关键判断：答案错误的代价有多大？客服答错可以道歉，医疗诊断答错要出人命。代价越高，越应该选 WeKnora 的三路混合检索。

评估方法论详见 RAG 评估方法论。

4. 部署环境

关键判断：数据合规是否允许文档上传到第三方云？如果不允许，排除所有纯云方案；如果允许，云方案能省 80% 运维成本。

5. 预算与资源

关键判断：有没有 3 个月以上的持续投入承诺？RAG 不是”上线就完”的项目——文档在变、模型在变、用户需求在变。没有持续维护预算，选最简单的方案。

6. 可扩展性需求

扩展性就像房子的承重墙——建的时候多花一点，改的时候少拆很多。

关键判断：6 个月内是否需要深度定制检索逻辑或接入自定义数据源？如果是，排除 AnythingLLM 和 FastGPT。

7. 生态与社区

生态规模决定你遇到问题时能多快找到答案。但 star 数不等于活跃度——要看的指标是：

关键判断：团队是否习惯”看文档解决问题”还是”去社区问人”？文档党选 WeKnora/RAGFlow（中文文档完善），社区党选 Dify（社区最大，踩坑记录最多）。

决策输入维度（汇总）

ASCII 决策树

以下决策树从最关键的问题开始，逐层分支。每个菱形是一个判断节点，每个矩形是推荐结果。按顺序回答问题，就能定位到最适合的选型。

                    ┌─────────────────────┐
                    │   选哪个 RAG 平台？  │
                    └─────────┬───────────┘
                              │
              ┌───────────────┴───────────────┐
              │ Q1: 需要可视化 Agent 工作流编排？ │
              └───────┬───────────────┬───────┘
                   是 │               │ 否
                      │               │
            ┌─────────┴──────┐        │
            │ Q1a: 需要企业级  │        │
            │ 多租户 + 权限？  │        │
            └──┬──────────┬──┘        │
             是│          │否          │
               │          │            │
        ┌──────┴──┐  ┌────┴─────┐     │
        │ FastGPT │  │  Dify     │     │
        │ (企业级  │  │ (最灵活的 │     │
        │  权限+   │  │  工作流)  │     │
        │  工作流) │  │           │     │
        └─────────┘  └───────────┘     │
                                       │
                  ┌────────────────────┴───────────────────┐
                  │ Q2: 检索质量要求极高（答案错误的代价大）？ │
                  └───────┬───────────────────────┬───────┘
                       是 │                       │ 否
                          │                       │
               ┌──────────┴──────────┐            │
               │ Q2a: 团队能维护     │            │
               │ Go 栈 + 3+ 外部依赖？│            │
               └──┬──────────────┬──┘            │
                是│              │否               │
                  │              │                 │
           ┌──────┴─────┐  ┌────┴──────┐          │
           │  WeKnora    │  │ Q2b: PDF/  │          │
           │ (三路混合    │  │ 表格占比   │          │
           │  检索+图谱) │  │ > 30%？    │          │
           └────────────┘  └─┬───────┬──┘          │
                           是│       │否            │
                             │       │              │
                      ┌──────┴──┐ ┌──┴────────┐    │
                      │ RAGFlow │ │ Dify + 自定 │    │
                      │ (最强    │ │ 义检索策略  │    │
                      │  文档解析│ │ (用 Dify 的 │    │
                      │  + OCR) │ │  灵活度补)  │    │
                      └─────────┘ └────────────┘    │
                                                     │
                    ┌────────────────────────────────┴───────────┐
                    │ Q3: 完全本地部署，零外部依赖（数据不出机器）？ │
                    └───────┬───────────────────────────┬───────┘
                         是 │                           │ 否
                            │                           │
                     ┌──────┴───────┐     ┌─────────────┴──────────┐
                     │ AnythingLLM  │     │ Q4: 快速原型 还是 生产？  │
                     │ (单文件部署， │     └──┬─────────────────┬──┘
                     │  内建向量DB) │      原型│               │生产
                     └──────────────┘         │               │
                                        ┌──────┴──┐    ┌──────┴──────────┐
                                        │  Dify   │    │ WeKnora / RAGFlow│
                                        │ (拖拽即用│    │ (质量天花板)     │
                                        │  分钟级) │    └─────────────────┘
                                        └─────────┘

如何使用：从顶部开始，逐个回答菱形框中的问题，沿”是/否”分支向下走，直到到达矩形推荐节点。如果同时满足多条路径的起点条件（比如既要 Agent 编排又要极致检索），见下方”混合方案”。

同一决策逻辑的 Mermaid 版本（可渲染）见文末附录。

场景化推荐

以下每个场景给出：推荐选型 + 推荐理由 + 不选其他的理由 + 典型部署方式 + 踩坑提醒。

场景 1：个人学习 / 原型验证 -> AnythingLLM

典型画像：一个人、一台笔记本、想今晚就跑起来看看 RAG 是什么效果。

推荐 AnythingLLM 的理由：

• 安装到跑通全程 30 分钟——Docker 一个容器，或直接 Electron 桌面版
• 内建 LanceDB 做向量存储，不需要额外装 Milvus/Qdrant/Chroma
• 支持多种 LLM 后端（OpenAI / Ollama / LM Studio），切换零代码
• UI 开箱即用，不需要写一行前端代码

不选其他的理由：

• WeKnora：个人维护不动 3 个外部依赖
• Dify：配置项太多，原型阶段不需要那么多选择
• RAGFlow：文档解析虽强，但原型阶段通常只喂几十篇文档，差异不大
• FastGPT：企业权限对个人无用

典型部署：

# Docker 一行启动
docker run -d -p 3001:3001 anythingllm/anythingllm
# 或下载桌面版，双击打开

踩坑提醒：

• AnythingLLM 的默认 chunk 策略偏粗糙（按 token 数硬切），如果文档有明确的章节结构，检索质量会明显下降。可以在设置里切换为”自然段落”分 chunk。
• LanceDB 是嵌入式向量库，数据量超过 10 万条后性能会下降。如果未来数据量增长，需要迁移到外部向量库——此时就不再是”零依赖”了。

精读 AnythingLLM 见 deep-dive-anythingllm.md。

场景 2：中小企业客服机器人 -> FastGPT

典型画像：10-50 人公司，客服团队 3-5 人，需要让 AI 回答用户常见问题，要求按部门隔离知识库，经理能看到统计但普通客服不能看财务知识库。

推荐 FastGPT 的理由：

• 多租户 + 角色权限是 FastGPT 的核心设计，不是后补的功能——这意味着权限模型是完整的，不是”能设密码”级别的
• 工作流编排内建：可以根据用户问题类型，先走意图识别节点，再分支到不同知识库检索
• 支持对话统计和反馈收集，方便运营持续优化知识库
• 中文生态好，文档和案例都针对国内企业场景

不选其他的理由：

• Dify：权限模型偏基础，企业级多租户需要自研
• WeKnora：没有可视化工作流，客服场景需要灵活编排（意图识别 -> 知识检索 -> 兜底转人工）
• RAGFlow：无 Agent 编排，无法实现”检索不到就转人工”的流程
• AnythingLLM：无多租户，无权限

典型部署：

# docker-compose 启动（含 MongoDB + PostgreSQL + OneAPI）
docker-compose up -d
# 首次访问配置管理员账号和 LLM API Key

踩坑提醒：

• FastGPT 的知识库是”应用级”隔离而非”文档级”隔离——同一个应用下的所有文档对有权限的用户都可见。如果需要更细粒度的文档级权限，需要二次开发。
• 工作流节点的超时设置默认偏短（10 秒），复杂检索场景容易超时，需要在工作流设置里调大。
• FastGPT 依赖 OneAPI 做 LLM 统一代理，OneAPI 本身也是个需要维护的服务——出问题时排查链路较长。

精读 FastGPT 见 deep-dive-fastgpt.md。

场景 3：LLM 应用开发平台 -> Dify

典型画像：技术团队构建多种 LLM 应用（不只是 RAG），需要 Prompt 管理、Agent 编排、A/B 测试、多模型切换等开发平台能力。

推荐 Dify 的理由：

• 144K star，开源 LLM 应用平台中生态最大——遇到任何问题，大概率有人踩过坑并写了解决方案
• 可视化工作流是 Dify 的杀手级特性：拖拽式编排 Agent 节点、知识检索节点、条件分支、循环、HTTP 请求节点
• Prompt 管理支持版本控制和 A/B 测试，可以对比不同 Prompt 的效果
• 多模型支持：同一个工作流可以同时用 GPT-4 做推理、用 Claude 做摘要、用本地模型做 Embedding
• API 优先设计：所有功能都有 API，方便嵌入到现有产品中

不选其他的理由：

• WeKnora：不是”应用开发平台”，只是”检索引擎”——缺少 Prompt 管理和 Agent 编排
• RAGFlow：纯 RAG，无法构建非 RAG 类应用（如纯对话、工具调用）
• AnythingLLM：定制能力太弱，无法做 Agent 编排
• FastGPT：工作流能力有，但生态和扩展性不如 Dify

典型部署：

# docker-compose 完整部署（含 PostgreSQL + Redis + Weaviate + Nginx）
git clone https://github.com/langgenius/dify.git
cd dify/docker
docker-compose up -d
# 访问 /install 初始化

踩坑提醒：

• Dify 的知识检索节点底层是相对标准的向量检索，没有 RAGFlow 的深度文档理解，也没有 WeKnora 的三路混合。如果检索质量不够，需要自己替换 Embedding 模型或加 Reranker 节点。
• 工作流在复杂场景下（> 20 个节点）调试体验会变差——日志分散在各节点，没有全局 trace view。建议拆分成多个子工作流。
• Dify 的”知识库”和”工作流”是两个独立概念——知识库只管建索引，工作流决定怎么用。新手容易以为”建了知识库就完了”，忘了在工作流里加知识检索节点。

精读 Dify 见 deep-dive-dify.md。

场景 4：扫描件 / 复杂文档处理 -> RAGFlow

典型画像：每天处理上百份 PDF——合同、发票、财报、技术手册——其中大量表格、嵌套图片、数学公式，传统方案提取出来是乱码。

推荐 RAGFlow 的理由：

• DeepDoc 是 RAGFlow 的核心差异化能力：自研的文档深度理解引擎，不是外包给 pdfplumber/pymupdf 的浅层封装
• 支持表格识别与提取：能把 PDF 里的表格还原成结构化数据，而不是把所有单元格拼成一串文字
• 内建 OCR：扫描件不需要预处理，直接上传
• 20+ 文件格式支持：DOCX、PPTX、XLSX、Markdown、CSV、JSON 等
• 分 chunk 策略最灵活：按标题、按段落、按页面、Q&A 拆分，且可以自定义

不选其他的理由：

• WeKnora：文档解析是短板，复杂 PDF 需要自己接外部 OCR/解析工具
• Dify：文档解析是标准能力，对表格/图片/公式的处理远不如 RAGFlow
• AnythingLLM：文档解析最弱，基本就是按文本提取
• FastGPT：文档解析中等，无 DeepDoc 级别的深度理解

典型部署：

# docker-compose（含 Elasticsearch/Infinity + Redis + MySQL + MinIO）
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker
docker-compose up -d

踩坑提醒：

• RAGFlow 的 DeepDoc 解析是 CPU/GPU 密集型操作。大量文档同时上传时，解析队列会积压。建议设置并发限制，或使用独立解析服务器。
• RAGFlow 的对话能力偏弱——它本质是”文档理解 + 检索”，LLM 对话层比较薄。如果需要复杂的多轮对话或 Agent 编排，建议 RAGFlow 做解析和检索，Dify 做对话编排。
• 分 chunk 策略的选择对最终效果影响巨大。一般原则：有明确章节结构的用”按标题”，FAQ 类用”Q&A 拆分”，无结构的长文用”按段落”。

精读 RAGFlow 见 deep-dive-ragflow.md。

场景 5：极致检索质量 / 企业级 -> WeKnora

典型画像：金融/法律/医疗场景，答案必须正确——不是”差不多对”，而是”有出处、可验证”。团队有 Go 后端能力，运维能维护多组件系统。

推荐 WeKnora 的理由：

• 三路混合检索是目前开源 RAG 中检索质量的天花板：
  • BM25（关键词精确匹配）——专有名词、编号、代码片段不会漏
  • 向量检索（语义相似度）——同义表述、跨语言能匹配
  • 知识图谱检索（实体关系）——结构化推理、跨文档关联
• RRF（Reciprocal Rank Fusion）融合三路结果，比单路或简单加权融合效果好 15-25%
• 复合 Rerank：粗排用轻量模型、精排用重模型，在延迟和质量之间取最优平衡
• 自维护 Wiki：知识库内容有过期检测，能自动发现矛盾和过时内容

不选其他的理由：

• Dify：检索是标准方案，没有三路混合，没有图谱检索
• RAGFlow：文档解析强但检索本身是向量 + 关键词双路，缺图谱
• AnythingLLM：单路向量检索，质量差距最大
• FastGPT：检索能力中等，没有 Rerank

典型部署：

# 多组件部署（需向量DB + 图DB + LLM网关 + 核心服务）
# 参考官方 docker-compose，至少需要：
# - PostgreSQL（元数据）
# - Elasticsearch/Infinity（向量索引）
# - Neo4j/Apache AGE（知识图谱）
# - LLM API 网关
docker-compose -f docker-compose-full.yml up -d

踩坑提醒：

• WeKnora 的部署和维护成本是 5 个项目中最高的。首次部署通常需要 1-2 天，后续维护需要有人对向量 DB 和图 DB 有基本了解。
• 三路混合检索的延迟比单路高 2-3 倍（三条路并行检索 + RRF 融合 + Rerank）。对延迟敏感的场景，可以只开两路（BM25 + 向量），关闭图谱。
• Go 核心代码对大多数 Python/JS 开发者来说是黑盒——能调用但不能改。如果需要深度定制检索逻辑，Go 门槛会劝退很多人。

精读 WeKnora 见 deep-dive-weknora.md。

场景 6：犀牛鸟竞赛贡献 -> WeKnora

典型画像：参加腾讯犀牛鸟开源人才培养计划，需要在有限时间内做出有价值的贡献，兼顾学习收益和简历价值。

推荐 WeKnora 的理由：

• WeKnora 是腾讯开源项目，犀牛鸟由腾讯主办——贡献链路最短、导师资源最直接
• Go 技术栈在竞赛中是差异化优势——大多数参赛者只会 Python/JS，会 Go 的少
• 检索质量方向有明确的改进空间（chunk 策略优化、Rerank 改进、图谱推理增强），每个都能做独立 PR
• 项目有完整的贡献指南和 Issue 标签体系（good first issue / help wanted）

不选其他的理由：

• Dify：生态虽大但竞争也大——144K star 意味着 good first issue 抢的人多
• RAGFlow：Infiniflow 团队维护节奏快，外部贡献者难跟上
• AnythingLLM / FastGPT：竞赛贡献的区分度不够

贡献路径：

1. 先从文档和测试开始（门槛最低，熟悉代码库）
2. 再做 chunk 策略改进（改动小、效果可量化）
3. 最后尝试 Rerank 或图谱检索优化（难度最高、价值最大）

踩坑提醒：

• 竞赛期间要平衡”贡献数量”和”贡献深度”——5 个小 PR 不如 1 个被 maintainer 点赞的中 PR
• WeKnora 的 CI 流程较长，PR 从提交到合入通常需要 3-7 天，要提前规划

犀牛鸟竞赛贡献指南见 deep-dive-weknora-contribution.md。

反模式

日常类比：知道该选什么很重要，知道不该怎么选同样重要——就像知道”发烧不能捂汗”比知道”发烧要吃退烧药”更能救命。

反模式 1：按 Star 数选型

错误认知：Dify 144K star，选它不会错。

正确理解：Star 数反映的是”知名度”和”社区活跃度”，不是”对你的场景的适配度”。一个只做 PDF 表格提取的项目，用 Dify 144K star 的标准检索，效果远不如用 RAGFlow 83K star 的 DeepDoc。Star 数是参考指标，不是决策依据。

反模式 2：追求”全都要”

错误认知：我要检索质量最好 + 文档解析最强 + Agent 编排最灵活 + 部署最简单。

正确理解：这 5 个项目中没有任何一个同时满足以上所有条件。这就是为什么有”混合方案”——但混合方案本身的集成和维护成本也不低。”全都要”的结局通常是”全都不精”。正确做法是：确定 1-2 个最核心的需求，选最匹配的；其余需求通过次优但可接受的方式覆盖。

反模式 3：低估文档预处理的工作量

错误认知：选了 RAGFlow 就不用管文档质量了，直接上传就行。

正确理解：即使是最强的文档解析引擎，也无法修复源文档的问题——扫描件模糊、表格跨页、公式用图片代替而非 LaTeX。数据清洗（Garbage In, Garbage Out）在 RAG 中永远是第一步，且通常占整个项目 40-60% 的工作量。选型时不要只看”解析能力”，要看”解析能力 + 你的文档质量”的综合效果。

反模式 4：忽略检索延迟

错误认知：检索质量越高越好，延迟无所谓。

正确理解：WeKnora 的三路混合检索延迟是 AnythingLLM 单路检索的 2-3 倍。在实时对话场景（客服、搜索建议），用户对 > 3 秒的响应就会感到不耐烦。如果业务对延迟有硬约束，检索质量必须做妥协——开两路而非三路、用轻量 Reranker 而非重模型、减少 Top-K。

反模式 5：选完型就不迭代

错误认知：决策树选出了 WeKnora，以后就一直用 WeKnora。

正确理解：RAG 选型不是一次性的。团队在变、文档在变、需求在变、项目本身也在变。正确的姿势是：先用最简单的方案跑通（AnythingLLM 或 Dify），有了真实数据和反馈后，再根据实际瓶颈决定是否迁移到更复杂的方案。详见下方”从原型到生产的迁移路径”。

反模式 6：只看功能列表，不看架构限制

错误认知：FastGPT 支持自定义 LLM、支持知识库、支持工作流——功能都有了。

正确理解：功能列表说的是”能不能做”，架构限制说的是”做得好不好”以及”改起来难不难”。FastGPT 的工作流是 TypeScript 实现的，扩展工作流节点需要写 TS 代码并重新编译——而 Dify 的工作流节点可以通过 Python 脚本动态定义，不需要改 Dify 本体。功能列表是表面，架构是地基。

混合方案

什么时候需要混合方案？当你有两个以上的核心需求，且没有任何单一项目能同时满足时。

混合方案 1：Dify 编排 + WeKnora 检索后端

适用场景：既要灵活的 Agent 编排（Dify 的强项），又要极致的检索质量（WeKnora 的强项）。

架构：

用户请求
    │
    ▼
┌─────────┐    ┌─────────────────┐
│  Dify    │───>│ WeKnora REST API │───> 三路混合检索
│ 工作流   │    └─────────────────┘     + Rerank
│ 编排     │              │
│          │<─────────────┘ 返回检索结果
│          │
│          │───> LLM 生成回答
└─────────┘

实现方式：在 Dify 工作流中，用”HTTP 请求”节点调用 WeKnora 的检索 API，把返回结果作为知识上下文传给 LLM 节点。

代价：

• 多了一套 WeKnora 的运维（向量 DB + 图 DB + 核心服务）
• Dify 的知识库管理界面管不了 WeKnora 的索引——文档更新需要双写或单独对接 WeKnora
• 两系统间的延迟叠加：WeKnora 检索 1-2 秒 + Dify 工作流编排 0.5-1 秒 + LLM 生成 1-3 秒 = 总延迟 2.5-6 秒

适合的团队：10 人以上技术团队，有专人维护 WeKnora，Dify 只做应用层。

混合方案 2：RAGFlow 解析 + Dify 编排

适用场景：文档又多又复杂（PDF 表格 + 扫描件），同时需要 Agent 编排和多轮对话。

架构：

文档上传
    │
    ▼
┌──────────┐     ┌──────────────┐
│ RAGFlow  │────>│ RAGFlow 的   │
│ DeepDoc  │     │ 向量索引      │
│ 解析+分chunk│   └──────┬───────┘
└──────────┘            │
                        ▼
用户请求 ──> Dify ──> RAGFlow 检索 API ──> 返回 chunks ──> LLM 生成

实现方式：RAGFlow 做文档解析和索引构建（这一步只需要在文档更新时跑），Dify 在对话时调用 RAGFlow 的检索 API 获取 chunks。

代价：同方案 1 的运维和延迟叠加问题，但 RAGFlow 部署比 WeKnora 简单（组件少）。

混合方案 3：AnythingLLM 单机 + 云端 LLM

适用场景：数据合规要求文档和索引不能出本地，但本地 GPU 跑不动大模型。

架构：

┌─────────────────────────────────┐
│ AnythingLLM (本地)              │
│   ├── LanceDB (本地向量索引)    │
│   ├── 文档存储 (本地)           │
│   └── LLM 调用 ───────────────>│──> OpenAI API / Claude API (云端)
│                                 │    只传检索结果和 Prompt，不传原文档
└─────────────────────────────────┘

关键风险：虽然原文档不出本地，但检索结果（chunks）和 LLM 生成的回答会经过云端——合规审查是否允许？需要和法务确认。

混合方案选型判断

从原型到生产的迁移路径

日常类比：先骑自行车验证路线，确认值得去再买摩托车——而不是一上来就买哈雷。

阶段 0：确认需求（1-3 天）

不要选平台，先回答这些问题：

1. 用户是谁？他们问什么类型的问题？
2. 知识库有多少文档？什么格式？增长速度？
3. 答案错误的代价有多大？
4. 有多少人力可以持续维护？
5. 延迟和并发要求是什么？

如果这些问题答不上来，说明还没到选型的时候——先去做用户访谈。

阶段 1：原型验证（1-2 周）

原则：用最简单的方案跑通，用真实数据验证假设。

原型的目标不是”效果最好”，而是”用最小成本确认方向正确”。如果 Dify + 基础检索已经能满足 70% 的问题，可能根本不需要迁移到 WeKnora——剩下 30% 也许通过优化 chunk 策略就能解决。

阶段 2：瓶颈定位（1-2 周）

用原型收集真实数据后，分析瓶颈在哪：

阶段 3：渐进迁移（2-8 周）

原则：增量迁移，不要一次性切换。

以”从 Dify 迁移到 WeKnora”为例：

1. 第 1 周：部署 WeKnora，用同一批文档建索引，但不接入生产流量
2. 第 2-3 周：A/B 测试——相同问题同时走 Dify 和 WeKnora，人工对比答案质量
3. 第 4 周：WeKnora 质量确认优于 Dify 后，逐步切流量（10% -> 50% -> 100%）
4. 第 5-8 周：Dify 降级为 fallback（WeKnora 超时或异常时走 Dify），稳定后下线 Dify

关键提醒：迁移期间双系统并行运行，运维成本翻倍。确保有足够人力支撑过渡期。

迁移的止损点

什么时候应该放弃迁移，接受当前方案的不足？

• 迁移 4 周后，新方案质量没有显著提升（< 5% 的召回率提升）——不值得
• 迁移导致运维成本增加 3 倍以上，但质量提升 < 20%——ROI 不够
• 团队对新技术栈（如 Go）的学习曲线超过 2 个月——考虑用熟悉的方案 + 外部插件替代

综合对比表

与 Memory 系统的关系

已有 Memory 系统（如 DB-Agent-Memory）时的选型考虑：

• Memory 管”记住”（对话历史/用户偏好） — 任何 RAG 平台都需要配合 Memory 使用
• RAG 管”查到”（外部文档） — 选哪个 RAG 不影响 Memory 选型
• 重叠区处理：当检索结果与 Memory 中记忆冲突时，需要冲突解决策略

Memory vs RAG 边界见 B 线 - Memory 与 RAG 边界 腾讯生态分工见 B 线 - 腾讯记忆生态 DB-Agent-Memory 详见 deep-dive-tencentdb-agent-memory

交叉引用

附录：Mermaid 决策树

flowchart TD
    START[选 RAG 平台] --> Q1{需要可视化<br>Agent 工作流?}
    Q1 -->|是| Q1A{企业多租户<br>+ 权限?}
    Q1A -->|是| FAST[FastGPT]
    Q1A -->|否| DIFY[Dify]

    Q1 -->|否| Q2{检索质量<br>要求极高?}
    Q2 -->|是| Q2A{团队能维护<br>Go + 3+ 依赖?}
    Q2A -->|是| WK[WeKnora]
    Q2A -->|否| Q2B{PDF/表格<br>占比 > 30%?}
    Q2B -->|是| RF[RAGFlow]
    Q2B -->|否| DIFY2[Dify + 自定义检索]

    Q2 -->|否| Q3{完全本地<br>零外部依赖?}
    Q3 -->|是| ALL[AnythingLLM]
    Q3 -->|否| Q4{快速原型<br>还是生产?}
    Q4 -->|原型| DIFY3[Dify]
    Q4 -->|生产| WK2[WeKnora / RAGFlow]

    style WK fill:#e8f4e8
    style DIFY fill:#e8e8f4
    style DIFY2 fill:#e8e8f4
    style DIFY3 fill:#e8e8f4
    style RF fill:#f4e8e8
    style ALL fill:#f4f4e8
    style FAST fill:#e8f4f4

证据等级