company-kb/docs/03-知识库框架选型调研.md

# 知识库框架选型 · 深度调研报告

> 主题：卡帕西 LLM Wiki 方法论（≥2 套实现）+ Google OKF + 传统 RAG 知识库对比
> 用途：公司分层知识库选型
> 调研日期：2026-06-24 | 方法：smart-router → research-suite 后端 + WebSearch/WebFetch 交叉验证

## 摘要（TL;DR）

1. **卡帕西方法论 = "Stop Retrieving, Start Compiling"**（编译 > 检索）。2026-04 提出，X 上 1600 万阅读。核心：让 LLM 把原始资料"编译"成结构化、互链的 Markdown wiki（一次性），之后直接把 wiki 喂进上下文，而非每次查询都对原始文本跑向量检索。
2. **Google OKF（Open Knowledge Format）= 卡帕西模式的标准化**。2026-06-12 Google Cloud 发布 v0.1，本质就是"带 YAML frontmatter 的 Markdown 目录"，唯一必填字段 `type`。是"格式不是平台"，无 SDK、无运行时、无锁定。
3. **三者不是互斥，而是分层互补**：卡帕西原理是"地基"，OKF 是"地基的标准格式"，RAG/向量库是"规模超过几百页后的导航层"。
4. **对我们 5 人团队的结论**：现阶段方案（Git+Markdown+frontmatter）已天然命中 OKF/卡帕西模式，**方向正确，且应直接采用 OKF 的 frontmatter 约定**以获得未来可移植性。规模红线在"~100 源 / 几百页"，远未到，**先不上 RAG**的判断成立。

详见各章。来源列表见末尾。

## 1. 卡帕西 LLM Wiki 方法论（方法论本体）

**核心洞察**：传统 RAG 是"健忘症"——每次查询都从零检索、合成、然后忘掉。知识从不沉淀，系统永远长不大。卡帕西的替代：LLM 当"编译器"，读完所有源 → 抽取概念、压缩含义、建立交叉引用 → 产出结构化 wiki。查询时对**已编译的知识**推理，而非原始文本。

**关键特征**：
- 知识"累积"而非"检索"，是持久复利资产（与你机器里 `llm-wiki` SKILL 的"编译>检索"理念一字不差）。
- 纯 Markdown，围绕 index.md 组织，无需向量库。
- 版本化、类型化、API 可访问，是 agent 推理的底座。

## 2. 卡帕西方法论的两套参考实现

### 实现 A：llm-wiki SKILL（本机已激活，pkm-suite）
- raw/→wiki/ 增量编译，10 步摄入流程，Delta Check（hash 去重）。
- Frontmatter Schema：通用字段 type/title/created/updated/tags/status/related/sources + 类型特有字段（source/entity/concept/comparison/question）。
- 三级查询（Quick/Standard/Deep）、Hot Cache（hot.md ~500 词）、8 项 Lint 健康检查、矛盾检测。
- 融合 claude-obsidian 精华。**这是我们手里现成的卡帕西实现**。

### 实现 B：Claude Code + Obsidian 社区实现
- 用 Claude Code 把原始源编译进 Obsidian vault，sources/entities/concepts/comparisons 分目录。
- 与实现 A 同源同构，验证了"CC 做编译器 + Markdown vault 做载体"是社区主流落地路径。

## 3. Google OKF（Open Knowledge Format）v0.1

**定位**：把"LLM wiki"这个涌现模式，标准化成厂商中立、可移植的格式。作者 Sam McVeety / Amir Hormati（Google Cloud），451 行规格，"a format, not a platform"。GitHub 上附 3 个样例 bundle + 2 个参考实现。

**规格（frontmatter 6 字段，仅 type 必填）**：
| 字段 | 必填 | 含义 |
|------|------|------|
| `type` | ✅ 唯一必填 | 概念类别（Metric/Table/Dataset/API/Runbook…） |
| `title` | 选 | 人类可读名 |
| `description` | 选 | 一句话摘要 |
| `resource` | 选 | 指向底层资源的链接 |
| `tags` | 选 | 分组关键词 |
| `timestamp` | 选 | 信息最后有效时间 |

**结构**：一个 bundle = 一个 Markdown 文件目录，一文件一概念，文件路径即标识符。生产者与消费者解耦（谁定义 type、加什么字段，由生产者决定）。建议放版本控制里，改动可审、有日期。

**OKF 刻意不做的事**：不是搜索排名信号、不是 web 发现标准（不同于 sitemap/llms.txt）、不替代 schema.org/JSON-LD、v0.1 明确是草稿。

**OKF 与 RAG 的关系**：OKF 面向"在公司知识上跑内部 copilot 或 RAG 的团队"，把 bundle 加载进检索层，让 agent"先读 OKF 再猜"。即 OKF 是喂给 RAG 的优质结构化输入，二者协作。

## 4. 传统 RAG / 向量库 知识库

**机制**：文档切块 → 向量化 → 查询时相似度检索 top-k chunk → 喂 LLM 合成答案。
**优势**：规模无上限，适合海量、异构、高频更新语料；不需要预先"编译"。
**痛点（卡帕西批判的核心）**：
- chunk 不透明、缺上下文，知识从不沉淀，每次查询从零开始（"perpetual amnesia"）。
- 准确度/速度/可维护性在"一类知识检索问题"上被 wiki 模式碾压（但仅限那一类）。

## 5. 规模红线与失效模式（选型最该警惕的）⚠️

