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%重叠，闭眼用就行。

先跑个Recall@K的基准值出来，再谈优化。

换了切分策略，涨个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和Recall@K。

尤其要单独盯一下精确匹配类的问题，召回率是不是明显拉胯。

要是差很多，别死磕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切得特别小，比如才200token，BM25在上面效果会很差。

词频统计在短文本上根本不准，噪声特别大。

怎么办？BM25按整篇文档建索引，向量检索按chunk来。

BM25管大范围捞文档，向量检索管细粒度找片段，各司其职。

别死磕都在chunk级别做，灵活点。

3.5 怎么验证

对比纯向量和混合检索的Recall@50和MRR。

要是MRR没涨，说明BM25没起作用。

要么是k值不对，要么是BM25分数噪声太大，挨个排查就行。

别加了就当完事了，不测一下你都不知道自己加了个寂寞。

4 重排序：不是万能药

4.1 前置条件不满足，越用越拉胯

Reranker听着就高级，交叉编码器，逐对打分，精度碾压embedding。

正常情况下，能给nDCG@10涨5到15个点。

但有个大前提：你第一阶段的召回率得够高。

有人不管三七二十一，先买个商业reranker API用上，一个月大几百美元花着。

结果上线之后，效果不升反降，延迟还涨了一截。

为啥？召回率太低了，正确答案根本没进候选池。

你给reranker一堆歪瓜裂枣，它再能排，也排不出正确答案啊。

就像选秀，海选就把实力派都刷下去了，决赛你再怎么评，也选不出冠军。

4.2 真实翻车案例

真有团队踩过这个坑，花四百刀一个月买reranker服务，结果nDCG不升反降。

查来查去，发现第一阶段Recall@50才0.61。

一百个正确答案，三十九个连候选池都没进去，reranker巧妇难为无米之炊啊。

后来人家先优化切分，召回率干到0.78，再开reranker，直接干到0.87。

钱还省了，一个月就花三十刀。

你看，顺序错了，全是白费功夫。

4.3 什么时候别着急用

给你个经验值：Recall@50没到0.8到0.9这个区间，别优先搞reranker。

先把上游修好。

召回率太低的时候，reranker效果忽上忽下，有时候涨有时候跌，纯纯薛定谔的优化。

等召回率上来了，它的增益才是稳的。

具体拐点你自己测，但大方向错不了。

要是预算有限，开源的BGE、Qwen的重排序模型都很香，Apache协议，商用也没顾虑。

大部分场景完全能替代商业API，省下来的钱喝奶茶不好吗。

4.4 怎么验证

测之前先确认召回率到没到拐点。

到了，再对比加和不加的nDCG@10。

没到？先回去优化检索去。

别本末倒置。

5 Query改写：锦上添花而已

5.1 常见方案盘点

Query改写是很多人眼里的黑科技，其实投入产出比最没谱。

常见的几种，按成本从低到高排：

HyDE，让大模型先编一段假想答案，再用这段去检索，花一次大模型调用的钱。

退阶提问，把具体问题往宽泛了提，两个问题一起搜，也是一次调用。

多query生成，整三五个不同角度的问题，分别搜再合并，成本直接翻好几倍。

5.2 别迷信复杂方案

HyDE在短问题、术语多的场景确实好用，用户就输俩关键词，生成一段完整内容再搜，准度立马上去。

但别觉得越复杂越好用。

很多团队试了一圈花里胡哨的改写方案，最后发现最简单的同义改写就够用。

复杂方案啥额外提升都没有，光增加成本和延迟。

还有研究发现，多query那点增益，经过重排序和截断之后，实际部署里几乎就没了。

折腾半天，竹篮打水一场空。

5.3 正确打开方式

别上来就给所有query都加改写。

先跑基线，基线效果已经不错的话，改写带来的提升非常有限。

只有当你发现某类问题召回率特别低，比如用户输入特别短、关键词模糊，再针对性加改写。

而且要做自适应触发，初始检索置信度够高，直接返回就行。

置信度低了再启动改写，能省不少钱和时间。

啥query都改写，纯属有钱没地方花。

5.4 怎么验证

对比加和不加的MRR，同时盯紧延迟。

MRR涨不到2%，就别搞了。

为了这点提升，加复杂度加成本，不值得。

工程上讲究个投入产出比，不是功能越多越好。

6 调优的本质

6.1 先修上游，再动下游

核心原则第一条：先修上游，再动下游。

切分的问题别指望embedding补，召回的问题别靠重排序遮。

每个环节都有对应的指标：Recall@K看检索好不好，nDCG看排序好不好，MRR看query理解好不好。

跳过检查直接往下游走，就是掩耳盗铃，问题迟早要爆。

当然也不是死规矩，你指标明确指向下游有问题，那直接修下游也没问题。

但大部分人，都是上游烂得一塌糊涂，天天在下游瞎折腾。

6.2 用数据说话，别瞎猜

第二条：测量，不要猜测。

每次改东西，都要有前后对比数据。

换切分、换模型、加混合检索、加重排、加改写，每一步都要测。

没有数据支撑的优化，本质上就是瞎蒙。

蒙对了是运气，蒙错了是常态。

别自我感动式优化，熬半宿调参数，最后啥效果没有，图啥呢。

6.3 简单的往往最好用

第三条：简单方案往往胜过复杂方案。

就像混合检索的权重，很多人调得头秃，其实上游搞好了，简单的RRF融合就够用。

越复杂的方案，理解成本越高，维护起来越麻烦，出问题排查都找不到根因。

做工程不是炫技，稳、准、省，才是硬道理。

RAG调优这事儿，没有什么一劳永逸的最优参数。

说白了就是搭一套反馈循环，每次都比上一次好一点。

那些把效果做上去的团队，不是找到了什么神奇参数，而是建立了一套发现问题、定位问题、验证修复的流程。

这套流程，比任何单个技巧都值钱。

毕竟，靠运气调出来的参数，迟早会靠实力跌回去。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01