---

去年一年，企业知识库的技术路线讨论发生了不小的变化。上半年大家还在讨论"RAG万能"，下半年 Karpathy 抛出 LLM Wiki 之后，圈内开始认真反思：RAG 真的是最优解吗？

---

01｜RAG 的技术架构

---

1.1 一条流水线

RAG 说白了就是一条流水线：

入库：文档 → 切块 → 向量化 → 存进向量库查询：问题 → 向量化 → 检索Top-K片段 → 拼上下文 → LLM生成回答

核心就四个东西：Embedding 模型把文本变成向量，向量数据库负责存和查，LLM 负责基于检索结果生成回答，LangChain/LlamaIndex 这些框架把它们串起来。

这套东西不算复杂，但"不算复杂"和"能用好"之间差着十万八千里。

1.2 Chunking：最难的一步

很多人以为 RAG 最大的挑战是选模型、选向量库，其实不是。Chunking（分块）才是最折磨人的环节。

你面对的问题是这样的：文档得切成小块才能向量化，但怎么切？

切法	怎么干的	优点	坑在哪
固定长度	每N个token一刀切	最好实现	一句话能切成两半
递归字符	按换行、段落、句子依次切	能保段落完整	遇到格式乱的文档直接抓瞎
语义分块	算相邻句子的相似度，突变处下刀	块内语义紧实	阈值调到怀疑人生
结构化分块	按标题、章节切	效果最好	强依赖文档有结构
父子文档	小块去检索，大块送LLM	两头兼顾	复杂度直接翻倍

有个根本矛盾绕不过去：块太小，上下文不够；块太大，噪声太多。 chunk_size 常见值在 256-1024 tokens 之间，但你实际调的时候会发现，换个数据集就得重新来一遍。

有人用 chunk_overlap（相邻块重叠 10%-20%）来缓解上下文断裂，但这本质上是把矛盾往后推迟了，不是真正解决。

1.3 RAG 确实有的几个优势

说 RAG 的问题不代表它不好，几个工程优势还是很硬的：

更新快。 新文档往向量库里一灌，5-15 分钟就能被检索到。如果是微调路线，就算用 LoRA 这种轻量方案，一轮下来也要 24-72 小时。金融合规领域天天有新规，等不起。

模型和知识解耦。 换模型不影响知识库，加知识不用动模型。这个解耦在设计上很干净。

幻觉确实少了。 裸跑 LLM 幻觉率在 39%-91%（JMIR 2024, Stanford HAI 数据），多证据 RAG（向量+BM25+知识图谱一起上）能把幻觉砍掉 40% 以上，医疗场景甚至压到了 5.8%。

上手快。 框架生态已经很成熟了，2-4 周能跑通一个可用版本。

---

02｜LLM Wiki：另一种思路

---

2.1 Karpathy 想说什么

2025 年 Karpathy 发了个项目叫 LLMWiki，核心想法其实一句话就能说清楚：别让 LLM 当搜索引擎，让它当图书管理员。

搜索引擎什么都知道一点，但什么都不记得。图书管理员会维护卡片目录，知道哪本书和哪本书有关联，会告诉你"这两本书对同一个问题说法不一样"。

LLM Wiki 的架构分三层：

┌─────────────────────────────────────────┐│  Schema层 — 人来定规则                   ││  知识怎么组织、交叉引用怎么做，人写好规范   │├─────────────────────────────────────────┤│  Wiki层 — LLM 来维护                     ││  Markdown写的实体页、概念页、摘要、        ││  交叉引用、矛盾标注                        │├─────────────────────────────────────────┤│  原始素材层 — 人提供，LLM只读             ││  PDF、文章、笔记、数据                    │└─────────────────────────────────────────┘

人和 LLM 的分工很明确：人负责决定"什么东西值得进来"，LLM 负责所有维护工作。

2.2 三个操作

Ingest（灌文档）。 这不是简单的"存起来"。LLM 会读完整篇文档，创建摘要页，更新所有相关的实体页和概念页——一次 Ingest 平均要动 10-15 个 Wiki 页面。更重要的是，如果新内容和已有知识矛盾，LLM 会直接标出来。

Query（查东西）。 搜的是已经整理好的 Wiki，不是原始文档的碎片。知识已经被去重、综合、标注过矛盾了。

Lint（体检）。 定期跑一次，看看有没有矛盾、过时内容、没人引用的孤立页面。

2.3 和 RAG 本质不一样的地方

用一张表说清楚：

	RAG	LLM Wiki
知识状态	无状态，每次现查现拼	有状态，知识越用越厚
综合时机	查的时候才综合	灌文档的时候就综合好了
矛盾处理	今天问一个答案，明天问可能反了	灌文档时一次性发现并标注
交叉引用	没有	LLM自动维护
文档越多	信噪比可能下降	知识网络越密，质量反而上去

