重排为什么按对计费
重排模型对「查询与候选文档」这一对输入打分，因此计费口径是按对或按处理 token，而不是按请求。它位于检索之后、生成之前：不改变召回范围，只把真正相关的片段顶到前面。成本随候选数近似线性增长，所以候选池大小直接决定这笔开支；候选池开得越大越贵，而对效果的边际帮助很快衰减，合理做法是向量粗排先收窄，再用重排精挑。
基本信息
| 计量口径 | 按查询与文档对计费，或按送入的文档 token 量计费 |
|---|---|
| 典型候选量 | 粗排结果 50-100 条送入重排，具体按评测确定 |
| 调用位置 | 检索之后、生成之前，只影响排序不影响召回 |
| 触发策略 | 粗排分数接近或问题复杂时启用，简单命中可跳过 |
| 降本手段 | 热门查询结果缓存、候选片段先截断、减少候选数量 |
| 配合关系 | 与向量检索是分工关系，不能替代召回本身的质量 |
典型使用场景
- 企业知识库问答里前几条经常答非所问，生成质量被检索顺序拖累
- 多路召回融合之后顺序混乱，需要统一打分重排
- 长文档片段先截到关键段再送重排，成本能明显下降而效果基本不变
- 高频重复问题用重排结果缓存，避免同一查询反复付对计费
- 两阶段检索设计：向量或关键词粗排扩大到百条，重排压缩到最终几条
重排调用示例
重排调用示例
# 送入的候选已由粗排收窄，通常控制在百条量级
# query 建议用改写后的查询；documents 先截断成关键片段再送
curl https://api.cohere.com/v2/rerank \
-H "Authorization: Bearer $RERANK_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "rerank-v3.5",
"query": "缓存命中如何计费",
"documents": ["文档A片段", "文档B片段", "文档C片段"],
"top_n": 3
}' # top_n 只取最终几条进提示词，控制生成侧上下文候选规模与收益
| 候选数 | 成本量级 | 效果预期 |
|---|---|---|
| 10-20 条 | 低 | 粗排已经很准时足够，多数场景下性价比较高 |
| 50-100 条 | 中 | 常见推荐区间，能救回被粗排压低的正确片段 |
| 200 条以上 | 高 | 边际收益明显衰减，除非粗排质量很差 |
| 全库直送 | 极高 | 成本失控，且大量无关片段干扰打分稳定性 |
重排救不了召回：如果正确文档根本没被粗排召回，无论候选排多重排都找不到它，这类问题应回到切分、embedding 与查询改写环节解决。
送重排前先把候选片段截短：多数重排模型只看关键片段即可判定相关性，把整块长文本原样送入会按 token 计费并显著抬高成本。