万字长文！LLM Wiki 技术深度拆解与落地实践

本文来源： 徐小夕（公众号：徐小夕）
原文链接： https://mp.weixin.qq.com/s/O25EFVskTIdJyZJ1w55sSg
发布时间： 2026-09-02 08:20

作者： 徐小夕　　发布时间： 2026-09-02 08:20

上期精彩：对比实测：为什么 JitWord 是目前最适配商用的 Web Word 编辑器？

这几年我们一直在深耕 AI Agent 与大模型应用，比如 JitKnow AI 知识库、JitWord协同AI文档、Pxcharts 超级表格，同时也持续在给大家分享 GitHub 上真正能落地、能解决实际问题的优质AI开源项目。

今天这篇不是产品发布稿，而是一篇攒了很久的技术复盘：我们为什么会从「坚定的 RAG 信徒」，变成「知识编译」路线的实践者，以及这条叫 LLM Wiki 的路，到底值不值得大家花时间读完。

所以，这是一篇 LLM Wiki 的深度技术落地分享，全文约 1w 字，有需要的可以仔细阅读本文。

文中提到的产品：JitKnow AI 知识库
产品地址：know.jitword.com

一、一个困扰我们很久的问题：知识为什么留不下来？

故事要从一次客户拜访说起。对方是一家制造企业的信息化负责人，他们已经用上了标准的 RAG 知识库：文档切片、向量化、提问时检索、拼上下文、生成答案。流程很标准，上线时大家都挺兴奋。

三个月后，他跟我们倒苦水：同一个设备故障，上周车间问了一遍，这周又有人问一遍，系统每次都吭哧吭哧重新检索、重新拼答案，「它好像从来不记得自己昨天答过什么」。

更糟的是，两个文档对同一参数的说法不一致，系统把新旧答案一起端上来，一线工人不知道该信谁。

回公司后我们盯着自家的架构图看了很久，发现这不是某一家产品的问题，而是传统 RAG 的「隐性问题」：它本质是一种「解释执行」的无状态架构——原始文档被机械分块塞进向量库，每次查询都从零开始检索、排序、组装，答完就忘。知识在每一次查询之后都消散了，无法形成积累。

我们意识到：企业知识管理的核心矛盾，不是「检索不够快」，而是「知识无法持续积累复用」和「检索精度撑不住业务」的双重困境。继续在老路上调参，解决不了这个问题。

二、范式转移：像编译器一样处理知识

后来我们系统研究了 Andrej Karpathy 提出的 LLM Wiki 思路，一下子被点醒了。它的核心设计哲学只有四个字：编译执行。

打个比方：传统 RAG 就像是现场口译——每次提问都临时翻一遍原始资料，翻完就忘；而 LLM Wiki ，像出版一本书——新资料入库时，LLM 就完成阅读、理解、提炼、关联，把碎片「编译」成结构化、语义互联、可溯源的 Markdown 知识文档，之后所有查询都直接读这本越写越厚的书。

处理的时机变了，三件事全变了：

① 知识有了状态：预编译的 Wiki 页面是持久化的「活资产」，每次新数据进来，系统基于已有知识存量去更新关联页面，知识随业务数据复利式积累，而不是每次查询后归零。

② 成本大幅度降低：算力消耗从查询高峰期转移到数据摄入的低峰期，同一份资料只编译一次。查询频率远高于摄入频率的企业场景，这笔账越算越划算——行业实测数据显示，相比传统 RAG，Token 消耗可以减少 84.6% - 95%。

③ 推理不断链：编译阶段就基于全局语义做深度整合，预构建的交叉引用把散落在不同文档里的相关知识点提前连好，跨文档推理不再出现逻辑断裂。

💬 一句话总结：RAG 是「每次把原料现做成菜」，LLM Wiki 是「把菜提前做好、持续改进配方」——前者喂饱一次，后者养出一座中央厨房。

三、三层分离架构：数据、知识与规则各管一段

LLM Wiki 的骨架是严格的三层分离架构，各层通过标准化协议交互——这既是可扩展性的保证，也是全链路可溯源的前提。

第一层：原始数据源（Raw Sources）。整个系统的「单一可信数据源」。运维手册、工单、客服记录、研发文档……一律以原始格式只读存放。

核心规则是「不可变」：任何知识更新只能通过添加新文件完成，谁也不能直接改原始资料。这条铁律从底层保证了每个结论都能反向追到出处，这是企业合规与故障排查的硬需求。

