SPX-MicroCF懂得接话，也懂得倾听。
TurnBench ↗ 打断检测召回率第一，轮次结束召回率第三。
用户说完了吗？现在该接话，还是继续听？
在 TurnBench 官方隐藏测试集上，MicroCF 以 98.4% 的打断检测召回率位居榜首，并以 90.6% 的轮次结束召回率排名第三。它结合语音活动检测与后续活动预测，帮助语音应用判断：现在该回答、再等等，还是停下来听用户说。
听见当下，
判断接下来。
用户停了一下，可能是说完了，也可能只是在换气。要判断能不能接话，既要听清眼前的声音，也要考虑用户会不会继续说。
VAD · 有没有在说话
识别音频中的语音活动，判断用户此刻是在说话，还是暂时安静。
VAP · 接下来谁会说话
结合双方前面的对话，预测接下来的说话情况，帮助判断用户还要继续，还是准备交出话语权。
两路信息配合使用，才能更好地区分“暂时停顿”和“已经说完”。预测只依据此前听到的声音，不会读取后面的音频。
别急着接话，
先听完整。
同样是一小段安静，出现在句中和句尾，含义并不相同。MicroCF 会结合前面的对话状态持续判断，而不是一听到停顿就开始回答。
该接话时接话，
该停下时停下。
EOT 判断用户是不是说完了；INT 判断用户是不是要打断系统。 两者参考的信息相近，但判断错了，后果并不一样：接话太早，会把用户的话截断；停得太晚，用户就很难改口或补充。
因此，MicroCF 分别处理“接话”和“被打断”这两件事，兼顾检出率、误触发和等待时间。好的交互不仅要快，也要知道什么时候不该抢着说。
表现如何，
看公开评测。
在 TurnBench 官方测试中，MicroCF 的打断检测召回率排名第一，轮次结束召回率排名第三。下面同时列出召回率、误触发率和检测延迟，方便查看它在不同指标上的表现。
FPR 7.3% · 中位检测延迟 747 ms
FPR 7.9% · 中位检测延迟 678 ms
数据来源：TurnBench 官方测试结果 ↗。排名按隐藏测试集上的召回率排序；下方分别展示测试集和开发集结果。图中的检测延迟不代表完整应用的响应时间。
对话顺不顺，时机很重要。
MicroCF 帮助语音应用判断什么时候回应、什么时候继续听。应用再结合自己是否正在播报、用户正在办理什么事，决定接下来怎么做。
查看公开评测 ↗