关于 LLM Wiki
LLM Wiki 是由 Andrej Karpathy（特斯拉前 AI 总监、OpenAI 联合创始人）提出的一种知识库架构理念，2026 年 4 月在 X 上发布后 48 小时内获得 5000+ Stars，被视为对传统 RAG 范式的一次重要反思。
一、核心思想
LLM Wiki 的核心命题是：为什么每次都要检索，而不是让知识持久化？
传统 RAG 的工作方式是"用户提问 → 向量化 → 相似度匹配 → 拼上下文 → 生成回答"。每次请求都在做同样的事情——把文档当外挂硬盘，每次用都要重新查找。
LLM Wiki 的思路是反过来：让 LLM 当一名图书管理员，把零散的原始文档"编译"成一个结构化的、人类可读的 Markdown Wiki，然后在这个 Wiki 上做问答。
Karpathy 的原话：
"I spend more tokens manipulating knowledge than manipulating code."
"我花更多 token 在处理知识上，而非写代码上。"
他将原始资料（论文、仓库、网页）丢进 raw/ 文件夹，让 LLM 增量式地"编译"出一套 Wiki——包括摘要、概念定义、百科式文章，以及最重要的：知识点之间的反向链接。
二、LLM Wiki vs 传统 RAG 对比
| 维度 | 传统 RAG（向量库） | LLM Wiki（Markdown 知识库） |
|---|---|---|
| 数据形式 | 不透明向量（数学空间） | 人类可读 Markdown |
| 检索逻辑 | 语义相似度（最近邻） | 显式链接（反向链接/索引） |
| 可审计性 | 低（黑箱匹配） | 高（直接溯源到原文） |
| 知识积累 | 静态（需重新索引） | 主动（通过 Lint 自修复） |
| 适合规模 | 百万级文档 | 100~10,000 条高价值信号 |
| 人机协作 | 人看不懂向量，完全依赖 AI | 人可读可改，AI 和人共同维护 |
三、FSSC Wiki 对 LLM Wiki 理念的实践
FSSC Wiki 在落地过程中吸收了 LLM Wiki 的核心精神，并根据柒鑫的业务场景做了适配：
| LLM Wiki 原则 | FSSC Wiki 落地方案 |
|---|---|
| 文档即知识库 | 审核手册原始 MD 文件就是知识源，无需额外建表 |
| 人类可读 | MkDocs Material 渲染，浏览器直接翻阅，不依赖 AI 也能用 |
| 语义问答 | BGE + ChromaDB + DeepSeek 提供 Q&A，回答标注来源章节 |
| 透明溯源 | 每条回答附带 [来源 N，章节 X]，点击跳转到原文锚点 |
| 增量式编译 | sync_*_to_wiki.py 脚本 + onboard_company.py 管线，新内容一键编译 |
| 人机协作 | 反馈板让 LAN 用户提交建议，管理员审核改进 |
和 Karpathy 原始方案的不同之处：
- Karpathy 完全由 LLM 写入和维护 Wiki，人类不直接编辑
- FSSC Wiki 以人工审核过的业务手册为源头，AI 负责问答而非写入
- 增加了跨公司导航、表格索引、全文搜索等企业级功能
四、为什么选择这条路
RAG 适合海量、非结构化、不需要精确溯源的内容（如全网搜索、开放域问答）。
但审核手册这个场景不同：
- 精确性优先 — 审核规则一个字都不能错，向量检索的近似匹配不够可靠
- 人类可读 — 审核员需要自己翻手册确认，不能只依赖 AI 的"黑箱答案"
- 增量积累 — 新公司、新业务不断加入，知识库需要持续生长而非每次重建
- 可追溯 — 每一条审核规则的出处都要能追溯到原始文档的具体段落
LLM Wiki 的"先编译成可读文档，再基于文档做问答"恰好匹配这些需求。FSSC Wiki 是这一理念在企业内部知识管理场景的首次完整落地。
参考：Andrej Karpathy 2026年4月 X 帖子「LLM Knowledge Bases」；VentureBeat 报道「Karpathy shares LLM Knowledge Base architecture that bypasses RAG」