技术团队该怎么选？深入评测多款开源知识库 AI 框架的技术底座与并发表现

上个月我带团队做内部知识库改造，把市面上最主流的四款开源 RAG 框架拉出来完整跑了一遍。这四款框架分别是 Dify、FastGPT、RAGFlow 和 MaxKB。

很多人选型只看 GitHub 上的 Star 数量或者前端界面好不好看。但是把项目真放到生产环境给几百号员工用的时候，真正决定系统会不会崩溃的，是底层的存储架构、文档解析能力，以及高并发请求下的响应延迟。

为了拿到真实数据，我们在测试环境准备了一台 32 核 CPU、64GB 内存、配备单张 NVIDIA A10（24GB 显存）的独立物理机，测试文档统一使用一份 52 页包含复杂嵌套表格、单双栏混排和扫描印章的财务审计报告。

四款框架的技术底座拆解

选型第一步，必须看它们的技术栈。技术栈决定了后续二次开发的门槛和运维成本。

Dify 的后端核心使用 Python 开发，Web 框架采用 Flask，异步任务依赖 Celery 和 Redis。关系型数据库使用 PostgreSQL，向量数据库支持插件化接入，比如 Qdrant、Weaviate、Milvus 和 pgvector。它的界面交互很流畅，工作流编排功能很全。但是由于 Python 的 GIL（全局解释器锁）限制以及 Celery 任务调度机制，它的默认并发吞吐并不高。

FastGPT 的架构完全不同。它的核心代码使用 TypeScript 编写，后端基于 Node.js 与 Next.js API Routes 构建。它的主数据库采用 MongoDB，专门存储配置、对话记录与切片数据；向量检索则主要依靠 PostgreSQL 的 pgvector 插件。Node.js 的单线程异步非阻塞 I/O 在处理大量流式（SSE）长连接时非常省资源，内存占用远比 Python 框架低。

RAGFlow 的核心定位是深度文档理解。它的后端同样使用 Python，但底层检索没有使用通用的开源向量库，而是深度整合了自研的 Infinity 检索引擎，同时也支持 Elasticsearch。它最大的特点是内置了名为 DeepDoc 的视觉多模态解析模块，包含 OCR、表格结构还原和版面分析模型。

MaxKB 属于轻量派，后端基于 Python 的 Django 框架，前端使用 Vue.js，向量与关系数据统一放在 PostgreSQL + pgvector 里面。它的系统组件最少，部署最快，整个架构没有复杂的中间件。

真实文档解析实测：表格与多格式处理

知识库好不好用，七成取决于入库切分做得准不准。如果切出来的文本块把表格列弄丢了，后面选什么大模型都答不对。

我们把 52 页带复杂资产负债表的 PDF 丢进四个系统：

1.RAGFlow 表现最准。它的 DeepDoc 模块会先对页面做版面分割，把表格转成 HTML 格式保留行和列的关系。我们在检索“2023年第三季度固定资产折旧金额”时，它能精确召回完整的表格单元格。但是它的 CPU 和 GPU 资源消耗极大。在纯 CPU 模式下，解析这篇 52 页的文档花掉了整整 142 秒；挂载 A10 GPU 后，耗时缩短到 28 秒。

2.Dify 的入库速度很快，4 秒内完成分块。但是它把表格里的跨行和跨列全部打平成了无序的纯文本，单元格之间的对应关系完全错位，导致后续大模型给出的数字对不上号。

3.FastGPT 对复杂排版 PDF 的处理比较吃力。它更适合处理结构规整的 Markdown、TXT 或者通过手动导入 QA 问答对。如果直接喂杂乱的 PDF，切片召回的噪音较多。

4.MaxKB 切分速度最快，同样在 3 秒左右处理完毕，但分块粒度调节选项最少，不支持表格的重构。

关键结论：如果你的业务文档里包含大量财报、合同扫描件、跨页表格，必须优先考虑 RAGFlow 的解析能力；如果是规范的制度文档、Markdown 技术文档，Dify 和 FastGPT 的分块方式就已经足够。

并发性能与吞吐压测

