我解决Rag知识库召回不准的过程

起因是群里一句"搜不到"

知识库上线第一周，业务方在群里说"搜不到"。紧接着两个建议：换 embedding 模型、再灌一批文档。我盯着这两条看了半天，都没动手——太贵了，而且我怀疑不对症。

我换了个便宜的做法：建一个一次性的小知识库，一份四行文档，同一个问题换三种问法各搜一次，看分数。文档我故意写了个坑：全文只用"忠诚度点数"，一次都不出现"积分"。因为用户嘴里说的和文档里写的，经常不是同一个词。10 月 27 号，我在阿里云百炼命令行上把这件事跑完了。

建库很快，墙来得更快

上传文档、建库等导入、建检索服务，三条命令的事。装命令行在CLI 安装页，Key 在控制台密钥管理页领。建库那一刻有两个旋钮就定死了：分块大小默认 600 字，嵌入模型默认 text-embedding-v4。

墙在服务建好之后：draft 态、beta 版本，直接检索报错，说缺一个 rerank 阈值字段；我补上再检索，又报缺另一个 top-k 字段。同一个状态码、同一个参数无效，一次只报一个。建服务的帮助里明明写着"其余设置用服务端默认"，可草稿配置里这俩字段根本没填，检索那边却非要它们存在。

绕法也不复杂：把服务配置读出来，给知识库那一段补上这两个字段，再整体回写。回写成功，附带两条"未知字段原样透传"的警告。卡在这儿的人很多会以为是自己库建错了，其实不是，是草稿态的默认值没填全。

三个分数，一条 chunk

补完字段，三种问法：问"会员积分怎么算"，0.49；问"忠诚度点数怎么算"，0.86；问"满多少点可以换中杯手冲"，0.95。三次都在一秒上下，而且返回的是同一条 chunk。

这组数让我踏实的地方在于：同义词不是没召回（0.49 不是零），是分数被词面不命中压低了；三组同一条 chunk 说明差别不在"召回了哪块"，在"这块被打了几分"。所以那种"调大 top-k 就能搜到"的直觉，在这个 case 里是无效的——块就一个，top-k 调上天也就那一个。

再看 chunk，排除一个常见嫌疑人

召回不准第二大原因是答案被切在两个块边界上。我查了 chunk 列表：一共一条，整篇文档就在一个块里（文档比默认 600 字短，没切）。分块边界这个嫌疑人当场排除。

这一步是排除法，值钱就在"排除"两个字：如果 chunk 有好几条且答案跨块，该动的是建库时的分块大小、得重建；如果只有一条且内容完整，就别浪费一轮重建去追一个已经洗清嫌疑的人。

阈值和分数是一套系统

库里的 rerank 阈值是 0.01，所以三组全过。但我把它提到 0.5 一想：同义词那组 0.49 就被滤掉了。用户看到的是"搜不到"，而检索其实召回了，只是被阈值挡在门外。

这就是我这天最大的收获："召回不准"和"召回不到"是两种病。前者是分数低但还在阈值上（相关，只是难看）；后者是分数低于阈值被滤掉（其实召回过）。区分它们不需要换模型，只需要把分数和阈值放一起看，两条只读命令。

对了，删库那步别省。我这回建的一文档一库一服务，测完就删，删完还去列表里复核了一遍名字消失、总数回落。临时诊断的东西最容易变成常驻的账，删和复核这两下，是让整个实验真的"临时"的关键。

还有个习惯是这天养成的：跑完三组探针把分数和阈值一起截个图存下来。下次谁改了语料或者动了阈值，复跑一遍对照，哪个档位掉队一目了然。比"感觉最近搜得不准"靠谱太多，而且成本就是三次检索。

后来我把这四步抄成了一页排障手册贴在组里：先跑三组探针问法看分数档位，再 chunk list 看块数和边界，再把阈值贴到分数旁边问"它会滤掉谁"，再改措辞，最后才轮到换模型。每步都是只读或者一次性资源，错了不心疼。手册最大的好处是把"老人口传"变成"新人照走"。

还有个观念变化：我以前把阈值当旋钮拧，拧到不投诉为止；现在把它当判据看。0.01 和 0.5 之间，隔着的是"用户能搜到"和"用户搜不到"，而检索其实都召回了。监控里该盯的是最低档分数离阈值还有多远，不是命中率那一个数。

最后才轮到模型和文档

四步走完——分数、chunk、阈值、措辞——如果分数整体偏低、chunk 完整、阈值也合理，那才考虑换 embedding 或补文档。顺序反了的代价是换一次模型要重建库重灌数据；顺序对了，每一步诊断都是只读或者一次性资源，错了也不心疼。

一句诚实话

这是单文档、单 chunk、单次运行的小实验，不是基准测试，我也不评价哪个 embedding 或 rerank 模型好。实验用的库和服务用完就删了，删完复核过净增为零。三个问法都指向同一份四行文档，分数差异只反映词面和语义的距离，不反映别的。

想先在网页上看看知识库长什么样，去阿里云百炼控制台逛逛。终端这条路从建库到拿到三组分数，命令耗时加起来几秒；贵的那部分从来不是命令，是知道先看哪两个数。