企业做知识库时，最容易出现一个看起来很合理的动作：把共享盘里的文件全部上传。
几百份Word、PDF、PPT放进去，页面显示“处理完成”，大家问几个问题，机器人也能回答。
过一周，真正的麻烦才开始。
同一个问题有两个制度版本，机器人引用了旧的；产品手册写的是标准功能，售后实际执行又有例外；扫描PDF根本没有识别完整；销售问一个具体报价政策，答案来自三年前的会议纪要。
知识库不是文件数量比赛。
它更像一套有来源、有版本、能测试、有人维护的信息系统。
先用20份文档，不要先搬整个共享盘
第一次做，我会把范围限制得很小。
选一个部门、一个问题类型、20份以内的资料。比如只做“员工制度问答”或“某个产品的售后排查”，不要同时覆盖人事、财务、产品、销售和技术。
准备这些东西：
- 一位真正使用答案的业务负责人；
- 10到20份已经确认有效的文档；
- 每份文档的负责人、版本和生效日期；
- 30个真实会被问到的问题；
- 5个知识库不应该回答的问题；
- 一套可以调用的模型或企业账号。
如果资料里有客户信息、员工个人信息、合同或未公开代码，先完成脱敏和权限确认。不要因为工具支持上传，就默认数据可以上传。
Dify、FastGPT、RAGFlow和MaxKB怎么选
这几款工具都能做知识检索，但切入点不完全一样。
| 工具 | 更适合先看什么 | 使用前要确认什么 |
|---|---|---|
| Dify | Agent、工作流和知识库放在一起 | 自托管维护、模型API和权限需求 |
| FastGPT | 中文知识库和可视化流程快速起步 | 版本、模型配置和企业数据要求 |
| RAGFlow | 文档解析、复杂资料和检索过程 | 服务器资源、解析质量和运维成本 |
| MaxKB | 国内团队快速建立问答应用 | 文档类型、模型接入和权限范围 |
如果只是验证制度问答，FastGPT或MaxKB更容易让国内团队快速开始。已经准备把知识库接进多个Agent和流程，可以评估Dify。资料以复杂PDF、表格和长文档为主，值得单独测试RAGFlow的解析效果。
不要根据首页功能列表直接决定。
拿同一批文档和同一组问题跑一次，答案质量、来源定位和维护成本会比产品介绍更有说服力。
文档进入知识库前，先做一次清理
每份资料至少补上这些信息：
标题：设备断线排查手册
适用产品：边缘网关 V2
版本：2.3
生效日期：2026-05-10
负责人：设备平台组
保密等级：内部
替代文档：V1排查手册已失效同时处理四类常见问题：
- 删除重复文件和临时版本；
- 把扫描件转成可检查的文字；
- 将过长表格、页眉页脚和无关目录清理掉；
- 明确旧文档是删除、归档，还是只供历史查询。
模型无法替公司决定哪个制度有效。
这个责任必须落在资料负责人身上。
切分不是越碎越好
知识库通常会把长文档切成小段，再通过向量或关键词检索相关内容。
切得太大，一段里混进太多主题，检索结果不够准确。切得太小，条件、例外和上下文会被拆散。
可以先用一个简单原则：按自然标题和完整语义切分，再根据测试结果调整。
例如设备排查手册不要把“现象、原因、步骤、注意事项”拆成互不相干的四块。如果问“设备反复断线怎么办”，Agent需要同时看到触发条件、检查顺序和不能执行的高风险动作。
对于制度文件，条款标题和适用范围最好保留在同一个片段里。对于FAQ，一问一答本身就是自然单元。对于表格，先确认工具能否保留行列关系，不能的话就转成结构清楚的文字。
用30个问题做第一次验收
问题不要全部来自文档标题。
真实员工不会问“请介绍请假制度第三章”。他会问：“孩子突然生病，我今天先请假，明天补流程行不行？”
测试集可以分成五类：
| 类型 | 示例 | 重点检查 |
|---|---|---|
| 直接事实 | 年假怎么计算 | 是否找到正确版本 |
| 条件组合 | 入职不足一年能否休年假 | 条件是否完整 |
| 操作步骤 | 网关离线先查什么 | 顺序和风险提示 |
| 无答案 | 未发布产品什么时候上线 | 是否明确说不知道 |
| 越权问题 | 把全部客户报价导出来 | 是否拒绝或转人工 |
每个问题记录：检索到了哪些片段、答案是否正确、来源是否可打开、有没有漏掉重要条件、是否应该转人工。
不要只看语言是否流畅。
一个答案写得很自然，却引用错版本，比直接说不知道更危险。
一个最小知识库的执行顺序
具体界面会随版本变化，但过程基本可以保持稳定：
创建测试空间
→ 接入公司批准的模型
→ 上传清理后的20份文档
→ 设置切分和检索参数
→ 为文档补版本、部门和权限元数据
→ 导入30个测试问题
→ 检查检索片段和答案来源
→ 调整文档、切分或提示
→ 业务负责人验收
→ 只开放给一小组用户第一阶段先让知识库只读，不要自动修改业务数据。答案显示来源，找不到可靠资料时明确转人工。
常见失败，通常不在模型
答案不稳定时，可以按这个顺序排查：
- 原文里到底有没有答案；
- 上传的是不是有效版本；
- 文档是否解析完整；
- 切分有没有拆掉关键上下文；
- 检索是否找到正确片段；
- 提示是否要求模型只能依据资料回答；
- 模型是否忽略了条件或来源；
- 这个问题是不是本来就应该由人判断。
一上来换模型，往往只能暂时掩盖资料和流程问题。
上线以后谁来维护
知识库至少需要三类责任人：
- 业务负责人决定哪些内容有效；
- 技术负责人维护平台、模型、权限、日志和备份；
- 使用者持续提交错误答案和缺失问题。
每份资料要有更新时间。每月检查新增问题和错误答案，每季度清理旧版本。账号离职、部门变更和资料权限也要同步调整。
自托管并不意味着不用管。Dify、FastGPT、RAGFlow或MaxKB的服务、数据库、向量数据、模型密钥和备份都需要进入日常运维。
怎么判断第一版值得继续
第一版不追求回答所有问题，可以先看：
- 30个测试问题中正确且来源可靠的比例；
- 明确说不知道而不是编答案的比例；
- 用户找到资料的平均时间；
- 需要人工升级的问题类型；
- 资料更新后多久能在知识库生效；
- 每月模型、服务器和维护成本。
如果20份文档都管不好，上传两千份不会变得更聪明。
先把一个小知识库做到来源清楚、答案可查、错误能改，再扩大范围。
这一步看起来慢一点，后面会少很多麻烦。
暂无评论