新手程序员必看：如何将企业知识库从“资料堆”升级为“知识资产”？

本文探讨了企业知识库建设中，如何将散落的资料有效组织成知识的关键问题。传统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 → 标准化工具协议 → 工具发现 → 权限控制 → 企业系统接入。

也就是说，真正难的不是“找到资料”，而是“把散落的资料组织成知识”。这正是最近一种叫编译式 RAG（Compiled 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，比如：

# 企业 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/、不得修改 raw；query 只读 wiki/、不得重新读 raw；lint 要检查断链、孤儿页面和过期内容。

规则看起来简单，但背后有个挺重要的思想转变：这些规则不是写给人看的，是写给 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 元，但你没有重新 ingest，Wiki 依旧停留在 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

– 每页头部带 frontmatter：title / type / sources / updated

– type 字段标注页面类型：concept（概念）/ system（系统）/ debate（争议）

## 链接语法

– 页面之间用 `[[slug]]` 双方括号互链，如 `[[compiled-rag]]`

## 两个特殊文件

– wiki/index.md：内容目录，按 type 分区列出所有页 + 一行摘要 + 链接（查询入口）

– wiki/log.md：append-only 日志，每条以 "## [YYYY-MM-DD] ingest | 标题" 开头

## 三个操作

– Ingest：读 raw/ 新原料，按本 schema 在 wiki/ 编译互链页，更新 index/log。raw/ 只读不改。

– Query：只读 wiki/，从 index.md 导航定位相关页，给带引用的回答。不重读 raw/。

– Lint：检查断链、孤儿页、过期内容，报告问题。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？