尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

《大模型RAG生成式AI开发实战》_1.[第1章 RAG基础概念] RAG技术全景图:检索增强生成的核心原理与应用场景

《大模型RAG生成式AI开发实战》_1.[第1章 RAG基础概念] RAG技术全景图:检索增强生成的核心原理与应用场景 告别LLM一本正经地胡说八道一张全景图带你吃透RAG让大模型从闭门造车进化到开卷考试这是每一个想做大模型应用的开发者必须补上的第一课。本文将从认知纠偏、架构拆解、检索选型、数据工程到落地场景手把手帮你建立RAG的全景视野彻底搞懂检索增强生成到底在解决什么问题、该怎么解决。RAG技术全景图核心原理与应用场景1. RAG到底是什么从死记硬背到开卷考试2. 为什么大模型非RAG不可幻觉、时效与私有知识三座大山3. RAG核心架构拆解检索器、生成器与连接器4. 检索技术选型向量、关键词与混合检索5. 数据准备与分块Garbage In, Garbage Out6. 典型应用场景与落地路径找到你的第一战场基础概念与认知误区大模型原生缺陷与RAG解药三阶段流水线与质量瓶颈技术选型与Embedding模型分块策略与数据清洗落地场景与MVP路径文字目录RAG到底是什么从死记硬背到开卷考试的认知升级为什么大模型非RAG不可幻觉、时效与私有知识三座大山RAG核心架构拆解检索器、生成器与连接器怎么打配合检索技术选型向量检索、关键词检索与混合检索的抉择数据准备与分块Garbage In, Garbage Out的真理典型应用场景与落地路径找到你的第一战场嗨大家好呀我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》1.[第1章 RAG基础概念] RAG技术全景图检索增强生成的核心原理与应用场景。老话说得好“没有金刚钻别揽瓷器活”。可在如今这个大模型满天飞的时代很多兄弟看着Demo里ChatGPT对答如流就觉得自己手里握的不是金刚钻而是瑞士军刀——啥都能干。结果呢一放到真实业务里它给你把公司内网架构图瞎编一通把过时的API文档说得有模有样甚至给不存在的论文列出一串参考文献。你是不是也这样明明接了大模型API看着它回答得像模像样心里却直打鼓“这哥们到底靠不靠谱啊” 别慌今天咱们就聊聊怎么给大模型戴上紧箍咒也就是RAG——检索增强生成。这玩意儿是你从玩Demo迈向做产品的第一块垫脚石。1. RAG到底是什么从死记硬背到开卷考试的认知升级嗨咱先不聊代码先聊个认知。啥是RAGRetrieval-Augmented Generation检索增强生成。这名字听起来挺唬人但你把它拆开看就是检索加上生成。很多新手第一次听到RAG脑子里直接跳出来的画面是“哦就是给大模型外挂一个数据库呗。” 或者更离谱的“RAG是不是就是微调Fine-tuning的另一种叫法” 停这俩认知都是巨坑掉进去你后面所有的架构设计都会歪。我见过太多兄弟一上来就先把公司几百份PDF往向量数据库里一倒接个OpenAI的API然后拍着胸脯说“我们上RAG了” 结果用户问一句咱们2024年Q2的退款政策是啥系统检索回来一份2023年的旧文档模型一看有资料自信满满地开始按老政策回答。用户真按这个去退款客服团队直接炸了。这就是典型的把RAG当文档搜索引擎的误区。还有兄弟拿着RAG做微调的事试图靠往向量库里塞数据来教会模型新的推理能力这完全是南辕北辙。RAG的本质不是让模型在训练时死记硬背更多知识而是在考试时允许它翻书。你可以这么理解微调Fine-tuning就像高考考前把知识全塞进脑子里考场上全凭记忆和参数里的惯性RAG就像开卷考试考场上给你一摞参考书考察的是你的阅读理解、信息整合和表达能力。模型那个大脑袋参数里装的是通用的语言能力和推理能力而具体的、实时的、私有的知识存在外头的图书馆向量库或搜索引擎里。从演进上看RAG也经历了好几代。最早是Naive RAG就是简单的检索-拼接-生成像把书页撕下来贴到试卷上。后来发展到Advanced RAG引入了查询改写、重排序、上下文压缩这些精细操作相当于学会了在书里做目录、划重点。再到Modular RAG检索和生成被拆成了可插拔的模块甚至能循环迭代比如检索一次生成一段发现不够再检索。你现在入局至少得奔着Advanced RAG的思路去别停留在Naive阶段。正确的做法是什么是建立一个检索-阅读-生成的协同流水线。当用户提一个问题系统先不急着让模型回答而是先派一个图书管理员去知识库里找最相关的几页资料。找回来之后不直接丢给模型而是整理成一段参考资料塞进Prompt里再告诉模型“你待会的回答必须严格基于我给你的这些资料。如果资料里没提你就老老实实说不知道别给我编。”你看这时候模型的角色从全知全能的神变成了严谨的秘书。它不需要记住公司所有产品参数它只需要会读文档、会总结、会组织语言。这样做的好处太大了知识更新了换掉外头图书馆里的书就行模型不用重新训练换业务线了换一批文档就行API接口都不用改。数据和模型解耦这才是工程化思维。所以啊RAG不是给模型灌记忆而是给模型配了一副实时更新的外接眼镜。记住这个类比后面所有架构设计都是围绕这个逻辑展开的。小结RAG的核心是开卷考试不是死记硬背。检索负责找证据生成负责组织语言两者缺一不可。2. 为什么大模型非RAG不可幻觉、时效与私有知识三座大山光知道RAG是开卷考试还不够咱得深挖一层为什么大模型非得靠RAG不可它不是很厉害吗兄弟厉害归厉害但大模型有三个原罪就像游戏角色自带的Debuff很难根除。第一个叫幻觉Hallucination。这词听起来挺文艺说白了就是一本正经地胡说八道。模型被训练成必须给出流畅回答可它并不真正知道什么是真什么是假。我见过一个真实案例某创业公司做技术博客助手让GPT-4写篇关于分布式事务的总结。结果文章写得文采飞扬里头引用了一篇论文《A Novel Approach to Distributed Transaction by Smith et al. 2023》名字像模像样DOI编号也像那么回事。结果你猜怎么着这篇论文根本不存在Smith这人可能是个卖汉堡的。开发者没细看直接发出去被读者在评论区锤爆了。这还算轻的如果是医疗、法律、金融场景幻觉的代价可能就是真金白银甚至人身安全。第二个叫知识时效性。大模型的知识是参数化的训练数据截止到某个时间点。比如GPT-4的知识有截止日期你问它2024年最新出台的AI监管法案它要么说不知道要么开始用2023年的旧政策瞎编。就好比你拿着2022年的地图去2024年的北京找地铁站能找对才怪。模型参数一旦冻结它的时间观念就停滞了可现实世界的时间是往前走的。第三个叫私有知识缺失。模型训练用的是互联网公开数据你们公司的内部代码规范、内网架构文档、未公开的产品白皮书、人事行政制度、私有领域术语它一概没见过。你问它咱们公司报销流程需要几个审批人它凭着互联网的通用经验给你编一个通常需要直属领导审批可你们公司实际上需要三级审批。这种没见过的知识不是幻觉而是盲区更难防范。这三个痛点叠加在一起就是RAG的用武之地。RAG把知识从模型参数里抽离出来放到外置的、可实时更新的非参数记忆Non-parametric Memory中。每次回答前先从最新、最全、最准的知识库中检索证据再生成回答。具体怎么做在Prompt里做事实锚点。比如你这样构造Prompt请基于以下参考资料回答用户问题。 如果参考资料不足以回答问题请明确告知用户根据现有资料无法确定严禁编造。 参考资料 [检索到的文档片段1] [检索到的文档片段2] 用户问题{question}你看这就给模型戴上了紧箍咒。它想胡说八道可以但得先过检索资料这一关。资料里没有的它再能编也得憋着。这不是不相信大模型而是工程落地的底线思维。我们追求的是可验证的正确而不是听起来正确的。小结RAG不是锦上添花而是给大模型装上了事实校对仪是解决幻觉、时效和私有知识三大痛点的工程底线。3. RAG核心架构拆解检索器、生成器与连接器怎么打配合光知道RAG有用还不够咱得把它拆开来看看看这机器内部是怎么运转的。很多新手有个坏毛病选型时只盯着我用GPT-4还是Claude 3还是用开源的Qwen 仿佛选了个牛X的基座模型RAG就稳了。错在整个RAG链路里生成器也就是大模型可能只决定了20%的效果剩下80%取决于检索链路的质量。这是新手最容易忽视的真相。一个标准的、工业级的RAG流水线至少得有这么几个工位查询理解Query Understanding用户问这破玩意怎么退你得先把它翻译成退款流程不然检索器一脸懵逼。这叫查询改写Query Rewriting或者更高级的多查询扩展Multi-Query把一个口语化问题扩展成多个同义查询分别检索再合并结果。检索召回Retrieval从海量文档里快速捞出Top-K篇相关文档。这一步要的是速度和召回率不求最准但求别漏。重排序Rerank初召回的100篇里可能只有5篇真的有用。需要用更精细的模型比如Cross-Encoder再做一次精排。你可以理解为检索器是海选重排序是决赛。上下文压缩Context Compression把长篇文档里的无关段落剃掉只保留相关片段节省Token也减少噪声干扰。Prompt构建Prompt Engineering把检索结果、历史对话、系统指令编排成模型能理解的格式。不是简单拼接而是结构化呈现。生成与后处理Generation Post-processing让模型生成回答并加上溯源信息比如根据《用户手册》第3章让用户知道答案不是凭空来的。让我画个流程图你一看就明白用户原始提问查询改写与扩展检索召回Top-K 100篇重排序Cross-Encoder精排上下文压缩提取关键片段Prompt构建系统指令资料问题大模型生成带溯源的最终回答这个链路里新手最爱踩的坑就是检索Top-5直接拼进Prompt。比如用户问怎么退款你的检索器按向量相似度召回三篇文档分别是《付款流程说明》、《英文版退款政策已废弃》、《售后服务总则》。你不做重排序直接把这三篇按相似度高低塞进Prompt。模型看了半天发现《付款流程》里说付款后不可撤销《售后服务总则》里提了一句具体问题请联系销售唯独最关键的最新《退款政策》因为向量化后语义相近度略低排在了第四没被塞进Prompt。模型只能基于前三篇瞎编“退款请联系您的销售代表。” 而实际上最新的App内一键退款政策就在那第四篇文档里。还有Query改写这一步太重要了。用户问这破玩意怎么退系统如果直接拿这句话去检索大概率检索不到退款流程这种正式文档。你需要用一个小模型或者一个Prompt把口语化的问题改写成标准问法。这叫查询扩展是Advanced RAG的标配。上下文压缩也别忘了。有些兄弟说我用128K模型直接把100篇文档全塞进去。千万别大模型对长文本的注意力是有限的中间部分很容易看漏眼。你塞进去100篇模型可能只认真看了前5篇和后5篇中间的90篇成了注意力盲区。正确的做法是只塞最相关的5-10个片段每个片段控制在300-500字把信息密度拉满。长上下文是核武器但别拿它当常规武器用。小结RAG的工程质量80%取决于检索链路20%取决于基座模型。查询改写、重排序、上下文压缩这三板斧缺一不可。4. 检索技术选型向量检索、关键词检索与混合检索的抉择检索链路里最核心的引擎就是检索本身。现在主流的检索方式有三兄弟关键词检索比如BM25、向量语义检索Dense Retrieval、以及它们的混血儿——混合检索Hybrid Search。选错检索方式就像给赛车装了个拖拉机的引擎再强的模型也跑不动。很多新手到了这一步直接All-in向量检索。为啥因为听起来高大上啊“语义理解”、“Embedding”、“向量空间”多酷。结果呢用户搜个订单号ORD-2024-8892向量检索给你返回一个ORD-2024-8893因为Embedding觉得这两个字符串长得太像了语义相近。可用户要的是精确匹配啊再比如你用通用的语义向量模型去做电商客服用户问苹果15多少钱结果检索回来一篇《红富士苹果种植基地采购指南》因为苹果这个词在语义空间里水果和手机的距离可能比你想的近。这种坑踩进去你都不知道怎么死的。反过来只用关键词检索比如ElasticSearch的BM25也有问题。用户问为啥我的手机充不进电文档里写的是设备无法充电的排查方法关键词一个都对不上BM25直接傻眼。因为BM25是基于词频和共现的它不懂手机和设备是一个东西也不懂充不进电和无法充电是同义。所以啊生产环境里真正靠谱的是混合检索Hybrid。一路走关键词做精确匹配一路走向量做语义泛化两路召回的结果做一次融合比如RRF算法Reciprocal Rank Fusion或者交给重排序模型统一打分。这就好比打仗炮兵关键词负责定点清除空军向量负责大面积覆盖两者协同才能不留死角。这里还有个选型的坑Embedding模型别乱选。新手最爱犯懒直接用OpenAI的text-embedding-ada-002或者某个通用模型不做领域适配。你想想你搜的是法律合同、医疗文献、或者代码仓库通用语义模型能懂不可抗力和代码递归的细微差别吗国内像BGE、M3E这些开源模型在特定领域上微调后效果往往比通用模型好一大截。选型的时候一定得拿你的真实业务query去跑测试集看MRR、NDCG这些指标别凭感觉拍脑袋。这个图你看明白了RAG的检索层不是单行道而是立交桥。两路并进才能兼顾召回率和准确率。至于到底用BM25占几成、向量占几成这没有标准答案得根据你的数据特性做AB测试。但方向是明确的混合检索是工业界的共识单吊任何一路都是赌博。小结检索没有银弹Hybrid混合检索才是兼顾精确匹配与语义泛化的工业界共识。5. 数据准备与分块Garbage In, Garbage Out的真理如果说前面的检索和生成是上层建筑那数据准备就是地基。有句话叫Garbage In, Garbage Out垃圾进垃圾出。这道理谁都懂可新手在这一步掉的坑深得能埋人。最经典的错误操作拿到文档不管三七二十一按固定长度一刀切。比如每1000个字符切一块。兄弟你知道这意味着什么吗一个Markdown表格刚切到表头下一块直接是表格内容表头和数据身首异处。一段Python代码def calculateTotalPrice(orderId, couponCode):这行在上一块的末尾函数体在下一块的开头。用户问怎么计算优惠券价格检索召回的是上半块模型只看到一个函数名和orderId参数压根没看到couponCode于是回答不支持优惠券功能。实际上不是不支持是你把人家的代码拦腰斩了这叫分块事故。还有更隐蔽的坑。PDF转文本的时候页眉的第X页和页脚的版权所有 © 2023也被当成正文一起向量化。用户问公司版权归属检索结果召回一堆页脚模型一本正经地回答版权所有。这不是扯淡吗更离谱的是有些文档里重复出现导航栏、版权声明、作者介绍这些内容被反复向量化导致检索时召回一堆噪声块把真正有用的信息挤到了后面。正确的数据流水线应该是这样的第一步解析与清洗。PDF、Word、Markdown、HTML不同格式用不同的解析器。解析出来后把页眉页脚、水印、重复的超链接导航栏、页码、作者签名全部洗掉。这一步可以用正则表达式也可以用一些文档解析库。记住清洗不是可选步骤是必选项。第二步分块Chunking。别按固定长度切按语义切。比如Markdown按标题层级切HTML按标签切代码按函数或类切。如果文档太长可以用递归字符分割先按段落切段落还长就按句子切句子还长再按字符切同时保持重叠Overlap比如前一块的末尾100字包含在下一块的开头确保语义在边界处不断裂。分块长度选多少没有标准答案但有个经验区间纯文本可以按256-512 tokens代码按函数粒度QA对可以按问题加答案粒度。还有一个高阶技巧叫Parent Document Retrieval小块向量化用于检索但召回后把大块甚至整篇文档送进模型保证上下文的完整性。第三步元数据Metadata绑定。每块文本都要带上它的身份证来自哪个文件、第几章、什么类型、更新时间。这样在检索时你可以做过滤Filter比如只搜2024年的文档只搜技术规范类别的文档。元数据就是给检索加杠杆。你别看这一步脏、累、好像没技术含量在实际项目里数据准备往往占掉你80%的时间。但效果提升也是最大的。你检索做得再花哨如果喂进去的是切碎的表格和腰斩的代码那也是巧妇难为无米之炊。很多RAG项目做不出来效果根本不是因为模型不够大而是因为数据太脏。小结数据准备是脏活累活却是RAG效果的天花板。花80%的时间洗数据往往比花80%的时间调Prompt更有用。6. 典型应用场景与落地路径找到你的第一战场聊了这么多原理和架构咱最后再落地一点RAG到底适合干什么新手最容易犯的错就是上来就想做一个全公司万能知识库。销售文档、技术规范、人事制度、财务报表、老板讲话稿全部倒进去结果权限管理搞不定、文档格式乱七八糟、检索效果一塌糊涂。项目做了三个月Demo都跑不通团队信心崩了老板质疑声起你整个人都不好了。还有些场景根本不适合RAG。比如实时性要求极高的业务用户问我的订单现在到哪了你拿RAG去检索历史文档文档里写的是订单已发货可实际上5分钟前快递已经到驿站了。这种得走数据库查询或API别硬套RAG。再比如简单的计算题11等于几你检索什么直接让模型算就行。RAG不是万能胶别见什么就粘什么。那什么样的场景是RAG的舒适区我给你列几个典型企业知识库问答技术文档、产品手册、客服FAQ。知识相对静态问答频率高答案需要溯源。这是RAG最成熟的主战场。智能客服替代传统FAQ的硬匹配能理解用户口语化的问题并从多篇文档中组织答案。比如用户问这破玩意怎么退系统能自动关联到退款政策。代码助手基于企业私有代码库做问答比如咱们封装的支付模块怎么用。但这里要注意代码检索最好混合关键词和向量因为函数名和变量名是精确匹配而注释是语义匹配。合规审查与报告生成从大量合同、法规中检索相关条款辅助生成审查意见。这种场景对不胡说的要求极高RAG的事实锚点特性正好对症下药。怎么切入记住别贪大。从一个部门、一个小场景开始比如技术部的新人文档问答或者客服部的Top 50常见问题。文档量控制在几十到几百篇先把链路跑通。技术栈上先搭建一个最简单的关键词搜索基线看看效果如果关键词不够再上向量检索如果向量检索召回不准再加混合检索和Rerank。这叫MVP最小可行产品思维别一上来就搞平台化。评估一个场景是否适合RAG有三个标准第一知识是否以非结构化文档为主且更新不频繁第二问题是否是知识密集型需要综合多篇文档回答而不是计算密集型或实时查询型第三业务是否能容忍秒级的检索延迟如果三个都是Yes那RAG就是一把好刀。如果有一个No你就得再想想。小结RAG是手术刀不是万能锤。从闭环小场景切入用MVP思维逐步迭代才是落地正解。写在最后好了咱们这第一章的RAG技术全景图就聊到这。你看RAG从来不是简单的向量数据库大模型API的拼积木它是一套从数据工程、检索策略、重排序、上下文管理到Prompt优化的系统工程。它解决的也不是让模型更聪明的问题而是让模型更靠谱、更可控、更接地气的问题。在这一章里咱们把认知误区纠偏了把架构链路拆透了把检索选型捋清了把数据准备的脏活累活正视了也把落地场景锚定了。很多兄弟看着大模型这一片蓝海心里既兴奋又焦虑生怕自己上车晚了。但我跟你说大模型应用开发这班车现在才刚刚启动。RAG作为最成熟、最落地的工程范式是你从调API的脚本小子进化到做AI产品的系统工程师的必经之路。别怕链路长咱们程序员最擅长的不就是把复杂问题拆成一个个小模块然后逐个击破吗路虽远行则将至。事虽难做则必成。保持好奇持续动手先把这一章的脉络理顺后面的实战环节我带着你一行一行代码地搭起来。你也能做出让老板眼前一亮、让用户放心依赖的AI应用。关注私信备注“资料代找获取”全网计算机学习资料代找例如:《课程2026 年多模态大模型实战训练营》《课程AI 大模型工程师系统课程 (22 章完整版 持续更新)》《课程AI 大模型系统实战课第四期 (2026 年开课 持续更新)》《课程2026 年 AGI 大模型系统课 23 期》《课程2026 年 AGI 大模型系统课 21 期》《课程AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》《课程AI 大模型系统实战课三期》《课程AI 大模型系统课程 (2026 年 2 月开课 持续更新)》《课程AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》《课程AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》《课程2026 年最新大模型 Agent 开发系统课 (持续更新)》《课程LLM 多模态视觉大模型系统课》《课程大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》《课程大模型智能体线上速成班 V2.0》《课程JavaAI 大模型智能应用开发全阶课》《课程PythonAI 大模型实战视频教程》《书籍软件工程 3.0: 大模型驱动的研发新范式.pdf》《课程人工智能大模型系统课 (2026 年 1 月底完结版)》《课程AI 大模型零基础到商业实战全栈课第五期》《课程Vue3.5Electron 大模型跨平台 AI 桌面聊天应用实战 (2025)》《课程AI 大模型实战训练营 从入门到实战轻松上手》《课程2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》《课程大模型训练营配套补充资料》
返回列表