生产环境精排模型选型与落地指南

一、先给结论

精排模型（Reranker）不负责从整个知识库中找文档，而是对召回阶段给出的少量候选重新计算相关性。它可以纠正向量相似度、关键词匹配和多路融合产生的排序偏差，却无法找回没有进入候选集的答案。

在国内企业知识库和私有化 RAG 场景中，建议先从下面几类模型建立基线：

Qwen3-Reranker-8B 和 Qwen3-VL-Reranker-8B 可以作为质量上限实验，但不应因为参数量更大就直接作为线上默认模型。精排成本近似与“请求数 × 候选数 × 每对输入长度”成正比，大模型会同时放大延迟、显存和并发成本。

一条更贴近生产的默认链路是：

flowchart LR
    Q[用户问题] --> D[稠密向量召回]
    Q --> S[稀疏或关键词召回]
    Q --> R[规则或结构化召回]
    D --> F[多路融合]
    S --> F
    R --> F
    F --> A[权限过滤与版本校验]
    A --> U[去重与候选数封顶]
    U --> X[精排模型]
    X --> V[多样性与业务规则]
    V --> T[阈值与 Top K]
    T --> L[生成模型]

这里有两个关键顺序：

1. 权限过滤应在精排前完成，避免无权内容进入模型、日志和缓存；
2. 精排以后仍可执行去近重复、多样性和时效性规则，相关性分数不是最终业务排序的唯一依据。

二、先澄清几个常见误区

2.1 精排不能弥补召回缺失

如果正确证据没有进入 Top N 候选，精排模型不可能把它排到前面。上线精排前首先要检查 Recall@N，否则很容易把召回、分块或权限过滤的问题误判成模型能力不足。

可以把最终效果近似理解为：

1

端到端效果上限 ≈ 候选集召回率 × 精排正确率 × 生成模型证据利用率

这不是严格数学公式，但能帮助定位瓶颈：精排只改善中间一项。

2.2 Embedding 和 Reranker 不必来自同一系列

Embedding 将查询和文档分别编码，适合在海量向量中快速召回；Cross-Encoder Reranker 同时读取查询和候选，适合做更细致但更昂贵的相关性判断。两者目标不同，不要求品牌或模型家族一致。

例如，生产中完全可以使用 bge-m3 召回，再使用 Qwen3-Reranker-0.6B 精排。最终选择应以同一候选集上的业务评测为准，而不是追求模型名称整齐。

2.3 更换精排模型通常不需要重建向量索引

更换 Embedding 会改变向量空间，通常需要重算文档向量并建立新索引；更换 Reranker 只影响候选集的打分，通常不需要重建召回索引。

但这不代表可以直接覆盖配置。模型版本、提示词、截断方式和分数分布都会变化，必须创建新的精排配置版本，重新评测阈值，并通过灰度切换发布。

2.4 不同模型的分数不能直接比较

有的模型输出未经归一化的 Logit，有的示例会经过 Sigmoid，有的生成式 Reranker 使用 yes 与 no Token 的概率。即使都被映射到 0～1，也不代表 0.8 具有相同含义。

因此：

• 不要把不同模型的原始分数相加；
• 不要沿用旧模型的固定阈值；
• 双模型灰度时优先比较排序指标，或使用业务标注集单独校准；
• 日志同时保留 raw_score、校准版本和最终排名，但不要记录敏感原文。

2.5 最大上下文不是推荐输入长度

模型支持 8K 或 32K，不等于每个候选都应塞入整章文档。超长输入会增加尾延迟，稀释局部证据，并减少单批次可处理的候选数。

生产中通常精排 Child Chunk，再根据命中的 document_id、page_no、标题路径或父子关系取回可阅读的 Parent 内容。长文档需要滑动窗口时，也应明确窗口长度、步长和聚合策略，而不是无条件截取前 N 个 Token。

三、精排模型的主要技术路线

3.1 Encoder-only Cross-Encoder

查询与候选被拼成一对输入，编码后直接输出相关性分数。BGE、GTE、BCE 的常用精排模型属于这一类。

优点是推理链路简单、吞吐相对较高，容易接入统一的 /rerank 服务；缺点是上下文和任务指令能力通常弱于较大的生成式模型。

这一类最适合作为生产基线。很多业务并不需要数十亿参数模型，先验证“增加精排是否真的改善最终答案”比先追求最大模型更重要。

3.2 生成式 Reranker

