Rerank 重排序为什么重要？

安逸Ai大约 21 分钟RAG大模型100讲检索增强

Rerank 重排序为什么重要？ - 一句话定位

一句话核心：Rerank 是 RAG 系统里的"决赛评委"——在向量检索召回 Top 100 候选之后、LLM 生成答案之前，通过 Cross-Encoder 深度计算 Query-Document 相关性分数，把最相关的 Top 5 文档送进 LLM。它直接决定了最终答案的准确性、Token 成本和幻觉率，是工业级 RAG 从"能用"到"好用"的关键一跃。

核心概念（术语表）

RAG（Retrieval-Augmented Generation）：检索增强生成，先从知识库检索相关文档，再交给 LLM 生成答案，Rerank 是它内部的精排环节。
Embedding 模型（嵌入模型）：把单段文本编码为一个高维向量（如 768/1024 维），通过向量相似度（如余弦）判断语义接近度。
Rerank 模型（重排序模型）：接收 (Query, Document) 对作为整体输入，输出一个标量相关性分数，专为"精排"设计。
Bi-Encoder（双塔模型）：Query 和 Document 各自独立编码为向量，再算相似度。代表：Sentence-BERT、Contriever，文档可预编码，速度极快。
Cross-Encoder（交叉编码器）：Query 和 Document 拼成一个序列一起送入 Transformer（如 BERT），注意力机制在所有 token 之间做深度交互，输出一个分数。精度碾压 Bi-Encoder，但不能预编码文档。
Recall（召回率） vs Precision（精确率）：初始检索追求高召回（少漏文档，K 取 100+）；Rerank 追求高精确（少混噪声，N 取 5）。
FAISS：Meta 开源的向量相似度搜索库，毫秒级从百万级向量中召回 Top K，是 RAG 里"海选"环节的事实标准。
Top K / Top N：向量召回时取 K 个候选（通常 100），Rerank 后再取 N 个（通常 5）交给 LLM，K≫N 是业界典型配比。

阅读全文

## 历史背景 / 来源

Rerank 的理论基础来自 Cross-Encoder 架构，源自 BERT 时代（2018-2019）：研究者发现把两个句子拼接输入 BERT 做 NLI 或 STS 任务，能拿到比 Sentence-BERT 显著更高的相关性分数。行业大规模应用则跟随 RAG 范式起飞，2023 年起 Cohere 推出商业化 Rerank API、智源 BGE 团队开源 BGE-Reranker 系列，让 Rerank 成为 RAG 流水线上的标配环节。主要来源：阿里云开发者社区《构建AI智能体：二十三、RAG超越语义搜索》。

工作原理 / 核心机制（详细讲解）

整体思路：把"找相关文档"拆成两步——先用 Embedding 做高速粗排（海选 100 人），再用 Rerank 做精细重排（专家面试留 5 人），最后只把这 5 份高质量上下文喂给 LLM。

输入与输出：

输入：用户自然语言查询 Query + 一份候选文档 Document。
输出：一个标量相关性分数（通常 0~1 或 0~10，越大越相关），以及按分数降序排列后的文档列表。

核心四步详解：

第一步【Query 预处理与向量化】：清洗 Query（如去掉多余空格、拼写纠正），用 Embedding 模型（如 paraphrase-multilingual-MiniLM-L12-v2）把它编码为一个向量。输入："如何学习钢琴？" → 输出：768 维向量。

第二步【向量召回，海选阶段】：在 FAISS 等向量库中做近似最近邻搜索（ANN），从百万级文档中召回 Top K 个候选。输入：Query 向量 + 100 万文档向量库 → 输出：相似度 Top 100 文档，例如：1. 钢琴保养指南 (0.82) 2. 音乐理论基础 (0.79) 3. 钢琴购买指南 (0.77) …… 共 100 个。这一步追求"宁可错杀一千，不可漏掉一个"，保证召回率。

