C# 接入 Rerank v5：重排模型怎么选

向量搜索找到了相关资料，AI 还是答错，问题可能出在「把哪些资料交给模型」这一步。原文讨论的 Cohere Rerank v5，就是在检索和生成之间重新筛选候选内容：Pro 偏重排序质量，Fast 偏重延迟和吞吐，两者都支持用相关性分数过滤结果。

对做知识库、客服助手和搜索型 Agent 的程序员，更有参考价值的是作者提出的处理顺序：先判断有没有足够相关的证据，再决定是否调用聊天模型。不过，推荐阈值、速度差异和成本收益，都还需要自己的数据验证。

搜到了相似内容，为什么还要再排一次

常见的检索增强生成（RAG）流程，会把向量搜索返回的 30 或 50 段内容直接交给聊天模型。问题是，语义相近不等于能够回答问题：询问年付套餐的退款期限，检索结果可能同时包含取消月付、提交退款申请、企业合同条款。

这些内容都谈到了付费，却只有一部分能回答「期限」。

重排器（reranker）同时读取问题和候选文档，为每个候选打分，再按相关性排序。它不负责搜索，也不负责生成答案。向量或关键词检索继续承担召回，聊天模型继续负责回答，中间增加一道证据筛选。

作者给出的例子是：检索返回 40 段，重排后最多保留通过阈值的前 3 段。候选既要排名靠前，也要达到最低相关性要求。

排第一，只能证明它比其他候选更相关，不能证明它足以支持回答。

因此，作者最想优先实现的功能，是没有候选通过阈值时，直接返回「不知道」，跳过聊天模型。这能减少模型根据无关材料拼答案的机会，但不能保证通过筛选的资料一定正确。

Pro 和 Fast 怎么选，分数能不能直接信

按原文引用的 2026 年 10 月 21 日 Foundry 公告，Cohere Rerank v5 已进入 Microsoft Foundry，分为 Pro 和 Fast。模型卡将两者列为预览中的文本分类模型，支持超过 100 种语言，输入包括文本和图像；文章实际展示的只有文本调用。

Pro 面向推理要求高、文档较长或领域较专门的排序任务。Fast 面向低延迟和高吞吐。作者建议，最终答案高度依赖少数证据时优先考虑 Pro；Agent 每个任务要搜索 5 到 10 次，或客服文章匹配量较大时，优先考虑 Fast。

这里没有完整的质量和延迟对照实验，属于选型建议。

更关键的变化是分数校准。接口返回的 relevance_score，希望在不同问题和领域之间保持相近含义。Cohere 建议 Pro 使用 0.50，Fast 使用 0.45 作为过滤起点。

原文引用的预期校准误差（ECE），可以理解为模型分数与实际相关比例之间的偏差。Cohere 报告两个 Rerank 5 模型的 ECE 都约为 0.06；Rerank 4 Pro 在人工判断数据上为 0.38，在 NIST 判断数据上为 0.31。这些都是厂商评测数字。

校准改善，让统一阈值更有依据，却不能把每条 0.7 分结果都当成经过验证的「70% 可用概率」。自己的文档、问题类型和语言分布，仍可能改变实际效果。

作者展示的一次输出中，Pro 耗时 2512 ms，Fast 为 2138 ms。两者都给正确的年付退款条款 0.81 分，最终只保留 1 段；退款申请入口分别得 0.13 和 0.06，月付取消说明分别得 0.06 和 0.05。

这证明了示例如何筛选，不能证明稳定的速度优势。原文也没给出可确认的 Foundry 价格，所以「RAG 中最便宜的质量提升步骤」仍缺少成本对照支撑。

接口怎么接，示例还缺了什么

原文用 .NET 10 控制台项目演示，依赖版本是 Azure.Identity 1.21.0，以及两个 Microsoft.Extensions.Configuration 包的 10.0.12，目标框架为 net10.0。

下面这些命令创建项目并准备配置读取：

dotnet new console -n Cohere-Rerank-v5-CSharp-Sample
cd Cohere-Rerank-v5-CSharp-Sample
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Configuration.UserSecrets
dotnet add package Microsoft.Extensions.Configuration.EnvironmentVariables
dotnet user-secrets init

