公司文档散在网盘、群聊、邮件和几个人的电脑里，谁想问点事都得靠找人。想做成「直接问一句话就有答案」的知识库，卡点通常不是选哪个工具，而是语料本身没理清楚、没人定更新规矩。这篇给一条从盘点到上线的落地路径，以及选型时该问自己的几个问题。
公司文档散在网盘、群聊、邮件和几个人的电脑里，谁想问点事都得先找人。想做成「直接问一句话就有答案」的知识库，卡住大多数团队的其实不是选哪个工具，而是语料本身没理清楚、更新没人管。这篇按一条从盘点到上线的路径讲，顺带把选型时该问自己的几个问题摆出来。
下面按七个环节走：先判断值不值得做，再盘点语料、清洗切分、标注权限，然后选型、试点、定更新规矩。每一节都给能直接动手的动作和判断标准，你可以对着自己团队的情况挑着用。
先判断这件事值不值得做
知识库不是万能药。收益最大的场景是：高频问题集中在少数几类文档上，比如制度、流程、产品参数、售后口径。反过来，一次性项目资料、常年没人问的归档文件、需要当场拍板的模糊问题，先不要往里塞。
- 先统计一个月内被重复问到的前二十个问题，数得出来再做；数不出来说明痛点还没到要建库的程度
- 把「谁问、问什么、答案从哪来」三列写成一页纸，作为后面验收的基准
- 问答量太少、问题发散、答案常需要现场判断的岗位，知识库只能当检索入口，不能当决策依据
- 问题集中在几个人身上、换个人就断档的环节，优先级最高，这类最值得先做
语料盘点：先知道手里有什么
动手之前先做一次清点。按来源分类：制度文件、产品资料、合同模板、客服记录、会议纪要、培训材料，逐类标出负责人和更新频率。这一步花的时间通常比想象中长，但省不掉。
| 分类 | 责任人 | 更新周期 | 是否入库 |
|---|---|---|---|
| 制度文件 | HR 或行政 | 改版时更新 | 是 |
| 产品资料 | 产品经理 | 版本发布时 | 是，需去旧版本 |
| 客服记录 | 客服主管 | 持续 | 筛选后入库 |
| 会议纪要 | 记录人 | 不定期 | 多数只做检索 |
| 合同与报价 | 法务或销售 | 按项目 | 脱敏后入库或干脆不入 |
同一件事往往有三四个版本。先定「哪一版算数」，其余标记为历史归档，否则模型会把旧口径也答出来，还会答得很自信。涉及客户信息、报价、未公开方案的文档，要么脱敏要么不进库，边界先划清再动手。
清洗与切分：这一步决定答得准不准
扫描件和图片型 PDF 先做文字提取，提取质量差的宁可人工校对，别把糊掉的识别结果直接喂进去。按语义切分而不是按页切：一个制度条款、一条产品参数、一段操作步骤尽量切在一个块里。跨块拼接最容易答得断章取义。
- 抽取文字把各类文档统一转成可检索文本，扫描件先 OCR，识别结果抽查几页，错误率高的回头人工过一遍。
- 按语义切块以条款、参数条目、操作步骤为单位切，不要机械按字数切；验证方式是随机抽十块，看每块单独读是否讲完整了一件事。
- 表格单独处理保留表头和单位，别直接拍平成一行文字，行列对应关系丢了问答就会答错数。
- 去重去噪页眉页脚、水印、修订记录、重复的免责声明清掉，它们会稀释检索命中，让该出现的块排不到前面。
标注与权限：让答案能溯源
每块内容至少带上来源文档、章节、生效日期、责任人四个字段。回答时能指回原文，用户才敢信。只给一句话没有出处的答案，多数人第一次用完之后就不敢再用第二次。
- 来源文档
- 回答时附上原文位置，用户能自己核对
- 生效日期
- 判断这条还作不作数，旧口径一眼可见
- 责任人
- 答错了知道找谁确认和修改
- 权限标签
- 按部门或角色控制可见范围，薪酬、法务、未发布产品这类内容要分开
还要区分「事实型」和「口径型」内容：产品参数、办公时间这类事实可以直接答；涉及承诺、赔偿、对外说法这类口径型内容，最好附上原文链接让人自己确认。标注不用一次做全，先覆盖被问得最多的那几类，剩下的边用边补。
选型对照：四种做法怎么挑
选型之前先明确三件事：文档量级、是否允许内容出内网、有没有开发资源。这三条基本就决定了能选哪条路。
| 做法 | 适合谁 | 要问清什么 |
|---|---|---|
| 现成 SaaS 知识库 | 文档量不大、不介意内容出内网 | 数据存放位置、导出方式、停用后数据怎么处置 |
| 通用大模型加自建检索 | 有开发资源、要接内部系统和权限 | 切分、检索、更新的活都得自己扛 |
| 办公套件自带问答 | 已在用某套办公生态、需求轻量 | 能力边界受限于该生态，跨系统资料往往覆盖不到 |
| 私有化部署 | 数据不能出内网 | 先评估文档量和并发，别为了合规硬上大集群 |
不管选哪种，先拿同一批二十个真实问题去试，看三件事：答对比例、能不能溯源、更新一份文档要多久。价格和具体规格到站内价格追踪页核对当时的数字，别用几个月前的印象做预算。想横向比较各类工具，可以去工具目录按类别筛一遍。/price-watch 和 /tools 里都有对应入口。
小范围试点到全量上线
选一个部门、一批文档、一群愿意反馈的人先跑两到四周，别一上来就全公司开放。试点期间最重要的不是把功能试全，而是把「答错的时候怎么归因」这个流程跑顺。
- 验收看三件事：常见问题答对比例、用户是否愿意继续用、答错时能不能一眼看出错在哪
- 收集答不准的问题，归因是语料缺失、切分不当还是检索没命中，分别处理，不要一律怪模型
- 全量前把入口固定下来：放在哪个系统、叫什么名字、出问题找谁，用一个渠道收反馈
- 试点结束做一次复盘，把答对率低的那几类文档列出来，要么补内容要么明确不纳入范围
如果试点期间用户问得最多的还是「你帮我查一下」，说明入口没被记住或者答案不够可信，先把这两件事解决再谈扩大范围。
上线之后：更新规矩比工具重要
知识库最大的风险不是答不出，而是答了旧口径还显得很确定。上线那天起，更新规矩就该定下来，不然三个月后它就是个更会说谎的旧文档集合。
- 定触发条件制度改版、产品参数变动、责任人换人，触发即更新，别等季度大扫除。把触发条件和责任人写进那份语料清单。
- 设库主角色指定一个人负责收更新、处理答错反馈、每季度抽查一批问答质量，这个角色要有时间预算，不能只是挂名。
- 留变更记录什么时候换了哪份文档、为什么换，出问题时能回溯是哪一版导致的。
- 设下线机制过期文档及时移出或标记失效；如果一个季度没人引用过的内容，也可以考虑归档。
判断这套规矩有没有在跑，看两个信号：一是最近一次文档更新到进库隔了多久，二是用户反馈的答错问题有没有闭环。到 /guides 里翻翻同类的落地经验，能少踩几个坑。
下一步先去做那件最不起眼但最要紧的事：把一个月内被重复问到的前二十个问题列出来。列完你就知道该先整理哪几类文档，也能拿去 /tools/speed-test 这类站内工具做横向测试时有统一的考题。→常见问题
我们文档特别乱，是不是得先全部整理完才能开始？
不用。先挑被问得最多的那一类文档做完整流程，跑通之后再按同样方法铺开。全部整理一遍往往拖几个月，期间一点收益都没有，而且整理完发现需求变了还得返工。
知识库和直接上传文档让模型读有什么区别？
直接上传适合单次、少量的问读；知识库解决的是多人反复问、内容持续更新、答案要能溯源这几件事。文档一多、一改版，靠人工上传就会失控，这时候才需要建库。
答不准的时候，是换模型还是换工具？
先别换。多数答不准出在语料层面：切分跨了段落、存在多个版本、检索没命中。按这个顺序查：问题在库里有没有对应原文、原文有没有被正确切分、检索有没有召回；三项都正常再考虑换模型或加重排。
内部资料放进知识库，数据安全怎么把控？
先把「能进、脱敏后能进、不能进」三类划清楚，薪酬、客户名单、未公开合同通常属于第三类。选型时问清数据存放位置、是否用于训练、停用后怎么删除，这三条比功能列表更重要。
上线之后没人用怎么办？
多数是入口太深或者答得不准。先把入口放到大家本来就在用的系统里，再拿被问最多的那批问题反复调到能答对。没人用的时候先看访问数据，别急着加功能。