第三步【Rerank 重排序，核心环节】：把这 100 个文档与 Query 逐一组装成 100 个 (Query, Document) 对，送入 Cross-Encoder（如 BGE-Reranker-large），模型内部通过 Self-Attention 让 Query 的每个 token 与 Document 的每个 token 深度交互，最后取 [CLS] 位的 logits 作为相关性分数。输入：100 个 (Query, Doc) 对 → 输出：100 个分数 → 降序排序 → 取 Top N（如 5）。上面例子经 Rerank 后变成：1. 钢琴入门指法教程 (0.95) 2. 钢琴练习曲目推荐 (0.92) 3. 音乐理论基础 (0.88) 4. 钢琴学习计划制定 (0.85) 5. 钢琴师资选择指南 (0.82)。注意：Rerank 把原本第一名的"钢琴保养指南"直接踢出 Top 5，把原本第七名的"钢琴入门指法教程"顶到第一名。

第四步【LLM 生成】：把精排后的 5 个文档 + Query 组合成 Prompt 喂给 LLM（如 Qwen、GPT），生成最终答案。这一步上下文只有 5 个文档而非 100 个，Token 成本直降 95%，噪声也被过滤到极低水平，幻觉率显著下降。

关键知识点（12 条，每条带数字/事实）

Rerank 在 RAG 流水线中位居第 2 环：位于"向量召回"与"LLM 生成"之间，专职做精排。
典型配比是 K=100 / N=5：初始召回 100 个候选，Rerank 后截断到 5 个，相当于 20:1 的压缩比。
Embedding 输出是"高维向量"，Rerank 输出是"一个标量分数"：维度上的根本差异，决定它们各司其职。
Cross-Encoder 不能预编码文档：每条 Query-Document 对都要重新过一次 Transformer，这是它慢的根本原因。
BGE-Reranker 由北京智源（BAAI）开源：包括 base、large 两档，large 精度更高但更慢，最新是多语言版 bge-reranker-v2-m3。
Cohere Rerank 是商业 API：rerank-multilingual-v3.0 支持多语言，特别适合 BM25 + 向量混合检索后的二次精排。
更大模型 = 更高精度 + 更慢速度：Rerank 模型选型本质是 latency 与 accuracy 的取舍，没有银弹。
Rerank 直接砍掉 95% 的输入 Token：原来送 100 份文档进 LLM，现在只送 5 份，token 成本压到原来的 1/20。
Rerank 能纠正初始检索的"大致对、答不对"：Embedding 召回的"钢琴保养指南"被 Rerank 干掉，因为保养≠学习。
Rerank 是"相关性"专家，不是"语义相似度"专家：相关比相似更窄、更任务导向。
典型幻觉率下降来自上下文噪声减少：把 100 个文档的噪声稀释后喂给 LLM，模型被迫"自己编"的概率大幅下降。
Rerank 不是万能：对"中国首都"这种简单事实查询，Rerank 是杀鸡用牛刀，应跳过；对毫秒级实时响应场景，Cross-Encoder 推理也撑不住。

应用场景（4 个真实例子）

场景 1：苹果公司歧义查询消解 —— 用户问"苹果公司的创始人是谁"，Embedding 召回里同时混进了"苹果公司"和"水果苹果"的文档，经 Rerank 后真正讲史蒂夫·乔布斯、沃兹尼亚克、韦恩 1976 年创业的文档被顶到第一位，水果描述被压到底部，避免 LLM 生成"苹果的创始人是亚当夏娃"式笑话。
场景 2：医疗/法律专业问答 —— Embedding 把"糖尿病胰岛素治疗指南"和"糖尿病饮食科普"都召回了，Rerank 专门优化相关性后，治疗指南被排到前面，LLM 输出可直接用于临床参考，幻觉率显著低于单阶段 Embedding。
场景 3：电商商品检索 —— 用户搜"红色 iPhone 15 保护壳"，Embedding 因"红色 iPhone"和"红色保护壳"两个语义重心被混淆，Rerank 后真正同时出现"红色+iPhone+保护壳"的 doc 被顶到 Top 1，点击率与转化率明显提升。
场景 4：企业知识库 + 大模型助手 —— 公司内部 RAG 系统把 100 份片段塞给 LLM，经常因上下文太长导致关键信息被忽略或遗忘。引入 BGE-Reranker 后只送 Top 5，上下文 Token 减少 80%+，问答准确率显著提升，每条查询成本几乎降至 1/5。

