Ai native knowledge rag

AI Native RAG 与知识系统设计 Skill

使用场景

• 企业需要把私有知识接入 AI 产品
• 需要设计从"能搜出来"到"可被产品依赖"的知识系统
• 需要判断 RAG 的边界和局限，以及什么时候需要升级为完整知识系统

触发条件

当用户提到以下任一场景时触发：

• 需要把企业私有知识接入 AI 产品
• 设计 RAG 系统的分块、向量化、检索策略
• 评估知识系统的召回质量和幻觉率
• 从"能搜出来"升级到"可被产品依赖"的知识架构

执行步骤

1. 资料来源分析：盘点可用资料来源，评估可信等级、更新频率和接入优先级。
2. 清洗与脱敏：统一格式、脱敏敏感信息、结构化处理（分段/元数据/标签）、质量校验。
3. 索引与权限控制：设计向量索引（分块策略/嵌入模型）、关键词索引和元数据索引，建立角色权限矩阵。
4. 检索与召回策略：设计混合检索策略（语义+关键词+精排），确定召回数量和排序依据。
5. 评估与更新机制：建立召回质量评估体系、失败案例分析流程、自动/人工更新机制和反馈驱动的知识补充流程。
6. 输出知识系统方案：整合资料清单、清洗方案、索引设计、检索策略和评估机制，判断是否需要从 RAG 升级为完整知识系统。

核心概念

• RAG（Retrieval-Augmented Generation）：先检索相关材料，再把材料提供给模型生成回答的基础机制
• 知识系统：不仅能检索，还能处理清洗、结构化、权限、版本、更新和评估的完整系统
• Grounding：让回答建立在被检索到的真实资料之上，而不是只依赖模型记忆
• 知识新鲜度：资料是否仍然反映当前规则、流程和业务事实

RAG 与知识系统流程

资料来源
  → 清洗与脱敏
    → 索引与权限控制
      → 检索召回
        → 模型生成
          → 评估与更新

这条链里，任何一环失真，最终都会被用户感知为"AI 在胡说"。

RAG 解决什么问题

RAG 的基本逻辑是：先检索相关资料，再把结果提供给模型生成回答。它能有效解决"模型不知道企业私有信息"的问题。

RAG 之所以重要，不是因为它时髦，而是因为绝大多数企业 AI 产品都不可能只依赖模型内部知识。

RAG 的三个优势

1. 接入快：适合把已有文档快速转成可问答资产
2. 更新方便：知识变化时不必重新训练模型
3. 更容易回溯：系统可以说明它使用了哪些资料

RAG 的最大价值，是让企业知识第一次以相对低成本的方式进入模型工作链。

RAG 的边界

RAG 不是万能方案：

• 最擅长补充知识，不擅长替代推理、流程编排和任务执行
• 检索命中了资料，回答却仍然不可靠——问题可能出在任务理解、上下文拼装或行动链路
• RAG 只能解决"知道什么"，不能单独解决"该怎么做"

好的 RAG 至少还需要

真正可被产品依赖的 RAG，至少还需要满足：

1. 检索结果要相关：不是只在关键词层面"像相关"
2. 知识内容要足够新鲜：不能长期引用过期资料
3. 权限要清楚：不同角色不应看到同一批材料
4. 召回质量要可评估：而不是只靠体感判断

如果这几件事做不好，RAG 很容易变成一种"看上去增强了知识、实际上增强了噪音"的系统。

从 RAG 到知识系统

当产品开始涉及以下方面时，它就已经不是单纯的 RAG，而是在建设知识系统：

• 资料清洗与结构化
• 索引策略优化
• 权限控制
• 版本管理
• 召回质量评估
• 知识更新机制

知识系统至少应该回答

• 哪些资料是可信源
• 哪些资料应该被优先召回
• 知识变化后如何更新
• 哪些角色可以访问哪些知识
• 系统如何判断这次知识使用是否真的有效

知识系统设计原则

1. 可信源原则：明确哪些资料是权威来源，哪些是参考来源
2. 新鲜度原则：资料必须有更新机制，过期资料自动降级
3. 权限原则：不同角色看到不同的知识范围
4. 可评估原则：召回质量必须可量化评估
5. 可回溯原则：系统能说清楚回答基于哪些资料

输出物：知识系统方案

1. 资料来源清单：可用资料、可信源、更新频率
2. 清洗与脱敏方案：如何处理敏感信息、如何结构化
3. 索引与权限设计：如何索引、如何控制访问权限
4. 检索与召回策略：检索方法、召回数量、排序策略
5. 评估与更新机制：如何评估召回质量、如何更新知识

使用方式

当用户提供企业知识场景时，自动执行：

1. 分析资料来源和可用性
2. 设计清洗与脱敏方案
3. 设计索引与权限控制
4. 设计检索与召回策略
5. 设计评估与更新机制
6. 判断是否需要从 RAG 升级为完整知识系统
7. 输出知识系统方案

