1. 为什么要把知识库“编译”成 Wiki第一次听到“LLM-Wiki”这个词很多人会下意识觉得又是新瓶装旧酒——不就是把文档丢给大模型做问答吗RAG 早就干这事了。但真正在企业里维护过知识库的人会明白RAG 那套“切片-向量化-召回-拼接”的流水线在文档量小、结构松散的时候确实好用一旦知识规模上去、文档之间开始互相引用、概念开始分层问题就全冒出来了。LLM-Wiki 这个思路的核心是把知识库从“一堆待检索的碎片”变成“一张有结构、有链接、可导航的网”然后再把在这张网上“怎么走、走哪条路”的决策权交给 LLM。我先把结论摆在这LLM-Wiki 不是要取代 RAG而是给 RAG 换了一套更接近人类查阅百科全书的底层组织方式。传统 RAG 像是把一本书撕成纸片塞进抽屉你问什么它就翻出几张最像的纸片LLM-Wiki 则是先把这本书重新编成一本带目录、带索引、带交叉引用的百科LLM 拿到问题后先看目录、再顺着链接跳转最后才去读具体段落。这两种方式的差别在简单问答上看不出来但在“跨文档推理”“多跳问答”“概念溯源”这类任务上差距是数量级的。那到底什么是“把知识库编译成 Wiki”这里的“编译”是个很妙的词它借用了编程语言里的概念——源代码原始文档经过编译器处理变成可执行的目标代码结构化 Wiki。放到知识库场景里原始文档就是源代码编译过程就是抽取实体、建立关系、生成摘要、构建链接、形成层级目录最终产物是一个机器可读、人类也可读的 Wiki 结构。这个结构不是给人看的静态网页而是给 LLM 当“地图”用的。适合读这篇内容的人我大致分三类。第一类是正在做企业知识库、文档问答系统的工程师你们大概率已经踩过纯向量检索的坑正在找更结构化的方案第二类是做 GraphRAG、知识图谱方向的研究者或开发者LLM-Wiki 和 GraphRAG 有大量重叠但工程落地路径不太一样第三类是对 LLM 应用架构感兴趣的技术负责人你们需要判断这套东西值不值得投入。不管你是哪一类我都会尽量把“为什么这么设计”讲透而不是只丢一堆概念。2. 从 RAG 到 LLM-Wiki 的范式迁移2.1 传统 RAG 的三个结构性缺陷要理解 LLM-Wiki 的价值得先把传统 RAG 的问题说清楚。我总结下来是三个结构性缺陷注意是“结构性”的不是调参能解决的。第一个缺陷是切片导致的语义断裂。文档被切成 512 或 1024 token 的块块与块之间的上下文就丢了。一个概念的定义在第三章它的应用案例在第七章传统 RAG 检索时可能只召回其中一块LLM 拿到的信息是残缺的。你可能会说可以用重叠切片缓解但重叠只能缓解相邻块的问题跨章节、跨文档的关联它无能为力。第二个缺陷是向量相似度不等于逻辑相关。向量检索找的是“语义上像”的内容但“像”和“相关”是两回事。用户问“A 方案在 B 场景下为什么失效”向量检索可能召回一堆讲 A 方案和 B 场景的段落但真正解释“为什么失效”的那段因果推理可能因为用词不同而排不进 top-k。这就是所谓的“语义鸿沟”。第三个缺陷是缺乏全局视角。传统 RAG 是“局部检索”它永远只能看到被召回的那几块无法回答“整个知识库里关于某主题的所有观点有哪些”“这些观点之间是什么关系”这类需要全局遍历的问题。GraphRAG 之所以火就是因为它试图解决这个问题而 LLM-Wiki 走的是另一条路。2.2 Wiki 结构为什么更适合 LLMWiki 这种组织形式有几个天然优势恰好对上 LLM 的能力特点。第一Wiki 是显式结构化的。它有页面、有标题、有段落层级、有内部链接、有分类标签。这些结构信息对 LLM 来说是极好的“导航信号”。LLM 不需要靠向量相似度去猜哪块内容相关它可以直接读目录、顺着链接走。这就像你在一座陌生城市里向量检索是给你一堆坐标点让你猜哪栋楼是目的地Wiki 是直接给你一张地图加路标。第二Wiki 的链接是语义化的。一个页面链接到另一个页面这个链接本身就携带了“这两个概念相关”的信息而且链接的锚文本还说明了“以什么方式相关”。这种显式的、带语义的关系比向量空间里的余弦相似度信息量大得多。第三Wiki 支持多粒度访问。你可以只看目录粗粒度可以看某个页面的摘要中粒度也可以深入某个段落的细节细粒度。LLM 可以根据问题的复杂度自主决定在哪个粒度上操作。简单问题看摘要就够复杂问题才逐层下钻。这种“按需展开”的能力是传统 RAG 的固定 top-k 召回做不到的。2.3 “检索权交给 LLM”到底是什么意思这个说法容易被误解。它不是让 LLM 去替代向量数据库做检索而是让 LLM 掌握“检索策略的决策权”。传统 RAG 的检索策略是写死的把 query 向量化去向量库找 top-k拼进 prompt。整个过程 LLM 是被动的它只能接受检索器给它的东西。而 LLM-Wiki 里LLM 是主动的它先看 Wiki 的目录结构判断这个问题应该从哪个入口进然后读相关页面的摘要判断要不要深入如果发现信息不够它会顺着链接跳到关联页面如果发现概念不清楚它会去查术语表页面。整个过程是 LLM 在“驾驶”Wiki 结构是“路网”检索工具是“方向盘和油门”。这种模式在业界有个更学术的叫法叫Agentic Retrieval智能体式检索。它的核心是把检索从“一次性函数调用”变成“多轮决策过程”。代价是延迟和 token 消耗会增加但换来的是准确率和可解释性的大幅提升。对于知识密集型、容错率低的应用场景这笔账是划算的。3. 知识库编译成 Wiki 的核心流程拆解3.1 原始文档的预处理与规范化编译的第一步不是急着抽实体而是把原始文档“洗干净”。这一步很多人会跳过结果后面全是坑。我踩过的坑包括PDF 里的表格被解析成乱码、Markdown 里的代码块被当成正文、HTML 里的导航栏混进了内容。这些脏数据一旦进入编译流程会污染整个 Wiki 结构。预处理我一般分四步走。格式统一把所有文档转成 Markdown 或纯文本保留标题层级和列表结构因为标题层级是后续构建 Wiki 目录的重要依据。噪声清除去掉页眉页脚、导航栏、广告、版权声明这些非内容元素。编码修正处理乱码、全半角混用、特殊字符转义。元数据抽取从文件名、文档头、路径里抽取标题、作者、日期、分类等元信息这些后面会变成 Wiki 页面的属性。这里有个经验预处理阶段一定要保留原始文档的“结构指纹”。什么叫结构指纹就是文档的标题层级、章节编号、列表嵌套这些信息。很多人预处理时为了“干净”把这些都删了结果后面构建 Wiki 层级时无据可依。我的做法是清洗内容但保留结构标记比如用#、##标记标题层级用缩进标记列表嵌套。3.2 实体抽取与概念识别这是编译流程里最核心也最难的一步。目标是从文档里识别出“值得单独建 Wiki 页面”的实体和概念。什么叫“值得单独建页”我的判断标准是这个概念在多个文档里出现、有明确定义、有独立的解释价值、会被其他概念引用。抽取方法上纯规则不行纯 LLM 也不行我一般用“LLM 抽取 规则过滤 人工校验”的组合。LLM 负责从段落里识别候选实体规则负责过滤掉明显不是实体的比如纯数字、停用词人工负责校验边界情况。抽取的实体类型包括术语、人物、组织、产品、方法、事件、指标等。这里有个关键决策实体粒度怎么定。太粗比如把“机器学习”当一个实体那这个页面会大到没法用太细比如把“梯度下降的学习率”当一个实体那页面会多到爆炸。我的经验是以“能否用一段话独立解释清楚”为标准。能独立解释的就单独建页不能的就作为父概念页面下的一个段落。3.3 关系抽取与链接构建实体抽出来后要建立它们之间的关系这是 Wiki 区别于普通文档集合的关键。关系类型我一般分这么几类层级关系A 是 B 的子类、组成关系A 由 B 组成、因果关系A 导致 B、对比关系A 和 B 相似/相反、引用关系A 引用了 B。关系抽取同样用 LLM 为主。我会给 LLM 一个关系类型清单让它从文档里识别实体对和它们的关系。这里要注意的是关系是有方向的A 导致 B 和 B 导致 A 完全不同抽取时一定要保留方向信息。链接构建是把关系落到 Wiki 页面上的过程。每个关系会变成页面里的一个链接链接的锚文本就是关系描述。比如“梯度下降”页面里有一句“梯度下降是反向传播的核心优化方法”这里的“反向传播”就是一个链接锚文本“核心优化方法”说明了关系类型。这种带语义的链接是 LLM 导航时的重要线索。3.4 摘要生成与层级组织每个 Wiki 页面都需要一个摘要这是 LLM 快速判断“这个页面要不要深入”的依据。摘要生成不是简单截取首段而是要让 LLM 读完整个页面的内容后生成一段 100-200 字的概括包含这个概念的定义、核心特征、主要应用、关联概念。层级组织是把所有页面组织成一棵树或一张网。树是目录结构网是链接结构两者都要有。目录结构给 LLM 提供“从粗到细”的导航路径链接结构给 LLM 提供“横向跳转”的能力。目录的构建可以基于实体的分类标签也可以基于文档的原始章节结构我一般两者结合。4. 检索权交给 LLM 的实操机制4.1 LLM 导航 Wiki 的决策循环LLM 在 Wiki 上的检索本质是一个“观察-决策-行动”的循环。我用一个具体例子来说明。假设用户问“为什么在数据稀疏场景下协同过滤的效果不如内容推荐”第一轮LLM 先看 Wiki 的顶层目录发现有几个相关入口“推荐系统”“协同过滤”“内容推荐”“数据稀疏性”。它判断这个问题涉及多个概念决定先进入“推荐系统”总览页。第二轮读“推荐系统”页面的摘要发现里面提到“不同推荐算法在不同数据条件下的表现差异”并链接到“协同过滤”和“内容推荐”两个页面。LLM 决定分别进入这两个页面。第三轮读“协同过滤”页面发现里面有一节讲“数据稀疏性问题”链接到“数据稀疏性”页面。LLM 进入该页面找到“稀疏场景下的算法表现对比”段落里面正好有协同过滤和内容推荐的对比数据。第四轮LLM 判断信息够了综合几个页面的内容生成答案并附上引用来源。整个过程 LLM 做了 4 轮决策访问了 5 个页面。传统 RAG 可能一次性召回 5 个片段但这 5 个片段未必覆盖了这条推理链。这就是“检索权交给 LLM”的价值。4.2 工具接口设计给 LLM 配哪些“方向盘”LLM 要在 Wiki 上导航需要一套工具接口。我一般会给它配这几个工具名称功能输入输出list_pages列出某层级下的所有页面层级路径页面标题列表read_summary读取页面摘要页面 ID摘要文本read_section读取页面某章节页面 ID 章节名章节内容follow_link跟随链接跳转页面 ID 链接锚文本目标页面 IDsearch全文/向量检索查询词相关页面列表get_backlinks获取反向链接页面 ID引用该页的页面列表这套接口的设计原则是每个工具做一件事粒度要细让 LLM 有充分的组合空间。不要做一个“万能检索”工具那样 LLM 又退化成被动接受了。4.3 上下文管理与 token 预算控制LLM 导航 Wiki 最大的工程挑战是 token 消耗。每读一个页面都要占上下文访问十几个页面就可能爆窗口。我的应对策略有三条。第一条摘要优先。永远先读摘要只有摘要显示“这个页面确实相关”才读正文。摘要控制在 150 字以内这样读 20 个摘要也才 3000 token。第二条按需展开。读正文时也只读相关章节不读整页。章节定位靠 LLM 自己判断或者用一个小模型做章节相关性打分。第三条上下文压缩。当访问页面多了把已经读过的内容做一次压缩只保留关键结论和引用来源释放 token 空间。这个压缩动作可以定期触发比如每访问 5 个页面压缩一次。提示token 预算控制是 LLM-Wiki 落地的关键工程点。我见过太多方案在 demo 阶段效果惊艳一上生产就因为 token 成本爆炸而搁浅。建议在架构设计阶段就把预算控制作为一等公民考虑。5. 与 GraphRAG、传统 RAG 的对比与选型5.1 三种方案的本质差异很多人把 LLM-Wiki 和 GraphRAG 混为一谈其实它们的底层逻辑不同。我用一张表说清楚。维度传统 RAGGraphRAGLLM-Wiki知识组织向量切片实体关系图结构化页面 链接检索方式相似度 top-k图遍历 社区摘要LLM 导航 多轮决策全局视角无有社区摘要有目录 链接网可解释性低中高构建成本低高中高查询延迟低中高适合场景简单问答全局分析复杂推理GraphRAG 的核心是“图 社区检测 分层摘要”它擅长回答“整个知识库关于某主题的主要观点是什么”这类全局问题。LLM-Wiki 的核心是“结构化页面 LLM 导航”它擅长回答“这个概念和那个概念之间是什么关系”这类需要多跳推理的问题。5.2 选型决策树怎么选我给一个简单的决策树。如果你的知识库文档量小于 1000 篇、问题以事实查询为主、延迟要求高传统 RAG 就够了别过度设计。如果你需要回答全局性、总结性问题比如“这批文档里有哪些主要争议点”GraphRAG 更合适它的社区摘要机制就是为这类问题设计的。如果你的问题需要跨文档、多跳推理比如“A 方案在 B 条件下的失效原因和 C 方案在 D 条件下的失效原因有什么共同点”LLM-Wiki 是更好的选择因为它的链接网和 LLM 导航能力天然支持这种推理链。当然这三者不是互斥的。我实际项目里经常是混合架构底层用向量库做粗召回中层用 Wiki 结构做导航上层用 LLM 做决策。GraphRAG 的社区摘要也可以作为 Wiki 的一个特殊页面类型存在。5.3 混合架构的落地建议如果你决定上混合架构我的建议是分层建设逐步替换。第一层保留现有向量检索作为兜底。当 LLM 导航找不到路时可以回退到向量检索。第二层构建 Wiki 结构。这一步可以增量做先给核心概念建页再逐步扩展。第三层接入 LLM 导航。先用小流量灰度观察 LLM 的导航路径是否合理再逐步放量。这样做的好处是风险可控每一层都能独立工作不会因为某一层没建好就整个系统瘫痪。6. 实操中的常见问题与排查技巧6.1 实体抽取的边界问题最常见的问题是实体边界模糊。比如“深度学习模型压缩”到底是一个实体还是三个实体深度学习、模型、压缩我的处理原则是看它在文档里是否被当作一个整体讨论。如果文档里经常说“深度学习模型压缩技术”那它就是一个实体如果说“深度学习的模型压缩方法”那“深度学习”和“模型压缩”是两个实体。排查技巧抽取完后统计每个实体的出现频次和共现关系。如果一个“实体”总是和另一个实体一起出现且从不单独出现那它可能应该合并。反之如果一个实体内部总是被拆开讨论那它可能应该拆分。6.2 链接爆炸与稀疏的平衡链接太少Wiki 就退化成普通文档集合链接太多LLM 导航时会迷路。我一般控制每个页面的出链在 5-15 个之间。低于 5 个说明关系抽取不充分高于 15 个说明关系太泛需要过滤。过滤原则只保留强关系弱关系用标签代替。比如“A 和 B 都属于机器学习”这是弱关系用标签“机器学习”标记即可不用建链接。“A 是 B 的核心算法”这是强关系建链接。6.3 LLM 导航迷路的排查LLM 导航时迷路表现为反复访问同一页面、或者在不相关页面间跳转。排查思路先看目录结构是否合理。如果目录层级太深或太浅LLM 会找不到入口。我一般控制在 3-4 层。再看摘要质量。如果摘要没抓住页面核心LLM 会误判相关性。摘要一定要包含“这个页面讲什么、和什么相关”。最后看链接锚文本。如果锚文本太泛比如“点击这里”LLM 无法判断链接目标。锚文本要具体说明关系类型。6.4 常见问题速查表问题现象可能原因排查方向解决建议LLM 反复访问同一页摘要不清晰或链接循环检查摘要和链接优化摘要打破循环链接答案遗漏关键信息相关页面未被访问检查目录和链接覆盖补充链接优化目录token 消耗过高读入过多正文检查摘要优先策略强制先读摘要按需展开导航路径不合理目录层级或链接语义问题检查目录和锚文本调整层级细化锚文本实体重复建页实体识别未去重检查实体别名建立别名映射表注意LLM 导航的调试不能只看最终答案要看中间路径。我一般会把 LLM 的每次工具调用都记日志事后分析路径是否合理。这是优化导航策略的最重要依据。7. 我踩过的坑和几条实在经验先说一个最容易被低估的坑别指望一次编译就完美。我第一个 LLM-Wiki 项目花了两周做编译结果 LLM 导航效果很差。后来发现是实体抽取太粗很多该拆的概念没拆。返工重做又花了一周。现在的做法是编译分多轮第一轮粗抽跑一遍导航测试看哪些地方 LLM 迷路针对性地细化那部分。迭代三四轮效果就上来了。第二个坑是过度追求自动化。我一开始想全自动编译结果质量不可控。后来改成“LLM 抽 人工校验关键实体”虽然慢一点但质量稳定得多。关键实体可能只占 20%但决定了 80% 的导航质量这部分人工投入是值得的。第三个坑是忽略冷启动问题。Wiki 刚建好时链接稀疏LLM 导航效果差。这时候可以先用向量检索兜底随着 Wiki 完善逐步切换。别一上来就全量切 Wiki那样用户体验会断崖式下跌。最后分享一个实用技巧给 Wiki 页面加“相关页面”区块。就是在每个页面底部列出 3-5 个最相关的其他页面。这个区块可以由 LLM 生成也可以由链接分析算法生成。它的作用是给 LLM 提供“下一步去哪”的显式建议实测能显著减少迷路。这套东西我前后折腾了大半年从最初的怀疑到现在的坚定中间踩的坑比写出来的多得多。如果你正准备上手我的建议是先小范围试点选一个文档量适中、问题类型明确的场景把编译和导航跑通再考虑规模化。别一上来就搞全公司知识库那样大概率会烂尾。