常见误区 / 踩坑（5 条）

❌ 误区 1：Embedding 召回足够好就不需要 Rerank。
✅ 正解：Embedding 优化的是"语义相似度"，不是"查询相关性"，且召回 K 越大噪声越多。没有 Rerank，LLM 会被次相关文档带偏。
❌ 误区 2：Rerank 召回 K 越大越好。
✅ 正解：Cross-Encoder 每条 doc 都要重新推理，K 从 100 涨到 1000，延迟线性增长、收益递减，工业实践 K=50~200 是性价比甜蜜点。
❌ 误区 3：Rerank 模型越大精度越高，所以直接选 large。
✅ 正解：large 在 GPU 上单次推理可达上百毫秒，并发场景直接打爆 QPS；高并发场景多用 base 蒸馏版或 API 版本。
❌ 误区 4：Rerank 能解决所有歧义。
✅ 正解：Rerank 依赖训练数据分布，对极冷门领域（如某型号芯片手册）需要先用领域数据微调，通用 Rerank 会失效。
❌ 误区 5：Rerank 输出的分数可以直接当阈值过滤。
✅ 正解：不同 Rerank 模型的分数分布不一致（Cohere 0~1、BGE 可能给到 ±10），统一业务阈值需要做分数校准（score normalization）。

性能 / 复杂度（数据驱动）

时间复杂度：Cross-Encoder 对 K 个候选做推理近似 O(K × L_doc × L_query × d²)，与候选数和文档长度强相关；Bi-Encoder 召回近似 O(log N)（ANN）。
空间复杂度：Embedding 需缓存全部文档向量 ≈ O(N × d)（N=文档数，d=768 或 1024）；Rerank 不需要额外存储。
典型性能数字：BGE-Reranker-base 在单张 A100 上推理 100 条 200 字文档约 200~400ms；Cohere Rerank v3 API 平均延迟约 250ms；BGE-Reranker-large 比 base 慢约 2~3 倍但精度高 3~5 个百分点。
与替代方案对比：
- 方案 A：纯 Embedding 召回——延迟低（<10ms 单查）、可百万级召回，但 Top-5 准确率较低。
- 方案 B：Embedding + Rerank 二阶段——Top-5 准确率显著提升，但延迟叠加约 200~500ms。
- 方案 C：纯 LLM 排序（让 GPT-4 直接打分）——精度最高，但成本是 BGE-Rerank 的 100~1000 倍，几乎不用于线上。
- 临界点：N<50 万文档且延迟容忍 500ms 以内 → 选方案 B；超大规模或毫秒级响应 → 用方案 A 或仅做轻量蒸馏版 Rerank。
Token 节省：从 100 docs→5 docs，上下文长度通常减少 80%~95%，对应 LLM 调用成本下降约 80%+。

与相关概念的区别（4 对）

