# Jev 及类 Jev 模型在电话语音机器人中的真正用武之地

这是我在担任语音 AI 编排平台产品负责人期间，结合自身观察以及他人发表的内容，对 Jev 和类似分类模型定位的一些个人看法。我原本在正文里给每个来源都加了链接，但该板块不允许在帖子中放链接，所以所有链接都放在了第一条评论里。 ## 一点历史背景 2022 到 2024 年间，大语言模型尚未普及，但手机通话中的机器人已经需要理解来电者的意图。于是我们自己构建了一个分类器。它能快速、低成本地从一句话中提取来电者的意图，使用客户可自行配置的目录，并在该语句中标注机器人所需的实体——结构化数据，既包括内置类型（如日期和数字），也包括为特定项目定义的自定义类型。效果够用，至今仍有一些项目在用它运行。 后来 LLM 出现了，有那么一段时间，大家觉得分类器似乎不再需要了——模型自己就能理解含义，自己就能组织回答。然而实际操作中，和往常一样，兴奋期很快结束了。在实际项目中，中型模型在初始提示词过大或经过几次话题切换后就开始崩溃，甚至开始胡编乱造。大型昂贵模型能扛得住，但要么让单次对话成本飙升，要么慢到实时通话无法接受。 当你专业地构建语音机器人，尤其是在大客户的生产系统中，你必须同时优化所有方面：回答质量、考核指标以及预算。机器人开发者通过工程手段绕过这个问题，比如采用多阶段机器人、同一个电话号码下用路由模型分发给多个智能体，以及在已知对话遵循固定流程的环节使用脚本化处理。 我们每年上线几百个大型商业项目，积累的经验足以说明：单一模型要么选错工具、要么超出上下文窗口、要么消耗大量 token 从而破坏服务的单位经济模型。在真实场景中，你不能依赖单一模型，它几乎肯定无法撑起整段对话。到那时，我们的老分类器已经过时了——首先是架构过时——我们开始用基于廉价快速小型语言模型的类似方案来替换它。 然后 Jev 出现了。**一切新事物都是被遗忘了的老东西 :)** 于是我决定结合我们自己的经验，看看分类模型在语音机器人中的应用场景和使用方式。 ## Jev 到底是什么 Jev 是 TypeSafe 推出的一款快速分类模型，自 2026 年 9 月起进入早期访问阶段。它接收一个状态（例如机器人的上一轮发言、当前流程步骤）和一组问题，返回一个带类型的结构化回答：在你设定的选项中做选择、在短刻度上打分，或者回答一个直接的是/否问题的概率。Jev 不生成文本，没有输出 token 这回事。它只返回一个带类型的结构体，拿到之后怎么处理是机器人设计师的事。 它相当快。延迟测量结果各不相同，但综合来看都在 500 毫秒以内。在一种情况下，一批 35 个问题在预热连接上约 170 毫秒完成，另一种情况是 332 到 892 毫秒。TypeSafe 官方资料称 70 到 500 毫秒。 为了更完整的图景，Jev 并非独苗。最近还出现了这些： - **Laya**，主要的、使用最广泛的免费替代品，由 Convai Innovations 的研究者发布，基于 Apache 2.0 协议开源。 - **Clef**，来自 Cloudflare，一个面向软件系统内部超快速决策的开放模型。 - **CMF**，轻量级开放模型，仅 304.5 MB。毫秒级响应，完全不生成文本，在分类任务上表现出高精度。 - **Bespoke Nimble**，Bespoke Labs 给出的"开源 Jev"方案，在 Qwen3.5-9B 上用 LoRA 微调，配合受限解码，让模型只能在允许的选项内作答。 - **Kev**，由 Jared Palmer 开发，最初是 Kev-0.5B——一个基于 Qwen2.5-0.5B 的超紧凑 Jev 类似模型，设计目标是在 MacBook Pro 等普通机器上本地运行，现已发展成一个模型系列。 - **CLM-8B**，来自 Stanford 和 Nvidia，缓存智能体的重复操作，在作者的测试中比 Jev 快达 9 倍。 到现在这类模型已经有相当多了。 我想要探讨的是：分类模型如何改进基于 LLM 的语音机器人。 ## 入口处的分类器，按主题划分的专属智能体 典型的语音菜单场景：一个电话号码下涉及多个主题，比如预订、订单状态、投诉或者"给我转人工"。如果把这些全部塞进同一个提示词，中型模型就会膨胀，在第二次或第三次切换话题后开始胡言乱语。 解决方案是在入口处放一个快速分类器。它选出一个针对单一主题调优的小型智能体，并将其接入对话。话题切换也是它的职责——作为一个独立的节点，在控制权交给大模型之前就完成判断，这样大模型就可以开始组织回答。 Piotr Zaczek 在 LinkedIn 上的一个短视频中展示了这一语音场景的实现。关键在于系统决定对话方向变更所需的时间：0.5 秒对将近 5 秒，再加上大模型 token 上的节省。Piotr 取消了大模型在自己主题之外推断和推理的权限，把这个工作交给了分类器。 为什么这样做？一个专属智能体拥有较短的提示词和单一的工具目录。分类器又便宜又快，所以每次话题切换时调用它的成本几乎可以忽略不计。在同一篇帖子中，Zaczek 还列出了他喜欢的三种用途，除了路由之外：通话后的审查、始终开启且不体现在语音回答中的后台限制、以及何时将通话转交给另一个智能体或人工的决策。值得记在心里。 ## 外部控制：模型提议，Jev 判定 基于 LLM 构建的机器人可以聊得很愉快，但很少能把业务流程走完到底。它找到了一个空档，却始终没有完成预订。它把预约记在了错误的名字下。对方说了"再见"，它却没有挂断。同一个问题问了两遍。 Giorgi Lomidze 讲述了他们如何在两周内将这类决策从语音模型中剥离出来，迁移到基于 Jev 的分类器上（《JEV in Production》，Medium，2026 年 9 月 24 日）。产品是 Pocos——一个面向沙龙和工作室的电话助手，生产环境运行在 Voximplant 上。很高兴看到这一点，感谢作者提及。 **它是如何搭建的：** 电话通过 SIP 接入，平台上的一个流程通过 realtime API 客户端连接 LLM（他们生产环境使用的是 Gemini Live），持续进行语音对话，处理问候、打断、计时器和挂机。语音模型听到来电者的话，并提议调用工具。模型做出的每一个推断，在改变系统或对话中的任何内容之前，都要经过分类器的审核。系统组装一个简短的事实包，Jev 收到几个是/否问题并返回概率。这些问题都是字面化的，例如"来电者是否确认了这个操作？"、"最后一句话是改变、确认还是取消了我们刚才说的内容？"以及"来电者说了再见吗？"。接下来发生什么取决于 Jev 返回的概率。阈值需要根据你的场景调整。在 Giorgi 的案例中，强烈同意从 0.9 开始，弱同意低至 0.1，"再见"从 0.75 起算才算强烈信号，且仅当来电者没有引入新话题时。 用他自己的话来说，这个方法的核心是：**LLM 只负责提议，Jev 负责判定，业务负责决策。** ## 回合结束：音频之上的语义 来电者在说到一半时突然安静了，静默计时器准备好将控制权交给机器人。在"我们把它改到周二好吗？"之后的"好"是一句完整的表述。而"我本来想说的是……"就不是，尽管停顿的时长是一样的。 我们有自己的轮次检测技术栈：一个模块集成了 Silero VAD、Pipecat 的 Smart Turn 回合结束检测器，以及可选的 Hush 降噪。开发者可以获取轮次事件，并对每个事件做出响应。