Knowledge Base Manager

知识库管理器

为 AI 系统和人类用户构建并维护高质量的知识库。

核心原则

知识库 = 结构化信息 + 高质量整理 + 易于访问

知识库不只是数据堆积，而是经过整理、验证和版本管理的信息，旨在回答问题并支持推理。

---

何时使用知识库

适合使用知识库的场景：

• ✅ 需要始终如一地回答事实性问题
• ✅ 信息经常变化，需要进行版本控制
• ✅ 需要统一并协调多个来源
• ✅ 来源溯源和引用追踪至关重要
• ✅ 构建需要可靠、可验证信息的 AI 系统
• ✅ 需要留存组织知识并使其可搜索
• ✅ 领域复杂，概念之间相互关联

不适合使用知识库的场景：

• ❌ 静态文档已经足够（使用文档 + 搜索）
• ❌ 没有人会维护或更新（知识必然会过时）
• ❌ 简单的 FAQ 能涵盖所有问题（少于 50 项）
• ❌ 信息不会变化（静态网站更快、更省钱）
• ❌ 团队缺乏整理资源

---

知识库类型：决策框架

1. 基于文档的知识库（RAG）

定义： 文档集合，经过分块和嵌入，可用于语义搜索

最适合：

• 技术文档
• 支持文章、常见问题
• 政策文档
• 研究论文
• 博客内容
• 用户手册

优势：

• 易于添加新文档
• 保留完整上下文
• 适用于以文本为主的内容

劣势：

• 难以查询关系（“谁在哪里工作？”）
• 多份文档中存在重复信息
• 难以保持事实一致

使用： rag-implementer skill + vector-database-mcp

---

2. 基于实体的知识库（知识图谱）

定义： 由实体（人物、地点、事物）及其关系构成的网络

最适合：

• 组织架构图
• 包含关联关系的产品目录
• 社交网络
• 推荐系统
• 欺诈检测
• 供应链跟踪

优势：

• 擅长回答“X 和 Y 有什么关系？”这类问题
• 事实一致（单一事实来源）
• 强大的关系遍历能力（“朋友的朋友”）

劣势：

• 需要预先建模（设计本体）
• 难以添加非结构化信息
• 需要学习图查询

使用： knowledge-graph-builder skill + graph-database-mcp

---

3. 混合知识库（RAG + 图谱）

定义： 使用文档存储非结构化知识，使用图谱存储结构化实体和关系

最适合：

• 企业知识管理
• 包含引用和关系的研究
• 医疗系统（文档 + 患者/药物关系）
• 法律系统（案例 + 判例 + 实体）
• 电子商务（产品 + 规格 + 关系）

优势：

• 兼具两者之长
• 灵活适应不同类型的知识
• 查询能力丰富

劣势：

• 构建和维护最复杂
• 需要同时具备 RAG 和图谱方面的专业知识
• 基础设施成本更高

使用： rag-implementer + knowledge-graph-builder 两种 skill

---

决策树：选择哪种知识库类型？

What kind of knowledge do you have?

├─ Mostly unstructured text (docs, articles, content)?
│  └─ Document-Based KB (RAG)
│     Use: rag-implementer skill
│
├─ Mostly structured entities with relationships?
│  └─ Entity-Based KB (Graph)
│     Use: knowledge-graph-builder skill
│
└─ Mix of both?
   └─ Hybrid KB (RAG + Graph)
      Use: Both skills + This skill for integration

---

知识库实施的 6 个阶段

第 1 阶段：知识审计与架构设计

目标：了解现有知识及其组织方式

操作：

1. 盘点现有知识来源

   • 内部：数据库、文档、维基、Slack、电子邮件
   • 外部：公共数据、API、第三方来源
   • 隐性知识：SME 访谈、录制的对话

2. 对知识类型进行分类

   • 事实型：可验证的事实（“产品 X 售价 50 美元”）
   • 流程型：操作方法（“如何部署”）
   • 概念型：定义与说明
   • 关系型：实体之间的联系

3. 选择知识库架构

   • 基于文档？基于实体？混合型？
   • 决策：使用上述框架