vs Embedding 检索：
- 速度：Embedding 极快（毫秒级、百万级召回）；Rerank 较慢（200~500ms、限百级候选）。
- 输出：Embedding 是 768/1024 维向量；Rerank 是 1 个标量分数。
- 精度：Embedding 擅长语义相似度（宽泛）；Rerank 擅长查询相关性（精细）。
- 怎么选：海选用 Embedding，精选用 Rerank，别用错地方。
vs Cross-Encoder 单独使用：
- 场景：纯 Cross-Encoder 无法处理百万级数据（每条 doc 都重算太慢）；Embedding+Rerank 二阶段才是工业方案。
- 怎么选：任何超过 10 万文档的库都必须二阶段。
vs LLM-as-a-Judge（让 GPT 打分）：
- 成本：LLM 打分精度高但费用是 BGE 的 100~1000 倍。
- 延迟：LLM 通常 1~3 秒，BGE 仅 200~400ms。
- 怎么选：离线评估用 LLM 打分，线上推理用专用 Rerank 模型。
vs BM25 / 关键词检索：
- 维度：BM25 看词频统计，对精确关键词匹配强；Rerank 看语义深度交互，对表述差异鲁棒。
- 实践：混合检索（BM25 + Embedding）→ Rerank 是当前最强方案（Cohere Rerank 官方推荐此架构）。

进阶 / 面试加分项

最新进展：LLM-based listwise Rerank（如 RankGPT、RankLLM、智源 BGE-Ranker-v2-miniclm）让 LLM 直接对候选列表整体重排，精度进一步逼近人类判断；ColBERT、ColPali 等 late-interaction 模型尝试在 Bi-Encoder 速度上逼近 Cross-Encoder 精度，是 2024~2025 的研究热点。
业界争议/未解问题：Rerank 是否会被更强大的长上下文 LLM 取代？目前看 128K~1M 上下文模型并未消灭 Rerank，因为 LLM 在长上下文中存在"lost-in-the-middle"现象，Rerank 仍是最经济的精度提升手段。
金句送给候选人："Embedding 决定你能不能找到相关信息，Rerank 决定你找到的是不是真的相关，LLM 决定答案好不好听——RAG 三阶段，缺一不可。"
加分项：能讲清楚 Cross-Encoder 为什么不能预编码（因为 Query 每次不同，Doc 嵌入需要与 Query 联合编码才能捕捉交互信号），是区分初/高级候选人的分水岭。

面试如何回答

🟢 什么是 Rerank？它在 RAG 系统中为什么重要？

回答要点：

Rerank（重排序）是 RAG 系统中位于向量召回与 LLM 生成之间的精排环节，通过 Cross-Encoder 对 (Query, Document) 对计算相关性分数，把最相关的 Top N 文档送进 LLM。

重要性体现在三方面：

提升答案质量：Embedding 召回的是"语义相似"的文档，Rerank 选出的是"真正回答问题"的文档，从源头减少 LLM 幻觉。
降低 Token 成本：典型从 100 docs 压到 5 docs，上下文减少 80%~95%，对应 LLM 调用费用几乎降到 1/5。
增强系统鲁棒：初始检索即便召回了部分噪声文档，Rerank 也能把它们压到尾部。

真实案例：用户问"如何学习钢琴"，Embedding 召回第一是"钢琴保养指南"，Rerank 后真正第一是"钢琴入门指法教程"。

金句："Embedding 决定能不能找到，Rerank 决定找的对不对，LLM 决定答的好不好听。"

加分项：能一句话点透 Cross-Encoder vs Bi-Encoder 的根本区别——前者深度交互精度高但慢，后者独立编码可预编码但精度有限，是面试官最爱追问的点。

🟡 为什么 Embedding 模型不能直接做精排？为什么必须用 Cross-Encoder？

回答要点：

Embedding 模型优化的是"语义相似度"，不是"查询相关性"，两者粒度不同。

三个根本原因：

独立编码失真：Bi-Encoder 把 Query 和 Document 各自编码为向量后再算余弦相似度，过程中 Query 和 Document 的 token 之间没有任何交互，比如"苹果公司创始人"中的"创始人"与文档中"乔布斯创立"无法在向量空间直接对齐，造成语义匹配失真。
精度上限较低：在 BEIR、MS MARCO 等公开榜单上，Bi-Encoder 的 nDCG@10 通常比 Cross-Encoder 低 5~15 个百分点，差距随查询难度增大而扩大。
词汇鸿沟难解：Embedding 难以捕捉"买苹果"和"苹果公司"这种同形歧义，Cross-Encoder 通过 Self-Attention 在所有 token 之间做深度交互，能直接判断"买"这个动词接哪个名词合理。

