Datawhale Jev Cookbook 202610 笔记5

Datawhale Jev Cookbook 202610 笔记5

第五章作业：智能家居实验

1. 实验截图

图 1：智能家居 3D 实验页面------左侧 3D 房屋（五间房间）与底部各屋电气开关矩阵；右侧"全链路决策追踪"面板对应指令「把咖啡烧上」的实时评估------意图 smart_home_command 100% 、复合请求判断为单一指令（4%） 、投机提示语中 appliance_action 采纳 turn_on、其余 light / fan / speaker / lock 分支均为 leave_unchanged 被代码端剪枝，整体耗时 435 ms。底部显示本次 UI 完整调用 tokens 3,886、成本约 $0.000904（高于图 2 的 SDK 精简调用 948 tokens，因为 UI 附带了完整房屋设备矩阵状态）。

图 2：01_智能家居实验.ipynb live 输出------健康检查 {"jev": true, "asr": false, "chat": false}（上，asr / chat 未配阶跃 Key 故为 false）；「把咖啡烧上」投机调用链路（下）：上游 562 ms，intent / category / appliance_action 采纳，light / lock 投机分支被代码端剪枝

2. 数据记录

在 Notebook 之外，我用同一套问题包批量跑了 8 条指令（7 条单指令 + 1 条复合指令），以"意图 + 设备类别 + 动作"三项全对记为正确。逐条明细如下两表（整理自同日留档 JSON，数值未改动）。

第一轮：完全照抄 Notebook 的问题包（灯 / 家电 / 门锁三类动作）

#	指令	意图（预测/标注）	类别（预测/标注）	动作（预测 → 应为）	判定	耗时 ms	tokens
1	把咖啡烧上	smart_home_command ✓	appliance ✓	turn_on → turn_on	✅	491	787
2	关掉客厅的灯	smart_home_command ✓	lighting ✓	turn_off → turn_off	✅	551	787
3	把大门锁上	smart_home_command ✓	lock ✓	lock → lock	✅	315	786
4	打开书房的风扇	smart_home_command ✓	fan ✓	leave_unchanged → turn_on	❌	249	789
5	把音响关掉	smart_home_command ✓	speaker ✓	leave_unchanged → turn_off	❌	244	786
6	客厅灯现在是开着的吗	smart_home_query ✓	lighting ✓	leave_unchanged → leave_unchanged	✅	243	791
7	1989 年世界大赛冠军是谁	information_request ✓	not_device_specific ✓	leave_unchanged → leave_unchanged	✅	246	794
8	关厨房灯然后锁书房门	smart_home_command ✓（复合判断 ✓）	lighting ✓	turn_off → turn_off	✅	255	791

指标	数值
准确率	6/8 = 75.0%（复合判断 8/8 = 100%）
耗时	均值 324 ms，最快 243 ms，最慢 551 ms
输入 token	均值 789，合计 6311
成本	8 次合计约 **0.000265**，单次约 0.000033

错误样本：打开书房的风扇、把音响关掉------类别都判对了（fan / speaker），但动作都退化成 leave_unchanged。

第二轮：补齐风扇、音响两类动作预判后重跑

#	指令	意图	类别	动作	判定	耗时 ms	tokens
1	把咖啡烧上	smart_home_command ✓	appliance ✓	turn_on ✓	✅	393	946
2	关掉客厅的灯	smart_home_command ✓	lighting ✓	turn_off ✓	✅	244	946
3	把大门锁上	smart_home_command ✓	lock ✓	lock ✓	✅	243	945
4	打开书房的风扇	smart_home_command ✓	fan ✓	turn_on ✓（上轮错误已修复）	✅	243	948
5	把音响关掉	smart_home_command ✓	speaker ✓	turn_off ✓（上轮错误已修复）	✅	250	945
6	客厅灯现在是开着的吗	smart_home_query ✓	lighting ✓	leave_unchanged ✓	✅	240	950
7	1989 年世界大赛冠军是谁	information_request ✓	not_device_specific ✓	leave_unchanged ✓	✅	241	953
8	关厨房灯然后锁书房门	smart_home_command ✓（复合判断 ✓）	lighting ✓	turn_off ✓	✅	242	950