4. 定义知识模式

   • 对于文档：元数据字段（来源、日期、作者、类别）
   • 对于实体：本体（实体类型、关系类型、属性）

验证：

• 已盘点所有知识来源并确定优先级
• 已选择知识库架构并说明理由
• 已定义模式并与用户验证
• 已制定成功指标

---

第 2 阶段：知识整理与摄取

目标：将原始信息转化为高质量知识

操作：

1. 从来源中提取知识

   • 自动化：抓取、API 摄取、文件解析
   • 手动：专家输入、标注、验证

2. 清理并规范化

   • 删除重复内容
   • 统一格式
   • 修正不一致之处
   • 补充元数据

3. 构建知识结构

   • 对于文档：智能分块（按语义边界）
   • 对于实体：提取实体、关系和属性

4. 添加来源信息

   • 来源 URL 或参考资料
   • 上次更新时间戳
   • 作者/贡献者
   • 置信度分数（如适用）

整理最佳实践：

• 单一可信来源：每个问题只有一个权威答案
• 去重：合并相似的知识条目
• 冲突解决：来源之间存在分歧时，制定优先级规则
• 丰富元数据：元数据越丰富，筛选和搜索效果越好

验证：

• 已提取知识并构建结构
• 质量指标达到阈值（准确率 >95%）
• 已为所有条目追踪来源信息
• 示例查询能返回相关结果

---

第 3 阶段：存储与检索设置

目标：搭建用于访问知识的技术基础设施

架构模式：

对于基于文档的知识库：

// Vector database for semantic search
interface DocumentKB {
  store: 'Pinecone' | 'Weaviate' | 'pgvector'
  chunks: {
    content: string
    embedding: number[]
    metadata: {
      source: string
      title: string
      updated_at: string
      category: string
    }
  }[]
}

对于基于实体的知识库：

// Graph database for relationship queries
interface EntityKB {
  store: 'Neo4j' | 'ArangoDB'
  nodes: {
    id: string
    type: 'Person' | 'Organization' | 'Product' | 'Concept'
    properties: Record<string, any>
  }[]
  relationships: {
    from: string
    to: string
    type: string
    properties: Record<string, any>
  }[]
}

对于混合型知识库：

// Both vector DB + graph DB
interface HybridKB {
  vectorDB: DocumentKB
  graphDB: EntityKB
  linker: {
    // Links documents to entities mentioned in them
    linkDocumentToEntities(docId: string): string[]
    // Links entities to documents that mention them
    linkEntityToDocuments(entityId: string): string[]
  }
}

操作：

1. 选择数据库

   • 文档：Pinecone、Weaviate、pgvector
   • 实体：Neo4j、ArangoDB
   • 混合型：两者加链接层

2. 实现搜索/查询层

   • 向量相似度搜索（用于文档）
   • 图遍历（用于实体）
   • 混合查询（结合两者）

3. 添加缓存并进行优化

   • 缓存常用查询
   • 针对常见访问模式进行优化

验证：

• 数据库已部署且可访问
• 搜索/查询功能正常运行
• 性能符合要求（大多数查询耗时 <100ms）

---

阶段 4：质量控制与验证

目标：确保知识库的准确性和可靠性

质量指标：

1. 准确率：测试问题中答案正确的比例
2. 覆盖率：可回答的用户问题比例
3. 新鲜度：知识的平均时长
4. 一致性：冲突／矛盾所占的比例
5. 来源质量：来自权威来源的比例

验证策略：

1. 测试问题集 创建 100 个以上已知正确答案的测试问题：

interface TestQuestion {
  question: string
  expected_answer: string
  category: string
  difficulty: 'easy' | 'medium' | 'hard'
}

2. 人工审核

• 随机抽取知识条目
• 由主题专家进行验证
• 建立用户反馈闭环

3. 自动化检查

• 重复检测：查找近乎相同的条目
• 冲突检测：查找相互矛盾的事实
• 过时检测：标记过时信息
• 引用验证：确认来源仍然存在

4. 持续监控

