跳到主要内容

第 2.5.3 节：把审批、发布状态和冲突处理放进知识治理流程

审批、发布状态和冲突处理只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够设计审批、发布状态和冲突处理的角色权限、审批条件、审计记录和越权处理。

实现步骤或决策流程​

推荐技术流​

本章推荐的资料治理技术流如下。

步骤做什么为什么
1盘点资料来源先知道售后政策、产品说明、FAQ（常见问题）和工单经验分别从哪里来。
2定义 source of truth（单一事实来源）解决多份资料说法不一致时以谁为准。
3指定 owner（负责人）和 reviewer（审核人）让资料错误有人修、有人审。
4设计状态流转区分草稿、审核中、已发布、冲突、废弃和归档。
5设计版本和有效期让系统知道当前应该引用哪个版本。
6设计权限级别防止内部资料被外部客户检索或引用。
7设计质量评分把资料完整性、权威性、新鲜度和一致性纳入检索前置条件。
8设计冲突处理发现冲突时转入审核流程，不让模型猜。
9发布后再解析和索引避免草稿和未审批资料进入正式回答。
10用日志和反馈持续复核把错误回答、低评分资料和过期资料带回治理闭环。

这条技术流和“上传即索引”相反。它看起来慢一点，但企业项目要的是长期可信，而不是一次演示能回答。

字段契约​

字段契约的作用是让业务负责人、内容审核人、AI（人工智能）工程师、客服团队和日志系统对齐同一种语言。本节不写代码，只讲字段含义、来源和验收要求。

资料主记录契约​

字段含义来源是否必填验收要求
knowledge_id（知识编号）唯一标识一份知识资料系统生成是不随标题变化而变化，能关联版本和日志。
title（标题）资料名称上传者或系统提取是客服和审核人能看懂。
knowledge_type（知识类型）售后政策、产品说明、FAQ（常见问题）、工单经验、培训材料等上传入口或人工选择是支持按资料类型过滤和统计。
owner_team（负责人团队）对资料业务准确性负责的团队管理员或业务配置是出错后能找到责任团队。
reviewer（审核人）负责审核资料能否发布的人或角色审核流程是，发布前必填审核中和已发布资料必须有审核人。
status（状态）draft、reviewing、published、deprecated、conflict、archived状态流转模块是检索和发布必须按状态过滤。
version（版本）资料当前版本上传或发布流程是引用和日志必须能追溯版本。
effective_date（生效日期）资料从哪一天开始可作为依据业务负责人填写是，政策类必填未生效资料不能进入正式回答。
expire_date（过期日期）资料到哪一天后不再作为当前依据业务负责人填写视资料类型已过期资料不能进入正式回答。
source_of_truth（单一事实来源）是否为权威来源，或引用哪个权威来源来源识别和人工确认是冲突时能判断优先级。
conflict_group_id（冲突组编号）资料与其他资料冲突时的分组编号冲突处理模块否冲突资料必须能被集中处理。
quality_score（质量评分）资料可用于回答的综合评分质量评分模块是低于阈值不能进入高置信回答。
permission_level（权限级别）public、customer、support_internal、manager_only 等可见范围上传者和审核人确认是检索和引用必须按角色过滤。
approval_record（审批记录）审批人、时间、意见、结论和适用范围审批流程是，发布前必填已发布资料必须可追溯审批记录。
change_reason（变更原因）为什么创建、修改、废弃或回滚上传者或审核人填写是，变更时必填版本变化能解释给业务和质检。
last_reviewed_at（最近复核时间）最近一次人工确认资料仍有效的时间复核流程是，发布后必填超过复核周期要提醒或降级。

质量评分契约​

评分维度说明低分表现对系统的影响
完整性是否包含标题、正文、适用范围、版本和负责人只有截图、片段或口头说明不能直接发布，退回补充。
权威性是否来自 source of truth（单一事实来源）或被负责人确认来自个人笔记或聊天记录降低排序，要求审核。
新鲜度是否在有效期内并按周期复核过期、未复核、未知生效时间不进入正式回答或提示转人工。
一致性是否和同类资料冲突新旧政策结论不一致进入 conflict（冲突中）。
可解析性是否能稳定抽取段落、表格和引用位置扫描图、格式混乱、附件缺失需要人工整理或低置信使用。
权限清晰度是否明确可见角色和引用展示范围内外部资料混在一起不允许发布到外部问答。
可引用性是否能定位到章节、页码、段落或 URL（统一资源定位符）只能找到整份文件回答引用质量下降。
反馈表现历史回答中是否经常被标错客服频繁纠错或用户差评触发复核和重新索引。

质量评分不是为了让系统“看起来专业”，而是为了让资料进入检索前有门槛。评分低的资料可以进入草稿区、内部参考区或质检任务，但不应该直接影响客户回答。

