企业官网建设流程全解析

大模型在处理内部问题时常出现幻觉和知识盲区，RAG技术通过开卷考试的方式，让大模型在答题前检索相关资料，从而提供准确答案。本文详细介绍了RAG的原理、链路以及实操步骤，帮助小白程序员理解和应用RAG技术，避免大模型应用中的常见问题。

你有没有遇到过这种情况：问大模型一个公司内部的问题，它一本正经地胡说八道？

比如问它"我们公司的退款流程是什么"，它给你编一套看起来很合理的步骤——但跟你公司的实际制度完全对不上。你追问它，它还能继续编，编得越来越像真的。

这不是模型"笨"，是它压根没见过你的数据。大模型的训练数据是公开互联网，你的公司制度、产品文档、私有知识，它一概不知。 但它不会说"我不知道"，而是编一个概率上最合理的答案——这就是幻觉。

RAG 就是解决这个问题的。今天这篇文章，从原理到生产一次讲透，全程不依赖任何框架。

01 RAG 就是开卷考试

先回答一个根本问题：为什么需要 RAG？

因为大模型有三个治不好的毛病：

这三个毛病有一个共同的根因：LLM 是闭卷考试选手。它靠肚子里的记忆答题，记忆里没有的，它不会说"我不知道"，而是编一个概率上看起来合理的答案。

RAG 的思路简单粗暴：让它开卷。

答题之前，先去资料库里把相关内容翻出来，塞进提示词，让它照着资料回答。

闭卷（裸 LLM）： 提问 → 靠记忆硬答 → 没有的部分瞎编
开卷（RAG）： 提问 → 先检索相关资料 → 基于资料生成 → 答不上就说不知道

说白了，RAG 根本没动"生成"那一环——生成用的还是同一个 LLM。它干的唯一一件事，是在模型答题前替它把对的资料翻出来。检索错了，生成再强也白搭——就像开卷考试翻错了书，答得再流畅也是零分。记住这句话，它是后面所有优化的出发点：混合检索、Rerank、Agentic RAG，全都在解决同一个问题——怎么把"对的那一段"捞出来。

一句话：RAG = 开卷考试。模型没变，变的是它答题前能不能翻到对的一页。

02 全链路：离线四步 + 在线四步

RAG 的完整链路分两个阶段，这个划分必须刻在脑子里，后面所有内容都挂在这两条线上：

【离线阶段：建索引】—— 一次性 / 定期做，回答"知识怎么进系统"
文档加载 → Chunk 分块 → Embedding 向量化 → 存入向量库

【在线阶段：查询】—— 每次提问都做，回答"问题怎么找到答案"
用户提问 → 向量检索召回 → Rerank 重排 → 拼进 Prompt → LLM 生成

光看链路有点抽象，我们用一个电商客服助手的场景，把两条链路各走一遍。

2. 1 离线阶段：把《退货退款政策》变成可检索的库

假设你是一家电商公司的技术负责人，客服团队每天要回答大量退货退款问题。你决定做一个 RAG 系统，把公司的《退货退款政策 v2.1》（5000 字）喂进去。

原始文档：《退货退款政策 v2.1》（5000 字 Markdown）
↓ 加载：解析成纯文本，标题层级保留
↓ 分块：按章节递归切，“七天无理由退货”“退款时效”"运费承担"各自成块
每块约 500 字，相邻块重叠 10%，防关键条款卡在切分线上
↓ 向量化：每个块过 embedding 模型，变成一串数字（如 1536 维向量）
↓ 入库：向量 + 原文 + 元数据（章节路径：售后/退货/运费）存进向量库

产出：几十个"政策片段"，等用户来问

① 文档加载

把各种格式的文档读进来转成纯文本。听着简单，实际是全链路最脏的活：

▪ PDF 最难搞，扫描件（图片型 PDF）得先 OCR；带表格的 PDF 转出来经常是乱码

