本文迁移自 mindcarver/91ai · 原始位置 docs/evaluation/kb-rag-platform-benchmark.md · 由 @阿新聊ai 整理。

四大开源知识库平台 RAG 实测：MaxKB / RAGFlow / FastGPT / Dify

可复现性状态：R1（narrative-only / artifacts-not-published）。 本文保留作者运行记录；报告所述脚本、输入快照和原始结果不在当前仓库，因此第三方目前不能仅凭本仓库复跑分数。详见评测可复现性状态。

TL;DR： 本文记录了作者报告的一手 RAG 平台实测。作者在同一台机器、同一个本地 Ollama（qwen2.5:14b + qwen3-embedding:4b）下，对四个开源知识库平台（MaxKB、RAGFlow、FastGPT、Dify）运行了 4 类数据集（英文技术文本、文本型 PDF、中文段落、扫描/图像文档）。由于原始产物未公开，以下数字和结论应视为运行记录：

• 在本次文本类语料（.txt / 文本 PDF / 中文）上，四家记录的召回为 80–100%，但 FastGPT top-1 与其他平台 top-5 不完全可比；
• 在本次扫描/图像样本和默认解析链路下，只有 RAGFlow 的 DeepDoc OCR 形成有效检索结果（76%），另外三家记录为 0–10%；
• "DeepDoc 解析最强"这句口碑是场景、版本和配置依赖的：本文只能确认它在本次扫描样本中的优势；
• 纯 API 自动化集成的摩擦度：MaxKB 最低，Dify 最高（FastGPT 居中偏上，RAGFlow 有版本回归 bug）。

整理日期：2026-07-03。文中数字为作者本机运行记录；文末列出的是原运行使用或规划公开的产物结构，这些产物当前尚未发布到本仓库。

一、为什么自己测，而不信榜单

开源知识库（RAG）平台的官方文档和营销页几乎都自称"支持 PDF、支持中文、支持私有化、检索又快又准"。但落到企业落地（尤其是高保密制造业、内部知识沉淀、Agent 编排），真正要回答的问题没有一个 README 会写：

• 给它真实的复杂 PDF（带表格、扫描件、多栏版式），它解析得出来吗？
• 中文检索靠不靠谱？分词、切片、embedding 对中文友好吗？
• 灌库、配模型、检索这一整套，能不能纯 API 自动化（决定能不能进 CI/CD、能不能批量管 25 个知识库）？
• 纯内网、数据不出网这个硬约束，到底哪家真做到？

这些问题只有把四个平台真的搭起来、灌同样的语料、问同样的问题、读它的源码和数据库才能回答。本文就是这件事的完整记录。

二、评测环境与公平性控制

2.1 硬件与服务

• 机器：Xeon 72 核 / 62G RAM / RTX 3090 24G，单机。
• 共享后端 LLM：原生（非容器）Ollama，http://<host>:11434，拉了 qwen2.5:14b（LLM）、qwen3-embedding:4b（embedding）。OpenAI 兼容端点 /v1。
• 四个平台全部同机纯私有化部署，共用同一个 Ollama：MaxKB :8004、FastGPT :8003、Dify :8001、RAGFlow :8002。
• Docker 镜像加速已配置（1panel.live / daocloud / rat.dev），v2raya 容器 restart=always。

2.2 公平性口径

为了减少平台外因素的干扰，我们做了三项控制；但下述裁判和 top-K 协议偏差意味着它不是严格 apples-to-apples：

1. 同一个 embedding + 同一个 LLM：四家全部接同一个 Ollama 的 qwen3-embedding:4b 做向量化、qwen2.5:14b 做答案生成与裁判，以减少模型差异。
2. 同一份语料、同一组问题：每个数据集的 50/40 道题，四家都跑同一份，golden 答案固定。
3. 统一指标：① 检索召回 recall@hit%（golden 文档是否进入 top-K）；② 回答正确性（LLM 裁判 0–5 分）；③ 延迟、索引耗时。

⚠️ 一条诚实声明：原计划用更强裁判模型 glm-4.7，但它在 Ollama /api/generate 下对结构化打分 prompt 返回空（推理 token 被吞），所以全程改用 qwen2.5:14b 兼任裁判。同族自评可能影响绝对分数，也可能影响相对排名；当前没有异族裁判或人工标注证明排名不受影响。

三、四个数据集：分别压哪一面