示例

示例：AI 客服知识系统设计

场景描述： 构建一个完整的客服知识系统，支持 FAQ、政策文档、案例的检索和使用。

用户输入： "我们的客服知识分散在 Confluence、内部Wiki、PDF文档里，想整合成AI可用的知识库"

Skill 执行流程：

1. 资料来源分析

来源	内容	更新频率	可信等级	接入优先级
售后政策文档	退款、退换货规则	每季度	高	P0
物流合作手册	各物流商政策	每月	高	P0
FAQ 文档	常见问题解答	每周	中	P1
客服案例库	历史工单处理记录	每日新增	中	P1
产品说明书	商品详细信息	每季更新	中	P2
促销活动规则	临时活动	实时	低	P2

2. 清洗与脱敏方案

清洗流程:
  Step1. 格式统一:
    - PDF → 文本提取
    - Confluence → API导出
    - 历史工单 → 结构化字段提取
    
  Step2. 敏感信息脱敏:
    - 手机号: 138****8888
    - 地址: XX省XX市XX区（只保留到区）
    - 真实姓名: 张**
    - 内部员工名: 保留职位，匿名姓名
    
  Step3. 结构化处理:
    - 自动分段：按主题/问题分段
    - 提取元数据：文档类型、更新日期、责任人
    - 打标签：售后/物流/产品/活动
    
  Step4. 质量校验:
    - 空内容检测
    - 重复内容去重
    - 过时内容标记（超过1年未更新）

3. 索引与权限控制

索引策略:
  
  向量索引:
    - 分块策略: 每块512 tokens，重叠50 tokens
    - 嵌入模型: text-embedding-3-large
    - 向量维度: 3072
    - 索引更新: 每日增量
    
  关键词索引:
    - 用于精确匹配（如订单号、商品ID）
    - Elasticsearch存储
    
  元数据索引:
    - 文档类型、更新时间、责任人
    - 用于过滤和排序

权限矩阵:
  
  角色1_普通客服:
    - 可检索: FAQ、物流政策、通用售后规则
    - 不可检索: 特殊审批流程、客户隐私案例
    
  角色2_客服主管:
    - 可检索: 全部公开文档 + 案例库
    - 不可检索: 系统配置、权限文档
    
  角色3_管理员:
    - 可检索: 全量文档
    - 可写: 知识库管理

4. 检索与召回策略

查询类型	检索策略	召回数量	排序依据
"如何退款"	语义检索+关键词	Top5	相关度+可信度
"订单12345"	关键词精确匹配	有限	时间倒序
"物流延误怎么办"	语义检索	Top3	相关度
"这个案例怎么处理"	案例库向量检索	Top3	相似度

混合检索策略:
  步骤1: 向量检索（语义匹配）→ Top10
  步骤2: 关键词过滤（精筛）→ Top10
  步骤3: 精排模型 → Top3-5
  步骤4: 权限过滤（按用户角色）
  
RAG增强:
  - 检索结果 + 重上下文 → LLM生成
  - 标注来源文档ID
  - 如果检索结果相关性<0.7，提示"知识库可能无相关信息"

5. 评估与更新机制

召回质量评估:
  
  每周抽样评估:
    - 随机抽取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 执行流程：

1. 资料来源分析

来源	内容类型	更新频率	可信等级	接入优先级
ADR 文档（Confluence）	架构决策记录	每月新增	高——权威来源	P0
故障复盘报告（飞书）	故障根因、修复方案	每次故障后	高——事后校验	P0
技术方案文档（Confluence）	系统设计方案	季度更新	高	P0
GitHub Wiki	组件使用说明	不定期	中——可能过时	P1
代码注释 / README	接口说明、配置指南	随代码变更	中	P1
飞书群聊记录	讨论片段、临时方案	实时	低——需提炼	P2

2. 清洗与脱敏方案

清洗流程:
  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个月未更新的文档降级
    - 重复检测: 同一主题多文档时保留可信等级最高的版本
    - 空白/模板文档过滤

3. 索引与权限控制

索引策略:
  向量索引:
    - 分块策略: 每块 512 tokens，重叠 80 tokens（技术文档逻辑连贯性要求高）
    - 嵌入模型: text-embedding-3-large
    - 按文档类型分区: adr / postmortem / tech-design / wiki / code

  关键词索引:
    - 服务名、组件名、错误码等精确匹配
    - Elasticsearch 存储

  元数据索引:
    - 文档类型、创建时间、最后更新时间、作者、关联服务

权限矩阵:
  角色1_初级研发:
    - 可检索: 公开技术方案、ADR、组件文档
    - 不可检索: 故障报告中的敏感根因、安全相关文档

  角色2_高级研发/TL:
    - 可检索: 全部技术文档 + 故障报告
    - 不可检索: 人力成本等管理类文档

  角色3_架构师/管理员:
    - 可检索: 全量文档
    - 可写: 知识库元数据管理、可信源配置

