重排序
重排序常用于检索结果二次排序。使用前先在模型广场查看可用模型。
如果你已经在做知识库检索，Rerank 负责“召回之后的精排”：
- 向量检索负责先捞出一批可能相关的文档
- 重排序负责在这批候选里重新判断谁最相关
- 聊天模型最后基于更靠前的文档生成答案
很多检索效果“差一点但又不是完全不对”的问题，恰恰就出在这一步。
向量召回能帮你先找出一批大致相关的内容，但谁该排第 1、谁该排第 8，不一定会自动处理得很好，这就是 Rerank 发挥作用的地方。
创建重排序 POST
地址示例：POST https://xiaolan.ainb.plus/v1/rerank
常用请求参数
model：重排序模型query：用户查询documents：候选文档数组
示例请求
先把 MODEL 替换成模型广场里实际可用的重排序模型名：
bash
MODEL="替换成模型广场里的重排序模型名"
curl https://xiaolan.ainb.plus/v1/rerank \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <你的 API Key>" \
-d '{
"model": "'"$MODEL"'",
"query": "找出和 Go 并发最相关的片段",
"documents": ["Go 支持 goroutine", "CSS 用来写样式", "Redis 是内存数据库"]
}'响应
返回结果通常包含每个候选项的排序分数和顺序。
第一次验证时，不必一次塞很多文档。先用 3 到 5 条短文本测试，确认排序逻辑和输出结构，再继续放大候选集。
第一次测试时，最好故意把文档写得“有明显相关”和“明显不相关”。
这样一眼就能判断排序方向对不对，而不是在一堆模棱两可的文档里怀疑模型是不是没生效。
使用场景
典型链路：
txt
用户问题 → 向量检索召回 20 条 → rerank 重排 → 取前 3 条给聊天模型重排序不负责生成答案，只负责判断哪些候选文档更相关。
它最适合放在“已经先召回出一批候选”之后。
如果你的候选集本身就完全不相关，Rerank 也很难凭空把答案变出来。
使用建议
documents不要一次塞太多- 候选文档尽量短而完整
- query 写用户原始问题，不要写系统提示词
- 分数只能在同一次请求内横向比较
- 先召回，再精排，不要把它当成聊天模型来用
如果你在做 RAG，一个常见的稳妥组合是：
- 先用 Embedding 召回 10 到 30 条候选
- 再把这批候选交给 Rerank
- 最后只取前几条给聊天模型
这样做的目的，是把“先尽量别漏掉”和“最后尽量排准确”拆成两步做。
常见问题
排序结果不稳定
先检查候选文档是否过长或互相重复。重排序模型更适合对相近候选做精排。
返回 400
检查 documents 是否是字符串数组，模型名是否来自模型广场。
如果请求结构看起来都没问题，再继续确认候选文档是不是混进了空值、非字符串，或者整批内容长到超出当前模型习惯处理的范围。
为什么有了 embedding 还要 rerank
向量检索更擅长“先找一批可能相关的候选”，但不一定能把最相关的几条稳稳排在最前面。Rerank 的作用，就是把这一步再做细一点。