Ch09: 选型决策与生产化——从 Demo 到上线

Part 4: 评估与选型 前置章节：Ch08: 如何衡量 RAG 的好坏——评估方法论 后续章节：Ch10: 竞赛贡献路径与开放挑战

1. 开场：选择的悖论

买车的时候，你不需要法拉利去超市买菜，也不需要五菱宏光去跑赛道。一辆车好不好，完全取决于你要用它做什么。但如果 4S 店同时摆了 5 辆车，销售都在吆喝”我们家最强”，你反而会被信息淹没——这就是心理学上的”选择悖论”（Paradox of Choice）：选项越多，决策越难，最后容易犯两种错：要么选了”看起来最火”的那辆（按 Star 数选型），要么想着”能不能把法拉利的引擎装到五菱宏光的车身上”（追求全都要）。

RAG 平台选型也面临同样的困境。当前开源 RAG 领域有 5 个主力项目，每个都有明确的设计哲学差异：WeKnora 把检索质量推到极致，Dify 把开发体验做到最好，RAGFlow 把文档解析做到最强，AnythingLLM 把部署门槛降到最低，FastGPT 把企业权限做得最完善。没有一个”综合最强”的万能选手，只有”最匹配你场景”的那一个。

选型的核心困难不是”评测哪个分高”，而是”搞清楚自己最在意什么”。一个只做 PDF 表格提取的项目，用 Dify 144K Star 的标准检索，效果远不如用 RAGFlow 83K Star 的 DeepDoc。Star 数反映的是知名度，不是对你的适配度。

本章的目标是把这个看似混沌的决策空间变得有序。先用七大维度帮你明确”自己最在意什么”，再用决策树帮你在 3-4 个问题内定位到唯一答案，然后给出六个典型场景的具体推荐，并警告六种常见的选型反模式。下半章聚焦”选完之后怎么办”——从 Demo 到生产有六维鸿沟要跨越，四种部署模式可选，生产环境有一组关键指标必须达标。最后对 5 个平台做生产就绪度评估，帮你判断”选了它之后还要补多少功课”。

选型不是一次性的。正确姿势是：先用最简单的方案跑通原型，有了真实数据和反馈后，再根据实际瓶颈决定是否迁移到更复杂的方案。就像学开车——先用驾校的桑塔纳练手，拿了驾照再决定买什么车。

2. 七大决策维度

选房子要看位置、面积、价格、学区、物业。选 RAG 平台也一样，关键是搞清楚自己最在意哪个维度，而不是每个维度都要满分。以下七个维度按优先级排列——从最容易”选错就回不了头”的开始。

维度一：团队规模与技术能力

这是第一道分水岭。一个没有后端工程师的 3 人团队，和一个 20 人技术团队，面对同样的业务需求，最优选型完全不同。关键判断：团队能否维护 3 个以上的外部依赖（向量数据库 + 图数据库 + LLM 网关）？如果不能，WeKnora 直接排除。个人开发者只会 Python/JS 排除 WeKnora（Go 核心难改），3-5 人创业团队全栈但人少运维资源有限偏好单 Docker 部署方案，10-20 人技术团队有后端 + 运维可以接受多组件考虑 WeKnora 或 RAGFlow，企业 IT 团队需要多租户 + 权限 + 审计则指向 FastGPT 或自研权限层。这里容易犯的错是高估自己团队的运维能力——”我们有后端工程师”不等于”我们有精力维护 Neo4j 图数据库”。RAG 系统的运维不只是启动服务，还包括索引重建、知识库更新、向量库内存监控、LLM 限流处理，这些日常运维任务会持续消耗人力。

维度二：文档类型与复杂度

文档是 RAG 的燃料。给拖拉机加航空煤油跑不起来，给喷气式飞机加柴油也飞不上天。关键判断：文档中表格/图片/公式占比超过 30%？如果是，RAGFlow 的 DeepDoc 是目前开源方案中解析能力最强的。纯文本为主差异不大，代码 + 文档混合选 Dify 的灵活分 chunk，结构化数据选 WeKnora 的图谱检索。