▪ 表格直接转纯文本会丢结构，要转成 Markdown 表格保留行列

▪ 代码块要保留格式和语言标记

电商场景比较幸运：政策文档是 Markdown，天然干净。但如果你的源是 PDF，听我一句劝，这一步至少预留三分之一的工程时间。

② Chunk 分块

为什么必须切块？三个原因：文档太长塞不进上下文窗口；embedding 模型有输入上限（通常几百 token）；切块后才能精准命中"相关的那一段"，而不是甩一整篇过去。

我们的政策文档按章节递归切分：

顺带把三种切法都摆出来，按场景选：

Chunk 大小怎么定？这是高频追问。

答案是：没有万能值，得实测调。太大（2000+ 字）一块混多个主题，向量被稀释；太小（100 字以内）语义不完整，"该公司收入增长 3%"脱离上下文根本不知道指谁。

经验起点是 256-1024 token，重叠 10%-20%，再根据实际检索质量微调。重叠是为了防边界截断——关键信息恰好落在切分线上时，不重叠就会丢。

③ Embedding 向量化

Embedding 干的事：把文本变成一串数字（向量），让语义相近的文本，数字也相近。

听着抽象，打个比方。给水果定坐标：

苹果 → (甜度 8, 酸度 3, 硬度 7)
橙子 → (甜度 7, 酸度 6, 硬度 3)
土豆 → (甜度 2, 酸度 1, 硬度 8)

苹果和橙子坐标接近（都是甜的、不太酸），土豆和它们差得远。Embedding 做的就是这件事——给每段文字定一组"语义坐标"，坐标越近，意思越像。只不过不是手工定 3 个维度，而是让模型自动学出几百上千个维度。

向量还能捕捉语义方向。经典例子：国王 - 男性 + 女性 ≈ 女王。这不是在做数学题，而是在向量空间里"把性别方向换了一下——“国王"和"女王"只差一个"性别"维度，去掉"男性”、叠上"女性"，自然就到了"女王"附近。

衡量"近不近"用余弦相似度——看两个向量方向一不一致，不管长短。两篇内容相同但长度不同的文章，向量长度不同、方向一致，相似度照样接近 1。

到这里都还顺利，真正埋雷的地方在容错逻辑上。很多项目会做"API 挂了自动降级本地模型"的设计，看起来贴心，但藏着 RAG 全链路最阴的一个坑：

⚠️ 大坑：建库和查询必须用同一个 embedding 模型。

如果建库那天用的 1536 维模型，查询那天降级成 384 维本地模型，会发生什么？——两个模型的向量空间完全不一致，检索结果全是乱的。

而且这是隐性 bug：代码不报错、接口不超时，只是检索出来的东西莫名其妙。你第一反应绝对不会是"模型换了"，而是"chunk 切得不好"，然后调三天切分参数，越调越魔幻。

修复方案：建库时把 embedding 模型名写进元数据，查询时校验，不一致直接报错拒绝服务——宁可明确失败，不要静默胡说。

④ 存入向量库

向量库选型，看规模和基础设施：

选型的核心是"够用"，不是"最强"——数据量没到十万级，Milvus 的分布式能力一分都用不上。

入库时有三个细节别忘：

▪ 向量旁必须存原文——检索出来拼回 prompt 的是原文，不是向量

▪ 存元数据（来源章节、分类、块序号）——后面做过滤全靠它

▪ 批量入库——避免一次性内存暴涨

2. **2 在线阶段：用户问"买了三天想退货，运费谁出？"

光看链路有点抽象，我把在线阶段四步拆开，用同一个例子走一遍，你就知道每一步到底在干嘛。

第一步：向量召回（粗筛）

用户问题过 embedding 模型变成向量，去向量库里算相似度，拉回 top 20 条。实际跑出来大概长这样：

