Deep Dive：LLM Wiki 企业知识库范式——从 RAG 到知识预编译的架构与实践

在企业知识管理里，大家几乎人手一个 RAG（检索增强生成）知识库：文档切片、向量化、提问时检索、拼上下文、生成答案。流程很标准，上线时都很兴奋。可运行几个月后，很多人会撞上同一个困惑：

同一个问题，上周车间问了一遍，这周又有人问一遍------系统每次都重新检索、重新拼答案，它好像从来不知道自己昨天答过什么。

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

这不是某一款产品的 bug，而是传统 RAG 的隐性问题。今天这篇，我们把 Andrej Karpathy 提出的 LLM Wiki（知识编译） 范式拆开讲清楚：它想怎么解决这个问题，落地到企业是什么架构，钱到底花在哪。

一、先理解问题：RAG 的「解释执行」困局

传统 RAG 本质上是一种 「解释执行」的无状态架构：

原始文档被机械分块塞进向量库；
每次查询都从零检索、排序、组装上下文；
答完就忘，知识无法累积；
新旧说法冲突时，答案一起端上来，没有裁决机制。

它的核心矛盾不是"检索不够快"，而是 "知识无法持续积累复用" 和 "检索精度撑不住业务需求"。继续在老路上调参，解决不了这个问题。

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

LLM Wiki 的核心设计哲学只有四个字：编译执行。

打个比方：

	传统 RAG	LLM Wiki
类比	现场口译：每次提问都临时翻一遍原始资料，翻完就忘	出版一本书：资料入库时 LLM 读完、理解、提炼、关联，把碎片编译成结构化文档
处理时机	查询时	摄入时
结果	答完就忘	一本越写越厚的书

处理时机一变，三件事全变：

知识有了状态 ：预编译成的 Wiki 页面是持久化资产，每次新数据进来基于已有知识库存量更新关联页，知识随业务数据复利式积累，而不是每次查询后归零。
成本大幅降低 ：算力从查询高峰期转移到数据摄入的低峰期，同一份资料只编译一次。行业实测，Token 消耗可减少 84.6% - 95%。
推理不断链：编译阶段基于全局语义做深度整合，预构建的交叉引用把散落在不同文档的相关知识点提前连好，跨文档推理不出现逻辑断裂。

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

三、三层分离架构（可溯源是设计出来的）

LLM Wiki 的骨架是严格的三层分离架构，每层职责单一、通过标准化协议交互------这既是可扩展性的保证，也是全链路可追溯的前提。
#mermaid-svg-tppa8dtOprINsosG{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-tppa8dtOprINsosG .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-tppa8dtOprINsosG .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-tppa8dtOprINsosG .error-icon{fill:#552222;}#mermaid-svg-tppa8dtOprINsosG .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-tppa8dtOprINsosG .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-tppa8dtOprINsosG .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-tppa8dtOprINsosG .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-tppa8dtOprINsosG .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-tppa8dtOprINsosG .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-tppa8dtOprINsosG .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-tppa8dtOprINsosG .marker{fill:#333333;stroke:#333333;}#mermaid-svg-tppa8dtOprINsosG .marker.cross{stroke:#333333;}#mermaid-svg-tppa8dtOprINsosG svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-tppa8dtOprINsosG p{margin:0;}#mermaid-svg-tppa8dtOprINsosG .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-tppa8dtOprINsosG .cluster-label text{fill:#333;}#mermaid-svg-tppa8dtOprINsosG .cluster-label span{color:#333;}#mermaid-svg-tppa8dtOprINsosG .cluster-label span p{background-color:transparent;}#mermaid-svg-tppa8dtOprINsosG .label text,#mermaid-svg-tppa8dtOprINsosG span{fill:#333;color:#333;}#mermaid-svg-tppa8dtOprINsosG .node rect,#mermaid-svg-tppa8dtOprINsosG .node circle,#mermaid-svg-tppa8dtOprINsosG .node ellipse,#mermaid-svg-tppa8dtOprINsosG .node polygon,#mermaid-svg-tppa8dtOprINsosG .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-tppa8dtOprINsosG .rough-node .label text,#mermaid-svg-tppa8dtOprINsosG .node .label text,#mermaid-svg-tppa8dtOprINsosG .image-shape .label,#mermaid-svg-tppa8dtOprINsosG .icon-shape .label{text-anchor:middle;}#mermaid-svg-tppa8dtOprINsosG .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-tppa8dtOprINsosG .rough-node .label,#mermaid-svg-tppa8dtOprINsosG .node .label,#mermaid-svg-tppa8dtOprINsosG .image-shape .label,#mermaid-svg-tppa8dtOprINsosG .icon-shape .label{text-align:center;}#mermaid-svg-tppa8dtOprINsosG .node.clickable{cursor:pointer;}#mermaid-svg-tppa8dtOprINsosG .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-tppa8dtOprINsosG .arrowheadPath{fill:#333333;}#mermaid-svg-tppa8dtOprINsosG .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-tppa8dtOprINsosG .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-tppa8dtOprINsosG .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tppa8dtOprINsosG .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-tppa8dtOprINsosG .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tppa8dtOprINsosG .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-tppa8dtOprINsosG .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-tppa8dtOprINsosG .cluster text{fill:#333;}#mermaid-svg-tppa8dtOprINsosG .cluster span{color:#333;}#mermaid-svg-tppa8dtOprINsosG div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-tppa8dtOprINsosG .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-tppa8dtOprINsosG rect.text{fill:none;stroke-width:0;}#mermaid-svg-tppa8dtOprINsosG .icon-shape,#mermaid-svg-tppa8dtOprINsosG .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-tppa8dtOprINsosG .icon-shape p,#mermaid-svg-tppa8dtOprINsosG .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-tppa8dtOprINsosG .icon-shape .label rect,#mermaid-svg-tppa8dtOprINsosG .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-tppa8dtOprINsosG .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-tppa8dtOprINsosG .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-tppa8dtOprINsosG :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 原始数据层 Raw Sources
知识编译层 Knowledge Layer
规则约束层 Schema
LLM 编译一次
生产与维护
AGENTS.md / CLAUDE.md