我们没有只用一个数据集（单数据集会掩盖平台在不同场景的差异），而是用了 4 个，每个压一个不同的能力面：

每个数据集都构建为「语料库 + 测试题（带 golden 答案与 golden 文档）」。原运行所述构建脚本当前未发布到本仓库，计划产物见文末。

四、结果一：TechQA（英文技术文本，baseline）

这是最"正常"的 RAG 任务：英文技术文档 + 自然语言问题。四家使用同一任务，但 FastGPT 是 top-1，其余三家是 top-5：

FastGPT 的 87.5% 是 top-1 口径（它的 /dataset/searchTest 端点实测恒返回 top-1，无论 limit=5/10），其余三家是 top-5。它记录的是首条命中表现，不能与另外三家的 top-5 召回率直接排序。

这一轮的关键观察：在这批文本任务上，四家记录值均接近 90%，但 FastGPT 的 top-1 与其余平台 top-5 不可直接等同。工程指标记录为：RAGFlow 建库最快（70s）、Dify 检索最快（中位 0.38s）但建库最慢（多阶段 pipeline ~22 分钟）、MaxKB 较均衡。

回答分都在 2.7–2.9，主要被裁判偏严 + ~10% 未命中题拉低。我们还用中转站 gpt-5.4 对 MaxKB 做了一次对照（检索沿用本地 embedding 不变）：召回 90% 不变、回答 2.9→2.92。这个单平台、单配置对照提示该轮瓶颈更可能在检索侧，但不足以证明 RAG 的一般性天花板或其他平台更换生成模型后的表现。

五、结果二：CUAD（文本型 PDF）

CUAD 是 510 份真实 SEC 商业合同 PDF（带文本层，但版式复杂、有表格和条款结构），取 50 份 + 50 题。

这一轮有个反直觉的结果：RAGFlow DeepDoc 在文本型 PDF 上反而最低（80%），Dify 最高（90%）。

原因是 CUAD 是电子申报的文本型 PDF（有文本层，不是扫描件）。DeepDoc 的强项是 OCR / 复杂版式 / 表格——遇到本身就有文本层的 PDF，这些强项用不上，差异就落在切片粒度和检索匹配上，而 RAGFlow 的合同切块对"找属性"类查询不如 Dify 顺手。DeepDoc 不是万能 PDF 利器，它的优势要换扫描件/复杂版式才体现（见第七节 DocVQA）。

另外一个重要坑：FastGPT 默认的 PDF 解析器 @llamaindex/liteparse（原生二进制）对这批真实 PDF 报 "invalid PDF format"，39/50 解析失败，重传稳定复现。FastGPT 内置了 pdfjs 兜底，但回退逻辑只在"native 加载失败"时触发、不覆盖"内容解析失败"——需要手动禁用 LiteParse native（改名 .node）才走 pdfjs。对要做复杂 PDF 的场景，这是个隐蔽坑：灌库看着成功，实则大半文档没切出 chunk。

六、结果三：CMRC2018（中文）

CMRC2018 是 SQuAD 式中文阅读理解，构建为 211 篇中文段落 + 40 道中文问。

在本次 CMRC2018 样本和配置下，四家记录值为 80–100%，qwen3-embedding:4b 在这批中文题上形成了有效召回。Dify 记录为 100%，RAGFlow 为 80%；由于 FastGPT 是 top-1、其他平台是 top-5，这些数值不构成严格的平台排名。

绝对召回高于 TechQA 轮（80–100% vs ~90%），可能与 CMRC 语料较小（211 篇）且每题答案落在单一段落有关。受 top-K 口径和同族裁判影响，本轮数值应视为运行快照，不应生成统一相对排名。

七、结果四：DocVQA（扫描/图像文档，DeepDoc 主场）

这是 CUAD 留下的悬案——到底 DeepDoc 强在哪？我们用 DocVQA（文档图像 + 视觉问答），把 50 份文档图像（无文本层，Pillow 包成 image-PDF）灌进四家。

这是本次运行中的镜像反转：在所测文本型 PDF 上 RAGFlow 记录值最低，但在所测扫描/图像样本上记录为 76%，另外三家为 0–10%。

在本次记录的版本、默认解析链路、配置和 DocVQA 样本下，只有 RAGFlow 的 DeepDoc OCR 把无文本层图像转成了可检索文本；FastGPT/MaxKB 形成 0 chunks，Dify 只留下图片占位符。这说明 DeepDoc 在这次扫描样本中提供了关键 OCR 能力，但不能外推为所有版本、插件、配置或复杂版式上的永久结论。

