1. 为什么要把知识库“编译”成 Wiki第一次听到“LLM Wiki”这个词很多人会下意识地把它理解成“给大模型用的维基百科”。这个理解只对了一半。真正做过知识库落地的人会明白Wiki 在这里不是指某个具体网站而是指一种结构化的、可被人和机器同时阅读的知识组织形态。把知识库编译成 Wiki本质上是把散落在各种文档、表格、聊天记录里的原始素材转换成一套带层级、带链接、带语义边界的知识节点集合。我最早接触这个思路是在处理一个内部技术文档库的时候。当时库里有三千多篇 Markdown、几百个 PDF还有一堆从聊天工具里导出的问答记录。直接拿去做向量检索效果惨不忍睹——问“某个接口的超时配置在哪”检索出来的却是另一篇讲部署流程的文章因为两篇都出现了“超时”这个词。问题不在于向量模型不行而在于原始知识本身没有被组织过。向量检索是在一堆没有骨架的肉里找一块特定的肌肉找不到是正常的。把知识库编译成 Wiki解决的正是这个“骨架缺失”的问题。它要求我们在入库之前先做一轮结构化的整理把一篇长文档拆成若干语义完整的节点给每个节点一个稳定的标题和路径建立节点之间的引用关系标注每个节点适用的范围和前提条件。做完这一步知识库才真正具备了被检索的价值。这里有个关键判断不是所有知识库都值得编译成 Wiki。如果你的知识库只有几十篇文档且内容高度同质直接做全文检索就够了编译反而是过度工程。但如果你的知识库满足下面任意一条编译就是必须的文档数量超过五百篇且来源多样同一个概念在不同文档里有不同表述甚至互相矛盾存在大量“前提条件”比如某个配置只在特定版本下有效需要支持多轮追问而不是一问一答我见过太多团队跳过这一步直接上向量数据库结果调了三个月参数召回率还是上不去。根因不在检索层在知识层。1.1 Wiki 形态和普通知识库的本质区别普通知识库的存储单位是“文档”Wiki 的存储单位是“节点”。这个区别听起来很小实际影响巨大。一篇文档里往往混杂了多个主题。比如一篇讲“服务部署”的文档前半部分讲环境准备中间讲配置项最后讲回滚流程。如果整篇作为一个检索单位向量会被平均掉任何一个具体问题的相似度都不高。而 Wiki 形态要求把它拆成三个节点环境准备、配置项说明、回滚流程。每个节点只讲一件事向量表达就精准了。另一个区别是链接。普通知识库的文档之间是孤立的Wiki 的节点之间是有向图。当 LLM 检索到“配置项说明”这个节点时它能顺着链接找到“环境准备”和“回滚流程”从而获得完整的上下文。这一点在 Agent 场景下尤其重要因为 Agent 需要的不只是一个答案而是答案所在的完整决策链。还有一个容易被忽略的区别Wiki 节点带有明确的边界声明。每个节点会写清楚“本文适用于哪个版本”“不适用于什么情况”。这看起来是负担实际上是给 LLM 的护栏。没有边界的知识LLM 会过度泛化把只在特定条件下成立的结论当成普遍真理。1.2 编译这个词的准确含义我用“编译”而不是“整理”或“转换”是有意为之。编译在计算机里指的是把高级语言翻译成机器能执行的形式这个过程包含词法分析、语法分析、语义分析、优化、代码生成。知识库编译成 Wiki流程惊人地相似。词法分析对应的是切分把原始文档切成最小语义单元。语法分析对应的是结构识别判断这些单元之间的层级和顺序关系。语义分析对应的是概念归一把不同表述的同一概念合并把同名但不同义的概念区分开。优化对应的是去重和精简删掉冗余表述保留核心信息。代码生成对应的是节点输出生成带标题、路径、链接、边界的 Wiki 节点。这个类比不是文字游戏。它意味着知识库编译应该像编译器一样是一个可重复、可验证、可增量的过程。原始文档更新了不需要重新编译整个库只需要重新编译受影响的节点。这一点在知识库规模上去之后是能不能维护下去的分水岭。2. 检索权交给 LLM 到底意味着什么“把检索权交给 LLM”这句话是这套方法论里最容易被误读的部分。很多人第一反应是让 LLM 直接去读整个知识库然后回答问题。这在知识库小的时候可行一旦超过上下文窗口就彻底失效。所以这里的“交给 LLM”不是让 LLM 承担存储和全量扫描而是让 LLM 承担检索决策。传统检索的流程是固定的用户提问 → 向量化 → 相似度匹配 → 返回 Top-K → 拼进 Prompt。这个流程里LLM 只在最后一步参与前面全是机械的。问题在于用户的提问往往不是一次检索能解决的。比如问“为什么我的服务启动失败”可能需要先检索错误码再根据错误码检索对应的配置项再根据配置项检索版本兼容性说明。这是一个多跳过程固定流程做不到。把检索权交给 LLM就是让 LLM 来决定下一步该查什么。它拿到用户问题后先判断需要哪些信息然后生成检索请求拿到结果后判断信息是否足够不够就继续查够了就组织答案。这个过程中LLM 是检索的调度者而不是被动的消费者。2.1 检索权转移的三个层次我把这个转移分成三个层次方便你判断自己的项目该做到哪一层。第一个层次是查询改写。LLM 不直接检索而是先把用户的口语化问题改写成适合检索的形式。比如用户问“那个超时怎么调”LLM 改写成“服务调用超时时间配置项”。这一步不需要多跳但能显著提升召回率。实现成本低收益明显适合作为起点。第二个层次是多跳检索。LLM 根据第一轮检索结果决定是否需要第二轮、第三轮检索。每一轮的查询词由 LLM 根据已有信息生成。这一步需要 LLM 具备一定的推理能力且需要给检索工具设计清晰的接口。实现成本中等但对复杂问题的效果提升很大。第三个层次是检索策略选择。知识库里可能同时存在向量索引、关键词索引、图索引。LLM 根据问题类型决定用哪种索引甚至组合使用。比如事实性问题走向量关系性问题走图精确匹配走关键词。这一步实现成本最高但在知识库结构复杂时是必要的。大部分项目做到第二个层次就够用了。第三个层次适合知识库规模超过万级节点、且查询类型高度多样的场景。2.2 为什么不能让 LLM 直接读全库这里要专门说一下因为这是最常见的误区。有人会想既然 LLM 上下文窗口越来越大那直接把整个知识库塞进去不就行了。三个现实问题让这条路走不通。第一是成本。每次提问都把全库塞进 Prompttoken 消耗是检索方案的几十倍甚至上百倍。第二是注意力稀释。上下文越长LLM 对中间部分的注意力越弱关键信息容易被淹没。第三是更新延迟。知识库一更新所有缓存全部失效响应时间不可控。所以“检索权交给 LLM”的前提是知识库已经被编译成结构良好的 Wiki 节点。LLM 检索的是节点不是原始文档。节点足够小可以精确匹配节点足够结构化可以顺着链接跳转。这才是可行的路径。2.3 检索权和生成权的分离还有一个设计上的关键点检索权和生成权要分离。LLM 决定查什么但查到的内容不能直接由同一个 LLM 无约束地改写。原因很简单LLM 在生成时会有幻觉如果它同时负责检索和生成一旦检索结果不理想它可能用幻觉来填补。我的做法是检索阶段用一个 LLM 实例只负责生成查询和判断信息充分性不生成最终答案。生成阶段用另一个实例只负责基于检索到的节点组织答案不允许引入节点之外的信息。两个实例的 Prompt 完全不同职责边界清晰。这样即使生成阶段出现幻觉也能通过对比检索节点快速定位。3. 知识库编译成 Wiki 的完整实操流程前面讲的是思路这一部分讲具体怎么做。我按实际项目里的顺序把流程拆成六步。每一步都有踩过的坑我会标出来。3.1 第一步原始素材的盘点与分类在动手编译之前先花时间盘点。我见过太多人跳过这一步直接开始切分结果切到一半发现素材里有大量重复和矛盾返工成本极高。盘点的产出是一张表记录每个素材的来源、类型、更新频率、可信度。可信度这一列很重要因为不同来源的素材冲突时需要有一个优先级。比如官方文档的可信度高于聊天记录最新版本的高于旧版本。素材来源类型更新频率可信度处理策略官方产品文档Markdown季度高全量编译内部技术方案PDF不定期高全量编译聊天问答记录文本每日中筛选后编译历史邮件文本不定期低仅提取结论外部参考资料网页不定期中人工审核后编译这张表不是形式主义。它决定了后续编译的优先级和资源分配。可信度低的素材不要花太多时间做精细切分提取核心结论就够了。注意盘点阶段一定要和素材的维护者确认更新频率。我遇到过一次某份文档标注是季度更新实际已经两年没动过里面的配置项早就废弃了。如果按季度更新来处理会浪费大量编译精力。3.2 第二步语义切分与节点定义切分是编译里最考验判断力的一步。切得太粗节点内部主题混杂检索不准切得太细节点之间上下文断裂LLM 拼不出完整答案。我的经验是按“一个节点回答一个问题”来切。具体操作时先通读文档在每一个主题转换的地方做标记。主题转换的信号通常有出现新的小标题、出现“另外”“接下来”“需要注意的是”这类转折词、举例结束回到论述。切分完之后给每个节点定义一个稳定的路径。路径的格式建议是“领域/子领域/主题”。比如“部署/环境准备/依赖安装”。路径的作用是给 LLM 一个空间感让它知道这个节点在知识体系里的位置。这里有个坑不要用文档原有的标题作为节点标题。文档标题往往是为了阅读流畅不是为了检索精确。比如“一些注意事项”这种标题检索时毫无信息量。要改写成“配置项修改时的三个兼容性注意事项”这种自带语义的标题。3.3 第三步概念归一与冲突消解这一步是编译的核心价值所在。同一个概念在不同文档里可能有不同叫法比如“超时时间”“超时时长”“timeout”如果不归一检索时会漏掉。反过来同一个词在不同语境下可能指不同东西比如“节点”在部署语境下指服务器在图结构语境下指数据点如果不区分检索时会混入无关内容。我的做法是建一张概念表记录每个标准概念和它的所有别名以及它的适用语境。这张表在编译时用来做替换和标注在检索时用来做查询扩展。冲突消解更麻烦。当两份素材对同一件事给出不同说法时不能简单取最新的因为旧说法可能对应旧版本仍然有效。我的处理方式是保留两个节点但在节点里明确标注适用版本和适用条件。然后在两个节点之间加一条“互斥”链接提示 LLM 这两个结论不能同时使用。提示冲突消解不要追求一次性做完。知识库是活的冲突会不断出现。更好的做法是建立一个冲突登记表每次发现冲突就登记定期集中处理。这样不会阻塞编译进度。3.4 第四步链接建立与图结构生成节点建好之后要建立节点之间的链接。链接分三种层级链接、引用链接、互斥链接。层级链接是父子关系比如“环境准备”是“依赖安装”的父节点。引用链接是相关内容之间的跳转比如“配置项说明”引用“版本兼容性”。互斥链接是前面提到的标注两个节点不能同时使用。链接的建立可以半自动化。先用规则匹配比如两个节点共享超过三个关键词就建立候选链接然后人工审核。完全自动的链接质量不可控完全人工的效率太低。半自动是平衡点。图结构生成之后要做一个连通性检查。如果发现某些节点是孤立的没有任何链接要么是切分时漏了关联要么是这个节点本身冗余可以考虑合并或删除。3.5 第五步节点内容的标准化输出每个节点最终要输出成标准格式。我用的格式是 YAML 头加 Markdown 正文。YAML 头里放元数据节点 ID、路径、标题、适用版本、适用条件、最后更新时间、可信度。正文里放具体内容控制在 300 到 800 字之间。为什么是 300 到 800 字太短信息不完整太长向量表达会被稀释。这个区间是实测下来检索效果最好的。超过 800 字的节点考虑再切分。正文的写法也有讲究。第一句必须是这个节点的核心结论因为检索时第一句的权重最高。后面再展开解释。这样即使 LLM 只读了第一句也能拿到关键信息。3.6 第六步增量编译与版本管理知识库编译不是一次性的。原始素材更新后要能增量编译。这就要求每个节点记录它来源于哪个原始素材的哪个版本。素材更新时对比版本差异只重新编译受影响的节点。版本管理用 Git 就够了。每次编译提交一次节点的新增、修改、删除都有记录。出问题时可以回滚到任意历史版本。这一点在知识库规模大了之后是救命的。4. 检索权交给 LLM 的具体实现编译完成后知识库变成了一堆结构化的 Wiki 节点。接下来是让 LLM 来检索这些节点。这一部分讲具体实现。4.1 检索工具的设计LLM 要检索得给它工具。工具的设计要遵循一个原则接口简单语义清晰。我通常给三个工具。第一个是search_nodes输入查询词返回匹配的节点列表每个节点返回 ID、标题、路径、摘要。第二个是get_node输入节点 ID返回节点完整内容。第三个是follow_link输入节点 ID 和链接类型返回关联节点列表。这三个工具的组合能覆盖大部分检索场景。LLM 先用search_nodes找到候选再用get_node读取详情需要扩展时用follow_link跳转。工具的返回格式要固定方便 LLM 解析。我用的格式是 JSON字段名固定不返回多余信息。返回内容里不要有自然语言解释解释由 LLM 自己生成。4.2 检索循环的控制LLM 检索时容易陷入两个极端要么查一次就停信息不够要么反复查停不下来。需要设置控制机制。我的做法是设置最大检索轮次通常是 5 轮。每轮结束后让 LLM 判断信息是否充分。判断的标准写在 Prompt 里如果已经能回答用户问题且答案有节点支撑就停止如果还缺关键信息继续查如果连续两轮没有新信息停止。这个判断逻辑要写清楚不能含糊。含糊的 Prompt 会让 LLM 在该停的时候不停或者不该停的时候停。4.3 检索结果的组装检索结束后LLM 拿到了一组节点。这些节点要组装成最终答案。组装时要注意三点。第一只使用检索到的节点内容不允许 LLM 引入外部知识。这一点要在 Prompt 里反复强调。第二标注信息来源每个结论后面标注来自哪个节点方便用户核查。第三处理节点间的冲突如果检索到的节点有互斥链接要在答案里说明两种情况的适用条件让用户判断。组装后的答案要简洁不要把所有节点内容都堆上去。LLM 要做的是提炼和综合不是复制粘贴。4.4 一个完整的检索示例假设用户问“服务启动时报超时错误怎么排查”第一轮LLM 生成查询“服务启动 超时 错误 排查”调用search_nodes返回三个候选节点超时错误码说明、启动流程配置项、网络连接检查。第二轮LLM 调用get_node读取三个节点。发现超时错误码说明里提到“超时可能是依赖服务未就绪导致”于是生成新查询“依赖服务 就绪检查”调用search_nodes。第三轮找到“依赖服务就绪检查”节点读取后发现需要检查健康检查接口配置。此时 LLM 判断信息充分停止检索。第四轮LLM 组装答案先说明超时的常见原因再给出排查步骤每一步标注来源节点。答案里包含错误码说明、配置项检查、依赖服务检查三个部分逻辑完整。这个示例里LLM 做了三次检索决策每次决策都基于上一轮的结果。固定流程做不到这一点因为固定流程不知道第一轮之后该查什么。5. 常见问题与排查技巧实录这一部分是我在实际项目里踩过的坑整理成速查表。每个问题都附了排查思路和解决方法。问题现象可能原因排查方法解决方法检索结果总是无关节点切分过粗主题混杂随机抽 10 个节点看是否只讲一件事重新切分按“一个节点一个问题”原则检索结果重复概念未归一同一概念多个节点搜索同一概念的不同叫法建立概念表合并重复节点LLM 检索停不下来停止条件不明确查看检索日志看每轮是否有新信息明确停止条件设置最大轮次答案有幻觉生成阶段引入了外部知识对比答案和检索节点强化 Prompt禁止引入节点外信息节点更新后检索失效增量编译未触发检查素材版本和节点版本建立版本对比机制自动触发重编译多跳检索断链链接建立不完整检查节点连通性补充引用链接做连通性检查检索速度慢节点数量过大索引未优化查看检索耗时分布分层索引先粗筛再精排除了表里的问题还有几个经验性的技巧。技巧一给节点加“反例”字段。有些节点讲的是“什么情况下适用”但 LLM 容易过度泛化。加一个“不适用情况”字段明确写出这个节点不适用于什么场景能有效减少误用。技巧二检索日志要保留。每次检索的查询词、返回节点、LLM 的决策过程都要记录。出问题时日志是唯一的排查依据。我通常保留最近一个月的日志定期分析高频查询和失败查询。技巧三定期做检索质量评估。准备一组标准问题每个问题有标准答案和标准来源节点。定期跑一遍看召回率和准确率。质量下降时能及时发现。技巧四节点标题要包含同义词。比如“超时配置”这个标题可以在后面加括号写上“超时时长、timeout”。这样检索时命中率更高。标题是检索的第一入口值得多花心思。技巧五不要追求一次编译完美。知识库编译是迭代过程。先编译一版能用的上线跑起来根据实际检索效果再优化。我见过团队花三个月做完美编译结果上线后发现用户的问题类型和预期完全不同白费功夫。6. 工具选型与工程化建议最后说一下工具选型。这部分不是必须的但能帮你少走弯路。编译阶段我用 Python 脚本加 LLM API。脚本负责切分、归一、链接生成LLM 负责语义判断和内容改写。为什么不全部用 LLM因为切分和链接生成有大量规则性工作用脚本更快更稳定。LLM 只用在需要语义理解的地方。存储阶段节点用 Markdown 文件存 Git索引用轻量级向量库。不建议一上来就用重型向量数据库节点数量在万级以下时轻量级方案完全够用且更容易调试。检索阶段LLM 的选型要看任务复杂度。查询改写用轻量模型就够多跳检索和答案组装用能力更强的模型。分开选型能控制成本。工程化方面最重要的是可观测性。每次检索的输入输出、每轮决策、耗时、token 消耗都要记录。没有可观测性出了问题只能猜。我通常用一个简单的日志表记录这些字段定期分析。还有一个建议先做小规模验证。选一个子领域的知识库比如只编译“部署”相关的文档跑通全流程验证效果。效果达标再扩展到全库。全库编译的复杂度是子领域的十倍以上直接上全库容易失控。这套方法我在几个项目里跑过知识库规模从几百节点到几万节点都有。规模越大前期编译的投入回报越明显。小规模时可能感觉不到优势但一旦超过某个临界点没有编译的知识库会迅速变得不可维护。这个临界点我的经验是五百个节点左右。低于这个数怎么搞都行高于这个数不编译就是给自己挖坑。