第 2.5.2 节：把 Owner、Reviewer、新鲜度和版本纳入知识治理流程
Owner、Reviewer、新鲜度和版本只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够写出 Owner、Reviewer、新鲜度和版本的验收样例、通过/不通过标准、判断阈值和风险说明。
核心概念四层解释法
下面的概念都按四层解释：人话解释、项目位置、工程动作、面试说法。
Source of Truth（单一事实来源）
人话解释：source of truth（单一事实来源）就是公司遇到同一个事实问题时，最终以哪份资料为准。它不是“唯一一份资料”，而是“最终裁决依据”。
项目位置：在客服工作台里，售后政策可能同时出现在官网、客服 FAQ（常见问题）、培训课件、内部通知和工单经验里。系统必须知道：当这些资料说法不一致时，哪个来源优先。例如售后政策以审批后的政策文档为准，产品规格以产品负责人发布的产品说明为准。
工程动作：你要给每份资料写入 source_of_truth（单一事实来源）字段，标注它是否是权威来源、引用哪个权威来源、是否只是解释材料。检索和生成时，权威资料优先；非权威资料只能辅助解释，不能覆盖权威资料。
面试说法：企业 RAG（检索增强生成）不是把所有文档等权重丢进向量库。我会先定义单一事实来源，让模型优先引用业务认可的版本，避免旧 FAQ（常见问题）或个人笔记覆盖正式政策。
Owner（负责人）与 Reviewer（审核人）
人话解释：owner（负责人）负责资料是否正确，reviewer（审核人）负责资料能不能发布。负责人回答“这是不是业务事实”，审核人回答“这能不能给系统用”。
项目位置：售后政策的 owner（负责人）可能是售后运营团队，reviewer（审核人）可能是客服质检或法务；产品说明的 owner（负责人）可能是产品团队，reviewer（审核人）可能是内容运营；工单经验的 owner（负责人）可能是客服主管，reviewer（审核人）可能是一线质检。
工程动作：字段里要有 owner_team（负责人团队）和 reviewer（审核人）。状态从 draft（草稿）进入 reviewing（审核中）时，必须有 reviewer（审核人）。状态进入 published（已发布）前，必须有审批记录和最近复核时间。
面试说法：资料治理不能只靠 AI（人工智能）工程师。工程师负责系统字段、权限和流程，业务负责人负责事实准确性，内容审核人负责发布质量，客服团队负责反馈错误样例。
Freshness（新鲜度）
人话解释：freshness（新鲜度）就是资料是否仍然新。不是所有资料都按上传时间判断，有些资料过了生效期才可用，有些资料超过复核周期就不该继续自动回答。
项目位置：售后政策有 effective_date（生效日期）和 expire_date（过期日期）；产品说明有发布批次；客服 FAQ（常见问题）可能每月复核；工单经验可能 90 天后必须重新确认。
工程动作：你要设计 effective_date（生效日期）、expire_date（过期日期）、last_reviewed_at（最近复核时间）和复核周期。检索时，未生效、已过期、超过复核周期的资料不能直接进入正式回答，最多进入后台提醒或人工参考。
面试说法：我会把 freshness（新鲜度）做成系统规则，而不是靠模型判断。资料即使相似度很高，只要过期或未复核，就不能作为正式回答依据。
Approval（审批）
人话解释：approval（审批）就是确认资料从“有人写了”变成“公司允许系统使用”。企业知识库里，未审批资料不能直接影响客户回答。
项目位置：售后政策改版后，草稿可以先进入内部编辑区，但不能进入外部客户问答。内容审核人确认后，资料进入 published（已发布）状态，并生成 approval_record（审批记录）。
工程动作：你要记录审批人、审批时间、审批意见、适用范围和变更原因。审批记录要能追溯到版本，不能只保留最新一次结果。
面试说法：我不会把“上传者是员工”当成可发布依据。企业 RAG 要区分草稿、审核中和已发布，只有已审批资料才能进入正式检索。
Versioning（版本管理）
人话解释：versioning（版本管理）就是资料变更后，新旧版本怎么并存、怎么切换、怎么追溯。它解决“现在以哪个版本回答”和“过去为什么那样回答”两个问题。
项目位置：客服 FAQ（常见问题）可能有 2026.06 版和 2026.07 版。7 月 1 日以前的历史回答引用旧版是合理的；7 月 1 日以后继续引用旧版就是问题。
工程动作：每份资料要有 version（版本）、effective_date（生效日期）、expire_date（过期日期）、change_reason（变更原因）和版本关系。新版本发布后，旧版本通常进入 deprecated（已废弃）或 archived（已归档），但不能直接删除，因为历史工单和引用日志还要追溯。
面试说法：版本管理不是文件名加 v2。它要影响检索、引用、日志和回滚。上线后出错时，系统要能知道哪个回答用了哪个资料版本。
Conflict Handling（冲突处理）
人话解释：conflict handling（冲突处理）就是系统发现两份资料对同一问题给出不同结论时，不能让模型自由综合，而要进入可控流程。
项目位置：产品说明书写“电池保修 12 个月”，售后 FAQ（常见问题）写“电池保修 6 个月”。这两份资料可能都能命中用户问题，但结论冲突。系统应该把它们放进同一个 conflict_group_id（冲突组编号），提示 owner（负责人）和 reviewer（审核人）处理。
工程动作：你要设计冲突检测入口、冲突状态、冲突组、冲突优先级和兜底回答。冲突未解决前，资料可进入 conflict（冲突中）状态；正式回答应拒答、引用权威来源或转人工确认。
面试说法：资料冲突不是 Prompt（提示词）能彻底解决的问题。我会用冲突组、权威来源和人工审核流程处理，避免模型把互相矛盾的资料拼成错误承诺。
Published（已发布）与 Deprecated（已废弃）
人话解释：published（已发布）代表资料可以进入正式回答；deprecated（已废弃）代表资料不再作为当前答案依据，但仍可保留给历史追溯。
项目位置：2026 年 7 月新售后政策发布后，旧政策应进入 deprecated（已废弃）或 archived（已归档）。客服查看历史工单时可以看到旧政策，但新客户提问不能再引用旧政策。
工程动作：状态字段必须进入检索过滤和引用展示。published（已发布）资料可以用于回答；deprecated（已废弃）资料只用于历史追溯；archived（已归档）资料默认不进入检索；draft（草稿）和 reviewing（审核中）不能进入正式客户回答。
面试说法：我会把资料状态作为 RAG 的硬过滤条件。不是所有进入数据库的资料都能进入模型上下文。
Quality Score（质量评分）
人话解释：quality_score（质量评分）是系统对资料可用程度的综合评价。它不是“内容写得好不好看”，而是“能不能安全、准确、稳定地用于回答”。
项目位置：售后政策如果有负责人、审批记录、版本、生效日期、权限、引用锚点，并且最近复核过，质量评分就高。某个客服私下整理的经验贴即使很有用，如果无审批、无适用范围、无复核时间，评分也不能高。
工程动作：质量评分可以结合完整性、权威性、新鲜度、一致性、可解析性、权限清晰度和反馈质量。评分低的资料不能直接进入高置信回答，应该进入补充、审核或人工参考。
面试说法：RAG 效果差时，我不会只调模型参数。我会先看资料质量评分，检查资料是否完整、权威、新鲜、一致和有权限标记。
本章在客服工作台中的位置
客服 Agent（智能体）工作台可以拆成 8 层。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 用户入口 | 外部客户、一线客服、运营人员提问或维护资料 | 识别角色和权限。 |
| 问题分流层 | 判断走普通回答、RAG、Tool Calling（工具调用） 还是人工 | 本章提供资料可用性判断。 |
| 资料治理层 | 管理资料来源、负责人、状态、版本、审批、冲突和质量评分 | 本章核心。 |
| 解析与索引层 | 解析文档、分块、生成 Embedding（嵌入向量）、建立索引 | 只允许合格资料进入正式索引。 |
| 检索生成层 | 检索、重排序、生成引用回答或拒答 | 使用治理字段过滤和排序。 |
| 工单协作层 | 创建工单、转人工、沉淀经验 | 经验沉淀要回到治理流程。 |
| 审批与质检层 | 审批资料、复核错误回答、处理冲突 | 本章核心。 |
| 日志审计层 | 记录资料变更、检索引用、审批和反馈 | 本章核心。 |
本章主要处在资料进入 RAG 之前，以及回答出错后回到资料修正的闭环里。它不像分块和向量数据库那样显眼，但它决定了系统能不能长期可信。
一个简单判断是：如果你的客服工作台没有资料状态、负责人、版本、审批和冲突处理，那么即使用了很强的模型，也只能算演示版知识库，不能算企业级知识库。
系统流程图
这张流程图有 5 个重点：
读图重点：先读上组：资料不是上传后直接可用，冲突和审核失败都会回修；再读下组：已发布资料进入索引和回答，反馈决定它回到草稿更新还是退出当前检索。
- 资料进入系统不等于可回答，必须先治理。
- 单一事实来源、负责人、版本、权限和有效期要在审核前补齐。
- 冲突资料不能交给模型自由综合，要进入冲突组处理。
- 只有 published（已发布）资料进入正式索引和客户回答。
- 问答日志和客服反馈会反过来推动资料更新、废弃和归档。
模块拆分
客服知识库资料治理可以拆成 9 个模块。
| 模块 | 负责什么 | 主要输出 |
|---|---|---|
| 资料接入模块 | 接收售后政策、产品说明、FAQ（常见问题）、工单经验和培训材料 | 原始资料记录。 |
| 来源识别模块 | 判断资料来自官网、业务系统、人工上传、工单沉淀还是外部文件 | source_of_truth（单一事实来源）候选。 |
| 元数据管理模块 | 管理负责人、审核人、版本、生效日期、过期日期和权限 | 资料字段契约。 |
| 状态流转模块 | 控制 draft（草稿）、reviewing（审核中）、published（已发布）等状态 | 可发布状态机。 |
| 质量评分模块 | 计算完整性、权威性、新鲜度、一致性和可解析性 | quality_score（质量评分）。 |
| 冲突处理模块 | 发现多资料结论冲突并创建冲突组 | conflict_group_id（冲突组编号）和处理记录。 |
| 审批记录模块 | 记录审核人、审批意见、发布时间和变更原因 | approval_record（审批记录）。 |
| 索引发布模块 | 只把合格资料送入解析、分块、Embedding（嵌入向量）和索引 | 可检索知识片段。 |
| 反馈复盘模块 | 接收客服反馈、用户差评、质检问题和错误引用 | 更新、废弃或归档任务。 |
作品集项目不需要一开始做成复杂平台，但至少要做出最小治理闭环：
- 资料有状态。
- 资料有负责人和版本。
- 只有已发布资料能被检索。
- 过期和冲突资料会被拒绝或转人工。
- 回答能显示引用资料和版本。
这 5 点比“多接几个模型”更能体现企业工程能力。