不止是RAG，LLM Wiki 如何构建可累积的工程化知识库

bboyzqh

495人浏览 · 2026-06-13 13:19:02

bboyzqh · 2026-06-13 13:19:02 发布

一. LLM Wiki 核心思想

Wiki 是一项持续积累的长期资产。传统 RAG 在每次查询时均需从零检索，而 LLM Wiki 在内容摄入及问答过程中会同步更新和维护自身知识库。知识库按 raw/（原始素材）和 wiki/（整理后的实体页、主题页、摘要页）分类存储，交叉引用在迭代中逐步建立，矛盾点在持续标注中不断明确，综合分析也随之沉淀成形。知识随时间沉淀累积，而非反复消耗。

传统 RAG: 文档 → 查询 → 答案 (知识丢失)
LLM Wiki: 文档 → 摄入 → Wiki 丰富 → 查询 → 答案 (知识累积)

附：

基于 Andrej Karpathy 的 llm-wiki 方法论 github 地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

二. LLM Wiki 三大操作

2.1 知识 Ingest（提取）

发生在知识 Ingest 的时机主要有：知识初始化构建和增量更新。ingest 新文档时典型的流程图如下：

LLM Wiki 核心目录如下：

Wiki Root（知识库根目录）/
  ├── .wiki-schema.md          # 知识库 schema，记录语言配置、别名词表、关系类型等元信息
  ├── .wiki-cache.json         # 缓存文件，记录 raw 文件与 wiki 页面的映射关系
  ├── index.md                 # 知识库总览索引
  ├── log.md                   # 活动日志，记录所有 ingest、query、digest 操作
  │
  ├── raw/                     # 原始素材存放目录，保留出处，便于后续回溯
  │   ├── articles/            # 网页文章
  │   ├── tweets/              # X/Twitter
  │   ├── wechat/              # 微信公众号
  │   ├── xiaohongshu/         # 小红书（手动粘贴）
  │   ├── zhihu/               # 知乎
  │   ├── youtube/             # YouTube 字幕
  │   ├── pdf/                 # PDF 文件
  │   └── assets/              # 素材图片等附件
  │
  ├── wiki/                    # Wiki 页面目录（核心内容，经AI编译过的结构化页面）
  │   ├── sources/             # 素材摘要页（每篇素材对应一页）
  │   ├── entities/            # 实体页（概念、人物、技术等独立页面）
  │   ├── topics/              # 主题页（研究主题汇总）
  │   ├── comparisons/         # 对比分析页
  │   ├── synthesis/           # 综合性报告页（含 sessions/ 子目录存放对话结晶化结果）
  │   ├── queries/             # 查询结果页
  │   ├── knowledge-graph.md   # Mermaid 格式知识图谱
  │   ├── knowledge-graph.html  # 交互式知识图谱（双击可直接在浏览器打开）
  │   └── graph-data.json      # 图谱数据（节点、边权重、社区聚类等）
  │
  └── .wiki-tmp/               # 临时文件（ingest 流程中间产物）

2.2 知识 Query（查询）

LLM Wiki 提供的检索方案：用户提问 -> 先读index.md定位相关页面 -> 读取相关页面 -> 综合回答附引用：

上述流程无法检索到 index.md 未索引到但源文件存在的知识，可引用向量索引（比如采用 Chroma+SQLite 方案）来解决这个问题，核心的知识检索流程：

用户提问 -> 向量语义检索 topK 知识点 -> 读index.md页面 -> 获取父章节摘要（父节点一般是目录，可以取目录名和所有file类型子节点的摘要）及兄弟文档标题 -> 综合回答附引用：

2.3 知识Lint（健康检查）

知识库需要让 LLM 周期性检查 Wiki 的健康状况（比如发现矛盾、过时声明、孤儿页面、缺失交叉引用、知识空白等），并通知用户修复这些缺陷，核心流程如下：

三. LLM Wiki 在工程上的应用

LLM Wiki 的工程化应用架构主要涵盖管理端与应用端两大核心模块：管理端聚焦于知识库的构建与评测，应用端则负责知识库检索技能（Skill）的调用与执行。

在应用端，AI 助手具备高度的扩展性，支持同时挂载多个知识库及技能插件。在管理端，系统提供了灵活的知识库构建机制，包含标准构建与自定义构建等多种方式，以满足不同业务场景的需求。此外，系统内置了专用的知识库检索技能（knowledge-search），用于实现高效、精准的信息检索。

为保障知识质量，系统建立了自动化的评测闭环：当知识库完成初始构建或增量更新后，系统将自动触发评测任务，以持续验证并优化知识库的检索效果。

四. 一些思考

LLM Wiki 方法论适合小型知识库（比如上百篇文章），大型知识库还要是 RAG
值得注意的一点，知识构建和增量更新都需要 LLM 去读取知识库内容，比较消耗 token
LLM Wiki 的核心方法论需深刻理解以下两点：
1. 明确产物定位：Wiki 的构建结果本质上是“辅助检索的产物”。概念、实体或 Topic 页面不应直接堆砌源文档内容，而应提炼并存储 Overview、核心要点等高价值关联信息。
2. 遵循渐近式检索路径：检索过程应遵循“Index + Overview（全局定位） -> 概念/实体/Topic（知识枢纽） -> Raw 文件（事实溯源）”的三级递进策略。同时，index.md 索引目录中需嵌入文档摘要信息，以此作为检索的“符号表”，实现更精准的知识定位。
在不同业务场景下，知识库的构建约束存在显著差异。例如，数据资产类知识库侧重于表结构知识的提取，而问答（QA）知识库则更关注核心概念的抽取。因此，知识库系统需具备接收并适配用户自定义约束的能力。这些约束最终将结构化地体现在 LLM Wiki 生成的 .wiki-schema.md 文件中。当约束条件较为复杂或繁多时，建议引入 schema 文件夹，对各类规则与约束进行模块化分类管理，以提升系统的可维护性与扩展性。
支持自定义目录是否合理？这是一个值得讨论的问题，个人理解：知识的抽取通常先对 entity、concept和topic进行提取，理论上用户只能看到源文档、执行检索知识操作，中间产生的 entity 等目录应该对用户不可见。另外知识库构建出的结构本质上是树上的非叶子节点，叶子节点是 raw 文件。如果非要支持自定义目录的话，流程应该是这样的：entity、concept和topic进行提取 -> 再将entity、concept和topic等挂到自定义目录上。

最后推荐可借鉴的 LLM Wiki 开源SKILL：

karpathy-llm-wiki（Astro-Han）：GitHub - Astro-Han/karpathy-llm-wiki: Agent Skills-compatible LLM wiki for Claude Code, Cursor, and Codex. Build a Karpathy-style knowledge base from raw sources, citations, and linting. · GitHub

轻量 Agent Skill 封装，把 Karpathy LLM Wiki 方法论打包为可安装技能（适配 Claude Code/Cursor/Codex），提供 Ingest/Query/Lint 三操作，遵循 agentskills.io 标准。本质是 SKILL.md 规范+模板，依赖宿主 Agent 执行，无 GUI、无向量检索和知识图谱等扩展。