搜索层：当 index.md 不够用时，怎么给 LLM Wiki 加检索

LLM Wiki 搜索层

一开始不要急着上向量数据库。LLM Wiki 的美感之一，就是 index.md 在中小规模下已经很好用。搜索应该是规模增长后的自然升级，而不是第一天的复杂度。

这篇讲：

什么时候 index.md 够用；
什么时候需要搜索；
从简单到复杂怎么加；
搜索和 RAG 在 LLM Wiki 里的位置。

先说结论

0-100 个 Wiki 页面，先靠 index.md 和 Obsidian 搜索。
100-300 个页面，加入 rg / 命令行搜索会很有用。
300 页以上，可以考虑专门的 Markdown 搜索工具、BM25、向量检索或 qmd。
搜索层不替代 Wiki，它只帮 Agent 更快找到相关页面。
不要让搜索结果直接变答案，仍然要回到 Wiki 页面和来源。

1. 搜索层解决什么

没有搜索时，query 流程是：

读 index.md -> 找相关页面 -> 读页面 -> 回答

有搜索后，变成：

读 index.md -> 搜索候选页面 -> 读页面 -> 回答

注意：

搜索只是找页面，不是替代知识整理。

LLM Wiki 的核心仍然是 Markdown 页面。

搜索只是导航增强。

2. 不同规模的搜索策略

规模	推荐方式
1-50 页	`index.md`
50-150 页	`index.md` + Obsidian 搜索
150-300 页	`rg` + Graph View + Dataview
300-1000 页	Markdown 搜索工具 / BM25
1000 页以上	BM25 + vector + rerank

这不是硬规则。

判断标准是：

Agent 是否还能在合理时间内找到相关页面。

3. 第一层：index.md

index.md 是最简单的搜索。

它可以被 Agent 直接读。

好 index 应该有：

分类；
页面链接；
一句话摘要；
最近更新；
重要问题。

示例：

## Concepts

- [[wiki/concepts/llm-wiki]] — 由 LLM Agent 维护的 Markdown 知识库模式。
- [[wiki/concepts/ingest]] — 把 raw source 纳入 Wiki 的操作。
- [[wiki/concepts/wiki-lint]] — 检查 Wiki 健康度的操作。

如果你有 80 个页面，index 仍然很清楚，就不需要更复杂的东西。

4. 第二层：Obsidian 搜索

Obsidian 内置搜索适合人用。

你可以搜：

path:wiki/concepts LLM Wiki

或者搜：

tag:#llm-wiki

这对人类浏览很方便。

但 Agent 不一定能直接用 Obsidian UI。

所以如果你希望 Agent 自动搜索，最好准备命令行工具。

5. 第三层：ripgrep

rg 是最实用的第一层命令行搜索。

例子：

rg -n "LLM Wiki" wiki/

搜概念：

rg -n "RAG|retrieval|检索" wiki/

搜没有来源字段的页面：

rg -L "sources:" wiki/concepts/*.md

给 Agent 的 prompt：

回答问题前，请先用 index.md 判断方向。
如果 index.md 不够，请用 rg 搜索 wiki/ 下相关页面。
不要直接搜索 raw/，除非 wiki 信息不足。

这条规则很重要。

因为如果每次都回 raw，你又退回普通 RAG 了。

6. 第四层：本地 Markdown 搜索工具

当页面很多时，纯 rg 只能搜字面词。

问题是：

你搜“知识积累”，页面写的是“compounding artifact”；
你搜“体检”，页面写的是“lint”；
你搜“资料吸收”，页面写的是“ingest”。

这时可以考虑：

BM25；
hybrid search；
Markdown 专用搜索；
qmd 这类本地工具。

Karpathy 的 gist 里提到 qmd 作为可选工具，它的意义是：

本地搜索 Markdown；
可以给 LLM 通过 CLI 或 MCP 使用；
不必一开始搭复杂后端。

这类工具适合作为后期增强。

7. 第五层：向量检索

向量检索适合语义搜索。

但一开始不要急。

它引入新问题：

chunk 怎么切；
index 怎么更新；
结果怎么引用；
权限怎么做；
搜到 raw 还是 wiki；
过时页面怎么处理。

如果你要加，建议只索引 wiki/，不要先索引 raw/。

原因：

Wiki 是整理后的知识层，信噪比更高。

等 wiki 信息不足时，再让 Agent 回 raw 查证。

8. 搜索结果怎么用于回答

错误方式：

搜索到几个片段 -> 直接生成答案

正确方式：

搜索到候选页面 -> 读取完整 wiki 页面 -> 基于页面回答 -> 必要时追 raw

Prompt：

请回答问题：
<问题>

流程：
1. 读 index.md。
2. 如果需要，用搜索工具找候选 wiki 页面。
3. 读取候选页面全文。
4. 回答时列出参考页面。
5. 不要只根据搜索片段回答。

搜索片段只能帮你找门。

答案要进屋看完整页面。

9. 什么时候该加搜索

你会遇到这些信号：

Agent 每次都读很多无关页面；
index.md 太长，导航慢；
同义词导致找不到页面；
Graph View 已经很密；
query 经常漏掉相关旧页面；
lint 经常发现重复概念。

这时可以加搜索。

否则先别加。

10. 搜索层写进 AGENTS.md

## Search Policy

1. 默认先读 `index.md`。
2. 如果 index 不足，再搜索 `wiki/`。
3. 搜索只用于找到候选页面，不能只根据片段回答。
4. 只有当 wiki 信息不足时，才搜索 `raw/`。
5. 回答时引用 wiki 页面；如果使用 raw，说明原因。
6. query 后如果发现 index 漏掉重要页面，更新 index。

11. 一个渐进实现

阶段 1：只用 index

index.md

阶段 2：加 rg

rg -n "<keyword>" wiki/

阶段 3：加一个 search script

比如以后可以写：

./scripts/search-wiki "LLM Wiki 和 RAG"

先返回：

文件路径；
命中行；
摘要。

阶段 4：加专门工具

再考虑：

BM25；
vector；
qmd；
MCP server。

练习

用 rg 搜你的 Wiki：

rg -n "LLM Wiki" wiki/

问 Agent：

请基于 index.md 和 rg 搜索结果，找出所有和 query 有关的页面。
不要回答问题，只列候选页面。

再让它回答：

现在读取候选页面，回答：query 和 ingest 的区别是什么？

如果答案好，让它写回 synthesis。

小结

LLM Wiki 的搜索层应该渐进加入：

先用 index.md；
再用 Obsidian 搜索；
再用 rg；
再考虑 Markdown 搜索；
最后才上向量检索。

搜索不是核心。

核心仍然是：

raw；
wiki；
schema；
ingest；
query；
lint。

下一篇是完整项目：用 LLM Wiki 从零学习一个新领域。

参考资料

Karpathy: LLM Wiki