主题
测试与调优
指令能否被稳定识别并正确执行,取决于两个阶段的验证:先在批量测试中验证模型对大量 query 的识别与提参准确率,再通过端到端调试验证全链路是否真的走通。本篇按这两个阶段给出操作流程与归因方法。
1. 整体流程
指令集配置完成后,按以下两个阶段推进测试与调优:
第 1 阶段:批量测试(识别与提参准确率)
→ 平台根据指令例句自动泛化,产出整体识别准确率
→ 定位并修改不符合预期的数据,准确率保证在 80% 以上
第 2 阶段:端到端测试与边界验证
→ 进入产品管理 → 打开 AIOT 指令 → 预览调试
→ 验证全链路(识别 → 下发 → 设备响应)与边界场景2. 第 1 阶段:批量测试
指令配置完成后,首先进入批量测试页面,创建任务。平台会根据指令中创建的例句自动泛化,产出整体识别准确率。
⚠️ 批量测试的前提条件:
- 仅当提示词类型选择「根据指令集生成」时,才可以进行批量测试——因为批量测试依赖结构化指令作为泛化与比对的基准;选择「自定义提示词」时无结构化基准,无法批量测试,只能走第 2 阶段端到端调试验证。
- 集贤 IoT 暂不支持批量测试,请直接进入第 2 阶段的端到端调试进行验证。
这一步测试的是模型对于大量 query 的识别和提参的准确性。如果有不符合预期的数据,则代表模型对当前泛化口令的识别不准确,需要查看预期输出和实际输出定位问题。
2.1 归因:IoT 设备
如果是 IoT 设备,需要看 domain / intent / value 三个参数中哪个值与预期不符:
| 不符参数 | 问题定位 |
|---|---|
| domain 不符 | 品类配置 |
| intent 不符 | 控制项/部件/操作行为 |
| value 不符 | 参数配置 |
2.2 归因:端侧直连产品
如果是端侧直连产品,需要看 action / type / desc:
| 不符参数 | 问题定位 |
|---|---|
| action 不符 | 控制项编码识别错误 |
| type 不符 | 操作行为配置 |
2.3 通过标准
定位问题后进行相应修改,将批量测试的准确率保证在 80% 以上,再进入下一阶段。
3. 第 2 阶段:端到端测试与边界验证
进入产品管理,打开 AIOT 指令,点击右上角预览调试。
3.1 调试参数填写
如果是 IoT 平台产品,需要在调试窗左上角的调试设置中填写相关参数:
| 设备类型 | 需填写参数 |
|---|---|
| 小家虚拟设备 | mock_deviceid |
| 小家真实设备 | deviceid / token |
| 集贤真实设备 | productid / deviceid |
如果是端侧直连设备,则不需要上述过程。
3.2 真实设备 vs 虚拟设备
填写参数后即可在调试窗进行测试。真实设备与虚拟设备的区别:
- 真实设备:若信息填写正确,调试窗可直接测试真实设备的反应,直接产生状态变化;
- 小家虚拟设备:只能看到下发内容和虚拟接口返回内容,且无法验证状态冲突场景——因为虚拟接口无真实状态。
3.3 调试窗可验证的长尾场景
批量测试只覆盖「单句 query 的识别与提参」,而调试窗支持真实上下文与全链路,适合验证批量测试覆盖不到的长尾场景:
| 长尾场景 | 说明 | 验证要点 |
|---|---|---|
| 多轮补槽 / 指代 | 上一轮问「开到多少度?」,本轮只说「26 度」 | 模型能否结合上下文补全意图,而非当作新的独立指令 |
| 模糊指代消歧 | 「那个关掉」「调低一点」在有/无控制上下文时 | 有上下文按设备控制处理,无上下文交回闲聊 |
| 意图串扰 | 查询与设置共用相近控制项(如「查询息屏时间」vs「设置息屏时间」) | 是否正确分流到查询 / 设置,不误判 |
| 参数越界 / 缺失 | 超出取值范围、或未指定关键参数(如多部件未指定上灯/下灯) | 是否触发反问澄清,而非强行下发 |
| 定时 / 时间触发 | 「X 分钟后关」「每天 8 点开」 | 是否走定时链路、时间参数是否换算正确 |
| 完全静默 / 垫句联动 | 关闭执行反馈 + 空垫句 | 是否按预期静默或播报垫句 |
| 非设备控制兜底 | 闲聊、情绪表达、开放域问答 | 是否正确交回普通对话,不误触发控制 |
💡 长尾场景重点覆盖多轮上下文、边界参数、冲突与兜底这些「单句测不出」的情况,是量产前必须逐一走查的部分。
3.4 调试窗日志怎么看:三层定位法口诀
在调试窗返回内容下方会展示完整日志(JSON)。无论链路多复杂,定位问题都可浓缩成一句口诀,逐层往下问,哪一步答「否」,问题就出在哪一层:
一看进没进——意图准入是否判为设备控制 二看计划对不对——规划层是否正确理解并拆解任务 三看指令发没发全——执行层参数是否齐全、多任务是否漏发 四看设备回了啥——平台执行结果与最终回复是否忠实
对照下表,即可从口诀直接找到「看哪个日志字段、判断什么、错了去哪修」:
| 口诀 | 看哪个日志字段 | 判断什么 | 配置去处 |
|---|---|---|---|
| 一看进没进 | 是否进入设备控制链路 | 意图准入判 0/1 是否正确 | 提示词编写 § 2.1 |
| 二看计划对不对 | AIOT_TASK_PLAN.data(agent/taskType/reasoning/tasks) | 意图理解与任务拆解是否正确 | 提示词编写 § 2.2 |
| 三看指令发没发全 | tool_calls[].args(如 intents 里的 intent/domain/value) | 参数是否齐全、多任务是否漏发 | 提示词编写 § 2.4 |
| 四看设备回了啥 | observation / FinalAnswerTool.args | 平台执行成败、报错信息、最终回复是否忠实 | 提示词编写 § 2.5 |
💡
observation.intent_result不仅用于判断成败,还会驱动FinalAnswerTool生成最终回复,是回复话术自定义的依据,配置逻辑详见 提示词编写 § 2.5 执行结果与回复自定义。
实例:小家 IoT,query =「打开灯」执行失败的日志分析
以下为一次 status: failed 的真实日志(节选三块关键内容):
- 规划层解析(
AIOT_TASK_PLAN)——理解正确:
json
"reasoning": "用户指令“打开灯”匹配设备0的“灯”模式开关 -> 无范围数据,按用户给定值下发 -> 走IOTAgent直接执行",
"tasks": [{ "intent": "打开灯", "device": "皓月调光面板" }]规划层把「打开灯」正确识别为设备控制、拆成单任务 → 这一层没问题。
- 执行层下发(
tool_calls.args)——参数正确:
json
"name": "iot_do_batch_domain_intent",
"args": { "intents": [{ "intent": "打开灯", "domain": "灯" }] }intent/domain 提取无误 → 参数也没问题。
- 平台返回(
observation/FinalAnswerTool)——问题在这里:
json
"observation": { "error": "Tool 'iot_do_batch_domain_intent' not found" }
...
"FinalAnswerTool": { "answer": "抱歉，我暂时没有理解您的指令", "success": false }报错 Tool ... not found 说明该工具未被添加到工具配置列表(或平台侧未开通),导致规划、提参都对,却在下发时失败。
💡 定位结论:规划、提参都正确,失败发生在工具调用环节 → 应回到 工具配置 检查
iot_do_batch_domain_intent是否已加入工具列表。此外本例中第一步iot_get_device_shadow返回device not found,说明调试参数(deviceid等)填写有误,真实设备状态查询也不通,需一并核对调试设置。
3.5 多指令(复合指令)的配置与排查
一句话里包含多个控制动作(如「制冷模式16度最大风」),就是复合指令。它最容易「发一半、漏一半」,排查核心是规划层拆几个任务与执行层发几个意图是否一致。
💡 复合指令的提示词配置写法(taskType 判定、合并 intents 的规则与 few-shot)见 提示词编写 § 3.2;本节只给一份正确的返回日志作对照,并说明排查要点。
正确日志实例(query =「制冷模式16度最大风」)
规划层判 single + 单 task,执行层三个意图合并进同一 intents 数组:
json
// 规划层 AIOT_TASK_PLAN:single,tasks 只有 1 个
"taskType": "single",
"tasks": [{ "intent": "设置模式,设置温度,设置风速", "device": "格力静舒风空调" }]
// 执行层 tool_calls.args:一次调用,intents 数组发全 3 个意图
"name": "iot_do_batch_domain_intent",
"args": { "intents": [
{ "intent": "设置模式", "domain": "空调", "value": "制冷模式" },
{ "intent": "设置温度", "domain": "空调", "value": "16" },
{ "intent": "设置风速", "domain": "空调", "value": "max" }
] }
// 平台返回 observation / FinalAnswerTool
"observation": { "intent_result": "已成功把格力静舒风空调模式调到制冷模式" },
"FinalAnswerTool": { "answer": "已设置为制冷模式", "success": true }排查要点:按顺序数三个数字对不对得上——
- 数
tasks:single却拆出多个 task → 规划层错,须合并为 1 个; - 数
intents:数量少于动作数 → 执行层「发一半」,须合并进同一数组; - 看
observation.intent_result:回复不完整或有 alias 未归一 → 检查 value 枚举与回复配置。
以上任一处不一致,均按 提示词编写 § 3.2 调整配置;回复话术问题则见 提示词编写 § 2.5。