编译规则·关联规则·冲突规则
sources 来源页
entities 实体页
concepts 概念页

需≥2来源提及
pending 待审核页
PDF / Word / 图片 / 工单 / 记录

只读·不可变·单一可信源

第一层原始数据层：整个系统的"单一可信数据源"，一律以原始格式只读存放。核心规则是"不可变"------知识更新只能通过添加新文件完成，谁也不能直接改原始资料。这条铁律保证了每个结论都能反向追到出处。
第二层知识编译层 ：区别于向量库"黑盒"的关键。这一层全是人类可读、可审计的 Markdown 文件 ，每个文件带标准 YAML 元数据头（来源映射、编译时间戳、标签、关联列表）。按 Karpathy 落地规范分为四类页面：
- sources/ 来源页：每份资料的摘要与溯源依据
- entities/ 实体页：设备、产品、部门等有唯一标识的对象
- concepts/ 概念页：需 2 篇以上 source 提及才创建，防止孤立观点被抬成"通用知识"
- pending/ 待处理页：来源存疑或内容冲突的，先进隔离区，不进检索层
第三层规则约束层：通常是 AGENTS.md 或 CLAUDE.md 这样的配置文件，装着三段式规则：知识怎么编译、页面怎么关联、冲突怎么判定。精髓是解耦------想调整摘要粒度或引用规则，改配置文件即可，不用动一行编译代码。

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

四、六阶段实践工作流：知识从零到一