真实场景：Cohere Rerank 官方文档明确推荐 Hybrid Retrieval（BM25 + Embedding）→ Rerank 三阶段架构，正是因为纯 Embedding 召回有天花板。

金句："Embedding 给你一张城市鸟瞰图，Cross-Encoder 给你一张显微镜下的特写。"

加分项：能补充一句——Cross-Encoder 之所以不能预编码文档，是因为每次 Query 不同，Document 的嵌入需要随 Query 联合编码才能捕获交互信号，这是它慢的根源也是它准的根源。

🟡 Rerank 模型在生产环境怎么选型？BGE-Rerank 和 Cohere Rerank 怎么取舍？

回答要点：

选型本质是精度、延迟、成本、数据合规四者的平衡。

三大主流选项对比：

BGE-Reranker-base/large：智源 BAAI 开源，可本地部署，数据不出域，适合医疗、法律、金融等敏感场景；large 精度高但 GPU 单次推理 200~400ms，并发需 A10/A100 级别显卡。
Cohere Rerank（rerank-multilingual-v3.0）：商业 API，零运维、平均延迟约 250ms，混合检索（BM25+Embedding）后精排效果业界公认 Top；缺点是按调用次数计费、数据出域，且中文场景不如 BGE 精细。
BGE-Reranker-v2-m3：智源最新多语言版，对中英及小语种平衡最好。

真实案例：某电商客服 RAG 系统每天 50 万次查询，先用 BGE-M3 Embedding 召回 Top 100，再调 Cohere Rerank API 压到 Top 5，问答准确率提升约 20 个百分点，单次 LLM 调用成本下降约 80%。

金句："自研求合规，API 求省心，混合跑最大。"

加分项：能聊到最新趋势——LLM-based listwise Rerank（如 RankGPT）让大模型对候选列表整体重排，精度已逼近人类标注，但成本是 BGE 的 50~100 倍，更适合离线评估而非线上推理。

🔴 Rerank 的 Top K 和最终送入 LLM 的 Top N 该如何设置？有什么经验法则？

回答要点：

核心原则：K 决定召回率上限，N 决定 LLM 上下文质量，两者通过"压缩比"耦合。

三档典型配置：

通用 RAG：K=100、N=5，压缩比 20:1，是 LangChain、LlamaIndex 默认推荐的起点。
高精度专业域（医疗/法律）：K=200、N=5~8，召回更广但需要 Rerank 强力过滤，N 略增保证上下文完整。
低延迟实时场景：K=50、N=3，减少 Rerank 推理次数和 Prompt 长度。

关键经验法则：

K 越大 Rerank 收益递减，超过 200 后精度提升 <2 个百分点但延迟线性增长。
N 通常 ≥3，避免 LLM 因上下文过少产生幻觉；N ≤10，否则 Prompt 过长引入"lost-in-the-middle"现象。
监控指标：在 BEIR/MS MARCO 子集上跑网格搜索，选 nDCG@N 与端到端答案质量联合最优 的组合。

真实案例：阿里云百炼平台示例中，初始召回 K=100，经 BGE-Reranker 后输出 Top 5，质量与成本平衡最佳。

金句："K 看召回，N 看上下文，Rerank 看相关性——三段式流水线没有银弹，只有 trade-off。"

加分项：能提到 late-interaction 模型（如 ColBERT）在 Bi-Encoder 速度与 Cross-Encoder 精度之间取得折中，是 2024 年起的研究热点，未来可能取代传统二阶段架构。

🟢 Rerank 一定能提升效果吗？什么场景下应该跳过 Rerank？

