// AI Native 产品方法论——RAG与知识系统设计的实操 Skill。 用户提供企业知识场景，Skill 自动执行知识系统设计流程： 资料来源分析 → 清洗与脱敏 → 索引与权限控制 → 检索召回 → 评估与更新 → 输出知识系统方案。 基于《AI Native 产品方法论》第15章。
[HINT] Download the complete skill directory including SKILL.md and all related files
| 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 在胡说"。
RAG 的基本逻辑是：先检索相关资料，再把结果提供给模型生成回答。它能有效解决"模型不知道企业私有信息"的问题。
RAG 之所以重要，不是因为它时髦，而是因为绝大多数企业 AI 产品都不可能只依赖模型内部知识。
RAG 的最大价值，是让企业知识第一次以相对低成本的方式进入模型工作链。
RAG 不是万能方案：
真正可被产品依赖的 RAG，至少还需要满足：
如果这几件事做不好，RAG 很容易变成一种"看上去增强了知识、实际上增强了噪音"的系统。
当产品开始涉及以下方面时，它就已经不是单纯的 RAG，而是在建设知识系统：
当用户提供企业知识场景时，自动执行：
场景描述： 构建一个完整的客服知识系统，支持 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 → 实时可用
人工维护:
- 每月清洗：移除过时文档
- 每季评估：文档质量评分
- 每年归档：历史文档迁移
反馈驱动:
- 客服标记"检索结果不准确" → 触发人工审核
- 高频未命中查询 → 补充相应知识
输出结果：
# 知识系统方案：AI 客服
资料整合:
来源数: 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 范畴）