冲突处理契约​

字段含义说明
conflict_group_id（冲突组编号）同一组冲突资料的编号例如“定制款退货政策冲突”。
conflict_reason（冲突原因）为什么判断为冲突结论不同、有效期重叠、权限不一致、来源优先级不清。
primary_source（主来源）临时或最终优先来源通常指向 source of truth（单一事实来源）。
affected_knowledge_ids（受影响知识）哪些资料被卷入冲突方便批量处理和下线。
resolution_owner（处理负责人）谁负责裁决一般是业务负责人或内容审核人。
resolution_status（处理状态）待处理、处理中、已解决、转人工规则决定是否允许进入检索。
resolution_note（处理说明）最终如何处理更新、废弃、合并、保留为内部参考。

冲突处理的默认原则是：冲突没有解决前，不要让模型自行“综合”。

发布索引契约​

字段含义验收要求
index_allowed（是否允许索引）资料能否进入正式检索索引只有 published（已发布）且权限清晰的资料为是。
index_scope（索引范围）对外客户、内部客服、管理层或全部必须和 permission_level（权限级别）一致。
citation_required（是否必须引用）回答是否必须展示依据政策、产品承诺、售后规则默认必须。
fallback_action（兜底动作）资料不可用时怎么处理拒答、转人工、提示资料待审核或创建工单。
review_due_at（下次复核时间）下次必须人工确认的时间到期前提醒 owner（负责人）或 reviewer（审核人）。

这一组字段决定资料能不能从治理区进入 RAG（检索增强生成）区。没有这道门，草稿、旧版和冲突资料很容易被模型看到。

制作步骤​

下面是一套不用写代码也能落地的制作步骤。读者可以把它直接转成作品集里的项目方案。

第 1 步：盘点资料来源​

先列资料，不要先谈模型。

资料来源例子初始风险
正式政策售后政策、保修政策、服务承诺需要版本和生效日期。
产品资料产品说明书、规格表、使用手册容易和官网页面或培训课件冲突。
客服 FAQ（常见问题）一线客服常用回答、标准话术容易多版本并存。
工单经验典型投诉、退款争议、异常处理经验可能只适合内部参考。
培训材料新客服培训课件、质检案例可能过期或不适合对外引用。
临时通知促销期规则、紧急政策变更有效期短，必须标注过期时间。

盘点时要问 3 个问题：这份资料从哪里来，谁负责，能给谁看。

第 2 步：定义单一事实来源​

对每类资料定义权威来源。

主题推荐 source of truth（单一事实来源）辅助资料
售后退换货审批后的售后政策文档FAQ（常见问题）、客服话术、培训课件。
产品规格产品负责人发布的产品说明或规格表官网介绍、销售话术。
保修范围售后政策和产品保修条款工单经验、客服备注。
投诉升级客服主管发布的内部流程历史工单案例。

辅助资料不是没用，但它不能覆盖权威来源。它可以帮助模型把政策解释得更清楚，不能改变政策结论。

第 3 步：设计状态流转​

推荐状态流转如下：

  1. 新资料进入 draft（草稿）。
  2. 字段补齐后进入 reviewing（审核中）。
  3. 审核通过后进入 published（已发布）。
  4. 发现冲突时进入 conflict（冲突中）。
  5. 新版本发布后，旧版本进入 deprecated（已废弃）。
  6. 长期不用但需要留痕的资料进入 archived（已归档）。

这套状态要和索引发布绑定。只有 published（已发布）资料能进入正式索引。其他状态最多进入后台管理、内部参考或人工处理队列。

第 4 步：设计版本和有效期​

版本设计要回答 4 个问题：

  • 当前哪个版本能回答当前问题？
  • 历史回答当时使用了哪个版本？
  • 新版本什么时候生效？
  • 旧版本什么时候废弃或归档？

售后政策尤其要注意 effective_date（生效日期）和 expire_date（过期日期）。如果新政策 2026 年 7 月 1 日生效，6 月 30 日的历史工单引用旧政策可能是正确的；7 月 1 日后继续引用旧政策就是错误。

第 5 步：设计权限级别​

客服工作台可以先用 4 档权限：

权限级别含义例子
public外部客户可见公开售后政策、公开产品说明。
customer登录客户可见和自己订单相关的说明、账户服务规则。
support_internal客服内部可见内部话术、投诉升级流程、工单经验。
manager_only主管或审核人可见质检报告、敏感投诉处理策略。

权限过滤要发生在资料入库、检索、生成和引用展示多个环节。不要把内部资料先交给模型，再要求模型“不要说出去”。

第 6 步：设计质量评分​

可以先用 100 分制，但不要只看文本质量。