维度三：检索质量要求

检索质量是 RAG 的命门。但”高质量”是有代价的——就像精度手表比普通手表贵 10 倍，大多数场景不需要那 0.01 秒精度。关键判断：答案错误的代价有多大？客服答错可以道歉，医疗诊断答错要出人命。代价越高，越应该选 WeKnora 的三路混合检索（BM25 + 向量 + 知识图谱 + RRF 融合 + 复合 Rerank）。基础够用（召回率 > 60%）任何方案都行，中等要求（> 80%）需要混合检索 + Rerank，极高要求（> 95%）只有 WeKnora 能达到。

维度四：部署环境

关键判断：数据合规是否允许文档上传到第三方云？如果不允许，排除纯云方案。完全本地/离线选 AnythingLLM（内建 LanceDB，数据不出机器），自托管 Docker 全部 5 个都支持，云托管选 Dify Cloud 或 FastGPT Cloud 省 80% 运维成本，混合部署选 Dify（数据在本地、模型在云端）。

维度五：预算与资源

关键判断：有没有 3 个月以上的持续投入承诺？RAG 不是”上线就完”的项目——文档在变、模型在变、用户需求在变。低预算（< 2 人月）选 AnythingLLM 一天上线，中预算（2-10 人月）选 Dify 一两周上线，高预算（> 10 人月）WeKnora 需要 1-3 月深度定制。没有持续维护预算，选最简单的方案。

维度六：可扩展性需求

扩展性像房子的承重墙——建时多花一点，改时少拆很多。关键判断：6 个月内是否需要深度定制检索逻辑或接入自定义数据源？如果是，排除 AnythingLLM（固定管线）和 FastGPT（扩展性有限）。自定义检索策略最灵活的是 WeKnora，Agent 编排最灵活的是 Dify，分 chunk 策略最灵活的是 RAGFlow。

维度七：生态与社区

生态规模决定你遇到问题时能多快找到答案。但 Star 数不等于活跃度——要看的指标是近 30 天 PR 数、中文文档质量、插件/扩展市场、企业客户案例。关键判断：团队是否习惯”看文档解决问题”还是”去社区问人”？文档党选 WeKnora/RAGFlow（中文文档完善），社区党选 Dify（社区最大，踩坑记录最多）。WeKnora 14.3K Star 但近 30 天 PR 活跃且中文文档质量高，Dify 144K Star 且极活跃有插件市场和大量企业案例，RAGFlow 83K Star 且活跃中文文档完善，AnythingLLM 61K Star 活跃度中等有插件市场但中文文档质量一般，FastGPT 28K Star 活跃度中等但中文文档质量高企业案例多。生态的另一个维度是”插件/扩展市场”——如果你未来需要接入更多数据源或工具，Dify 和 AnythingLLM 有正式的插件市场，而 WeKnora 和 RAGFlow 没有官方插件机制需要通过代码扩展。

3. 决策树

以下决策树从最关键的问题开始逐层分支。按顺序回答问题，3-4 个问题就能定位到唯一答案。

Q1: 是否需要可视化 Agent 工作流编排？
├── 是 → Q1a: 是否需要企业级多租户 + 权限？
│       ├── 是 → FastGPT（企业级权限 + 工作流）
│       └── 否 → Dify（最灵活的工作流编排）
└── 否 → Q2: 检索质量要求是否极高（答案错误代价大）？
        ├── 是 → Q2a: 团队能否维护 Go 栈 + 3 个以上外部依赖？
        │       ├── 是 → WeKnora（三路混合检索 + 图谱 + 复合 Rerank）
        │       └── 否 → Q2b: PDF/表格占比是否超过 30%？
        │               ├── 是 → RAGFlow（DeepDoc 最强文档解析）
        │               └── 否 → Dify + 自定义检索策略
        └── 否 → Q3: 是否需要完全本地部署，零外部依赖？
                ├── 是 → AnythingLLM（单文件部署，内建向量库）
                └── 否 → Q4: 是快速原型还是生产系统？
                        ├── 原型 → Dify（拖拽即用，分钟级上手）
                        └── 生产 → WeKnora / RAGFlow（质量天花板）

