知识库先编译再查，而不是查询时拼原文

更新于 2026-09-22

**传统 RAG 每次提问都从原始文档的 chunk 里临时拼答案；LLM Wiki 式做法是先用 agent 把资料编译成持久、可维护的 Markdown 知识层，之后查询读的是这个已整理的结构。核心差别不是「要不要检索」，而是「知识在什么时刻被整理成结构」。**

一、三层结构

  • Raw sources：原始资料，不可变，是事实源。
  • Wiki：LLM 生成并维护的页面（实体页 / 概念页 / 来源页 / 综合页 / 对比页）。
  • Schema：类似 AGENTS.md，规定怎么建页、命名、更新、查询。

隐喻：Obsidian 是 IDE，LLM 是程序员，wiki 是 codebase。

二、「不用 RAG」不等于「不检索」

知识库小的时候，靠 index.md 就能定位；变大后 index.md 太长，必须补定位机制。Karpathy 也说中等规模 index.md 可用、变大再加本地搜索。

两种定位机制角色不同：

EmbeddingRerank
作用召回候选（粗找）精排候选（判断哪些最该读）
输入query + 全库向量query + 少量候选文本
速度 / 成本快、低慢、较高
缺点容易泛相关不适合扫全库

流程：query → embedding/BM25 召回约 50 条 → rerank 挑前 5 → LLM 读。

三、可迁移的判断

  • 反对的是**「每次都从 raw docs 临时拼答案」**，不是反对 agent 去查页面。
  • 选型先问：知识在什么时刻被整理成结构 —— 查询时（RAG）还是入库时（编译）。
  • 编译层能持续维护（去重、检测矛盾、补链、健康检查），这是纯检索层拿不到的。

来源：Karpathy 的 LLM Wiki gist（raw sources / wiki / schema 三层）；claude-obsidian 把该思路产品化（丢入网页/PDF/聊天记录 → 自动抽实体与概念、建双链、检测矛盾、会话结束更新 hot.md、健康检查孤儿页与死链）。

相关