Appearance
Q67 · 开源 RAG 平台比如 RAGFlow，应该如何选型？
一家企业想做制度问答。员工问“现在上海出差的住宿上限是多少”，系统应从当前生效的差旅制度找到数字，并给出出处；若员工问到没有权限查看的人事薪酬附件，系统必须拒绝展示。团队看到 RAGFlow 的文档解析演示不错，又看到 Dify 能搭建知识库和工作流，便想知道该选谁。选型的起点是这两个真实问题，而不是项目主页的功能列表。
下文的“星河公司”、文件、问题、数值和验收线均为假设 POC，用来演示决策方法。假设旧制度写“上海住宿上限 500 元/晚”，自 2026 年 9 月 1 日生效的新版写“600 元/晚”；当前日期为 2026 年 9 月 26 日。系统答 600 元还不够，必须指向新版的相应条款，且不能把只有人事部可看的附件泄漏给普通员工。
先认清选型里会用到的词
**RAG（Retrieval-Augmented Generation，检索增强生成）**是“先从资料里找相关内容，再让模型据此回答”的做法。开源 RAG 平台通常把文件导入、解析、建立索引、检索、问答和管理界面组合起来；开源只表示可取得相应源码和许可条件，并不意味着部署、模型调用、运维免费，也不意味着所有商业使用方式都不受限制。
| 术语 | 初学者可以怎样理解 | 星河公司的对应物 |
|---|---|---|
| POC（概念验证） | 用小而真实的样本验证候选方案能否达到业务底线 | 用一批制度原件和固定问题跑三种方案 |
| 文档解析 | 把 PDF、扫描页或表格还原成可处理的文字及结构 | 从新版制度的表格中正确提取“上海 / 600 元/晚” |
| OCR（光学字符识别） | 把扫描图片里的字识别成文字 | 旧制度只有扫描版时识别数字和标题 |
| 切块 / chunk | 把解析后的长文拆成供检索的小段 | “上海住宿上限”条款成为可检索片段 |
| 索引 / 检索 | 建立便于查找的数据结构 / 按问题找片段 | 找到新版制度中的上海条款 |
| 召回 | 检索阶段把正确片段列入候选结果 | 正确条款出现在前几条结果中 |
| 引用 / citation | 回答指向支持它的原文位置 | 给出新版文件和条款，而非仅报数字 |
| ACL（访问控制列表） | 记录谁能读哪些资料的规则 | 普通员工不能读人事附件 |
| 元数据 | 附在文档或片段上的版本、部门、日期等信息 | 生效日=2026-09-01、部门=人事 |
| 延迟的 p95 | 100 次请求中约 95 次不超过的响应时间 | 大多数员工等答复的时间上界 |
| 总拥有成本 | 购买或使用之外，运行与维护的全部代价 | 机器、模型、解析、备份、升级和人力 |
“平台有权限功能”和“这一次员工问答已正确按原系统身份过滤每个可召回片段”是两件事。比如团队空间可见性、知识库管理权限、问答时按员工身份过滤资料，属于不同层次，都要逐一验证。
先把业务约束写成同一张试卷
POC 先准备相同的原始资料：新版和旧版制度各一份、带表格的 PDF、一页扫描件、公开的报销 FAQ、人事薪酬附件，共 20 份文件。这里的 20 只是示例规模。每份记录来源、版本、生效时间、部门、保密级别，并把正确答案及支持它的原文页码或段落由业务负责人确认。测试集可设计 24 个问题：8 个直接查条款、6 个跨表格或扫描页、6 个新旧版本冲突、4 个越权提问。前 20 个是“有权得到答案”的问题，后 4 个应拒绝披露。
对三个候选方案使用同一批文件、同一组问题、同一身份、同一模型和嵌入模型配置，并记录版本与参数。嵌入模型把文字转成用于相似度检索的数值表示；若更换它，检索结果也可能改变。若某个平台无法使用完全相同的模型或解析器，就在实验记录里标出差异，不能把差异简单归因于“平台本身”。要同时做检索测试与端到端问答：检索测试看正确原文有没有被找出，问答测试看模型是否依据它给出正确、有引用的答案。
图里三张工作台拿到的是同一份样本，右侧是一份共同试卷。图没有给谁打勾或宣布胜者；勾选项代表“必须检查的项目”。真正的测试还要覆盖版本、成本和恢复能力。
下表是本例团队事先约定的验收线，不是 RAGFlow、Dify 或行业标准的成绩。设线时应由业务、安全和运维人员共同确认，不应为了让某个候选过关而事后改题。
| 项目 | 本例验收方法 | 本例假设底线 |
|---|---|---|
| 解析正确性 | 人工对照扫描页与表格，检查数字、标题、行列关系 | 关键 20 处字段全部正确；错误可定位到原件 |
| 有权限问答 | 对 20 个有权问题核对答案和引用是否确实支持答案 | 至少 18 个答案及其引用都正确 |
| 越权隔离 | 普通员工身份问 4 个只在人事附件中的问题；同时检查检索结果与最终回答 | 4 个都不能暴露受限片段或内容 |
| 新旧版本 | 问“现在上限”并检查旧版是否被误用；再问历史日期 | 当前问题指向新版，历史问题按有效期处理 |
| 响应与导入 | 在约定机器、并发数和模型下重复测量 | 本例约定 p95 不超过 5 秒；导入时长另行记录 |
| 可恢复性 | 备份后模拟单节点故障并恢复 | 原件、索引、配置和权限可按演练步骤恢复 |
解析关键字段和越权隔离在本例是硬门槛；即使总分高，只要泄露受限内容便不能上线。其余项目可按业务需要权衡。24 道题只是早期筛选，不能据此宣称生产环境的准确率或性能。
候选方案怎样放在同一维度比较
RAGFlow 官方快速上手把创建数据集、选择切块方式、查看并修改解析后的片段、检索测试、建立问答应用串成一条路径；其当前文档也描述了团队成员、资源共享范围和资源操作权限。它适合进入“复杂文件解析与检索结果可检查”这一类 POC，但官方提供功能不等于我们的扫描制度一定解析正确，更不等于从原系统同步来的每位员工权限已自动映射。RAGFlow 快速上手 · RAGFlow 权限总览
Dify 是另一个值得对照的开源 AI 应用平台：官方项目介绍其工作流、RAG 管道、模型和工具支持，以及自托管选择。自托管版官方文档还说明了知识库的检索测试与工作流中的知识检索节点。它可作为“知识库与应用编排一起交付”的候选。具体文件解析效果、知识检索设置、应用权限和运维边界，仍需在选定版本做同一 POC。其官方许可是带附加条件的 Dify Open Source License，包括多租户服务及前端标识相关条件；计划对外提供多租户服务或改前端标识时，应在选型时逐条核对许可，而非只看“开源”二字。Dify 官方仓库 · 自托管版检索测试 · 知识检索节点 · Dify 官方许可
第三个候选可以是自建检索与问答流水线：团队自己选解析器、检索库、模型服务和前端接口。它可为已有身份系统、文档生命周期或特殊审计流程做精确整合，但文件同步、升级、监控、回滚与安全测试都要自己承担。这里“自建”是一种组织与工程方案，不是某个确定产品，所以不能给它一个统一的性能数字。
| 要比较的维度 | RAGFlow POC 要问 | Dify POC 要问 | 自建 POC 要问 |
|---|---|---|---|
| 文档进入系统 | 扫描页、表格、版本字段的解析和片段预览是否够用？ | 当前选定版本的知识处理路径能否保留所需结构？ | 解析器和人工修订流程谁维护？ |
| 检索与回答 | 目标条款是否被召回，引用能否追到原件？ | 同样模型与数据下，知识检索和工作流输出如何？ | 每一级检索、重排、生成如何观测？ |
| 权限 | 资源权限怎样与员工身份、原文权限相连？ | 知识库、应用与最终用户的权限边界怎样落地？ | ACL 如何在检索前后强制执行并测试？ |
| 运维与集成 | 依赖服务、备份、升级、API 接入谁负责？ | 自托管组件、应用发布、升级与许可谁负责？ | 每个服务的版本、故障恢复和监控谁负责？ |
| 成本 | 机器、解析与模型、存储、运维工时是多少？ | 平台部署、模型与插件/集成、许可核对工时是多少？ | 开发、值守、升级和长期维护是多少？ |
表中是待验证的问题，不是未经测试的产品评分。RAGFlow 当前快速上手列出 Docker 部署前置条件（x86 CPU 至少 4 核、内存至少 16 GB、磁盘至少 50 GB），并说明支持环境与镜像情况；这提醒团队把机器与依赖服务计入预算，不能把这些数字当成所有部署的实测占用。选型时要固定版本，核对发布说明与部署文档；夜间开发版、云托管版和自托管社区版也不能混在同一张比较表里。RAGFlow v0.27.2 快速上手：Prerequisites
从一个失败样本看出差距在哪里
假设 POC 中平台甲把新版 PDF 表格的“上海”这一行拆开，检索时只找到“600 元/晚”却丢了城市；模型答对数字也缺少可核对的依据。此时先看解析后的文本和片段：若行列关系已经错，调大模型或改提示词难以可靠补救，应尝试另一种解析/切块配置或修正源文件。若片段正确却排在候选之外，再查检索设置和版本过滤。若检索结果正确而回答说 500 元，则检查生成阶段是否混入旧版片段、是否按生效日期筛选。这个定位顺序避免“答案错了就换平台”的误判。
另一个失败更严重：普通员工的检索结果里出现人事附件，即使模型最后没有把薪酬数字写进回答，也已经越过资料边界。应先停用该对外入口，核对身份传递、知识库共享范围和检索过滤位置；不要只靠回答提示词写“请保密”。删除或修改原系统权限后，还要验证平台内同步和索引是否及时更新。RAGFlow 当前官方文档将团队成员身份、资源共享范围和操作权限分开描述，这正说明选型时要逐层走通实际员工账号，而非只用管理员账号试答。RAGFlow 团队与资源权限 · 资源操作权限
最后做一次总成本核对：文档 OCR 或视觉解析是否调用外部模型，嵌入和重排模型如何计费，索引与原件占多少存储，高峰查询需要几台机器，升级是否要重建索引，备份和权限审计由谁执行。这里的“重排”是把初次检索得到的候选片段重新排序。让财务和运维按同一份业务量假设估算月度成本与人力，再结合硬门槛作决定。若两种平台都满足底线，优先考虑团队能持续维护、能与现有身份和文档系统接通的方案；若都不满足，不必勉强在两者中二选一。
面试时可以这样回答
我会先把业务场景变成同一批文件和测试题，再比较 RAGFlow、Dify 和自建方案，不按功能数量或演示效果直接定胜负。比如企业制度问答，我会放入扫描表格、新旧版本和受限人事附件，先验解析后的片段，再验正确条款有没有被检索出来，最后验回答和引用；普通员工能否看到受限内容是硬门槛。三组实验尽量固定模型、数据、身份和环境，记录不一致之处。随后核对平台与原系统的权限映射、文档更新、部署依赖、备份恢复、许可和模型及运维总成本。RAGFlow 的解析可见性和检索测试、Dify 的知识库与工作流都值得试，但最终选实际 POC 达标且团队养得起的方案。
若追问“RAGFlow 官方演示能引用，为什么还要测”，回答是：引用功能存在与引用支持我们这份制度的正确条款不同，解析错误或旧版混入都可能让引用貌似可信。若追问“开源就可以免费商用吗”，回答是：要看具体许可和使用方式；运行、模型、存储与维护仍有成本，Dify 的附加许可条件尤其要在目标用法下核对。若追问“怎样避免候选方案测得不公平”，回答是固定数据、问题、模型、身份和环境，并保留每次解析、检索、回答及失败证据。
参考资料
- RAGFlow v0.27.2 官方快速上手：部署前置、数据集、切块预览、检索测试与问答流程。
- RAGFlow 官方权限总览及团队和资源权限：权限层次。
- Dify 官方仓库：产品定位、知识库/工作流与自托管。
- Dify 自托管版官方检索测试文档及知识检索节点文档：检索测试和应用编排路径。
- Dify Open Source License：附加许可条件的原文。