大模型在处理内部问题时常出现幻觉和知识盲区RAG技术通过开卷考试的方式让大模型在答题前检索相关资料从而提供准确答案。本文详细介绍了RAG的原理、链路以及实操步骤帮助小白程序员理解和应用RAG技术避免大模型应用中的常见问题。你有没有遇到过这种情况问大模型一个公司内部的问题它一本正经地胡说八道比如问它我们公司的退款流程是什么它给你编一套看起来很合理的步骤——但跟你公司的实际制度完全对不上。你追问它它还能继续编编得越来越像真的。这不是模型笨是它压根没见过你的数据。大模型的训练数据是公开互联网你的公司制度、产品文档、私有知识它一概不知。 但它不会说我不知道而是编一个概率上最合理的答案——这就是幻觉。RAG 就是解决这个问题的。今天这篇文章从原理到生产一次讲透全程不依赖任何框架。01 RAG 就是开卷考试先回答一个根本问题为什么需要 RAG因为大模型有三个治不好的毛病毛病具体表现例子幻觉不知道就瞎编还编得像真的问它你公司的退款政策它一本正经地胡说知识过时训练数据有截止日期问它昨天的汇率、上周发布的 API不认识私有数据企业文档、个人数据它没见过问它你家产品的参数、你的写作风格这三个毛病有一个共同的根因LLM 是闭卷考试选手。它靠肚子里的记忆答题记忆里没有的它不会说我不知道而是编一个概率上看起来合理的答案。RAG 的思路简单粗暴让它开卷。答题之前先去资料库里把相关内容翻出来塞进提示词让它照着资料回答。闭卷裸 LLM 提问 → 靠记忆硬答 → 没有的部分瞎编开卷RAG 提问 → 先检索相关资料 → 基于资料生成 → 答不上就说不知道说白了RAG 根本没动生成那一环——生成用的还是同一个 LLM。它干的唯一一件事是在模型答题前替它把对的资料翻出来。检索错了生成再强也白搭——就像开卷考试翻错了书答得再流畅也是零分。记住这句话它是后面所有优化的出发点混合检索、Rerank、Agentic RAG全都在解决同一个问题——怎么把对的那一段捞出来。一句话RAG 开卷考试。模型没变变的是它答题前能不能翻到对的一页。02 全链路离线四步 在线四步RAG 的完整链路分两个阶段这个划分必须刻在脑子里后面所有内容都挂在这两条线上【离线阶段建索引】—— 一次性 / 定期做回答知识怎么进系统文档加载 → Chunk 分块 → Embedding 向量化 → 存入向量库【在线阶段查询】—— 每次提问都做回答问题怎么找到答案用户提问 → 向量检索召回 → Rerank 重排 → 拼进 Prompt → LLM 生成光看链路有点抽象我们用一个电商客服助手的场景把两条链路各走一遍。1 离线阶段把《退货退款政策》变成可检索的库假设你是一家电商公司的技术负责人客服团队每天要回答大量退货退款问题。你决定做一个 RAG 系统把公司的《退货退款政策 v2.1》5000 字喂进去。原始文档《退货退款政策 v2.1》5000 字 Markdown↓ 加载解析成纯文本标题层级保留↓ 分块按章节递归切“七天无理由退货”“退款时效”运费承担各自成块每块约 500 字相邻块重叠 10%防关键条款卡在切分线上↓ 向量化每个块过 embedding 模型变成一串数字如 1536 维向量↓ 入库向量 原文 元数据章节路径售后/退货/运费存进向量库产出几十个政策片段等用户来问① 文档加载把各种格式的文档读进来转成纯文本。听着简单实际是全链路最脏的活▪ PDF 最难搞扫描件图片型 PDF得先 OCR带表格的 PDF 转出来经常是乱码▪ 表格直接转纯文本会丢结构要转成 Markdown 表格保留行列▪ 代码块要保留格式和语言标记电商场景比较幸运政策文档是 Markdown天然干净。但如果你的源是 PDF听我一句劝这一步至少预留三分之一的工程时间。② Chunk 分块为什么必须切块三个原因文档太长塞不进上下文窗口embedding 模型有输入上限通常几百 token切块后才能精准命中相关的那一段而不是甩一整篇过去。我们的政策文档按章节递归切分章节块大小内容七天无理由退货~500 字退货条件、适用范围、不适用商品退款时效~400 字审核时间、到账时间、不同支付方式运费承担规则~300 字买家承担 vs 商家承担、质量问题例外特殊商品退货~350 字生鲜、定制商品、数码产品的特殊规则顺带把三种切法都摆出来按场景选切法怎么切优点缺点固定大小每 N 字符切一块简单可预测无视结构段落表格被拦腰斩结构感知按标题→段落→句子递归切尊重文档结构略复杂语义切分相邻句 embedding 相似度突变处下刀块内主题最纯要额外算一遍相似度成本高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 模型名写进元数据查询时校验不一致直接报错拒绝服务——宁可明确失败不要静默胡说。④ 存入向量库向量库选型看规模和基础设施向量库定位适用Chroma轻量嵌入式本地文件持久化个人项目、十万级以内 chunkPGVectorPostgreSQL 插件已有 PG 基础设施不想多运维一套Milvus分布式专业向量库生产海量、要高可用FAISS本地库不是服务离线批量实验选型的核心是够用不是最强——数据量没到十万级Milvus 的分布式能力一分都用不上。入库时有三个细节别忘▪ 向量旁必须存原文——检索出来拼回 prompt 的是原文不是向量▪ 存元数据来源章节、分类、块序号——后面做过滤全靠它▪ 批量入库——避免一次性内存暴涨**2 在线阶段用户问买了三天想退货运费谁出光看链路有点抽象我把在线阶段四步拆开用同一个例子走一遍你就知道每一步到底在干嘛。第一步向量召回粗筛用户问题过 embedding 模型变成向量去向量库里算相似度拉回 top 20 条。实际跑出来大概长这样排名 来源章节 内容摘要 相似度1 七天无理由退货 “签收后7天内可申请无理由退货需商品完好…” 0.892 退款流程 “提交申请后1-3个工作日审核退款原路返回…” 0.853 运费承担规则 “退货运费由买家承担因质量问题退货的运费…” 0.834 特殊商品退货 “生鲜、定制商品不支持无理由退货…” 0.785 退货时效 “签收次日起算7个自然日…” 0.76你可能发现了——用户明明问的是运费但运费承担规则只排第 3排在前面的反而是七天无理由退货和退款流程。原因也不复杂向量检索比的是整体语义相似度七天无理由退货和退款流程跟退货这个大主题更近自然排前面。但用户要的不是怎么退货是运费谁出——粗筛捞得全但排不准这很正常。第二步Rerank 精排粗筛不准那就加一道精排。把 top 5 条和用户问题一起丢进跨编码器逐词对照打分排名 来源章节 跨编码器得分 变化1 运费承担规则 8.72 ↑ 从第3升到第12 七天无理由退货 6.35 ↓ 从第1降到第23 特殊商品退货 4.18 ↑ 从第4升到第34 退款流程 2.05 ↓ 从第2降到第45 退货时效 1.32 ↓运费承担规则直接从第 3 翻到了第 1。原理也不复杂粗筛比的是整体像不像精排比的是局部对不对。跨编码器是把问题和文档拼在一起逐词比对的——用户的运费和文档的运费承担规则精确匹配得分自然高而退款流程虽然语义相关但里面压根没有运费这个词逐词比对后得分就掉下去了。粗筛像猎头扫简历5 秒一份快速过精排像面试官坐下来深聊一个一个对。 先粗筛再精排捞得全也排得准。取 top 3 进入下一步。第三步拼接 Prompt把 top 3 的原文塞进提示词。直接把检索结果丢给模型还不够还得加工一下你是电商客服助手。请基于以下参考资料回答用户问题。如果资料里没有相关信息请如实说我暂时无法回答不要编造。【参考资料 1】运费承担规则退货运费由买家承担因质量问题退货的运费由商家承担。运费在退款时一并扣除无需单独支付。【参考资料 2】七天无理由退货签收后7天内可申请无理由退货需商品完好、包装齐全。不适用于生鲜、定制商品、已拆封的数码产品。【参考资料 3】特殊商品退货生鲜、定制商品不支持无理由退货。数码产品已拆封的需提供检测报告方可退货。用户问题买了三天想退货运费谁出两个细节参考资料带了来源标记“运费承担规则”方便溯源——用户追问的时候能说清楚这个结论来自哪条政策提示词里写了资料里没有就说不知道——这是在给模型上缰绳不让它瞎编。第四步LLM 生成模型看到参考资料后基于资料生成回答您购买三天在7天无理由退货期限内可以申请退货。退货运费由您自行承担退款时会一并扣除。如果是因为商品质量问题退货运费则由商家承担。答案里的每一个数字、每一条规则都来自参考资料——7天内来自参考资料 2运费买家承担来自参考资料 1质量问题商家承担也来自参考资料 1。要是粗筛里压根没有运费承担规则那段模型再聪明也只能编。四步走完整个流程的核心就一句话粗筛负责捞得全精排负责排得对Prompt 负责给模型上缰绳。 三件事做好了RAG 的在线阶段就不会掉链子。一句话离线四步把知识变成可检索的向量在线四步把问题变成最相关的答案。两阶段必须用同一个 embedding 模型否则向量空间对不上检索结果全乱。03 怎么检索得准链路搭完第一次检索大概率会让你失望——不是完全不准是大部分还行关键时候掉链子。**1 检索方式全景先搞清楚有哪些牌可以打。三种检索方式每种都有自己的绝活和盲区检索方式原理擅长盲区速度向量检索稠密语义相似度同义词、意译、模糊表达精确编号、专有名词快关键词检索 BM25稀疏词频 稀有度精确匹配、型号、报错码同义词、语义改写快混合检索两路并行 RRF 融合盲区互补成本翻倍中光看表格没体感每种举个正反例子向量检索——比的是意思像不像不是字面。搜小狗能找到只写了幼犬的文档因为小狗和幼犬语义接近。但搜HTTP-403 报错返回的可能是一堆泛泛的服务器错误讨论——语义确实近但你要的就是 403 这个精确编码它抓不到。BM25 关键词检索——比的是字面命中。搜HTTP-403精确命中写了这个错误码的文档。但搜kitty找不到通篇只写了cat的文档——它只认字面不懂同义。混合检索——两路都跑盲区互补。向量检索管语义BM25 管精确关键词两路各查各的用 RRF 融合。搜RTX 4090 价格向量检索能找到显卡多少钱BM25 能精确命中RTX 4090这个型号——单靠任何一路都会漏。三种检索负责的是捞得全但捞回来的顺序不一定对。后面还需要一道精排把真正相关的排到前面——这就是 Rerank3.3 再展开讲。整个流程是这样的检索三选一 → 负责捞得全召回阶段↓Rerank 精排 → 负责排得对精排阶段↓拼 Prompt → 负责约束生成**2 混合检索两种盲区互补运费承担规则 ← 对了排第 3特殊商品退货退货时效方案 B向量检索 Rerank运费承担规则 ← 对了排第 1七天无理由退货特殊商品退货退款流程退货时效三个指标分别算recall3前 3 条里有没有正确答案方案 A 的运费承担规则排第 3命中recall3 1。方案 B 排第 1也是 1。看起来一样别急。MRR第一个正确答案排第几方案 A 排第 3MRR 1/3 ≈ 0.33。方案 B 排第 1MRR 1。差距就出来了——MRR 关心的是找到得够不够快排第 1 和排第 3 体验完全不同。nDCG整个排序列表质量如何方案 B 把正确答案排在最前面不相关的沉底nDCG 更高。方案 A 虽然也找到了但正确答案被两个不相关的压着列表整体质量差一截。三个指标各管一件事recall 管找没找到MRR 管找得快不快nDCG 管整个列表排得好不好。实际评估时从真实用户问题里挑 30-50 个人工标好标准答案改一版参数跑一遍三个指标——数字涨了才算优化。凭感觉说好像准了不算真的不算。一句话混合检索补精确匹配、Rerank 把对的排前面、RRF 用只看排名的方式融合两路结果优化效果盯 recallk数字涨了才算数。04 怎么检索得聪明前三章解决的是检索得准这一章换一个维度怎么让检索变聪明——该查什么、什么时候查、查几次。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%。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 自己肚子里有。它需要找的是写这类技术文章时是什么风格——怎么开头、怎么用比喻、段落多长、语气什么样。1 离线197 篇文章怎么变成风格参考库知识源是197 篇 Markdown 文章按分类放在 11 个目录里。技术类占大头——Spring 全家桶 39 篇、Java 与 JVM 30 篇个人类也不少——个人成长 29 篇、管理与随笔 28 篇。这些文章切块入库后每个 chunk 带两个元数据标签styletechnical / personal和category来自哪个目录。写技术文章时只检索 technical 的 chunk写随笔时只检索 personal 的 chunk——用元数据过滤风格不过滤知识。切块一篇真实文章的拆解拿《手动撸一个 Redis 分布式锁》走一遍7745 字切块参数是每块 1000 字符、重叠 150 字符、从切点往前扫空行找段落边界。切完产出 10 个 chunk挑几个有代表性的Chunk 1988 字文章开头“大家好呀对于使用 Java 的小伙伴其实我们完全不用去手动撸一个分布式锁直接使用 Redisson 就行。但是因为这些封装好的组建让我们越来越懒……”Chunk 2796 字锁超时的核心问题“通过和当前时间比较判断锁是否超时。如果锁未超时直接返回如果锁超时重新设置锁的超时时间成功获取锁。还有其它问题么当然因为在并发场景下会存在 A、B 两个线程同时……”Chunk 3907 字并发场景分析“延长或缩短了锁的超时时间不会有问题么其实在现实并发场景中能走到这一步基本是’同时’进来的两者的时间差非常小……”Chunk 8-10 是文章尾部的总结和好文推荐链接。197 篇文章的尾部长得一模一样——都是模板。这些是噪声入库前应该清洗掉该库建得糙没做这一步。入库真实参数参数值为什么这么定CHUNK_SIZE1000 字符约 500-700 中文 token试过 2000混主题太严重试过 500语义太碎。1000 是经验甜点CHUNK_OVERLAP150 字符约 15%防止关键信息卡在切分线段落边界回扫从切点往前找空行避免在段落中间下刀Embedding 模型OpenAItext-embedding-3-small1536 维优先降级用本地bge-small-zh-v1.5384 维批量入库50 块一批避免内存暴涨元数据styletechnical/personalcategory按目录结构自动推断用于过滤风格197 篇文章切完产出约 2800 个 chunk向量库文件 28MB。就是一个小文件的事ChromaDB 一个嵌入式文件就装下了。2 在线写一篇 RAG 文章时系统怎么找风格参考以这篇 RAG 文章为例走一遍完整流程。第一步风格判断用户输入写一篇关于 RAG 原理和实战的技术文章。“RAG”“原理”“实战都是技术关键词过滤styletechnical把聊聊焦虑”谈谈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 保持第 12 MySQL 单表可以放多少数据 0.996 保持第 23 Redis 高可用原理 0.994 ↑ 从第 3 升到第 3噪声被淘汰后补位4 如何保障 MySQL 和 Redis 数据一致性 0.992 ↑ 从第 5 升到第 45 只会单机执行定时任务多机执行 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取