使用方式：从 Q1 开始，诚实回答每个问题，沿分支向下走，直到到达推荐节点。如果同时满足多条路径的起点条件（比如既要 Agent 编排又要极致检索），考虑混合方案：Dify 做编排层负责工作流和对话管理，WeKnora 做检索后端负责三路混合检索和 Rerank，两者通过 HTTP API 对接。这种混合方案的代价是多一套 WeKnora 的运维（向量 DB + 图 DB + 核心服务），且两系统间延迟叠加（WeKnora 检索 1-2 秒 + Dify 编排 0.5-1 秒 + LLM 生成 1-3 秒 = 总 2.5-6 秒）。

需要注意的是，决策树给的是”最匹配”而非”唯一可行”。到达某个推荐节点后，建议回头检查其他维度是否有硬约束——比如决策树推荐了 WeKnora，但你的部署环境是完全离线的，那就需要重新评估。另一个常见情况是决策树推荐了 RAGFlow（因为文档复杂），但你同时需要 Agent 编排能力——这时候正确选择不是换掉 RAGFlow，而是用混合方案：RAGFlow 做文档解析和索引构建（这步只在文档更新时跑），Dify 在对话时调用 RAGFlow 检索 API 获取 chunks 再传给 LLM 生成。

4. 六个场景化推荐

场景一：个人学习/原型验证 —— AnythingLLM

典型画像：一个人、一台笔记本、想今晚就跑起来看看 RAG 是什么效果。推荐理由：安装到跑通全程 30 分钟，Docker 一行命令（docker run -d -p 3001:3001 anythingllm/anythingllm）或直接下载 Electron 桌面版双击打开；内建 LanceDB 做向量存储不需要额外装 Milvus/Qdrant/Chroma；支持多种 LLM 后端（OpenAI/Ollama/LM Studio），切换零代码；UI 开箱即用不需要写一行前端。不选其他的原因：WeKnora 个人维护不动 3 个外部依赖，Dify 配置项太多原型阶段不需要那么多选择，RAGFlow 解析虽强但原型阶段通常只喂几十篇文档差异不大，FastGPT 企业权限对个人无用。踩坑提醒：默认 chunk 策略偏粗糙（按 token 数硬切）如果文档有明确章节结构检索质量会明显下降可在设置里切换为”自然段落”分 chunk；LanceDB 是嵌入式向量库数据量超过 10 万条后性能下降如果未来数据量增长需要迁移到外部向量库。

场景二：中小企业客服机器人 —— FastGPT

典型画像：10-50 人公司，客服 3-5 人，需要让 AI 回答用户常见问题，要求按部门隔离知识库，经理能看统计但普通客服不能看财务知识库。推荐理由：多租户 + 角色权限是 FastGPT 的核心设计而非后补功能（这意味着权限模型是完整的不是”能设密码”级别），工作流编排内建可根据用户问题类型先走意图识别节点再分支到不同知识库检索，支持对话统计和反馈收集方便运营持续优化知识库，中文生态好文档和案例都针对国内企业场景。不选其他的原因：Dify 权限偏基础企业级多租户需自研，WeKnora 无可视化工作流客服场景需要灵活编排（意图识别 -> 知识检索 -> 兜底转人工），RAGFlow 无 Agent 编排无法实现”检索不到就转人工”的流程，AnythingLLM 无多租户无权限。踩坑提醒：知识库是”应用级”隔离而非”文档级”隔离——同一应用下所有文档对有权限的用户都可见需更细粒度则要二开；工作流节点超时设置默认偏短（10 秒）复杂检索容易超时需在工作流设置里调大；FastGPT 依赖 OneAPI 做 LLM 统一代理，OneAPI 本身也是个需要维护的服务出问题时排查链路较长。

