主题
指令的测试和调优
指令能否被 LLM 稳定识别,取决于测试是否覆盖了真实使用场景、调优是否有据可依。本篇给出一套三阶验证 + 归因决策树的方法论,配合 批量测试 工具形成完整闭环。
1. 为什么需要专门做「指令测试与调优」
指令配置和一般的 Prompt 编写不同:
- 例句稍有偏差 → LLM 直接识别到错误的操作行为;
- 编码冲突(controlCode 与其它指令重名)→ LLM 会「乱蒙」;
- 数据类型选错 → 参数解析失败,即使指令命中也无法执行;
- 提示词与其它技能冲突 → 意图被别的技能截胡。
因此必须以「验证 → 归因 → 修改 → 回归」的螺旋方式推进,而非「配一次就上线」。
2. 三阶验证模型
第 1 阶:跑批测试 (Batch Test)
目标: LLM 层识别准确率
工具: 指令集详情页 → 批量测试
通过标准: 整体准确率 ≥ 目标值(建议 ≥ 90%)
第 2 阶:端到端测试 (E2E)
目标: 全链路是否走通(识别 → 下发 → 设备响应)
工具: 智能体调试 + 真机
通过标准: 关键 case 100% 走通
第 3 阶:边界验证 (Edge Case)
目标: 极端场景是否稳健
工具: 手工构造对抗集
通过标准: 拒识 + 误识均在可接受阈值内2.1 第 1 阶:跑批测试
- 入口:指令集详情页 → 【批量测试】按钮;
- 测试集来源:平台根据每个操作行为的例句自动泛化(默认 5 倍,可调)
- 产出:整体准确率 + 明细列表(每条 query 的期望 vs 实际);
- 通过阈值:建议 90% 以上;若整体 < 80%,说明配置有系统性问题,应先修配置再复测。
2.2 第 2 阶:端到端测试
跑批只验证 LLM 侧的识别,不代表设备真的动了。E2E 关注的是:
- action 是否与设备协议一致(编码、参数格式);
- 下发链路是否通畅(端侧 / IoT 平台);
- 设备是否按预期执行(需真机或模拟器)。
推荐做法:每条控制项都选取 2~3 条典型 query 在应用调试中跑一遍,观察端上响应。
2.3 第 3 阶:边界验证
覆盖以下 4 类场景:
| 类型 | 示例 | 期望行为 |
|---|---|---|
| 拒识 case | 「今天天气怎么样」 | 不触发任何指令,交给闲聊 |
| 模糊 query | 「调整一下」 | 反问澄清 or 拒识,不擅自选择 |
| 多指令 query | 「打开空调调到 26 度」 | 任务规划器开 → 拆解;关 → 择一 |
| 口语化 / 方言 / 语气词 | 「灯儿再亮点儿呗」 | 命中调高操作行为 |
3. 归因决策树
当发现某条 query 识别错误,按下列决策树逐层排查:
识别错误
├─ 命中了错的指令(跨指令误识)
│ ├─ 是否有 controlCode 重复? → 修编码
│ ├─ 是否例句在多条指令间重叠? → 拆例句
│ └─ 是否其它系统技能截胡? → 检查技能优先级
│
├─ 命中了正确指令但错的操作行为
│ ├─ 例句是否覆盖不足? → 补例句
│ ├─ 操作行为语义是否与例句错位? → 换 opName / 换例句
│ └─ 是否自定义操作行为名称与设备物模型不一致? → 对齐命名
│
├─ 命中正确指令 + 正确操作行为,但参数错
│ ├─ 数据类型选错(应 NUMERIC 却选 ENUM)? → 换类型
│ ├─ 单位 / 步长配置错? → 修参数
│ └─ 槽位提取提示词太模糊? → 补提示词 + 举例
│
└─ 完全拒识
├─ 该 query 是否本就应拒识? → 是,通过
├─ 例句是否覆盖该口语表达? → 补例句
└─ 是否被上层意图路由拦截? → 检查 [多轮意图控制](../../02-技能库/01-系统技能/03-多轮意图控制.html)4. 常见错误速查表
| 症状 | 可能原因 | 修法 |
|---|---|---|
| 相邻两条指令互相误识 | controlCode 太相似 / 例句重叠 | 编码差异化 + 例句去重 |
| 「调高一点」不命中调高 | 未勾选「调高」操作行为 or 例句只写了「调大」 | 勾选行为 + 补例句 |
| 「调到 3 档」参数解析为 3 但设备用了别的枚举值 | ENUM 编码与设备协议不一致 | 对齐 enumCode |
| 「30 分钟后关机」不生效 | 未开定时能力 or 定时执行指令未勾选电源 | 开启 定时指令 相关卡片 |
| 指令识别对但设备没动 | action 命名与设备协议不一致 | 与设备端对齐 <code>_<op> |
| 拒识率过高 | 例句过少 / 与其它技能冲突 | 补例句 + 复查技能优先级 |
| 静默场景仍在播报 | 「执行反馈开关」未关 / 垫句非空 | 参见 静默指令 |
5. 调优 5 步流程
Step 1 · 建立基线
· 首次配置完立即跑批,记录准确率作为基线
Step 2 · 抽错误 case
· 从明细列表按错误类型分桶(见归因决策树)
Step 3 · 单点修改
· 每次只改 1~2 处配置,便于归因
Step 4 · 版本化保存
· 用指令集副本或备注记录本次修改内容
Step 5 · 回归跑批
· 与上一版本对比:准确率是否上升?是否引入新错误?
· 若引入新错,回退单点修改核心纪律:一次只改一件事,回归确认后再改下一件。批量修改会导致归因困难。
6. 上线前 Checklist
- [ ] 批量测试整体准确率 ≥ 90%
- [ ] 所有控制项都做过至少 3 条端到端测试
- [ ] 覆盖了 4 类边界场景(拒识 / 模糊 / 多指令 / 口语)
- [ ] action 命名已与设备开发对齐
- [ ] 定时 / 静默 / AIoT 设备控制技能配置已复核
- [ ] 与 多轮意图控制 / AIoT 指令控制 的联动已验证