Qwen3-Reranker 使用因果语言模型判断查询与文档是否相关。官方实现不是让模型生成一段解释，而是读取 yes 和 no 对应 Token 的 Logit，再计算相关概率。

其优势是任务指令、多语言、代码和复杂语义判断能力更强；代价是参数量、显存和单对推理延迟更高。服务端必须固定模板和 Token 判定逻辑，不能让客户端自由拼提示词，也不要使用自由文本生成作为线上打分协议。

3.3 多模态 Reranker

多模态精排会同时理解文本、图片、页面截图或视频片段。它适合处理“哪张图回答了问题”“哪个 PDF 页面包含目标流程图”这类纯文本无法完整表达的相关性。

它不是文本精排的无成本升级：图片解码、视觉 Token、分辨率和视频抽帧都会显著增加计算量。生产上应先通过 OCR 文本、图文向量或元数据召回小规模候选，再调用多模态精排。

3.4 Listwise 和大模型评分

Listwise 方法让模型一次比较多个候选，能利用候选之间的相对关系，但容易受到输入顺序、候选数量和上下文长度影响。通用生成模型直接输出排名还可能产生漏项、重复 ID 或格式错误。

除非业务评测证明有必要，否则不建议把通用大模型 Listwise 排序作为高并发主链路。更稳妥的默认方案仍是逐对打分、统一批处理，再由确定性代码完成排序。

四、国内生产环境常见候选模型

4.1 模型对比

表中的“最大输入”是模型规格，不是推荐生产值。上线前还要核对具体模型 Revision、Tokenizer、推理引擎和显存限制。

4.2 Qwen3-Reranker

Qwen3-Embedding 官方仓库同时发布了 0.6B、4B、8B 三档 Qwen3-Reranker。官方模板如下：

1
2
3

<Instruct>: {task_instruction}
<Query>: {query}
<Document>: {document}

生产接入需要注意：

• 指令属于模型契约的一部分，中文问答、代码检索和跨语言检索应分别评测；
• 官方示例以 yes/no Token 的 Logit 计算相关性，不应改为让模型输出解释文本；
• 虽然模型规格为 32K，官方示例仍使用较小的运行时 max_length，生产值应由吞吐和长文评测决定；
• 先比较 0.6B 与轻量 Cross-Encoder，只有质量增益覆盖成本时再升级到 4B 或 8B。

4.3 BGE Reranker

bge-reranker-v2-m3 官方模型卡将其定位为多语言、轻量且易部署的精排模型。BGE 系列还包括偏中英文的 bge-reranker-base/large，以及能够通过选择层数平衡速度与质量的 bge-reranker-v2-minicpm-layerwise。

生产中不要仅因召回使用 bge-m3 就固定选择同系列精排。应将 bge-reranker-v2-m3 作为稳定基线，再与 Qwen、GTE 或 BCE 使用同一测试集比较。

4.4 GTE Multilingual Reranker

gte-multilingual-reranker-base 官方模型卡给出的规格约为 306M 参数、8192 最大输入和 70+ 语言支持，并提供 Transformers、Infinity 和 Text Embeddings Inference 的接入示例。

它适合多语言、长输入和较高吞吐场景。官方 Transformers 示例使用 trust_remote_code=True，生产环境应固定 Revision，审查远程代码并将模型制品纳入内部镜像，不应在容器启动时拉取不受控的新代码。

4.5 BCE Reranker

bce-reranker-base_v1 官方模型卡给出的规格约为 279M 参数、512 最大输入，支持中文、英文、日文和韩文。它适合 FAQ、制度条款和短 Chunk 场景，也适合作为中文与跨语言检索的低成本对照组。

官方文档给出的候选数和阈值只能作为示例，不能直接复制到所有知识库。512 Token 的输入限制也意味着服务端必须有确定的标题、正文和查询截断策略。

4.6 Jina 等其他模型怎么看

jina-reranker-v2-base-multilingual 可以作为多语言技术基线，但其公开模型卡标注为 CC BY-NC 4.0。企业商业部署必须先完成许可证审查，不能只因为模型可下载就默认可商用。

同理，选任何模型都要同时检查：模型权重许可证、训练或推理代码许可证、是否包含 Remote Code、能否离线分发、依赖是否允许进入企业镜像，以及模型来源和校验和是否可追溯。

五、如何做选型决策

