AI 知识库系统总览与设计哲学
作者：知识管理系统架构师视角
日期：2026-06-09
系列：AI 知识库系统调研（00/09）
定位：工程师实践指南，非学术综述
1. 为什么需要 AI 知识库
1.1 知识的三个层次：信息 → 知识 → 智慧
在讨论”AI 知识库”之前，必须先厘清一个认知论上的基础问题：我们究竟在管理什么？
数据 (Data) → 原始、离散、无上下文11
↓ 结构化 + 关联
信息 (Information) → 有组织、可理解
↓ 内化 + 验证 + 实践
知识 (Knowledge) → 可行动、可复用、带推断能力
↓ 长期积累 + 跨域融合
智慧 (Wisdom) → 判断力、取舍能力、元认知
大多数工程团队的知识管理工具（Wiki、Confluence、Notion）停留在”信息层”。信息层的特征是：你能搜到文档，但不一定能解决问题。文档告诉你”这个 API 怎么调用”，但不告诉你”在什么场景下你不应该调用这个 API”。
知识层的核心特征是可行动性（Actionability）和情境化（Contextualization）：
| 层次 | 存储形式 | 消费方式 | 问题示例 |
|---|---|---|---|
| 信息 | 文档、Wiki | 搜索、浏览 | ”这个函数的参数是什么？“ |
| 知识 | 规则、模式、经验 | 推理、类比 | ”这种崩溃应该怎么诊断？“ |
| 智慧 | 判断框架、元原则 | 评估、决策 | ”这两个方案哪个更适合我们的团队？” |
AI 知识库的目标是让系统在”知识层”工作，而不是仅仅做一个更好的搜索引擎。
1.2 工程师的痛点：经验分散、难以复用、无法传承
以 Android 性能调优为例，一个资深工程师的脑子里可能存着：
- “AtlasTextOp 在 Scale 动画场景下会触发 Cache Miss，原因是 Strike Descriptor 的 scale factor 变化导致 LRU 失效” — 这是一次排查一周才发现的结论
- “用 simpleperf 抓栈时，如果进程有大量 JNI transition，需要加
--trace-offcpu，否则 off-cpu 时间会漏掉” — 这是踩坑两天的经验 - “Perfetto 的
ftrace在某些内核版本上sched_switch事件会丢失，需要同时开sched_wakeup作为补偿” — 这是某个版本特有的 bug
这些知识在哪里？在工程师的脑子里。当工程师离职、转岗、或者只是忘了的时候，这些知识就消失了。
痛点的结构性分析：
经验碎片化
├── 口口相传 → 变形、失真
├── 内嵌在代码注释里 → 搜不到、不成体系
├── 记在个人笔记里 → 无法共享
├── 沉入历史 PR/Issue → 需要知道关键词才能找
└── 从未被记录 → 彻底消失
可复用性差
├── 每次遇到同类问题重新摸索
├── 新人入职靠"师傅带"
├── 同类问题各团队独立解决
└── 最佳实践无法沉淀
无法传承
├── 组织知识随人才流失而流失
├── 项目文档在项目结束后无人维护
└── 老代码无人敢改（没人理解原始意图）
1.3 传统文档 vs AI 知识库的本质区别
这是最需要辨析的一个问题。很多人把 AI 知识库理解为”把文档喂给 ChatGPT”，这种理解太浅。
传统文档系统的本质假设：
- 知识是静态的，写完就不变
- 消费者是人类，需要线性阅读
- 搜索是关键词匹配
- 知识的有效性由作者自行保证
AI 知识库的本质假设：
- 知识是动态的，需要持续精炼
- 消费者包括 AI，需要语义理解
- 检索是语义相关性匹配
- 知识的有效性需要系统性验证和衰减机制
一个具体的对比：
场景：工程师问"我的 RecyclerView 滑动卡顿，怎么排查？"
传统文档系统的响应：
→ 搜索"RecyclerView 卡顿"
→ 返回5篇文档，需要人工阅读判断
→ 可能找到一篇2019年的文档，其中的API已经废弃
AI 知识库的响应：
→ 语义理解问题意图
→ 检索相关知识块（置信度高、时间戳新、适用于当前系统版本）
→ 综合推理给出分步排查路径
→ 如果知识库中有团队自己踩过的坑，优先引用
→ 标注哪些结论是确定的，哪些是推测
1.4 人类消费 vs AI 消费的不同需求
这是一个经常被忽视的设计约束。同一份知识，人类阅读和 AI 处理对格式的要求截然不同：
| 需求维度 | 人类消费 | AI 消费 |
|---|---|---|
| 文本长度 | 喜欢完整的上下文和背景叙述 | 精简、避免冗余，影响 token 效率 |
| 结构 | Markdown 段落、列表 | 结构化字段，便于提取 |
| 歧义处理 | 可以从上下文理解隐含含义 | 需要显式、精确的表述 |
| 知识边界 | 模糊边界可以接受 | 需要明确的适用条件（scope） |
| 时效性 | 能看出文档是否过时 | 需要显式的时间戳和有效期字段 |
| 交叉引用 | 超链接 | 实体 ID、关系类型 |
这意味着一个好的 AI 知识库必须维护两套表示：一套供人类阅读，一套供 AI 处理，并保持两套的同步。
2. 可维护知识库的设计原则
2.1 Single Source of Truth（单一真相来源）
在分布式团队中，知识最大的敌人不是”没有文档”，而是”同一件事有三份互相矛盾的文档”。
SSoT 原则要求：每一条知识有且仅有一个权威来源。所有其他地方的引用都是指向这个来源的链接，而不是拷贝。
错误模式（反例）：
wiki/performance/memory.md → 包含"内存阈值是 512MB"
docs/guidelines/thresholds.md → 包含"内存阈值是 256MB"（已更新）
README.md → 包含"内存阈值是 512MB"（未更新）
三个地方的信息不一致，工程师不知道该信任哪个。
正确模式：
knowledge/facts/memory_threshold.md ← 唯一权威来源
wiki/performance/memory.md → [参见 memory_threshold]
docs/guidelines/thresholds.md → [参见 memory_threshold]
README.md → [参见 memory_threshold]
修改阈值时，只需要修改一处。
实施 SSoT 的关键技术决策：
- 知识 ID 系统：每条知识有全局唯一 ID（如
KB-PERF-001） - 引用机制：其他文档用 ID 引用，不拷贝内容
- 破坏性更新通知：当 SSoT 更新时，引用者收到通知
2.2 知识原子化：每条经验独立、自解释
原子化是知识库可维护性的基础。一条”原子化”的知识需要满足：
- 自解释：不需要阅读其他知识就能理解这条知识的含义
- 不可再分：不能拆分为更小的独立知识单元
- 单一职责：只描述一件事
# 反例：一个大而全的知识块
title: "Android 性能优化"
content: |
## 内存优化
避免内存泄漏，使用 WeakReference...
内存阈值是 512MB...
## GPU 优化
避免 overdraw...
使用 GPU 调试工具...
## 启动优化
避免在 Application.onCreate() 中做耗时操作...
# 正例：原子化知识块
id: KB-MEM-001
title: "Android 内存泄漏：Handler 引用 Activity 的常见模式"
content: |
在 Activity 中创建匿名 Handler 时，Handler 会隐式持有 Activity 的引用。
如果 Handler 发送了延迟消息（postDelayed），Activity 销毁后消息队列仍持有
Handler 引用，导致 Activity 无法被 GC。
applies_to: ["Android", "Java", "Handler"]
confidence: 0.95
last_verified: "2025-11-01"2.3 元数据驱动：置信度、来源、时间戳、有效范围
元数据是 AI 知识库区别于传统文档的关键特征之一。每条知识需要携带足够的元数据，让系统（和 AI）能够判断这条知识是否可信、是否适用。
{
"id": "KB-PERF-042",
"title": "simpleperf 抓栈时 JNI transition 导致 off-cpu 时间丢失",
"content": "...",
"metadata": {
"confidence": 0.92,
"source": {
"type": "empirical",
"origin": "ISS-202504-000123A",
"verified_by": ["engineer-A", "engineer-B"]
},
"temporal": {
"created_at": "2025-04-15",
"last_verified": "2025-10-01",
"valid_until": null,
"decay_rate": 0.05
},
"scope": {
"applies_to": ["Android 12+", "simpleperf 0.9+"],
"does_not_apply_to": ["pure Java processes"],
"conditions": "进程存在高频 JNI 调用（>1000次/秒）"
},
"relations": {
"supersedes": [],
"contradicts": [],
"related": ["KB-PERF-040", "KB-PERF-041"]
}
}
}置信度（confidence）的计算模型：
初始置信度 = f(来源可靠性, 验证人数, 验证方式)
来源可靠性：
官方文档 → 0.95
代码验证 → 0.90
多人实验 → 0.85
单人经验 → 0.70
推测/假设 → 0.40
时间衰减：
confidence(t) = confidence_0 × e^(-λ × Δt)
λ = decay_rate（技术知识通常 0.03~0.1/月）
2.4 知识腐烂问题：如何识别和处理过时知识
知识腐烂（Knowledge Rot）是所有知识库面临的最核心挑战。Android 生态一年内就能让大量”最佳实践”失效。
识别腐烂知识的信号：
- 时间信号：创建时间超过 N 个月未验证
- 引用信号：知识中引用的 API / 版本已废弃
- 矛盾信号：新的知识与旧知识结论相反
- 外部信号：关联的 Issue / PR 被关闭，结论有变
处理策略：
知识状态机：
DRAFT → ACTIVE → STALE → DEPRECATED
↓ 重新验证
ACTIVE
ACTIVE: 可以直接使用，置信度 > 0.7
STALE: 可以参考，但需要验证，置信度在 0.4~0.7
DEPRECATED: 不应使用，置信度 < 0.4 或被明确废弃
自动腐烂检测（CI 定期运行）：
def check_knowledge_staleness(knowledge_base):
stale_items = []
for kb_item in knowledge_base:
age_days = (today - kb_item.last_verified).days
decay = kb_item.metadata.decay_rate
current_confidence = kb_item.confidence * math.exp(-decay * age_days / 30)
if current_confidence < STALE_THRESHOLD:
stale_items.append({
"id": kb_item.id,
"original_confidence": kb_item.confidence,
"current_confidence": current_confidence,
"last_verified": kb_item.last_verified,
"action": "needs_review"
})
return stale_items2.5 版本控制：Git 在知识库中的角色
将知识库存储在 Git 仓库中，不仅仅是为了备份，更是为了获得版本控制能力。
Git 在知识库中能做的事：
| Git 能力 | 知识库应用场景 |
|---|---|
| commit history | 追踪知识的演化过程，理解为什么这条知识被修改 |
| branch | 知识的草稿/实验版本，不影响主干 |
| tag | 标记某个时间点的知识快照（对应产品版本） |
| blame | 追溯某条知识的创建者和修改者 |
| diff | 可视化知识内容的变化 |
| PR/review | 知识更新需要 peer review，防止错误知识进入 |
一个合理的 Git 工作流：
feature/KB-new-knowledge
↓ PR + review
main (ACTIVE 知识)
↓ 定期打 tag
v2025.Q4 (季度快照)
3. 可迭代性设计
3.1 知识的生命周期
摄取(Ingest)
↓
[原始知识池]
↓
验证(Validate)
↓
精炼(Refine) ←── 新证据
↓
[活跃知识库]
↓
废弃(Deprecate)
↓
[历史档案]
每个阶段的关键活动：
摄取（Ingest）：
- 来源：Issue 系统、代码 PR、Slack/飞书对话、技术分享、实验日志
- 形式：原始文本，不加工
- 关键：保留来源引用，不丢失 provenance
验证（Validate）：
- 确认知识是否可复现（对于经验性知识）
- 确认边界条件（在什么情况下成立）
- 打初始置信度
精炼（Refine）：
- 原子化分解
- 标准化格式
- 建立关联关系
- 合并重复知识
废弃（Deprecate）：
- 明确废弃原因（被新知识取代 / 技术栈变化 / 证伪）
- 保留历史记录，不物理删除（考古价值）
3.2 增量更新 vs 全量重建
这是一个工程效率和一致性的权衡：
全量重建（Full Rebuild）：
- 优点：保证最终一致性，简单可靠
- 缺点：计算成本高，延迟高（知识更新不及时）
- 适合：向量索引的初始化，定期（每周）重建
增量更新（Incremental Update）：
- 优点：实时性好，成本低
- 缺点：可能累积不一致（知识 A 更新了，但依赖 A 的知识 B 没有同步更新）
- 适合：单条知识的 CRUD 操作
推荐策略：
写入路径：
知识变更 → 增量更新向量索引 → 标记关联知识为"需重算"
定期任务（每周日凌晨）：
遍历"需重算"的知识 → 重建关联关系 → 全量重建相关向量
3.3 新证据如何更新旧知识（不是追加而是更新）
这是 AI 知识库与”日志式知识积累”的根本区别。
错误模式（日志式追加）：
KB-PERF-001 (2024-01): "建议使用 doFrame callback 监测帧率"
KB-PERF-047 (2024-06): "doFrame 方案在 Android 14 上有精度问题，建议改用 SurfaceFlinger"
KB-PERF-089 (2025-03): "SurfaceFlinger 方案需要 root 权限，普通 App 不可用"
→ 工程师不知道到底用哪个
→ 需要读所有三条才能得出结论
正确模式（知识图谱更新）：
KB-PERF-001 (当前最新状态):
title: "App 帧率监测方案"
conclusion: "普通 App 推荐 Choreographer.FrameCallback；需要精确帧时序的场景"
"需要用 SurfaceFlinger（需 root）"
history:
- 2024-01: 初始建议 doFrame callback
- 2024-06: 发现 Android 14 精度问题，添加 SurfaceFlinger 方案
- 2025-03: 补充 SurfaceFlinger 的权限限制
confidence: 0.90
实施这种更新模式的技术要求：
- 知识 ID 稳定不变（即使内容被大幅修改）
- 每次修改保存 diff 到 changelog
- LLM 在处理新证据时，先检索是否存在相关知识，再决定”更新”还是”新建”
3.4 知识图谱的动态演化
知识不是孤立的点，而是网络中的节点。随着知识库增长，关系网络会自动涌现出结构：
实体节点：
- 概念（如"AtlasTextOp"）
- 技术（如"Perfetto"）
- 问题类型（如"卡顿"）
- 解决方案（如"减少 overdraw"）
关系类型：
- IS_A：Skia 是 2D 图形引擎
- CAUSES：高频 GC CAUSES 卡顿
- SOLVES：降低 GC 频率 SOLVES 卡顿
- DEPENDS_ON：AtlasTextOp DEPENDS_ON FontCache
- CONTRADICTS：观点 A CONTRADICTS 观点 B
- SUPERSEDES：新方案 SUPERSEDES 旧方案
知识图谱的动态演化意味着：
- 添加一条新知识后，自动检测它与现有知识的关系
- 当检测到 CONTRADICTS 关系时，触发人工审核
- 关系密集的节点（Hub）往往是核心概念，需要更频繁的维护
3.5 置信度衰减机制
技术知识有”半衰期”。以下是不同类别知识的典型衰减参数：
| 知识类别 | 衰减率（λ/月） | 半衰期（月） | 示例 |
|---|---|---|---|
| API 行为 | 0.05 | ~14 | ”这个 API 的返回值含义” |
| 性能数值 | 0.08 | ~9 | ”这个操作耗时约 Xms” |
| 框架原理 | 0.02 | ~35 | ”Android 渲染管线的工作原理” |
| 硬件特性 | 0.01 | ~70 | ”这款芯片的 cache 行为” |
| 算法原理 | 0.005 | ~140 | ”LRU 算法的时间复杂度” |
| 数学定理 | 0 | ∞ | “勾股定理” |
4. AI+人类双消费架构
4.1 人类消费层：可读性、可编辑、搜索
人类阅读知识的需求：
- 叙事性：需要故事化的背景和推理过程（“为什么”比”是什么”更重要）
- 渐进式披露：先看摘要，需要时才深入细节
- 可编辑：工程师能随时纠正错误，降低维护摩擦
- 关键词搜索：习惯用关键词找到相关内容
针对人类消费的格式规范：
# [知识标题]
> TL;DR：一句话总结核心结论
## 背景
[为什么这个知识重要，触发这个问题的场景]
## 核心结论
[清晰、直接的结论]
## 证据与推理
[如何验证，代码示例，日志片段]
## 注意事项
[边界条件，不适用场景]
## 参考
[来源链接，相关知识 ID]4.2 AI 消费层：向量化、RAG、结构化查询
AI 消费知识的需求与人类截然不同：
向量化（Embedding）：
# 知识块的向量化处理
def vectorize_knowledge(kb_item):
# 合成用于向量化的文本（比 Markdown 原文更适合向量化）
embedding_text = f"""
标题：{kb_item.title}
核心结论：{kb_item.core_conclusion}
适用场景：{', '.join(kb_item.metadata.scope.applies_to)}
关键词：{', '.join(kb_item.keywords)}
"""
return embedding_model.encode(embedding_text)RAG 检索：
def retrieve_for_rag(query, top_k=5):
query_vector = embedding_model.encode(query)
# 向量相似度检索
candidates = vector_db.search(query_vector, top_k * 3)
# 后过滤：只保留 ACTIVE 状态、置信度 > 0.6 的知识
filtered = [
c for c in candidates
if c.status == "ACTIVE" and c.confidence > 0.6
]
# 重排序：考虑置信度 × 相关性
reranked = sorted(filtered,
key=lambda x: x.similarity * x.confidence,
reverse=True)
return reranked[:top_k]结构化查询（知识图谱）：
// 查询"卡顿"问题的所有已知根因
MATCH (problem:Problem {type: "卡顿"})<-[:CAUSES]-(cause:Cause)
WHERE cause.confidence > 0.7
RETURN cause.title, cause.confidence
ORDER BY cause.confidence DESC4.3 两层保持同步的机制
人类层（Markdown）和 AI 层（向量 + 图谱）的同步是最容易出问题的地方。
同步策略：
事件驱动同步：
Markdown 文件变更（Git commit）
↓
CI/CD pipeline
↓
解析变更的 .md 文件
↓
├── 更新向量数据库（增量 upsert）
├── 更新知识图谱（实体和关系）
└── 重新计算当前置信度
防止脱节的保障：
- 每次 AI 层被查询时，返回结果时带上”最后同步时间”
- 如果 AI 层的数据比 Markdown 层老超过阈值（如 24 小时），触发警告
- 定期（每周）全量 diff 验证两层一致性
4.4 知识的多种表征形式
同一条知识在系统中以多种形式共存：
一条知识的完整存储：
1. Markdown 文档（人类可读）
└── /knowledge/perf/KB-PERF-001.md
2. 结构化 JSON（机器可读元数据）
└── /knowledge/perf/KB-PERF-001.json
3. 向量嵌入（语义检索）
└── vector_db.collection["kb-perf"] key=KB-PERF-001
4. 图谱节点（关系查询）
└── graph_db.node(id="KB-PERF-001", labels=["Knowledge", "Performance"])
5. 摘要嵌入（快速过滤）
└── vector_db.collection["kb-summary"] key=KB-PERF-001
5. 系统整体架构
5.1 架构概览
┌─────────────────────────────────────────────────────────────────┐
│ 知识来源层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Issue/Bug│ │ 代码 PR │ │ 即时通讯 │ │ 技术分享/ │ │
│ │ 系统 │ │ │ │ (飞书等) │ │ 实验日志 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └──────┬───────┘ │
└───────┼─────────────┼─────────────┼────────────────┼───────────┘
│ │ │ │
└─────────────┴─────────────┴────────────────┘
│
┌─────────▼──────────┐
│ 摄取层 │
│ Ingest Pipeline │
│ ・格式标准化 │
│ ・来源追踪 │
│ ・去重检测 │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ 提炼层 │
│ LLM Refinement │
│ ・原子化分解 │
│ ・元数据提取 │
│ ・关系识别 │
│ ・置信度评估 │
└─────────┬──────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌─────────▼────┐ ┌────────▼──────┐ ┌──────▼───────┐
│ Markdown │ │ 向量数据库 │ │ 知识图谱 │
│ Vault │ │ (Qdrant/ │ │ (Neo4j/ │
│ (Git 管理) │ │ Chroma) │ │ Memgraph) │
└─────────┬────┘ └────────┬──────┘ └──────┬───────┘
│ │ │
└─────────────────┼─────────────────┘
│
┌─────────▼──────────┐
│ 消费层 │
├────────────────────┤
│ ・RAG 问答 │
│ ・语义搜索 │
│ ・图谱查询 │
│ ・知识推荐 │
│ ・腐烂检测 │
└────────────────────┘
5.2 摄取层（Ingest Layer）
摄取层负责将各种来源的原始信息转化为可处理的格式：
class KnowledgeIngester:
"""统一摄取接口，支持多源输入"""
def ingest_from_issue(self, issue_id: str) -> RawKnowledge:
"""从 Issue 系统摄取解决方案"""
issue = issue_client.get(issue_id)
return RawKnowledge(
content=self._extract_resolution(issue),
source_type="issue",
source_id=issue_id,
source_url=issue.url,
ingested_at=datetime.now()
)
def ingest_from_pr(self, pr_url: str) -> List[RawKnowledge]:
"""从 PR 摘取重要的代码评审经验"""
pr = git_client.get_pr(pr_url)
comments = pr.review_comments
# 过滤出有价值的评审意见（非样板语句）
valuable_comments = self._filter_valuable_comments(comments)
return [self._comment_to_raw_knowledge(c) for c in valuable_comments]
def _extract_resolution(self, issue) -> str:
"""提取 Issue 中的解决方案部分"""
# 寻找"根因"、"解决方案"、"结论"等关键段落
...5.3 存储层（Storage Layer）
存储层组件：
Markdown Vault (Obsidian 格式)
├── /knowledge
│ ├── /performance # 性能优化经验
│ ├── /debugging # 调试技巧
│ ├── /architecture # 架构决策记录
│ └── /tools # 工具使用指南
├── /meta
│ ├── /templates # 知识模板
│ └── /taxonomy # 分类体系
└── README.md # 知识库使用指南
向量数据库（Qdrant）
├── collection: knowledge-full # 完整知识的向量
├── collection: knowledge-summary # 摘要向量（快速检索）
└── collection: knowledge-title # 标题向量（精确匹配辅助）
知识图谱（Neo4j）
├── 节点类型：Knowledge, Concept, Technology, Problem, Solution
└── 关系类型：CAUSES, SOLVES, DEPENDS_ON, CONTRADICTS, SUPERSEDES
5.4 提炼层（Refinement Layer）
这是知识库中最复杂的部分，使用 LLM 对原始知识进行结构化处理：
REFINEMENT_PROMPT = """
你是一个知识库管理员。请将以下原始内容转化为结构化知识条目。
要求：
1. 提取核心结论（1-3句话）
2. 识别适用场景和边界条件
3. 评估置信度（0-1）
4. 提取关键词和标签
5. 识别与其他知识的关系（如果有）
原始内容：
{raw_content}
输出格式：JSON（严格按以下 schema）
"""
def refine_knowledge(raw: RawKnowledge) -> StructuredKnowledge:
response = llm.complete(
REFINEMENT_PROMPT.format(raw_content=raw.content),
response_format=StructuredKnowledgeSchema
)
return StructuredKnowledge(**response)5.5 消费层（Consumption Layer）
消费层提供多种访问模式：
class KnowledgeBaseAPI:
def rag_query(self, question: str) -> RAGResponse:
"""RAG 问答：最常用的消费方式"""
relevant_knowledge = self.retrieve_for_rag(question)
context = self._format_context(relevant_knowledge)
answer = self.llm.complete(
f"基于以下知识库内容回答问题：\n{context}\n\n问题：{question}"
)
return RAGResponse(
answer=answer,
sources=relevant_knowledge,
confidence=self._estimate_answer_confidence(relevant_knowledge)
)
def semantic_search(self, query: str, filters: dict = None) -> List[Knowledge]:
"""语义搜索：返回相关知识条目"""
...
def graph_query(self, cypher: str) -> List[dict]:
"""图谱查询：用于复杂关系查询"""
...
def get_by_id(self, kb_id: str) -> Knowledge:
"""精确查询：通过 ID 获取知识"""
...6. 本系列文档导航
本系列文档共 10 篇，覆盖 AI 知识库系统从设计到落地的完整路径：
| 序号 | 文档标题 | 核心内容 | 阅读时间 |
|---|---|---|---|
| 00 | 总览与设计哲学（本文） | 为什么要建、设计原则、整体架构 | 30 分钟 |
| 01 | 知识摄取与来源管理 | 多源数据统一摄取、provenance 追踪 | 20 分钟 |
| 02 | 知识原子化与元数据设计 | Schema 设计、置信度模型、分类体系 | 25 分钟 |
| 03 | 向量数据库选型与实践 | Qdrant vs Chroma vs Weaviate，embedding 策略 | 20 分钟 |
| 04 | 知识图谱构建与查询 | Neo4j 建模、关系提取、Cypher 查询 | 25 分钟 |
| 05 | LLM 提炼层设计 | Prompt 工程、结构化输出、质量控制 | 20 分钟 |
| 06 | RAG 系统优化 | Hybrid Search、重排序、上下文压缩 | 25 分钟 |
| 07 | 知识腐烂检测与更新 | 衰减模型、CI 检测、自动更新流程 | 20 分钟 |
| 08 | Obsidian Vault 工程实践 | 目录结构、模板、插件生态、与 AI 层同步 | 15 分钟 |
| 09 | 端到端实战：Android 性能知识库 | 完整案例，从 0 到 1 建设一个领域知识库 | 45 分钟 |
推荐阅读顺序：
初次接触者：00 → 09（先看总览，再看实战案例，获得感性认识）
系统设计者：00 → 01 → 02 → 05 → 07（理解设计决策）
基础设施工程师：03 → 04 → 06 → 08（关注技术选型和工程实践）
想直接上手的工程师：09（直接看实战，遇到问题再回来查阅）
附录：快速参考
知识条目 Schema（最小版本）
# 知识条目最小 Schema
id: "KB-{领域}-{序号}" # 如 KB-PERF-001
title: "简洁的标题"
core_conclusion: "核心结论（1-3句）"
content: | # 完整内容（Markdown）
...
metadata:
confidence: 0.85 # 0-1
status: ACTIVE # DRAFT | ACTIVE | STALE | DEPRECATED
created_at: "YYYY-MM-DD"
last_verified: "YYYY-MM-DD"
decay_rate: 0.05 # 每月衰减率
source:
type: empirical # empirical | official | inferred
origin: "ISS-xxx 或 PR URL"
scope:
applies_to: [] # 适用的技术/版本
conditions: "" # 生效的前置条件
tags: [] # 用于搜索的关键词
related: [] # 相关知识 ID知识质量评估清单
在提交一条新知识到知识库之前，检查以下项目：
- 标题是否清晰描述了这条知识的核心内容？
- 核心结论是否可以脱离上下文独立理解？
- 适用范围（scope）是否明确定义？
- 是否包含验证方式或证据？
- 置信度是否合理（经验性知识不应高于 0.85）？
- 是否检索过现有知识库，确认没有重复或矛盾？
- 如果与现有知识矛盾，是否标记了 CONTRADICTS 关系？
- 来源是否可追溯？
本文档为 AI 知识库系统调研系列的第 0 篇，提供整体框架和设计哲学。后续文档将深入每个子系统的工程细节。