gabrielmoreira AI Native RAG 与知识系统设计 Skill
使用场景
- 企业需要把私有知识接入 AI 产品
- 需要设计从"能搜出来"到"可被产品依赖"的知识系统
- 需要判断 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 → 实时可用
人工维护:
- 每月清洗：移除过时文档
- 每季评估：文档质量评分
- 每年归档：历史文档迁移
反馈驱动:
- 客服标记"检索结果不准确" → 触发人工审核
- 高频未命中查询 → 补充相应知识
输出结果：
# 知识系统方案：AI 客服
资料整合:
来源数: 6类（Confluence、Wiki、PDF、案例库等）
总文档: ~2000篇
预计向量化后: ~50000 chunks
系统架构:
存储: Pinecone（向量）+ PostgreSQL（元数据）
检索: 混合检索（语义+关键词）
权限: RBAC（基于角色的访问控制）
更新: 自动同步（WebHook+定时任务）
质量保证:
- 召回准确率目标: >85%
- 信息新鲜度: 政策文档<1季度，FAQ<1周
- 敏感信息: 100%脱敏
- 权限合规: 不同角色看到不同内容
从RAG到知识系统:
✓ 资料清洗（不只是接入）
✓ 权限控制（不只是检索）
✓ 版本管理（文档更新追踪）
✓ 质量评估（不只是能用）
✓ 持续更新（不是一次性）
建议: 升级为完整知识系统（已超出简单RAG范畴）