AI Native RAG 与知识系统设计 Skill

使用场景

• 企业需要把私有知识接入 AI 产品
• 需要设计从"能搜出来"到"可被产品依赖"的知识系统
• 需要判断 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范畴）