flowchart TD
    A[是否必须理解图片、页面或视频] -->|是| B[多模态候选链路]
    B --> C[先测 Qwen3-VL-Reranker-2B]
    C --> D{2B 是否达到业务指标}
    D -->|是| E[保留 2B]
    D -->|否且资源足够| F[对比 8B 或优化候选与切图]
    A -->|否| G{资源和 SLA 是否严格}
    G -->|是| H[先测 BGE / GTE / BCE]
    G -->|否| I[加入 Qwen3-Reranker-0.6B]
    H --> J{业务难例是否仍明显}
    I --> J
    J -->|否| K[选择吞吐和成本更优者]
    J -->|是| L[对比 Qwen3-Reranker-4B]
    L --> M{增益是否覆盖延迟和成本}
    M -->|是| N[灰度 4B]
    M -->|否| K

选型时至少同时看五个维度：

1. 效果：在真实问题、真实 Chunk 和真实候选分布上的 nDCG@K、MRR@K；
2. 上限：召回阶段的 Recall@N 是否足够，精排后正确证据是否进入 Top K；
3. 性能：P50/P95/P99 延迟、每秒处理 Pair 数、Token 吞吐和最大稳定并发；
4. 稳定性：超时、OOM、坏输入、长尾长度和依赖故障下能否降级；
5. 治理：许可证、离线部署、Revision 固定、审计和数据边界。

公开榜单只能帮助缩小候选范围，不能替代企业自己的评测。通用榜单的语言、负样本、文档长度和标注方式通常与真实知识库不同。

六、候选集应该给多大

6.1 先保证 Recall@N，再优化精排

候选数 N 太小，正确证据进不来；N 太大，则成本、延迟和噪声同时增加。没有一个适用于所有系统的固定值。

可以从 N=50/100/200、最终 K=5/10 组成实验网格，但这些只是工程起点，不是推荐标准。应绘制三条曲线：

• Recall@N 随 N 的变化；
• 精排后 nDCG@K 或 MRR@K 随 N 的变化；
• P95 延迟和 GPU 成本随 N 的变化。

选择继续增加 N 已几乎不改善效果、但计算成本开始明显上升的位置。

6.2 多路召回要控制配额

稠密、稀疏、标题、标签和结构化召回可能返回大量重复内容。进入精排前应：

• 使用 chunk_id 和内容哈希去重；
• 对不同来源设置最低或最高配额，防止单路垄断候选集；
• 使用 RRF 等方法融合排名，不直接混合不可比的原始分数；
• 保留 source_channel 和原始排名，便于离线归因；
• 删除无权限、已删除或内容版本过期的候选。

6.3 先精排 Chunk，再取回上下文

精排对象最好与召回对象一致。对于 Parent-Child 分块，通常让模型判断较短的 Child Chunk，再根据命中的父子关系取回更完整的上下文交给生成模型。

如果把所有 Child 合并成整个 Parent 再精排，可能导致：

• 单个候选输入过长；
• 关键证据被无关段落稀释；
• 长文档天然获得更多匹配机会；
• 排名结果无法精确定位页码和引用片段。

七、设计稳定的精排服务契约

调用方不应直接指定任意模型路径、提示词和阈值。建议由平台维护版本化 rerank_profile，业务只选择经过审批的 Profile。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "request_id": "req-20260811-001",
  "tenant_id": "tenant-a",
  "profile_id": "text-rerank-zh-v3",
  "query": "试用期内解除劳动合同需要哪些材料？",
  "candidates": [
    {
      "candidate_id": "chunk-101",
      "content_revision": "sha256:...",
      "title": "员工关系管理制度",
      "text": "...",
      "source_channel": "dense"
    }
  ],
  "top_n": 10
}

返回值至少应包含：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "request_id": "req-20260811-001",
  "profile_fingerprint": "sha256:...",
  "results": [
    {
      "candidate_id": "chunk-101",
      "raw_score": 3.71,
      "calibrated_score": 0.86,
      "rank": 1,
      "truncated": false
    }
  ],
  "degraded": false
}

Profile 指纹应覆盖：

• 模型 ID、Revision、权重校验和和 Tokenizer；
• 推理引擎及版本、精度或量化方式；
• 指令模板和模板版本；
• 查询、标题、正文的 Token 预算及截断方式；
• 长文窗口和窗口分数聚合策略；
• 原始分数变换及校准版本；
• 候选数、Top K、超时和批处理限制。

这样才能复现实验、定位分数漂移，并在模型升级后准确回滚。