分数区间建议处理
85-100可进入正式检索，适合作为回答依据。
70-84可进入内部检索，但关键结论需要引用权威资料。
50-69只适合人工参考或待审核，不直接回答客户。
0-49退回整理、补负责人、补版本或处理冲突。

质量评分要能解释。不要只显示一个分数，还要告诉审核人为什么扣分：缺负责人、过期、权限不清、无法解析、与旧政策冲突等。

第 7 步：设计冲突处理​

冲突不一定靠系统自动完全判断，但系统要能把冲突暴露出来。

常见冲突来源：

  • 两份资料对同一售后规则给出不同天数。
  • 产品说明和客服 FAQ（常见问题）对保修范围不一致。
  • 新旧版本有效期重叠。
  • 内部资料和公开资料的口径不一致。
  • 工单经验中的特殊处理被误当成通用政策。

处理步骤：

  1. 标记 conflict_group_id（冲突组编号）。
  2. 把相关资料状态改为 conflict（冲突中）或降低可用范围。
  3. 通知 owner_team（负责人团队）和 reviewer（审核人）。
  4. 确认 source of truth（单一事实来源）。
  5. 更新、废弃、合并或归档冲突资料。
  6. 重新发布和索引。

第 8 步：设计发布和回滚​

发布不是“点击保存”。发布要满足：

  • 字段完整。
  • 有负责人和审核人。
  • 有审批记录。
  • 状态为 published（已发布）。
  • 到达生效日期。
  • 权限级别明确。
  • 没有未解决冲突。
  • 质量评分达到阈值。

回滚也要设计。新政策发布后如果发现错误，系统不能靠删除资料解决。应该发布修正版本，旧版本进入 deprecated（已废弃），并在 change_reason（变更原因）里说明为什么回滚或修正。

第 9 步：设计验收问题集​

资料治理验收不能只问几个正常问题。至少要覆盖：

验收类型示例问题期望行为
最新政策“定制款现在能 7 天无理由退吗？”引用最新已发布售后政策。
旧版资料“旧 FAQ（常见问题）里说能退，是真的吗？”说明旧版已废弃，以新政策为准。
产品冲突“电池到底保修 6 个月还是 12 个月？”发现冲突时拒答或转人工，不编造。
权限控制外部客户问内部投诉升级策略不泄露内部资料。
工单经验客服问“类似投诉以前怎么处理”内部展示经验，但标注不是公司承诺。
复核超期命中长时间未复核资料降级、提醒复核或转人工。

这类验收能证明你的知识库不只是“能答”，而是“知道什么时候不能答”。

和后续章节关系​

本章是第 2 卷 RAG 工程链路里的资料底座。

后续章节和本章的关系
文档解析与清洗只有先知道资料状态和权限，解析后的内容才知道能不能进入索引。
分块、Embedding（嵌入向量）、索引与重排分块和索引要继承 knowledge_id（知识编号）、version（版本）、权限和质量评分。
向量数据库与混合检索检索过滤需要使用状态、有效期和权限字段。
RAG 评估评估不仅看命中率，还要看引用是否来自正确版本和已发布资料。
MCP（模型上下文协议） 基础与工具生态知识资料和工具能力都需要清晰边界，后续可以通过 MCP 暴露受控资源。
LangGraph（智能体状态图框架） 状态图资料冲突、转人工、审批和复核可以成为状态图中的节点。
可观测性与安全权限资料变更日志、引用日志和权限过滤会进入线上审计。

如果说前面的 RAG 边界章节解决“哪些问题该走 RAG”，本章解决的是“什么资料有资格进入 RAG”。

岗位 JD（职位描述） 能力映射​

企业知识库治理能力常对应“RAG 工程化”“知识运营”“AI 产品落地”和“内容安全”类岗位要求。

JD（职位描述）常见要求本章对应能力面试证据
建设企业级知识库治理流程能定义 owner（负责人）、reviewer（审核人）、状态、版本、审批和质量评分展示资料主记录契约和状态流转图。
控制知识库回答风险能处理过期、冲突、缺审批、越权和低质量资料用失败兜底表说明何时拒答或转人工。
与业务、客服、质检协作能区分业务事实责任、内容审核责任和工程实现责任说明售后政策改版如何从草稿到发布再到回滚。
支撑审计和持续运营能记录资料变更、审批、引用和反馈复盘日志用 knowledge_id（知识编号）和 version（版本）追溯错误回答。

版本与资料来源​

本节聚焦企业知识库资料治理、质量评分、状态流转、权限审计和面试表达。

过时风险：模型供应商的文件检索接口、Embedding（嵌入向量）模型、向量数据库能力和企业内部审批流程都会变化。进入真实项目开发前，必须重新核对官方文档、当前模型能力、客户资料流程和权限要求。

继续学习​