排名 来源章节 内容摘要 相似度
1 七天无理由退货 “签收后7天内可申请无理由退货，需商品完好…” 0.89
2 退款流程 “提交申请后1-3个工作日审核，退款原路返回…” 0.85
3 运费承担规则 “退货运费由买家承担；因质量问题退货的，运费…” 0.83
4 特殊商品退货 “生鲜、定制商品不支持无理由退货…” 0.78
5 退货时效 “签收次日起算7个自然日…” 0.76

你可能发现了——用户明明问的是"运费"，但"运费承担规则"只排第 3，排在前面的反而是"七天无理由退货"和"退款流程"。

原因也不复杂：向量检索比的是整体语义相似度，"七天无理由退货"和"退款流程"跟"退货"这个大主题更近，自然排前面。

但用户要的不是"怎么退货"，是"运费谁出"——粗筛捞得全，但排不准，这很正常。

第二步：Rerank 精排

粗筛不准，那就加一道精排。把 top 5 条和用户问题一起丢进跨编码器，逐词对照打分：

排名 来源章节 跨编码器得分 变化
1 运费承担规则 8.72 ↑ 从第3升到第1
2 七天无理由退货 6.35 ↓ 从第1降到第2
3 特殊商品退货 4.18 ↑ 从第4升到第3
4 退款流程 2.05 ↓ 从第2降到第4
5 退货时效 1.32 ↓

"运费承担规则"直接从第 3 翻到了第 1。

原理也不复杂：粗筛比的是"整体像不像"，精排比的是"局部对不对"。

跨编码器是把问题和文档拼在一起逐词比对的——用户的"运费"和文档的"运费承担规则"精确匹配，得分自然高；而"退款流程"虽然语义相关，但里面压根没有"运费"这个词，逐词比对后得分就掉下去了。

粗筛像猎头扫简历，5 秒一份快速过；精排像面试官坐下来深聊，一个一个对。 先粗筛再精排，捞得全也排得准。

取 top 3 进入下一步。

第三步：拼接 Prompt

把 top 3 的原文塞进提示词。直接把检索结果丢给模型还不够，还得加工一下：

你是电商客服助手。请基于以下参考资料回答用户问题。
如果资料里没有相关信息，请如实说"我暂时无法回答"，不要编造。

【参考资料 1】运费承担规则
退货运费由买家承担；因质量问题退货的，运费由商家承担。
运费在退款时一并扣除，无需单独支付。

【参考资料 2】七天无理由退货
签收后7天内可申请无理由退货，需商品完好、包装齐全。
不适用于：生鲜、定制商品、已拆封的数码产品。

【参考资料 3】特殊商品退货
生鲜、定制商品不支持无理由退货。
数码产品已拆封的，需提供检测报告方可退货。

用户问题：买了三天想退货，运费谁出？

两个细节：参考资料带了来源标记（“运费承担规则”），方便溯源——用户追问的时候能说清楚"这个结论来自哪条政策"；提示词里写了"资料里没有就说不知道"——这是在给模型上缰绳，不让它瞎编。

第四步：LLM 生成

模型看到参考资料后，基于资料生成回答：

您购买三天，在7天无理由退货期限内，可以申请退货。退货运费由您自行承担，退款时会一并扣除。如果是因为商品质量问题退货，运费则由商家承担。

答案里的每一个数字、每一条规则，都来自参考资料——"7天内"来自参考资料 2，"运费买家承担"来自参考资料 1，"质量问题商家承担"也来自参考资料 1。要是粗筛里压根没有"运费承担规则"那段，模型再聪明也只能编。

四步走完，整个流程的核心就一句话：粗筛负责捞得全，精排负责排得对，Prompt 负责给模型上缰绳。 三件事做好了，RAG 的在线阶段就不会掉链子。

一句话：离线四步把知识变成可检索的向量，在线四步把问题变成最相关的答案。两阶段必须用同一个 embedding 模型，否则向量空间对不上，检索结果全乱。

