检索增强生成系统的效果，往往不只取决于向量召回。真正决定哪些材料进入大模型上下文的，是召回之后的重排序环节。Jina Reranker 3.5 以约 6 亿参数实现了一次针对专业领域检索的升级：它在判例法任务上比 v3 提升超过 50%，在法律、医疗和金融基准中缩小了与参数规模大 7 倍模型的差距，并在结构化数据任务上直接超过这些大模型。
更重要的是，它被设计为 v3 的直接替代品，不要求调用方修改 API。这意味着团队可以把升级重点放在灰度验证和质量评估上，而不必重写检索链路。
列表式重排序解决的不是“逐篇打分”
典型 RAG 检索分为两个阶段：召回器先从大规模语料中快速找出几十个候选项，重排序模型再挑出最值得进入上下文的若干结果。
逐项式重排序通常独立判断每个查询与文档的相关性。列表式重排序则把候选结果放在同一个比较环境中，让模型关注文档之间的相对顺序。例如，三个合同条款都提到“终止”，但只有一个同时满足司法辖区、违约条件和日期范围；相对比较比孤立打分更容易拉开差异。
可以把处理过程抽象为：
用户问题
↓
向量或关键词召回 Top 50
↓
列表式 Reranker 重新排序
↓
选择 Top 5
↓
拼接上下文并调用生成模型
这种能力在法律、医疗和金融场景尤其重要。这些语料中充满相似术语，真正的相关性常由多个限定条件共同决定。来源摘要给出的基准结果表明，3.5 的改进并不只是扩大通用模型规模，而是明显作用于专业领域和结构化数据。
6 亿参数的工程价值在哪里
参数量不能直接等同于延迟或成本，但在部署方式、硬件和推理框架相同的前提下，较小模型通常更容易控制显存占用、并发能力和响应时间。Jina Reranker 3.5 与大 7 倍模型之间差距缩小，意味着团队不必默认用更大的模型换取专业检索质量。
结构化数据上的表现也值得注意。企业检索对象并不总是自然语言段落，还可能是账单记录、病例字段、判决元数据或产品表格。将这些记录序列化后，重排序器需要同时理解字段和值之间的关系：
case_id: 2024-0172 | court: Supreme Court | topic: contract termination | decision_date: 2024-06-12
如果模型只能匹配词面，“contract termination”可能占据主要权重；如果它能处理结构关系，法院层级、裁判日期和案件主题就可以共同影响排序。摘要没有披露模型训练与架构细节，因此不能仅凭基准结果推断具体实现，但结构化任务超越更大模型，至少说明参数规模不是该类检索的唯一决定因素。
可以这样实践：用可替换配置接入重排序 API
下面示例假设服务提供常见的 HTTP 重排序接口：请求包含查询、候选文档和模型名，响应返回索引与相关性分数。不同部署的鉴权头、模型标识和响应字段可能不同，运行前应按实际 API 文档调整。代码只使用 Python 标准库，可直接作为迁移验证脚本。
先设置服务地址、密钥和实际模型标识：
export RERANK_ENDPOINT="https://your-rerank-service.example/v1/rerank"
export RERANK_API_KEY="replace-with-your-key"
export RERANK_MODEL="replace-with-your-v3-or-v3.5-model-id"
python rerank_demo.py
rerank_demo.py 内容如下：
import json
import os
import urllib.request
endpoint = os.environ["RERANK_ENDPOINT"]
api_key = os.environ["RERANK_API_KEY"]
model = os.environ["RERANK_MODEL"]
documents = [
"The court dismissed the contract termination claim for lack of jurisdiction.",
"The hospital revised its treatment protocol for postoperative infections.",
"The appellate court upheld termination after a material breach of contract.",
"Quarterly revenue increased while credit-loss provisions remained unchanged.",
]
payload = {
"model": model,
"query": "appellate decision about contract termination after material breach",
"documents": documents,
"top_n": 2,
}
request = urllib.request.Request(
endpoint,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
},
method="POST",
)
with urllib.request.urlopen(request, timeout=30) as response:
result = json.load(response)
for item in result["results"]:
index = item["index"]
score = item.get("relevance_score")
print(f"score={score} document={documents[index]}")
既然 3.5 是 v3 的直接替代品，实际迁移时应尽量只切换服务端部署或模型配置，不修改业务请求结构。这样出现质量或延迟回退时，可以快速切回旧版本。
上线前不要只看平均分
公开基准能说明模型潜力，却不能替代业务数据上的验证。法律、医疗和金融检索还涉及权限、时效性、地域和合规条件，这些约束不一定会被通用相关性分数完整表达。
建议至少检查以下指标：
- 在同一批候选文档上比较 v3 与 3.5 的
Recall@K、MRR或nDCG@K。 - 分开统计自然语言文档与结构化记录，避免平均值掩盖某一类数据的回退。
- 记录 P50、P95 和 P99 延迟，并在真实候选数量下压测。
- 对高风险领域保留规则过滤，例如访问权限、日期范围和司法辖区过滤。
- 检查重排序后的 Top K 是否真的改善最终回答，而不是只提升离线相关性指标。
- 使用影子流量或小比例灰度发布，并保留 v3 的快速回滚配置。
Jina Reranker 3.5 的核心吸引力，不只是 6 亿参数模型在若干榜单上逼近更大的模型，而是它把专业领域质量、结构化数据能力和低迁移成本放在同一次升级中。对于已经使用 v3 的团队，这是一项适合通过配置切换、成对评测和灰度流量验证的升级；对于新系统，则应先确定召回质量和候选规模，再判断重排序器能带来多少真实收益。