为什么 LLM Wiki 不是 RAG，而是知识编译系统
核心判断
LLM Wiki 和 RAG 的区别，不是是否使用 LLM，也不是是否读取文档，而是知识是否被编译成可持续复用的中间层。RAG 在查询时临时理解材料；LLM Wiki 在摄取时把材料转化为结构化知识。
RAG 的问题不是检索，而是没有积累
RAG 的基本动作是：用户提问，系统检索相关片段，把片段塞进上下文，然后让模型回答。这个模式适合实时资料、临时查询和动态数据，但它有一个结构性限制：每次查询都要重新理解原始材料。
所以 RAG 的知识生命周期很短。一次回答结束后，检索片段和模型当时形成的综合判断通常不会沉淀下来。下次再问相似问题，系统仍然要从检索开始。
这不是 RAG 做得不好，而是它的范式如此。它处理的是“当下这次问题”，不是“长期知识体”。
LLM Wiki 的关键是持久中间层
RAG vs LLM Wiki 的核心差异在于：LLM Wiki 会在 raw source 和用户查询之间建立一个持久的 Wiki 层。
这个 Wiki 层不是原文备份，也不是摘要堆积，而是被编译过的知识结构：
- entity 负责稳定概念。
- topic 负责跨文章整合。
- comparison 负责区分相邻概念。
- output 负责把 Wiki 转化为可读成果。
因此，LLM Wiki 的一次编译不是为了一次回答，而是为了降低未来所有相关回答的理解成本。
为什么叫知识编译
Knowledge Compilation 这个类比很准确。
程序编译把源代码转化为更可执行的目标形态。知识编译则把原始文章转化为更可查询、可组合、可审查的 Wiki 形态。
这个过程至少做了四件事：
- 删除不会改变理解的细节。
- 提取可复用概念。
- 建立概念之间的链接。
- 标记前提、边界和冲突。
如果只做摘要，Wiki 会变成压缩版资料库；如果完成编译，Wiki 才会变成可运行的知识系统。
人类的位置没有消失
LLM Wiki 不是把理解外包给模型，而是把整理、重排、初步连接这些高摩擦劳动交给模型。人仍然负责三件事：
- 选择哪些 source 值得进入系统。
- 判断哪些概念和关系真的重要。
- 通过输出和探索反向检验 Wiki 是否有用。
这也是本库新增四动作模型的原因：compile(source) 负责摄取，audit(scope) 负责可信度，produce(query) 负责价值检验，explore(topic) 负责提出下一轮问题。
对 Agentic Work Atlas 的含义
对本库来说，LLM Wiki 不应该追求“存更多文章”，而应该追求“每次摄取都让未来问题更容易回答”。
这带来一个很实用的判断标准：
如果一篇 raw source 不能沉淀为 entity、topic、comparison 或明确的问题，它就不应该被机械编译。
同样，输出不是额外装饰。输出是 Wiki 的压力测试：如果基于现有 Wiki 写不出清楚文章，说明概念还没编译好；如果能写出文章但无法回链证据，说明 Wiki 可信度不足。
局限
LLM Wiki 的代价也很明确：
- 它需要高质量 source，否则只是把低质量材料结构化。
- 它需要审查，否则错误链接和虚假综合会持续累积。
- 它适合稳定知识和高频复用问题，不适合完全实时的动态资料。
- 当页面规模继续增长，可能需要 GBrain 这类混合检索架构补足查找效率。
所以极简版本的 LLM Wiki 不应急着工程化。先证明四个动作能形成闭环，再考虑引入更重的检索、调度或自动化。
一句话
RAG 是把资料临时带进上下文；LLM Wiki 是把资料编译成一个会复利的知识中间层。
本文使用的 Wiki 页面
回填检查
| 新判断 | 支撑依据 | 处理 |
|---|---|---|
| LLM Wiki 与 RAG 的核心差异是是否形成持久中间层 | Wiki: RAG-vs-LLM-Wiki、Knowledge-Compilation | 保留 |
| Output 是 Wiki 的压力测试 | Wiki: Agent-Knowledge-Management；实践判断仍需更多 source | 放入 research agenda |
| LLM Wiki 不应机械编译所有 raw source | Wiki: Knowledge-Compilation；Schema 收录规则 | 保留 |
| 大规模 Wiki 可能需要 GBrain 这类混合检索架构 | Wiki: GBrain | 保留 |