interface KBHealthMetrics {
  accuracy_score: number // 0-100
  coverage_score: number // % questions answered
  freshness_score: number // avg days since update
  consistency_score: number // % no conflicts
  user_satisfaction: number // feedback rating
}

行动：

1. 运行测试问题验证（目标：准确率 >90%）
2. 开展人工审核（抽查 10% 的条目）
3. 修复检测到的问题（重复、冲突、过时）
4. 建立监控仪表板

验证：

• 测试问题准确率 >90%
• 覆盖 >80% 的用户问题
• 冲突信息 <5%
• 监控仪表板正常运行

---

阶段 5：版本控制与演进

目标：跟踪知识随时间的变化，并支持回滚

版本控制的重要性：

• 知识会变化（事实更新、政策变更）
• 需要审计记录（谁在何时更改了什么）
• 支持回滚（撤销不良更新）
• 支持历史查询（“2023 年关于 X 的政策是什么？”）

版本控制策略：

1. 快照版本控制

interface KnowledgeEntry {
  id: string
  content: string
  version: number
  created_at: string
  updated_at: string
  updated_by: string
  changelog: string
  previous_version?: string // ID of prior version
}

2. 事件溯源

interface KnowledgeEvent {
  event_id: string
  entity_id: string
  event_type: 'created' | 'updated' | 'deleted'
  timestamp: string
  changes: {
    field: string
    old_value: any
    new_value: any
  }[]
  author: string
}

3. Git 风格的版本控制

• 将知识视为代码
• 基于提交进行更改
• 为实验性知识创建分支
• 验证后再合并

行动：

1. 实现版本跟踪
2. 为所有更新添加变更日志
3. 创建回滚机制
4. 构建版本比较工具

验证：

• 所有更改均有版本记录
• 回滚经过测试且正常运行
• 支持历史查询
• 审计记录完整

---

阶段 6：维护与治理

目标：长期保持知识库健康

维护任务：

每日：

• 监控错误和故障
• 查看用户反馈
• 处理紧急更正

每周：

• 审核新内容提交
• 更新时效性知识
• 运行自动化质量检查

每月：

• 审核知识新鲜度
• 查看并解决冲突
• 分析使用模式
• 更新过时内容

每季度：

• 全面质量审计
• 审查架构／本体
• 优化性能
• 开展用户满意度调查

治理框架：

1. 角色与职责

• 知识所有者：负责内容的领域专家
• 策展人：审核并批准更改
• 贡献者：提交新知识
• 使用者：使用知识并提供反馈

2. 变更流程

Submit → Review → Approve → Publish → Monitor

3. 质量标准

• 最低来源质量要求
• 引用要求
• 更新频率要求
• 冲突解决流程

行动：

1. 制定维护计划
2. 明确分配角色与职责
3. 编写治理文档
4. 培训团队掌握相关流程

验证：

• 已制定维护计划
• 治理规范已记录并传达
• 团队已接受流程培训
• 质量持续提升

---

知识库反模式

❌ 反模式 1：未经整理就倾倒数据

问题：不进行质量筛选，将所有内容一股脑导入

影响：信噪比低、搜索结果差、用户体验不佳

解决方案：导入前先整理。质量胜于数量

---

❌ 反模式 2：没有版本控制

问题：知识发生变化，但没有跟踪历史记录

影响：无法审计更改、无法回滚错误、无人负责

解决方案：从阶段 5 开始实施版本控制

---

❌ 反模式 3：知识陈旧

问题：知识库已过时，但无人知晓

影响：AI 系统使用旧事实生成幻觉，用户得到错误答案

解决方案：监控内容新鲜度 + 定期更新

---

❌ 反模式 4：信息重复

问题：同一事实出现在多个地方，导致内容不一致

影响：答案相互矛盾，用户感到困惑

解决方案：去重 + 建立唯一可信来源

---

❌ 反模式 5：没有来源信息

问题：知识缺少来源引用

影响：无法验证准确性，也无法追溯错误

解决方案：始终记录来源 + 时间戳 + 作者

---

与其他技能集成

与 rag-implementer 配合

