LLM Wiki 构建手册：可直接落地的标准流程

快速上手构建专属LLM Wiki，一份清晰、可落地的标准流程，帮你高效组织和管理知识。
核心内容：
1. 从资料准备到增量编译的完整构建流程
2. 知识库约束配置与全局索引设计
3. 针对不同规模知识库的两种查询模式

是时候开始动手构建LLM Wiki了

今天的内容，尽量遵循 Karpathy 原生 LLM Wiki 范式与业界通用工程实践。但毕竟是一个新事物，至于到底好不好用，我们需要自己去尝试，自己去寻找适用和不适用的场景。

01

—

资料准备

1. 建立 /raw文件夹，放入所有原始资料：Markdown、PDF、TXT 等。

2. 强制规范：系统只读取/ raw目录，永远不修改、不覆盖原始文件。

3. /raw文件是唯一可信数据源，所有 Wiki 内容均由此增量生成。

raw只是一个示例，至于起什么名字，你自己决定。

—

知识库约束配置

可新建 SCHEMA.md 或 PURPOSE.md 配置文件，用于：

• 定义知识库主题边界、写作风格、知识粒度

• 统一页面结构、避免编译发散

作用：约束 LLM 提炼知识的方向，保证全站风格、标准统一。

03

—

增量编译

以文件为粒度做增量编译：

1. 读取 /raw中新增/变更文件（旧文件通过哈希缓存自动跳过，不重复处理）

2. 提炼核心实体、概念、论点，生成完整、独立、结构化的 Wiki 单页（不是碎片、不是分块）

3. 自动在页面间建立前向 [[wikilink]] 知识网络（提醒：建议反向link不要直接写到wiki页面中，增加页面的复杂度和tokens消耗。课题使用脚本来建立一个反向文档，在需要时读取。）

4. 级联更新：新增资料会自动更新所有相关旧页面、旧链接、冲突信息（提醒：级联更新有可能会出现级联爆炸，大幅提高tokens的消耗，甚至导致级联失败，在这里可以添加限制，例如级联更新最大深度＜20等）

5. 自动刷新全局索引目录

04

—

全局索引

index.md 是 LLM Wiki 的系统级“目录”表与全局入口，作用是让模型看懂知识库全貌：

• 存储：所有页面标题 + 核心摘要

• 中小规模：单文件顶层索引即可使用

• 大规模优化：当 index 总内容超出模型上下文窗口、或页面数量过多时，分层拆分多级索引。例如，保留全局index.md，但其内容是指向topics的，然后topics下有具体的主题索引md，例如 topics/Agent.md，Agent.md中是当前主题下的wiki页面索引。具体要分多少层，需要按照你项目的要求来决策。

05

—

查询模式

模式A：原生标准模式（中小型知识库默认）

适用场景：知识库规模适中、索引可完整塞进 LLM 上下文

流程：

1. LLM 完整读取顶层 index.md

2. 根据摘要自主判断相关页面

3. 读取完整 Wiki 页面全文

4. 依靠页面内 wikilink 做多跳推理、完整上下文作答

特点：零向量、零检索碎片、零 chunk 割裂。这是 LLM Wiki 最纯正、效果最好的原生范式。

模式B：大规模扩展模式（社区工程方案）

适用场景：知识库极大，维护分层索引复杂低效

本质：向量检索只做页面定位，不直接生成答案

流程：

1. 对 Wiki 全页建立向量索引，每个chunk都要标记父页面ID

2. 用户提问 → 向量+关键词混合检索 → 召回 Top-K chunks

3. 根据chunks中的父页面 ID 从文件系统读取完整原始 Wiki 页面

4. LLM 基于完整页面 + wikilink 多跳推理作答

关键点：

• 向量检索是辅助定位插件，不替代原生索引范式

• 绝对不使用碎片 chunk 作为上下文（这是 LLM Wiki 与传统 RAG 的本质区别）

• index 依然保留，降级为知识分类概览

还是那句话，没有最好的技术，只有最适配场景的技术。

毕竟有的场景重视质量但对价格不敏感；而有的场景质量可以差一些，但是成本必须控制……

不存在不被现实约束的需求和产品，适合的才是最好的。

登录查看剩余 70% 内容