语音 Agent 在用户的每一次停顿都要回答同一个问题:「用户说完了吗?」判断太早 → 抢话打断(false cutoff);判断太晚 → 满屏尴尬静默(dead air)。EOU 模型用「语义完整性 + 韵律声学线索」替代传统「VAD + 固定静音阈值」,是决定语音客服「像不像真人」的第一瓶颈。
Silero VAD 等只区分「有声 / 无声」,静音超过 500–800ms 就认为说完。致命缺陷:① 停顿 ≠ 说完(思考停顿被抢话);② 有声 ≠ 有话(咳嗽 / 叹气进入 ASR 产生幻觉文本);③ 固定等待 = 延迟地板(每轮干等 700–800ms,对话像对讲机)。
像人一样综合语义(这句话语法上完整了吗)与声学韵律(语调上扬还是下降、语速、节奏)预测话轮是否结束。推理本身仅 10–60ms(CPU 可跑),整体判停延迟可从 700–800ms 压到 300ms 以内,同时噪声在语音层被源头拦截。
① 纯文本语义模型(读 STT 转写判断句子完整性,如早期 LiveKit 135M)→ ② 音频原生小模型(直接吃 PCM 保留韵律,如 Smart Turn v3、LiveKit v1)→ ③ STT / 端到端模型内置(Deepgram Flux、OpenAI Realtime semantic_vad)。当前路线之争:LiveKit 主张判停应由 Agent 框架层解决(跨 STT 厂商行为一致),Deepgram 主张融进 STT 层(链路最短)。
催收、回访、IVR 导航中用户报卡号 / 地址 / 身份证号存在大量思考停顿。EOU 直接决定被打断投诉率与通话完成率;外呼场景抢话直接导致挂断率上升。
ASR → LLM → TTS 级联管线中,EOU 是触发 LLM 开始生成的「扳机」,决定端到端响应延迟的下限(目标 <800ms)。
区分用户的附和语气词(「嗯嗯」「对」不该停)与真正想插话(「等一下」该停),是判停三分类思路的价值延伸。
需要 8M–135M 的小模型在 CPU / 端侧低延迟运行(int8 量化后最小仅 8MB),无 GPU 也能跑生产流量。
↔ 表格可横向滑动 | 数据截至 2026-07,以官方仓库最新版本为准
| 模型 | 技术路线 | 参数量 / 体积 | 语言 | 推理延迟 | 许可 | 适用判断 |
|---|---|---|---|---|---|---|
| LiveKit Turn Detector v1 / v1-mini 2026-07 发布 · Agent 框架层 |
音频直入双分支:语义分支(音频编码器 + adapter 投影入 LLM 嵌入空间)+ 声学分支(韵律 / 时序编码器 + 循环层)融合,无需等转写 | v1 云端完整版;v1-mini 量化裁剪后可 CPU 推理 | 14 种(英语为主,官方列表无中文重点) | 300ms 延迟预算下误切断率 9.9%(官方 eot-bench) | 代码 Apache-2.0 / 模型 LiveKit License | 效果最强;深度绑定 LiveKit Agents 生态 效果首选 |
| Pipecat Smart Turn v3.2 pipecat-ai · 社区驱动 |
音频原生:Whisper Tiny 骨干 + 线性分类头,直接吃 16kHz PCM(≤8s 当前话轮),与 Silero VAD 搭配(静音时才推理) | 约 8M 参数;int8 量化 8MB / fp32 32MB | 23 种(含中文) | CPU 最快 10ms,云实例 <100ms(Pipecat Cloud 实测约 65ms) | BSD 2-clause 全开(权重+数据+训练码) | 唯一明确支持中文且可自由微调的音频原生 EOU 中文客服首选 |
| LiveKit Turn Detector(早期开源版) 2024 · HuggingFace 开放权重 |
纯文本语义:基于 SmolLM v2 微调的 Transformer,读 STT 流式转写判断句子语义完整性 | 135M 参数 | 英语起步,后扩多语种 | 依赖转写到达时间(文本路线的结构性延迟) | 开放权重 / LiveKit License | 曾将误打断降低 39%;学习文本路线的最佳样本 |
| Turnsense latishab · 社区轻量项目 |
文本语义:SmolLM2-135M 微调;三分类(Complete / Incomplete / Invalid)思路把噪声单独归类 | 基于 SmolLM2-135M 微调裁剪,发布版约 47M(INT8 约 50MB) | 英语为主 | CPU 约 54ms,主打树莓派等低功耗设备 | 开源 | 代码量小,适合入门读源码理解 EOU 原理 |
跑 Smart Turn 仓库的 record_and_predict.py:对麦克风说「我想找一下,嗯……那个退货标签」,可直观对比 EOU 与纯 VAD 的行为差异。生产接入范式:判停模型与流式 ASR 并行——VAD 切出语音段后同时送两者,总延迟取两者最大值而非累加;判停返回 Invalid 时直接丢弃,噪声源头拦截还省 ASR 算力。
↔ 表格可横向滑动
| 方案 | 路线定位 | 核心特点 | 注意事项 |
|---|---|---|---|
| Deepgram Flux 2025 发布 · 2026 多语言版 |
STT 与判停一体化的「对话式语音识别」(Conversational Speech Recognition) | 直接输出「话轮完整」的转写事件,免去外挂 EOU 模型;事件驱动输出简化 Agent 开发 | 判停行为与 STT 厂商深度耦合,换厂商 = 换对话手感;LiveKit 基准中 300ms 预算下误切断率 12.9% |
| LiveKit Cloud v1 托管推理 |
Agent 框架层统一判停 | eot-bench 综合最强(300ms/9.9%、600ms/4.5%);LiveKit Cloud 上免费默认启用,每月 7500 次免费推理额度 | 完整版仅托管提供;本地只有 v1-mini |
| AssemblyAI Universal-Streaming | STT 内置智能 endpointing | 语义 + 声学结合,输出 end-of-turn 置信度,可按业务调阈值 | 同属 STT 耦合路线;中文支持需单独评估 |
| OpenAI Realtime API · Semantic VAD | 端到端语音模型内置 | 提供 semantic_vad / server_vad 两种模式,随 API 生效零部署 | 社区反馈短回复("yeah" / "嗯")存在漏检;行为黑盒、可调参数有限 |
| Krisp ultraVAD | 独立语义 VAD 商业模型 | 可嵌入自有管线的第三方组件 | LiveKit 基准中 300ms 预算下误切断率 27.7%,落后于头部方案 |
| 国内:阿里云 OutboundBot / 火山引擎豆包 Realtime | 实时对话 API 内置智能断句 | 与国内电话线路 / RTC 生态集成度高,中文优化好 | 判停能力打包在整体方案内,公开技术细节与独立可调性较少 |
LiveKit 随 v1 开源了 eot-bench 基准套件 + 14 语种真实话轮数据集,按生产视角评测:话轮内每次停顿都是决策点,模型要在中途停顿时等待、在真正结束时快速响应。
| 模型 | 300ms 延迟预算 → 误切断率 | 600ms 延迟预算 → 误切断率 |
|---|---|---|
| LiveKit Turn Detector v1 | 9.9% | 4.5% |
| Deepgram Flux | 12.9% | 9.9% |
| Soniox | — | 5.5% |
| Krisp ultraVAD | 27.7% | — |
数据来源:LiveKit 官方博客(2026-07),基准由 LiveKit 主导,横向对比时注意「裁判即选手」的立场因素;建议用 eot-bench 自测目标语种。
痛点:抢话直接导致挂断率上升;每路通话都要一个判停实例,CPU 与 GPU 方案单路成本差一个数量级。
商用替代:阿里云 OutboundBot 智能断句(与国内电话线路集成最省事)。延伸阅读:外呼长短期记忆知识图谱专题(EOU 管「听得对」,记忆管「说得对」)。
痛点:700–800ms 固定等待是端到端延迟的最大单项;用户表述长、思考停顿多,误切断即投诉。
商用替代:Deepgram Flux(英文为主)/ 火山引擎对话式 AI(中文 RTC 生态)。
痛点:用户输入多为短指令(「查话费」「转人工」),超短语音易被漏检或误判为噪声。
评测方法:用 eot-bench 思路自建中文短指令测试集,核心看「300ms 预算下的误切断率 + 短语音漏检率」两个数。
EOU 模型只解决「判得准」这一环。完整的话轮工程共六层:端点策略解决用得巧,并行化解决响应快,填充语解决显得快,打断处理解决停得住,信道适配解决电话场景特性,数据闭环解决越用越准。很多手段不换模型就能显著改善体验。
| 优先级 | 手段 | 理由 |
|---|---|---|
| 🥇 立即做 | 对话状态条件化阈值 + 录入模式 + DTMF 兜底 | 零模型成本,直接消灭最痛的「报卡号被截断」 |
| 🥈 一周内 | 思考语填充 + 置信度分级等待 | 体感延迟立降,纯策略代码 |
| 🥉 一个月 | EOU/ASR 并行 + 打断状态对齐 + 三指标监控 | 架构性改造,一次做对 |
| 🏅 长期 | 投机预生成 + 8kHz 微调 + 数据闭环 | 持续拉开与竞品差距 |
一句话总结:EOU 模型解决「判得准」,端点策略解决「用得巧」,并行化解决「响应快」,填充语解决「显得快」,打断处理解决「停得住」,数据闭环解决「越用越准」——六层都做,才是完整的话轮工程。