• 用于混合知识库中基于文档的部分
• 遵循 RAG 实施阶段
• 将向量搜索与知识库查询集成

与 knowledge-graph-builder 配合

• 用于混合知识库中基于实体的部分
• 遵循图设计模式
• 将图遍历与知识库查询集成

与 data-engineer 配合

• 用于 ETL 管道（提取、转换、加载知识）
• 用于数据质量监控
• 用于性能优化

与 quality-auditor 配合

• 用于自动化质量检查
• 用于测试和验证
• 用于持续监控

与 technical-writer 配合

• 用于知识文档编写
• 用于编写知识库使用指南
• 用于编写治理文档

---

工具与技术

基于文档的知识库技术栈

• 向量数据库：Pinecone、Weaviate、pgvector
• 嵌入：OpenAI、Cohere、自定义
• 搜索：语义搜索 + 关键词混合搜索

基于实体的知识库技术栈

• 图数据库：Neo4j、ArangoDB
• 查询：Cypher、AQL
• 可视化：Neo4j Bloom、Gephi

内容整理工具

• 去重：自定义算法、模糊匹配
• 冲突检测：基于规则、基于 ML
• 验证：测试问题集、人工审核

监控

• 指标：自定义仪表板（Grafana）
• 日志记录：对查询/更新进行结构化日志记录
• 警报：内容新鲜度、准确性、错误率警报

---

成功指标

知识质量

• 准确性：测试问题上的准确率 >90%
• 覆盖率：能够回答 >80% 的用户问题
• 新鲜度：平均内容时效 <30 天
• 一致性：相互冲突的信息 <5%

用户满意度

• 相关性：>85% 的查询结果被评为相关
• 实用性：>80% 的用户认为知识库有价值
• 速度：查询时间中位数 <100ms

运营健康状况

• 正常运行时间：>99.9%
• 更新频率：至少每周一次
• 团队参与度：定期贡献

---

常见陷阱与解决方案

陷阱 1：“建好了，自然有人来”

问题：没有用户验证，知识库无法满足需求

解决方案：从用户研究开始，持续验证

陷阱 2：追求完美

问题：等到知识库“完美”才发布

解决方案：覆盖率达到 80% 即发布，根据使用情况迭代

陷阱 3：过度设计

问题：简单文档就能解决问题，却构建复杂的混合系统

解决方案：从简单方案开始，仅在需要时增加复杂度

陷阱 4：忽视维护

问题：只构建一次，之后从不更新

解决方案：从第 1 天起制定维护计划

---

快速入门清单

开始之前：

• 阅读本技能的全部内容
• 如果使用文档知识库，请查看 rag-implementer
• 如果使用实体知识库，请查看 knowledge-graph-builder
• 明确使用场景和成功指标

阶段 1 - 架构（第 1 周）：

• 清点知识来源
• 选择知识库类型（文档/实体/混合）
• 定义架构/本体
• 搭建基础设施

阶段 2 - 初始构建（第 2-3 周）：

• 导入并整理初始知识
• 实现搜索/查询功能
• 创建测试问题集
• 与用户一起验证

阶段 3 - 迭代（持续进行）：

• 根据使用情况添加更多知识
• 监控质量指标
• 发现问题后及时修复
• 建立维护节奏

---

相关资源

• 技能：rag-implementer、knowledge-graph-builder、data-engineer、quality-auditor
• MCP：vector-database-mcp、graph-database-mcp、knowledge-base-mcp、semantic-search-mcp
• 模式：STANDARDS/architecture-patterns/rag-pattern.md、knowledge-base-pattern.md（即将推出）
• 集成：INTEGRATIONS/pinecone/、INTEGRATIONS/graph-databases/neo4j/

---

延伸阅读

• 知识图谱指南
• 使用大模型构建知识库
• RAG：检索增强生成
• 知识管理最佳实践

---

请记住：知识库的质量取决于其整理质量。从第 1 天起就重视质量，建立维护流程，并根据用户反馈不断迭代。目标不是收纳所有知识，而是拥有经过妥善整理且易于访问的 正确 知识。