03 怎么检索得准

链路搭完，第一次检索大概率会让你失望——不是完全不准，是"大部分还行，关键时候掉链子"。

3. **1 检索方式全景

先搞清楚有哪些牌可以打。三种检索方式，每种都有自己的绝活和盲区：

光看表格没体感，每种举个正反例子：

向量检索——比的是"意思像不像"，不是字面。

搜"小狗"，能找到只写了"幼犬"的文档，因为"小狗"和"幼犬"语义接近。但搜"HTTP-403 报错"，返回的可能是一堆泛泛的"服务器错误讨论"——语义确实近，但你要的就是 403 这个精确编码，它抓不到。

BM25 关键词检索——比的是"字面命中"。

搜"HTTP-403"，精确命中写了这个错误码的文档。但搜"kitty"，找不到通篇只写了"cat"的文档——它只认字面，不懂同义。

混合检索——两路都跑，盲区互补。

向量检索管语义，BM25 管精确关键词，两路各查各的，用 RRF 融合。搜"RTX 4090 价格"，向量检索能找到"显卡多少钱"，BM25 能精确命中"RTX 4090"这个型号——单靠任何一路都会漏。

三种检索负责的是"捞得全"，但捞回来的顺序不一定对。后面还需要一道精排，把真正相关的排到前面——这就是 Rerank，3.3 再展开讲。

整个流程是这样的：

检索（三选一） → 负责"捞得全"（召回阶段）
↓
Rerank 精排 → 负责"排得对"（精排阶段）
↓
拼 Prompt → 负责"约束生成"

3. **2 混合检索：两种盲区互补

3. 运费承担规则 ← 对了！排第 3

4. 特殊商品退货

5. 退货时效

方案 B（向量检索 + Rerank）：

1. 运费承担规则 ← 对了！排第 1

2. 七天无理由退货

3. 特殊商品退货

4. 退款流程

5. 退货时效

三个指标分别算：

recall@3：前 3 条里有没有正确答案？方案 A 的"运费承担规则"排第 3，命中，recall@3 = 1。方案 B 排第 1，也是 1。看起来一样？别急。

MRR：第一个正确答案排第几？方案 A 排第 3，MRR = 1/3 ≈ 0.33。方案 B 排第 1，MRR = 1。差距就出来了——MRR 关心的是"找到得够不够快"，排第 1 和排第 3 体验完全不同。

nDCG：整个排序列表质量如何？方案 B 把正确答案排在最前面，不相关的沉底，nDCG 更高。方案 A 虽然也找到了，但正确答案被两个不相关的压着，列表整体质量差一截。

三个指标各管一件事：recall 管"找没找到"，MRR 管"找得快不快"，nDCG 管"整个列表排得好不好"。

实际评估时，从真实用户问题里挑 30-50 个，人工标好标准答案，改一版参数跑一遍三个指标——数字涨了才算优化。凭感觉说"好像准了"不算，真的不算。

一句话：混合检索补精确匹配、Rerank 把对的排前面、RRF 用只看排名的方式融合两路结果；优化效果盯 recall@k，数字涨了才算数。

04 怎么检索得聪明

前三章解决的是"检索得准"，这一章换一个维度：怎么让检索变聪明——该查什么、什么时候查、查几次。

4. 1 三板斧：改写、过滤、补上下文

查询改写（Query Rewriting）

用户的原话往往不适合直接拿去检索。比如用户问"那个东西怎么退"——检索引擎知道"那个东西"是啥就有鬼了。

解法是先让 LLM 把问题改写成适合检索的形式，再拿去查：

用户原话：“那个东西怎么退”
↓ LLM 改写
改写后：“退货退款流程是什么”
↓ 再去检索
命中：退货退款政策、退款时效…

成本是一次额外的 LLM 调用，收益在模糊查询场景下非常明显。用户不知道你的知识库用的是什么术语，LLM 知道——让它当翻译。