场景三：LLM 应用开发平台 —— Dify

典型画像：技术团队构建多种 LLM 应用（不只 RAG），需要 Prompt 管理、Agent 编排、A/B 测试、多模型切换等开发平台能力。推荐理由：144K Star 开源 LLM 应用平台中生态最大遇到任何问题大概率有人踩过坑并写了解决方案；可视化工作流是杀手级特性——拖拽式编排 Agent 节点、知识检索节点、条件分支、循环、HTTP 请求节点；Prompt 管理支持版本控制和 A/B 测试可对比不同 Prompt 效果；多模型支持同一工作流可以同时用 GPT-4 做推理用 Claude 做摘要用本地模型做 Embedding；API 优先设计所有功能都有 API 方便嵌入现有产品。不选其他的原因：WeKnora 不是”应用开发平台”只是”检索引擎”缺少 Prompt 管理和 Agent 编排，RAGFlow 纯 RAG 无法构建非 RAG 类应用（如纯对话/工具调用），AnythingLLM 定制能力太弱无法做 Agent 编排，FastGPT 工作流能力有但生态和扩展性不如 Dify。踩坑提醒：知识检索节点底层是相对标准的向量检索没有 RAGFlow 的深度文档理解也没有 WeKnora 的三路混合如果检索质量不够需自己替换 Embedding 模型或加 Reranker 节点；工作流超过 20 个节点调试体验变差日志分散在各节点没有全局 trace view 建议拆分成多个子工作流；Dify 的”知识库”和”工作流”是两个独立概念新手容易以为”建了知识库就完了”忘了在工作流里加知识检索节点。

场景四：扫描件/复杂文档处理 —— RAGFlow

典型画像：每天处理上百份 PDF——合同、发票、财报、技术手册——其中大量表格、嵌套图片、数学公式，传统方案提取出来是乱码。推荐理由：DeepDoc 是 RAGFlow 的核心差异化能力——自研的文档深度理解引擎不是外包给 pdfplumber/pymupdf 的浅层封装；支持表格识别与提取能把 PDF 里的表格还原成结构化数据而不是把所有单元格拼成一串文字；内建 OCR 扫描件不需要预处理直接上传；20+ 文件格式支持（DOCX/PPTX/XLSX/Markdown/CSV/JSON 等）；分 chunk 策略最灵活按标题、按段落、按页面、Q&A 拆分且可自定义。不选其他的原因：WeKnora 文档解析是短板复杂 PDF 需要自己接外部 OCR/解析工具，Dify 文档解析是标准能力对表格/图片/公式的处理远不如 RAGFlow，AnythingLLM 文档解析最弱基本就是按文本提取，FastGPT 文档解析中等无 DeepDoc 级别的深度理解。踩坑提醒：DeepDoc 解析是 CPU/GPU 密集型操作大量文档同时上传时解析队列会积压建议设置并发限制或使用独立解析服务器；对话能力偏弱——RAGFlow 本质是”文档理解 + 检索”LLM 对话层比较薄如果需要复杂多轮对话或 Agent 编排建议 RAGFlow 做解析和检索 Dify 做对话编排；分 chunk 策略选择对最终效果影响巨大一般原则是有明确章节结构的用”按标题”、FAQ 类用”Q&A 拆分”、无结构长文用”按段落”。

场景五：极致检索质量 —— WeKnora