卡帕西纯 wiki 模式在 **"约 100 个源 / 几百个页面"** 后破裂，两个原因：
1. **index.md 不可导航**：目录条目太多，LLM 首读的单一摘要文件失效，定位不到相关页。
2. **摄入悖论（循环依赖）**：编译新源时，"不先能导航大索引，就无法判断该更新哪些已有页"——要维护索引得先有可用索引。

**业界共识的解法 = 混合（wiki + RAG）**：保留"编译知识"的思想，但用**向量库替代 index.md 做导航层**，从而支持任意规模。检索负责"找到相关 chunk"，wiki 构建负责"结构化它们"，结构化 wiki 作为合成的输入。结论是"RAG 没死，是 wiki 和 RAG 互补"。
- 注意残留局限：矛盾检测受限于检索——不相似的文档永不共现，冲突检测不到。

## 6. 三方对比矩阵

| 维度 | 卡帕西 LLM Wiki | Google OKF | 传统 RAG |
|------|----------------|-----------|---------|
| 本质 | 方法论（编译>检索） | 格式标准 | 检索架构 |
| 载体 | Markdown + index | Markdown + frontmatter | 向量库 + chunk |
| 知识沉淀 | ✅ 累积复利 | ✅（格式层面） | ❌ 每次从零 |
| 规模上限 | ~100源/几百页 | 同 wiki（它是格式） | 无上限 |
| 可移植/无锁定 | ✅ | ✅✅（标准化） | 取决于实现 |
| 检索准确度 | 高（小规模） | — | 中（chunk 噪声） |
| 基建复杂度 | 极低 | 极低 | 高 |
| CC 原生友好 | ✅✅ | ✅✅ | ❌ 需中间层 |

## 7. 对公司分层知识库的选型建议

1. **采集层 + 原始汇聚层（第一件事）= 直接落地卡帕西/OKF 模式**。我们原方案（Git+Markdown+frontmatter）已命中，只需把 frontmatter **对齐 OKF 6 字段**（type 必填）+ 保留我们溯源字段（source/author/created/ingested），获得未来可移植性与 Google 生态背书。
2. **复用 `llm-wiki` SKILL 作为"编译器"**：raw/→wiki/ 增量编译、Lint、矛盾检测都现成，是处理层的天然第一层，不必重造。
3. **先不上 RAG**：5 人团队、项目资料量级远低于 ~100 源红线。`先不上向量库` 的原判断被证实正确。
4. **预留混合演进路径**：当某个领域语料逼近几百页、index 开始不可导航时，按业界混合方案引入向量库当"导航层"，wiki 编译层不变。这给处理层留了清晰的升级接口。
5. **type 体系要早定**：OKF 把 type 交给生产者定义。我们应在 CONVENTIONS.md 里先约定一套公司 type（如 project/decision/conversation/doc/runbook/metric），避免后期不一致。

## 8. 来源

卡帕西方法论：
- [Beyond RAG: Karpathy's LLM Wiki Pattern](https://nayakpplaban.medium.com/beyond-rag-how-andrej-karpathys-llm-wiki-pattern-builds-knowledge-that-actually-compounds-31a08528665e)
- [The Compiler Analogy Explained](https://www.mindstudio.ai/blog/karpathy-llm-knowledge-base-architecture-compiler-analogy)
- [Building an LLM Wiki with Claude Code and Obsidian](https://medium.com/@manavghosh/building-an-llm-wiki-with-claude-code-and-obsidian-eb6c0990e723)
- [Karpathy's LLM Wiki got 16M views](https://implicator.ai/karpathys-llm-wiki-got-16-million-views-the-code-isnt-the-point-2/)

Google OKF：
- [Google Cloud 官方博客：OKF](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing)
- [OKF: What It Is, the Spec, How to Use It](https://www.startuphub.ai/ai-news/insights/2026/google-open-knowledge-format-okf-explained-2026)
- [OKF wants to be the lingua franca](https://www.ppc.land/googles-okf-wants-to-be-the-lingua-franca-for-ai-agent-knowledge/)
- [Google Open-Sources OKF (451 lines, 1 required field)](https://www.implicator.ai/google-open-sources-a-knowledge-format-and-wires-it-into-its-catalog/)
- [Publishing an OKF bundle with 11ty（6 字段细节）](https://www.simoncox.com/post/2026-06-17-publishing-an-okf-bundle-with-11ty/)

对比与规模失效：
- [The LLM Wiki at Scale: From Personal Research Tool to Production RAG（规模红线）](https://michalnasternak.medium.com/the-llm-wiki-at-scale-from-personal-research-tool-to-production-rag-247710a1284c)
- [Karpathy's AI Wiki vs Structured Databases](https://www.mindstudio.ai/blog/karpathy-wiki-vs-structured-database-ai-memory)
- [Did Karpathy's LLM Wiki Just Kill RAG? Enterprise Verdict](https://www.epsilla.com/blogs/llm-wiki-kills-rag-karpathy-enterprise-semantic-graph)
- [LLM Wiki vs RAG for Internal Codebase Memory](https://www.mindstudio.ai/blog/llm-wiki-vs-rag-internal-codebase-memory)

> 调研方法说明：research-suite 后端本轮 GATHER 未命中（quality WARNING, 0 source），已切换 WebSearch/WebFetch 兜底并交叉验证。关键结论（OKF 发布日期、6 字段、规模红线）均 ≥2 源印证。