技术思考 | 端到端语音交互在教育场景落地的思考
一、技术方案背景（级联 vs 端到端）
| 方案类型 | 方案编号 | 方案简述 | 代表性工作 | 特点 | 技术依赖 |
|---|---|---|---|---|---|
| 级联 | 方案一 | 纯级联方案 | ASR + LLM + TTS 【代表性工作】X-Talk https://arxiv.org/pdf/2512.18706 |
技术成熟、模块易拆解，落地门槛低 | ASR 识别准确率、LLM 逻辑推理能力、TTS 的表现力 |
| 级联 | 方案二 | 标签化的纯级联方案 | 语音理解 (Caption) + LLM (支持标签) + Instruct-TTS 【代表性思想】OSUM-EChat(实际是端到端方案) https://arxiv.org/pdf/2508.09600 |
可捕捉基础语音标签（情绪、语速等），TTS 可控性提升 | 语音标签识别模型、LLM 理解+共情，支持标签输出、Instruct-TTS 的可控能力 |
| 级联 | 方案三 | SpeechLLM 级联方案（半级联方案） | SpeechLLM + TTS 【代表工作】FireRedChat(不支持标签) https://arxiv.org/pdf/2509.06502 或 SpeechLLM 支持标签 + Instruct-TTS |
简化级联链路，减少「语音理解」的误差传递 | SpeechLLM 语音语义建模能力、TTS 与标签协同 |
| 端到端 | 方案四 | 半双工端到端 (Thinker-Talker) | 【代表工作】Qwen2.5-Omni/Qwen3-Omni (Thinker + Talker)（参考 MinMo 可以支持全双工） | 分模块优化 “思考（语义理解）+ 表达（语音生成）”，属于端到端方案的一种形式 | Thinker 模块负责共情的文本回复、Talker 负责感染力的语音输出 |
| 端到端 | 方案五 | 半双工端到端 (Native w/ Text) | 【代表工作】Kimi-Audio/Step-Audio2/Fun-Audio-Chat/LongCat-Flash-Omni | 原生支持语音 + 文本融合，无法拆分出 Thinker-Talker 模块 | 文本 - 语音统一建模的技术 |
| 端到端 | 方案六 | 全双工端到端 (Native w/ Text) | 【代表工作】Moshi/Fun-Audio-Chat-Duplex | 支持双向的实时交互，可主动附和、实时打断，最接近真人对话形式 | 原生的用户&AI 双路建模方案 |
| 端到端 | 方案七 | 全双工端到端 (Native w/o Text) | 【代表工作】MOSS-Speech | 纯语音链路，无文本中间层，最彻底的端到端（Speech-to-Speech） | 纯语音语义理解能力、无文本依赖的语音生成 |
二、「现在」做端到端方案的「理由」（When&Why）
核心源于「现有技术局限性」与「业务需求升级」的双重原因：
技术层面 - 级联方案的局限性
- 误差累积问题显著：级联方案依赖 ASR→LLM→TTS 或 SpeechLLM→TTS 的逐模块传递，任一环节的错误会被放大。
- 例如 ASR+LLM+TTS：用户说 “今天天气真好，适合去公园散步”，ASR 误识别为 “今天天气真糟，适合去公园散步”，LLM 基于错误文本生成负面反馈，后续流程都错导致对话体验打折扣
- 例如 SpeechLLM+TTS：SpeechLLM 可能会消除部分 ASR 错误的影响，但如果是文本 response 的情感标签/自然语言描述预测错误，则可能 Instruct-TTS 会输出不合适的情绪/语气，对话的体验也会变差
- 重要信息严重损失：级联方案仅能捕捉文本信息，无法感知用户语音中的情绪（开心 / 低落 / 调侃）、语气强度、副语言信息（如犹豫、强调）
- 例如：用户用带有调侃的语气说 “你这回答也太离谱了”，级联方案仅识别文本语义，TTS 输出严肃反驳语气，导致缺乏真人情商
- 能力拆解难 & 效果有损：将 TTS 输出能力拆分为固定标签（如 “重读 / 不重读”“开心 / 难过”），无法实现连续、精准的调控
- 重读：应该如何定义清楚重读的具体能力？需要拆分不同重读的强弱等级吗？（轻度、适中、强烈的重读）
- 简单情况只能实现 “是 / 否”重读，是否存在 “轻度重读（略微强调）”“强烈重读（严肃的纠正）” 的细腻适配，语音控制很生硬
- 情感：应该做到什么级别的感情控制？短句级别、句子级别、段落级别？
- 综合难点：需要【产品+算法】把 Instruct-TTS 能力明确清楚，对 Instruct-TTS 的能力拆解(产品)、Benchmark(产品+算法)、技术方案选定(算法)要求都比较高
- 补充：业务的产品，能知道什么样的语音数据是好的，但是不一定具备「拆解出为什么觉得好」的能力、或者「需要拆解的维度太多」了？
- 端到端模型能够通过数据和 Context 来学习隐式规则（只需要数据，不需要能力拆解）
结论：以上局限，可能必须通过「端到端类型的对话方案」才能得到本质的解决，不然能做的只是一些短期过渡的方案
业务层面 - 需求升级与行业竞争
- 级联方案效果触顶
- 级联方案的时延、情绪适配能力、交互自然度等维度可能存在阶段性瓶颈，无法满足业务侧对 “真人化对话” 的要求
- 竞品验证技术天花板
- 国内外头部厂商已落地端到端方案，验证了其更高的能力上限
- 国内：豆包实时语音对话支持情绪感知（用户低落时 TTS 自动切换温柔语气）；元宝也支持了语音交互能力；千问 C 端在陪聊的方向上，正在加速落地
- 国外：GPT-4o-realtime 实现毫秒级时延 + 语音 - 视觉多模态交互；Gemini Live 支持全双工实时打断 + 情绪自适应，均突破级联方案的核心局限
- 行业认可度显著提升
- 端到端方案已从技术探索阶段走向商业化验证
- 技术/开源社区/产业界对端到端技术合理性、落地可行性的认可度显著提高，路线的探索预估风险比之前更低
三、端到端的核心新能力是什么（What）
端到端语音对话系统的核心优势，体现在交互体验、性能指标和能力扩展三个维度：
交互效果：更贴近真人的自然反馈
- 【感知】能够更精细化地捕捉用户语音中的多维信息
- 语速快慢、语调高低、情绪类型（开心 / 低落 / 调侃）、意图属性（疑问 / 陈述 / 请求）
- 【反馈】可以从文本共情回应 & 语音输出语气/重读/情感等多个层面上，给出适配的反馈
- 【教育场景痛点】结合「教学大纲/知识点」「用户语音的内容/情绪等信息」「教师人设」，给出符合教学场景的语音反馈（重读/情绪风格）
- 例如：学生兴奋地分享解题思路时，AI 不仅文本上给予肯定，TTS 还会以激烈赞扬的语气回应，增强互动共鸣。
性能指标：突破时延瓶颈
- 【痛点】目前级联方案的时延，长期卡在 1.5s-2s 左右，与真人的 “实时对话感” 仍然具有差距
- 端到端方案语音直接流式输出，整个系统时延可控制在几百毫秒（行业最优水平如 GPT-4o-realtime 已达 300ms），大幅提升交互流畅度
扩展潜力：支持多模态融合
- 【潜力】从架构设计上天然适配后续多模态能力的接入（图像、视频等），无需对核心链路进行颠覆性重构
- 例如：教育场景中，后续可接入图像模态，AI 老师通过摄像头识别学生皱眉、走神等表情，更实时调整讲解节奏和语气
四、技术方案的产品化落地（How）
现状与护城河
- 现状：普通 AI 助手/语音对话的赛道已经非常拥挤，豆包日活过亿，元宝/千问持续发力抢占市场
- 难点：“高情商”、“拟人化”是所有竞品都在讲的故事
- 护城河：结合公司垂类场景优势，聚焦在 “教育场景深耕”，打造具有差异化和解决痛点问题的产品
- 宝贵财富：「教育数据 (垂类数据的护城河)」「教研专家 (Benchmark 的护城河)」
- 核心方向：做一个高智商(懂教学)、高情商(能共情)、有感染力(真人魅力)的「超越真人的 AI 老师/AI 学伴」
懂教学：个性化适配学习需求（LLM 大脑）
- 基于学习数据（错题记录、学习进度、知识薄弱点）定制交互策略
- 基础薄弱学生放慢语速、重复核心知识点，进阶学生加快节奏、补充拓展内容
高情商：能「共情」和适配情绪 （语音理解和生成）
- 【输入侧 - 耳朵】实时识别学生情绪（考试失利后的低落、解题成功后的兴奋、遇到难点后的烦躁）
- 精准捕捉学习状态（例如：犹豫语气 = 思路卡顿，快速语气 = 自信掌握），实时调整讲解深度
- 支持方言 / 口音识别与适配（如南方口音、英语发音不标准），降低沟通门槛，避免因口音导致的理解偏差
- 【输出侧 - 嘴巴】语音输出时可以给出对应的语气（安慰时温柔舒缓、鼓励时激昂有力、答疑时耐心平和），模拟真人对话中的即时共情回应，增强情感连接。
有感染力：语音输出的细腻把握（语音交互的更高要求）
- 节奏与停顿设计：讲解难点时放慢语速、关键知识点后停顿 1 秒（留思考时间），总结时加快节奏、强化逻辑连贯性
- 更加主动的反馈融入：对话中穿插轻声附和（“对”“没错”“继续说”），模拟真人教学中的互动感，避免单向输出的枯燥感
- 情感递进传递：支持段落级情绪变化，如讲解复杂知识点时从 “温和引导” 到 “逐步强化”，循循善诱，增强教学的感染力，形成个人教学魅力
五、技术选型的关键决策（Which）
核心两套方案的对比
先不考虑端到端的「全双工」的能力，只对比方案四（Thinker-Talker 端到端/Qwen3-Omni）和方案五（Native 端到端/Fun-Audio-Chat）
| 评估维度 | 细节维度 | 说明 | Thinker-Talker 方案适配性（Qwen3-Omni） | Native 端到端方案适配性（Fun-Audio-Chat） |
|---|---|---|---|---|
| 模型相关 | 方案结构 | 模型整体结构框架 | Qwen3-Omni 含 MTP Module、MoE Talker、MoE Thinker、Vision Encader、AuT 等模块 | 含 Speech Encoder、Adapter、Shared LLM Layer、Text Head、Speech Refined Head、Speech Detokenizer 等模块 |
| 模型相关 | 开源模型能力 | 依赖的开源模型的基础能力 | Qwen3-30BA3B，论文评测更加完备 数据量：AuT 是两千万小时训练；Talker 是数百万小时 |
⚠️ Fun-Audio-Chat-8B（30B-A3B 比 8B 模型的效果上限更高） 数据量：整体使用了数百万小时的合成数据 |
| 模型相关 | 开源代码完备性 | 训练代码/复现的难度 | ⚠️ Tokenizer 未开源，需要自己整合训练 Talker（在 CosyVoice3 的基础上 CPT/SFT） | 所有模型/训练代码流程全开源，可以直接复用 |
| 成本相关 | 数据储备 | 现有数据是否满足方案需求 | 可复用现有文本数据 + 语音数据，对话类型数据量的要求相对更少 | ⚠️ 需大量纯语音对话数据，数据缺口现状预计较大 |
| 成本相关 | 机器储备 | 训练/推理的相关成本考虑 | ⚠️ 30B-A3B 的吞吐大概相当于 8B 的一半，推理成本高 但是单从 Talker 的角度，推理成本很低 |
8B 的训练/推理成本相对更低 |
| 成本相关 | 技术栈匹配度（研究成本） | 团队现有技术栈与方案的适配程度 | 可复用 SpeechLLM + Context-TTS 技术积累，模块协同经验成熟 | ⚠️ 需重新评估探索/实验周期，现有技术（模态对齐/TTS）的复用程度相对更低 |
| 成本相关 | 后续维护成本 | 模型训练、迭代、故障排查成本 | 模块独立，问题定位与修复效率高 | ⚠️ 耦合度高，文本输入引入了语音输出信息，badcase 排查难度相对更大，牵一发而动全身 ⚠️【举例】模型支持另外一个音色，就需要重新评估智商，甚至可能导致智商的倒退 |
| 具体落地 | 团队分工 | 哪个方案适合哪个小组做 | 工作完全独立，适合 TTS 组部分人力来做，理解侧短期内复用 Qwen3-30B-A3B-Thinker 即可 | 训练模型的实际人力不需要多，大部分人力可能在数据上，更偏向前沿的探索性工作 |
| 具体落地 | 上线周期可控性 | 从开发到落地的周期 | 短（3-6 个月），风险相对可控 | ⚠️ 不好预估，可短可长 |
注：整体两种方案不冲突，不一定需要「两者取其一」，但是应该需要抽出专门人力专注做
VoiceBench 具体评测对比
备注：数据汇总了 Qwen3-Omni 和 Fun-Audio-Chat 两篇技术报告中各类开源模型的结果
- 【说明一】只考虑各技术方案的开源版本，不考虑未开源的大参数模型（比如 Fun-Audio-Chat MOE 30B-A3B 可能更好，但没开源）
- 【说明二】Fun-Audio-Chat 技术报告没有和 Qwen3-Omni/LongCat-Flash-Omni 对比
| 模型 | LLM 参数量 | SD-QA | MMSU | OpenBookQA | IFEval | AdvBench | Overall |
|---|---|---|---|---|---|---|---|
| GLM4-Voice | 9B | 36.98 | 39.75 | 53.41 | 52.80 | 88.08 | 54.28 |
| MiniCPM-o 2.6 | 7B | 50.72 | 54.78 | 78.02 | 49.25 | 97.69 | 65.73 |
| Baichuan-Omni-1.5 | 7B | 43.40 | 57.25 | 74.51 | 54.54 | 97.31 | 61.33 |
| Kimi-Audio | 7B | 63.12 | 62.17 | 83.52 | 61.10 | 100.00(最优) | 74.02 |
| Step-Audio2-Mini | 7B | 56.06 | 52.18 | 64.18 | 38.01 | 93.08 | 57.09 |
| MiMo-Audio | 7B | 54.79 | 59.66 | 73.41 | 66.45 | 96.73 | 70.22 |
| Fun-Audio-Chat-8B | 8B | 66.27 | 71.08 | 83.52 | 78.52 | 98.65 | 79.61 |
| Qwen3-Omni-30B-A3B-Instruct | 30B-A3B | 76.9 | 68.1 | 89.7 | 77.8 | 99.3 | 82.36 |
| Qwen3-Omni-30B-A3B-Thinking | 30B-A3B | 78.1 | 83.0(最优) | 94.3(最优) | 80.6(最优) | 97.2 | 86.64 |
| Longcat-Flash-Omni-Instruct | 560B-A27B | 82.46(最优) | 81.95 | 93.41 | 77.99 | 100(最优) | 87.16(最优) |
技术选型时的其他思考
问题一：Fun-Audio-Chat 有哪些可以借鉴到 Qwen3-Omni？（综合优势）
- 借鉴一：5Hz refine，体现在 Talker 大致可以理解成把文本 embedding ungroup 一定倍数（但这么做对 TTS 任务会带来什么收益呢？）
- 借鉴二：Fun-Audio-Chat 类似 Talker 的模块，能否采用一些策略复用到 Qwen3-Omni 的 Talker，比如「模型参数」的直接复用
- 借鉴三：Core-Cocktail Training，训练策略的 trick，任何模型都可以尝试复用
- 借鉴四：Multi-Task DPO Training，训练策略问题，依赖于各类能力的数据
- 提升点：robustness to real speech data, capabilities of instruction-following, audio understanding, and voice empathy
问题二：Fun-Audio-Chat 输入 TTS 已合成 token 的作用和收益？（明确动机）
- 输入增加 speech-token，潜在价值在于 TTS 合成的语音本身，能够反向影响文本/语义层面的输出，可能上限更好，但是训练难度更大
- 问题一：合成的语音 token，如果不合理，引入到 SharedLLM，会不会反而影响生成的文本能力（收益 vs 风险的权衡）
- 问题二：模型换成支持另外一个音色，就需要重新评估 S2S 的智商，有可能会引起智商的倒退
- SharedLLM 输入侧引入语音，也可能是为了方便验证 Duplex 全双工而设计的？
- 根据 Fun-Audio-Chat 开源代码来看，语音到文本 s2t 的技术能力是不同时生成语音 token 的，那说明其实 s2t 任务仍然采用的是 talker 的思想；反而是 s2s 的时候采用另外的一套推理方式。
问题三：核心问题，数据方面的问题应该如何解决？
- 此处不过多展开，会另开专题。
- 思想：数据是原料，啥模型都需要。数据可能才是真正各家拉开差距的决定性因素，垂类数据目前可能还算是小公司的护城河，但优势很快就会/基本已经消失。
问题四：从 Qwen3-Omni 和 Fun-Audio-Chat 中跳脱出来，还有其他更优的选择吗？未来可以复用 Thinker-Talker 的技术成果吗？
- 美团龙猫全模态模型：LongCat-Flash-Omni: https://arxiv.org/pdf/2511.00279
- 简述：不是 Thinker-Talker 架构，类似 Kimi-Audio 和 StepAudio2，两个模态对应两个输出头，合成的语音没有作为 LLM 输入的 condition
- 优势：参数体量更大 - 520B-A27B；数据体量在 1000 万小时，支持语音和视觉模态
- 方案一：直接走 LongCat-Flash-Omni 的路子做端到端（所有参数都开源了）
- 方案二：只复用 LongCat-Flash-Omni 文本输出的能力，额外训练一个 Talker 复用 Thinker-Talker 的能力
问题五：Talker 方案是否一定需要一个语音多模态的 Thinker?
- 并不需要。ASR + LLM 的级联也可以理解成一个级联版的「Thinker」，不影响需要探索一个 Context 理解能力的 TTS 模型。
- 在这种「非端到端」方案的语境下，Talker 称为 Context-TTS 应该更合适一些，是一个纯 TTS 的任务，这样能把范畴更清楚地定义出来。
分析与总结
- 核心原则：「数据都是能力的核心支撑」，除数据工作外，两个方案其实思想基本类似，但需优先评估现有数据缺口，提前做好数据储备
- 综合考虑成本和现状，端到端要做优先选择 Thinker-Talker 的原因：
a. 更契合团队的技术积累与数据储备现状，上线周期短、挑战性不算大，风险可控，算是「端到端语音对话」方案中「最务实/可落地」的方案
b. 参考 https://mp.weixin.qq.com/s/tD0bJCeoaDH3kNj3yJ449w 中提到的端到端系统的现实挑战
ⅰ. Thinker-Talker 应该是技术挑战性相对最少的端到端方案，智商的保持 Qwen3-Omni 也是能打的
c. 功能层面：RAG / 网络搜索 / function call / 文本安全过滤等功能，在 Thinker-Talker 方案中可通过中间「文本」直接对接，实现相对更加简单
d. 成本问题：即使知道比较好的方案是什么，也需要考虑整体的绝对成本和 ROI 投资收益比（即使知道方案，也不一定有足够投入能做出来，相比于做出来的收益成本过高）
ⅰ. 完全原生端到端的数据驱动方案，有可能是「非头部基模大厂的技术陷阱」
六、阶段性目标与长远愿景（Where）
终极愿景：“三全” 目标
- 全双工：实现真人级对话体验，支持自然附和、主动打断、节奏同步，消除人机交互的 “延迟感” 与 “机械感”；
- 全模态：融合图像、视频、文本等多模态信息，例如 AI 老师通过图像识别学生表情、手势（如皱眉 = 困惑、点头 = 理解）
- 按照真人生物学基础，眼睛接收的信息密度要远高于耳朵
- 全主导：给出更加 proactive 积极主动的反馈，无需等待用户发言即可调整教学策略，进行主动问询和话题引导
- 补充：视觉模态其实也存在「双工」价值，比如不说话、只做动作，是不是也需要 AI 老师给用户更 proactive 层面的主动发起话题/反馈？
分阶段目标
- 短期目标（3-6 个月）：
- 完成 Thinker-Talker 端到端方案落地，实现基础的情绪感知和能力
- 覆盖教育场景核心能力：知识点讲解、错题答疑、语音互动反馈等等
- 中期目标（6个月-1年）：
- 升级为「全双工」端到端方案，支持实时打断、主动附和，情绪感知精度提升至更高水平
- 融合图像模态，实现 “语音 + 表情” 双维度交互（如通过摄像头识别学生专注度，调整讲解节奏）
- 长期目标（1-2 年）：
- 实现 “全模态 + 全场景适配”，支持语音、图像、视频、文本的全模态无缝融合
- 达到 “超真人交互体验”：AI 老师能通过微表情、语气变化传递复杂情绪，比真人更懂学生的个性化需求
参考资料
- 【级联 vs 端到端、全双工、轮次检测、方言语种、商业模式… 语音 AI 开发者都在关心什么？丨 Voice Agent 学习笔记】
- https://mp.weixin.qq.com/s/SqXLZvq_zwWDcOVKbAb7HQ
- 智谱+阶跃+Soul 的圆桌讨论，但时间是2025年4月份，仅做其他公司「探索历程」的参考
- 【端到端语音对话系统的丰满理想和骨感现实】
- https://mp.weixin.qq.com/s/tD0bJCeoaDH3kNj3yJ449w
- 详细分析了级联方案和端到端方案的各自优缺点，相对还是比较客观
- 【本地部署+全面测评！阿里最强全模态大模型Qwen3-Omni史诗级更新！】
- 【AudioMultiChallenge：语音对话系统多轮交互的 benchmark - 理解任务（评测是智商）】
- 论文：2025-12-16: https://arxiv.org/pdf/2512.14865
- Leaderboard: https://scale.com/leaderboard/audiomc
- 开源模型中，Qwen3-Omni-30B-A3B-Instruct 排位靠前
- 【超越级联系统：端到端语音大模型设计解析】
- https://mp.weixin.qq.com/s/ql15USv8TnZrjGPdCpq6iA
- 部分端到端方案的技术解析，但不是很新
- 【Qwen3-Omni 试用 demo】
- https://modelscope.cn/studios/Qwen/Qwen3-Omni-Demo
- 可切换音色，也可选择是否启用 CoT 推理
- 本文标题：技术思考 | 端到端语音交互在教育场景落地的思考
- 创建时间：2026-01-15
- 本文链接：2026/01/15/2026-01-15_edu-s2s/
- 版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！