这个坑值得记一笔。Linux 上用 cohere 5.13 的 Python SDK 调 rerank-v3.5，把 1200 个切片一次性传进去重排，接口回 400，原文是 too many documents: 1200, maximum is 1000。降到 900 条能过，但长文档场景每天都会碰到，手动删条数不是办法。
刚开始盯着「把候选集和最终结果混在一起，重复送排」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。单次请求的文档数有硬上限，超了直接拒；切片数量随文档长度线性增长，事前没有截断；并发批次没按上限切，合并时又拼成一个大请求。
先确认 SDK 版本与模型名，排除旧接口
python -c "import cohere;print(cohere.__version__)"接着按上限切片逐批调用，再合并分数
python rerank_batches.py --input chunks.jsonl --batch 800 --model rerank-v3.5然后用向量召回把候选压到 200 条再重排
python retrieve.py --topk 200 --out candidates.jsonl等前面都确认过，再合并各批结果时先归一化分数再统一排序
python merge_rerank.py --parts out/ --out final.jsonl --topn 8怎么算真的好了，看的是同一批现象。重排接口不再返回 400，最终前 8 条的顺序与单批全量重排一致，整体延迟下降一半。
这里还有个坑。重排的收益在候选集较小时最明显，把 top_k 拉到几百再送排，钱花了顺序也未必更好。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。