Hermes+LLM Wiki：我的知识库管理进化之路

从RAG到LLM Wiki：我的知识库管理进化之路

作者：科技界的一粒微尘
用AI把碎片知识编织成网，看LLM Wiki如何让知识产生复利

📋 本文概览： RAG（检索增强生成）和LLM Wiki是两种互补的知识管理方法。RAG擅长"搜"，Wiki擅长"织"。本文以搭建「嵌入式Linux知识体系」Wiki为例，从架构设计到批量导入17份海思文档，完整展示Wiki的创建过程、RAG与Wiki的11维对比、以及日常维护和使用的实操指南。读完你会理解：为什么Wiki不是RAG的替代品，而是知识管理的下一个阶段。

▲ 左侧：14个Wiki页面通过[[wikilinks]]紧密互连，形成知识网络 | 右侧：17份源文档通过索引接入

一、从RAG说起：搜索很好，但还不够

去年我用TF-IDF + 纯NumPy搭了一个本地RAG系统。20篇HI3519DV500的SDK文档、硬件设计指南、编译方案全扔进去，拆成418个chunk，5000维TF-IDF向量，查询速度10毫秒以内。问"DDR走线阻抗要求"，能秒出3个高相关片段和出处链接。

RAG解决了一个明确的问题：从海量文档中快速找到相关片段。这是它的核心价值，也是它的天花板。

用了几个月后，三个痛点越来越明显。

痛点一：同一个概念散落在五六个chunk里。 比如MPP（Media Processing Platform）的概念，“VI负责视频输入”“VPSS做缩放降噪”“VENC硬编码”——这三句话分别出在三个不同chunk里。每次聊MPP pipeline，我都要从三四个碎片里拼凑完整答案。知识在源文档里分散，在RAG的检索结果里也分散。

痛点二：查过的知识下次还得从头查。 RAG没有记忆。今天查了DDR走线规则，明天同样的问题还得再来一遍"检索→拼凑→回答"的流程。检索结果每次都一样，但拼凑的心智成本每次都得重新付。知识没有沉淀。

痛点三：文档之间的关系全靠人脑。 MPP pipeline和RTSP推流有什么关系？RTSP推流和OS04A10的时钟配置有什么关联？DDR设计和电源管理有什么交叉？RAG的余弦相似度算不出来这些——它只看关键词重叠，不理解概念之间的逻辑联系。

这三个痛点指向同一个根因：RAG是"搜"，不是"学"。搜得越快，积累越慢——因为每次都从零开始，没有存量。

这让我开始关注Karpathy提出的LLM Wiki。

二、LLM Wiki：不是搜索引擎，是知识编辑器

Andrej Karpathy在一个GitHub Gist里分享了他的Wiki工作流。核心思想很简单：让AI一次性把源文档读完，提炼成结构化的wiki页面，然后持续维护。

它不是搜索引擎。搜"MPP"不会给你10个高亮片段。你会直接打开concepts/mpp-media-pipeline.md，看到一份完整的、有交叉引用的、有出处的知识页面。

Wiki的三层架构

第一层是raw/——原始资料。源文档、论文、笔记扔进去，只读、不可修改。每一份源文件带frontmatter元数据：来源URL、摄入日期、内容SHA256哈希。

第二层是wiki页面——entities（实体）、concepts（概念）、comparisons（对比）、queries（查询）。这些是AI从源文件中提取和总结的，人工审核后入库。每个页面必须包含frontmatter（标题、日期、标签、来源）和至少2个交叉引用。

第三层是SCHEMA.md——Wiki的"宪法"。定义了文件名规范、标签分类体系、页面创建阈值（一个概念必须出现在2+源文件中才创建独立页面）、更新策略（新旧信息冲突时标注双方立场，不直接覆盖）。

整体架构如图：

RAG和Wiki的11维对比

这个表是我用了几个月RAG、又搭了Wiki之后总结的：

RAG是"随时翻的工具书"，Wiki是"越写越厚的笔记本"。 前者适合查"电源管理有几种电压域"，后者适合理解"为什么电源管理是嵌入式开发的基石"。

三、实操：搭建嵌入式Linux知识体系Wiki

理论说完了，看实操。我用17份HI3519DV500文档作为种子，建了一个「嵌入式Linux知识体系」Wiki。

3.1 初始化：定义领域和规则

第一步是写SCHEMA.md。这不是走过场——它决定了Wiki的质量上限。

我为这个领域定义了标签体系，分为三个层级。

技术领域标签包括boot（U-Boot/启动流程）、kernel（内核配置/模块）、driver（设备驱动）、dtb（设备树）、filesystem（rootfs/initramfs）、build（Buildroot/交叉编译）、debug（gdb/ftrace/oops）、rt（PREEMPT_RT/实时调度）、memory（内存管理/DMA）、networking（网络栈/socket）、security（安全启动/SELinux）。

硬件标签包括soc（SoC架构）、peripheral（SPI/I2C/UART）、memory-hw（DDR时序）、power（电源管理/上电时序）、interrupt（GIC中断控制器）。