典型画像：金融/法律/医疗场景，答案必须正确——不是”差不多对”，而是”有出处、可验证”。团队有 Go 后端能力，运维能维护多组件系统。推荐理由：三路混合检索是目前开源 RAG 中检索质量的天花板——BM25 保证专有名词和编号不漏、向量检索保证同义表述和跨语言能匹配、知识图谱检索保证结构化推理和跨文档关联；RRF（Reciprocal Rank Fusion）融合三路结果比单路或简单加权效果好 15-25%；复合 Rerank 粗排用轻量模型精排用重模型在延迟和质量间取最优平衡；自维护 Wiki 有过期检测能自动发现矛盾和过时内容。不选其他的原因：Dify 检索是标准方案没有三路混合没有图谱检索，RAGFlow 文档解析强但检索本身是向量 + 关键词双路缺图谱，AnythingLLM 单路向量检索质量差距最大，FastGPT 检索能力中等没有 Rerank。踩坑提醒：部署和维护成本是 5 个项目中最高的首次部署通常需要 1-2 天后续维护需要有人对向量 DB 和图 DB 有基本了解；三路混合检索延迟是单路的 2-3 倍（三条路并行取最慢 + RRF 融合 + Rerank）对延迟敏感场景可只开两路（BM25 + 向量）关闭图谱；Go 核心代码对大多数 Python/JS 开发者来说是黑盒——能调用但不能改，如果需要深度定制检索逻辑 Go 门槛会劝退很多人。

场景六：犀牛鸟竞赛 —— WeKnora

典型画像：参加腾讯犀牛鸟开源人才培养计划，需要在有限时间内做出有价值的贡献，兼顾学习收益和简历价值。推荐理由：WeKnora 是腾讯开源项目犀牛鸟由腾讯主办贡献链路最短导师资源最直接；Go 技术栈在竞赛中是差异化优势——大多数参赛者只会 Python/JS 会 Go 的少；检索质量方向有明确的改进空间（chunk 策略优化、Rerank 改进、图谱推理增强）每个都能做独立 PR；项目有完整的贡献指南和 Issue 标签体系（good first issue / help wanted）。不选其他的原因：Dify 生态虽大但竞争也大 144K Star 意味着 good first issue 抢的人多，RAGFlow 团队维护节奏快外部贡献者难跟上，AnythingLLM/FastGPT 竞赛贡献区分度不够。贡献路径建议：先从文档和测试开始（门槛最低熟悉代码库），再做 chunk 策略改进（改动小效果可量化），最后尝试 Rerank 或图谱检索优化（难度最高价值最大）。踩坑提醒：竞赛期间要平衡”贡献数量”和”贡献深度”——5 个小 PR 不如 1 个被 maintainer 点赞的中 PR；WeKnora 的 CI 流程较长 PR 从提交到合入通常需要 3-7 天要提前规划。

5. 六个选型反模式

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

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

反模式二：追求”全都要”。 错误认知是”我要检索最好 + 解析最强 + 编排最灵活 + 部署最简单”。正确理解是 5 个项目没有任何一个同时满足以上所有。”全都要”的结局通常是”全都不精”。正确做法：确定 1-2 个最核心需求选最匹配的，其余需求通过次优但可接受的方式覆盖。

反模式三：低估文档预处理的工作量。 错误认知是”选了 RAGFlow 就不用管文档质量了”。正确理解是即使最强的解析引擎也无法修复源文档的问题——扫描件模糊、表格跨页、公式用图片代替。数据清洗在 RAG 中永远是第一步，通常占项目 40-60% 工作量。

反模式四：忽略检索延迟。 错误认知是”检索质量越高越好延迟无所谓”。正确理解是 WeKnora 三路混合延迟是 AnythingLLM 单路的 2-3 倍。实时对话场景用户对超过 3 秒响应就会不耐烦。业务有延迟硬约束时检索质量必须妥协——开两路而非三路，用轻量 Reranker 而非重模型。

反模式五：选完型就不迭代。 错误认知是”决策树选出 WeKnora 以后就一直用”。正确理解是 RAG 选型不是一次性的——团队在变、文档在变、需求在变。正确姿势是先用简单方案跑通有真实反馈后再决定是否迁移。详细迁移路径：先 Dify 验证方向，确认瓶颈后根据瓶颈类型选择迁移目标，增量迁移不做一次性切换。

