# P7 Knowledge RAG

> AI Native RAG 与知识系统设计 Skill

- Skill: `gabrielmoreira/p7-knowledge-rag` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gabrielmoreira/p7-knowledge-rag`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/p7-knowledge-rag/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/gabrielmoreira/p7-knowledge-rag

---



# 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. **清洗与脱敏方案**

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

3. **索引与权限控制**

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

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

4. **检索与召回策略**

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

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

5. **评估与更新机制**

```yaml
召回质量评估:
  
  每周抽样评估:
    - 随机抽取100个真实查询
    - 人工评分：相关度1-5分
    - 计算平均召回分
    - 目标：平均分>4.0
    
  失败案例分析:
    - "未找到相关信息"的查询
    - 检索到但未被采纳的结果
    - 知识已更新但检索结果仍显示旧版本

更新机制:
  
  自动更新:
    - 源文档变更 → 自动触发重新索引（24小时内）
    - 新增FAQ → 实时可用
    
  人工维护:
    - 每月清洗：移除过时文档
    - 每季评估：文档质量评分
    - 每年归档：历史文档迁移
    
  反馈驱动:
    - 客服标记"检索结果不准确" → 触发人工审核
    - 高频未命中查询 → 补充相应知识
```

**输出结果**：

```yaml
# 知识系统方案：AI 客服

资料整合:
  来源数: 6类（Confluence、Wiki、PDF、案例库等）
  总文档: ~2000篇
  预计向量化后: ~50000 chunks

系统架构:
  存储: Pinecone（向量）+ PostgreSQL（元数据）
  检索: 混合检索（语义+关键词）
  权限: RBAC（基于角色的访问控制）
  更新: 自动同步（WebHook+定时任务）

质量保证:
  - 召回准确率目标: >85%
  - 信息新鲜度: 政策文档<1季度，FAQ<1周
  - 敏感信息: 100%脱敏
  - 权限合规: 不同角色看到不同内容

从RAG到知识系统:
  ✓ 资料清洗（不只是接入）
  ✓ 权限控制（不只是检索）
  ✓ 版本管理（文档更新追踪）
  ✓ 质量评估（不只是能用）
  ✓ 持续更新（不是一次性）

建议: 升级为完整知识系统（已超出简单RAG范畴）
```