有个场景很能说明问题：你和 AI 聊了半小时，深入分析了一个技术问题，得到了很有价值的结论。关掉对话框，一切归零。明天另一个人问同样的问题，系统从零开始再做一遍——100 个人问，就做 100 遍。

LLM Wiki 不是这样。那次半小时的深入分析会变成一个 Wiki 页面，后面的人直接就能用。

---

03｜硬碰硬比一下

---

性能

	RAG	LLM Wiki
首次查询	2-5秒	5-15秒（得先综合）
后续查询	2-5秒（每次重新来）	2-5秒（已经综合好了）
准确率	~78%（通用领域）	看 Ingest 质量，天花板更高
幻觉率	优化后 5.8%-15%	Wiki 本身不存在幻觉

钱

	RAG	LLM Wiki
基础设施	向量库+存储，1,200/月	几乎为零，就是个文件系统
灌文档	便宜，Embedding 一次就行	贵，LLM 要深度读+综合+改十几个页面
查询	每次都要检索+生成	Wiki 已经综合好了，LLM 直接回答
维护	得盯着文档质量	LLM 自动 Lint

说得直白一点：RAG 的钱花在每次查询上，LLM Wiki 的钱花在灌文档的时候。 如果查询量大，LLM Wiki 反而更省钱。

工程

	RAG	LLM Wiki
搭建周期	2-4周	1-2周，LLMWiki 开箱能用
调优重心	Chunking 能调到你崩溃	不需要 Chunking
瓶颈	文档质量	Schema 设计

---

04｜RAG 真正的痛点

---

上面说了一堆数据对比，但数据比较"体面"。实际落地中，RAG 让人头疼的问题远不止这些。

4.1 切块这件事，怎么搞都有遗憾

前面说了 Chunking 的各种策略，但归根结底，文本的物理结构和语义结构经常对不上。

固定长度分块最容易出事。一个真实的案例：某医疗 RAG 系统检索到了"ST段抬高"这个片段，但 chunk 的边界刚好把紧接着的"非心梗"说明切到了下一个块里。模型只看到了前半句，直接给出了心梗的诊断建议。

这种事情在长文档里太常见了。用语义分块能好一些，但 breakpoint_threshold_amount 这个参数本身就够喝一壶的——阈值低，块碎得跟渣一样；阈值高，一个块里能塞进三四个话题。

4.2 没有记忆，每次从零开始

这是 RAG 架构设计上的根本问题，不是调参能解决的。

RAG 是无状态的。你昨天问了一个问题，系统检索了 5 份文档，综合出了一个很棒的回答。今天你问一个相关问题，系统完全不知道昨天做过什么，重新检索、重新拼、重新生成。如果涉及的两份文档有矛盾，两天的回答可能完全相反。

在企业里，这意味着大量重复劳动被浪费了。同一个技术方案评审，五个不同的工程师分别去问，系统做了五遍一模一样的检索和推理。没有人从别人的提问中获益。

4.3 文档越多，越不准

向量检索的质量和文档总量负相关——文档越多，语义空间越拥挤，相似度匹配的精度就越打折。

尤其是企业文档，普遍存在重复内容、格式混乱、多个版本的同一个文档共存的情况。某企业上 RAG 后效果不好，排了两个月的问题，发现 60% 的锅在源文档质量上。算法和模型都是次要的。

4.4 领域术语是道硬伤

纯语义检索分不清跨领域的术语歧义。医学里"positive"是阳性，日常里是"积极的"；法律里"解除"是终止合同，日常里是"缓解"。混合检索（关键词+语义）能缓解一点，但做不到根治。

在医疗、法律、航空维修这类术语密集的领域，RAG 的语义深度经常不够用，关键时刻容易翻车。

4.5 做不了全局推理

传统 RAG 的检索本质上是 Top-K 相似度匹配，它只能找到"和问题最像的几个片段"，但做不了跨文档的全局分析。

微软 GraphRAG 团队做过一个测试：让 Baseline RAG 从几千篇新闻里总结"前五大主题"，结果返回的全是不相关的内容。因为"主题"这个概念没法靠向量相似度检索——它需要的是全局理解。GraphRAG 用知识图谱做，准确找到了冲突与军事活动、政治实体、基础设施威胁等关键主题。

---

05｜LLM Wiki 为什么开始被认真对待

---

5.1 核心假设不一样

RAG 隐含了一个假设：检索到了对的内容，就能给出对的回答。但实际不是这样——片段找对了但缺上下文，回答照样跑偏；片段对了但 LLM 在"组装"的时候自己加了料，幻觉还是会出。

LLM Wiki 的做法是：别等查询的时候再去拼，灌文档的时候就让 LLM 读懂、综合好、把关系理清楚。 查的时候面对的是已经消化过的知识，而不是一堆碎片。