把"预编译"落到工程上，是一个完整闭环：
#mermaid-svg-XWSG7ljOsKVUz6oG{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-XWSG7ljOsKVUz6oG .error-icon{fill:#552222;}#mermaid-svg-XWSG7ljOsKVUz6oG .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-XWSG7ljOsKVUz6oG .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-XWSG7ljOsKVUz6oG .marker{fill:#333333;stroke:#333333;}#mermaid-svg-XWSG7ljOsKVUz6oG .marker.cross{stroke:#333333;}#mermaid-svg-XWSG7ljOsKVUz6oG svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-XWSG7ljOsKVUz6oG p{margin:0;}#mermaid-svg-XWSG7ljOsKVUz6oG .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster-label text{fill:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster-label span{color:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster-label span p{background-color:transparent;}#mermaid-svg-XWSG7ljOsKVUz6oG .label text,#mermaid-svg-XWSG7ljOsKVUz6oG span{fill:#333;color:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG .node rect,#mermaid-svg-XWSG7ljOsKVUz6oG .node circle,#mermaid-svg-XWSG7ljOsKVUz6oG .node ellipse,#mermaid-svg-XWSG7ljOsKVUz6oG .node polygon,#mermaid-svg-XWSG7ljOsKVUz6oG .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-XWSG7ljOsKVUz6oG .rough-node .label text,#mermaid-svg-XWSG7ljOsKVUz6oG .node .label text,#mermaid-svg-XWSG7ljOsKVUz6oG .image-shape .label,#mermaid-svg-XWSG7ljOsKVUz6oG .icon-shape .label{text-anchor:middle;}#mermaid-svg-XWSG7ljOsKVUz6oG .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-XWSG7ljOsKVUz6oG .rough-node .label,#mermaid-svg-XWSG7ljOsKVUz6oG .node .label,#mermaid-svg-XWSG7ljOsKVUz6oG .image-shape .label,#mermaid-svg-XWSG7ljOsKVUz6oG .icon-shape .label{text-align:center;}#mermaid-svg-XWSG7ljOsKVUz6oG .node.clickable{cursor:pointer;}#mermaid-svg-XWSG7ljOsKVUz6oG .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-XWSG7ljOsKVUz6oG .arrowheadPath{fill:#333333;}#mermaid-svg-XWSG7ljOsKVUz6oG .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-XWSG7ljOsKVUz6oG .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-XWSG7ljOsKVUz6oG .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-XWSG7ljOsKVUz6oG .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-XWSG7ljOsKVUz6oG .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-XWSG7ljOsKVUz6oG .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster text{fill:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG .cluster span{color:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-XWSG7ljOsKVUz6oG .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-XWSG7ljOsKVUz6oG rect.text{fill:none;stroke-width:0;}#mermaid-svg-XWSG7ljOsKVUz6oG .icon-shape,#mermaid-svg-XWSG7ljOsKVUz6oG .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-XWSG7ljOsKVUz6oG .icon-shape p,#mermaid-svg-XWSG7ljOsKVUz6oG .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-XWSG7ljOsKVUz6oG .icon-shape .label rect,#mermaid-svg-XWSG7ljOsKVUz6oG .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-XWSG7ljOsKVUz6oG .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-XWSG7ljOsKVUz6oG .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-XWSG7ljOsKVUz6oG :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 反馈
1 摄入 Ingest

时间戳+来源指纹
2 编译 Compile

语义切分→生成页→全量更新
3 关联 Graph Linking

预构建双向交叉网络
4 冲突 Conflict

不覆盖·新旧并存·人工
5 检索 Retrieve

意图→三路召回→重排
6 迭代 Iterate

低峰巡检·持续整合

值得细说的三个环节：

② 编译阶段------"只编译一次"是铁律。

LLM 先按文件类型调解析器（PDF 解析、OCR、多模态模型）转成纯文本，再按语义而非版式 多级拆分，提炼实体/结论；然后按 Schema 模板生成规范页面归类；最后做最关键的一步------全局增量更新：新页面与全量知识库语义比对，所有受影响关联页同步刷新、交叉引用重算。同一份资料只会编译一次。

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

这是最有"工程审美"的地方。新数据与旧结论"打架"时，系统绝不直接覆盖，而是：

完整记录双方内容与时间戳
页面里保留两种说法并标注来源
往矛盾管理页加待办
推人工审核工单

知识冲突从用户侧的"隐性问题"，被提前变成系统侧的"显性待办"。企业落地时，这步通常由业务专家做最终裁定。

⑥ 迭代阶段------知识自己"长大"。

业务低峰期跑两类后台任务：全量巡检（查断链、找孤页、揪隐藏冲突并自动修复）+ 持续整理（结合近期数据与高频查询日志，补关联、调优先级）。运维良好的库上线 3-6 个月后，查询正确率能比初期再提升 15 个百分点以上。

五、三路混合检索：泛化召回变精准命中

都编译成 Wiki 了，查询怎么做？答案是意图理解 + 三路并行 + 融合重排：

LLM 当"语义翻译器"：把自然语言问题转成结构化检索参数------核心意图、范围限定、优先关键词。
三路检索同时开跑 ：
- BM25 关键词：精准咬住业务术语和产品型号；
- 知识图谱关系：沿着预构建的交叉引用直接遍历知识链；
- 向量语义：兜住"没有关键词但语义相关"的内容。
加权合并 + 重排 ：交给 Qwen3-Reranker-4B 这类专用重排模型打分，返回 Top K。

为什么要三路并行？因为单一手段都有盲区：纯关键词抓不住语义，纯向量对专业术语容易"眼瞎"，而图谱检索正是编译阶段提前铺好的轨道。行业实测，三路混合检索相比纯向量检索，召回率能高出 15% - 20%，语义正确率提升近 30 个百分点，延迟保持在同一个数量级。

