| name | ai-native-knowledge-rag |
| description | AI Native 产品方法论——RAG与知识系统设计的实操 Skill。
用户提供企业知识场景，Skill 自动执行知识系统设计流程：
资料来源分析 → 清洗与脱敏 → 索引与权限控制 → 检索召回 → 评估与更新 → 输出知识系统方案。
基于《AI Native 产品方法论》第15章。
|
| tags | ["ai-product","methodology","rag","knowledge-system","retrieval","book-skill"] |
| author | Max |
| source_book | AI Native 产品方法论 |
| version | 1 |
AI Native RAG 与知识系统设计 Skill
使用场景
- 企业需要把私有知识接入 AI 产品
- 需要设计从"能搜出来"到"可被产品依赖"的知识系统
- 需要判断 RAG 的边界和局限，以及什么时候需要升级为完整知识系统
触发条件
当用户提到以下任一场景时触发：
- 需要把企业私有知识接入 AI 产品
- 设计 RAG 系统的分块、向量化、检索策略
- 评估知识系统的召回质量和幻觉率
- 从"能搜出来"升级到"可被产品依赖"的知识架构
执行步骤
- 资料来源分析：盘点可用资料来源，评估可信等级、更新频率和接入优先级。
- 清洗与脱敏：统一格式、脱敏敏感信息、结构化处理（分段/元数据/标签）、质量校验。
- 索引与权限控制：设计向量索引（分块策略/嵌入模型）、关键词索引和元数据索引，建立角色权限矩阵。
- 检索与召回策略：设计混合检索策略（语义+关键词+精排），确定召回数量和排序依据。
- 评估与更新机制：建立召回质量评估体系、失败案例分析流程、自动/人工更新机制和反馈驱动的知识补充流程。
- 输出知识系统方案：整合资料清单、清洗方案、索引设计、检索策略和评估机制，判断是否需要从 RAG 升级为完整知识系统。
核心概念
- RAG（Retrieval-Augmented Generation）：先检索相关材料，再把材料提供给模型生成回答的基础机制
- 知识系统：不仅能检索，还能处理清洗、结构化、权限、版本、更新和评估的完整系统
- Grounding：让回答建立在被检索到的真实资料之上，而不是只依赖模型记忆
- 知识新鲜度：资料是否仍然反映当前规则、流程和业务事实
RAG 与知识系统流程
资料来源
→ 清洗与脱敏
→ 索引与权限控制
→ 检索召回
→ 模型生成
→ 评估与更新
这条链里，任何一环失真，最终都会被用户感知为"AI 在胡说"。
RAG 解决什么问题
RAG 的基本逻辑是：先检索相关资料，再把结果提供给模型生成回答。它能有效解决"模型不知道企业私有信息"的问题。
RAG 之所以重要，不是因为它时髦，而是因为绝大多数企业 AI 产品都不可能只依赖模型内部知识。
RAG 的三个优势
- 接入快：适合把已有文档快速转成可问答资产
- 更新方便：知识变化时不必重新训练模型
- 更容易回溯：系统可以说明它使用了哪些资料
RAG 的最大价值，是让企业知识第一次以相对低成本的方式进入模型工作链。
RAG 的边界
RAG 不是万能方案：
- 最擅长补充知识，不擅长替代推理、流程编排和任务执行
- 检索命中了资料，回答却仍然不可靠——问题可能出在任务理解、上下文拼装或行动链路
- RAG 只能解决"知道什么"，不能单独解决"该怎么做"
好的 RAG 至少还需要
真正可被产品依赖的 RAG，至少还需要满足：
- 检索结果要相关：不是只在关键词层面"像相关"
- 知识内容要足够新鲜：不能长期引用过期资料
- 权限要清楚：不同角色不应看到同一批材料
- 召回质量要可评估：而不是只靠体感判断
如果这几件事做不好，RAG 很容易变成一种"看上去增强了知识、实际上增强了噪音"的系统。
从 RAG 到知识系统
当产品开始涉及以下方面时，它就已经不是单纯的 RAG，而是在建设知识系统：
- 资料清洗与结构化
- 索引策略优化
- 权限控制
- 版本管理
- 召回质量评估
- 知识更新机制
知识系统至少应该回答
- 哪些资料是可信源
- 哪些资料应该被优先召回
- 知识变化后如何更新
- 哪些角色可以访问哪些知识
- 系统如何判断这次知识使用是否真的有效
知识系统设计原则
- 可信源原则：明确哪些资料是权威来源，哪些是参考来源
- 新鲜度原则：资料必须有更新机制，过期资料自动降级
- 权限原则：不同角色看到不同的知识范围
- 可评估原则：召回质量必须可量化评估
- 可回溯原则：系统能说清楚回答基于哪些资料
输出物：知识系统方案
- 资料来源清单：可用资料、可信源、更新频率
- 清洗与脱敏方案：如何处理敏感信息、如何结构化
- 索引与权限设计：如何索引、如何控制访问权限
- 检索与召回策略：检索方法、召回数量、排序策略
- 评估与更新机制：如何评估召回质量、如何更新知识
使用方式
当用户提供企业知识场景时，自动执行：
- 分析资料来源和可用性
- 设计清洗与脱敏方案
- 设计索引与权限控制
- 设计检索与召回策略
- 设计评估与更新机制
- 判断是否需要从 RAG 升级为完整知识系统
- 输出知识系统方案
示例
示例：AI 客服知识系统设计
场景描述：
构建一个完整的客服知识系统，支持 FAQ、政策文档、案例的检索和使用。
用户输入：
"我们的客服知识分散在 Confluence、内部Wiki、PDF文档里，想整合成AI可用的知识库"
Skill 执行流程：
- 资料来源分析
| 来源 | 内容 | 更新频率 | 可信等级 | 接入优先级 |
|---|
| 售后政策文档 | 退款、退换货规则 | 每季度 | 高 | P0 |
| 物流合作手册 | 各物流商政策 | 每月 | 高 | P0 |
| FAQ 文档 | 常见问题解答 | 每周 | 中 | P1 |
| 客服案例库 | 历史工单处理记录 | 每日新增 | 中 | P1 |
| 产品说明书 | 商品详细信息 | 每季更新 | 中 | P2 |
| 促销活动规则 | 临时活动 | 实时 | 低 | P2 |
- 清洗与脱敏方案
清洗流程:
Step1. 格式统一:
- PDF → 文本提取
- Confluence → API导出
- 历史工单 → 结构化字段提取
Step2. 敏感信息脱敏:
- 手机号: 138****8888
- 地址: XX省XX市XX区（只保留到区）
- 真实姓名: 张**
- 内部员工名: 保留职位，匿名姓名
Step3. 结构化处理:
- 自动分段：按主题/问题分段
- 提取元数据：文档类型、更新日期、责任人
- 打标签：售后/物流/产品/活动
Step4. 质量校验:
- 空内容检测
- 重复内容去重
- 过时内容标记（超过1年未更新）
- 索引与权限控制
索引策略:
向量索引:
- 分块策略: 每块512 tokens，重叠50 tokens
- 嵌入模型: text-embedding-3-large
- 向量维度: 3072
- 索引更新: 每日增量
关键词索引:
- 用于精确匹配（如订单号、商品ID）
- Elasticsearch存储
元数据索引:
- 文档类型、更新时间、责任人
- 用于过滤和排序
权限矩阵:
角色1_普通客服:
- 可检索: FAQ、物流政策、通用售后规则
- 不可检索: 特殊审批流程、客户隐私案例
角色2_客服主管:
- 可检索: 全部公开文档 + 案例库
- 不可检索: 系统配置、权限文档
角色3_管理员:
- 可检索: 全量文档
- 可写: 知识库管理
- 检索与召回策略
| 查询类型 | 检索策略 | 召回数量 | 排序依据 |
|---|
| "如何退款" | 语义检索+关键词 | Top5 | 相关度+可信度 |
| "订单12345" | 关键词精确匹配 | 有限 | 时间倒序 |
| "物流延误怎么办" | 语义检索 | Top3 | 相关度 |
| "这个案例怎么处理" | 案例库向量检索 | Top3 | 相似度 |
混合检索策略:
步骤1: 向量检索（语义匹配）→ Top10
步骤2: 关键词过滤（精筛）→ Top10
步骤3: 精排模型 → Top3-5
步骤4: 权限过滤（按用户角色）
RAG增强:
- 检索结果 + 重上下文 → LLM生成
- 标注来源文档ID
- 如果检索结果相关性<0.7，提示"知识库可能无相关信息"
- 评估与更新机制
召回质量评估:
每周抽样评估:
- 随机抽取100个真实查询
- 人工评分：相关度1-5分
- 计算平均召回分
- 目标：平均分>4.0
失败案例分析:
- "未找到相关信息"的查询
- 检索到但未被采纳的结果
- 知识已更新但检索结果仍显示旧版本
更新机制:
自动更新:
- 源文档变更 → 自动触发重新索引（24小时内）
- 新增FAQ → 实时可用
人工维护:
- 每月清洗：移除过时文档
- 每季评估：文档质量评分
- 每年归档：历史文档迁移
反馈驱动:
- 客服标记"检索结果不准确" → 触发人工审核
- 高频未命中查询 → 补充相应知识
输出结果：
资料整合:
来源数: 6类（Confluence、Wiki、PDF、案例库等）
总文档: ~2000篇
预计向量化后: ~50000 chunks
系统架构:
存储: Pinecone（向量）+ PostgreSQL（元数据）
检索: 混合检索（语义+关键词）
权限: RBAC（基于角色的访问控制）
更新: 自动同步（WebHook+定时任务）
质量保证:
- 召回准确率目标: >85%
- 信息新鲜度: 政策文档<1季度，FAQ<1周
- 敏感信息: 100%脱敏
- 权限合规: 不同角色看到不同内容
从RAG到知识系统:
✓ 资料清洗（不只是接入）
✓ 权限控制（不只是检索）
✓ 版本管理（文档更新追踪）
✓ 质量评估（不只是能用）
✓ 持续更新（不是一次性）
建议: 升级为完整知识系统（已超出简单RAG范畴）
示例：企业内部研发知识库构建
场景描述：
一家中型 SaaS 公司的研发团队需要构建内部技术知识库，将散落在 Confluence、GitHub Wiki、飞书文档和代码注释中的技术方案、架构决策记录（ADR）、故障复盘报告整合为 AI 可检索的知识系统，支持研发人员快速查询历史技术决策和故障处理经验。
用户输入：
"我们研发团队有大量技术文档分散在 Confluence、GitHub Wiki 和飞书里，每次查历史故障或架构决策都要翻好几个地方。想做一个内部知识助手，但不确定该从哪开始、怎么保证检索出来的内容是最新可信的。"
Skill 执行流程：
- 资料来源分析
| 来源 | 内容类型 | 更新频率 | 可信等级 | 接入优先级 |
|---|
| ADR 文档（Confluence） | 架构决策记录 | 每月新增 | 高——权威来源 | P0 |
| 故障复盘报告（飞书） | 故障根因、修复方案 | 每次故障后 | 高——事后校验 | P0 |
| 技术方案文档（Confluence） | 系统设计方案 | 季度更新 | 高 | P0 |
| GitHub Wiki | 组件使用说明 | 不定期 | 中——可能过时 | P1 |
| 代码注释 / README | 接口说明、配置指南 | 随代码变更 | 中 | P1 |
| 飞书群聊记录 | 讨论片段、临时方案 | 实时 | 低——需提炼 | P2 |
- 清洗与脱敏方案
清洗流程:
Step1. 格式统一:
- Confluence → REST API 导出 HTML → Markdown
- GitHub Wiki → Git clone → Markdown
- 飞书文档 → API 导出 → Markdown
- 代码注释 / README → 直接读取
- 飞书群聊 → 过滤机器人消息、合并同一话题线程
Step2. 敏感信息脱敏:
- 内部域名/IP: 替换为 <internal-host>
- 密钥/Token: 全量移除
- 客户名称: 替换为客户A/B/C
- 员工工号/手机号: 匿名化
Step3. 结构化处理:
- ADR: 提取「背景-决策-后果」三段式元数据
- 故障报告: 提取「时间线-根因-修复-预防」结构
- 自动打标签: 架构/故障/运维/安全/性能
Step4. 质量校验:
- 过时标记: 超过18个月未更新的文档降级
- 重复检测: 同一主题多文档时保留可信等级最高的版本
- 空白/模板文档过滤
- 索引与权限控制
索引策略:
向量索引:
- 分块策略: 每块 512 tokens，重叠 80 tokens（技术文档逻辑连贯性要求高）
- 嵌入模型: text-embedding-3-large
- 按文档类型分区: adr / postmortem / tech-design / wiki / code
关键词索引:
- 服务名、组件名、错误码等精确匹配
- Elasticsearch 存储
元数据索引:
- 文档类型、创建时间、最后更新时间、作者、关联服务
权限矩阵:
角色1_初级研发:
- 可检索: 公开技术方案、ADR、组件文档
- 不可检索: 故障报告中的敏感根因、安全相关文档
角色2_高级研发/TL:
- 可检索: 全部技术文档 + 故障报告
- 不可检索: 人力成本等管理类文档
角色3_架构师/管理员:
- 可检索: 全量文档
- 可写: 知识库元数据管理、可信源配置
- 检索与召回策略
混合检索策略:
步骤1: 向量检索（语义匹配）→ Top10
步骤2: 关键词过滤（服务名/组件名精确匹配）→ 补充召回
步骤3: 精排模型（按相关度 + 可信等级 + 新鲜度加权）→ Top5
步骤4: 权限过滤（按用户角色）
查询示例:
"订单服务之前挂过几次，根因是什么":
→ 语义检索故障报告 → 按服务名过滤 → 时间倒序
"为什么当初选了 Kafka 而不是 RabbitMQ":
→ 语义检索 ADR → 关键词匹配技术栈 → Top3
"支付模块的限流配置怎么改":
→ 语义检索技术方案 + 代码 README → Top5
- 评估与更新机制
召回质量评估:
每周自动评估:
- 从真实查询日志抽取 50 条
- 研发人员标记「有用/部分有用/无用」
- 目标: 有用率 > 80%
失败案例分析:
- 查询命中但内容过时 → 触发文档新鲜度检查
- 查询未命中但知识确实存在 → 优化分块或嵌入策略
- 同一问题反复查询 → 标记为需要补充知识条目
更新机制:
自动:
- Confluence 文档变更 Webhook → 24小时内重新索引
- GitHub Wiki push → 触发增量索引
人工:
- 每季度: 整体文档质量审核
- 故障发生后: 72小时内复盘报告必须入库
输出结果：
资料整合:
来源数: 6类（ADR、故障报告、技术方案、Wiki、代码文档、群聊提炼）
总文档: ~3500篇
预计向量化后: ~80000 chunks
系统架构:
存储: Milvus（向量）+ PostgreSQL（元数据）+ Elasticsearch（关键词）
检索: 混合检索（语义 + 关键词 + 精排）
权限: RBAC（基于角色）
更新: Webhook 驱动 + 定时全量校验
质量保证:
- 召回有用率目标: >80%
- 信息新鲜度: ADR/故障报告 < 1季度，组件文档 < 6个月
- 敏感信息: 100%脱敏（密钥、内部域名、客户信息）
- 权限合规: 初级研发不可见安全文档和敏感故障根因
从RAG到知识系统:
✓ 资料清洗（多源格式统一 + 结构化提取）
✓ 权限控制（按研发角色分级）
✓ 版本管理（ADR 决策追踪、文档过时降级）
✓ 质量评估（周度自动抽样 + 失败案例分析）
✓ 持续更新（Webhook 驱动增量索引）
建议: 升级为完整知识系统（涉及清洗、权限、版本、评估全链路）
示例：多源合规文档检索系统
场景描述：
一家金融科技公司需要构建合规知识检索系统，将监管法规、内部合规手册、审计报告和监管问询答复等多源文档整合起来，供合规团队、业务团队和法务团队按权限检索。核心挑战是：法规更新频繁、不同岗位权限差异大、回答必须可回溯到原始法规条文。
用户输入：
"我们合规部门每天要查大量监管文件，包括银保监会发文、内部合规手册和审计报告。这些文档分散在不同系统里，而且监管规则经常更新。希望能做一个合规知识助手，不同角色看到的内容不一样，回答必须标注出处。"
Skill 执行流程：
- 资料来源分析
| 来源 | 内容类型 | 更新频率 | 可信等级 | 接入优先级 |
|---|
| 监管法规（银保监会/央行官网） | 正式法规、通知 | 不定期（高频） | 最高——权威来源 | P0 |
| 内部合规手册 | 合规解读、操作指南 | 每季度 | 高——经法务审核 | P0 |
| 审计报告 | 审计发现、整改要求 | 每年 + 专项 | 高 | P1 |
| 监管问询答复 | 历史答复模板 | 每次问询后 | 高——经审批 | P1 |
| 行业案例汇编 | 处罚案例、同业经验 | 每月更新 | 中——参考来源 | P2 |
| 内部培训材料 | 合规培训课件 | 每季度 | 中 | P2 |
- 清洗与脱敏方案
清洗流程:
Step1. 格式统一:
- 监管法规 PDF → OCR + 文本提取 → 按条款分段
- 合规手册 Word → 结构化提取 → 按章节分段
- 审计报告 → 提取「发现-风险等级-整改建议」结构
- 问询答复 → 提取「问题-答复-依据」三段式
Step2. 敏感信息脱敏:
- 客户名称/账户信息: 全量替换
- 内部系统名称: 抽象化处理
- 具体金额（涉及客户）: 脱敏
Step3. 结构化处理:
- 法规: 提取文号、发布日期、生效日期、适用范围
- 审计报告: 提取审计期间、审计类型、风险等级
- 自动打标签: 反洗钱/消费者保护/资本管理/信息披露/操作风险
Step4. 质量校验:
- 法规有效性校验: 是否已被废止或修订
- 新旧版本比对: 标注修订内容
- 冲突检测: 内部手册与最新法规是否一致
- 索引与权限控制
索引策略:
向量索引:
- 分块策略: 按法规条款级别分块（平均 256 tokens），保留条款编号作为上下文
- 嵌入模型: text-embedding-3-large（法律领域微调版本优先）
- 按文档类型分区: regulation / manual / audit / case
关键词索引:
- 法规文号、条款号精确匹配
- 关键合规术语（如"反洗钱""KYC""资本充足率"）
元数据索引:
- 文号、发布机构、生效日期、废止状态、适用业务线
- 用于法规有效性和适用范围过滤
权限矩阵:
角色1_业务人员:
- 可检索: 合规操作指南、通用法规摘要、培训材料
- 不可检索: 审计报告全文、监管问询答复、处罚案例细节
角色2_合规专员:
- 可检索: 全部法规 + 合规手册 + 审计报告 + 问询答复
- 不可检索: 底稿、原始数据
角色3_法务/合规总监:
- 可检索: 全量文档
- 可写: 合规解读、知识库管理
角色4_审计人员:
- 可检索: 全量只读
- 特殊: 可查看历史版本和变更记录
- 检索与召回策略
混合检索策略:
步骤1: 向量检索 → Top10
步骤2: 关键词过滤（法规文号/条款号精确匹配）→ 补充召回
步骤3: 有效性过滤（排除已废止法规）
步骤4: 精排（相关度 + 可信等级 + 生效日期加权）→ Top5
步骤5: 权限过滤（按用户角色）
查询示例:
"个人贷款的资金用途限制有哪些最新规定":
→ 语义检索法规 → 过滤已废止 → 按发布日期排序 → Top5
→ 每条结果标注: 法规名称、文号、条款号、生效日期
"去年审计发现的反洗钱问题整改得怎么样了":
→ 语义检索审计报告 + 关键词"反洗钱" → 按审计时间排序
→ 关联检索整改记录
"同业因为消费者保护被罚的案例有哪些":
→ 语义检索行业案例 → 标签过滤"消费者保护" → 按时间排序
- 评估与更新机制
召回质量评估:
每周抽样:
- 抽取 80 条真实合规查询
- 合规专员评分: 法规引用是否准确（1-5分）
- 重点评估: 法规有效性（是否引用了已废止法规）
- 目标: 引用准确率 > 95%，废止法规命中率 < 1%
失败案例分析:
- 引用了已废止法规 → 优化有效性过滤逻辑
- 检索到了法规但未找到具体条款 → 优化分块粒度
- 业务人员查询未命中 → 补充合规解读文档
更新机制:
自动:
- 监管官网爬虫 → 新法规发布 4 小时内入库
- 法规废止/修订 → 自动标记旧版本 + 触发手册一致性检查
人工:
- 法务团队: 新法规发布后 48 小时内完成合规解读
- 每季度: 内部合规手册与最新法规交叉校验
- 审计报告: 审计结束后 1 周内入库
输出结果：
资料整合:
来源数: 6类（监管法规、合规手册、审计报告、问询答复、案例、培训材料）
总文档: ~12000篇（含历史法规版本）
活跃文档: ~4500篇（排除已废止）
预计向量化后: ~120000 chunks
系统架构:
存储: Milvus（向量）+ PostgreSQL（元数据 + 版本链）+ Elasticsearch（关键词）
检索: 混合检索（语义 + 关键词 + 有效性过滤 + 精排）
权限: RBAC + ABAC（基于角色 + 基于文档属性）
更新: 监管爬虫 + 法务人工审核双通道
质量保证:
- 法规引用准确率目标: >95%
- 废止法规命中率: <1%
- 信息新鲜度: 监管法规 < 4小时，合规手册 < 48小时
- 权限合规: 业务人员不可见审计报告和问询答复
- 可回溯性: 100%回答标注法规名称、文号和条款号
从RAG到知识系统:
✓ 资料清洗（法规条款级结构化 + 有效性校验）
✓ 权限控制（四级角色 + 文档属性双重过滤）
✓ 版本管理（法规修订链 + 废止标记 + 历史版本可查）
✓ 质量评估（引用准确率 + 废止过滤率双重指标）
✓ 持续更新（监管爬虫实时抓取 + 法务人工解读）
✓ 与其他系统联动（上下文工程 + 记忆系统）
建议: 升级为完整知识系统（合规场景对准确性、时效性和可回溯性要求极高，远超简单 RAG 范畴）
