如何科学评估 WeKws 唤醒模型DET 曲线、FRR/FAR 指标完全解读【免费下载链接】wekwsProduction First and Production Ready End-to-End Keyword Spotting Toolkit项目地址: https://gitcode.com/gh_mirrors/we/wekws训练完一个关键词唤醒KWS模型后最核心的问题不是loss 降了多少而是这个模型到底能不能用。对于 WeKws 这类端到端唤醒模型业界通用的科学评估方式只有一套用FRR/FAR 指标配合DET 曲线。本文将用通俗的语言带你彻底看懂这两个指标的含义、计算逻辑以及如何用 WeKws 自带的工具一键完成评估。为什么唤醒模型不能只看准确率普通的分类任务可以用 accuracy 来衡量但唤醒场景完全不同设备处于持续监听状态唤醒词出现的概率极低可能一小时才出现几次而非唤醒语音却占 99% 以上。此时即便模型把所有音频都判定为未唤醒准确率也能高达 99%——但这显然是一个完全不可用的模型。因此唤醒模型评估必须拆成两个独立维度来衡量维度通俗解释后果漏唤醒FRR用户喊了你好小问设备没反应体验极差用户会反复喊误唤醒FAR没人喊设备却自己亮了电量浪费、隐私尴尬、后台误触发这两个指标天然此消彼长科学评估的本质就是在两者之间找到平衡点。FRR 与 FAR唤醒评估的两大核心指标FRRFalse Rejection Rate漏唤醒率FRR 也叫误拒率指所有包含唤醒词的音频中被模型漏掉的占比FRR 漏唤醒的音频数 ÷ 全部包含唤醒词的音频数在 WeKws 中这一计算逻辑位于 compute_det.py对每条正样本取该音频内唤醒词所有帧的最大得分若低于当前阈值就记一次漏唤醒。得分来自 score.py 输出的 score 文件其背后的 max-pooling 训练策略定义在 loss.py 中。FARFalse Alarm Rate误唤醒率FAR 也叫误警率。唤醒场景下更常用的单位是每小时误唤醒次数False Alarm Per Hour因为它与设备持续监听的直觉完全一致——一个产品级唤醒模型通常要求 FAR 低于1 次/小时甚至 0.5 次/小时。FA per hour 误触发次数 ÷ 非唤醒音频总时长小时计算时有个关键细节一旦某帧得分超过阈值判定为误唤醒WeKws 会通过--window_shift默认 50 帧跳过其后一段帧避免对同一次误触发重复计数——这正是生产环境中的真实判定逻辑。DET 曲线一张图看懂唤醒模型全部实力单独看某个阈值下的 FRR/FAR 没有意义因为阈值一变两个数字都变。**DET 曲线Detection Error Tradeoff**把阈值从 0 扫到 1过程中的所有 (FAR, FRR) 组合画成一条曲线让模型实力一目了然。WeKws 的 plot_det_curve.py 生成的 DET 曲线中横轴False Alarm Per Hour每小时误唤醒次数纵轴False Rejection Rate %漏唤醒率百分比曲线越靠近左下角、整体越低说明模型越好——因为这意味着在相同误唤醒水平下漏唤醒更少。对比多个唤醒词如你好小问你好问问时把多条曲线画在同一张图上还能直观看出模型对哪个词更友好。实操用 WeKws 一条命令跑通完整评估WeKws 把评估流程封装得极其简单以 examples/hi_xiaowen/s0/run.sh 为例运行 stage 3 即可完成打分 → 计算指标 → 画曲线全流程bash run.sh 3 3内部依次执行了三步你完全可以手动拆开跑第 1 步模型打分用 score.py 让模型在测试集上逐条输出得分python wekws/bin/score.py \ --config exp/ds_tcn/config.yaml \ --test_data data/test/data.list \ --checkpoint exp/ds_tcn/avg_30.pt \ --score_file exp/ds_tcn/test_avg_30.pt/score.txt第 2 步计算 FRR/FAR用 compute_det.py 遍历阈值并输出统计文件python wekws/bin/compute_det.py \ --keyword HI_XIAOWEN \ --test_data data/test/data.list \ --score_file exp/ds_tcn/test_avg_30.pt/score.txt \ --stats_file exp/ds_tcn/test_avg_30.pt/stats.HI_XIAOWEN.txt第 3 步绘制 DET 曲线用 plot_det_curve.py 生成 det.pngpython wekws/bin/plot_det_curve.py \ --keywords_dict dict/dict.txt \ --stats_dir exp/ds_tcn/test_avg_30.pt \ --figure_file exp/ds_tcn/test_avg_30.pt/det.pngCTC 类模型则对应使用 compute_det_ctc.py支持多关键词一键评估。读懂 DET 曲线并选好部署阈值的 4 个技巧先定 FAR 上限再找 FRR产品需求通常先给出可接受的误唤醒比如 1 次/小时在曲线上找到该 FAR 对应的点其纵坐标就是最低漏唤醒率。看曲线的拐点曲线平缓段说明指标稳健陡升段说明该区域对阈值极其敏感部署时应尽量避开陡峭区域。对比基线曲线用同一测试集对比不同模型如 DS-TCN 与 MDTC的曲线重叠少且靠下的那条更优不要只看单个点的数字。用 stats 文件做精细选点stats.关键词.txt中每行是阈值 FA/小时 FRR可直接查出满足 FAR 约束的具体阈值写入运行时配置参考 stream_kws_ctc.py 的--threshold参数。新手避坑指南评估时最容易犯的 5 个错误❌用训练集/验证集评估DET 曲线必须基于独立测试集如 Hi Xiaowen 的 test 集否则指标虚高。❌只看 FRR 忽略 FAR只报漏唤醒率是报喜不报忧两个指标必须成对出现。❌正负样本比例失衡正样本太少会导致 FRR 统计不可靠评估前先看日志中 keyword 与 filler 的时长统计。❌忘记 window_shift阈值扫描时若把窗口偏移设得太小误唤醒会被重复计数曲线整体被高估。❌阈值取整不精细compute_det.py 默认--step 0.01若产品对阈值敏感可改为 0.001 提高选点精度。小结评估唤醒模型从来不是跑个准确率那么简单。掌握FRR/FAR 指标、会读DET 曲线、会用 WeKws 的 compute_det.py 与 plot_det_curve.py 完成端到端评估你就能科学地回答这个模型到底能不能上线这个问题。下次训练完模型记得先画一条 DET 曲线看看哦【免费下载链接】wekwsProduction First and Production Ready End-to-End Keyword Spotting Toolkit项目地址: https://gitcode.com/gh_mirrors/we/wekws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考