回答要点：

不是所有场景都需要 Rerank，盲目引入反而增加延迟和成本。

应跳过 Rerank 的三类场景：

简单事实查询：例如"中国首都""浙江省会"，向量召回 Top 1~3 已确定答案，Rerank 是杀鸡用牛刀，还会增加 200~500ms 延迟。
毫秒级实时响应：例如搜索框自动补全、实时对话流式输出，Cross-Encoder 的推理时间不可接受，应只用 Embedding。
极弱算力环境：纯 CPU 或边缘设备，跑不动 Cross-Encoder，应直接信任 Embedding Top K。

必须用 Rerank 的四类场景（行业共识）：

高精度专业域：医疗、法律、金融——错误答案代价远大于推理成本。
复杂抽象查询：多概念、模糊、长尾的 Query，例如"评估企业 ESG 表现的关键指标"。
关键任务应用：答案准确性直接决定业务成败，如合同审查、临床辅助。
文档质量参差不齐：知识库含大量相似或冗余段落，需要 Rerank 强力去噪。

真实案例：阿里巴巴百炼平台示例中，针对"如何学习钢琴？"这类复杂抽象查询，无 Rerank 时 LLM 输出泛泛而谈，加了 Rerank 后能精确推荐《拜厄钢琴基本教程》、每天 30~60 分钟练习等具体信息。

金句："Rerank 是精度倍增器，不是万灵药——精度要求决定该不该用，延迟预算决定能不能用。"

加分项：能补充——Rerank 还需要冷启动成本，团队没有足够标注数据时，可以先用 Cohere/BGE 通用模型跑通流程，再用领域数据 LoRA 微调，做"通用底座+领域适配"。

🟡 Embedding 模型和 Rerank 模型在架构和工作原理上有什么本质区别？

回答要点：

核心区别：Embedding 是 Bi-Encoder 双塔独立编码，Rerank 是 Cross-Encoder 交叉联合编码。

架构差异详解：

Bi-Encoder（Embedding 用）：Query 和 Document 各自经过同一个或两个编码器，分别得到向量 u 和 v，再用余弦相似度 cos(u,v) 或点积判断相关性。优势：Document 可离线预编码存进向量库，百万级检索毫秒级响应。
Cross-Encoder（Rerank 用）：把 [CLS] Query [SEP] Document [SEP] 整体拼成一个序列送入 Transformer，所有 token 之间做 Self-Attention 深度交互，取 [CLS] 位向量过分类头输出 1 个分数。优势：Query 与 Document 的词元在每一层都能交互，理论上可达相关性判断的精度上限。

关键权衡：Cross-Encoder 不能预编码 Document，每次 Query 都要重新推理 N 条文档，因此 K 必须小（通常 ≤200），这就是为什么必须有 Bi-Encoder 先召回、再 Cross-Encoder 精排的"二阶段"架构。

业界基准：在 BEIR 榜单上，BGE-Reranker-large 比 bge-large-en-v1.5 Embedding 在 nDCG@10 上高出 10~20 个百分点，差距随查询难度增大而扩大。

金句："Bi-Encoder 是望远镜——看得广但模糊；Cross-Encoder 是显微镜——看得窄但锐利；RAG 流水线就是先望远镜再显微镜。"

加分项：能补充 late-interaction 模型（如 ColBERT）尝试在 Bi-Encoder 速度上逼近 Cross-Encoder 精度，是 2024~2025 年学术界最热方向。

🟡 实际项目中如何把 BGE-Reranker 集成到基于 FAISS 的 RAG 流程里？

回答要点：

典型五步集成法，核心是 Embedding 粗排 + BGE-Reranker 精排 + LLM 生成。

第一：准备 Embedding 模型做召回——用 HuggingFaceEmbeddings 加载 paraphrase-multilingual-MiniLM-L12-v2 等模型，把语料编码进 FAISS。

