检索：关键词与语义
共享盘和 Wiki 依赖文件名、目录与关键词匹配，提问措辞要贴近原文；知识库把文档切成片段，用向量与关键词混合索引，口语提问也能被召回，再由模型组织答案。代价是索引要定期重建，旧片段不清理会与新版一起被召回。
输出：找文件与给答案
传统做法交付一份文档，读者自己翻到第几页；知识库交付带引用的回答，句末标出源文档与章节。这要求每段知识能独立成义，否则切片后语义残缺、答非所问。所以重排文档结构，比挑选模型更值得先做。
维护：管理员与知识主人
共享盘上传权限很宽，谁都能传，结果同名文件多版本并存。知识库要为每类知识指定负责人与复核人，写明制度改版、产品变更等更新触发条件，并把过期下线写进流程；没有负责人的库，三个月就会出现两个口径。
边界：权限与适用场景
知识库要求片段级权限标签，检索时先过滤再生成，避免模型把无权限内容拼进答案，涉及个人信息的内容还要脱敏留痕。但知识总量小、提问集中在几份固定文档时，共享盘加索引目录更省事；错误代价高的低频场景应先补专家复核。
适用与不适用
适合谁
- 客服、售后、交付等存在高频问答的岗位
- 制度与产品文档版本多、更新频繁的企业
- 跨部门查阅需求多、权限差异明显的组织
不适合谁
- 文档总量很少、提问集中在固定几份文件
- 没有内容负责人、也不打算设置复核人
典型场景
某装备企业的售后工程师遇到故障时，过去要在共享盘里按机型翻 PDF，常常翻到旧版手册。改造后技术部把手册按故障现象拆成问答片段，标注机型与版本；客服描述现象即可拿到带页码的回答，技术主管每周抽查被引用的片段是否对应最新版本。
可执行步骤
- 盘点文档格式、版本与持有部门，按使用频率排序，标出重复件与已废止文件
- 按条款或问答对重排长文档，让每段能独立成义，再确定入库的片段粒度
- 为每类知识指定负责人与复核人，写明更新触发条件与响应时限，并明确谁有权裁决冲突说法
- 为每个片段配置权限标签，检索时先过滤再生成，并开启访问日志与操作留痕
常见坑
- 把整本手册直接导入，切片后语义残缺，回答容易断章取义；应先按条款重排再入库，否则复核比人工查阅更慢。
- 只做向量检索不做关键词兜底，型号、编号类提问召回率低；应做混合检索并保留原文页码，让工程师能一眼核对。
- 权限沿用文件夹授权，模型把无权限内容拼进答案；应在片段级打标签并在召回阶段过滤，而不只是界面隐藏。
自检与验收清单
- 每份入库文档是否有明确负责人与生效版本号
- 回答是否附带源文档名称、具体章节与页码定位
- 检索是否同时覆盖语义召回与型号、编号等精确词
- 无权限片段是否在召回前被过滤，且访问留有日志
常见问题
知识库是不是把文件传到系统里？
不是。上传只完成存储，能不能用取决于切片是否成义、权限是否打标、检索是否覆盖精确词，以及有没有人负责更新。只做上传的系统通常几周内就退化成另一个共享盘，投入也难有回报。
和原来的 Wiki 能共存吗？
可以。常见做法是 Wiki 继续作为制度原文的权威版本，知识库作为检索与问答层，定期同步并保留链接。关键是明确哪一份是唯一事实源，避免两边各自修改后出现口径冲突，让一线反复确认。
小团队需要专门的平台吗？
文档量在几十份以内、提问集中在少数文件时，先做目录索引与责任分工更划算；等提问分散到多个岗位、更新频率上来，再考虑上系统，避免为低频需求长期维护索引与权限体系。