角色一：内容负责人
每类知识要有一个能对内容正确性负责的人，通常来自业务部门而非 IT，职责是判断哪一版是现行标准、哪些已废止、新问题由谁补写。缺少这一角色时，知识库会退化成多人上传、无人裁决的文档堆，检索越好，错误传播越快。
角色二：知识运营
运营岗负责把长文档拆成可检索片段、统一术语、补写问答对、维护标签与同义词表。这项工作介于编辑与产品之间，需要懂业务的提问方式。可由培训或质量岗兼任，但要给出固定工时，否则永远排在日常事务之后。
角色三：复核与安全
高风险回答需要业务专家抽检，抽检比例与频次写进流程；IT 侧负责账号、权限、日志与部署环境。两类角色不必专职，但要有明确响应时限，否则内容更新卡在审批环节，一线逐渐绕开系统直接问人，系统就成了摆设。
数据：单一事实源
文档需为可提取文本的格式，扫描件先识别校对；同一主题只保留一份权威版本，其余标注为参考资料。多个版本并存时，模型会把不同口径拼成完整回答，这是最难排查的错误类型，因为每一句都能找到出处，整体却是错的。
数据：分级与更新
内容要能按敏感度打标，明确哪些可对外、哪些限部门、哪些含个人信息需脱敏；同时准备真实提问样本集用于验收。更新机制包括触发条件、下线流程与留存期限，三者缺一，知识库半年后就会失去可信度，也很难再被业务启用。
适用与不适用
适合谁
- 有明确业务负责人、愿意派人做内容加工的团队
- 文档已电子化、版本管理初步成型的企业
- 准备把知识库接入客服或交付流程的组织
不适合谁
- 希望由 IT 一个部门包办内容与业务的团队
- 底稿以纸质或扫描件为主、没有校对人力
典型场景
某物业公司上线前先做条件盘点：工程部出两名负责人管设备操作与应急预案，品质部抽一人做片段加工，IT 负责账号与日志。数据侧把现有制度按现行与废止分开，扫描件重新录入，再从客服记录整理一批真实提问做样本。
可执行步骤
- 按知识主题划分负责人与复核人，写清裁决与更新职责，避免出现无人认领的主题
- 指定内容加工人并预留固定工时，把加工量纳入季度目标与每周交付节奏
- 清理重复、废止文档与个人留存副本，确定唯一权威版本并登记生效日期
- 完成扫描件识别校对与敏感内容分级脱敏，并保留原图便于逐条回查核对
常见坑
- 让 IT 独自承担内容责任，业务不参与裁决；上线后回答与现场做法脱节，一线不再信任，也无人愿意反馈。
- 不给加工工时，靠加班拆文档；切片质量差，召回后仍需重读原文，效率没有改善，反而多出一层操作成本。
- 保留多个版本的现行文件，模型拼接不同口径；应指定一份主版本，并同步下线旧版、复印件与个人留存副本。
自检与验收清单
- 每类知识是否有能裁决对错的负责人与更新责任
- 内容加工是否有固定工时、交付节奏与验收口径
- 重复、废止文档与个人副本是否已经清理，并留有记录
- 是否有真实提问样本集用于验收、回归与版本留存
常见问题
没有专职知识运营，能不能做？
可以，但要指定兼任人选、给出固定工时，例如每周半天，并把片段加工量写进季度目标。完全靠项目期临时抽调，通常在验收后就没人维护，半年内回答质量明显下降，系统随之闲置。
数据一定要搬到统一平台吗？
不一定。可以在原系统上建索引层，通过接口读取并只同步片段与权限标签，原文仍留在原处。这样改动小，但要求原系统提供稳定读取接口与版本标识，否则片段与原文容易脱节。
含个人信息的记录怎么处理？
先判断是否确有必要入库，能脱敏的脱敏，能用汇总替代的不用明细；访问日志与留存期限要同步设计。具体合规要求应结合业务场景由法务与安全团队确认，不由工具默认设置决定。