第二层：Wiki 知识编译层（Knowledge Layer）。区别于向量库「黑盒」的关键所在——这一层全是人类可读、可审计的 Markdown 文件，每个文件对应一个清晰的知识单元，带标准 YAML 元数据头（来源映射、编译时间戳、标签、关联列表），页面之间双向交叉引用。按 Karpathy 的落地规范，它又细分为四类页面：sources/ 来源页（每份资料的摘要与溯源依据）、entities/ 实体页（设备、产品、部门等有唯一标识的对象）、concepts/ 概念页（需 2 篇以上来源提及才创建，防止把孤立观点抬成「通用知识」）、pending/ 待处理页（来源存疑或内容冲突的，先进隔离区，不进检索层）。

第三层：规则约束层（Schema）。通常是 AGENTS.md 或 CLAUDE.md 这样的配置文件，装着三段式规则：知识怎么编译、页面之间怎么关联、冲突怎么判定。它的精髓是解耦——想调整摘要粒度或引用规则，改配置文件就行，不用动一行编译代码。

下面我画了一个三层的架构设计，方便大家理解：

这一层的运作逻辑是「LLM 全权维护、人类全程审计」：新数据进来，模型自动完成读懂、提炼、建页、更新关联页、维护双向引用这一整套动作；人只做价值判断——审核、校验、裁定冲突。

精力花在刀刃上，而不是花在机械且无意义的整理上。

按 Karpathy 落地实践的测算，这种自动维护机制能把传统 Wiki 常见的「知识死区」压到 10% 以内。

四、六阶段闭环：知识从零到一的产生过程

把「预编译」落到工程上，是一个知识沉淀的完整闭环。

下面我画了一张流程图，大家可以参考一下：

值得细说的三个环节

② 编译阶段——「只编译一次」是铁律。

LLM 先按文件类型调解析器（PDF 解析、OCR、多模态模型）转成纯文本，再按语义而不是版式做多级拆分，提炼实体、概念、结论；

然后按 Schema 模板生成规范页面归入对应目录；

最后做最关键的一步——全局增量更新：新页面与全量知识库做语义比对，所有受影响的关联页面同步刷新、交叉引用重算。

同一份资料只会被编译一次，此后所有查询直接读成品。

④ 冲突检测——不覆盖，只标记。

这是我认为最体现「工程审美」的设计：新数据与旧结论打架时，系统绝不直接覆盖，而是完整记录双方内容与时间戳、在页面里保留两种说法并标注来源、往矛盾管理页添加待办、推送人工审核工单、所有历史版本留档可回溯。

知识冲突从用户侧的「隐性问题」，被提前变成了系统侧的「显性待办」。企业落地时，这一步通常由业务专家完成最终裁定——机器负责发现，人负责拍板。

⑥ 迭代阶段——知识库自己「长大」。

业务低峰期，系统自动跑两类任务：全量巡检（查断链、找孤页、揪隐藏冲突并自动修复）和持续整合（结合近期数据与高频查询日志，补关联、调整索引优先级）。

这把「人找知识」变成了「知识来找人」——行业实践数据显示，运维良好的知识库上线 3-6 个月后，查询精准率能比初期再提升 15 个百分点以上。

五、三路混合检索：「泛化召回」如何变成「精准命中」

有人会问：都编译成 Wiki 了，查询时怎么检索？答案是我们采用了一套「意图理解 + 三路并行 + 融合重排」的组合拳。

下面我基于上面画的流程架构图，详细给大家介绍一下实现思路：

第一步，LLM 当「语义翻译器」，把自然语言问题转成结构化检索参数：核心意图是什么、范围限定在哪、哪些关键词优先。

第二步，三路检索同时开跑：BM25 关键词检索负责精准咬住业务术语和产品型号；知识图谱关系检索沿着预构建的交叉引用直接遍历知识链；向量语义检索兜住那些「没有关键词、但语义相关」的内容。

第三步，结果加权合并，交给 Qwen3-Reranker-4B 这类专用重排模型排序，返回 Top K。

为什么要这么折腾？因为我们发现单一的手段都会存在盲区，比如：

纯关键词抓不住语义，纯向量对专业术语容易「眼瞎」，而图谱检索正是编译阶段提前铺好的轨道——查「生产线异响振动」，系统能从「故障现象」页直接跳到「可能原因」「诊断步骤」「维修工单历史」「厂商手册」，一条完整的知识链一次返回，中间不断链。

📊 行业项目实测：三路混合检索相比纯向量检索，召回率高出 15% - 20%，语义命中率提升近 30 个百分点，而延迟保持在同一水平。

六、拆两段「代码」，看看编译产物长什么样

说再多不如直接实践。下面两段是 LLM Wiki 生态中典型的实现形态（简化示意），也是我们设计 JitKnow 时反复参考的结构。

第一段：一个编译产物的标准长相。

entities/空压机-3号机组.md（LLM 编译产物，简化示意）---
type: entity
title: 空压机-3号机组
created: 2026-08-12T03:14:22Z
updated: 2026-08-27T01:02:11Z
sources:
  - sources/运维手册-2026版.md
  - sources/维修工单-0821.md