八、输入拼接、截断与长文处理

8.1 固定模板，不让调用方自由拼接

Encoder-only 模型通常接收 (query, passage) Pair；Qwen3-Reranker 则有明确的任务指令、查询和文档模板。模板中的标记、换行、系统提示和任务指令都会影响分数，应由服务端统一管理。

调用方提交结构化字段，网关负责拼接。这样可以避免不同业务团队用同一个模型却产生不兼容的分数分布。

8.2 Token 预算要按字段分配

建议始终完整保留短查询，并按业务重要性拼接候选字段：

1
2
3

文档标题：{title}
章节路径：{section_path}
正文：{chunk_text}

截断应按 Token 而不是字符计算，并记录 truncated=true。对于表格、代码和条款，优先按结构边界切分，避免把一行表格、一段函数或一个编号条款从中间截断。

8.3 长文使用窗口时必须版本化聚合逻辑

如果一个候选必须覆盖长文，可以切成多个窗口分别打分，再聚合为文档分数：

• max 强调“只要有一个片段相关”，但可能被偶然高分放大；
• mean 更稳定，却可能稀释局部关键证据；
• Top-m Mean 介于两者之间，但增加一个需要评测的参数。

窗口长度、步长、最大窗口数和聚合公式必须进入 Profile 指纹。否则同一模型版本也无法复现实验结果。

九、生产性能与容量规划

9.1 用 Pair Token 计算容量

只看“每秒请求数”会低估精排负载。一次查询包含 N 个候选，实际工作量是 N 个 Query-Document Pair；不同 Pair 长度又可能相差几十倍。

容量规划至少记录：

1
2

pair_count = query_count × candidate_count
pair_tokens = Σ token_count(query + candidate + template)

线上监控应同时观察 QPS、Pair/s、Token/s 和长度分位数。

9.2 动态批处理按 Token 封顶

批处理不能只限制请求条数，应同时限制：

• 每批最大请求数；
• 每批最大 Pair 数；
• 每批总 Token；
• 单个 Pair 最大 Token；
• 最大排队时间。

将相近长度的 Pair 分桶可以减少 Padding 浪费。大候选请求还应拆分成子批次，避免一个超长请求阻塞整个队列。

9.3 在线与离线任务隔离

离线评测、历史回放和索引验收会产生大批量请求，不应与在线问答共用没有配额的队列。至少应区分在线与离线队列、并发限制和 GPU 池，保证线上 SLA。

9.4 超时要可降级

精排超时后，安全的默认策略是退回精排前的融合排序，而不是让整个问答失败。降级结果应标记 degraded=true，进入监控和业务分析。

重试必须有次数上限，并释放已占用的批处理槽位。对确定性的 OOM、超长输入和格式错误不应盲目重试。

如果业务对精排不可缺失，应在产品层返回明确的暂时不可用，而不是静默生成低质量答案。降级策略取决于风险等级，法律、医疗或关键操作知识不应与普通 FAQ 使用同一策略。

十、多模态精排怎么落地

Qwen3-VL-Embedding 官方仓库发布了 2B 和 8B 两档 Qwen3-VL-Reranker，查询和候选都可以是文本、图片、截图、视频或混合输入，并通过 yes/no 概率输出相关性分数。

10.1 只处理确实需要视觉理解的候选

典型场景包括：

• 用户按自然语言查找流程图、统计图或产品图片；
• PDF 页面正文相似，但需要根据版面和图表判断相关性；
• 截图中的按钮位置、错误弹窗或界面状态决定答案；
• 视频中需要定位某个动作或画面片段。

纯文本制度、FAQ 和代码检索继续使用文本 Reranker。将所有候选都转成截图只会增加成本并削弱可解释性。

10.2 多模态服务使用资产 ID，不接收任意 URL

推荐请求传递经过授权的 asset_id、页码、区域坐标或时间范围，由媒体网关读取内部对象存储。不要允许模型服务直接访问用户传入的公网 URL。

媒体网关应校验：

• 租户和文档访问权限；
• MIME 类型、文件头和解码结果；
• 图片像素、长宽比、帧数、时长和总字节数；
• 页面、区域或视频片段是否仍对应当前内容 Revision；
• 是否需要去除 EXIF、脚本或其他非必要元数据。

10.3 保留可引用的证据位置

多模态精排结果不能只返回图片分数，还应返回：