反模式六：只看功能列表不看架构限制。 错误认知是”FastGPT 支持自定义 LLM、知识库、工作流——功能都有了”。正确理解是功能列表说的是”能不能做”，架构限制说的是”做得好不好”以及”改起来难不难”。FastGPT 扩展工作流节点需要写 TS 代码并重新编译，Dify 的工作流节点可以通过 Python 脚本动态定义。功能列表是表面，架构是地基。

6. Demo 到生产的六维鸿沟

日常类比：做一顿家常饭——食材现买、锅碗现洗、吃完不用收拾。开一家餐厅——每天定点开门、菜单不能缺菜、后厨不能断供、每道菜口味一致、食材提前备好、还得分不同客人的忌口。给 4 个人做饭和给 400 人做宴席，不是”做的量多一点”那么简单，而是整个组织方式、流程设计、质量控制都完全不同。

从技术上看，Demo 到生产的鸿沟体现在六个维度：

规模维度： Demo 阶段文档量百级，生产需要万级到百万级。典型断裂场景：开发时 100 篇文档检索质量很好，上线后 10 万篇文档检索噪声指数级增长，Faithfulness 从 0.85 跌到 0.55。根因不是算法变了，而是分块策略在大规模下失效。

并发维度： Demo 阶段单用户，生产需要十到千 QPS。常见断裂点：单用户测试正常，十个用户同时提问 LLM API 限流导致一半请求超时。RAG 的 QPS 瓶颈通常不在检索层（向量库可扩容），而在 LLM 的限流——GPT-4 限流约 500 RPM，即使你的向量库能处理一万 QPS，LLM 也只能过 8-10。

延迟维度： Demo 阶段”能跑就行”，生产需要 P95 < 3 秒的 SLA。关键区分”平均延迟”和”尾延迟”——P50 可能 2 秒但 P99 可能 8 秒，尾延迟通常来自图谱检索多跳推理或 LLM 偶发慢响应。

准确率维度： Demo 阶段人工看几个 case，生产需要 RAGAS 端到端量化。不能只看检索召回率——召回率高但精确度低意味着噪声太多，精确度高但召回率低意味着漏了关键信息。Faithfulness、Answer Relevancy、Context Precision、Context Recall 四指标的组合诊断才是正确打开方式。

可用性维度： Demo 阶段宕机手动重启，生产需要 99.9% uptime + 自动 failover。RAG 的可用性取决于最脆弱的依赖——通常是 LLM API。OpenAI 历史上出现过多次全球性宕机，如果没有降级策略 LLM 一挂就只能返回”系统繁忙”。

成本维度： Demo 阶段不看账单，生产需要 $/query 精细管控。RAG 单次查询成本中 LLM 生成费占 70-90%。标准型（GPT-4o）约 $0.02/query，1K QPS 月成本约 $52K。没有成本规划的 RAG 项目上线后经常因为”账单太吓人”被紧急叫停。

7. 四种部署模式

模式一：单机部署（AnythingLLM Desktop）

日常类比：骑自行车——一个人骑刚好，零油耗零停车费随停随走。最适合”只想把本地 PDF 丢进去问问”的场景，不需要考虑别人同时用、不需要担心数据安全，更不需要操心服务是否稳定。适用场景：个人知识管理、隐私优先、原型验证。最低资源 1C2G/1-5GB 磁盘。AnythingLLM 在架构上做了三个减法决策：用 SQLite 替代 PostgreSQL 消除数据库运维、用 LanceDB 替代 Milvus 消除向量库运维、只走单路向量检索消除 BM25 倒排索引维护。三个减法换来极低资源消耗和极简部署体验，代价是检索质量天花板低、无法水平扩容、无多租户。配合 Ollama 本地 LLM 可实现”下载即用数据不出本机”——这是其他 4 个项目做不到的。局限：无水平扩容无多租户无高可用，SQLite 万级文档后查询延迟明显增大，文件损坏会导致全部数据丢失没有主备恢复机制。