这是很多团队最容易踩坑的地方。Demo 阶段一两个人测着很顺畅，上线后几十个客服同时提问，服务立刻卡死。

我们使用 Locust 编写测试脚本，模拟并发用户发送知识库检索与对话请求。模型端统一调用内网部署的开源模型（不计入公网网络抖动），向量检索统一取 Top-5 切片。我们分别测试了 20、50、100 和 200 并发下的表现：

数据说明了几个技术事实：

第一，FastGPT 的网络并发处理能力最强。在 100 并发下，它的 QPS 达到 78.6，P99 延迟保持在 2 秒以内。这得益于 Node.js 处理 I/O 密集型任务的高效。因为 RAG 的核心是等待大模型吐字和等待数据库返回向量，后端主要承担流式数据转发。FastGPT 在这块的资源浪费最少。

第二，Dify 在高并发下需要做深度调优。Dify 默认 Docker 镜像配置的 Gunicorn Worker 数量较小。并发达到 100 时，大量请求开始在队列中等待，甚至直接返回 504 网关超时错误。如果不改配置文件，直接拿默认参数上生产，很容易出现服务假死。

第三，RAGFlow 的 Infinity 引擎单次检索极快。在单纯的向量检索环节，Infinity 的毫秒级响应表现优异。但在整套 API 链路上，由于前端到后端再到解析引擎的多层 Python RPC 调用，整体延迟被拉高。

生产落地步骤与避坑指引

如果你的团队准备动手搭建，按照以下顺序进行可以避免返工：

第一步：先做文档特征分类，不要盲目定框架。

先收集业务团队最常用的 100 份文档。

1.如果扫描件和复杂表格占比超过 40%，直接选 RAGFlow。

2.如果团队需要复杂的业务判断流（比如根据不同部门路由到不同知识库、调用外部 ERP 接口），选 Dify。

3.如果主要做内部客服机器人，追求高并发响应和低服务器成本，选 FastGPT。

第二步：拆分基础组件，严禁全量容器单机部署。

官方提供的 `docker-compose.yaml` 文件大多是为了本地演示设计的，把 Web、数据库、缓存全部打包在同一台机器上。

1.必须把向量数据库独立部署。如果使用 PostgreSQL + pgvector，请单独分配一台至少 16 核、32GB 内存的服务器，并在配置文件中将 `shared_buffers` 调大到物理内存的 25%，把 `work_mem` 从默认的 4MB 调整到 64MB。

2.单独配置 Redis。将缓存和任务队列解耦，避免队列爆满影响 API 鉴权信息读取。

第三步：调整 Web 网关参数，防止长连接中断。

知识库问答是基于 Server-Sent Events (SSE) 的流式传输，一个回答可能持续 10 秒到 30 秒。

1.使用 Nginx 作为反向代理时，必须显式设置 `proxy_buffering off;`，关闭缓冲区。如果不关，Nginx 会等大模型全部生成完才一次性吐给前端，前端看起来就是卡住不动。

2.把 `proxy_read_timeout` 和 `proxy_send_timeout` 至少提高到 300 秒，避免复杂检索时网关主动切断长连接。

第四步：调整 Celery 与进程参数（针对 Dify）。

如果选了 Dify：

1.打开 `docker-compose.yaml`，修改 API 容器的启动命令，把 Gunicorn 的 `-w`（Worker 数量）从默认值修改为 `2 * CPU核心数 + 1`。

2.调大 Celery Worker 的并发执行数 `–concurrency`，防止大量文件同时上传入库时，后台任务完全卡死。

总结选型建议

•如果团队懂 Node.js，文档以文字和常见排版为主，追求高并发、低硬件开销：选 FastGPT。

•如果团队懂 Python，需要非常强大的可视化工作流搭建能力，希望统一管理各种大模型 API：选 Dify。

•如果团队最头疼的问题是 PDF 表格解析混乱，手里有 GPU 计算卡，可以接受较慢的入库速度换取高检索准确率：选 RAGFlow。

•如果运维人员极少，只需要做一个简单的公司内部规章问答，硬件预算紧张：选 MaxKB。