基准测试得分为0？大概率是你的测试环境崩了，而不是模型太烂

很多做 RAG 或 AI Agent 内存模块的朋友在跑 Benchmark 时，如果看到 Baseline 跑出 0 分，第一反应可能是“这个竞品太弱了”或者“我的方案完胜”。但实测经验告诉我：基准分 0 几乎永远意味着你的 Harness（测试框架）出 Bug 了。

分享几个在 RAG 实战中极其隐蔽、但能直接把结果搞砸的坑，以及一套可靠的验证流程。

两个最容易被忽略的测试陷阱

• 上下文预算不对等：

很多开发者习惯对比 top-k。但如果 A 组检索的是 20 条短句子，B 组检索的是 20 个完整会话，即便 k 相同，实际喂给大模型的 Token 数可能差了 10 倍。在这种情况下，B 组表现更好根本不是因为算法强，而是因为它拿到的信息量更多。
避坑指南： 必须在每个准确率指标旁边标注实际的字符数或 Token 数。没有 Budget Parity（预算对等）的对比没有任何意义。

• 被 API 默默吞掉的参数：

这是最恶心的坑。很多 AI SDK 允许你传递未定义的 kwargs 而不报错。比如你以为在设置 limit=10，但 API 实际识别的参数名是 top_k=。结果就是你的配置被静默忽略，模型一直在用默认值跑，而你却在分析为什么调参没效果。
避坑指南： 不要信任任何不报错的参数传递。必须通过结果来反推：把 top_k 从 5 改到 20，如果检索出的结果数量没变，说明你的配置根本没生效。

确保结果可信的三个“质量门”

为了防止被假数据欺骗，建议在部署 RAG 测试工作流时，强制加入这三个检查环节：

一、正向对照组 (Positive Control)
为每组测试设置一个“绝对不能失败”的简单问题（答案就在语料库里）。如果这一项得分低于阈值，直接判定为“环境崩溃”并终止测试，而不是记录为“低分”。这能快速揪出截断 Bug 或鉴权失败。

二、上下文证据上限 (Evidence-in-context Ceiling)
在计算准确率前，先检查正确答案是否真的出现在检索出的 Context 中。如果召回率（Recall）本身就极低，那么无论怎么优化 Prompt 或 Reranker 都是徒劳。

三、参数效能断言 (Parameter-efficacy Assertion)
每当你调整一个参数，必须通过断言验证其行为是否发生了相应变化。如果参数变了但行为没变，说明你的测试框架在配置空转。

这种分层检查的逻辑在于：一旦报错，你能立刻知道是检索层没拿到数据，还是模型层没读懂数据，而不是对着一个 0 分结果在那儿瞎猜。