我试了一下 Ettin Reranker，和 BGE-Reranker-v2-m3 比到底差多少？

上周我们 RAG pipeline 的召回质量一直上不去top-10 的 hit rate 卡在 0.78 左右老板说你那个检索能不能再准一点。我之前一直用的 BGE-Reranker-v2-m3想着要不要换个 reranker 试试。4 月 22 号刷 HuggingFace 看到 Ettin Reranker 家族发布了号称在 BEIR 上刷了不少新高我就花了两天时间做了个对比测试。直接回答标题问题Ettin RerankerLarge 版本在 NDCG10 上比 BGE-Reranker-v2-m3 高出约 2.8 个百分点但延迟几乎翻倍单条 query20 passages 从 38ms 涨到 71ms显存占用也从 ~1.8GB 涨到 ~4.2GB。如果你的场景对精度极度敏感且硬件预算够Ettin 值得一试如果你在 T4 这种卡上跑、或者对延迟有硬要求50msBGE-v2-m3 依然是更稳的选择。为什么 Reranker 选型这么重要RAG 的检索分两阶段大家都知道——先用 embedding 做粗召回top-100再用 reranker 做精排top-10。reranker 的质量直接决定了最终喂给 LLM 的上下文是不是靠谱的。我之前的 pipeline 是这样的graph LR A[用户 Query] -- B[Embedding 检索 Top-100] B -- C[Reranker 精排 Top-10] C -- D[拼接 Prompt] D -- E[LLM 生成回答]问题出在 C 这一步。BGE-v2-m3 用了大半年了稳定是稳定但在一些长文档、跨语言的 case 上排序经常翻车。比如用户问的是中文但相关文档是英文技术文档BGE 经常把不太相关的中文段落排到前面。测试环境和方法我的测试环境GPU单卡 A1024GBCUDA 12.4数据集从我们业务数据里抽了 500 条 query每条配 20 个候选 passage混合中英文另外跑了 BEIR 的 3 个子集NFCorpus、SciFact、FiQA做标准化对比batch size 统一设 32FP16 推理跑之前先踩了个坑。Ettin 的模型加载方式和 BGE 不太一样直接用sentence-transformers的CrossEncoder会报错ValueError: Ettin models require trust_remote_codeTrue in model_kwargs加上trust_remote_codeTrue就好了但说实话第一次看到这个报错我还以为下错模型了。精度对比Ettin 确实更强但没有碾压在 BEIR 子集上的 NDCG10模型NFCorpusSciFactFiQA平均BGE-Reranker-v2-m30.3810.7420.4210.515Ettin-Reranker-Base0.3890.7560.4390.528Ettin-Reranker-Large0.4020.7710.4510.541平均下来 Ettin-Large 比 BGE-v2-m3 高了 2.6 个点Ettin-Base 高了 1.3 个点。在我们自己的业务数据上中英混合差距更明显一些指标BGE-v2-m3Ettin-LargeHit Rate50.7820.821MRR100.6940.733跨语言 case 正确率0.610.74跨语言场景 Ettin 确实甩开了一截。我猜是训练数据里多语言对齐做得更好但官方没公开训练细节也只是猜测。延迟对比Ettin 慢了不少这是硬伤单条 query 20 passages 的推理延迟P50/P95单位 ms模型P50P95参数量BGE-Reranker-v2-m33852568MEttin-Reranker-Base4563780MEttin-Reranker-Large71941.3BEttin-Large 的 P95 到了 94ms如果你的 RAG 链路本身就有 LLM 生成的延迟比如调 Claude Opus 4.7 一次就是 2-4 秒多这几十毫秒其实无所谓。但如果你是做实时搜索、要求端到端 200ms 以内返回结果的这个差距就很难接受了。显存占用小卡用户请三思FP16 推理时的峰值显存模型显存占用BGE-Reranker-v2-m3~1.8 GBEttin-Reranker-Base~2.6 GBEttin-Reranker-Large~4.2 GB如果你在 T416GB上同时跑 embedding 模型 rerankerBGE-v2-m3 绰绰有余但 Ettin-Large 就得算着来了。我同事在 T4 上跑 Ettin-Large BGE-M3 embedding 的时候 OOM 了一次后来把 batch size 降到 16 才勉强跑起来。我的选型建议折腾了两天我的结论选 Ettin-Large 的场景- 对精度要求极高法律/医疗问答错一条代价很大- 跨语言检索是核心需求- 硬件预算够至少 A10 或以上- 延迟容忍度 100ms继续用 BGE-v2-m3 的场景- 显存紧张T4/4090 单卡还要跑别的东西- 延迟敏感实时搜索、客服机器人- 精度够用就行稳定性优先还有个折中方案Ettin-Base。精度比 BGE 好一点延迟和显存都还可控适合想升级但不想大改架构的情况。一个额外的工程建议如果你的 RAG pipeline 里 LLM 调用那一步本身就是瓶颈比如 Claude Opus 4.7 生成一次要 3 秒那 reranker 多花 30-50ms 根本不是问题精度提升带来的最终回答质量改善远比这点延迟重要。我们团队目前的做法是 reranker 本地推理LLM 调用走 OpenRouter 或者 ofox.io 这类聚合网关——ofox.io 是大模型云厂商官方授权的服务商0% 加价对齐官方价格改个 base_url 就能在 Claude / GPT-5.5 / DeepSeek V4 之间切换不用每家都单独申请 Key。这样 reranker 精排完之后直接把 top-k 结果扔给 LLM整条链路延迟大概在 3.5-4.2 秒其中 reranker 占 70-90msLLM 生成占大头。from openai import OpenAI # reranker 精排完的 top-5 passages 拼成 context client OpenAI(api_keyyour-key, base_urlhttps://api.ofox.io/v1) response client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[ {role: system, content: 基于以下检索结果回答用户问题。}, {role: user, content: fContext:\n{context}\n\nQuestion: {query}} ] )小结Ettin Reranker 是 2026 年目前开源 reranker 里精度最高的一档跨语言场景提升明显。但更好不等于适合所有人——显存和延迟的代价是实打实的。我目前的做法是在对精度要求最高的那条业务线上换了 Ettin-Large其他线还是 BGE-v2-m3等后面 Ettin 出量化版本再考虑全面切换。目前没找到比这个方案更好的平衡点如果有人试过 INT8 量化 Ettin 的效果欢迎评论区告诉我掉了多少精度。