腾讯混元实时语音：智商保留率从21%到69%

腾讯混元 11 月 13 日发布实时语音模型 Hy Realtime，官方摆出的第一个数字跟声音无关：文本世界的推理能力搬进语音后，保留率从 21% 提升到 69%。这项能力已在元宝语音通话、腾讯客服上线，近期将开放腾讯云 API，说明语音助手的竞争正式从”像不像人”转向”掉不掉智商”。

为什么一个无关音色的数字成了主角？因为过去两年，实时语音模型的演示几乎都卡在同一个困境：聊三分钟很惊艳，聊十分钟就开始犯糊涂。前面说过的条件忘了，复杂问题答得含糊，一旦要联网查东西就断线。用户的新鲜感一过，产品留存就崩了。Hy Realtime 想解决的，正是这道坎。

保留率 21% 到 69% 到底在说什么

先解释”保留率”这个词。文本模型的知识、逻辑和推理能力，要搬到语音场景，必须先经过”口语化”这道工序——把书面语改写成适合说出来的话。但这个改写过程会稀释信息：长句被砍短、逻辑连接词被省略、精确的推理链条被”大概就是这样”取代。结果是模型说得越来越像人，脑子却越来越不好使。

官方给出的数字是：通过重构口语化改写的数据生产链路，高质量文本数据向语音任务的迁移保留率从 21% 提升到 69%。翻译成人话：以前把一个复杂的推理问题交给语音模型，只有两成多的逻辑能力被完整保留下来；现在接近七成。

这个提升带来的体感差异，比音质提升明显得多。21% 的保留率意味着，你问它一个需要三步推理的问题，它大概率会在第二步就跑偏；69% 的保留率意味着，三步里能走完两步多。对客服、教育、陪伴这类需要长对话的场景，这是能不能用的分界线。

能力维度	上一代实时语音模型	Hy Realtime	对用户的实际影响
文本推理保留率	约 21%	约 69%	复杂问题不再中途跑偏
不完整输入理解	依赖完整句子	结合上下文还原意图	话说半截、中途改口也能懂
工具调用	需外部编排	模型自主判断是否联网	当场查完再回答
副语言感知	以转写为主	情感、语调、环境音	能听出不耐烦和背景噪音
唱歌	不支持	支持自然语言点歌	按歌手、年代、曲风组合点歌
首响延迟	等待整段文本生成	边生成文本边合成语音	开口更快，接近真人应答

懂”话说一半”是怎么做到的

现实交流里，用户说话往往口齿含糊、话说半截，或者中途改口纠正自己。这对语音模型是硬骨头：传统方案把语音转成文字后再理解，一旦转写错误，后面全错。Hy Realtime 的做法是结合对话上下文做意图还原——不是逐句理解，而是把整段对话当成一个整体来推断用户到底想要什么。

举个例子：用户先说”帮我查下明天去上海的高铁”，接着说”不对，是后天”，再说”算了还是飞机吧”。传统系统会把这当成三个独立请求，可能同时执行三个任务。新模型会结合上下文判断出这是一次需求的修正，只执行最后一个。这种能力听起来不起眼，但在真实通话里，它决定了助手是”聪明”还是”烦人”。

预训练阶段的三级跳

官方技术稿提到，预训练沿”模态连通—深度融合—全场景感知”三个阶段推进。第一阶段让语音和文本能对上号，解决”听得清”；第二阶段让模型在语音空间里直接理解语义，而不是依赖转写文本，解决”听得懂”；第三阶段把感知范围扩展到情感、语调、环境音这些副语言特征，解决”听得出情绪”。

第三阶段的意义常被低估。人在通话里传递的信息，很大一部分不在字面意思上。”我没事”这三个字，用不同语气说出来是两种意思。如果模型只处理字面文本，就永远无法理解这种微妙差别。而一旦它能感知语调，客服场景里的情绪安抚、教育场景里的鼓励引导，才有可能做对。

工具调用：语音版 Agent 的关键一步

这次新增的 Agentic 工具调用能力，是整个发布里最容易被忽略、但商业价值最高的一块。模型会根据对话上下文和用户意图，判断是否执行联网搜索，把搜索决策、调用工具与生成回答统一在一个链路里完成。