模式二：Docker Compose（大多数项目）

日常类比：开一家连锁加盟店——设备由总部配好（Docker 镜像），按照手册组装（docker-compose.yaml），开店成本低，但每家店独立运营不能跨店调货。适用场景：中小团队、私有化部署、快速上线、日均 < 10K 查询。对于大多数 RAG 项目来说这是最主流的部署方式，因为它在”部署便利性”和”生产可靠性”之间取得了较好的平衡。典型包含 Nginx（反向代理）+ API Server + Worker（异步任务）+ PostgreSQL（持久化）+ Redis（缓存）+ 向量数据库（检索），最低 2C4G（Dify/FastGPT/WeKnora）到 4C8G（RAGFlow 因为 DeepDoc 解析消耗大）。五平台 Docker 支持对比：Dify 6 服务约 2GB 冷启动 30 秒，RAGFlow 5+ 服务约 5GB 冷启动 60 秒，AnythingLLM 1 服务约 800MB 冷启动 10 秒，FastGPT 4+ 服务约 1.5GB 冷启动 30 秒，WeKnora 5+ 服务约 1GB 冷启动 20 秒。局限：单节点部署 API Server 无副本、数据库无主备、扩容需改 yaml + 重启服务。一旦需要高可用或水平扩容必须迁移到 Kubernetes——但这个迁移不是简单”把 docker-compose 翻译成 Helm Chart”，需要重新设计有状态服务的部署方式。

模式三：Kubernetes（生产级扩缩容）

日常类比：经营酒店集团——前台统一接客（Ingress），各楼层按需开关（Pod），空调自动调温（Service Mesh），一间房出问题自动换房（Pod 重调度）。适用场景：企业生产、高可用、自动扩缩容。三个关键设计：API Server 无状态化（所有状态存 DB，Pod 可随意杀重启）、Worker 按队列深度扩缩容（文档摄入积压时自动加 Worker）、向量库用 StatefulSet（数据不能丢需稳定网络标识）。目前 FastGPT 在 K8s 部署上走得最远（Sealos 云原生平台），Dify 有社区贡献的 Helm Chart，WeKnora 和 RAGFlow 需自建。

模式四：Serverless（未来方向）

日常类比：共享办公空间——不用时不付租金，有人来才开灯。面临三个挑战：向量库加载索引需数十秒但函数冷启动只有几百毫秒（矛盾）、弹性扩容可能打爆 LLM 限流、请求 60-80% 时间在等 LLM 返回但等的时候也在计费。更深层的问题是 RAG 的有状态组件（向量索引、知识图谱、BM25 倒排索引）天然不适合 Serverless。当前 5 个项目均未原生支持，需要更细粒度架构拆分才能实现。

什么时候从 Docker Compose 升级到 K8s？三个信号：日均查询超过 10K、需要 99.9% 以上可用性、需要按团队/客户隔离资源。如果三个信号一个都不满足，Docker Compose 就够了——不要为了”看起来专业”而过早引入 K8s 的运维复杂度。

8. 生产关键指标

生产环境的 RAG 系统需要持续监控四组核心指标。没有数字就没有优化方向——”感觉答案还行”不是生产级系统的健康标准。

延迟指标： P50 < 2 秒（用户”正常体验”）、P95 < 5 秒（”可接受上限”）、P99 < 10 秒（”容忍极限”）、首 Token 延迟 < 1 秒（流式输出的感知速度关键）。WeKnora 的三路检索 P50 约 3-5 秒（图谱路是尾延迟根源），Dify/RAGFlow P50 约 2-4 秒，AnythingLLM P50 约 1.5-3 秒。所有项目的 LLM 生成都是延迟主要来源（占 60-80%）。

吞吐量指标： QPS 上限 = LLM 配额 / 每请求 LLM 调用次数。内部知识库（百人团队）1-5 QPS 无明显瓶颈，企业客服（千人并发）10-50 QPS 瓶颈在 LLM 限流需多模型分流 + 问答缓存，SaaS 平台（万级用户）100+ QPS 需多租户分区 + 本地小模型。

