最近一直在搞知识库相关的项目越做越觉得传统的RAG路子有点到头了。很多团队用向量数据库做检索增强前期小规模demo效果惊艳一旦知识库涨到几千篇甚至上万篇文档召回质量就开始飘忽不定。我自己的想法是——知识库不能永远是一堆被切成块的纯文本它应该被“编译”成一种带结构、带链接、带索引的知识网也就是Wiki而检索这件事也应该从“工程规则说了算”变成“让LLM自己决定怎么查、查什么、查到什么程度为止”。这就是我这篇要聊的LLM-Wiki思路。这篇是LLM-Wiki系列的第一篇定位是总论我会把核心概念、设计动机、关键机制、落地需要跨过的坎都讲清楚后面几篇再展开具体的构建流程、工具选型和代码实现。适合正在做RAG知识库、被召回率折磨的工程师也适合刚接触知识库构建、想避开弯路的产品和技术负责人。1. 从一次检索翻车开始知识库越大向量检索越不可靠先讲个真实的场景。我接手维护的知识库大概有三千多篇技术文档覆盖数据库、中间件、云原生基础设施。上线初期用的是最标准的RAG流水线——文档切片、向量化、top-k召回、拼上下文交给LLM作答。前几百篇文档的时候体验还不错库逐渐膨胀之后问题开始暴露。最典型的一次用户的问题是“MySQL的隔离级别和Oracle的隔离级别有什么区别”系统召回了五段文本其中三段是MySQL事务相关的两段是Oracle架构概述没有一段同时包含两张隔离级别对比表格。最后LLM只能基于残缺上下文硬答答出来的内容方向对但缺了关键的细节比如“Oracle默认隔离级别实际上是Read Committed但语义上更接近Repeatable Read”这种关键信息完全丢失。用户接着追问“那InnoDB默认隔离级别是什么”这一次向量检索召回的还是同样一批文章而且因为上一轮的关键词干扰召回列表里混进了两篇不相关的性能调优文章。top-k固定为5正确答案明明在库里有却因为分块把一张完整的对比表格切成了两半导致语义碎片化模型始终没拿到完整的答案。这个现象不是个例我归纳了三个根因向量相似度不等于答案命中。语义相近的文本片段可能有完全不同的信息价值。一篇讲“隔离级别定义”的文章和一篇讲“具体事务冲突案例”的文章向量距离很近但前者才是用户真正需要的。固定top-k根本不适合复杂问题。简单问题一两段文本就能答全对比类、综述类问题往往需要横跨多个页面、多个来源。top-k固定意味着系统不会因为问题变复杂而自动扩大检索范围。切块方式破坏了知识结构。很多文档的精华恰恰在表格、代码块、步骤列表里按固定token数硬切把这些完整结构拆得七零八落召回后组装出来的上下文是“半张桌子半张椅子”。这些痛点的本质是知识库的组织方式连续文本流和LLM的阅读方式需要精确定位到某个答案点并沿着线索深挖之间缺少一个中间层。而这个中间层在我看来就是一个经过编译的Wiki——带页面、带链接、带索引让LLM可以“像人一样翻阅”。这也是我在标题里强调“编译成Wiki”的原因不是简单把文档改名成Wiki而是彻底重组知识的表现形态。2. “编译”到底编译了什么知识库到Wiki的三层改造“编译”这个词我斟酌了很久。它暗示的不是自动生成一篇Wiki博文而是把一套松散的知识资产变成一个有明确结构、可导航、可验证的知识系统。具体落到工程上我把它拆成三层。2.1 第一层把连续文本流拆解成可翻阅的知识页传统RAG的分块单位是“N个token”而LLM-Wiki的分块单位是“一个完整的知识单元”。一个知识页应该对应一个主题主题的颗粒度以“用户想了解这件事时希望看到一个完整说明”为准。实际的拆法可以这样起步先把原始文档解析成标题树利用Markdown的H1到H6结构、PDF的书签层级把整份文档切成若干候选片段。然后做一次片段合并——太短的段落且隶属同一父标题就合并包含表格或代码块的区域则保持独立页面。每个页面都需要有元信息头部至少要包含页面标题必须是叙述性的比如“MySQL默认隔离级别说明”而不是“第3章第2节”。一句话摘要让LLM在导航时快速判断这个页面对当前问题有没有用。标签列表延续原文的分类主题词用于路由分流。关联页面说明“读这个之前建议先看哪页”或“这个问题涉及哪页”。这一步做完知识库就从“一堆长文档”变成了“一张页面清单”每页都是自包含的、可被单独理解的知识块。这就是“编译”的第一层产物。2.2 第二层补齐页面之间的显式链接关系而不是只靠向量近似向量检索本质上是在算“模糊的相似度”它说不出“A和B的关系是什么”。但人的认知方式不是这样的——人查Wiki时看到“隔离级别”这个页面会顺着链接跳到“锁机制”、“MVCC版本链”、“死锁检测”这些页面这些跳转关系是显式的、有语义的。这就是第二层编译的重点建立页面间的显式链接。链接分两类。一类是结构链接来自文档本身的目录和层级比如“事务概述”页面天然链接到“事务隔离级别”和“事务回滚机制”。另一类是语义链接需要在构建时抽取或人工补充比如“死锁检测”页面链接到“innodb_lock_wait_timeout参数调优”、“高并发下锁竞争排查思路”等。链接的构建可以半自动完成先让LLM批量阅读页面摘要输出候选的关联关系和理由再由领域人员抽样审核。不要一上来就指望纯自动化知识库质量的关键在链接质量而链接质量在冷启动阶段必须有人为把关。关于这一点后面第四节会专门讲容易翻车的地方。有了链接之后知识库就形成了网状结构。页面是节点链接是有向边向量检索仍然可以作为兜底的“模糊通道”但主检索路径变成了“沿着链接导航”。2.3 第三层为LLM生成可操作的路由与索引最后一层是为LLM生成“怎么查”的地图。人用Wiki时会先看分类导航或者搜索框LLM也需要一个同等功能的东西这不能靠实时扫描所有页面标题去猜。需要构建的索引包括分类索引按知识域划分的大类如“数据库内核原理”“SQL优化实践”“故障排查案例”“参数配置参考”。每个分类下面挂页面ID列表。别名路由表把用户可能用的自然语言表达映射到知识域的入口。比如用户问“数据库老是锁怎么办”路由表应该把它映射到“故障排查案例”下的“锁等待与死锁处理”页面。关键页面清单一批高热度入口页面作为检索的默认出发点。在运行时LLM看到的不再是一堆二进制向量而是一份可读的站点地图。它需要自己决定先进入哪个分类打开哪个页面读完页面摘要后是继续深读还是沿着链接跳到关联页。这就是“把检索权交给LLM”的物理基础。3. 把检索权交给LLM从“一次检索”到“检索决策链”传统RAG和LLM-Wiki在检索这条链路上有一个根本区别前者把“检索”当成一次性查表操作后者把“检索”当成一个由LLM主导的决策链。3.1 传统RAG的流程与局限传统RAG的流程可以简化为四步用户query向量化向量库召回top-k拼接固定上下文LLM生成答案。这里面没有“判断”的余地。当用户的问题是“什么是数据库死锁”时top-3召回的文本恰好够用体验不错。但当问题是“在我们这个业务场景下数据库频繁出现锁等待应该从哪些参数和索引设计两个方向来排查”时这个流程就顾不过来了——它既需要“锁机制基础”的背景页也需要“实际案例排查”的实战页还需要“参数优化”的参考页。固定top-3没法同时满足这三个跨域需求。更深层的问题在于系统没有能力判断“已经够了”。top-k是死的不会因为信息不足而追加一轮也不会因为信息已充分而减少。这导致两端的浪费都有简单问题拿了一堆无关上下文复杂问题拿了不够用的上下文。3.2 LLM主导的检索决策路由、翻阅、跳转、收敛四步LLM-Wiki的检索决策链我概括成四步每一步LLM都有明确的决策权和判断依据。第一步是路由。LLM拿到用户query后不急着检索而是先判断这个问题属于哪个知识分类。这一步用的是第三层编译生成的分类索引和别名路由表。比如“事务隔离级别对比”会被路由到“数据库内核原理”分类而“为什么我的慢查询突然变多”会被路由到“故障排查案例”分类。第二步是翻阅。LLM读取目标分类下的页面摘要列表判断哪些页面可能与问题相关再点进去看正文。这个动作对应Wiki里的“浏览目录后点开文章”比向量召回多了一步“先看摘要再决定是否深读”的过滤能有效避免把无关页面塞进上下文。第三步是跳转。当LLM读完成一个页面发现信息不够时它参考页面的链接关系决定下一步跳转方向。比如读完“隔离级别定义”页面发现需要看“锁机制与隔离级别的实现关系”就沿着链接跳转过去。这个能力让复杂问题可以跨页面多次检索且每走一步都有明确的语义依据。第四步是收敛。LLM在阅读过程中持续判断当前积累的信息是否足以回答用户问题。足够则停止检索进入生成阶段不足则回退到第二步或第三步。收敛条件可以由工程侧控制——比如设置单次回答最多访问8个页面超过则强制收敛避免无休止的跳转消耗token。这四步合起来检索从“一次recall”变成了“一段决策过程”。LLM不再是被动的上下文接收者而是主动的信息搜寻者。这正是“把检索权交给LLM”这句话的准确含义。3.3 工程上的安全边界不能把检索权完全裸交给模型但把决策权交给LLM不意味着工程侧可以完全放手。LLM在检索路径上出现幻觉、误判、循环跳转都是可能的所以边界必须用代码和配置画死。我目前实践下来铁律有以下几条页面访问预算必须写死。每个query最多访问N个页面N根据成本模型定一般8到12比较合理。超限后立即截断转入生成阶段。检索路径必须有审计痕迹。每次检索决策路由到哪、打开哪页、从哪页跳到哪页、为什么跳都要记录日志。这是后续排查答案质量问题和调优链接结构的重要依据也是判断LLM检索行为是否符合预期的唯一手段。路由置信度低时自动降级。如果LLM在路由阶段给出的分类置信度低于阈值不要让它自由发挥工程侧自动退回向量检索召回候选页面再让LLM从中挑选。禁止LLM直接联外网。在知识库内部Wiki检索闭环内不要赋予LLM调用外部搜索工具的能力避免检索路径不可控。这四条边界不是限制LLM的自由度而是保证检索决策链在高成本、高延迟、不可控三种风险下仍然可控。权限可以松底线不能松。4. 实测里最容易翻车的三个落地点概念讲完了说点实操层面的东西。LLM-Wiki的思路在demo阶段跑通不难难的是在真实知识库上稳定运行。我按自己踩坑的代价从大到小排列一下。4.1 页面划分与原文结构的对齐问题第一个也是最值得重视的坑页面划分不是越细越好也不是按照原来的章节机械照搬而是要与原文结构对齐但允许合理合并。我最初尝试过按H2标题直接切页一份文档切成几十个小页面看起来粒度很漂亮。实际用下来发现问题明显一个H2章节里往往包含了背景、步骤、案例三个子主题切成单页后页面内部信息密度不够LLM翻阅时经常要点开两三个页面才能拼出完整答案token成本直接飙升。后来改成“H2做默认边界但子主题足够完整时独立成页”的策略页面数降了四成单次检索的访问页面数也明显下降。判断子主题是否“足够完整”经验标准是把这一页单独拿出来一个没读过原文的人能否通过页面本身理解这个主题。如果能独立成页如果必须靠上下文才知道在说什么就并入父页面。这个标准有点主观但实际执行起来比依赖纯规则靠谱得多。还有一个常见材料是PDF扫描件或图片型文档。这类材料必须先做OCR和版面分析否则切出来的页面全是乱码。别指望这个过程100%自动高精度版面还原必然需要人工抽检尤其是表格和代码块OCR很容易破坏对齐关系。4.2 链接关系的质量比数量重要链接是Wiki的灵魂但低质量的链接比没有链接更糟糕。LLM在翻阅时会相当信任链接关系——它认为链接指向的页面理应和当前页面相关。如果链接乱指LLM会被带到不相关的页面然后基于不相关的内容强行作答幻觉概率大增。我第一次全自动跑链接抽取时让LLM对所有页面两两计算关联度结果生成了上万条弱关联链接。实际使用中LLM频繁跳转到关联度tag于中等的页面检索链条越走越远最终答案越来越偏。后来调整了策略链接分两级。强链接主题强相关、结构上有明确先后次序、内容上存在必须相互引用才能解释清楚的关系。每页保留5到8条强链接这些链接是LLM导航的主要通道。弱链接主题相关但非必需仅作补充阅读。默认不主动推给LLM只有强链接链条找不到信息时才作为候选回退项。生成方式也改了不再追求全量自动。冷启动阶段先靠人工梳理核心页面的强链接然后用LLM批量生成候选、人工抽检后进入弱链接池。运行后配合检索审计日志发现跳跃次数多但答案质量差的链接关系定期清理。关于链接质量治理这个以后单独写一篇再展开其中会涉及怎么用图分析量化每条链接的“使用率”和“跳转后继续深读率”。4.3 检索成本与延迟决策链不是白来的多步检索在准确率上的收益是实打实的但代价也是实打实的——每次路由、翻阅、跳转都是一次LLM调用。一个复杂问题如果访问了8个页面加上中间的判断调用总调用次数可能达到15到20次。按主流大模型的定价算单次回答的成本是传统RAG的5到10倍。延迟方面串行决策链意味着用户需要等待更长时间复杂问题十几秒很正常。成本控不住的话这个方案根本没法在生产环境落地。我目前用三招压成本第一路由判题用便宜模型。路由和页面摘要判断这种“轻决策”用参数量较小的模型完全够只有真正打开页面深读和最终生成答案时才用强模型两级模型配合能砍掉一大半成本。第二页面访问加缓存。高频问题命中的页面大多是固定的几个热点页把页面内容和页面摘要缓存下来能直接跳过重复的检索步骤。对于一个每周被问几十次的常见问题第二周起基本只需要一次页面缓存命中的成本。这个思路我在缓存层设计里有单独的实现细节比如热点页面预取策略和失效更新机制等后续写具体的调优篇再聊。第三路由决策结果复用。同一类问题第一次路由到某个分类后把“问题模式-路由结果”记下来做经验库后续相似问题直接匹配经验库不再走判断链。这样既能保证检索有效性又不必为每一个新问题都承担完整决策链成本。延迟方面我建议在生产环境给LLM-Wiki接口设置两种模式——快速模式在3秒内只做一轮路由加一次翻阅适合常规问题深度模式放开到8个页面适合复杂问题。两种模式共用一个知识库只是决策链的深度预算不同体验上柔性强很多。5. 现阶段我对LLM-Wiki的最终判断经过前面对概念、机制和踩坑点的拆解肯定会有人问把检索权交给LLM路径这么长、成本这么高到底值不值我的看法是——对于几十篇文档的小知识库传统RAG完全够用没必要上LLM-Wiki那是杀鸡用牛刀。但当知识库体量到数千篇、问答场景涉及大量跨页对比和深度排查时把知识编译成Wiki、把检索权交给LLM就不是可选项而是刚需。从我实际跑下来的结果看复杂问题的答案完整性提升非常明显最大的收获不是某一次回答有多漂亮而是系统终于有了“可控的检索过程”——每一步为什么查到这页、为什么跳走、信息是否收敛。所有决策可审计、可回放、可优化链路这在传统RAG里是做不到的。如果真要在自己的项目里动手我给一个最朴素的建议捷径就是把“编译Wiki”当作一次领域建模来做。先别急着堆自动化找三个领域最能代表知识库结构的核心话题手工把它们对应的页面切分、链接和索引建扎实跑通一个端到端的小闭环再逐步扩大到全库。这中间积累的处理规范和踩坑经验比任何技术选型都值钱。