为什么这件事重要？因为语音助手过去最大的短板是”只能聊天”。你问它今天天气，它答得出来；你问它”我们公司上季度的报销政策改了没有”，它就只能说”我无法查询”。一旦能自主调用工具，语音助手就从”陪聊”变成了”办事”——这恰好是企业在客服场景里最愿意付钱的能力。

训练时的奖励设计

官方披露的强化学习设计值得细看：奖励目标从”答案对不对”扩展到了工具调用的完整过程，冗余检索还会被阶梯式降权。这意味着模型如果乱搜一气，在训练阶段就要被扣分。

这个设计直指真实痛点。语音交互的时间成本极高——用户等三秒就开始不耐烦。如果模型为了保险起见每次都联网搜一遍，体验会非常糟糕。阶梯式降权的意思是：搜一次能解决的问题搜了三次，扣分；该搜的时候没搜，也扣分。这种精细的奖励设计，比单纯追求答案准确率更贴近产品需求。

另一处设计是底线门控：安全、格式、风格、逻辑四条做成”一票否决”，而不是加权扣分。代价是模型在边界情况上会更保守，收益是红线不会被平均分稀释。对面向公众的客服产品，这个取舍是合理的——宁可少答一句，不能答错一句。

唱歌这个彩蛋为什么不是彩蛋

唱歌能力来自与腾讯音乐 TME 灵音 AI 团队的深度 Co-Design。用户可以用自然语言组合点歌：歌手、专辑、曲风、语种、发行年份、热度随便叠加，还能承接前文继续选。官方给的例子是”来首 2010 年到 2020 年之间的英文民谣”，模型会结合多轮上下文理解意图、匹配歌曲并演唱。

表面看这是营销彩蛋，实际上它测试的是模型的高表现力控制力。唱歌比说话难得多：咬字要准、气息要连、旋律和节奏要协调，还要在长音上保持音色稳定。一家公司如果能把歌唱稳定，说明它在声学生成上的工程能力到了相当水平。

真正的护城河是曲库和版权

点歌功能的卡点从来不是模型能力，而是曲库和版权。腾讯音乐手握国内最大的在线音乐库之一，这个能力换别家来做，未必抄得动。这才是这次发布最”腾讯”的地方——它没有单纯比拼模型参数，而是把生态资产直接焊进了产品。

补贴与定价的算盘

HyRealtime 目前对个人用户免费开放——元宝 App 里选”初语”音色就能用，网页 Demo 也免费。这是典型的先规模后变现打法：语音交互的推理成本比文字高得多，免费期实际上是腾讯在替用户付算力账单。

对开发者，真正的成本要等腾讯云 API 定价公布才知道。语音模型的计费通常按音频时长或并发路数算，与文字按 token 计价完全不同。如果按分钟计费，一个高频客服场景的月度账单会非常可观。建议在评估阶段就把这条算进去，别只看模型效果。

低延迟是怎么压下来的

语音交互的体验，有一半取决于首响延迟——从用户说完到模型开口的那段时间。传统方案是”先想完再说”：文本模型生成完整回复，再交给语音合成。这种方式逻辑完整，但延迟高，听起来像在念稿。

Hy Realtime 采用低延迟方案，与”大脑”协同，实现边生成文本、边合成语音。核心是对文本与语音进行协同序列建模，加上高效声学生成技术，使语音生成不必等待完整文本输出后再开口。

三阶段训练的顺序

训练分三步：文本模型预训练打好语言基础；大规模语音数据预训练学习语音时序、韵律及文本对齐，并在此阶段注入 TN 相关数据，缓解流式场景下传统模块难以直接使用的问题；精品发音人微调进一步收敛特定音色、发音、韵律与情感。

这个顺序体现的是”先通用、后专用”的思路：前两步解决”能说、会说”，第三步解决”说得好、有情感”。对做集成的团队，第三步是关键约束——音色不是任意克隆出来的，而是精品发音人微调的结果。这也解释了为什么当前体验入口只给了固定音色，而不是自定义音色。想要一个”自己的声音”，还需要等开放音色定制能力。

