OpenRouter 上线了 Reranker Models，并提供统一的 /api/v1/rerank 端点。
这件事的重点不是又多了一个模型类型，而是 RAG 流程里的“精排层”开始被纳入通用模型网关。
#Embedding search 只完成了第一步
很多 RAG 系统的默认路径是：把文档切块，做 embedding，按向量相似度召回若干片段，然后直接交给模型回答。
问题在于，embedding search 找到的是“可能相关”的块，不一定是“最能回答当前问题”的块。尤其当文档数量变大、chunk 粒度不一致、问题含义更复杂时，向量相似度排序会把一些表面相近但信息价值低的片段排到前面。
Reranker 做的是第二次判断：给定 query 和候选 documents，重新评估每个文档与问题的真实相关性，再返回更准确的排序结果。
#OpenRouter 的接入方式
OpenRouter 官方文档显示，Rerank API 使用 POST 请求：
https://openrouter.ai/api/v1/rerank
请求里包含 query、documents、model，也可以通过 top_n 控制返回多少条结果。首批模型包括 Cohere 的 rerank 系列，例如 cohere/rerank-v3.5。
这意味着已经在用 OpenRouter 的团队，不需要单独接 Cohere SDK，也不需要维护另一套供应商鉴权。RAG 流程可以继续走同一套 API key 和调用方式。
#对工程团队的价值
Reranker 最适合放在 embedding 检索之后。先用向量检索召回一批候选，再用 reranker 精排，最后把排名靠前的片段交给生成模型。
这条路径会增加一次模型调用，但通常能换来更稳定的答案质量。对客服知识库、代码库问答、企业文档搜索这类场景，精排层往往比盲目扩大 top-k 更有效。
OpenRouter 把它产品化后，开发者接入成本降低，RAG 系统也更容易从“能答”走向“答得准”。
#为什么统一网关有意义
直接接入 Cohere 当然也能用 rerank。OpenRouter 的价值在于把 rerank 变成现有模型调用体系里的一个端点，而不是另一套供应商接入工程。
这对小团队尤其明显。RAG 系统通常已经同时依赖生成模型、embedding 模型、日志、缓存和文档处理。如果 rerank 还要单独配置鉴权、限额、计费和错误处理，很多团队会先把它省掉。
统一网关降低的是“愿不愿意加这一层”的门槛。等 rerank 和生成、embedding 一样容易调用，它才更可能成为默认架构，而不是只出现在高配 RAG 方案里。