第 2.5.1 节：先确定知识库的单一事实来源
进入实现之前，先围绕“先确定知识库的单一事实来源”划清适用场景、不做范围和判断条件。完成本节后，你应该能够写出单一事实来源的适用场景、不适用场景、前置条件和进入工程实现的判断标准。
本章要解决什么问题
很多企业做 RAG（检索增强生成） 项目时，一开始会把注意力放在模型、Embedding（嵌入向量）、向量数据库、重排序和 Prompt（提示词）上。客户说“我们有很多资料”，工程师就开始讨论怎么切分、怎么向量化、怎么召回。演示阶段看起来很顺：上传几份文档，问几个问题，模型能回答。
真正上线后，问题很快出现。
用户问“这个产品现在还能 7 天无理由退货吗”，系统同时检索到 2025 年售后政策、2026 年临时通知和某个客服自己整理的 FAQ（常见问题）。用户问“配件是否保修”，系统命中产品说明书 A 版和 B 版，两个版本结论不同。客服主管更新了售后规则，但旧资料还在知识库里继续被命中。某个工单经验本来只适合内部培训，却被外部客户问答引用。回答看起来通顺，实际把过期、冲突、越权的资料包装成了公司承诺。
这类失败常常不是模型问题，而是资料治理问题。
本章要解决的问题是：如何把企业知识库从“文件堆”治理成可发布、可追溯、可复核、可下线的资料资产。
在企业客服知识库与工单 Agent（智能体） 工作台里，RAG 回答必须回答 6 个问题：
- 这份资料是不是单一事实来源 source of truth（单一事实来源）？
- 谁是 owner（负责人），谁是 reviewer（审核人）？
- 资料是否新鲜，是否超过 freshness（新鲜度）要求？
- 资料是否经过 approval（审批）并允许发布？
- 当前 version（版本）和历史版本之间如何追溯？
- 多份资料冲突时，系统如何处理，而不是让模型自己猜？
本章会用流程图、字段契约、状态表、权限表和失败兜底表，把资料治理讲成真实项目可以落地的工程设计。
学习目标
学完本章后，读者应该能做到：
- 用人话解释企业 RAG 为什么会因为资料治理失败。
- 识别客服知识库中的过期、重复、冲突、无负责人、无权限标记和无版本资料。
- 设计 source of truth（单一事实来源）、owner（负责人）、reviewer（审核人）、freshness（新鲜度）、approval（审批）、versioning（版本管理）和 conflict handling（冲突处理）。
- 区分 draft（草稿）、reviewing（审核中）、published（已发布）、deprecated（已废弃）、conflict（冲突中）和 archived（已归档）状态。
- 为售后政策、产品说明、客服 FAQ（常见问题）和工单经验设计资料字段契约。
- 设计业务负责人、内容审核人、AI（人工智能）工程师和客服团队之间的协作边界。
- 把资料质量评分纳入 RAG 的检索、发布、验收和复盘流程。
- 说明资料冲突、资料过期、权限错误、审批缺失和版本混乱时如何兜底。
- 把本章能力讲成作品集项目和面试中的工程亮点。
贯穿业务场景
本章继续使用“企业客服知识库与工单 Agent 工作台”作为贯穿项目。这个工作台服务 4 类人：
| 角色 | 典型需求 | 对知识治理的要求 |
|---|---|---|
| 外部客户 | 查询产品、售后、物流和服务规则 | 只能看到允许公开的已发布资料。 |
| 一线客服 | 快速查政策、生成回复建议、处理工单 | 需要最新政策、内部话术和可追溯引用。 |
| 业务负责人 | 维护售后政策、产品说明和服务承诺 | 需要确认哪些资料是公司认可版本。 |
| 内容审核人 | 审核资料是否准确、合规、可发布 | 需要审批记录、变更原因和冲突提示。 |
围绕这个工作台，我们重点处理 4 类资料。
| 资料类型 | 常见问题 | 治理重点 |
|---|---|---|
| 售后政策 | 政策改版后旧条款仍被引用 | 版本、生效日期、废弃状态和审批记录。 |
| 产品说明 | 产品手册、官网页面、培训课件说法不一致 | 单一事实来源、冲突组和负责人确认。 |
| 客服 FAQ（常见问题） | 一线客服私下维护多个版本 | 审核流、发布状态、质量评分和适用范围。 |
| 工单经验沉淀 | 历史处理经验有价值，但不一定能对外承诺 | 权限级别、适用条件、复核周期和转人工规则。 |
来看一个具体场景。
公司在 2026 年 7 月 1 日修改了售后政策：部分定制类商品不再支持 7 天无理由退货。业务负责人在内部群发了通知，运营同学更新了官网政策页，但客服 FAQ（常见问题）里仍然保留旧答案，产品说明书也还没更新。一线客服问系统：“定制款能退吗？”如果 RAG 只按相似度召回，模型可能把旧 FAQ（常见问题）和新政策混在一起回答。
这时真正需要的不是换一个更强模型，而是资料治理：
- 明确官网政策页或审批后的售后政策文档是 source of truth（单一事实来源）。
- 给旧 FAQ（常见问题）标记 deprecated（已废弃）或 conflict（冲突中）。
- 要求新政策必须有 owner_team（负责人团队）、reviewer（审核人）和 approval_record（审批记录）。
- 在检索时只允许 published（已发布）且 effective_date（生效日期）已经到达的资料进入正式回答。
- 对冲突资料生成提醒，让内容审核人处理，而不是让模型自行判断。
这就是本章要训练的项目意识。
新手为什么会卡住
新手做企业知识库时，常见卡点不是“不知道怎么调用模型”，而是低估了资料本身的复杂度。
| 误解 | 问题在哪里 | 正确理解 |
|---|---|---|
| 上传成功就是知识库成功 | 上传只代表文件进了系统，不代表内容可用 | 资料要经过归属、审核、状态、权限、版本和索引流程。 |
| 相似度最高的资料就是正确答案 | 相似度不等于权威性和新鲜度 | 检索排序要结合状态、版本、有效期、质量评分和权限。 |
| 模型能自己判断新旧资料 | 模型不知道企业内部哪个版本有效 | 生效日期、过期日期和发布状态必须由系统字段控制。 |
| 冲突资料让模型综合一下 | “综合”可能变成编造承诺 | 冲突资料要进入冲突处理流程，必要时拒答或转人工。 |
| 资料负责人可有可无 | 没有人负责，错误资料无法修正 | 每份关键资料必须有 owner（负责人）和 reviewer（审核人）。 |
| 权限靠 Prompt 提醒 | Prompt 不能替代权限过滤 | permission_level（权限级别）要进入入库、检索、引用和日志。 |
| 知识库上线后就结束 | 企业政策和产品会持续变化 | freshness（新鲜度）、复核周期和废弃流程是长期运营能力。 |
这些误解背后是同一个问题：把 RAG 当成模型项目，而不是企业知识工程项目。企业知识工程的第一原则是：模型只能基于你允许它看到的资料回答；如果资料本身失控，回答就会失控。