燃烧仿真进阶：大涡模拟（LES）关键技术与实操要点
2026/10/15 7:30:31
想给知识问答加上重排模型，却把它当成聊天模型调用，常会拿不到预期的排序结果。本文面向第一次使用百炼 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_url=os.environ["BAILIAN_DASHSCOPE_BASE_URL"]candidates=["演示图书室开放时间为周一到周五上午。","演示借阅记录有误时，在借阅页面选择反馈并附上记录编号。","演示读者卡为蓝色，入场时请展示读者卡。",]reply=dashscope.TextReRank.call(api_key=os.environ["DASHSCOPE_API_KEY"],model="qwen3.7-text-rerank",query="借阅记录写错了，应该在哪里反馈？",documents=candidates,top_n=2,)ifreply.status_code!=200:raiseRuntimeError(f"排序失败，状态={reply.status_code}，编号={reply.request_id}")forposition,rowinenumerate(reply.output["results"],start=1):source_index=row["index"]ifnotisinstance(source_index,int)ornot0<=source_index<len(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 官方介绍，Qwen，2025-06-05。两页访问于 2026-10-14。