文章目录前言1 文档切分第一块多米诺骨牌1.1 你看不起的切分比换模型管用1.2 三种经典翻车现场1.3 基线怎么搭要不要优化1.4 语义切分是不是神药2 向量化Embedding不是银弹2.1 两个天生的盲区2.2 模型怎么选2.3 什么时候值得微调2.4 怎么验证3 混合检索召回率的高杠杆3.1 为什么必须加BM253.2 RRF融合和k值的坑3.3 权重分配别死磕3.4 小chunk的注意事项3.5 怎么验证4 重排序不是万能药4.1 前置条件不满足越用越拉胯4.2 真实翻车案例4.3 什么时候别着急用4.4 怎么验证5 Query改写锦上添花而已5.1 常见方案盘点5.2 别迷信复杂方案5.3 正确打开方式5.4 怎么验证6 调优的本质6.1 先修上游再动下游6.2 用数据说话别瞎猜6.3 简单的往往最好用P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01前言很多人做RAG上线之后总遇到一种“沉默的失败”。答案读着行云流水一点卡顿都没有仔细一瞅内容全错。把A产品的定价规则安到B产品头上前半句刚说不支持后半句就教你怎么操作。主打一个逻辑自洽的胡说八道。大部分人碰到这事儿第一反应是调prompt。第二反应换个更大的模型。第三反应更绝加个系统提示词苦口婆心跟模型说“求你了仔细读上下文”。折腾一圈下来该错还是错。为啥病根在检索端你给生成端刮痧有啥用。RAG翻车十次有八次都是检索拉胯只不过穿了件生成流畅的外套骗得你团团转。而检索的坑早在你把文档切分入库那一秒就已经埋好了。1 文档切分第一块多米诺骨牌1.1 你看不起的切分比换模型管用很多人优化RAG上来就冲embedding榜单。挑参数最大的、排名最高的跟买手机只看跑分似的参数不够大就觉得没面子。但很少有人愿意花时间琢磨chunking就好像健身只买装备不练动作纯属本末倒置。英伟达之前做过测试其他条件全不变就换切分策略召回率能差出9个百分点。你花大价钱升级的embedding模型可能还不如换个切分方式涨点多。说出来挺扎心但事实就是这么回事。1.2 三种经典翻车现场切分的核心矛盾就是颗粒度大了小了都出事边界切错了更要命。第一种chunk切太小。一个完整的知识点劈成两半召回只召到下半截前提条件全丢了。就像你看菜谱只看到“下锅炸三分钟”没看到前面“先解冻”出锅直接啃冰碴子。第二种chunk切太大。两千个token塞了仨完全不搭的知识点就因为开头一句话匹配上了全给模型塞进去。模型看着看着就串台了把甲公司的数据安到乙公司头上纯纯张冠李戴。第三种切割边界踩雷。最绝的就是把否定词给切分开上一句结尾是“不”下一句开头是“承担责任”。检索匹配到“承担责任”高高兴兴给你送过来完全没看见前面那个“不”字。这不叫检索这叫反向送分。1.3 基线怎么搭要不要优化别上来就整花活先拿基线跑通全流程。大部分结构化文档递归字符切分512token大小20%重叠闭眼用就行。先跑个RecallK的基准值出来再谈优化。换了切分策略涨个1%到2%那纯属蚊子腿没必要折腾。要是能差出5%以上别犹豫这就是你当前的头号优化目标。1.4 语义切分是不是神药语义切分听着特别高级智能识别语义边界科技感拉满。实际用起来你就知道调参能调到怀疑人生阈值调来调去最后定在92附近的大有人在。而且就算调好了在结构化文档上它也没比按标题层级切分强多少。听我一句劝结构化文档老老实实按标题层级切非结构化的乱文再考虑语义切分。别啥场景都往上套高科技不对症还不如土办法好使。2 向量化Embedding不是银弹2.1 两个天生的盲区embedding把文本映射成语义向量听着很万能其实俩天生的毛病改不了。第一个语义近不等于事实对。“这个药有效”和“这个药无效”意思完全相反向量距离却可能特别近。为啥用词几乎全一样就差一个“不”字。几百维的向量空间里一个字的差别很多模型根本编码不到位。你库里要是有一堆“不支持”“不兼容”的内容纯向量检索在这类问题上召回率天生就低。别硬扛自己测测就知道了。第二个精确标识符抓瞎。用户搜“错误代码E4392”纯向量检索大概率给你返回E4391和E4393。因为语义上太像了模型觉得这不都差不多嘛。但用户要的就是精准的那一条差一个数字都不行。这事儿向量检索天生不擅长别为难它。2.2 模型怎么选MTEB榜单上模型上百个你别啥都看就盯Retrieval子榜就行。别的分类、聚类任务分数再高跟你RAG检索没关系别被带偏。别光看绝对排名算算性价比参数小排名还靠前的才是真香款。0.6B参数排第8和8B参数排第2前者性价比甩后者八条街。咱们做工程的讲究个花小钱办大事。2.3 什么时候值得微调要是你做的是医疗、法律、金融这种领域专业术语堆成山通用模型根本看不懂。那微调确实香有人用金融数据微调gte模型召回率直接快翻倍。但要是你就是普通技术文档、产品说明、FAQ通用模型完全够用。别上来就说我要微调好像不微调显得不够专业似的纯纯浪费算力。先跑基线不行再调步子别迈太大。2.4 怎么验证换模型前后对比Hit Rate和RecallK。尤其要单独盯一下精确匹配类的问题召回率是不是明显拉胯。要是差很多别死磕embedding了赶紧补BM25去。一条路走到黑不如换个思路补短板。3 混合检索召回率的高杠杆3.1 为什么必须加BM25前面说向量检索俩毛病否定词分不清精确码抓不住。怎么治答案特别复古加BM25。BM25靠词频精确匹配搜错误代码这种东西一搜一个准。但它也有缺点同义词、改写句它完全不认。所以这俩天生互补一个管语义一个管精确双打比单打强太多。3.2 RRF融合和k值的坑混合检索最常用的就是RRF融合两边各跑一遍按排名算分合并。这里有个参数k很多人直接用默认60小数据集上直接踩坑。你想想你知识库一共就80份文档k设60前60名的权重几乎没差别。那融合了个啥跟随机排序差不多。小数据集听我的k降到10左右靠前的结果才能有权重优势。默认参数不是万能的得配你的数据规模。3.3 权重分配别死磕很多人调混合检索天天纠结BM25和向量各占多少权重。这事儿本来就难俩分数量纲都不一样BM25从零到十几都有可能余弦相似度就在0到1之间晃。你硬给个固定比例本质上就是瞎蒙。有人搞分数归一化结果归一化还容易放大噪声越调越乱。给你俩靠谱方案第一个先用BM25召回前N个再用交叉编码器精排。干净利落不用纠结分数对齐效果还稳。第二个要是非要加权融合先测召回率涨没涨延迟能不能接受。要是向量检索没给BM25的结果新增任何相关文档那你加它干啥纯纯增加延迟。该删就删别舍不得。3.4 小chunk的注意事项要是你的chunk切得特别小比如才200tokenBM25在上面效果会很差。词频统计在短文本上根本不准噪声特别大。怎么办BM25按整篇文档建索引向量检索按chunk来。BM25管大范围捞文档向量检索管细粒度找片段各司其职。别死磕都在chunk级别做灵活点。3.5 怎么验证对比纯向量和混合检索的Recall50和MRR。要是MRR没涨说明BM25没起作用。要么是k值不对要么是BM25分数噪声太大挨个排查就行。别加了就当完事了不测一下你都不知道自己加了个寂寞。4 重排序不是万能药4.1 前置条件不满足越用越拉胯Reranker听着就高级交叉编码器逐对打分精度碾压embedding。正常情况下能给nDCG10涨5到15个点。但有个大前提你第一阶段的召回率得够高。有人不管三七二十一先买个商业reranker API用上一个月大几百美元花着。结果上线之后效果不升反降延迟还涨了一截。为啥召回率太低了正确答案根本没进候选池。你给reranker一堆歪瓜裂枣它再能排也排不出正确答案啊。就像选秀海选就把实力派都刷下去了决赛你再怎么评也选不出冠军。4.2 真实翻车案例真有团队踩过这个坑花四百刀一个月买reranker服务结果nDCG不升反降。查来查去发现第一阶段Recall50才0.61。一百个正确答案三十九个连候选池都没进去reranker巧妇难为无米之炊啊。后来人家先优化切分召回率干到0.78再开reranker直接干到0.87。钱还省了一个月就花三十刀。你看顺序错了全是白费功夫。4.3 什么时候别着急用给你个经验值Recall50没到0.8到0.9这个区间别优先搞reranker。先把上游修好。召回率太低的时候reranker效果忽上忽下有时候涨有时候跌纯纯薛定谔的优化。等召回率上来了它的增益才是稳的。具体拐点你自己测但大方向错不了。要是预算有限开源的BGE、Qwen的重排序模型都很香Apache协议商用也没顾虑。大部分场景完全能替代商业API省下来的钱喝奶茶不好吗。4.4 怎么验证测之前先确认召回率到没到拐点。到了再对比加和不加的nDCG10。没到先回去优化检索去。别本末倒置。5 Query改写锦上添花而已5.1 常见方案盘点Query改写是很多人眼里的黑科技其实投入产出比最没谱。常见的几种按成本从低到高排HyDE让大模型先编一段假想答案再用这段去检索花一次大模型调用的钱。退阶提问把具体问题往宽泛了提两个问题一起搜也是一次调用。多query生成整三五个不同角度的问题分别搜再合并成本直接翻好几倍。5.2 别迷信复杂方案HyDE在短问题、术语多的场景确实好用用户就输俩关键词生成一段完整内容再搜准度立马上去。但别觉得越复杂越好用。很多团队试了一圈花里胡哨的改写方案最后发现最简单的同义改写就够用。复杂方案啥额外提升都没有光增加成本和延迟。还有研究发现多query那点增益经过重排序和截断之后实际部署里几乎就没了。折腾半天竹篮打水一场空。5.3 正确打开方式别上来就给所有query都加改写。先跑基线基线效果已经不错的话改写带来的提升非常有限。只有当你发现某类问题召回率特别低比如用户输入特别短、关键词模糊再针对性加改写。而且要做自适应触发初始检索置信度够高直接返回就行。置信度低了再启动改写能省不少钱和时间。啥query都改写纯属有钱没地方花。5.4 怎么验证对比加和不加的MRR同时盯紧延迟。MRR涨不到2%就别搞了。为了这点提升加复杂度加成本不值得。工程上讲究个投入产出比不是功能越多越好。6 调优的本质6.1 先修上游再动下游核心原则第一条先修上游再动下游。切分的问题别指望embedding补召回的问题别靠重排序遮。每个环节都有对应的指标RecallK看检索好不好nDCG看排序好不好MRR看query理解好不好。跳过检查直接往下游走就是掩耳盗铃问题迟早要爆。当然也不是死规矩你指标明确指向下游有问题那直接修下游也没问题。但大部分人都是上游烂得一塌糊涂天天在下游瞎折腾。6.2 用数据说话别瞎猜第二条测量不要猜测。每次改东西都要有前后对比数据。换切分、换模型、加混合检索、加重排、加改写每一步都要测。没有数据支撑的优化本质上就是瞎蒙。蒙对了是运气蒙错了是常态。别自我感动式优化熬半宿调参数最后啥效果没有图啥呢。6.3 简单的往往最好用第三条简单方案往往胜过复杂方案。就像混合检索的权重很多人调得头秃其实上游搞好了简单的RRF融合就够用。越复杂的方案理解成本越高维护起来越麻烦出问题排查都找不到根因。做工程不是炫技稳、准、省才是硬道理。RAG调优这事儿没有什么一劳永逸的最优参数。说白了就是搭一套反馈循环每次都比上一次好一点。那些把效果做上去的团队不是找到了什么神奇参数而是建立了一套发现问题、定位问题、验证修复的流程。这套流程比任何单个技巧都值钱。毕竟靠运气调出来的参数迟早会靠实力跌回去。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01