元数据过滤（Metadata Filtering）

检索时先按标签缩小范围，再做向量检索。

回到电商客服场景，知识库里既有"退货退款政策"也有"会员积分规则"还有"配送时效说明"。用户问退货问题时，先用元数据过滤把范围缩小到"售后"分类，再做向量检索——砍掉一半不相干的，检索精度立刻上来。

用户：“买了三天想退货，运费谁出？”
↓ 元数据过滤：category = “售后”
↓ 向量检索：只在"售后"分类里搜
↓ 结果：退货相关的内容，不会混进"会员积分"“配送时效”

粗判会不会判错？会，但判错的代价很低——大不了就是没过滤，退回全库检索，不会引入错误结果。元数据过滤追求的是砍掉明显不相干的，不是搞精准分类。

Contextual Retrieval（上下文感知检索）

切块有个天然缺陷：会切断指代关系。

比如一段政策文档写着"该公司收入增长 3%"——"该公司"指谁？答案在上一段，但切块后上一段不在同一个 chunk 里了。带着这种残缺的文本去嵌入，向量自然也残缺。

Anthropic 的解法是：嵌入之前，先让 LLM 给每个 chunk 补一段上下文说明。

原始 chunk：“该公司收入增长 3%，Q3 营收突破 50 亿。”
↓ LLM 补上下文
带上下文的 chunk：“本文讨论的是小米集团2024年财报。
该公司收入增长 3%，Q3 营收突破 50 亿。”
↓ 再去嵌入
向量里包含了"小米集团"的语义信息

代价是建库时多一遍 LLM 调用，收益是长文档场景下的召回质量。Anthropic 的实测数据：结合 Contextual Embedding + BM25 + Rerank，检索失败率降低 67%。

4. 2 Agentic RAG：检索是工具，不是必经之路

传统 RAG 是无脑流水线：每个问题都检索，不管需不需要。

但检索是有成本的——延迟、token、还有噪声。检索回来无关内容，不仅浪费，还会干扰生成：模型看到一堆不相关的资料，答案质量反而下降。

Agentic RAG 的思路是把检索当成 Agent 的一个工具，由模型自己决策：要不要查、查什么、查几次。

什么时候该查、什么时候不该查？用电商客服的例子走一遍。

不查的场景：用户问"什么是七天无理由退货"——这就是常识，模型肚子里有，直接答就行，不需要检索。硬要去查反而多此一举。

查一次就够的场景：用户问"买了三天想退货，运费谁出？"——这是单跳问题，检索一次"运费承担规则"就能回答。

需要迭代查的场景：用户问"双十一买的东西想退货，优惠券还能用吗"——这个问题涉及两块不同的知识，一次查不全。

第一轮检索：
想：这个问题既涉及"退货"又涉及"优惠券"，先查退货规则
查：检索"双十一退货政策"
看：找到了"促销活动期间购买的商品，退货后优惠券不退还"
但用户可能还会问"那退款金额怎么算"——促销价和原价不一样

第二轮检索：
想：需要补充"促销订单退款金额"的规则
查：检索"促销订单退款计算方式"
看：找到了"促销订单退款按实付金额计算，优惠券抵扣部分不退"

综合两轮结果，给出完整回答：
“双十一购买的商品可以退货，退款按您的实付金额计算。
优惠券抵扣的部分不退还，退货后优惠券也不会恢复。”

传统 RAG 只能查一次，要么只捞到退货规则漏了退款金额，要么两块都捞到但混在一起排序混乱。

Agentic RAG 的价值在于：第一轮查完发现信息不够，能根据结果构造更精确的第二轮查询——就像研究员反复查阅、交叉验证，材料够了再动笔。

一句话：查询改写救模糊问题，元数据过滤先砍一半噪声，Contextual Retrieval 补回切断的上下文；检索频率跟内容复用性走——常识够答就不查，Agentic RAG 让模型自己决定。