related:
  - concepts/轴承过热的诊断方法.md
  - entities/二线空压机机组群.md
---

# 空压机-3号机组（实体页）

## 基本信息与结论摘要（编译提炼）
……

> ⚠️ 冲突标记：额定转速新旧说法不一致，
> 详见 pending/转速参数冲突-20260827.md

---
📎 溯源：本页面每个结论均链接至原始文档对应段落

大白话解读：这个页面就是「编译」二字的实物。YAML 头把「我从哪来、我关联谁、我什么时候被更新过」写得明明白白；正文是人话，不是切片；冲突不藏着掖着，显式挂出来指向待处理页。

最得意的一处细节是最后的溯源链接——点击任何一条结论，都能跳回支撑它的原始文档段落。这就是「行级溯源」：审计的人不用满库翻原文，机器也不怕被质疑「这话谁说的」。

第二段：Schema 规则文件——给模型立的「家规」。

AGENTS.md（规则约束层，简化示意）# 知识编译规则（示例）
1. 每份原始资料入库后，先生成对应 sources/ 摘要页。
2. 实体页在资料中首次提及时创建，后续资料持续补充属性。
3. 概念页须有至少2篇来源页提及方可创建。
4. 摘要保留关键数值与型号，禁止泛化表述。

# 冲突处理规则（示例）
1. 新数据与已有结论不一致时，禁止直接覆盖。
2. 保留新旧两种说法并标注来源，生成待处理页。
3. 仅当新来源权威性明显更高时，才在引用页置顶展示新结论。

大白话解读：这相当于给 LLM 立的家规。有价值的细节是第 3 条「概念页须 2 篇以上来源」——它防的是把某个文档里的孤立观点过度抽象成「企业通用知识」，等于在源头给知识噪声装了闸门。而「禁止直接覆盖」这条规则，决定了整个系统的知识是不断层的——旧结论永远有迹可循。

七、关键共识：不是替代 RAG，而是分层协同

写到这里必须把话说清楚：LLM Wiki 不是 RAG 的掘墓人，而是它的搭档。这已经是行业普遍共识——RAG 负责「覆盖广」，兜住海量非结构化数据的检索；LLM Wiki 负责「精度高」，把核心知识沉淀成可复用资产。

落地时最实用的是「核心-边缘」分层架构：高频高价值的核心知识（通常百篇以内）放进 Wiki 编译层，查询直读成品；查不到时自动降级到 RAG 辅助库兜底；最后由融合生成层把两路结果整合成带来源标注的答案。

下面我画了一张架构图，供大家参考：

这套组合拳的效果有实测背书：采用混合架构的企业知识库，相比纯 RAG 检索准确率提升 20% 以上，综合运营成本下降超过 40%。

八、算一笔创业团队最关心的账

作为创业团队，我们对成本天然敏感。LLM Wiki 的成本结构跟 RAG 有非常大的差异，成本上有非常大的优势：算力从查询侧搬到摄入侧，一次性编译，反复查询摊销。

行业调研的一组公开数据很能说明问题：传统 RAG 企业级部署成本在 3.44 万 - 5.8 万美元之间，月度运营 8100 - 19500 美元；

而 LLM Wiki 类方案初始部署约 1000 美元，月运营成本可低至 25 - 50 美元；Token 消耗减少 84.6% - 95%，顺带还缓解了长上下文「迷失在中间」效应。

但丑话也要说在前头：这笔账有个前提——「查询/摄入比」要够高。同一份知识被反复查询复用时，编译成本才被摊薄；如果每天灌进上百篇新文档却只有几十次查询，传统 RAG 反而更划算。

另外三个可调的旋钮大家也要心里有数：知识粒度（越细编译越贵、复用越好）、冲突检测频率（越勤算力越贵）、人工校验范围（越广人力越贵）。

技术选型从来不是选「最强」，而是选「最匹配」。

九、可以应用在哪些企业（个人观点，仅供参考）

🏢 科技公司——技术资产的沉淀与复用。研发文档、架构说明书、工单、周报散在各处，技术人员每天超过 20% 的时间花在找资料上；「预编译 + 自动增量更新」把非结构化文档变成结构化、可关联、可溯源的资产，实测知识沉淀效率提升 80% 以上，跨团队对信息「一次检索」搞定。

🏭 制造企业——现场级数据的价值萃取。运维记录、工单、老师傅的经验笔记是真正的金矿，但传统向量检索对设备型号、工艺参数这类术语的精准匹配撑不住产线要求。多源数据编译成故障诊断知识链后，行业实测检索准确率可达 90% 以上，设备维修平均耗时缩短超过 30%——隐性经验第一次变成了可复用的显性资产。

两类的共同特征：知识复用频率高、精度要求高、多源强关联。反过来，知识更新极快而查询很少的场景，暂时别上车。