主题
08 - 内容治理与冷启动
一句话:知识底座上线失败,多数不是检索不准,而是库里没有可信答案——所以冷启动的第一件事不是接引擎,是给每个主题定一个权威源、给每份文档找一个负责人;没人认领的文档进了库,只是把没人管的答案变成机器在传播的错答案。本栏按内容侧优先排处置顺序,判据是下面的四分体检,不依赖任何统计断言。
一、先承认问题在内容侧
技术链路能承诺“进得来的都能查到、查不到的会说没有”,它无法承诺“库里的内容是对的”。企业真实场景的三种失败,责任都在内容:
| 现象 | 看起来像 | 实际是 |
|---|---|---|
| 答非所问且引用真实存在 | 检索差 | 库里那份文档本身就过期,引用没错,内容已废 |
| 同一问题两个答案 | 模型不稳定 | 两份文档互相冲突,且没有指定谁是权威 |
| 员工不用,回退问同事 | 采纳差 | 他问的范围压根没人维护,问一次错两次就再也不问 |
结论一句:检索质量决定上限,内容治理决定地板。地板没铺,越准的检索只是把错答案说得越肯定。
二、权威源与负责人
一个主题只允许一个权威源,其余全部降级为参考。这条没有替代方案,多源并存时任何检索策略都只是在猜哪份更新。
| 角色 | 负责 | 交付物 |
|---|---|---|
| 内容负责人 | 单份文档的正确性与时效,回答“这条还有效吗” | 复审记录、下线确认 |
| 知识库管理员 | 一个知识域的权威源清单、冲突裁决、密级判定 | 权威源清单、裁决记录 |
| 平台运维 | 链路可用、权限生效、容量与备份 | 验收证据(见 06) |
三者不能合并。负责人兼管理员,会出现“自己判定自己文档可信”;管理员兼运维,权限审批与放行会走同一个手。
冲突裁决规则要写死,不靠模型判断:时间新者优先只在同一权威源内成立;跨源冲突时按权威源清单裁定,未列入清单的一律不作为答案依据,并在回答里给出“该主题存在多个说法”的提示,而不是选一个看起来合理的。
三、存量文档先体检再入库
企业文档不能整库直连导入。先做四分:
扫描看五项事实:负责人是否存在;最后更新时间与声明的复审周期是否匹配;同主题是否存在冲突(靠主题标识判定,不是靠人眼看标题);是否含不适合被检索与引用的内容(个人信息、未发布财务数据、内部代号清单);许可是否允许再用——转载、外部授权、开源许可三类来源必须能回答“我们有没有权利把它答给别人”。
主题标识与权威源清单要真存下来:主题 ID 由管理员在知识域内维护,文档元数据携带该 ID,权威源标记随检索结果返回(见 02 §五)。没有这两项,上面的“无冲突”判定与答案里的“存在多个说法”提示都退化成人工眼看和模型自觉。
四项里没有一项是技术问题,都是内容管理问题;但四项都不做,后面所有检索调优都在给噪声排序。
四、时效与生命周期
每份文档挂三项元数据,缺项即“待归位”、不进默认检索(与 01 的就绪判据同一条口径):负责人、复审周期、生效状态(现行 / 待复审 / 已废止)。
| 状态 | 检索行为 | 答案里的表现 |
|---|---|---|
| 现行 | 正常召回 | 直接引用 |
| 待复审 | 可召回 | 引用附带“该内容已超过复审期,请以最新发布为准” |
| 已废止 | 不召回:由服务端过滤条件里的生效状态执行(见 03),不靠删除文档 | 仅在被明确追问历史版本时受控给出,并标注废止 |
过期是静默失败:不报错、不告警,只是答案一天天变错。所以复审周期的提示必须在答案里可见,而不是只在管理台里标红——没人看管理台。
五、冷启动的顺序
不要按“部门全覆盖”推进,按“问题闭环”推进。
- 选三个高频高代价场景:判断标准是同一问题每天被问很多次、答错的代价能算出来(合规口径、报销与审批规则、故障处置手册)。
- 评测集先于建库:每个场景先出 30 到 50 个真实问题与标准答案来源,再去找文档。顺序反过来,就会变成“库里有什么就答什么”。
- 小库上线,公开拒答:范围窄、答案硬,宁可说“未覆盖”,先建立“它答的能信”这件事。
- 用拒答清单反推扩库:把“查不到”的问题按主题聚类,决定下一个入库对象。扩库由真实需求拉动,而不是由部门配合度拉动。
- 每扩一个域,重跑一次门禁:新域的文档质量、术语习惯与旧域不同,平均值会骗人,分桶看。
第 2 步是最常被跳过的一步,跳过的结果是三个月后没人能说清“这套系统到底覆盖了什么”。
六、结构化数据划界
制度问答与数据查询是两件事,本栏只做前者。
| 维度 | 知识检索 | 数据查询(指标 / SQL) |
|---|---|---|
| 真相载体 | 文档,允许有措辞差异 | 表与指标口径,不允许近似 |
| 错误形态 | 答得不准、引用错 | 数字算错,看起来一样可信 |
| 权限模型 | 文档与密级可见性 | 行级列级权限、指标授权 |
| 校验方式 | 评测集与人工复核 | 口径对账、结果可重跑 |
| 变更节奏 | 随制度发布 | 随数仓模型变更 |
把数据库接进知识库一起召回,会出现最危险的一种错误:模型用一份旧报表文档里的数字,回答了一个本该实时计算的问题。
接法只有一条:数据查询走独立的受控工具(按指标语义层或模板化查询授权),与知识检索在编排层并列,各自返回各自的可信范围;知识库里不放实时数字,只放指标的定义与口径说明。边界写在这里,避免上线后被“顺手也接个数据库吧”推着走。
七、边界
- 本栏给治理口径与推进顺序,不给通过线;覆盖率、复审及时率、拒答率的目标值属业务约定。
- “谁来看内容”是组织决定,不是技术默认值。平台能提供的是让它被看见:无人认领的文档不进默认检索,过期在答案里提示,冲突在回答里显式说明。
- 内容合规审核(涉政、暴恐、侵权、个人信息裸露)不由引擎提供,需外部服务或人工承担;未接入前,高风险内容类型在本节四分阶段直接判“拒收”,不要靠事后检索过滤兜(见 03、06)。
- 多模态一期不做(见 06):音视频与图文混排的深度解析不承诺,体检阶段直接判为“需改写”或“拒收”,不要指望链路自动补齐。