文章指出将企业知识库接入AI时关键不在于“找到资料”而在于“组织成知识”。传统RAG方法每次查询都需重新理解效率低下。编译式RAG通过提前编译知识查询时直接使用编译结果提升效率。文章介绍了编译式RAG的原理、实现方法以及与传统RAG和GraphRAG的区别并建议从简单的知识库开始实践强调知识库应从“存资料”转向“组织知识”。找到资料从来不是最难的事把散落在几十份文档里的资料组织成知识才是企业知识库真正的分水岭。最近在折腾企业知识库接入 AI的项目越弄越觉得有个地方不太对劲。我们给 AI 接企业知识库的标准做法基本都是这一套PDF、Word、网页、数据库、Notion、飞书文档统统切 chunk、做 embedding、扔进向量数据库。用户一提问系统去检索找到几个相关片段交给大模型自己判断哪些有用、怎么组织成答案。这套流程当然管用但有个问题很容易被忽略同一批知识AI 每回答一次问题都要重新“理解”一遍。知识之间关联越多这个毛病就越明显。举个例子。假设你有 100 篇关于 AI Agent 的文章20 篇讲架构、15 篇讲 Memory、10 篇讲 MCP、8 篇讲 Workflow剩下的是各种项目实践。用户问“MCP 为什么会改变 Agent 的工具调用方式”传统 RAG 会去检索 MCP、Agent、Tool Use 相关的片段但真正靠谱的答案往往不是某一个 chunk 里现成写好的——它需要把好几篇文章的信息串起来Agent → Tool Use → MCP → 标准化工具协议 → 工具发现 → 权限控制 → 企业系统接入。也就是说真正难的不是“找到资料”而是“把散落的资料组织成知识”。这正是最近一种叫编译式 RAGCompiled RAG的思路想解决的问题。它没打算把传统 RAG 干掉只是换了个角度与其每次查询都临时组织一遍知识不如先把知识编译好查询时直接用编译结果。听起来变化不大但足以改变我们设计知识库的方式。传统 RAG 到底卡在哪儿把传统 RAG 的流程拆开看1000 份文档切成 10 万个 chunk做 embedding存进向量数据库用户提问后召回 Top-K交给 LLM 综合出答案。这本质上是个搜索系统——用户问什么就去库里找什么。所以它最擅长回答“帮我找到相关资料”这类问题比如“公司年假多少天”检索几个片段直接给答案就行。但一旦问题变成“为什么公司去年开始调整销售政策”事情就不一样了这可能牵扯到销售政策、财务制度、公司战略、某次管理层会议、客户投诉、销售数据、产品变化信息分散在十几份甚至几十份文档里。模型每次都得重新完整走一遍检索、阅读、建立关联、综合推理的过程有点像一个人每次做研究都要把整个资料库重新翻一遍——真正值得沉淀的东西从没留下来留下的只是一份向量索引。「说白了传统 RAG 更多是把知识库当成机器索引而不是人能直接打开看的知识系统。」编译式 RAG 到底“编译”了什么这里容易有个误会编译式 RAG 不是把 Markdown 编译成某种二进制文件它真正改变的是知识加工发生的时间点。传统 RAG 是“解释执行”用户提问 → 检索 → 临时组织知识 → 生成答案每次运行都要现场组织一遍。编译式 RAG 则是把这部分工作提前到编译阶段原始资料 → Ingest编译 → 知识 Wiki → 用户提问 → 读取 Wiki → 生成答案。这和编程语言里“解释执行 vs 编译执行”的区别几乎是一回事。举个具体例子。假设有三份资料一份说 OpenAI 推出了某种 Agent 能力一份说企业开始通过 MCP 接入内部系统一份说 Agent 可以通过 Tool Use 调用 CRM。传统 RAG 不会主动把这三份资料变成一个长期存在的知识结构每次用户问“企业 Agent 为什么需要 MCP”模型都得重新把相关资料找出来再建立关系。编译式 RAG 会提前做一遍理解、归纳、建立关联生成一份 Wiki比如markdown企业 Agent企业 Agent 的核心能力包括 Reasoning、Tool Use、Memory、Workflow。其中 Tool Use 负责调用外部能力MCP 则提供了一套标准化的工具连接方式。相关知识[[tool-use]] [[mcp]] [[agent-architecture]]以后再问问题模型看到的不再是一堆互不相干的 chunk而是一张已经整理过的知识网络。这就是“编译”的核心。Karpathy 的 LLM Wiki把这个想法做到最简单这个思路最近被更多人讨论很大程度上是因为 Karpathy 提出的 LLM Wiki。它的设计相当朴素没有一上来就上向量数据库、GraphRAG、复杂 Agent Framework而是把知识拆成三层原始资料Raw Sources、组织规则Schema、编译产物Wiki。Raw Sources 就是原始资料本身原则很简单——原料不能被修改。Schema 是知识组织规则规定页面怎么命名、每个页面有哪些字段、页面之间怎么建链接、哪些内容该进索引、怎么记录 ingest 日志、怎么检查断链和孤儿页面。相当于告诉 Agent“你不是随便写 Markdown而是在按一套知识库规则生产知识。”Wiki 则是最终的编译产物每一篇都是人可以直接打开读的 Markdown。这一点其实很关键传统 RAG 的中间产物是 embedding、向量索引、chunk、metadata人很难直接检查而 LLM Wiki 的中间产物就是一篇篇 Markdown可以打开、修改、Git diff、审计甚至直接交给另一个 Agent 使用。所以我更愿意这么理解「传统 RAG 在构建知识索引编译式 RAG 在构建知识资产。」真正跑起来只需要一个很小的闭环想自己试试的话不需要先部署一套复杂的 RAG 平台。最小目录可能就这样llm-wiki-demo/ ├── CLAUDE.md ├── raw/ │ ├── article-a.md │ ├── article-b.md │ └── article-c.md └── wiki/ ├── index.md └── log.md最重要的是 CLAUDE.md它不是普通说明文档而是知识编译器的 Schema。里面可以定义页面命名规则放在 wiki/ 下用小写连字符 slug、每个页面必须有的 frontmatter 字段title、type、sources、updated、页面间用 [[slug]] 建立链接、index.md 维护整体索引、log.md 记录每次 ingest以及 ingest 只能读 raw/ 生成或更新 wiki/、不得修改 rawquery 只读 wiki/、不得重新读 rawlint 要检查断链、孤儿页面和过期内容。规则看起来简单但背后有个挺重要的思想转变这些规则不是写给人看的是写给 Agent 执行的。Agent 不再只是“帮你写 Markdown 的聊天机器人”而是一个知识编译器。第一次 ingest 的时候Agent 会先读 CLAUDE.md再读 raw/ 下的所有文章接下来不是简单复制而是抽取概念、合并重复信息、判断哪些信息属于同一主题、建立页面和链接、生成 index、记录日志最终把三篇原始文章编译成一整套带索引和链接的 Wiki 页面。这里有个特别重要的细节raw 目录始终不变。这是整个系统可靠性的底线——raw 是证据wiki 是编译产物。Wiki 写错了可以重新编译结构不合理可以改 Schema 再编译但原始材料永远保留。这和软件工程里 source code → build artifact 的关系几乎一模一样。为什么一定要有 index.md很多人第一次做知识库容易把 Markdown 文件一股脑堆起来最后攒了一千个 md 文件看着很像样其实跟文件夹没太大区别。编译式 Wiki 的关键之一就是必须存在一份导航结构比如按 Concepts、Systems、Debates 分类列出各个页面的链接。有了它查询就不再是“从所有文件里盲搜”而是先定位 index再顺着链接一路读下去知识才真正开始有“结构”。Markdown 甚至能直接“长成”知识图谱做到这一步会发现件有意思的事Wiki 页面里本来就有 [[agent]]、[[mcp]]、[[tool-use]] 这样的链接而“A 页面链接到 B 页面”本身就是一条关系。把这些链接解析出来就成了一张图。这是 GBrain 这类工具特别有意思的地方——它把 Markdown 中显式存在的链接解析成带类型的有向关系typed edges比如“某人 works_at 某公司”、“某人 founded 某公司”。这里有个跟 GraphRAG 很本质的区别值得单独说一下。很多人一看到知识图谱第一反应是“这不就是 GraphRAG 吗”其实不是两者最根本的差异在于图是怎么构建出来的。GraphRAG 一般是原始文本交给 LLM让模型自己抽取实体和关系再建图——比如文章里写“张三于 2022 年加入 ABC 公司后来负责 AI 项目”模型得自己判断出“张三 works_at ABC”“张三 leads AI Project”这一步本身就存在模型判断的不确定性。而 GBrain 的 self-wiring 更像是Markdown 里已经写着“张三目前在 [[companies/abc]] 工作”工具只是把这条显式链接解析成 typed edge——关系是人写出来的工具只负责把它接起来。这种方式为什么特别适合企业知识企业里有大量关系本来就该由人明确声明比如“张三 belongs_to 销售部”“某客户 uses 产品 A”“项目 A depends_on 系统 B”。这些关系一旦重要就不该完全交给 LLM 去猜。你可以直接在 Markdown 里写清楚客户用了哪个产品、由谁负责工具自动把关系建起来而且每条边都能追溯回具体的 Markdown 原文。这在企业环境里意义不小。业务部门经常会问“AI 为什么认为这两个东西有关系”如果答案是“模型推理出来的”说服力其实有限但如果答案是“因为这条关系写在某份文档的第 42 行”那就完全是另一回事了——「可解释性从“模型能力”变成了“数据结构能力”。」踩坑提示 没有显式链接就没有关系。如果 Markdown 里只写“张三在 ABC 公司工作”却没有 [[companies/abc]] 这样的链接self-wiring 并不会凭空推断出“张三 works_at ABC”。这正是它和 GraphRAG 的分界线显式结构化关系适合用 GBrain 这类 self-wiring 方案纯散文式的文本、需要从字里行间挖掘潜在关系还是得靠 GraphRAG。GBrain 不是“更聪明的 GraphRAG”它解决的是另一个问题——把人已经明确表达出来的知识关系可靠地变成机器可查询的图。在一次固定实验里六篇 Markdown 页面解析出了 16 条带类型的有向边且全程不需要调用大模型价值不在于边多而在于整个过程是确定的。编译式 RAG 的代价查询更贵知识会过期讲到这里容易有个错觉——既然提前把知识整理好了查询是不是又快又便宜不一定这恰恰是编译式 RAG 该诚实面对的地方。在一组实验里编译式 Wiki 查询消耗的 token 大约是传统向量 RAG 的 20 倍。原因不难理解Wiki 更强调完整上下文和跨页面关联传统 RAG 可能只塞几个片段进去而编译式 Wiki 要读 index、相关页面、跨页面关系上下文自然大得多。所以它不是“新的 RAG一切都更好”而是用更多的查询成本换取更好的知识组织、可读性和跨源合成能力也决定了它更适合知识规模不大、但关系复杂的场景。另一个容易被忽略的问题是知识会过期。假设 raw 里的文章写着“产品 A 售价 100 元”编译后 Wiki 也是这句话第二天原始资料改成 120 元但你没有重新 ingestWiki 依旧停留在 100 元。这不是 bug是编译式系统天然的特性——Wiki 本身就是个中间产物source 变了artifact 也该重新构建。所以编译式 RAG 真正要解决的不是“怎么编译一次”而是“什么时候重新编译”这已经是个实实在在的工程问题了。更现实的做法把它当成一套“知识 CI/CD”如果企业真要落地这套东西我不会简单把它理解成一个 RAG 方案而更愿意看成一条流水线知识源 → ingest → 知识 Wiki → lint → review → publish → AI 查询。甚至可以进一步接到 Git 上——知识变更后自动 ingest、自动 lint、生成 diff、人工 review 再发布。这时候知识库就不再是个静态文件夹而是一套真正的知识工程流水线Knowledge Engineering Pipeline这可能才是编译式 RAG 最值得企业关注的地方。传统 RAG、编译式 RAG、GraphRAG到底怎么选我自己的判断标准很简单不要先问“哪个技术更先进”先问“你的知识长什么样”。如果知识量特别大——上百万份文档、上千万 chunk、每天持续更新——没必要把所有东西都编译成 Wiki传统向量 RAG 仍然是更好的选择尤其适合高频查询、单跳事实、严格 SLA 的场景让向量检索做它擅长的事就好。如果知识量不大但关系复杂——几十篇研究报告、几十篇内部技术文档你经常问“A 和 B 是什么关系”“这个结论来自哪些材料”——这时候编译式 Wiki 就很有价值因为你要解决的已经不是“找一个 chunk”而是“理解一整张知识网络”。如果是大量非结构化文本、需要自动挖掘关系——上千篇新闻、上万篇研报、大量访谈记录里面没有任何显式链接你希望系统自己发现人物、公司、事件之间的关系——那 GraphRAG 更合适因为它解决的正是“从非结构化文本中发现关系”这个问题。更可能的答案是混合方案现实中的企业很少只有一种知识更常见的是“稳定核心知识 海量动态数据”并存。公司制度、产品知识、组织架构、业务规则、技术架构这类变化不快的核心知识很适合编译成 Wiki订单、客户记录、销售流水、日志、实时库存这类规模巨大、持续变化的动态数据更适合交给向量 RAG、数据库、搜索或 API 处理。最终架构大概率是一个路由层把问题分流到编译式 Wiki 和向量 RAG甚至再接一层 GraphRAG再汇总给 LLM 生成答案。编译式 RAG 不是来替代传统 RAG 的它更像是给企业知识体系加了一层稳定、可读、可维护的中间层。想自己上手建议从一个很小的知识库开始不用一上来就拿企业几十万份文档开刀找一个自己真正熟悉的主题就行比如 AI Agent准备五六篇相关文章放进 raw/先写好 CLAUDE.md 定义命名规则、页面结构、链接规则、index、log、ingest 和 query 的边界然后让 Agent 执行一次 ingest看看 wiki/ 里生成了什么。CLAUDE.md 参考你可以放在任何 Agent 里面运行让 Agent 帮你把 raw 的 md 文档转成 wiki 文档。不要急着拿去问 AI先自己打开 Wiki 看看页面组织得合不合理、有没有重复、有没有遗漏、链接对不对、有没有孤儿页面、引用能不能追溯回原文。这一步很重要因为知识库首先是给人看的其次才是给模型看的。接下来可以做个简单对比实验拿同一个问题比如“MCP 和传统 Function Calling 到底是什么关系”先用传统 RAG 跑一遍记录召回了哪些 chunk、用了多少上下文、答案是什么再用编译后的 Wiki 跑一遍看模型读了哪些页面、是否更容易建立跨页面关系、答案能不能引用来源。最后改一下原始资料里关于 Function Calling 的内容不重新编译直接问——你会看到 Wiki 仍然给出旧答案重新 ingest 之后再问一次新答案才会出现。这个实验能让你真正体会到——编译式 RAG 的本质不是“更好的检索”而是“把知识组织这件事提前做完”。CLAUDE.md 参考LLM Wiki Schema你可以放在任何 Agent 里面运行让 Agent 帮你把 raw 的 md 文档转成 wiki 文档。# LLM Wiki Schema规则层 · 人类撰写## 页面命名约定- 所有页平铺在 wiki/ 下文件名用小写连字符 slug如 compile-vs-interpret.md - 每页头部带 frontmattertitle /type/ sources / updated -type字段标注页面类型concept概念/ system系统/ debate争议## 链接语法- 页面之间用[[slug]]过去企业做知识库路径通常是收集资料 → 建立搜索 → 接一个 RAG → 让 AI 回答问题。未来可能会逐渐变成原始资料 → 知识整理 → 知识编译 → 可读 Wiki → 知识图谱 → 向量索引 → Agent。最重要的变化是知识库不再只是“存资料”的地方它开始承担“组织知识”的职责。Markdown 在这里反而是个挺有意思的载体——足够简单人能读、Agent 能读、Git 能管、diff 能比较、链接能表达关系不需要一个庞大的数据库就能先把整个知识体系跑起来。编译式 RAG 真正有意思的地方其实不止是 Wiki 本身。一个成熟的 AI 系统最终不该只知道“公司有什么知识”还得知道“过去做过什么决定”“为什么这么决定”“哪些方案被否掉了”“这个结论来自哪里”“现在这个问题和过去哪个相似”。顺着这个方向往下走文档 → 证据 → 论断 → 知识 → 关系 → 决策 → 推理状态RAG 这个概念本身可能都会慢慢变化。过去我们说 Retrieval Augmented Generation重点在“检索”未来更值得关注的可能是“知识增强”甚至是“推理状态增强”——不只是给模型找资料而是给它一个已经组织好的认知环境。如果只想记住这篇文章的几句话我建议是这三句1传统 RAG 解决的是“从资料里找到答案”编译式 RAG 更关注“先把资料组织成知识”。2Compiled RAG 和 GraphRAG 的核心区别不是贵不贵而是关系怎么产生的——一个偏向编译已有结构一个偏向从非结构化文本里发现关系。3编译式 RAG 不是传统 RAG 的替代品它更适合规模可控、需要跨源理解和人工审计的稳定知识。如果你的知识库只有几百篇核心文档而且文档之间关联很多真的值得自己动手做一个 LLM Wiki——不用等什么平台拿一个 Git 仓库建好 raw/、wiki/、CLAUDE.md跑一次 ingest看看你的知识有没有真正“长出结构”。如果再往前一步把 [[links]] 变成 typed edges你会发现所谓知识图谱有时候根本不需要先从一个复杂的图数据库开始——它完全可以从一个人愿意维护的 Markdown 链接起步。最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】