训练阶段	主要目标	数据规模/特征	解决的体验问题
文本预训练	语言基础与推理	通用文本语料	知识面与逻辑能力
语音预训练	时序、韵律、对齐	千万小时级语音，51 套纯文本集、50 多套语音评测集	说话自然、不卡顿
发音人微调	音色与情感收敛	精品发音人数据	音色稳定、有情绪
后训练 MOPD	双教师能力迁移	文本教师 + 语音 Agent 教师	保住推理能力
强化学习	工具调用与偏好对齐	双轨奖励 + 底线门控	搜得准、不啰嗦

已经在哪些场景跑起来了

官方给出的落点很清楚：C 端在元宝，B 端在腾讯客服，开发者等腾讯云 API。这个顺序透露了策略——先在自家产品里跑通，再用真实数据喂养模型，最后才对外卖能力。

腾讯客服这个场景尤其关键。客服话务是典型的”高重复、高情绪、高标准”场景：每天成千上万通电话问的是相似问题，用户情绪起伏大，答错的代价很高。如果模型能在这里跑稳，说明它经得起真实业务的考验；反之，任何一次答错都会被放大成舆情。

对客服行业的影响

最先被改变的不是”陪聊”，而是话务流程。过去客服系统的自动化靠的是流程编排和关键词匹配，用户一绕弯就转人工。现在模型能理解不完整输入、能自主查资料、能感知情绪，很多原本必须转人工的对话可以留在机器端。这对企业的直接价值是人力成本，对用户的直接价值是等待时间。

但也要看到边界。客服场景里最难的不是回答问题，而是承担责任——退款、赔偿、投诉升级这些决策，模型无法也不该独立做出。所以短期内更现实的分工是：模型处理信息查询和初步安抚，人类处理决策和例外。把这条线划清楚的企业，落地会顺很多。

为什么语音模型特别容易掉智商

理解这件事需要一点技术直觉。文本模型的所有能力，来自海量文字语料里学到的模式；而语音模型要在声音信号上做同样的推理，就需要把”声音”映射回”意义”。这个映射一旦有损，后面的推理就全都建在沙地上。

损失从三个地方来。第一是识别误差：同音字、方言口音、背景噪音，都会让转写出错。第二是口语化改写：为了说得自然，模型会压缩长句、省略连接词，而精确推理恰恰依赖这些”冗余”的信息。第三是流式的约束：语音必须边想边说，不能等整段逻辑想完，这本身就限制了推理深度。

HyRealtime 的解法是在后训练阶段专门补这一块。团队重构了面向真人交流场景的高质量数据生产与门控体系，用双教师把知识、推理能力从文本模型迁移到语音模型，并用 51 套纯文本集和 50 多套语音评测集守着”文本智商不降”这条线。这套做法的本质，是承认语音模型会掉智商，然后在工程上一点点捞回来。

和竞品比处在什么位置

官方称在内部专家盲评与公开 Benchmark 上，相较 Hy2-O、豆包、GPT-Live、Gemini Live、Qwen 等多款语音模型取得领先。需要提醒的是，这些分数来自腾讯自测与内部盲评，第三方独立基准尚未充分验证。

这个口径问题值得认真对待。语音模型的评测远比文本模型难：音质靠人耳，理解靠任务集，延迟靠实测网络环境。不同厂商的测试集、评分标准、录音条件都不一样，横比的意义有限。真正可靠的判断方式，是拿自己的业务录音去测——尤其是”话说一半”和”中途改口”这两类输入，它们最能区分模型的真实水平。

三条技术路线的分野

目前实时语音有三条主流路线。第一条是”级联式”：语音识别加文本模型加语音合成，三段拼起来，工程简单但延迟高、情感丢失严重。第二条是”端到端”：一个模型直接从语音到语音，延迟低但对训练数据要求极高。第三条是”双教师蒸馏”，Hy Realtime 走的正是这条——用文本模型当通用能力教师，用语音 Agent 教师管多轮与工具调用，两边共同指导学生模型。

第三条路线的好处是兼顾：既保住了文本模型的推理能力，又学到了语音场景的交互习惯。难点在于配比——两个教师给的信号如果冲突，学生模型会陷入两难。官方提到的”受控配比”和”on-policy 逐 token 反馈”，就是解决这个冲突的工程手段。