5.2 知识图谱的门槛在降低

微软 2024 年开源 GraphRAG 之后，知识图谱不再只是学术圈的东西了。GraphRAG 在全面性、多角度等维度上持续碾压 Baseline RAG。

但知识图谱的工程成本确实不低——要上 Neo4j、要建模、要维护。LLM Wiki 用了一种更轻的方式：Markdown 文件之间的交叉引用。没有图数据库，没有 RDF，就是文件里互相链接。本质上也是一种知识图谱，只是实现路径完全不同。

5.3 Agent 时代需要"工作记忆"

2025 年 Agentic RAG 开始热起来（arXiv:2501.09136），Agent 不再是"检索一段文字然后回答问题"，而是要做多步推理、跨文档关联、动态调整策略。

这要求知识库不只是存文档，还得能被读写、能追溯变更、能作为 Agent 的"工作记忆"。LLM Wiki 的 Wiki 层天然就是这个角色。

5.4 顺手把文档治理做了

RAG 有一个很少被提起的前提假设：你的文档质量是过关的。但实际上，企业文档普遍是一团糟——格式混乱、内容重复、版本打架、关键信息散落在十个不同的文件里。

LLM Wiki 在 Ingest 的时候，LLM 要通读全文并综合，这个过程本身就会暴露这些问题。矛盾会被标注，孤立内容会被发现，重复信息会被合并。等于是顺手把文档治理也给做了。

---

06｜什么场景用什么

---

直接看图：

知识天天在变的——用 RAG。

金融合规、政策解读、市场行情这类场景，新文档源源不断。RAG 灌一篇就能搜一篇，其他方案都跟不上这个节奏。建议配混合检索（向量+BM25），召回率会好不少。

术语特别多的垂直领域——RAG 加知识图谱，或者直接 LLM Wiki。

医疗、法律、航空维修。纯 RAG 对术语的理解深度不够。LLM Wiki 的实体页天然适合存术语定义和关系。有数据表明，医疗项目用微调+RAG 混合方案，误诊率能从 19% 压到 3.2%。

知识稳定但查询量大的——LLM Wiki 最合适。

员工手册、操作规范、产品规格书。文档不频繁变动，但天天有人查。LLM Wiki 的 Ingest 成本只花一次，后面查的都是已经整理好的知识。不需要 Chunking 调优，不需要向量数据库。

文档海量且查询复杂的——两个一起上。

大型制造企业的维修知识库，几千份手册加上故障记录和维修日志。RAG 负责广覆盖，LLM Wiki 负责把关键的设备关系、故障模式沉淀下来。各干各擅长的事。

要审计溯源的——LLM Wiki。

法律合规、金融风控。LLM Wiki 每次知识更新都有变更记录，每个结论都能追溯到原始文档。RAG 的"溯源"只能到检索片段级别，粒度差了不少。

---

07｜接下来会怎么走

---

说几个判断。

RAG 和 LLM Wiki 不是二选一。 以后大概率是 RAG 管广度检索、LLM Wiki 管深度沉淀，两者配合。Agentic RAG 已经在探索让 Agent 自己决定什么时候检索、什么时候查 Wiki。

知识图谱会从"高级特性"变成"标配"。 不管是 GraphRAG 的重实现，还是 LLM Wiki 的轻量实现，知识之间的关系网络会越来越重要。

Ingest 成本会越来越低。 LLM Wiki 现在的主要问题是灌文档时 LLM 调用成本高。但开源模型能力在快速提升，推理成本也在持续下降，这个瓶颈不会存在太久。

知识库会从"被动查询"变成"主动维护"。 Agent 不只是查知识库，还会往里写东西、改东西、治理它。未来的知识库是一个活的系统，不是一本死字典。

---

没有万能架构。选型的关键不是哪个技术更先进，而是你的场景到底需要什么——是快速检索的广度，还是知识沉淀的深度，还是两者都要。

想清楚这个，答案自然就出来了。

普通人如何抓住AI大模型的风口？

领取方式在文末

为什么要学习大模型？

目前AI大模型的技术岗位与能力培养随着人工智能技术的迅速发展和应用 ， 大模型作为其中的重要组成部分 ， 正逐渐成为推动人工智能发展的重要引擎 。大模型以其强大的数据处理和模式识别能力， 广泛应用于自然语言处理 、计算机视觉 、 智能推荐等领域 ，为各行各业带来了革命性的改变和机遇 。

目前，开源人工智能大模型已应用于医疗、政务、法律、汽车、娱乐、金融、互联网、教育、制造业、企业服务等多个场景，其中，应用于金融、企业服务、制造业和法律领域的大模型在本次调研中占比超过 30%。

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

最后

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】