平台标签按芯片分类：hisi（海思Hi35xx）、rockchip（瑞芯微）、nxp（NXP i.MX）、allwinner（全志）、ti（TI Sitara）。

此外还有工程标签：best-practice（最佳实践）、pitfall（踩坑记录）、optimization（性能优化）、comparison（对比分析）、tutorial（step-by-step教程）。

每个wiki页面必须打上至少一个标签，标签必须来自SCHEMA.md中定义的集合——不能用没注册过的标签，防止标签泛滥失去意义。

3.2 批量导入：17份源文件 → 14个Wiki页面

源文件来自之前整理的HI3519DV500知识库，按三大板块组织。

操作类有三份文档。核心的「开发板操作命令手册」涵盖SSH连接、驱动加载、传感器时钟配置、RTSP推流（VENC/AI ISP/NPU三种模式）、拉流查看等完整操作流程。另外还有双目摄像头同步方案和显示屏VO不出图排查方案。

硬件类有八份专题总结加上两份综合文档。芯片概览涵盖架构和规格；时钟复位涉及时钟树和PLL配置；电源管理涵盖多路供电和上下电时序；DDR设计涉及走线规则和ODT配置；启动配置涵盖Boot模式和介质选择；外设接口涵盖MIPI/USB/SPI/I2C等；排查量产涵盖故障诊断；NAND Flash涵盖坏块管理。综合文档「硬件设计知识提炼」是从海思三份官方文档中浓缩的803行精华，「硬件原理排查指南」是一份747行的全芯片排查手册。

软件类有三份方案文档。编译方案v1和v2是前期规划，编译实战总结是最终落地版，记录了6步编译流水线的完整过程：依赖安装5分钟、工具链安装2分钟、SDK解压12分钟产出2.6GB源码、BSP全编译20分钟产出14MB uImage、MPP Sample编译5分钟产出49个ARM64 ELF、固件打包1分钟产出249MB可烧录镜像。

AI一次性读取这17份源文件（共约1.2MB文本），识别出3个核心实体和11个重要概念，然后为每个创建独立页面。整个过程自动化，但我在生成后逐页审核了以下内容：

3.4 查看Wiki的目录结构

Wiki生成完成后的目录如下。这个结构本身就是一种导航：

embedded-linux-wiki/
├── SCHEMA.md              ← 领域定义 + 标签体系 + 页面阈值
├── index.md               ← 总目录，14个页面的一行摘要
├── log.md                 ← 操作日志（append-only）
├── raw/                   ← 原始资料（只读，不可修改）
│   └── articles/          ← 17份源文件，含SHA256哈希
├── entities/              ← 3个实体页面
│   ├── hi3519dv500.md
│   ├── hongou-pi.md
│   └── os04a10.md
├── concepts/              ← 11个概念页面
│   ├── mpp-media-pipeline.md
│   ├── rtsp-video-streaming.md
│   ├── cross-compilation-toolchain.md
│   ├── bsp-build-system.md
│   ├── power-management.md
│   ├── boot-configuration.md
│   ├── npu-ai-inference.md
│   ├── ai-isp.md
│   ├── sensor-clock-configuration.md
│   ├── ddr4-interface-design.md
│   └── peripheral-interfaces.md
├── comparisons/           ← 对比分析页面
└── queries/               ← 有价值的查询结果存档

观察几个关键数字：17份源文件产出了14个wiki页面（3个实体+11个概念），wIKi页面总计约750行文本。源文件的1.2MB被浓缩到wiki页面的45KB，压缩比约27:1——但每一行都保留了出处标记，可追溯到原文。

3.3 Wiki的核心机制：出处与交叉引用

每个wiki页面都有两个关键设计。

出处标记——段落末尾的^[raw/articles/source.md]让每一句话都可追溯。比如rtsp-video-streaming.md中关于时钟配置的那段，标记了出自操作命令手册。不确定AI总结得对不对？点开原始文档直接核对。这解决了"AI幻觉"问题——AI可能总结有偏差，但出处给了你验证的能力。

交叉引用——每个页面至少链接到2个其他页面。sensor-clock-configuration同时链接到os04a10（传感器）、hongou-pi（开发板流程）和power-management（掉电机制）。这种链接织成一张网：你从这个节点出发，顺着链路能遍历整个知识体系。这是RAG做不到的——RAG只给你孤立的chunk，Wiki给你路径。

四、日常使用：查、读、追

查询流程

进入Wiki的入口只有一个：打开index.md。这是总目录，每个页面附一句话摘要。想知道编译相关有哪些内容，扫一眼Concepts区域就能看到cross-compilation-toolchain和bsp-build-system。

看到感兴趣的页面，Obsidian里点一下[[wikilinks]]就跳过去。读bsp-build-system.md时看到[[cross-compilation-toolchain]]的引用，再点一下跳过去。

怀疑AI总结有误？看段落末尾的出处标记，找到源文件核实原文。

Obsidian集成

Wiki就是一个普通目录，扔进Obsidian就是vault。

用Graph View看知识网络：hi3519dv500是中心节点，hongou-pi、mpp-media-pipeline、npU-ai-inference等从不同角度链接到它。能看到哪些概念被引用最多、哪些是孤岛。

