![59b77cb9-1b51-4b7f-8c8e-be933b55bb76.png](https://developer.qcloudimg.com/http-save/yehe-11956170/43cc929d8cd8f6fb585a1b25045aaf91.png)

## 1. 从一个小任务开始：评论分析之外，还有模型管理

把一组商品评论整理成“好评还是差评、依据是什么、用户在说什么”，很适合做一个小型 AI 工具。难点并不只有提示词：当应用直接绑定具体模型，换模型就要改调用配置；如果要处理超时和限流，还要考虑后续请求交给谁。随着调用入口增多，这些规则也容易分散在不同脚本里。

这次实验把两件事分开：Python 负责数据准备、输出校验和报告，蓝耘元生代的**智能路由**负责维护模型池与优先级。应用调用一个路由标识，再到平台调整它背后的模型配置。

要验证的不是“接上一个接口能不能回答问题”，而是一个完整流程：创建专用路由，用真实请求处理公开评论，核对返回结果，再检查平台配置变化能否在调用端体现。固定模型直连作为对照组，帮助看清引入路由后究竟改变了哪一部分。

这里先说明边界：本文的多条评论由本地 Python 按组发送，**没有使用蓝耘的“批量推理”产品功能**。本次实际使用的核心平台能力是智能路由，以及与调用核验相关的用量统计。

## 2. 数据和评价方法先固定，避免看完答案再挑样本

数据选用 Dimitrios Kotzias 提供的 [UCI Sentiment Labelled Sentences](https://archive.ics.uci.edu/dataset/331/sentiment%2Blabelled%2Bsentences)，具体使用其中的 `amazon_cells_labelled.txt`。UCI 页面将该数据集标为 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)，允许在保留署名的前提下共享和改编。数据引用：Kotzias, D. (2015), DOI：[10.24432/C57604](https://doi.org/10.24432/C57604)。

准备脚本固定随机种子 `20260926`，抽取 24 条评价样本，正负各 12 条；另外保留 2 条不重叠的样本检查接口和输出格式。文本保持原样，记录原始行号和文件 SHA-256。模型只能看到 `id`、`text`，既有标签 `gold` 留在本地用于比较。

每条评论要求返回四个字段：

| 字段 | 含义 | 如何检查 |
|---|---|---|
| `id` | 输入记录的唯一编号 | 不能漏掉、重复或凭空新增 |
| `sentiment` | `positive` 或 `negative` | 与数据集既有标签比较 |
| `evidence` | 支撑判断的英文原文片段 | 必须是对应评论中的连续子串 |
| `summary_zh` | 简短中文摘要 | 检查非空和中文内容，并抽查语义 |

“证据来自原文”和“情感判断正确”是两件事：抄对一句话，不代表理解就正确；中文摘要可读，也不等于摘要经过完整人工标注评测。实验分别统计这些结果，不把它们合成一个含义模糊的“准确率”。

这是一组英文短评论、正负均衡的小样本，适合验收流程。它没有中性标签，也不能代表中文电商、反讽长评或线上评论的真实类别比例；公开老数据还可能出现在模型训练材料中。因此本文不据此给模型排榜。

## 3. 创建本地项目：只用 Python 标准库

项目目录叫 `lanyun-review-router`。创建目录后，将配套的三个脚本放入其中：

```bash
mkdir lanyun-review-router
cd lanyun-review-router
# 将配套 prepare_data.py、experiment.py、report.py 放到此目录
python3 prepare_data.py
```

交付包已经保存全部实验结果，直接打开即可阅读；要重新发起付费实验，应先独立核实自有账号的价格、余额和本轮预算，再新建实验目录，只复制三个脚本、`tests/` 和 `data/`，不复制旧 `outputs/`。原包的证据和账本应完整保留，不能靠删旧账本继续原轮实验。数据准备脚本会下载 UCI 官方压缩包、固定抽样并生成来源说明。主要文件如下：

```text
lanyun-review-router/
├── prepare_data.py       # 公开数据下载、抽样与哈希
├── experiment.py         # 请求、预算预留和原始结果保存
├── report.py             # 离线核验、CSV 和 HTML 报告
├── data/                 # 固定输入与来源记录
├── outputs/              # 各轮响应、运行清单、总账本
└── assets/               # 本次实操截图
```

本次在 macOS、Python 3.14 上运行，没有安装模型权重，也没有新增 Python 第三方依赖。程序使用 `urllib` 发起请求，使用标准库处理 JSON、CSV 和 HTML。预算账本的文件锁依赖 `fcntl`，因此配套代码适用于 macOS/Linux；Windows 原生环境没有做兼容验证。

这里的“本地项目”与“平台路由”是两个对象。平台实际操作是创建路由，并不存在本文需要额外创建的同名云项目；教程也不把本地文件夹包装成平台功能。

## 4. 在蓝耘创建路由：模板、模型池和真实限制

打开[蓝耘元生代 MaaS 平台](https://maas.lanyun.net/#/model/modelSquare)，进入左侧“模型服务 → 智能路由”。策略库提供多种场景，本次从“智能客服与工单”点击“复制编辑”，创建一条专用于评论分析的路由。

![蓝耘智能路由策略库](https://developer.qcloudimg.com/http-save/yehe-11956170/c37f78e7412f8e7ddcfb887edfa01a69.png)

图 1：真实策略入口。模板适合用作配置起点，具体模型仍需按任务和账号当前可用情况核实。

路由名称填写“商品评论分析-公开数据实测-0926”，选择“海量 FAQ · 成本优先”快捷方案。评论分类属于短文本任务，这个选项用于表达选型偏好；它本身不能证明后续调用一定更便宜。

![填写路由名称并选择成本优先方案](https://developer.qcloudimg.com/http-save/yehe-11956170/a6fc20062920fe2d23acc92d33993537.png)

图 2：实际创建页面。本次“匹配推荐”显示“暂无推荐”，所以后续模型池采用手动配置，没有把空白推荐区描述成自动选型成功。

配置时遇到了两个容易漏掉的细节。第一，模型广场能找到的模型，不一定出现在路由的添加列表里。例如本次先查看了 `deepseek-v4-flash`，但路由添加窗口实际提供的是包括 `DeepSeek-V3.2` 在内的候选模型。第二，最初只配置两个主力模型时，点击发布得到提示：**“需配置 3 个主力模型和 2 个升级模型”**。最后按当前页面的校验要求补齐，而不是把教程写成任意数量都可发布。

最终配置为：

| 配置项 | 本次设置 |
|---|---|
| 主力模型，按顺序 | DeepSeek-V3.2 → MiniMax-M2.5 → QwQ-32B |
| 升级模型，按顺序 | GLM-5.1 → GLM-5.2 |
| 超时自动切换 | 开启 |
| 限流自动降级 | 开启 |
| 单模型超时 | 30 秒 |
| 最大重试次数 | 1 次 |

![主力模型池、升级模型池和异常处理配置](https://developer.qcloudimg.com/http-save/yehe-11956170/868ca446d9e626766b02636144a64d0e.png)

图 3：发布前的完整模型与异常处理设置。模型卡片的先后顺序可直接检查，不能只看是否勾选了某个“智能”选项。

平台模型详情页核实的输入/输出价格，依次为 DeepSeek-V3.2 的 2/3、MiniMax-M2.5 的 2.1/8.4、QwQ-32B 的 1/4、GLM-5.1 的 6/24、GLM-5.2 的 8/28，单位均为元/百万 token；其中 GLM-5.1 引用的是输入小于 32k 的分段。本次短评论处于这一范围。完整价格截图保留在配套文件中，价格应以读者实际操作时的页面为准。

![DeepSeek-V3.2 的平台价格和完整调用名称](https://developer.qcloudimg.com/http-save/yehe-11956170/b8c89c75007b8d39b1eb72c812811756.jpg)

图 4：模型显示名称与 API 标识不同。固定模型组实际使用 `/maas/deepseek-ai/DeepSeek-V3.2`，不是根据显示名称自行猜接口参数。

发布成功后，在“我的路由”中得到本次调用标识 `rtr2026092600001`。这是本账号创建的对象，读者复现时应使用自己发布得到的标识。

![专用路由发布后的状态](https://developer.qcloudimg.com/http-save/yehe-11956170/1ee3315d071192b4c24f991cc8539bff.png)

图 5：创建成功时的真实记录。“已发布”只证明配置保存成功，还需要实际请求验证。

## 5. 先做小样本测试，再接入 Python

点击路由右侧“测试”，选择账号已有 API Key，输入一条公开评论，要求返回情感、原文证据和简短中文摘要。本次测试窗口显示命中 `deepseek-v3.2`、响应时间 3.85 秒、Token 114，结果为负面评价，证据能够在原文找到。

![平台内测试显示实际命中模型和评论分析结果](https://developer.qcloudimg.com/http-save/yehe-11956170/db15b8d8d14e467e7c24ca98eec555d9.png)

图 6：平台内测试。这里的 Token 是页面显示的字段，没有输入/输出拆分，因此不把它直接套入单一价格当作精确账单。

Python 实验随后分别验证了固定模型和路由的两条独立小样本，均收到 HTTP 200、完整 JSON 和有效证据。正式评价才使用前面固定的 24 条评论，每次请求包含 4 条，共 6 次请求；两组提示词和生成参数一致。把 4 条短文本放进同一个请求，是本地组织输入的方式。

调用的关键结构很短：

```python
endpoint = "https://maas-api.lanyun.net/v1/chat/completions"
body = {
    "model": model_id,  # 固定模型标识，或自己创建的路由标识
    "messages": messages,
    "response_format": {"type": "json_object"},
    "temperature": 0,
    "max_tokens": 1024,
    "stream": False,
}
```

这里的 `messages` 由 `experiment.py` 从固定提示词和评论生成；以上是已交付代码的关键参数摘录。完整脚本另行处理鉴权、超时、错误保存和输出校验。

配套脚本默认以隐藏输入读取密钥，不把密钥写进代码或运行清单。实测命令如下，适用于前面准备的新实验目录；已存在的运行目录不允许覆盖。在旧目录只换 `--run` 名还不够：原账本已经预留 4.05 元，剩余预留空间 2.14 元，而重跑以下两组至少需要 2.70 元预留，会被预算保护中途阻止。

```bash
python3 experiment.py --dataset data/evaluation.jsonl \
  --run baseline --kind direct \
  --model /maas/deepseek-ai/DeepSeek-V3.2

python3 experiment.py --dataset data/evaluation.jsonl \
  --run route --kind route --model rtr2026092600001

python3 report.py --dataset data/evaluation.jsonl \
  --run baseline --run route --out-dir outputs/evaluation-report
```

每轮保留数据与提示词哈希、请求参数、返回的实际模型名称、Token 用量、耗时以及模型正文。`finish_reason=length`、无法解析的 JSON、漏 ID、重复 ID、虚构原文片段都按失败处理，不靠补括号或人工改答案制造成功。报告以整组输入为分母，失败和未完成记录不会悄悄消失。

## 6. 正式结果：流程跑通了，但不要把它读成模型排行榜

正式实验先执行固定模型组，再执行路由组；两组都串行发送 6 个请求，没有做并发压力测试。离线报告核对了两组的数据、提示词哈希和生成参数，结果如下。

| 指标 | 固定 DeepSeek-V3.2 | 蓝耘智能路由 |
|---|---:|---:|
| 完成请求 | 6/6 | 6/6 |
| 完整有效记录 | 24/24 | 24/24 |
| 情感标签与既有标注一致 | 24/24 | 24/24 |
| 证据片段在原文中精确匹配 | 24/24 | 24/24 |
| 输入 Token | 1,212 | 1,212 |
| 输出 Token | 1,310 | 1,263 |
| 请求耗时中位数 | 5.76 秒 | 5.70 秒 |
| 6 次请求耗时之和 | 34.60 秒 | 34.40 秒 |
| 实际返回模型 | deepseek-v3.2 | deepseek-v3.2 |

![从保存响应生成的正式对照结果](https://developer.qcloudimg.com/http-save/yehe-11956170/53918f1d27ba32836a208f3da56fb317.jpg)

图 7：本地成果页，由保存的响应和核验统计生成，并非蓝耘控制台截图。页面同时列出正式对照和后面的独立切换测试，二者没有混入同一个准确率分母。

两组都命中 DeepSeek-V3.2，标签结果相同并不意外。路由在这一阶段承担的是调用入口和模型配置管理，没有证据说明它提高了模型的理解能力。两组只差 0.06 秒左右的耗时中位数，且执行顺序固定、请求只有 6 次，网络状态和服务负载都可能影响结果，不能据此宣称路由更快。

把视线移到每条结果，会比只看“100%”更有价值。例如 `amazon-0044` 的原文是 “I only hear garbage for audio.”，路由组提取了同一句证据，摘要为“音频效果极差，全是杂音。”；`amazon-0241` 则从日历同步的负面评论中提取 “Big Disappointment”，摘要为“日历同步功能令人失望。”。这样的输出可以进入后续的人工复核列表。

![逐条评论的原文、证据与中文摘要](https://developer.qcloudimg.com/http-save/yehe-11956170/a95b60e76e7b6dc34127b80619e801c6.jpg)

图 8：实际模型输出的阅读视图。每条都保留源记录编号，可回到 JSONL 查原文与完整响应。

抽查也发现了值得克制使用摘要的地方：`amazon-0693` 只说作者需要最小耳塞、佩戴较稳，模型摘要却写成“耳机佩戴稳固，适合小耳道。”。后半句带有归纳推断，不能直接当成厂商确认的适配结论。**标签匹配、证据存在、摘要忠实度需要分别验收**，因此本文没有给中文摘要标上“100% 准确”。

## 7. 真正验证平台能力：调用标识不变，实际模型改变

正式评价结束后，再做一个可控切换。进入同一条路由的“编辑”，在主力池移除 DeepSeek-V3.2 后重新添加，让顺序变成：

```text
MiniMax-M2.5 → QwQ-32B → DeepSeek-V3.2
```

升级模型与异常处理设置保持原值，点击发布。这个操作只是调整当前路由池的成员顺序，不是删除模型服务。发布后调用标识仍为 `rtr2026092600001`。

![修改模型顺序后调用标识保持不变](https://developer.qcloudimg.com/http-save/yehe-11956170/b21d81af04ce0dcb36a586947c12026c.jpg)

图 9：平台中的模型池顺序已经变化，应用使用的路由标识保持不变。

再次调用之前独立的 2 条小样本，命令只换运行目录名称，`--model` 仍然传同一个路由标识：

```bash
python3 experiment.py --dataset data/smoke.jsonl \
  --run switch-route-01 --kind route --model rtr2026092600001
```

保存的 API 响应显示：HTTP 200，实际模型为 `minimax/minimax-m2.5`，耗时 12.09 秒，输入/输出分别为 146/304 Token，2 条标签与证据校验全部通过。对同一条不适配 D807 的评论，它返回负面判断，证据为 `Do Not Buy for D807`，摘要为“错误广告，不推荐购买”。

这里得到的结论很具体：**应用不需要改变路由标识，平台里的模型优先级变化能够体现在真实响应中。**这不是“路由自动识别评论难度并挑选最优模型”的证明，也不是超时后自动切换成功的证明。本次没有人为制造限流或故障，超时切换、限流降级只能记为“已配置，尚未验证”。实验结束后已重新发布初始顺序，便于按正式对照配置复现。

同一阶段还遇到了一个真实失败：单独从网页测试窗口发送评论，页面显示 7.88 秒后 `Failed to fetch`，Token 字段为 0。

![网页测试窗口实际出现的请求失败](https://developer.qcloudimg.com/http-save/yehe-11956170/ccc8fa5e41192592a97c5578bcf3a11a.jpg)

图 10：保留失败现场。页面的失败记录与前面的 Python 成功请求不是同一次调用。

这条信息不足以定位究竟是浏览器、网络还是服务端的哪一环出了问题，不能直接归咎于某个模型。排查时应把本地完成 ID、请求时间、实际模型和平台用量一起对照；在确认之前，也不要把“页面显示 0 Token”等同于“服务端没有处理、没有费用”。本次没有为了得到漂亮截图反复重试。

## 8. 看用量，也把费用口径讲清楚

进入蓝耘“用量观测 → 用量统计”，可以按统计周期、调用方式和 API Key 筛选。对于复用账号，首页总量可能包含其他任务；核对本实验时应尽量缩小时间范围，并关注具体模型行。平台统计与本地响应分别提供不同视角：前者反映账号侧用量，后者能关联到我们发送的具体样本。

![蓝耘平台的模型调用与用量统计](https://developer.qcloudimg.com/http-save/yehe-11956170/2f29756352de73d1b144e6333db8c08d.jpg)

图 11：实验后的平台用量截图。金额以平台账单结算为准，不能用本地预算预留替代账单，也不能把账号内其他模型的用量算成本实验。

截图中 DeepSeek-V3.2 为 15 次、5,619 Token，MiniMax-M2.5 为 2 次、789 Token；两行消费金额都显示为 ￥0.00。DeepSeek 的 5,619 恰好等于本地成功 API 的 5,505 加首次网页测试的 114。MiniMax 平台统计有两次调用，而本地只保存了一次 450 Token 的成功 API 响应，这也说明网页报错后仍须继续核对平台记录，不能凭前端错误判定后端没有消耗。当前时间段的 DeepSeek 账单详情仍显示“暂无数据”，所以暂不报告精确实扣金额。

本次正式两组的 DeepSeek 响应均报告缓存命中为 0。按核实的输入 2 元、输出 3 元/百万 Token 计算，仅这 12 次成功 API 请求的模型费估算为：

```text
固定模型：(1212 × 2 + 1310 × 3) / 1,000,000 = 0.006354 元
智能路由：(1212 × 2 + 1263 × 3) / 1,000,000 = 0.006213 元
```

路由组输出少了 47 Token，所以得到一个略小的算术结果，不能解释成路由带来了确定的省钱效果。把前后的 API 小样本也纳入，15 次成功 API 请求共 5,955 Token，按返回模型对应的页面标价估算约 **0.0166692 元**。这不含两次网页测试的费用，也不包含不可见的后端尝试、优惠或结算调整，因而不是最终实扣金额。

本地脚本还为每次尝试提前登记一个保守预留：固定模型 0.15 元、路由 0.30 元，累计预留上限 6.19 元，失败也占用预留。这只是给短样本实验限制调用次数，不是平台提供的硬消费限额。复现者应重新核实余额、模型价格和重试规则，生产系统还需要独立的告警、限额与账单对账机制。

## 9. 使用前后，到底改变了什么

| 关注点 | 固定模型调用 | 本次蓝耘智能路由实践 |
|---|---|---|
| 更换主模型 | 修改应用使用的模型配置 | 编辑平台路由顺序，应用保留路由标识 |
| 多模型候选管理 | 调用者自行维护候选和条件 | 平台集中展示主力池、升级池与优先级 |
| 超时和限流处理 | 需要自行实现或接入处理逻辑 | 页面可配置相应规则；本文未验证触发行为 |
| 结果验收 | 应用检查输出 | 仍由应用检查，路由不会替代业务校验 |
| 调用追踪 | 保存本地响应与耗时 | 本地记录加平台模型用量，相互核对 |
| 维护成本 | 单模型小工具更直接 | 多一个平台配置对象，需要记录变更并做回归 |

对于一个长期只用单模型、调用量很小的脚本，智能路由未必是必要环节。它更适合需要保留统一调用入口、经常调整候选模型，或者希望集中维护异常规则的工具和小型服务。实测中的 3 主力加 2 升级约束、路由候选范围，以及推荐区为空，也都应纳入选型判断。

要继续把这个原型做成可用工具，下一步应加入包含中性、混合情绪和反讽的自有验证集，给摘要增加人工复核，并在受控环境中单独验证超时与限流策略。每次修改模型池后先跑固定小样本，再决定是否扩大调用量；不要因为某一次 24/24 就省掉后续回归。




把一组商品评论整理成“好评还是差评、依据是什么、用户在说什么”，很适合做一个小型 AI 工具。难点并不只有提示词：当应用直接绑定具体模型，换模型就要改调用配置；如果要处理超时和限流，还要考虑后续请求交给谁。随着调用入口增多，这些规则也容易分散在不同脚本里。

把模型切换交给平台：用蓝耘智能路由搭建商品评论分析工具

人工智能

开发工具

云计算

基于真实商品评论数据集，实验验证蓝耘智能路由的调用流程：应用仅需固定路由标识，调整模型池顺序即可切换实际模型，无需改动代码。两组均24条完整记录、标签与证据100%匹配，路由组输出更省47Token。但摘要含推断，需人工复核。

压力测试

代码解释

DeepSeek

Windows

路由

Python

Linux

JSON

MaaS

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

把模型切换交给平台：用蓝耘智能路由搭建商品评论分析工具-腾讯云开发者社区-腾讯云

把模型切换交给平台：用蓝耘智能路由搭建商品评论分析工具

把模型切换交给平台：用蓝耘智能路由搭建商品评论分析工具

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