注意 dotnet user-secrets init 会生成自己的 UserSecretsId，不需要照抄原文项目文件里的标识；安装命令本身也没有锁定上述包版本。

配置项为 COHERE_RERANK_PRO_ENDPOINT、COHERE_RERANK_FAST_ENDPOINT，以及对应的 COHERE_RERANK_PRO_API_KEY、COHERE_RERANK_FAST_API_KEY。通过 dotnet user-secrets set 写入，用 dotnet user-secrets list 查看，最后执行 dotnet run。

endpoint 填 Foundry 资源基础地址，不带路径。同一资源下部署两个模型时，可以使用同一个 URL。不设置 API key 时，示例通过 DefaultAzureCredential 获取 Entra ID 令牌，作者要求先执行 az login。配置读取顺序是 User Secrets 在前、环境变量在后，因此环境变量可以覆盖前者。

请求使用 POST {endpoint}/providers/cohere/v2/rerank，Authorization 头采用 Bearer。模型名分别为 Cohere-rerank-v5-pro 和 Cohere-rerank-v5-fast；Entra ID 获取令牌使用的 scope 是 https://cognitiveservices.azure.com/.default。

请求体中最值得关注的是问题、候选和返回数量之间的关系：

    var body = new JsonObject
    {
        ["model"] = model.ModelId,
        ["query"] = query,
        ["top_n"] = topN,
        ["documents"] = new JsonArray(documents.Select(d => (JsonNode)d).ToArray())
    };

注意 top_n 只限制返回数量。示例传入 topN: 3 后，应用仍然用 result.Score >= model.Threshold 再过滤，不能把前三条直接视为可用证据。

HTTP 超时设置为 60 秒，正文使用 StringContent。作者说明这样会设置固定 Content-Length，而 JsonContent 使用分块传输。原文提供的 C# 主程序在 using var do 处截断，缺少后续解析和类型定义，不能直接复制为完整可运行程序。

两款模型还支持默认关闭的 Context Focus：返回文档内部最相关的字符区间，让聊天模型读取少量句子。开启时需在请求体加入 relevant_spans，设置 mode: enabled、threshold 和 max_spans。但本文示例并未实现，也没有提供完整参数对象和响应处理代码。

对于产品目录、事故日志、CRM 这类半结构化记录，作者转述 Cohere 的建议：每条记录转成 YAML 字符串，保留字段名和值的关系。普通 JSON 也可能适用，文章没有提供两种格式的对照结果。

我的判断

我认同把「证据不足时停止回答」放在调优前面。它给知识库应用提供了一个明确的控制点，也比不断要求聊天模型「不要编造」更容易检查执行结果。

但需要分清两个问题：重排器判断的是候选与问题的相关程度，资料是否过期、互相冲突、具有权威性，文章没有证明它能一并解决。检索阶段漏掉正确答案，重排器也无法找回来。

相比单纯提高向量搜索返回数量，重排多了一次模型调用，换来更细的筛选；相比只保留检索前几条，它增加了相关性判断。是否划算，要看减少的输入、额外延迟和答案质量，原文没有端到端对照数据。

0.50 和 0.45 适合作为实验起点，不适合作为上线保证。

尤其要检查「本来有答案却被过滤」和「根本没答案却通过」两类错误。多语言覆盖也一样：支持超过 100 种语言，不等于你的中文术语、混合语言文档和内部缩写已经验证过。

能拿来做什么

• 给现有知识库增加一次小规模对照：固定问题和召回结果，比较直接输入候选、重排后输入候选的回答表现，同时记录总耗时和输入量，判断新增调用是否值得。
• 在 Node 服务或其他后端实现「无候选通过就停止生成」的分支，并准备一组明确无答案的问题检查阈值；不要只用能命中资料的问题调参。
• 对多次搜索的 Agent 先评估 Fast，对最终少数证据决定答案的场景评估 Pro；使用相同问题和文档比较，避免把一次运行时间当成稳定结论。
• 如果长文档占据大量输入，单独试验 Context Focus，并检查截出的句子是否保留条件和例外；处理结构化记录时，再用同一批数据比较 YAML 与 JSON。