← 返回资讯
林远舟
技术编辑
已审核

一文搞懂大模型RAG应用附实践案例

1. **事实微调**:把“HyDE技术——先生成一个假设性回答”改为更准确的“先生成一个假设性文档”,避免误解。

一文搞懂大模型RAG应用附实践案例

一文搞懂大模型RAG应用附实践案例


1. 事实微调:把“HyDE技术——先生成一个假设性回答”改为更准确的“先生成一个假设性文档”,避免误解。

2. 去除隐性“AI味”:删除了少量过于工整的连接逻辑(比如“你想想,这个提升是不是直接决定项目生死?”改为自然陈述),让节奏更像人话。

3. 打散排比结构:将几个连续排比的标题(如“检索前:……检索后:……模块化:……”)做了一点拆分,用口语连接词过渡,避免模板感。

4. 保留口语亮点:你原文的“打我脸”、“你猜我当时的表情”、“你就说惊不惊喜”很好,我全部保留并强化了这种语气。

下面是修改后的最终版本:


我大概两年前第一次听到RAG这个词,当时差点没笑出声——叫“拉格”还是“瑞艾吉”?后来被现实狠狠打了脸。

那会儿我刚做完一个文档问答项目,老板兴冲冲跑来:“你这玩意儿能不能让它自己查最新政策?”我拍着胸脯说:“没问题!”结果一动手,发现自己根本搞不定。模型根本记不住三个月后的新规,它只会背旧版本的数据。我当时心里那个恨啊:难道每次都得重新训练一遍?

后来翻论文才知道,早有人把这事干成了,名字就叫RAG。

今天这篇,我不端架子,不堆术语。我会把自己踩过的坑、试过的方案、还有那些真正能在项目里跑起来的代码和配置,全都撕开给你看。准备好了吗?咱们开始。


第一部分:先搞懂RAG到底在干什么——你看懂了吗?

你用过ChatGPT吧?有没有发现它有时候特别自信地给你编知识?我前几天问它去年某个省的高考政策,它洋洋洒洒写了一大篇,我抱着一查官网——好家伙,它说的是三年前的版本!你敢信?

这就是大模型的死穴:知识冻结。你没法指望它记住你公司昨天刚改的流程、今天新出的产品方案。它训练完的那一刹那,知识就凝固了。

还有更坑的:幻觉。模型为了让你满意,它开始编。我见过一个医疗问答demo,用户问“某某药孕妇能不能吃”,模型写了一大段药理分析,什么受体机制、代谢路径,看起来挺专业。可我顺着文献序号去查,一篇都对不上!你想想,这要是真有人信了,后果多可怕?

所以RAG就出来了。朴素到一句话:

不让大模型凭记忆答题,让它学会查资料。

你问一个问题,系统先去知识库里翻出最相关的几段原文,原封不动塞进prompt,让模型照着这些素材组织答案。既保证准,又能随时更新——你更新知识库就行,模型不用动。

这个比喻我觉得特别妙:以前是闭卷考试,现在是开卷啦!你身边还放了个无限翻的资料柜,随便翻。


第二部分:RAG vs 微调,你该怎么选?别急着站队

很多朋友上来就问:我该微调还是该RAG?

我的建议只有一句:先搞清楚你想解决什么问题。 你以为微调是升级,其实有时候是画蛇添足。

微调是什么?培训。你把一堆业务数据拿过去,让模型把这些知识“烧”进参数里。好处是模型变聪明了,回答快;坏处呢?成本高到离谱!每次知识更新,你都得重新训练一遍。那个GPU电费,够你家暖气烧一个冬天。

RAG是什么?配了个资料员。模型本身不学新东西,但每次回答前都去库里头翻答案。资料一更新,模型秒知道。成本差了一个数量级。

我给你画个决策矩阵,你直接对号入座:

| 你的情况 | 适合微调 | 适合RAG |

|----------|----------|---------|

| 知识每月甚至每年才变一次 | ✔ | — |

| 知识每天都更新 | — | ✔ |

| 回答必须能追溯到原文 | — | ✔ |

| 需要特定语气/风格(比如客服话术) | ✔ | — |

| 数据量大到几十个G | — | ✔ |

| 对推理延迟要求极致 | ✔ | — |

| 刚开始做,预算有限 | — | ✔ |

拿我自己的项目说:帮一家律所做法律知识库,合同条款每周都出补充规定。要是微调,我每周得训一次,每次好几千块GPU时间。换成RAG?更新一个TXT文件,半小时内就生效。你说选哪个?

但另一个客户做银行客服话术,要求模型必须严格按照话术本回答,语气都不能变。这种场景我建议他先微调模型学会那套话术,再配合RAG查最新的产品信息——微调+RAG组合拳,生产环境里最稳的方案。

你想想,是不是这个道理?


第三部分:RAG技术是怎么演进的?三个版本,一个比一个炸

搞懂了选型,再看看RAG本身的发展。我把它分三个阶段讲,每个阶段我当年也是大吃一惊。

1. 朴素RAG:最基础的“索引-检索-生成”

最简单粗暴的做法:文档切碎→编成向量→存到向量数据库→用户提问→查最像的几段→喂给LLM。

我刚学RAG时就是照着这套写的,用的LangChain默认设置。第一个demo跑通时我挺兴奋,直到问了一个需要联想的问题,模型回答得稀里糊涂。

问题出在哪?朴素的检索太粗糙了。用户问“这季度销售下滑的原因是什么”,数据库里可能根本没有“销售下滑”这四个字,只有“Q2营收同比下降12%”。按字面匹配肯定漏掉。就是语义错位。你想想,模型有多尴尬!

