目录
[一、LLM Wiki介绍](#一、LLM Wiki介绍)
[它和 RAG 的关系](#它和 RAG 的关系)
[LLM Wiki的优势](#LLM Wiki的优势)
[LLM Wiki面临的挑战](#LLM Wiki面临的挑战)
[二、超长上下文，Agentic Retrieval和LLM Wiki技术选型](#二、超长上下文，Agentic Retrieval和LLM Wiki技术选型)
一、LLM Wiki介绍
今年上半年，Andrej Karpathy 提出了一个概念，很快在开源社区火了一圈 ------LLM Wiki。有意思的是，Karpathy 把理论框架讲得很完整，却没给出一套官方代码实现。于是 GitHub 上出现了大量自发实现，到现在也没有一个 "官方版本"。
这恰恰说明一件事：方向是对的，但路要靠社区自己走。
它在解决什么问题
做 RAG 的人几乎都绕不开一个痛点：切片（chunking）。你要把一大段技术文档喂给向量检索，就得先把文档切成一块块，再逐块向量化。切片粒度切大了信息太碎、检索不准，切小了上下文丢失、召回变差。而且更麻烦的是 ------ 只要切片这一步还需要人来调、人来校验，知识库的更新就永远没法全自动化。
LLM Wiki 的思路很直接：我打死不切片。 它把每个文档当成一篇 "维基百科页面" 来对待 ------ 有标题、有正文、有目录、有摘要，再把页面之间用双向链接串起来，配上一套目录层级和可选的知识图谱 。也就是说，它把一堆散乱的非结构化文档，"编译" 成一个结构化的、可导航的知识系统。
它和 RAG 的关系
先澄清一个常见的误解：LLM Wiki 不是要干掉 RAG。
- 狭义 RAG（向量检索），只是 LLM Wiki 提供的检索手段之一；
- 广义 RAG（先检索、再塞提示词、最后回答），LLM Wiki 属于其中的一种实现；
- 至于长上下文、agentic search，则分别适用 "单文档强相关" 和 "跨数据源多步推理" 的场景。
简单说，它们各有各的用武之地，LLM Wiki 专门啃大型复杂知识库这块最硬的骨头。
这套系统是怎么构建的
它的构建过程被 Karpathy 称为 "编译"，大致分六步：
1.页面化------ 每个原始文档变成一个 "维基页面"；
Step 1: 文档解析 提取标题、段落、表格，保留原始结构。
**Step 2:**结构识别 识别Markdown层级，构建父子关系树。
**Step 3:**生成Page Object 封装page_id/title/content/summary结构化对象。
2.双向链接------ 抽取实体（公司、人名、部门、产品名等），按规则判断是否独立成页，页面间用 [[链接]] 互跳，还能反查 "谁指向了我"；
**Step 1:**NER 识别文本中的关键实体 如"OpenAI, API Key"
**Step 2:**链接检查实体是否存在生成 \[API Key] 链接
**Step 3:**反向索引自动维护索引记录谁引用了当前页面
核心价值： 打破知识孤岛借鉴维基百科的链接思想，让孤立的文本片段形成相互关联的网络 。这对RAG系统至关重要，能帮助模型自动扩展关联知识，突破传统Top-k检索仅返回"直接匹配"结果的局限，更能基于链接关系进行**"多跳推理"和关联扩展**，从而显著提升回答的丰富度和准确性。
3.层级目录------ 保留文档的父子结构，让 agent 可以 "翻目录" 而不是非搜不可；
实现方式：
1）文档原生解析：直接解析 Markdown 标题层 级 (#, ##)，构建抽象语法树 (AST Tree)，还原作者意图。
**2）LLM 自动生成：**针对无结构化文本，通过 Prompt指令让模型分析内容 逻辑，输出JSON格式的层级 关系。
通常存储为节点关系型数据库，通过父子ID关联维护层级。支持：树遍历 (Traversal) · 层级检索 · 章节动态扩展。
**核心优势：**模拟人类认知逻辑，大幅提升检索精准度与效率
4.实体关系------从非结构化文本中，自动识别并抽取出结构化的 "实体"与"实体"的关系；
实体就是提取出来的关键词，实体一般都为名词，比如：人名，公司名，产品名等
例如：
原文："张三负责 Apollo 项目。Apollo 项目服务于腾讯。"
结果：(张三, 负责, Apollo)、(Apollo, 客户, 腾讯)
实现方式：
**1）LLM 端到端抽取 (主流):**通过精心设计的 Prompt 指令， 直接让大模型输出结构化数据，高效且适配性强。
**2）传统 NLP 技术栈:**利用依存句法分析、NER等工具，目前 在追求极致效率场景仍有应用，但正逐步被 LLM 方案替代。
抽取结果通常存入图数据库 (Graph DB)（如 Neo4j），将 海量碎片化信息编织成一张可被高效查询、遍历和推理的知 识图谱 (Knowledge Graph)，为企业构建专属的数字大脑。
5.自动摘要------small-to-big，便于快速判断文档价值；
企业知识通常篇幅过长，大语言模型 (LLM) 难以每次读取全文。因此，需要高效的摘要技术提炼 核心信息，解决长上下文处理难题。
**Step 1:Chunk Summary (细粒度摘要)**对长文本的最小语义单元 (Chunk) 进行初步提炼，保留关键事实与数据。
Step 2:Page Summary (页面聚合摘要) 将分散的 Chunk 摘要进行聚合与逻辑整合，生成完整的页面级摘要。
Step 3: Section Summary (全文/章节摘要) 进一步聚合页面摘要，形成文档全貌的宏观摘要，输出关键结论与核心观点。
**Query-aware Summary 核心思想：**从"为文档生成通用摘要"转变为 "为用户问题动态提取答案"，精准匹配信息需求。
6.索引------ 把每个页面向量化，并打通多种检索通道。
**本质：**为知识建立多种访问入口自动索引的核心思想是为知识建立多样化的访问入口，打破单一向 量（Embedding）检索的局限，通过组合不同维度的检索能力来覆盖复杂的查询需求。
目前用的最多的索引类型：
• Vector:理解文本深层语义含义
• BM25:经典高效的关键词检索
• Entity:人名/产品名等精准匹 配
• Graph:探索实体关联与多跳检索
• Hierarchy:支持目录式层级导航
7.语义导航------ LLM自主决定下一步该走哪，从当前知识点跳转；
由于已经做好了实体-实体关系，实体-页面，摘要-页面，页面-文档层级结构等等的关系，LLM根绝Query来决定下一步如何走：
**示例 (用户问"退款失败为何增多？")：**1.退款规则 → 2.支付系统 → 3.版本更新 → 4.Bug报告 → 5.客服工单
LLM Wiki的优势
除了前面说的，LLM Wiki的优势除了不需要切片，不需要人工的校验。还有它的自进化。
LLM Wiki将知识视为动态系统，在每次更新时进行整体的"编译"与 "重构"，以确保知识网络的准确性与实时性。
真正的成本在构建期：写规则、写解析 / 关系提取 / 多跳查询代码、做调试和测试，这部分投入大。但构建完善后，实际重跑全量编译相对 token 消耗并不高。
**实现的关键：**① 有能力做变更检测；② 编译流程自动化（解析、摘要、实体抽取、关联分析、索引更新的代码）。
LLM Wiki面临的挑战
工程化落地面临级联更新成本高 、知识生成不一致 、实体命名混乱 、关系链接过量 及摘要失效等系统性难题，是系统设计必须解决的拦路虎。当文档比较多，结构比较复杂时，这些问题就会很难。
二、超长上下文，Agentic Retrieval和LLM Wiki技术选型
首先声明一下，这三种都不能替代RAG，都只是在不同的场景下的不同技术路线。
超长上下文： 适合单文档强相关的资料。比如说各种各样的法律合同审计文档，或者是比较长的代码文件，或者是比较巨大的这种技术报告。这时候不适合切片，直接把全部内容都放进提示词中。
**Agentic Retrieval：**比较适合解决需要多步推理、跨数据源关联的复杂问题。利用LLM的推理能力，不停的推理和总结。
**LLM Wiki：**适用于复杂的知识系统，提取出文档，实体等之间的关联与层级关系，构造成一个庞大的复杂知识库。