质量指标（RAGAS）： Faithfulness > 0.85（答案有检索支撑，低于此值说明有幻觉）、Answer Relevancy > 0.80（答案回答了问题，低于此值说明答非所问）、Context Precision > 0.75（检索结果噪声低，低于此值说明 Rerank 失效）、Context Recall > 0.80（关键信息都被检索到，低于此值说明检索路数不够）。

成本指标： $/query 是最终衡量标准。经济型（GPT-4o-mini + 本地 Embedding）约 $0.006/query，标准型（GPT-4o）约 $0.02/query，高质量型（GPT-4 + Rerank + 三路检索）约 $0.05/query。月成本 = $/query x 月查询量，1K QPS 标准型月成本约 $52K。

这四组指标之间存在 trade-off：追求更高检索质量（三路混合）会增加延迟和成本；追求更低延迟（单路检索）会牺牲质量；追求更低成本（小模型）会降低生成质量。没有完美平衡点，只有适合你业务场景的平衡点。

9. 五平台生产就绪度

生产就绪度从七个维度评估（部署便利性、可观测性、多租户、高可用、数据管线、成本管控、文档/社区），每维度 1-5 分，按权重加总：

解读：Dify 最接近生产就绪（部署成熟、社区最大、Token 计费面板），缺口在 Metrics/Tracing 和检索深度。FastGPT 在企业 SaaS 场景最成熟（多租户最佳、Sealos 云原生），缺口在检索路数和社区规模。WeKnora 检索深度最强但工程化不足（可观测性只有 zap 日志、部署文档不足、无 Helm Chart），这些缺口正是竞赛贡献机会。RAGFlow 文档解析天花板但多租户弱资源消耗高。AnythingLLM 定位就是个人工具不适合生产。

对于犀牛鸟竞赛参赛者：WeKnora 的 2.65 分看起来不高，但反过来想——正是这些生产化缺口构成了”小改动大收益”的贡献方向：补运维文档（2-3 天）、加 Prometheus Metrics 导出（3-5 天）、写 K8s Helm Chart（5-7 天）、建评估 benchmark（5-7 天）。这些不是锦上添花的功能特性，而是”没有就不能上生产”的基础设施，维护者审核意愿通常更高。

10. 本章小结

选型决策的核心是”匹配”而非”最好”。七大维度帮你明确在意什么，决策树帮你 3-4 个问题定位答案，六个场景化推荐覆盖了从个人学习到竞赛贡献的全谱，六个反模式帮你避开常见陷阱。

选完之后的关键认知是：Demo 到生产有六维鸿沟（规模/并发/延迟/准确率/可用性/成本），不是”把 Demo 部署到服务器上”就完了。四种部署模式从单机到 Serverless 对应不同阶段需求，核心原则是不要为了”看起来专业”而过早引入不必要的复杂度。生产关键指标（Latency P99、QPS、RAGAS 四指标、$/query）是系统健康的数字化标准，没有监控就没有优化。

记住选型的正确姿势：先用 Dify 或 AnythingLLM 跑通原型（1-2 周），收集真实用户数据和反馈，根据实际瓶颈（检索质量不足/文档解析乱码/需要权限隔离/延迟不达标）决定是否迁移，增量迁移不做一次性切换。如果原型阶段就能满足 70% 需求，可能根本不需要迁移——剩下 30% 通过优化 chunk 策略或加 Reranker 就能解决。

下一章将聚焦犀牛鸟竞赛的具体贡献路径和 RAG 领域的开放挑战——从”选什么”和”怎么用”，进入”怎么贡献”和”还有什么没解决”。

导读目录：README.md 上一章：Ch08: 如何衡量 RAG 的好坏——评估方法论 下一章：Ch10: 竞赛贡献路径与开放挑战