上周有个粉丝私信我说他做RAG做了三个月领导问效果怎么样他答不上来。文档塞了几千份进去向量库建好了前端也搭了用户一问回答还是经常驴唇不对马嘴。他怀疑是模型不行想换GPT-4o试试。我看了他的系统问题根本不在模型上。说实话RAG这个方向门槛低但做好难。很多人以为RAG就是文档切块→向量化→检索→拼prompt→丢给大模型流程没错但每一步都有坑。你每一步都做了但每一步都只做了60分最后的效果就是不及格。我把过去一年踩过的坑和帮别人排查的问题总结了一下排在最前面的6个几乎每个RAG效果差的系统都中招了至少3个。先说好这篇文章不聊理论只说实操。你照着检查一遍自己的系统大概率能找到问题。一、分块策略你的chunk_size可能一开始就错了分块是RAG的第一步也是被忽视最严重的一步。大部分人的做法是什么一把刀切所有文档统一切500字overlap 50。简单粗暴然后祈祷效果好。但不同类型的文档最佳分块方式完全不一样。我把常见的几种场景列一下技术文档/操作手册按章节标题切。一个完整的操作步骤不能被切断否则你检索到了第3步打开阀门但丢了第4步确认压力表读数用户问怎么操作回答就是残缺的。用Markdown的标题层级来切比固定字数靠谱得多。合同/规章制度按条款切。一条一款是一个完整的语义单元不要为了凑字数把两条合并。合同的第3条和第4条可能讲的是完全不同的事混在一起检索出来就是噪音。FAQ/问答对一问一答就是一个chunk别拆。这种最简单但也最容易被忽视。有人把100个FAQ拼成一个大文档再切块原本完整的一问一答被切成了两半检索效果直接腰斩。长篇报告/论文可以用语义分块按段落语义边界切但对中文文档来说按自然段落切适当合并相邻短段效果就够用了。别搞太复杂。再说chunk_size。500字不是万能的。我们的实测数据文档类型推荐chunk_sizeoverlap技术手册300-400字50字合同条款200-300字0按条切FAQ不限按条切0研报/论文500-600字100字注意一个细节chunk太小检索准了但上下文不够大模型回答的时候缺信息chunk太大上下文够了但检索精度下降因为一个chunk里混了太多主题。这是个权衡你得根据自己的文档类型调。怎么判断你的分块对不对随机挑20条用户的真实问题看看检索回来的chunk里有没有包含回答所需的完整信息。如果超过5条检索回来的信息是残缺的你的分块策略就有问题。二、向量模型别用通用模型处理专业文档这个坑很深。大部分人用的是bge-large-zh或者text2vec这两个模型在通用场景下确实不错。但你的文档如果是金融、法律、医疗这种专业领域通用向量模型的效果会打折。举个例子。用户问保证期间和诉讼时效的区别如果你的文档里有一个chunk讲的是保证期间届满后保证人不再承担保证责任另一个chunk讲的是诉讼时效届满后债务人可以提出抗辩。通用向量模型可能把这两个chunk的相似度算得很高因为都涉及届满责任这些词但实际上它们讲的是两个法律概念。检索结果混淆大模型回答也会混淆。怎么解决预算够的话用领域微调的向量模型。BAAI发布了bge-large-zh-v1.5支持指令微调你可以用少量标注数据做微调。几十条到几百条高质量的正负样本对效果提升就很明显。预算不够的话至少换一个更强的通用模型。M3E、bge-m3都比老版本的bge好不少。bge-m3还支持多语言和长文本如果你的文档中有英文术语混排推荐用这个。还有一个土办法但很管用在文档前面加一段元数据。比如[文档类型合同条款] [条款编号第3条] [主题保证责任]保证期间届满后保证人不再承担保证责任…这样向量模型在编码的时候能捕捉到这是合同条款、讲的是保证责任这个上下文检索精度会提升一截。三、混合检索纯向量检索的天花板比你想象的低纯向量检索有个硬伤它擅长语义匹配但不擅长精确匹配。什么意思用户问ISO 27001认证需要哪些材料你的文档里有一段ISO 27001信息安全管理体系认证申请材料清单。如果用户问的是27001材料向量检索没问题。但如果用户问的是具体的文件编号GB/T 22080-2016向量检索大概率检索不到因为它在算语义相似度不是在做精确匹配。这种情况在技术文档、法规标准、产品规格书中特别常见。代码、编号、型号、版本号这些精确信息向量检索不灵。解决方案混合检索。具体做法是同时做两路检索一路向量检索用embedding模型算语义相似度一路关键词检索用BM25或Elasticsearch做精确匹配。然后把两路结果做融合排序。融合的方法最常用的是RRFReciprocal Rank Fusion公式不复杂score(d) Σ 1/(k rank_i(d))k一般取60意思是对每一路检索结果排名越靠前的文档得分越高两路加起来就是最终得分。你不用自己写LangChain和LlamaIndex都有现成的实现。实测效果我们在一个制造业知识库上测试纯向量检索的top-5命中率是72%加了BM25混合检索之后提到89%。提升17个百分点代价是多了一个Elasticsearch实例。有人会问那为什么不只用BM25因为BM25搞不定语义匹配。用户问怎么处理机器过热文档里写的是设备温度异常的应对措施BM25一个词都匹配不上向量检索能匹配上。两路互补才是最优解。四、重排序花小钱办大事的优化如果你的RAG系统只做了一轮检索就直接把结果丢给大模型你漏掉了一个性价比极高的优化环节。问题在哪向量检索返回的top-10结果排序不一定准。向量相似度高不等于回答相关度高。有些chunk跟问题在语义上很接近但对回答这个问题没什么帮助。重排序做的事就是把检索回来的top-20或top-30个chunk用一个更精细的模型重新打分排序挑出真正相关的top-5。用什么模型做rerank首选bge-reranker-v2-m3。开源免费中文效果好模型不大560M推理速度可以接受。部署方式跟向量模型差不多用HuggingFace的transformers库几行代码就能跑起来。如果你用的是云服务大部分向量数据库Milvus、Qdrant、Weaviate都内置了rerank功能直接调接口就行。效果到底有多明显还是上面那个制造业知识库加了rerank之后top-5命中率从89%提到94%。提升没有混合检索那么大5个百分点但实现成本低很多基本就是加几行代码的事。性能考量rerank模型比向量检索慢20-30条文档做rerank大概需要200-500ms。如果你对延迟敏感可以只对top-10做rerank不要太多。实际生产环境里用户问一个问题等2-3秒是可以接受的rerank增加的延迟在可容忍范围内。五、Query改写用户不会好好问问题这个环节被忽视得最厉害。你的RAG系统检索效果不好可能不是检索的问题是用户的问题。不是贬低用户是用户提问的方式跟你文档的表述方式不匹配。举几个真实例子用户问那个报表怎么导不出来。你的文档里写的是数据导出功能使用指南。向量相似度不一定高。因为报表导出和数据导出在语义上有关联但不是完全匹配。用户问系统又崩了怎么办。你的文档里写的是服务异常排查流程。“系统崩了和服务异常”意思接近但措辞差得远。用户问上次说的那个方案在哪。你的文档里没有任何一个chunk包含上次说的那个方案这个表述。这个问题你检索什么都是错的。三种Query改写策略1. 同义词扩展把用户的问题扩展一下。“报表导出改成报表导出 数据导出 下载 导出功能”。用一个大模型做扩展就行prompt很简单用户问题{query}请将这个问题扩展为3-5个语义相同但表述不同的变体用于检索。扩展后的多个query分别检索结果合并去重。这个方法简单但有效命中率一般能提升5-10个百分点。2. 历史对话改写如果是多轮对话场景用户的问题可能依赖上下文。用户先问什么是保证期间然后问那诉讼时效呢。第二个问题单独检索是诉讼时效但用户实际想问的是保证期间和诉讼时效的区别。用大模型把多轮对话压缩成一句独立的问题再做检索这个问题就解决了。3. HyDE假设性文档嵌入让大模型先根据用户问题生成一个假设性的回答然后用这个回答去检索。听起来绕但效果出奇地好。因为大模型生成的回答在表述风格上更接近文档的写法向量匹配更准。代价是多一次大模型调用延迟和成本都会增加。适合对准确率要求高但对延迟不敏感的场景。六、召回数量和上下文长度不是越多越好最后一个坑也是最反直觉的一个。很多人觉得既然检索精度不够那就多召回一些。top-5不行就top-10还不行就top-20。把20个chunk全塞进prompt里总有一个是对的。结果呢大模型的回答反而变差了。原因是大模型有中间遗忘的问题。当context很长的时候模型会关注开头和结尾的信息中间的内容容易被忽略。你把20个chunk塞进去排第10-15位的重要信息可能根本没被模型读到。而且召回的越多无关信息也越多。这些噪音会干扰大模型的判断让它分不清哪些信息是相关的、哪些不是。我的建议top-5够用了。经过分块优化、混合检索、rerank之后top-5的准确率应该在90%以上。如果到不了说明前面几个环节还有问题不要靠增加召回数量来弥补。每个chunk如果按500字算5个chunk就是2500字加上用户问题和系统prompt总长度大概3500-4000字。这个长度对大部分大模型来说是很舒服的区间模型能充分理解所有信息。如果你确实需要更多上下文试试这个把top-5做精排后放前面top-6到top-10放后面中间用一个分隔符隔开并在system prompt里告诉模型前面的内容更重要。这样做能让模型优先关注高质量内容同时保留一定的备选信息。检查清单我把这6个优化方向整理成一张检查清单你对照着看一下自己的RAG系统环节检查项常见问题分块策略chunk_size是否匹配文档类型一刀切500字向量模型是否用了领域适配的模型通用模型跑专业文档混合检索是否同时做向量关键词检索纯向量检索漏精确匹配重排序检索后是否有rerank环节直接用向量相似度排序Query改写是否对用户问题做预处理原始query直接检索召回数量top-k是否合理盲目加大k值一张表花10分钟对照检查一下。如果你的系统中了3个以上优化空间很大。如果中了1-2个优化后效果能再提一截。如果全部中了全部做了恭喜你你的RAG系统应该已经跑得不错了。写在最后RAG这个东西入门一天就够了做好得花半年。差别就在这些细节里。大模型选型、向量库选型那些大决策当然重要但真正决定效果好坏的是分块怎么切、检索怎么做、query怎么改这些看起来不起眼的小事。做技术的人容易犯一个毛病重架构轻细节。系统图画得很漂亮但每个环节都是60分最后总分不及格。反过来架构简单一点每个环节做到85分总分反而是优秀。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】