用Dataview做标签筛选——列出所有打hisi标签的页面、所有confidence: low的需要补充的页面。

与RAG配合使用

我的HI3519DV500知识库同时用了RAG和Wiki。场景决定了用什么工具。

查寄存器地址、命令参数、配置值——这些是RAG的强项。零散信息，毫秒级出结果，不需要上下文。

理解一个概念的全貌、梳理两个方案的区别、系统性学习某个主题——这些是Wiki的领地。Wiki给你完整的上下文和关联路径。

两者的互补架构可以这样理解：日常开发遇到问题，RAG秒出答案。周末想系统性梳理知识，打开Wiki深入阅读。写技术文章时，Wiki提供结构框架，RAG补充细节数据。

五、维护：Wiki如何持续生长

Wiki的价值在于持续维护。腐烂的Wiki比没有Wiki更糟。

添加新知识

有新文档时——比如一份新写的DDR PHY training笔记——把它放到raw/articles/目录。路径和文件名保留原始格式。

然后告诉AI"ingest这份新文档"，AI会自动完成四步操作。

第一步，计算SHA256。 对照raw/里的哈希，如果文件内容没变就跳过，防止重复处理。

第二步，扫描已有页面。 找出和新源相关的实体和概念。比如DDR PHY training文档涉及DDR设计，搜出已有的ddr4-interface-design.md。

第三步，更新或创建页面。 已有页面追加新信息，更新日期。新出现的概念（比如PHY training在多个源文件中反复出现）创建新页面并建立交叉引用。一份资料可能触发5-15个页面的更新——这是Wiki的"复利"：雪球越滚越大。

第四步，更新导航。 新页面加入index.md的正确分类下，操作追加到log.md。

定期健康检查

Wiki需要lint。我在SCHEMA.md里定义了一套检查规则。

检查孤岛页面——没有其他页面链接过来的页面。如果queries/里有个查询结果页从来没被引用过，说明它没融入知识网。检查断裂的wikilinks——指向不存在的页面。检查过期内容——updated日期超过90天没刷新。检查低置信度页面——confidence: low标记的页面需要补充来源。源文件SHA256对比——如果raw/里的源文件被人改过，哈希对不上，说明有内容漂移。

这些检查保证了Wiki不会悄悄地腐烂。

六、工具与命令速查

Wiki是纯文本（Markdown），不需要任何数据库。日常操作只需要终端和AI助手。

查询Wiki

搜索Wiki有两种方式。精确匹配用search_files（底层是ripgrep），语义搜索用AI直接帮你读。

# 按关键词搜wiki页面内容
search_files "DDR 走线" path="/home/ros2/obsidian/embedded-linux-wiki"

# 搜特定标签的页面
search_files "tags:.*hisi" path="/home/ros2/obsidian/embedded-linux-wiki" file_glob="*.md"

# 查看最近操作记录
read_file "/home/ros2/obsidian/embedded-linux-wiki/log.md" offset=-20

AI助手方式更自然——直接问"wiki里关于电源管理有哪些内容"，AI会自动读取index.md定位相关页面，然后打开读取并总结。

添加新知识

把新文档（比如一篇ddr-phy-training-note.md）放到raw/articles/目录下，然后对AI说"ingest这份新文档到wiki里"。AI会执行标准流程。

健康检查

定期跑lint确保Wiki不腐烂：

# AI会自动执行以下检查：
# 1. 孤岛页面（无入站链接）
# 2. 断裂的[[wikilinks]]
# 3. 过期页面（超过90天未更新）
# 4. 低置信度页面（confidence: low）
# 5. 页面过大（超过200行需要拆分）
# 6. 标签滥用（不在SCHEMA.md定义中的标签）
# 7. 源文件SHA256漂移检测

检查结果会按严重程度分级输出，并追加到log.md。

页面规模控制

Wiki页面有200行的软上限。当一个概念太庞大时（比如peripheral-interfaces.md从68行开始可能随着USB调试、SPI踩坑等内容加入而增长），应该拆分成子页面：

concepts/peripheral-interfaces.md       ← 总览页，链接所有子页面
concepts/spi-debugging.md               ← SPI调试子页面
concepts/usb-otg-configuration.md       ← USB OTG配置子页面

拆分后总览页保留各子页面的摘要和链接，细节移到子页面。

七、RAG和Wiki不是二选一

最后说一个重要的结论。

我不认为应该用Wiki替代RAG。它们解决的是不同层次的问题，互补而非互斥。

一个朴素的判断标准：如果答案是零散信息——一个寄存器地址、一个命令参数、一个配置值——RAG更快。如果答案需要上下文——一个概念的定义、一个pipeline的原理、两个方案的区别——Wiki更好。

随着知识库增长，两者还可以合流。当文档超过5000个时，用Wiki的结构化页面作为RAG的chunk来源，检索精度会比从原始文档直接切chunk高得多——因为wiki页面已经经过提炼和交叉引用，每个chunk的"信息密度"更高。这是下一个阶段的事，但架构上已经预留好了。

如果本文对你有帮助，欢迎点赞、在看、转发。

🔍 关注「AI的探索之旅」，获取更多AI开发实战经验。