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
• The Compiler Analogy Explained
• Building an LLM Wiki with Claude Code and Obsidian
• Karpathy's LLM Wiki got 16M views

Google OKF：

• Google Cloud 官方博客：OKF
• OKF: What It Is, the Spec, How to Use It
• OKF wants to be the lingua franca
• Google Open-Sources OKF (451 lines, 1 required field)
• Publishing an OKF bundle with 11ty（6 字段细节）

对比与规模失效：

• The LLM Wiki at Scale: From Personal Research Tool to Production RAG（规模红线）
• Karpathy's AI Wiki vs Structured Databases
• Did Karpathy's LLM Wiki Just Kill RAG? Enterprise Verdict
• LLM Wiki vs RAG for Internal Codebase Memory

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