• document_id 和 content_revision；
• page_no、bbox 或 timestamp_start/end；
• 对应的 OCR 文本或可读摘要；
• 缩略图资产 ID，而不是永久公开地址。

这样生成模型才能给出可追溯引用，前端也能定位到原页或视频片段。

10.4 独立资源池和预算

视觉 Token 的波动远高于纯文本。多模态精排应独立设置最大像素、每请求图片数、视频帧数、总视觉 Token 和超时，并优先部署在独立队列或 GPU 池，避免拖慢文本问答。

十一、如何建立评测集

11.1 数据必须来自真实流量

评测集应覆盖：

• 高频问题、低频长尾问题和表达不完整的问题；
• 同义改写、缩写、错别字和中英混合查询；
• 表格、代码、条款、时间敏感内容和跨文档问题；
• 看起来相似但不能回答问题的 Hard Negative；
• 没有答案的问题，防止模型总把某个候选判为高相关；
• 多租户、权限和已删除内容边界；
• 多模态场景中的 OCR 可解问题与必须看图的问题。

标注单位应是“这个候选能否为这个问题提供证据”，而不是只看主题是否相似。主题相同但无法支持答案的文档应标成低相关或不相关。

11.2 分层评测指标

精排离线指标提高，不保证最终答案一定提高。可能出现 Top 1 更准，但多样性下降、互补证据消失，导致需要多段证据的问题反而变差。因此必须保留端到端评测。

11.3 公平比较模型

模型对比时应固定：

• 同一批 Query 和候选集；
• 同一个内容 Revision；
• 同一候选数 N 和最终 Top K；
• 明确且可复现的模板与截断策略；
• 同一硬件、推理引擎或至少分别披露环境；
• 预热后再统计吞吐和尾延迟。

先比较“无精排”与“有精排”，再比较不同模型。如果所有模型相对无精排都没有改善，应优先检查标注、召回融合、Chunk 和最终生成链路。

十二、缓存、监控和故障处理

12.1 缓存键必须包含内容版本

精排结果缓存可以降低重复查询成本，但缓存键不能只使用 Query 和 candidate_id。建议至少包含：

1
2
3
4
5
6
7

hash(
  tenant_scope,
  normalized_query,
  candidate_id,
  content_revision,
  rerank_profile_fingerprint
)

权限变化频繁时，要么把授权上下文纳入缓存范围，要么只缓存模型分数并在读取结果前重新做权限校验。无论哪种方式，都不能让缓存绕过 ACL。

12.2 关键监控指标

服务层应监控：

• 请求量、Pair 数、总 Token 和长度分布；
• 排队、预处理、模型推理和后处理耗时；
• P50/P95/P99 延迟和超时率；
• GPU 利用率、显存、水位、OOM 和批次填充率；
• 截断率、降级率、空候选率和坏输入率；
• 模型分数分布、Top 1 与 Top K 分差及跨版本漂移。

业务层应监控答案采纳、引用点击、重新提问、人工转接和错误案例回流。只看 GPU 利用率无法判断精排是否产生业务价值。

12.3 输出校验

服务端必须验证：

• 返回分数数量与输入候选数量一致；
• 每个 candidate_id 唯一且未丢失；
• 分数不是 NaN 或无穷大；
• 排序稳定，相同分数有确定性的次级排序；
• 发生截断、窗口聚合或降级时有明确标记。

十三、安全与权限边界

13.1 ACL 必须早于精排

如果先精排再过滤，未授权内容已经进入模型显存、服务日志、Tracing 和缓存，也浪费了计算资源。因此应在召回融合后立即使用权威权限服务过滤，并校验租户、文档状态和内容 Revision。

如果一次请求处理时间较长或权限可能动态撤销，在结果交给生成模型前还应进行轻量复核。

13.2 候选文档是数据，不是指令

文档中可能包含“忽略之前要求”“调用某工具”等提示注入内容。精排服务只应执行固定相关性判断，不提供工具、网络或任意代码执行能力。

生成式 Reranker 的系统模板要明确把 Query 和 Document 视为待判断数据，并通过固定 Token 概率输出分数。不要把模型生成的解释当成可信控制指令。

13.3 日志最小化

日志默认记录 ID、长度、模型指纹、耗时和分数，不记录完整 Query、文档正文、图片或访问令牌。确需样本回放时，应经过授权、脱敏、加密和有限保留期，并能按租户删除。

十四、发布、灰度与回滚

14.1 模型升级流程