指标	数值
准确率	8/8 = 100.0%（复合判断 8/8 = 100%）
耗时	均值 262 ms，最快 240 ms，最慢 393 ms
输入 token	均值 948（+20%），合计 7583
成本	8 次合计约 **0.000318**，单次约 0.000040

关键发现

教程正文写的是"五类设备动作预判（灯/风扇/音响/家电/门锁）"，但 Notebook 里的示例问题包只问了灯、家电、门锁三类 。照着示例跑，风扇和音响指令会出现"类别对、动作空"的静默失败（见第一轮明细表 #4、#5）；补上两个问题后准确率从 75% 升到 100%，代价只是单次 token +20%、耗时基本不变。投机问题的覆盖面不是可选项，少问一类就是一个功能缺口。

3. 实验总结

这次实验最直观的体会是：JEV 把一个"自然语言指令"拆成了一组互不依赖的是非题。一次调用同时问意图、是否复合、设备类别和各类动作，返回的每条都带概率，代码按类别剪枝后直接执行。官方示例 562 ms 完成一次完整解析，批量 8 条平均 262 ms，单次 token 约 950、成本不到万分之四美元，比让人工点一次按钮还便宜。

也踩到了真实的坑：问题包少问两类设备，结果不报错，只是动作默默变成"保持不变"，用户会觉得"听不懂人话"。所以设计投机问题包时，覆盖面的检查要像写接口契约一样严格。

4. 回答打卡问题：如果选一个真实业务用 JEV，你会用在哪里，为什么？

我会用在客服工单的自动分流。

理由：

1. 任务形态完全对口：工单分流的本质是"从固定标签体系里选一个"，属于窄而确定的判断，正是 JEV 擅长的；这类任务交给生成式 LLM，反而要额外做 JSON 解析和格式纠错。
2. 需要概率而不是只有答案：分流错误有成本（技术问题进账单组会来回转派），有了 confidence 就能设双阈值------高置信度直接派单，低置信度进人工队列。第四章实测 0.5 阈值能稳稳拦住乱码，说明这条路可行。
3. 成本几乎可以忽略：按实测约 0.00004 美元/次，一天一万张工单的成本不到半美元，而一次错误分派的人力成本都远高于这个数。
4. 可审计：每个判断都返回分布，出问题能回溯"当时模型给的概率是多少、阈值怎么设的"，比黑盒 LLM 好解释。

边界也要说清楚 ：JEV 只适合做"判断"，不适合写回复。工单回复、安抚客户这类开放式生成仍然交给普通 LLM；两者串起来才是完整方案------JEV 负责路由，LLM 负责表达。

5. 学习总结

这期课最大的收获，是弄清了 JEV 和普通 LLM 的边界。

一、它不生成文本，而是返回判断。 普通 LLM 逐 token 写答案，要解析、要纠格式；JEV 一次请求带一个 state 和一组问题，直接返回 Choice 的完整概率分布或 Noul 的真值概率。问"这条工单属于哪类"，前者是写一段话再抠，后者是给一张带分数的表。

二、概率比答案更有价值。 实测遇到过 max_p=0.54、confidence 却只有 0.38，说明置信度是分布形状的压缩，不能直接用 top-1 代替。第三章的置信度门控、第四章的自一致性重复调用都围绕这一点：阈值跟风险走，查余额 0.5 够，转账要 0.9，擦线的转人工。

三、它更像代码里的分类器，不是聊天机器人。 扇出把问题一次问完、用不到的代码端剪枝；复合评分让模型只出原子分，权重留在自己手里；路由把便宜的判断挡在昂贵处理器前面。最深的体会是：JEV 的价值不在"答得好"，而在"错得可定位"。

分工也就清楚了。 适合 JEV 的：标签体系固定、一秒内能判断、结论要进代码分支、出错需追溯------分类、排序、路由、抽取、过滤，第五章实测单次约 950 token、不到万分之四美元。适合普通 LLM 的：开放式生成、多步推理与世界知识、长文创作。

最实际的不是二选一，而是串联：JEV 负责路由和判断，LLM 负责表达。落地时记住第五章踩的坑------问题包少问一类设备不会报错，只会静默降级，覆盖面要像接口契约一样逐项核对。