第 3.5.3 节：把研发知识库与政策摘要写成可校验、可复用的工程契约
研发知识库与政策摘要不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够把研发知识库与政策摘要落成字段表、校验规则、错误处理和验收样例。
实现步骤或决策流程
推荐技术流及原因
| 技术环节 | 中文解释 | 推荐原因 |
|---|---|---|
| Document Governance（文档治理） | 为资料建立来源、版本、负责人、权限、更新时间和过期状态 | 解决“哪个文件才算准”的根本问题 |
| Chunking（分块） | 把长文档按语义、标题、流程步骤或问答单元切分 | 让检索命中更准确，避免答非所问 |
| Embedding（嵌入向量） | 把文本转成便于相似度检索的向量表示 | 适合从大量资料中找到相关段落 |
| Vector Database（向量数据库） | 存储向量和元数据，用于快速检索相似内容 | 适合企业资料量持续增长的场景 |
| Reranker（重排序器） | 对初步检索结果重新排序，挑出更贴近问题的资料 | 提高答案依据质量，减少相似但不适用的片段 |
| RAG（检索增强生成） | 先检索资料，再基于资料回答 | 让答案能引用来源，不靠模型记忆 |
| RBAC（基于角色的访问控制） | 按员工角色、部门、岗位、项目控制可见资料 | 防止越权看到敏感制度或项目资料 |
| Citation（引用） | 回答中显示依据来源和关键段落 | 增强信任，也便于员工核对原文 |
| Feedback Loop（反馈闭环） | 收集错误反馈、修订资料并重新生效 | 让知识库越用越准，而不是一次性交付 |
| Audit Log（审计日志） | 记录谁问了什么、引用了哪些资料、答案版本和反馈处理 | 适合企业合规和运营复盘 |
这套技术流的理由很简单：企业内部问答的核心不是“回答得像人”，而是“回答得有依据、看得到权限、改得动资料、追得回责任”。
字段契约表
| 字段 | 含义 | 来源 | 必填 | 验证与兜底 |
|---|---|---|---|---|
| document_id | 资料编号 | 资料治理系统 | 是 | 每份资料唯一，便于更新和追溯 |
| title | 资料标题 | 原始资料或人工录入 | 是 | 标题缺失时不进入正式库 |
| owner | 资料负责人 | 业务部门 | 是 | 无负责人资料只能作为参考，不进入正式回答 |
| version | 资料版本 | 发布记录 | 是 | 多版本冲突时优先正式发布版本 |
| effective_date | 生效日期 | 制度或发布记录 | 是 | 未生效资料不能用于正式答复 |
| expiry_date | 过期日期 | 制度或负责人设置 | 否 | 过期资料检索时降权或下线 |
| access_scope | 可访问范围，如全员、部门、岗位、项目 | 权限规则 | 是 | 用户无权限时不得检索该资料 |
| chunk_id（分块编号） | 分块编号 | 分块流程生成 | 是 | 回答引用到具体片段，不能只引用整份文档 |
| question_intent | 用户问题意图，如制度查询、流程步骤、培训复习 | 提问理解 | 是 | 意图不明时先追问 |
| retrieved_sources | 被检索到的资料片段 | 检索与重排序结果 | 是 | 片段不足时拒答或只给查询建议 |
| answer | 面向员工的回答 | Agent（智能体）生成 | 是 | 必须基于 retrieved_sources |
| citations | 引用标题、片段、版本和更新时间 | 资料元数据 | 是 | 无引用时不能输出正式答案 |
| confidence_note | 可信度说明 | 检索质量和规则判断 | 是 | 冲突或不足时明确提示限制 |
| feedback_status | 员工反馈状态 | 员工操作或管理员处理 | 否 | 有误反馈进入资料负责人队列 |
| training_tags | 培训知识点标签 | 培训负责人或自动归类 | 内训场景建议必填 | 可用于复习、测评和学习路径 |
字段契约的价值，在于把“答案”拆成可以管理的企业资产。每一次回答都能说明：引用了什么资料、适用于谁、是否过期、谁能修正。
数据准备
企业知识库的数据准备决定了 RAG 项目能不能可靠落地。建议按下面顺序整理：
| 数据 | 准备方法 | 用途 | 风险控制 |
|---|---|---|---|
| 资料清单 | 列出文档名称、部门、负责人、版本、生效日期、更新时间 | 建立可维护知识资产 | 没有负责人的资料不要直接作为权威答案 |
| 权限范围 | 标注公开、部门内、项目内、管理层、敏感资料 | 检索前过滤 | 用户无权限时不能泄露标题和片段 |
| 切分规则 | 按条款、章节、问答、流程节点拆分 Chunk（分块） | 提升检索命中 | 切分过大难引用，过小易丢上下文 |
| 元数据 | 记录标题、来源、版本、适用对象、过期状态和负责人 | 引用、排序、过滤 | 过期资料只能提示，不作为正式答案 |
| 问题样例 | 收集员工常问、跨部门问题、新人培训问题和边界问题 | 评估检索和回答 | 高风险问题要包含拒答样例 |
| 反馈数据 | 记录点赞、纠错、人工改写、无法回答和资料缺口 | 持续修订 | 反馈必须进入负责人确认流程 |
数据准备完成后，要先做“资料可用性检查”：是否有重复冲突资料，是否知道最新版本，是否能判断用户权限，是否能在答案里引用来源。任何一项不清楚，都应该先治理资料，而不是急着扩展问答范围。
制作步骤
- 确定业务范围：先选一个高频且低到中风险的场景，例如报销制度问答、新员工入职问答、IT（信息技术）权限申请指南或产品培训问答。不要一开始就承诺覆盖全公司所有知识。
- 盘点资料质量：把资料分为正式制度、流程说明、培训资料、历史问答、参考材料和过期资料。没有负责人、没有版本、明显冲突的资料不要直接进入正式回答。
- 设计权限模型：明确用户身份、部门、岗位、项目和管理级别。敏感资料必须先过滤再检索，不能依赖模型自觉隐藏。
- 制定分块策略：制度类文档按条款和适用范围分块，流程类按步骤分块，培训类按知识点分块，研发类按模块、版本和问题类型分块。
- 建立检索链路：先用 Embedding（嵌入向量）召回相似片段，再用 Reranker（重排序器）挑出最相关、最适用、最新的资料。只相似不等于能用。
- 设计回答模板：回答应包含简明结论、适用范围、操作步骤、引用依据、注意事项和无法确认的部分。内训场景可以附带复习建议或延伸阅读。
- 加入拒答规则：无来源、无权限、资料冲突、问题超出范围、需要专业签字的情况必须拒答或转人工。拒答要说明原因，并给出下一步联系对象。
- 配置反馈闭环：员工可以标记答案有误、引用不准、资料过期或没有解决问题。反馈进入资料负责人处理，处理后重新索引并记录生效时间。
- 做样例验收：准备高频问题、边界问题、权限问题、过期资料问题和恶意试探问题，逐条检查回答是否有引用、是否拒绝越权、是否能追溯。
- 培训管理员：教客户如何新增资料、下线旧资料、处理反馈、查看常见问题和判断知识库是否需要扩展。