技术路线	代表做法	优势	短板
级联式	识别 → 文本模型 → 合成	工程成熟、可复用现有模型	延迟高、副语言信息丢失
端到端	单一模型语音进语音出	延迟最低、情感保留好	训练数据门槛极高、推理能力易退化
双教师蒸馏	文本教师 + 语音 Agent 教师	兼顾智商与交互	配比难调、工程复杂

真实场景里的三道坎

发布会上的演示都很顺，但落地时会遇到三道坎。第一道是口音与方言。中国市场的客服话务里，带口音的来电占比很高，模型在标准普通话上的表现，未必能迁移到带口音的语音上。这需要针对性的方言数据，而不是通用语料堆量能解决的。

第二道是专业术语。金融、医疗、政务场景里，大量词汇在日常语料里极少出现，模型容易听错也容易说错。这类问题通常靠行业词表和微调解决，但每家企业的词表都不一样，定制成本会转嫁给客户。

HyRealtime 目前还没解决第三道，即多人对话。当前模型主要处理一对一通话，一旦进入会议、三方通话这类场景，说话人分离、插话处理、上下文归属都会变得复杂。这块能力 HyRealtime 尚未覆盖，属于路线图之外的工作。

下一步的三个方向意味着什么

官方把下一步的三个方向写在了发布稿里：双工交互、长期个性化记忆、前后台 Agent 交互。这三个词现在都还没做满，等于把路线图公开了，后面每一版都可以对着验。

双工交互指的是”边听边说”——真人对话里，听和说是同时进行的，会点头、会插话、会在对方停顿的间隙接上。当前的语音模型基本是”轮流说”，一方说完另一方才开始，听起来总是有点机械。要做到真正的双工，模型必须能同时处理输入流和输出流，这在工程上是另一个量级的难题。

长期个性化记忆指的是跨越多次会话记住用户偏好。现在的语音助手每次通话都像初次见面，用户要反复交代背景。如果能记住”这位客户上次的问题””这个用户偏好简短回答”，体验会有质变。但记忆也带来隐私问题：记多久、能不能删、关掉连接后记忆还在不在，这些都需要产品层面的答案。

前后台 Agent 交互指的是让语音助手在后台调起其他智能体干活，前台继续和用户对话。比如用户说”帮我订明天的会议室”，前台继续聊天，后台的智能体去查日历、发邀请、确认回复。这是把语音助手从”对话界面”变成”任务入口”的关键一步，也是所有大厂都在抢的位置。

和海外产品比，差在哪在哪赢在哪

横向看，HyRealtime 与 Gemini Live、GPT-Live 这类海外产品最大的差别不在技术，而在生态。海外产品的优势是全球化语料和多语言能力，缺陷是在中国市场落地时缺少本地服务、缺少合规支撑、缺少生态应用。HyRealtime 反过来：中文场景更扎实、腾讯生态内的落地更顺、合规路径更清楚。

另一个差别是路线选择。海外产品普遍偏向端到端一体化，追求”最自然”的对话体验；HyRealtime 走的是双教师蒸馏，追求”最聪明”的对话质量。前者听起来更像人，后者办起事来更靠谱。对娱乐陪伴场景，前者更合适；对客服办事场景，后者更合适。

把这两个差别放在一起，就能看出 HyRealtime 的市场定位：它不是要做一个全球最强的语音模型，而是要做中文场景里最能干活的语音模型。这个定位务实，也解释了为什么它先去腾讯客服，而不是先去做聊天玩具。

它对公司业务意味着什么

把视角从技术拉到生意，这次发布至少改变三件事。第一，语音入口的价值重估。过去语音助手被认为是”锦上添花”的功能，因为不好用、留不住人。一旦能查资料、能办事、能长对话，它就变成了真正的服务入口，用户的打开频次和停留时长都会重新分配。

第二，客服外包市场的洗牌。HyRealtime 已在腾讯客服落地，本身就是一场内部替代实验。如果这套能力被证明可行，它会作为云服务卖给其他企业，届时大量重复性的客服岗位会被压缩。这个过程不会一夜发生，但方向已经很清楚——先替代最标准化的那部分话务，再逐步向上渗透。