第二：构建知识库文档列表——把每条原始文本包装成 LangChain 的 Document 对象，FAISS.from_documents(docs, embedding_model) 即可构建索引。

第三：粗排召回 Top K——用户 Query 进来后，vector_db.similarity_search(query, k=100) 拿到 100 个候选。

第四：用 BGE-Reranker 精排：
python
from transformers import AutoModelForSequenceClassification, AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("BAAI/bge-reranker-large")
model = AutoModelForSequenceClassification.from_pretrained("BAAI/bge-reranker-large")
pairs = [[query, doc.page_content] for doc in candidates]
inputs = tokenizer(pairs, padding=True, truncation=True, return_tensors="pt", max_length=512)
scores = model(**inputs).logits.view(-1).float().tolist()
reranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)[:5]

最后取分数最高的 Top 5。

第五：组装 Prompt 喂给 LLM——把精排后的 5 段 context 与 Query 组合成 Prompt，调用 Qwen/ChatGLM/GPT 等生成最终答案。

真实案例：阿里巴巴百炼示例中，针对"苹果公司创始人"这类歧义查询，无 Rerank 时 LLM 把苹果水果文档也带进上下文，加了 BGE-Reranker 后只输出真正讲乔布斯、沃兹尼亚克、韦恩 1976 年创业的文档，答案准确率显著提升。

金句："代码层面 Rerank 只有十几行，但价值是把 LLM 幻觉率腰斩。"

加分项：能补充——生产环境建议把 Embedding 和 Rerank 拆成独立微服务（如 NVIDIA NIM、Triton Inference Server），单独扩缩容，避免 Rerank 的 CPU/GPU 峰值抢占 Embedding 服务的算力。

🔴 线上 RAG 系统引入 Rerank 后，延迟、QPS、GPU 资源该怎么规划？

回答要点：

核心约束：Rerank 是 GPU 密集型推理，延迟与 Top K 线性相关，必须做好容量评估。

三大规划维度：

第一：延迟预算——Embedding 召回约 10~50ms，Rerank 推理 100 条 200 字文档在 A10 GPU 上约 150~300ms（base 模型）或 400~700ms（large 模型），LLM 生成 1~3 秒。整体端到端 P99 应控制在 2~3 秒，意味着 Rerank 阶段不能超过 500ms，否则 Prompt 再长一点就超时。

第二：QPS 与 GPU 配置——单张 A10 处理 base 模型约 50~100 QPS，处理 large 模型约 20~40 QPS（按 100 条候选 doc 测算）。如果日均 50 万次查询、峰值 200 QPS：base 模型需要 2~4 张 A10，large 模型需要 5~10 张 A10，并预留 30% 缓冲。

第三：成本优化技巧：

动态 Top K：简单查询降 K 到 50，复杂查询升 K 到 200，可用 Query 分类器判别。
模型蒸馏：用 large 蒸馏 base 或小模型，精度损失 2~3 个百分点但速度提升 2~3 倍。
批处理（Batching）：把同一时刻的多条请求拼成一个 batch 推理，GPU 利用率可从 30% 提到 70%+。
Cohere API 兜底：自建 GPU 集群应对峰值有压力时，可把溢出流量打到 Cohere Rerank API，按调用付费避免资源浪费。

真实案例：某电商客服系统上线 BGE-Reranker-large 后，端到端延迟从 1.2 秒升到 2.5 秒，问答准确率提升 18 个百分点，最终通过 K 降到 80 + 模型蒸馏到 base 把延迟压回 1.8 秒。

金句："Rerank 是 RAG 系统的精度加速器，但加速器自身也得被成本管理。"

加分项：能补充——监控指标必须包含 Rerank 前后 Top N 的 Recall@N 与 NDCG@N，如果精排前后指标几乎无变化，说明业务查询太简单或 Embedding 已足够好，Rerank 是冗余投入。