05 动手实操

前面四章讲的都是原理和链路，这一章用一个真实项目把 RAG 走一遍。

项目叫 article-writer，一个 AI 写公众号文章的 Agent。它的 RAG 和第二章的电商客服有一个本质区别：客服检索的是"答案"，写作检索的是"风格"。

客服用户问"运费谁出"，系统去知识库里找"运费承担规则"那段原文当答案。写作场景不一样——用户说"写一篇关于 RAG 的文章"，系统不需要找 RAG 的知识，LLM 自己肚子里有。它需要找的是"写这类技术文章时是什么风格"——怎么开头、怎么用比喻、段落多长、语气什么样。

5. 1 离线：197 篇文章怎么变成风格参考库

知识源是197 篇 Markdown 文章，按分类放在 11 个目录里。技术类占大头——Spring 全家桶 39 篇、Java 与 JVM 30 篇；个人类也不少——个人成长 29 篇、管理与随笔 28 篇。

这些文章切块入库后，每个 chunk 带两个元数据标签：style（technical / personal）和category（来自哪个目录）。写技术文章时只检索 technical 的 chunk，写随笔时只检索 personal 的 chunk——用元数据过滤风格，不过滤知识。

切块：一篇真实文章的拆解

拿《手动撸一个 Redis 分布式锁》走一遍，7745 字，切块参数是每块 1000 字符、重叠 150 字符、从切点往前扫空行找段落边界。

切完产出 10 个 chunk，挑几个有代表性的：

Chunk 1（988 字）：文章开头
“大家好呀，对于使用 Java 的小伙伴，其实我们完全不用
去手动撸一个分布式锁，直接使用 Redisson 就行。但是因为这些封
装好的组建，让我们越来越懒……”

Chunk 2（796 字）：锁超时的核心问题
“通过和当前时间比较，判断锁是否超时。如果锁未超时，直接返回，
如果锁超时，重新设置锁的超时时间，成功获取锁。还有其它问题么？
当然！因为在并发场景下，会存在 A、B 两个线程同时……”

Chunk 3（907 字）：并发场景分析
“延长或缩短了锁的超时时间，不会有问题么？其实在现实并发场景中，
能走到这一步，基本是’同时’进来的，两者的时间差非常小……”

Chunk 8-10 是文章尾部的总结和"好文推荐"链接。197 篇文章的尾部长得一模一样——都是模板。这些是噪声，入库前应该清洗掉，该库建得糙，没做这一步。

入库：真实参数

197 篇文章切完，产出约 2800 个 chunk，向量库文件 28MB。就是一个小文件的事，ChromaDB 一个嵌入式文件就装下了。

5. 2 在线：写一篇 RAG 文章时，系统怎么找风格参考

以这篇 RAG 文章为例，走一遍完整流程。

第一步：风格判断

用户输入"写一篇关于 RAG 原理和实战的技术文章"。“RAG”“原理”“实战"都是技术关键词，过滤style=technical，把"聊聊焦虑”"谈谈35岁危机"这类个人风格的 chunk 先排除掉。

第二步：向量召回（粗筛）

拿"RAG 原理 实战 技术文章"当查询去检索，拉回 top 20。这些 chunk 不是 RAG 的知识，是"写技术文章时的风格样本"。

实际跑出来前 5 条：

排名 来源文章 相似度 风格特征
1 手动撸一个 Redis 分布式锁 0.842 口语化开头：“大家好呀”
2 MySQL 单表可以放多少数据 0.817 数据驱动：先抛数字再展开
3 Redis 高可用原理 0.814 技术类比：用生活例子解释原理
4 只会单机执行定时任务？多机执行 yyds！ 0.794 反问句式：“还有什么策略呢？”
5 如何保障 MySQL 和 Redis 数据一致性 0.788 表格对比：用表格讲方案差异