第三，随着 HyRealtime 能力外溢，内容形态也会变化。唱歌能力看似娱乐，实际上打开了一个新方向：语音内容的生产。过去做一档播客、一段有声书，需要真人录制、后期剪辑；现在可以用自然语言描述需求，让模型直接生成带情感、带演唱的音频。这对中小创作者是重大利好，对配音行业则是压力。

不过也要冷静。语音内容的版权、标识、真实性认定都还没跟上。一段 AI 生成的音频如果被用来冒充他人，责任怎么划分？平台是否需要强制标识？这些问题不解决，商用规模就上不去。

企业该怎么评估这类能力

第一，别只看演示。发布会的 Demo 都是精选场景，真实业务里的口音、噪音、专业术语才是考验。建议拿自己最近一百通真实通话录音做盲测，重点看三类输入：话说一半、中途改口、带情绪的抱怨。

第二，算清楚延迟的真实成本。官方说首响延迟显著降低，但企业关心的不是实验室数字，而是端到端体验——包括网络传输、工具调用、语音合成。建议在自己的网络环境里实测，尤其是移动网络下的表现。

第三，把合规写进合同。语音数据涉及个人信息，很多行业还有录音留存要求。模型在云端处理语音，数据在哪里、存多久、谁能访问，这些必须在采购前问清楚。腾讯云 API 的具体定价、调用限制尚未公布，开发者接入成本还待官方明确。

第四，留一条退路。语音技术的迭代速度很快，今天的领先可能半年后被追上。建议架构上把语音层做成可替换的模块，避免深度绑定单一供应商。多接一家做备份，谈判时也更有底气。

开发者的接入清单

如果你是开发者，准备接入这类能力，建议按这个顺序推进。第一步做场景裁剪：不要一上来就做通用助手，选一个边界清晰、失败代价可控的场景，比如产品咨询、预约登记、常见故障排查。边界越清晰，模型越容易表现好。

第二步做数据准备：整理一份领域词表，把产品名、专有名词、内部术语都列进去，让模型在识别阶段少犯错。同时准备一批真实对话样本，用来做上线前的评测基线。

第三步设计兜底：任何语音交互都要有”转人工”的出口，而且要让人工坐席能看到完整对话记录。这既是体验保障，也是责任划分的依据。HyRealtime 在客服场景的实践说明，兜底机制不是技术缺陷，而是产品设计的一部分。

第五步才是规模化。在这个过程中，最该警惕的是”演示很好、上线很糟”的落差。语音产品尤其如此，因为用户对延迟和错误的容忍度远低于文字输入。

常见问题

Hy Realtime 现在能用到吗？

C 端已上线元宝 App 语音通话，需在音色设置里选择”初语”；B 端已在腾讯客服落地；开发者可通过腾讯云 API 接入，官方口径为”近期”上线。

保留率 69% 是什么概念？

指高质量文本数据向语音任务迁移时保住的能力比例，从上一代的 21% 提升到 69%。通俗说就是”说着说着变笨”的程度大幅缓解。

为什么一定要选”初语”音色？

因为新模型绑定了精品发音人微调的结果，当前只在这个音色上开放完整能力。自定义音色需要等后续开放。

唱歌功能商用有版权风险吗？

有。音乐版权与演唱音色授权需要明确，商用边界与平台合规仍在完善中，用于商业直播等场景前应先确认授权范围。

工具调用具体能做什么？

模型会自主判断是否需要联网搜索，把搜索决策、调用工具与生成回答统一完成。目前主要用于实时信息查询，未来会扩展到更多外部系统。

和豆包、Gemini Live 比谁更强？

官方称在内部盲评和公开榜单上领先，但这些数据来自腾讯自测。建议用自己的业务录音做盲测，尤其关注不完整输入和情绪识别。

双工交互什么时候能用上？

官方只列为下一步方向，未给时间表。当前版本仍是轮流说话模式。

延迟到底有多低？

官方称首响延迟显著降低，未给具体毫秒数。实际体验还取决于网络环境和所调用的工具，建议实测。

企业接入需要准备什么？

需要明确场景（客服、陪练、导览等）、准备真实通话录音用于评测、确认数据合规要求，并规划好供应商替换方案。

语音模型会不会取代人工客服？

短期内不会。更现实的分工是模型处理信息查询与初步安抚，人工处理决策、例外与投诉升级。判断标准是风险与责任，不是技术能力。