LLM Wiki 知识编译实战：从 RAG 存储到结构化 Wiki 的架构演进

1. 从存进去到编出来LLM Wiki 到底在解决什么大多数人第一次接触知识库脑子里浮现的画面就是一个巨大的文件夹里面塞满了 PDF、Markdown、网页剪藏然后接一个向量数据库用户提问时把最相似的几段捞出来喂给大语言模型。这套流程就是大家熟悉的 RAG。我早期也是这么干的搭起来很快demo 效果也唬人但真正上线跑一段时间就会发现一个尴尬的事实知识库越堆越大回答质量反而越来越飘。问题出在哪出在我们把存储当成了终点。传统 RAG 的本质是检索增强生成它假设知识是静态的、离散的、可以被切片和向量化的。但真实的知识是有结构的、有层次的、有依赖关系的。你把一篇讲知识编译的文章切成 512 token 的碎片再把这些碎片按余弦相似度排序模型拿到的是一堆失去上下文的断章残句。它能拼凑出一个看起来合理的答案但这个答案往往经不起推敲。LLM Wiki 这个概念核心思路就是把这个流程反过来。它不再把知识库当成一个仓库而是当成一个编译器。你喂进去的原始材料是源代码LLM Wiki 负责把这些源代码解析、链接、优化最终输出一个结构化的、可查询的、带语义关系的知识产物。这个产物可以是 Wiki 页面、可以是知识图谱、可以是一组带引用的问答对甚至可以是另一个更小的模型能直接消费的指令集。这个转变听起来抽象但落到实操上非常具体。传统 RAG 的流水线是文档 → 切片 → 向量化 → 检索 → 拼接 → 生成LLM Wiki 的流水线是文档 → 解析 → 实体抽取 → 关系建模 → 编译 → 结构化输出 → 查询。前者是线性的、无状态的后者是有状态的、可迭代的。你可以把 LLM Wiki 理解成一个知识编译器它的输入是原始语料输出是一个可以被反复查询和推理的知识结构。为什么现在这个概念突然火起来因为大语言模型的能力到了一个临界点。早期的模型做实体抽取和关系判断经常出错你不敢让它去编译知识只能让它做简单的检索拼接。但现在模型在结构化输出、长上下文理解、指令遵循上的能力大幅提升让它去承担知识编译这个角色变得可行了。Karpathy 提的那个 LLM Wiki 思路本质上就是让模型把一堆零散笔记编译成一个互相链接的 Wiki 网络而不是简单地做向量检索。所以这篇文章要聊的不是怎么再搭一个 RAG demo而是怎么把知识库从存储态推进到编译态。我会从架构设计、核心流程、实操踩坑、性能权衡几个角度把 LLM Wiki 这套东西拆开讲清楚。适合已经搭过基础 RAG、但觉得效果不够好的朋友也适合正在选型知识库方案的技术负责人。2. 知识编译的流水线拆解从原始语料到结构化 Wiki2.1 为什么不能直接上向量检索先说一个反直觉的结论在 LLM Wiki 的架构里向量检索不是第一公民而是最后一道兜底。这跟传统 RAG 完全相反。传统 RAG 里向量检索是核心所有东西都围着它转。但在知识编译的视角下向量检索只是一个模糊匹配的补充手段真正的主力是结构化的知识表示。原因很简单。向量检索的本质是相似度匹配它擅长回答哪段文字和这个问题最像但它不擅长回答这个概念和那个概念是什么关系、这个结论依赖哪些前提、这个流程的下一步是什么。后面这些问题需要的是结构化的知识表示而不是一堆浮点数向量。我做过一个对比实验。同一个技术文档库分别用传统 RAG 和 LLM Wiki 编译后的结构来回答这个系统的鉴权流程是怎样的。传统 RAG 捞出来的是几段提到鉴权的文字模型拼出来的答案经常漏掉关键步骤因为那些步骤分散在不同段落里向量相似度不高。而 LLM Wiki 编译后鉴权流程被抽取成一个有序的步骤链每个步骤关联到具体的接口和配置项模型直接读这个结构就能给出完整答案。2.2 编译流水线的四个阶段LLM Wiki 的编译流水线我把它拆成四个阶段解析、抽取、链接、编译。每个阶段都有明确的输入输出可以独立调试和替换。解析阶段负责把各种格式的原始文档转成统一的中间表示。PDF 要处理版面分析Markdown 要处理标题层级网页要处理正文提取。这个阶段的目标不是读懂内容而是保留结构。很多 RAG 方案在这一步就把结构丢了直接按固定长度切片这是后面效果差的根源。抽取阶段是让大语言模型从解析后的文本里抽出实体、概念、关系、流程、参数。这里的关键是schema 设计。你不能让模型自由发挥得给它一个明确的抽取模板。比如对于技术文档schema 可能包括概念名称、定义、所属模块、依赖项、相关接口、配置参数。对于业务流程文档schema 可能包括步骤序号、操作描述、前置条件、输出结果、异常处理。链接阶段是把抽取出来的实体和概念建立关联。这一步是 LLM Wiki 区别于普通知识图谱的地方。普通知识图谱靠人工定义本体LLM Wiki 靠模型在编译过程中动态发现关系。比如模型在抽取时发现A 概念的定义里提到了 B 概念就自动建立一条A 依赖 B的边。这些边会随着编译的迭代不断丰富。编译阶段是把前面三个阶段产出的结构化数据编译成最终可查询的知识产物。这个产物可以是一个 Wiki 站点每个概念一个页面页面之间互相链接也可以是一个知识图谱支持图查询还可以是一组带引用的问答对直接给下游应用消费。2.3 一个具体的编译示例光说流程太抽象我拿一个实际场景走一遍。假设你有一份 50 页的产品技术白皮书要把它编译成 LLM Wiki。第一步解析。用版面分析工具把 PDF 转成带层级结构的 Markdown保留标题、列表、表格、代码块。这一步的输出是一棵文档树每个节点有类型和内容。第二步抽取。把文档树按章节切分每个章节送给大语言模型让它按预设 schema 抽取。比如对于系统架构这一章模型抽取出组件列表、组件职责、组件间调用关系、部署拓扑。对于配置说明这一章模型抽取出配置项名称、类型、默认值、取值范围、影响范围。第三步链接。把不同章节抽出来的实体做对齐。比如系统架构里提到的鉴权服务和配置说明里提到的auth-service是同一个东西需要合并。这一步可以用模型做实体消歧也可以用规则做字符串匹配实际项目中通常是两者结合。第四步编译。把对齐后的实体和关系编译成 Wiki 页面。每个组件一个页面页面里包含职责描述、配置项表格、调用关系图、相关章节的原文引用。页面之间通过链接互相跳转。这个编译产物查询效率和回答质量都比传统 RAG 高一个档次。因为用户问鉴权服务怎么配置系统直接定位到鉴权服务的 Wiki 页面页面里配置项、默认值、示例一应俱全不需要模型去猜。3. 编译质量的决定因素Schema、分块与模型选型3.1 Schema 设计是天花板在 LLM Wiki 的实操中schema 设计决定了编译质量的上限。模型再强schema 设计得烂抽出来的东西也是垃圾。我见过太多项目在这一步偷懒直接让模型自由抽取结果每次跑出来的结构都不一样根本没法用。好的 schema 有几个特征。第一字段名要具体不要用描述这种模糊词要用功能定义、输入参数、输出格式这种明确词。第二字段类型要明确是字符串、列表、还是嵌套对象要在 schema 里定义清楚。第三要有必填和选填的区分必填字段缺失时模型要明确标注而不是瞎编。我常用的一个技术文档抽取 schema 长这样{ concept_name: string, 必填, 概念的标准名称, aliases: list[string], 选填, 别名和缩写, definition: string, 必填, 一句话定义, category: enum, 必填, 所属分类, dependencies: list[string], 选填, 依赖的其他概念, related_apis: list[object], 选填, 相关接口, config_params: list[object], 选填, 配置参数, source_refs: list[string], 必填, 原文出处 }这个 schema 的好处是每个字段都有明确的语义和类型约束模型抽取时不容易跑偏。source_refs字段尤其重要它保证了编译产物的可追溯性用户看到任何一个结论都能点回原文。3.2 分块策略要跟着结构走传统 RAG 的分块策略是固定长度 重叠窗口简单粗暴。LLM Wiki 的分块策略要跟着文档结构走。标题层级就是天然的分块边界一个三级标题下的内容通常是一个完整的语义单元不应该被切断。我的做法是先按标题层级切分如果某个章节超过模型上下文窗口的 70%再按段落切分切分时保留父级标题作为上下文前缀。这样每个块都带着自己的位置信息模型抽取时能知道这段内容在文档的哪个位置属于哪个章节。对于表格和代码块要特殊处理。表格不能按行切要整表保留否则模型抽出来的参数对应关系就乱了。代码块要保留语言标记和上下文注释否则模型不知道这段代码是干什么的。3.3 模型选型不是越大越好很多人以为 LLM Wiki 必须用最强的模型其实不是。抽取阶段和编译阶段对模型能力的要求不一样。抽取阶段需要的是结构化输出能力和指令遵循能力对模型的推理深度要求不高。这个阶段用中等规模的模型就够比如 7B 到 14B 参数级别的模型经过结构化输出微调后效果可以接近大模型。用大模型做抽取成本高、速度慢性价比很低。编译阶段需要的是关系推理能力和一致性维护能力这个阶段对模型能力要求高。因为编译时要处理实体消歧、关系推断、冲突消解这些都需要较强的推理能力。这个阶段建议用大模型或者用经过专门微调的中等模型。我实测下来一个比较经济的组合是抽取用本地部署的中等模型编译用 API 调用的大模型。这样既控制了成本又保证了编译质量。如果全部用本地模型编译阶段的一致性会差一些需要增加人工校验环节。4. 实操踩坑编译流水线跑通之后才会遇到的问题4.1 实体消歧同一个东西有十个名字编译流水线跑通之后第一个撞上的坑就是实体消歧。同一个概念在不同文档里可能有不同的叫法。比如用户中心、用户服务、user-service、账户系统指的可能是同一个东西。如果不做消歧编译出来的 Wiki 里会有四个重复页面每个页面都不完整。我的解决方案是两阶段消歧。第一阶段用规则做粗筛把字符串相似度高的实体聚成一簇。第二阶段用模型做精判把每一簇的实体名称和上下文送给模型让它判断是不是同一个东西。模型判断时给它一个明确的提示如果两个名称指向同一个概念输出 MERGE如果指向不同概念输出 SEPARATE如果不确定输出 UNCERTAIN。对于 UNCERTAIN 的情况不要强行合并而是标记出来让人工确认。我踩过的坑就是早期为了自动化把 UNCERTAIN 也强行合并了结果把两个不同的服务合并成了一个编译出来的 Wiki 页面内容自相矛盾。4.2 关系抽取的幻觉问题模型在抽取关系时会产生幻觉。比如原文只说A 调用了 B模型可能抽取出A 依赖 B、A 继承 B、A 包含 B三条关系。多出来的两条就是幻觉。控制幻觉的办法有三个。第一在 schema 里限定关系类型只允许模型从预定义的关系列表里选不允许自由发挥。第二要求模型给出原文依据每条关系必须附带原文片段没有依据的关系直接丢弃。第三做关系一致性校验比如A 依赖 B和B 依赖 A不能同时成立发现矛盾就标记出来人工复核。我现在的做法是关系抽取的 prompt 里明确写只抽取原文明确表述的关系不要推断。每条关系必须附带原文引用。如果原文没有明确表述关系输出空列表。 这样虽然会漏掉一些隐含关系但保证了准确率。隐含关系可以在编译阶段用规则或模型推理补全但那是另一个环节的事。4.3 编译产物的版本管理LLM Wiki 的编译产物是动态的每次重新编译都可能产生变化。如果没有版本管理你会陷入昨天还能查到的内容今天不见了的困境。我的做法是把编译产物当成代码来管理。每次编译生成一个版本号产物存到 Git 仓库里。查询时指定版本号保证结果可复现。同时保留编译日志记录每个实体的来源、每次关系变更的原因。这样出问题时可以追溯是模型抽取错了还是链接阶段合并错了还是编译阶段推理错了。这个做法听起来重但实际跑起来成本不高。Git 仓库存文本文件增量很小。编译日志用结构化格式存查询很方便。关键是它给了你可回滚的能力编译质量下降时可以快速回退到上一个稳定版本。5. 查询侧的设计编译产物怎么被消费5.1 查询路由先结构化后向量编译产物建好之后查询侧的设计要跟着变。查询请求先走结构化查询结构化查询搞不定再走向量检索。这个顺序不能反。结构化查询包括按实体名称精确查找、按关系路径图查询、按分类浏览。比如用户问鉴权服务的配置项有哪些系统先按鉴权服务这个实体名去查 Wiki 页面页面里直接有配置项表格不需要向量检索。只有用户问的是模糊的、开放性的问题比如这个系统怎么保证安全才走向量检索兜底。这个路由策略的效果提升很明显。我实测下来结构化查询能覆盖 70% 以上的常见问题而且回答准确率接近 100%因为答案直接来自编译好的结构不经过模型生成。剩下 30% 的开放性问题走向量检索虽然准确率低一些但因为有结构化知识作为上下文补充也比纯 RAG 好很多。5.2 引用追溯每个结论都要能点回原文LLM Wiki 相比传统 RAG 的一个巨大优势是引用可追溯。因为编译阶段每个实体和关系都记录了source_refs查询时可以把这些引用一并返回。用户看到答案后可以点击引用跳转到原文对应位置自己验证。这个功能在技术文档场景下特别有价值。工程师查配置项时不仅想知道默认值是多少还想知道这个默认值是在哪份文档里定义的、有没有版本差异。传统 RAG 给不了这个LLM Wiki 可以。实现上source_refs要存得足够细。不能只存来自白皮书第 3 章要存到来自白皮书第 3 章第 2 节第 4 段字符偏移 1200-1450。这样前端可以精确定位到原文位置高亮显示。5.3 增量编译不要每次都全量重跑全量编译很慢一个中等规模的知识库跑一次可能要几十分钟。实际使用中文档是持续更新的不可能每次都全量重跑。增量编译是必须的。增量编译的关键是变更检测。文档更新后先算出哪些章节变了只对这些章节重新做解析、抽取、链接。编译阶段要做全局一致性检查但只检查受影响的实体和关系不需要全量重算。我用的变更检测策略是内容哈希。每个章节算一个哈希值存到元数据里。文档更新后重新算哈希哈希变了就标记为脏章节只处理脏章节。这个策略简单可靠实测能减少 80% 以上的重复计算。6. 成本与性能的平衡本地部署还是 API 调用6.1 算力约束下的资源配置LLM Wiki 的编译过程是算力密集型的。抽取阶段要跑大量模型推理编译阶段要做关系推理和一致性检查。如果全部用 API 调用成本会很高。如果全部本地部署对硬件要求又很高。我的建议是分层部署。抽取阶段用本地模型因为抽取任务相对简单中等模型就能胜任而且抽取是批量任务本地跑没有延迟压力。编译阶段用 API 调用大模型因为编译任务复杂对模型能力要求高而且编译是低频任务API 成本可以接受。具体配置上抽取阶段用一张消费级显卡跑 7B 到 14B 的模型就够。编译阶段按需调用 API控制并发数避免成本失控。查询阶段如果走结构化查询几乎不消耗算力走向量检索时用本地嵌入模型做向量化成本也很低。6.2 缓存策略编译结果要缓存编译产物要缓存而且要多级缓存。实体级缓存存每个实体的抽取结果文档没变就不重新抽取。关系级缓存存关系推理结果实体没变就不重新推理。查询级缓存存常见查询的结果相同查询直接返回缓存。缓存失效策略要跟变更检测联动。脏章节对应的实体缓存失效实体变更对应的关系缓存失效。这样保证缓存不会返回过期结果。我踩过的坑是早期没做缓存每次查询都重新编译响应时间长达几十秒。加了缓存之后常见查询的响应时间降到毫秒级。这个提升对用户体验是决定性的。6.3 质量与成本的权衡最后说一个现实问题编译质量跟成本是正相关的。用更强的模型、更细的 schema、更严格的校验质量会更好但成本也更高。实际项目中要找到平衡点。我的经验是核心知识用高质量编译边缘知识用低成本编译。比如产品的核心功能、关键接口、重要配置这些用大模型精细编译保证准确率。一些辅助性的、参考性的内容用中等模型粗编译够用就行。这样整体成本可控核心质量有保障。判断哪些是核心知识可以看查询日志。查询频率高的实体和关系就是核心知识值得投入更多编译资源。查询频率低的可以降低编译精度。这个策略是动态调整的随着使用不断优化。7. 我在这套方案上踩过的几个真实坑第一个坑是过度依赖模型抽取。早期我让模型自由抽取所有内容结果抽出来的东西五花八门有的章节抽出十个字段有的章节抽出三个字段根本没法统一。后来改成严格 schema 约束虽然灵活性降低了但一致性大幅提升。这个教训是在知识编译场景下一致性比灵活性重要。第二个坑是忽略原文结构。我一开始把文档当成纯文本处理按固定长度切片结果标题和正文被切散了模型抽取时经常把上一节的内容算到下一节。后来改成按标题层级切分保留结构信息抽取准确率明显提升。这个教训是文档的结构信息是宝贵的上下文不能丢。第三个坑是编译产物不做版本管理。有一次模型升级后重新编译结果大量实体被合并错了但因为没有版本管理回滚不了只能手动修复。后来引入 Git 管理编译产物每次编译打 tag出问题一键回滚。这个教训是编译产物是资产要有版本管理。第四个坑是查询路由设计反了。我一开始让所有查询都走向量检索结构化查询只是补充。结果发现大量简单查询被复杂化响应慢、准确率低。后来改成结构化查询优先向量检索兜底效果立竿见影。这个教训是能用结构化查询解决的不要用向量检索。第五个坑是忽略增量编译。全量编译跑一次要半小时文档一更新就得重跑开发效率极低。后来做了变更检测和增量编译只处理脏章节编译时间降到几分钟。这个教训是增量能力是知识库能否持续运行的关键。这套 LLM Wiki 的方案我从去年开始在自己的项目里跑中间迭代了七八个版本。现在回头看最大的收获不是技术上的而是认知上的知识库的价值不在于存了多少而在于编译出了什么。一个编译良好的小知识库比一个堆满原始文档的大知识库有用得多。如果你也在做知识库相关的项目建议尽早从存储思维切换到编译思维这个转变越早做后面的路越顺。