粗筛的问题和第三章讲的一样：噪声混进来了——有些 chunk 是测试输出日志、好文推荐链接，和"写作风格"没关系，纯粹因为关键词重叠被捞上来。

第三步：Rerank 精排

粗筛结果丢进跨编码器精排，排序变了：

排名 来源文章 跨编码器得分 变化
1 手动撸一个 Redis 分布式锁 0.998 保持第 1
2 MySQL 单表可以放多少数据 0.996 保持第 2
3 Redis 高可用原理 0.994 ↑ 从第 3 升到第 3（噪声被淘汰后补位）
4 如何保障 MySQL 和 Redis 数据一致性 0.992 ↑ 从第 5 升到第 4
5 只会单机执行定时任务？多机执行 yyds！ 0.990 ↓ 从第 4 降到第 5

粗筛里混进来的测试输出日志、好文推荐链接，精排后都掉出了 top 5——跨编码器逐词比对后发现，这些 chunk 和"RAG 技术文章"的匹配度很低。和电商客服的例子一样——粗筛比"整体像不像"，精排比"局部对不对"。

第四步：拼 Prompt

精排后取 top 3，拼进 system prompt：

你是公众号文章写作助手。请参考以下历史文章的写作风格来写作。

【风格参考 1】（来源：手动撸一个 Redis 分布式锁）
“大家好呀，对于使用 Java 的小伙伴，其实我们完全不用去
手动撸一个分布式锁，直接使用 Redisson 就行。但是因为这些封装好
的组建，让我们越来越懒。”

【风格参考 2】（来源：MySQL 单表可以放多少数据）
“我说MySQL每张表最好不超过2000万数据，面试官让我回去等通知？”

【风格参考 3】（来源：只会单机执行定时任务？多机执行 yyds！）
“留给大家一个问题，如果有一条数据一直处理失败，每次获取数据，
都会先获取到这条问题数据，那么有什么策略可以让这条数据推后执行呢？”

请模仿以上段落的口吻、句式、段落节奏，写一篇关于 RAG 原理和实战的技术文章。

Agent 看到这些参考，会模仿里面的口吻、句式、节奏来写新文章。RAG 的知识来自 LLM 本身，风格来自这些检索到的历史文章片段。

整个流程和第二章的电商客服链路一样——切块、入库、粗筛、精排、拼 Prompt。目的不同，链路相同。

最后说一句实话：用 RAG 做风格匹配，效果其实一般。RAG 检索的依据是语义相似度，找的是"主题相近的文本"，不是"风格相近的文本"。两篇文章主题完全不同，写作风格可能一模一样——RAG 分辨不出来。

这里用"写作风格"做案例，是为了演示同一套链路怎么适配不同需求。实际生产中，RAG 用于知识检索（查政策、查文档、查流程）效果好得多——第二章的电商客服才是它的主战场。

一句话：197 篇文章切成 2800 个 chunk、28MB 的向量库、一个查询从粗筛到精排的完整过程——理论和实物对照着看，才算真正理解了 RAG。

06 写在最后

RAG 就一件事：在模型答题前，替它把对的资料翻出来。

第一章讲了为什么需要 RAG——大模型有幻觉、知识过时、不认识私有数据三个毛病，RAG 用开卷考试的思路解决。

第二章走了完整链路——离线四步把知识变成可检索的向量，在线四步把问题变成最相关的答案，用电商客服的例子从头到尾走了一遍。

第三章解决了"检索得准"——向量检索管语义，BM25 管关键词，RRF 融合两路结果，Rerank 把对的排前面。

第四章解决了"检索得聪明"——查询改写救模糊问题，元数据过滤砍噪声，Agentic RAG 按需决定查不查。

第五章用真实项目验证——197 篇文章切成 2800 个 chunk，从粗筛到精排的完整过程，理论和实物对照着看。

如何学习大模型 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

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

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