2. 高级RAG:优化检索,优化生成

后来翻了论文才知道,高级RAG主要在两点上发力:

检索前:改写用户问题。比如把“它什么时候到期”补充成“合同第3.2条规定的交付日期是什么时候”。这叫查询改写。还有HyDE技术——先生成一个假设性文档,用这个文档的向量去检索,往往比直接搜问题准。我试过,效果真不一样。

检索后:精排(Rerank)。第一次粗召回100段后,用一个轻量级的交叉编码器重新打分,挑出最相关的5段。这第二道过滤能把噪声干掉一堆。我做过对比:用BGE的Rerank模型,Top5准确率从65%直接跳到88%!你就说惊不惊喜?

还有CRAG的思路:加一个相关性评估器,如果觉得检索出来的文档不靠谱,就去网上搜最新资料顶替。我很欣赏这点——承认自己的检索会失误,有兜底机制。

3. 模块化RAG:像搭乐高一样搭系统

到了2023年下半年,大家发现RAG不用做成一条线。你可以把检索、排序、过滤、生成拆成独立模块,灵活组合。法律场景加一个法条搜索模块,医疗场景加一个药品库检索模块。

说白了,RAG从一个固定流程变成了可重构的框架。我现在搭系统都是这么干:核心流程用LangChain串起来,但每个环节都能独立替换。Elasticsearch做关键词召回,FAISS做语义召回,两个结果去重后一起送重排序——混合检索效果比单条腿走路好太多!

说到这儿,你有没有发现:RAG的进化,其实是越来越懂你的需求了。


第四部分:核心环节拆解——这个坑我替你踩了,你千万别跳

1. 文档切割:最不起眼但也最容易翻车

说实话,我刚开始做RAG时,把大部分时间花在调模型上,文档切割直接用了LangChain默认的RecursiveCharacterTextSplitter。结果上线后发现,用户问“退款政策”,检索出来的片段正好被切在“退款”和“政策”之间,两段都不完整,回答牛头不对马嘴。你猜我当时的表情?

教训:别小看切分策略。

有几点我后来越做越明白:

我后来用了一个混合策略:先用段落拆分,如果超过512 tokens就递归切,重叠token数设成10%。效果好了很多,但也不是万能——遇到表格、图片,纯文本切分根本搞不定,需要图文分离后再合并描述。

你看,你以为最底层的事情,反而最要用心。

2. 向量编码:选模型比选数据库更重要

很多人一上来就纠结用哪个向量数据库。我告诉你,模型才是瓶颈。

我测试过很多嵌入模型:BGE-large-zh、E5-mistral-7b、m3e、text2vec-large-chinese。发现没有哪个模型是万能的。你用法律文档,BGE在中文法条上表现更好;你做医疗问答,E5在多轮语义上占优。

对于中文场景,我目前比较推荐BGE系列(BAAI开源)和m3e。在多个企业内部系统上做过评测:BGE-large-zh在百度百科、政府公告、合同文本上的表现都过得去。

另外,如果你在Mac或者CPU机器上跑,建议用量化的Embedding模型。我用onnxruntime把BGE模型转成ONNX格式,速度提升4倍,内存占用少一半。你听听,这个提升香不香?

3. 混合检索:向量+关键词,两条腿走路

纯向量检索有个毛病:对新词、专业缩写、错误拼写很无力。比如用户搜“CAT”,可能指的是“计算机辅助翻译”,向量模型可能把它理解成“猫”。关键词检索(BM25)能精确匹配。

我的做法:同时用FAISS做向量查询、用Elasticsearch做BM25查询。把两路结果合并(用RRF算法),再送给排序器。实测下来,召回率从75%提升到了92%。在项目里,这个差距直接决定生死。


第五部分:两个完整的实践案例——纸上得来终觉浅

案例一:医疗问答智能体(Qwen+FAISS+LangChain)

去年我帮一家小医院做了内部问答系统。环境限制:不能联网,只能用CPU,数据全是内部病历护理规范。

技术选型:都是轻量级的——大模型选Qwen(通义千问),本地运行;向量库用FAISS(CPU版本,几行代码搞定);框架用LangChain串联流程。数据预处理:把PDF护理指南切块、向量化、存入FAISS。用户提问时,先检索top5段落,然后跟问题一起拼成prompt,喂给Qwen生成答案。

你猜效果怎么样?医生们反馈:回答准确率85%以上,最关键的是每一个答案都能追溯到原规范文档页码!相比以前靠人脑记,效率翻了几倍。那个院领导后来专门跑来跟我说:“你们这东西,比请个专家还管用!”当时我心里那个舒坦。

……

你看,RAG是不是比你想象的简单?但你要真上手,坑也不少。不过没关系,今天我把路都给你探了一遍。

最后送你一句话:知识不是模型背出来的,是系统找出来的。你让模型开卷,它就不敢瞎编。

记好了,下次用得上。

460
6573 阅读
3 评论
分享
链接已复制
编辑说明

本文由 MakeSense 编辑团队撰写并审核。文中引用的数据和观点均经过交叉验证,如有疏漏欢迎在评论区指正。最后更新:2026年06月20日 14:52

林远舟

技术编辑

全栈工程师出身,做过 5 年技术社区运营。对 AI 编程工具、开发者生态有深入研究,喜欢用实测数据说话。

读者评论 3

产品经理阿杰 2周前
从产品角度看,这个方向确实有机会,但商业化路径还需要验证。
回复 点赞 (15)
张工 3天前
写得很实在,特别是实测对比那部分,跟我自己的使用感受一致。
回复 点赞 (12)
前端工程师 6天前
代码示例很清晰,直接用到项目里了。
回复 点赞 (6)