六、一个编译产物长什么样

markdown 复制代码

---
类型: source
标题: 空压机-3号机组
创建: 2026-08-12
更新: 2026-08-27
来源:
  - sources/运行手册-2026版.md
  - sources/维修工单-0821.md
关联:
  - concepts/轴承过热的诊断方法.md
  - entities/二线空压机机组群.md
---

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

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

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

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

大白话解读：这个页面就是"编译"二字的实物。YAML 头把"我从哪来、我关联谁、我什么时候被更新过"写得明明白白；正文是人话不是切片；冲突不藏着掖着，显式挂出来指向待处理页。 最后的溯源链接是亮点------点击任何一条结论都能跳回支撑它的原始段落，这就是"行级溯源"。

七、不是要替代 RAG，而是分层协同

RAG 负责"覆盖广"（兜住海量非结构化数据），LLM Wiki 负责"精度高"（把核心知识沉淀成复用资产）------这是行业普遍共识。最实用的是「核心-边缘」分层架构：

复制代码

用户查询
   │
   ▼
┌─────────────────────────────┐
│ 核心层 LLM Wiki（高频高价值）  │ 命中 → 精准答案 + 溯源
│  预编译 · 交叉引用 · 直读成品   │
└─────────────────────────────┘
        │ 未命中
        ▼
┌─────────────────────────────┐
│ 辅助层 传统 RAG（海量低频）     │ 动态召回 · 兜底
└─────────────────────────────┘
        │
        ▼
融合生成：精准片段 + 补充 → 带来源标记的答案

行业实测，这种混合架构相比纯 RAG 检索准确率提升 20% 以上 ，综合运营成本下降 40% 以上。

八、算一笔账：知识库的成本结构

对于企业内部决策较敏感，成本尤其关键。行业调研的一组公开数据：

项目	传统 RAG	LLM Wiki 类
部署成本	3.4 万 - 5.8 万美元	约 1000 美元
月度运营	8100 - 19500 美元	25 - 50 美元
Token 消耗	基线	减少 84.6% - 95%

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

此外还有三个可调的旋钮：知识粒度（越细编译越贵但复用越好）、冲突检测频率（越频繁算力越贵）、人工校验范围（越广人力越贵）。技术选型从来不是选"最强"，而是选"最匹配"。

九、谁适合上这套？

科技公司：研发文档、架构文档、工单、周报散落各源的，人员每天 >20% 时间花在查资料上。"预编译 + 自动增量更新"把非结构化文档变成结构化、可关联、可溯源的资产，跨团队"一次检索"搞定。
制造企业：运维记录、工单、老师傅经验是真正的金矿；但传统向量检索对型号/工艺参数这类专业术语的匹配撑不住产线业务。把老师傅的隐性经验编译成故障知识链 + 知识图谱，变成可复用的显性资产。

两者的共同特征：知识复用频率高、精度要求高、多源强关联。反过来可能存在"知识更新极快而查询很少"的场景，暂时不建议上。

十、给做企业知识库几点落地建议

提示：本文基于公开资料与行业实践整理，具体数据来自业内公开报告/实测分享，不同场景结果会有差异，仅供参考。

这篇保留了你我理解到的方法论。如果在企业落地，我建议从最简单的三层最小闭环开始：

阶段一（跑通） ：单独挑选几个核心高频主题文档（几十篇内），搭 sources/ + entities/ 两层，只编译不分散，手动查缺。

阶段二（完善） ：引入 concepts/（≥2来源提及）和 pending/（冲突进隔离区），加入"冲突不覆盖只标记"规则，配上人工审核工单。

阶段三（规模化）：接上三路混合检索 + Reranker 重排，核心-边缘分层，让 RAG 兜低频抄底，形成"核心预编译 + 边缘动态检索"的完整闭环。

结语

回到开头那位信息负责人的困惑："它好像从来不记得自己昨天答过什么。" LLM Wiki 的回答是：那就让系统学会记住------把知识处理从查询时前移到摄入时，把碎片编译成资产，把冲突变成待办，把关联提前铺好。

它不是银弹，也不替代 RAG。但它代表一个清晰的趋势：企业知识建设正在从"以检索为中心"转向"以知识沉淀为中心"。知识库不该是被动查询的仓库，而应是持续增值的业务资产。

如果你也在调研下一代知识库，欢迎在评论区交流，同行者越多，走得越快。