对企业的直接启示：如果包含历史纸质工艺记录、扫描说明书或传真，应把 OCR 能力单列为 POC 门槛，并用自己的样本重跑。本文只能确认当次测试中 RAGFlow 的默认链路有效，不能证明其他版本或外接 OCR 方案不可用。

八、跨数据集综合：一张总表看清谁适合什么

核心结论：

1. 在本次文本样本和配置下，四家均形成较高召回记录；FastGPT top-1 与其他 top-5 不可直接比较。
2. DeepDoc 的表现具有场景依赖性：本次文本型 PDF / 中文记录值不占优，扫描样本中 OCR 优势明显。
3. 是否选择 RAGFlow，应由自己的扫描/图像文档 POC 决定，不能把这次样本结论视为永久产品属性。

九、部署/资源/授权（作者运行记录）

部署踩坑（均为真实）：

• Dify：DB 服务全在 compose profile 里，必须 --profile postgresql --profile weaviate 才起库，否则 api 找不到 db 陷入 restart 循环；首启 DB 迁移期间 nginx/plugin_daemon 会 restart。
• RAGFlow：ES 镜像经镜像源曾断连卡死（手动 docker pull 续传解决）；登录密码需 RSA 加密（取容器内 public.pem）；v0.26 的 init_llm_factory() 被官方注释，导致厂商表空，API 自配模型受阻。
• FastGPT：服务多、token/key 配置密，需改 minio 端口避让。
• MaxKB：一条命令起，最顺。

纯内网状态尚不能独立验证。 作者记录为四个平台均在本机部署并共用本地 Ollama，但当前没有公开网络抓包、完整配置快照或外连日志，不足以证明运行期数据完全不出网。高保密场景仍需自行验证。

十、纯 API 自动化摩擦（对做 CI/CD、多知识库管理很关键）

这是本次评测最"痛"的部分，也是最有工程价值的发现。我们尝试用纯 API（不走 UI）完成「配模型 → 灌库 → 检索」全流程，四家的摩擦度差异巨大：

10.1 FastGPT 的三个坑（实测）

1. 登录反爬：preLogin GET 拿一次性 code + 密码 sha256 → loginByPassword。
2. 模型层最复杂：aiproxy（独立 Go 服务 + 自己的 postgres）+ FastGPT 的 mongo system_models + plugin daemon 三层。custom 模型要走 requestUrl 直连 Ollama 才能用（custom 模型能列出但 getSystemModelConfig 会拒）。
3. 建库狂报 514 的真凶：user token 必须放在 token: HTTP header，不能放 Authorization:——后者会被当成 apikey 走 authOpenApiKey 查库失败。这个坑卡了很久。

10.2 Dify 的连环坑（实测）

1. 密码是 base64 不是 RSA：源码注释明说"uses Base64 encoding for obfuscation, not cryptographic encryption"。密码里的 @ 字符会破坏 base64 解码 → "Invalid encrypted data"。
2. 所有请求强制 CSRF 双提交：cookie 里的 csrf_token + X-CSRF-Token header 必须同时带。
3. 插件市场 identifier 不可截断：marketplace 返回的 latest_package_identifier 是 88 字符（含完整 commit hash），截断会报 "plugin package not found"。
4. 新版移除了 console 的 create_by_text：改走 RAG pipeline 工作流。但 service_api（/v1，dataset API key 鉴权）保留了 classic 接口，用 create-by-text + API key 旁路跑通。
5. hit-testing 的 query 上限 250 字符，超长直接拒。

10.3 RAGFlow 的版本回归

api/db/init_data.py:144 的 init_llm_factory() 在 v0.26 被官方注释掉，llm_factories 表未种子化 → add_llm 报 "factory Ollama is not allowed"。需要手工导 conf/llm_factories.json 或走 UI。这是版本回归 bug，不是设计如此。

10.4 共享 Ollama 的一次并发超时记录

作者记录在一次 RAGFlow 并发解析 + 其他平台 embedding 时，POST /api/embed 持续 60 秒超时，重启 ollama serve 后恢复。当前没有 GPU 状态、Ollama 日志或重复运行证明这是死锁，也不能仅凭一次事件确定根因。对共享 Ollama 的生产环境，可以把限并发、超时、队列和监控作为预防措施，并用本地压测确认阈值。