flowchart LR
    A[冻结模型与 Profile] --> B[离线固定候选评测]
    B --> C[容量与故障压测]
    C --> D[Shadow 同候选双打分]
    D --> E[小流量 Canary]
    E --> F[逐步放量]
    F --> G[原子切换默认 Profile]
    G --> H[保留旧 Profile 回滚]

Shadow 阶段应让新旧模型处理同一批候选，比较排名变化、分数分布、延迟和错误，而不是分别使用不同召回结果。不同模型的原始分数不可直接求差后下结论，应比较标注指标、Top K 重合率和排序变化。

14.2 回滚不需要回滚向量索引

只升级 Reranker 时，回滚通常是把默认 Profile 原子切回旧版本。旧模型实例、模板、校准参数和运行镜像需要在观察期内保留。

如果同一次发布还修改了召回模型、分块或索引，就不再是单纯精排升级，必须分别控制召回索引和精排 Profile 的切换，避免多个变量同时变化后无法归因。

14.3 就绪检查必须包含真实推理

容器进程存活不代表模型可用。Readiness 至少要验证权重加载完成、Tokenizer 可用、一次最小 Pair 推理成功，以及 GPU 显存处于预期范围。滚动发布时先预热新实例，再接收流量。

生产服务至少应避免单实例故障，副本数和跨节点策略根据 SLA 决定。量化、推理引擎或 GPU 型号变化也要视作新 Profile 重新压测，因为它们可能改变吞吐，甚至造成微小分数漂移。

十五、生产检查清单

模型与合规

• 模型在真实中文、多语言、代码或多模态数据上完成评测
• 权重、代码和依赖许可证允许目标用途
• 模型 ID、Revision、校验和、Tokenizer 和 Remote Code 已固定
• 模型制品已进入受控内部仓库，不在启动时临时下载

召回与候选

• 已测量 Recall@N，明确精排效果上限
• 多路召回完成去重、配额和稳定融合
• ACL、文档状态和内容 Revision 在精排前校验
• 候选数 N、最终 K 和多样性策略来自实验而非照抄示例

输入与分数

• 模板、指令、截断、窗口和聚合策略已版本化
• 不同模型分数未直接混用，阈值已重新校准
• 长文本、空文本、异常编码、表格和代码已有测试
• 多模态输入限制了像素、帧数、时长和总视觉 Token

性能与可靠性

• 按 Pair/s 和 Token/s 完成目标硬件压测
• 动态批处理同时限制 Pair 数、总 Token 和等待时间
• 在线、离线任务有独立配额或资源池
• 超时、OOM、服务不可用和坏输入有明确降级策略
• Readiness 包含真实推理，实例预热后才接流量

评测与发布

• 同时评估召回层、精排层、生成层和无答案场景
• Shadow 使用同一候选集比较新旧 Profile
• Canary 有业务和系统指标门槛，可自动停止放量
• 旧 Profile 和旧镜像在观察期内可原子回滚
• 日志和缓存不泄露正文，也不能绕过权限

十六、总结

生产环境选择精排模型，核心不是找到一张榜单上的第一名，而是建立一条可评测、可限流、可降级、可追溯的排序链路。

实际落地可以遵循以下顺序：

1. 先证明候选集的 Recall@N 足够；
2. 用 BGE、GTE 或 BCE 建立轻量 Cross-Encoder 基线；
3. 加入 Qwen3-Reranker-0.6B 比较复杂语义收益，再决定是否测试 4B/8B；
4. 只有视觉信息确实决定相关性时，才增加 Qwen3-VL-Reranker 多模态通道；
5. 固定模板、截断、候选数和 Profile 指纹，按 Pair Token 做容量规划；
6. 将权限过滤放在精排前，并准备融合排序降级；
7. 通过固定候选离线评测、Shadow、Canary 和原子切换完成发布。

精排模型更换通常不要求重建向量索引，这是它相对 Embedding 升级更容易灰度的地方；但分数、阈值、性能和行为都会变化，仍然必须把它当作一个完整的生产版本管理。

参考资料

• Qwen3-Embedding / Qwen3-Reranker 官方仓库
• Qwen3-VL-Embedding / Qwen3-VL-Reranker 官方仓库
• BAAI bge-reranker-v2-m3 官方模型卡
• Alibaba-NLP gte-multilingual-reranker-base 官方模型卡
• bce-reranker-base_v1 官方模型卡
• jina-reranker-v2-base-multilingual 模型卡