自以为92%的召回率很高，结果跑自己的文档站才拿了65%

写搜索引擎的人最容易掉进一个坑：拿着实验室里跑出来的漂亮数据去骗自己。我最近看到一个非常有意思的实战案例，开发者在发布 chops-search 时，号称 recall@1（首位召回率）能达到 92%，结果当他真正把这套引擎接入到自己的文档站点，并加入 CI 自动化测试门禁后，真实的评估结果只有 65%。

这种“理想与现实”的落差其实非常经典，也非常值得我们这些在折腾 RAG 或者搜索工作流的人复盘。

为什么文档站是搜索引擎的“屠宰场”

很多人觉得文档结构清晰、内容规整，应该是搜索最容易跑通的场景。但作者的实测证明，文档站其实是一个极其“敌对”的语料库。

• 语料规模小但密度极高： 只有 19 个页面，132 个数据块，但关键词密度极大。
• 结构化陷阱： 采用 Diátaxis 结构编写的文档，逻辑极其严密，这意味着查询词（Query）和文档内容之间的语义匹配非常微妙，一旦权重稍微偏一点，排名就会瞬间崩塌。
• 测试集的动态变化： 作者在实验过程中，测试集从 23 个 case 扩充到了 46 个，这导致你不能简单地用百分比对比前后性能，必须看具体的“通过案例数”。

那些看起来在进步、实则在“造假”的调优

最硬核的发现是，作者尝试了四种不同的排名杠杆（Ranking Levers），结果发现：每一次提升召回率的操作，本质上都是在改变“证据”本身，而不是在优化“排序逻辑”。

我把他的实测过程整理了一下，大家可以对比看下这种“虚假繁荣”：

• 基准线（Baseline）： 23 个 case，65% 召回率。
• 引入 BM25F 算法： 召回率直接飙升到 83%。看起来很牛对吧？但作者随后扩大了测试规模，用更难的 46 个 case 去测，召回率立刻跌到了 76%。
• 加入描述字段（Descriptions）作为关键词： 召回率又回升到 80%。
• 回归真实配置（Honest Configuration）： 当他把所有参数调回到实际部署时，召回率竟然掉到了 74%。

这里面有一个非常深刻的坑：如果你在评估时为了刷高分，人为调高了一个极低的阈值（比如设置了一个不符合实际生产环境的 min_cos 0.34），你得到的可能只是“测量债”（Measurement Debt）。那些在极端配置下才有的高分，在真实场景里根本跑不出来。

几点实战启示

这个案例给正在做搜索或 RAG 系统的同学提了个醒：

1. 别迷信单一指标： recall@1 很高不代表真的好用，一定要结合测试集的覆盖度和实际业务场景的分布。
2. 警惕“配置陷阱”： 如果你的评估指标是在一个 nobody runs（没人会用的）配置下跑出来的，那这个门禁（Gate）不是在帮你保质量，而是在帮你刷分数。
3. 重视证据质量： 优化排序算法（Reweighting）往往不如增加有效信息（Evidence changes）来得直接。

如果你也在做搜索相关的工程化落地，建议一定要建立一套跟生产环境参数完全对齐的 Eval 流程，否则你跑出来的曲线可能只是在自我感动。