想给知识问答加上重排模型却把它当成聊天模型调用常会拿不到预期的排序结果。本文面向第一次使用百炼 Rerank 的同学用三条虚构帮助说明跑通一次文本重排区分候选召回、相关性排序与最终回答。限定北京地域及 DashScope Python SDK资料核验于 2026 年 10 月 14 日未在读者账号实测调用可能产生费用。1. 重排的输入是一组候选不是聊天历史Rerank 即重排接收一个问题和若干候选内容输出这些内容相对当前问题的排序。它不是负责生成最终答案的聊天接口。第一次接入先固定三条候选避免把向量数据库、文档切分和对话生成同时混入诊断。本文选择当前官方文本排序文档列出的 qwen3.7-text-rerank使用 DashScope 的 TextReRank 调用。先准备 API Key、北京业务空间接入根地址与 SDK。百炼文本排序 API不要把 chat.completions 方法里的 messages 换成这款模型名就认为完成迁移。SDK 方法、输入参数和响应字段都属于接口契约。官方 HTTP 示例与 SDK 示例的参数组织也不同直接发 HTTP 时有嵌套对象SDK 则做了参数封装。最短验收路线是一次固定问题、三条候选、返回前两条、根据结果索引取回原候选。此时不调用生成模型直接打印排序结果能更清楚地看到重排功能本身是否正常。2. 用三条帮助说明做第一次请求准备一个独立 Python 环境并安装 DashScope SDK把密钥放在 DASHSCOPE_API_KEY 中。BAILIAN_DASHSCOPE_BASE_URL 设置为北京业务空间的 DashScope 根地址应包含 /api/v1按照控制台接入配置获取不使用 Chat Completions 的兼容根地址。importosimportdashscope dashscope.base_http_api_urlos.environ[BAILIAN_DASHSCOPE_BASE_URL]candidates[演示图书室开放时间为周一到周五上午。,演示借阅记录有误时在借阅页面选择反馈并附上记录编号。,演示读者卡为蓝色入场时请展示读者卡。,]replydashscope.TextReRank.call(api_keyos.environ[DASHSCOPE_API_KEY],modelqwen3.7-text-rerank,query借阅记录写错了应该在哪里反馈,documentscandidates,top_n2,)ifreply.status_code!200:raiseRuntimeError(f排序失败状态{reply.status_code}编号{reply.request_id})forposition,rowinenumerate(reply.output[results],start1):source_indexrow[index]ifnotisinstance(source_index,int)ornot0source_indexlen(candidates):raiseValueError(响应索引超出候选范围)print(position,source_index,row[relevance_score],candidates[source_index])该样本的人工期望是“借阅记录反馈”那一条最相关实际模型排序需要你运行验证本文没有给出虚构分数。第二名是谁并不是唯一正确答案它可能只弱相关验收先关注真正能回答问题的候选有没有被放到前面。示例不打印密钥也不自动重试。错误状态与请求编号便于求助但仍应检查是否存在敏感内容不能把真实问题和候选全文直接发到公开讨论里。3. 看懂顺序、索引和分数的不同用途结果列表的位置代表本次排名index 指向输入候选列表中的原位置。第一名不一定来自原列表第一个元素。拿回原文时使用响应 index而不是循环计数不然重排虽然完成展示出来的却仍可能是旧顺序的内容。输出信息应该怎样使用不应怎样使用结果列表顺序展示本次候选排名当作原文编号index找回同一请求的候选跨另一批候选复用relevance_score比较本次请求的相关性当成答案正确概率top_n限制返回数量让模型从库中搜索新文档官方特别说明相关性得分主要用于同一请求内的相对排序不适合当作跨请求绝对值比较。不要因为一个样本得分较高就把它写成“准确率很高”也不要拿另一问题的分数决定当前问题一定有答案。候选集合外的正确文档不会凭空出现。Qwen 官方把向量表示与重排作为不同能力介绍二者可配合使用但不是同一步骤。Qwen3 Embedding 官方介绍 重排只能重新评估已经提供的候选。4. 有结果却不好用按这一顺序判断先检查原候选里有没有答案。如果三条内容都与问题无关排出第一名也不能满足用户。应用应该允许“候选里未找到有效答案”而不是把得分最高的无关段落强行交给模型生成确定结论。再看每条候选是不是包含完整意思。过短标题可能无法回答实际问题多条完全无关的内容粘成一个巨大候选又会模糊语义。开始时用一两句完整说明最容易观察之后再研究你的文档切分策略。若报参数错误检查调用的是 SDK 还是原始 HTTP。不能把 HTTP 的 input 和 parameters 外层原样塞进 SDK 的同名调用。若使用另一款重排模型重新核验它的输入要求和支持范围不把本文的参数清单当作全部模型通用协议。若报长度或数量错误缩减为本例三条短文本再运行。样本成功说明接入大致成立不证明大规模候选也符合限额。真实请求的单条长度、候选数量和总输入约束需要依据当前模型文档分别检查。5. 接到知识问答前再做两个对照把三条候选打乱顺序保持问题不变。预期与问题真正相关的内容仍排在前面其 index 会随着输入顺序改变。这能检查你的展示代码是否真的按结果关联原文。不要固定要求某个 index 永远是第一名。再换一个没有答案的问题例如“演示馆下个月的扩建计划是什么”三条现有候选没有提供这个信息。应用应把这种样本标成答案缺失让后续生成步骤说明没有足够依据。不能仅凭存在排序结果就宣布已找到答案。接入实际系统时保留候选业务标识、当前问题和排名的对应关系。下游生成模型只接收经过选择的内容并有清晰来源边界。人工抽查用户问题与候选之间的可回答关系比只查看排名是否成功返回更有价值。若计划使用分数阈值过滤候选先收集你自己的相关与不相关样本再观察它们的分布。阈值不能从本文虚构案例推导也不能因为一次排序表现好就用于所有领域。上线初期保留人工抽查并记录过滤掉了哪些候选避免正确材料在这一步消失。第一次任务完成的标准是请求拿到有效结果、结果能关联原候选、相关样本和无答案样本都可以解释。做到这里再加入向量召回和生成回答能让每一层有独立验收点也更容易定位后续知识问答的误差。参考资料文本排序 API阿里云百炼页面更新时间未显示。Qwen3 Embedding 官方介绍Qwen2025-06-05。两页访问于 2026-10-14。
