[企业AI落地] 用 RAGFlow 给公司制度和合同资料做可溯源问答，先跑通一个小型内网知识库

很多公司做内部知识库问答时，真正卡住的不是能不能接上大模型，而是员工问完之后不敢用答案：制度出处在哪里，合同条款来自哪一版，SOP 步骤有没有被模型编错，都说不清楚。

如果只是做一个能聊天的机器人，门槛并不高；但如果要让它回答制度、合同、SOP 这类内部资料，就必须把“答案能不能追溯到原文”作为第一版验收目标。

这篇从一个小型试点开始：用开源 RAGFlow 搭一个公司制度和合同资料问答库，先跑通文档导入、问题测试、引用检查和人工复核这几个环节。

这不是要一次性建设完整企业知识中台，而是先做一个可验证的小闭环：选一类资料，部署一个工具，导入一批文档，准备一组测试问题，检查答案是否能引用原文，再决定是否扩大范围。

为什么这类场景适合先用 RAGFlow 试一版

RAGFlow 的定位是开源 RAG 引擎，重点不只是“把文档放进向量库”，而是围绕复杂文档解析、知识抽取、检索增强和引用依据来做问答。

这正好适合企业内部常见的资料场景。

比如：

如果企业只是想做“聊天机器人”，很多工具都能做；但如果目标是“回答必须能追溯到原文”，RAGFlow 这种强调文档理解和引用依据的工具更值得单独试一版。

先别全量导入，第一版只选一个小场景

我建议第一版不要把所有制度、合同和项目资料都扔进去。范围越大，越难判断问题到底出在文档质量、切分方式、模型能力还是检索配置。

更稳的第一版可以这样选：

如果团队第一次做，我更建议从“员工制度问答”或“脱敏合同模板查询”开始。它们的业务边界清楚，问题容易设计，答案也更容易人工判断对错。

一个小型内网知识库的最小部署形态

第一版不需要把它做成复杂系统。可以先按这几层准备：

这里最重要的不是“部署命令写得多漂亮”，而是不要跳过验收层。很多内部知识库失败，不是因为服务没跑起来，而是因为没人定义“什么叫回答可用”。

文档准备比部署更重要

RAGFlow 能处理复杂文档，但这不意味着文档可以完全不整理。

第一版资料至少要做这几件事：

1. 删除明显过期或废弃的文件。
2. 文件名加上版本和日期，例如“员工报销制度_2025版”。
3. 合同、客户资料先做脱敏，不要把真实客户名称、金额、账号、个人信息直接放进测试库。
4. 同一类文档不要混入太多历史版本，除非你专门要测试版本差异。
5. 对扫描版 PDF 先确认 OCR 效果，否则后面问答不准，很可能不是 RAGFlow 的问题，而是原文根本没被正确识别。

我更推荐先建一个测试目录：

有了这个目录，后面不管换 RAGFlow 配置、换模型，还是调整切分方式，都能复用同一套测试材料。

第一版测试问题要怎么设计

不要只问“公司的报销制度是什么”这种大问题。大问题容易得到泛泛答案，无法判断系统是否真的理解了文档。

更好的问题应该覆盖几类：

如果系统只能答事实查找，不能处理条件判断和引用追溯，那么它还不适合作为企业内部正式知识库。最多只能算资料检索助手。

验收时重点看四件事

我会把第一版验收分成四个维度。

第一，答案是否命中原文。

不是看回答像不像人话，而是看它有没有抓到原文里的关键条款、数字、条件和例外。

第二，引用是否可追溯。

如果回答说“可以报销”，但点不开原文依据，或者依据跳到了不相关段落，这个回答就不能算通过。

第三，是否承认不知道。

企业知识库不能为了显得聪明而瞎编。测试题里应该故意放几条文档没有覆盖的问题，看系统是否会提示“当前资料中没有找到明确依据”。

第四，错误是否可复盘。

如果答错了，要能判断原因：

这张表比“准确率多少”更实用，因为它能指导下一轮怎么改。

RAGFlow 和 Dify 的定位不要混在一起

这个场景里，我会把 RAGFlow 和 Dify 分开看。