十一、多维度加权评分

针对"高保密制造企业"的权重（私有化/检索/权限权重高），量纲 1–5（5 最佳）：

本次加权结果：MaxKB (4.08) > FastGPT (3.99) ≈ RAGFlow (3.96) > Dify (3.79)。由于 FastGPT 检索口径不同、裁判未经异族或人工校准，这只是当次权重下的决策草案，不是严格可比的综合排名。

注意：如果"文档解析/OCR"权重上调（企业有大量扫描件），RAGFlow 会上移；如果"编排/Agent"权重上调（做 25 个 Agent），Dify/FastGPT 会上移。

十二、分场景选型建议

1. 快速上线纯本地知识库问答（质量/FAE/工艺知识沉淀，最高保密）→ MaxKB：单容器、对 Ollama 开箱即用、中文好、实测召回 90%。自用 GPL 无碍。
2. 承载多 Agent 的统一底座（研发/良率/设备编排）→ Dify 或 FastGPT：Dify 编排/Agent/插件最强（但部署配置最重）；FastGPT 知识库+工作流均衡、学习曲线更平。建议 POC 二选一。
3. 文档解析要求极高 / 有扫描件（PDF datasheet、工艺曲线、扫描件）→ 优先把 RAGFlow 纳入 POC：本次记录中 DeepDoc/OCR 在扫描样本为 76%，其他默认链路为 0–10%。该结论绑定本次版本、配置和样本，仍需用企业文档验证。
4. 跨平台共享本地 Ollama：作者在一台 3090 上记录了四平台共用 LLM + embedding，也记录过一次并发超时。上线前应压测并配置限流、超时和监控，不应把单次事件直接定性为必然死锁。

十三、局限与诚实声明

• DocVQA/CUAD 是代理数据集，不是真实企业 datasheet。datasheet 多为带表格的 born-digital PDF——CUAD（文本合同）和 DocVQA（扫描表单）只是侧面逼近；绝对值和相对次序都可能随版本、配置和样本改变。真实选型应使用企业自己的 datasheet 做 POC。
• FastGPT 全程 top-1 口径（searchTest 限制），与另三家 top-5 不完全可比，已保守标注。
• 裁判模型单一（qwen2.5:14b 兼任，glm-4.7 在 Ollama 下无法完成结构化打分）。同族偏差可能影响分数和相对次序，尚无人工标注或异族裁判校准。
• 每个数据集只测了 40–50 题，样本量有限；它可以提供失败线索，不足以估计稳定的平台间差异。
• 部署、资源、授权、易用性、回答、检索和文档解析结论均来自作者运行记录；当前缺少可公开逐项审计的原始日志。

十四、可复现性状态与计划产物

当前等级为 R1：kb-benchmark/ 及下列脚本、数据快照和原始结果不在当前仓库。以下保留作者运行时记录的产物结构，不能当作已公开路径；升级清单见评测可复现性状态。

• 数据集构建：scripts/{build_benchmark,build_cuad,build_cmrc,build_docvqa}_benchmark.py（分别构建 TechQA/CUAD/CMRC/DocVQA 语料+题集）
• 灌库+检索：scripts/{bench_maxkb,bench_ragflow_poll,bench_fastgpt,bench_dify}.py + scripts/{cuad_retrieve,cmrc_bench,docvqa_bench}.py + scripts/{dify_helper,fastgpt_helper}.py
• 打分：scripts/score.py（统一召回 + 生成 + 裁判）
• 结果：results/{maxkb,ragflow,fastgpt,dify}.jsonl + {cuad,cmrc,docvqa}_*.jsonl + summary.json；若找回产物，需先区分 FastGPT top-1 与其他平台 top-5，不得默认同口径汇总。
• 证据：deployment_facts.md、config_findings.md、EVAL_FRAMEWORK.md、SUBAGENT_RUNBOOK.md

写在最后

这次运行记录最大的启示不是某家的分数，而是**"DeepDoc 最强"这类口碑依赖场景、版本和配置**：它在本次文本型 PDF 样本中记录值较低，在扫描样本中则体现出 OCR 优势。RAG 平台选型应使用自己的真实文档和统一口径重跑。

后续四个单独的篇章分别拆解 MaxKB / RAGFlow / FastGPT / Dify 的技术架构、实现原理、数据流与技术栈，便于深入理解它们为什么会表现出上述差异。