4. 检索与召回策略

混合检索策略:
  步骤1: 向量检索（语义匹配）→ Top10
  步骤2: 关键词过滤（服务名/组件名精确匹配）→ 补充召回
  步骤3: 精排模型（按相关度 + 可信等级 + 新鲜度加权）→ Top5
  步骤4: 权限过滤（按用户角色）

查询示例:
  "订单服务之前挂过几次，根因是什么":
    → 语义检索故障报告 → 按服务名过滤 → 时间倒序

  "为什么当初选了 Kafka 而不是 RabbitMQ":
    → 语义检索 ADR → 关键词匹配技术栈 → Top3

  "支付模块的限流配置怎么改":
    → 语义检索技术方案 + 代码 README → Top5

5. 评估与更新机制

召回质量评估:
  每周自动评估:
    - 从真实查询日志抽取 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 执行流程：

1. 资料来源分析

来源	内容类型	更新频率	可信等级	接入优先级
监管法规（银保监会/央行官网）	正式法规、通知	不定期（高频）	最高——权威来源	P0
内部合规手册	合规解读、操作指南	每季度	高——经法务审核	P0
审计报告	审计发现、整改要求	每年 + 专项	高	P1
监管问询答复	历史答复模板	每次问询后	高——经审批	P1
行业案例汇编	处罚案例、同业经验	每月更新	中——参考来源	P2
内部培训材料	合规培训课件	每季度	中	P2

2. 清洗与脱敏方案

清洗流程:
  Step1. 格式统一:
    - 监管法规 PDF → OCR + 文本提取 → 按条款分段
    - 合规手册 Word → 结构化提取 → 按章节分段
    - 审计报告 → 提取「发现-风险等级-整改建议」结构
    - 问询答复 → 提取「问题-答复-依据」三段式

  Step2. 敏感信息脱敏:
    - 客户名称/账户信息: 全量替换
    - 内部系统名称: 抽象化处理
    - 具体金额（涉及客户）: 脱敏

  Step3. 结构化处理:
    - 法规: 提取文号、发布日期、生效日期、适用范围
    - 审计报告: 提取审计期间、审计类型、风险等级
    - 自动打标签: 反洗钱/消费者保护/资本管理/信息披露/操作风险

  Step4. 质量校验:
    - 法规有效性校验: 是否已被废止或修订
    - 新旧版本比对: 标注修订内容
    - 冲突检测: 内部手册与最新法规是否一致

3. 索引与权限控制

索引策略:
  向量索引:
    - 分块策略: 按法规条款级别分块（平均 256 tokens），保留条款编号作为上下文
    - 嵌入模型: text-embedding-3-large（法律领域微调版本优先）
    - 按文档类型分区: regulation / manual / audit / case

  关键词索引:
    - 法规文号、条款号精确匹配
    - 关键合规术语（如"反洗钱""KYC""资本充足率"）

  元数据索引:
    - 文号、发布机构、生效日期、废止状态、适用业务线
    - 用于法规有效性和适用范围过滤

权限矩阵:
  角色1_业务人员:
    - 可检索: 合规操作指南、通用法规摘要、培训材料
    - 不可检索: 审计报告全文、监管问询答复、处罚案例细节

  角色2_合规专员:
    - 可检索: 全部法规 + 合规手册 + 审计报告 + 问询答复
    - 不可检索: 底稿、原始数据

  角色3_法务/合规总监:
    - 可检索: 全量文档
    - 可写: 合规解读、知识库管理

  角色4_审计人员:
    - 可检索: 全量只读
    - 特殊: 可查看历史版本和变更记录

4. 检索与召回策略

混合检索策略:
  步骤1: 向量检索 → Top10
  步骤2: 关键词过滤（法规文号/条款号精确匹配）→ 补充召回
  步骤3: 有效性过滤（排除已废止法规）
  步骤4: 精排（相关度 + 可信等级 + 生效日期加权）→ Top5
  步骤5: 权限过滤（按用户角色）

查询示例:
  "个人贷款的资金用途限制有哪些最新规定":
    → 语义检索法规 → 过滤已废止 → 按发布日期排序 → Top5
    → 每条结果标注: 法规名称、文号、条款号、生效日期

  "去年审计发现的反洗钱问题整改得怎么样了":
    → 语义检索审计报告 + 关键词"反洗钱" → 按审计时间排序
    → 关联检索整改记录

  "同业因为消费者保护被罚的案例有哪些":
    → 语义检索行业案例 → 标签过滤"消费者保护" → 按时间排序

5. 评估与更新机制

召回质量评估:
  每周抽样:
    - 抽取 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 范畴）