RAGFlow 更适合先验证文档解析、知识库构建、检索和引用依据。

Dify 更适合把已经验证过的问答能力接成业务工作流，比如审批助手、客服助手、投标材料整理、合同条款初筛。

如果一开始就用 Dify 搭完整工作流，但文档解析和引用依据还没验收，后面很容易出现一个问题：流程看起来跑通了，但回答质量不可靠。

所以更稳的顺序是：

1. 用 RAGFlow 先把一类文档的问答和引用跑稳。
2. 用固定问题集做验收。
3. 确认资料质量和召回效果后，再考虑接到 Dify、Open WebUI 或内部机器人。
4. 接入业务入口前，再补权限、日志和人工复核。

这样文章就不是泛泛讲“知识库治理”，而是给了一个能实际试跑的落地路线。

小团队可以按这套步骤试运行

如果是一个 5 到 20 人的小团队，可以先按下面的节奏跑一周。

第一天，选定资料范围。

只选一种资料，比如员工制度或脱敏合同模板。不要全公司资料一起上。

第二天，整理测试文档。

统一文件名、删除过期版本、做脱敏、检查 PDF 是否能被正常读取。

第三天，部署 RAGFlow。

按官方文档用 Docker 方式先跑起来，先不追求高可用，也不接公司统一入口。

第四天，导入文档并建立知识库。

导入后先看解析结果，不要急着问问题。尤其要检查表格、页眉页脚、编号条款有没有被正确处理。

第五天，跑测试问题集。

至少准备 20 个问题，每个问题都记录：答案是否正确、是否有依据、依据是否对应原文、是否需要人工复核。

第六天，整理错误样例。

把错误按“文档问题、切分问题、召回问题、模型回答问题、问题设计问题”分类。

第七天，决定是否扩大范围。

如果 20 个问题里只有 10 个勉强可用，就不要急着接入业务；如果大部分问题能准确引用原文，再考虑开放给小范围用户。

一份试运行记录表很有必要

我建议每次测试都留下这样的记录：

这张表对企业落地很重要。因为它能让团队知道：现在的问题到底是工具问题、资料问题，还是业务规则本来就没写清楚。

上线试点时先选三类用户

第一版不要直接开放给全员。更稳的做法是先选三类用户参与试运行。

第一类是行政、HR 或制度负责人。他们负责判断制度问答是不是准确，尤其是报销、请假、入职、转正这类高频问题。

第二类是销售、法务或项目负责人。他们负责测试合同条款、交付范围、付款节点这类问题，重点看系统有没有把不同版本、不同客户的材料混在一起。

第三类是实施或技术负责人。他们负责测试 SOP、故障处理和交付材料，重点看答案是否能定位到具体步骤，而不是只给一段泛泛建议。

这三类用户每人准备 5 到 10 个真实问题，比让所有人随便问更有效。试点阶段要收集的是错误样例和不可用场景，不是追求一开始就显得很智能。

哪些情况不适合第一版就上 RAGFlow

不是所有团队都适合马上部署。

如果你的资料大量是扫描件，而且 OCR 质量很差，应该先处理文档质量。

如果资料里有大量客户隐私、报价底线、合同金额，而团队还没有脱敏流程，应该先做数据边界。

如果公司内部还没想清楚谁负责更新文档，也不要直接全量上线。

如果只是想做一个“能聊天”的演示，也许用更轻的工具就够了，不一定要先搭 RAGFlow。

RAGFlow 更适合的问题是：资料比较复杂、需要引用依据、需要验证问答质量、未来可能继续接业务流程。

这篇文章真正想解决的问题

企业 AI 落地不应该总停在“权限、流程、治理”这些大词上。

对于内部知识库问答，一个更实际的起点是：

选一个开源产品，选一类资料，准备一套测试问题，跑一轮可追溯问答，然后用错误样例决定下一步。

RAGFlow 可以作为这个试点工具。它不一定是所有企业的最终方案，但它能帮助团队把“知识库是否真的可用”这件事验证清楚。

如果这一版跑通了，后面再讨论权限、日志、接入 Dify、接入企业微信或内部 Agent，才不是空谈。