DEV Community

cognitalk
cognitalk

Posted on

2026年语音AI前沿：FDE讨论级联架构 vs 语音到语音模型

Forward Deployed: Voice AI on what works in 2026


https://www.youtube.com/watch?v=MwNvowwcZOo

全文标题：2026年语音AI前沿：前部署工程师论级联架构、语音到语音模型与真实世界部署的取舍

第一部分 开场与嘉宾背景介绍 （0% - 8%）

  • 1. 节目与嘉宾介绍

    • 主持人介绍本期节目是Dayton Space推出的第四个播客，专注于“前部署工程”（FDE）领域。
    • 嘉宾Basil因组织行业晚宴、聚会、小组讨论和播客而进入主持人视野，他曾成功主持AIE大会的FDE分会场。
    • 主持人欢迎Basil来到播客。

  • 2. Basil的个人背景与播客创立动机

    • Basil最初在Credit Karma担任产品经理，后在一家小型风险工作室工作，最终创立咨询公司Exoflop Labs，为客户（零售商、保险公司等）构建AI代理。
    • 他认为当前的工作是他早期产品工作的自然延伸：理解客户需求，做出权衡，并帮助他们构建产品。
    • 创立播客的动机源于今年一月与私募股权公司合作时，发现很多人难以区分社交媒体上的营销宣传和真实情况。
    • 因此，他决定邀请在优秀公司从事前沿项目的工程师进行深度对话并录制发布，让人们能从中获得可应用于自身业务的实践经验。

  • 3. 播客过往内容回顾

    • 首期节目主题是“代理型工程的未来”，邀请了Factory、Cognition、Composio、Sounded等公司。
    • 后续还举办了关于语音代理、计算机使用代理和企业级代理的小组讨论。

第二部分 本期语音代理专题预览 （8% - 16%）

  • 1. 选定主题与嘉宾

    • 本次精选的往期节目主题是“语音代理”，因为这是目前AI领域最热门的用例之一，Sierra等公司也认为这是最具竞争力的市场。
    • 嘉宾来自Decagon、Vapy、Retail、Daily和一家名为Smallest AI的公司。

  • 2. 讨论的核心议题概览

    • 当前最先进架构：级联管道。讨论了构建语音代理的三步流程：语音转文本（STT）-> 大语言模型（LLM）-> 文本转语音（TTS），并解释了为何不直接使用端到端的“语音到语音”模型，因为后者目前还不够可靠。
    • 关键权衡：智能 vs. 延迟。高智能的响应往往意味着更慢的速度，这对不同的用例可能是好事也可能是坏事。
    • 可靠性问题。讨论了当底层LLM服务（如Opus）宕机时的应对策略，例如准备一个模型“瀑布流”作为备用，以确保语音代理不会停止工作。
    • 非平凡问题：话轮转换。探讨了语音代理如何判断用户的停顿是表示说完话等待回应，还是在思考过程中，这并非一个简单的问题。
    • 真实世界部署案例。提到了嘉宾之一Pipat曾为世博会构建了一个语音代理，用于接听电话并回答会议相关问题，并将收集到的真实数据转化为基准测试。

  • 3. 主持人的观点与行业观察

    • 主持人认为绝大多数语音应用场景是客服支持，这是一个价值数千亿美元的巨大市场，但现有体验普遍很差，希望新技术能提升其水平。
    • 他指出，有趣的是，不仅是销售语音管道的公司在推崇它，连专注于客服的人也得出了相同的结论：模型尚未成熟，甚至可能永远不会完全成熟，这就是当前必须采用的做事方式。
    • 真正感受到这种痛点的不是研究人员（他们总想用更大的模型解决一切），也不是产品工程师，而是那些直接面对客户的FDE们，他们会因为模型犯下严重错误而要求提供保证。

第三部分 基础架构详解：级联模型与入站/出站用例 （16% - 28%）

  • 1. 最简单的级联模型架构

    • 由Pipecat公司的Brun讲解最基本的架构，即“级联模型”。
    • 输入：语音通过传输协议（WebRTC、电话呼叫、WebSocket）进入。
    • 语音转文本（STT）：进行转录，期间可能加入额外模型进行背景噪音消除和语音隔离。
    • 话轮检测：由于语音没有回车键，需要使用语音活动检测（VAD）和智能话轮模型来判断说话是否结束，这与在句子中间停顿不同。
    • 大语言模型（LLM）处理：将转录后的文本发送给LLM，LLM可能会返回推理结果、触发工具调用等。
    • 文本转语音（TTS）：得到完整输出后，进行文本转语音处理，通常速度快于实时，然后通过原始传输协议流式传回给用户。

  • 2. 出站（Outbound）与入站（Inbound）用例的根本差异

    • 出站用例（如债务催收）：
      • 机器人发起呼叫，有明确目标。
      • 如果用户跑题或说奇怪的话，机器人可以直接挂断电话，因为它没有义务继续对话。
      • 因此，设置安全护栏相对容易。
    • 入站用例（如客服中心）：
      • 机器人不知道来电者的具体意图，只有一些存在的上下文。
      • 对于业务简单的商家（如花店），可处理的事情有限。
      • 但对于复杂平台（如亚马逊），有海量产品和多种政策，无法将所有信息放入单个提示词中。LLM会倾向于记住上下文的头尾，忘记中间部分，导致幻觉。
      • 因此需要更多智能手段，例如引入“压缩模型”。就像使用编码代理时，当上下文窗口用到25%就需要开始压缩和保存工作，防止模型偏离轨道。语音AI在这方面领先编码代理一代，很早就开始解决压缩问题。
      • 核心工作是防止机器人产生幻觉，并跟踪对话进程。由于话轮通常较短，且机器人说的比人类多，需要持续追踪用户说了什么以及对话进行到了哪一步。

第四部分 级联 vs. 语音到语音：架构之争与混合未来 （28% - 45%）

  • 1. 为什么不直接用语音到语音模型？

    • 主持人提问，既然级联模型如此复杂，为什么不直接使用端到端的语音到语音模型？
    • 回答（来自Smallest AI的代表）：用一个生动的例子说明。你可以打给一个很好的语音到语音演示，感觉它反应迅速、能识别语调。但当你说“下周预约”，它却问“是6月10日吗？”你纠正说是2030年，它会立刻同意。这表明它在处理基本事实时可能出错。
    • 级联模型的优势在于更强的控制力：
      • 可以对输入进行严格的护栏检查，如检测提示注入或社交工程攻击。
      • 可以经过意图选择、条件检查和上下文优化的流水线。
      • 在生成回复后，可以进行事实核查（如确认年份是否正确）。
      • 挑战在于如何让所有这些步骤变得高性能，过去半年团队一直在努力从流水线的每个环节节省毫秒级的延迟。

  • 2. 语音到语音模型的演进与优势

    • 最初的动机：语音转文本会丢失情感信息，无论用户是悲伤还是兴奋，机器人都以同样方式回应。
    • 更高级的理解：语音到语音是一种更接近人脑运作方式的异步架构。人脑是边听边想的，会打断、会做笔记（后台工具调用）。级联模型是同步的（一步一步来），而语音到语音模型能像人脑一样异步工作。
    • Smallest AI的Hydra模型：这是一个多模态模型，既能接收语音也能接收文本，同时输出语音和文本，因此它可以执行工具调用。但挑战在于，在变得更自然的同时，如何保持与传统STT模型同等的准确性，这涉及到模型的可解释性问题。
    • 混合方案是中期答案：语音到语音模型在改进，但对于复杂工作流，仍会使用多个LLM。一种可行的模式是：主循环使用语音到语音模型进行流畅对话，当需要进行复杂查询或工具调用时，再委托给级联模型处理。这类似于人脑的“自动驾驶”模式（处理日常事务）和“深思熟虑”模式（处理复杂问题）。

第五部分 模型选择、并行化与多语言挑战 （45% - 60%）

  • 1. 级联管道中的模型选择

    • 速度优先：如果需要快速响应的模型，可以选择关闭“思考”功能的模型。
    • 个人偏好：有人喜欢Google的Gemini 2.5，认为它速度极快；Haiku模型也很好，但整体速度仍低于预期。

  • 2. 如何实现管道并行化？

    • 分叉与瀑布流：可以将语音信号分叉，一路用于生成语音，另一路送入STT。STT输出的文本可以分叉给多个LLM，形成一个“瀑布流”。然后在底部设置一个门控机制（如选举或仲裁模型），来决定哪个LLM的输出最好。
    • 这是一种非常复杂的计算机架构思想，现在终于有了用武之地。

  • 3. 口音与多语言的处理

    • Smallest AI的策略：对于语音到语音模型，目前完全专注于提升英语的智能水平，不想引入其他变量。
    • 级联模型的多语言支持：Vapy的嘉宾分享了经验。
      • 在日本部署时，OpenAI的4.1或Deepgram的转录器效果不错，但在语音合成（TTS）环节遇到了问题。他们认为适用于英语、西班牙语、葡萄牙语的顶尖模型在日本完全失效。
      • 解决方案：允许客户自带自定义的TTS服务器。在每个市场都有本土的初创公司或实验室擅长本地语言的发音（如阿拉伯语中的品牌名和地址发音）。
      • 这也体现了级联模型模块化的好处，可以灵活替换特定组件。

第六部分 提示工程设计、延迟与用户体验的权衡 （60% - 78%）

  • 1. 提示词设计的最佳实践：单一巨型提示 vs. 工作流方法

    • 取决于用例和提示词大小。
    • 入站用例：通常有专用线路和可预测的工作流，更适合采用“节点/图构建器”的方法，即结构化的工作流。
    • 出站用例：用户反应不可预测（愤怒、烦躁），单一提示词像一个“中央大脑”，可以从提示词的不同部分提取信息来增强响应，更具灵活性。
    • 知识库的利用：在入站中，可能确切知道何时需要提取特定知识；在出站中，可能需要利用所有可用信息。
    • 当前趋势：随着LLM能力的提升，现在又开始倾向于给模型提供全部上下文，让它自己判断。但最终，对于非确定性系统，最好的方法还是针对每个客户的具体用例进行大量测试，并用LLM作为裁判来评估可靠性。

  • 2. 延迟的定义与优化

    • 什么是好的延迟？ 标准在不断变化，客户期望越来越高。
    • 填充词（Fillers）的价值：完全没有填充词的回复会显得生硬。在等待API响应（可能长达5秒）时，一个好的填充词（如“稍等一下，我查一下”）能让体验更自然。关键在于填充词的质量和自然度。
    • 最难的问题：在性能和稳定性/可靠性之间找到平衡，是语音部署中最难解决的问题。

  • 3. 降低延迟的具体策略

    • 卸载指令：将长工作流分解。例如，在催收场景中，并非所有通话都需要处理信用卡支付。可以将这部分功能交给专门的子代理，只在需要时才加载相关指令。
    • 多代理架构：使用专门的代理处理特定任务，完成后回到主代理的自由对话模式。
    • 流式处理到多个模型：将音频流同时发送给小语言模型（SLM）进行快速意图分类，同时主流水线可能在添加填充词，从而在后台启动一个更智能的思考过程。
    • 成本考量：将庞大提示词喂给LLM会产生成本，尤其很多通话可能在10秒内就挂断了。拆分提示词不仅能降低延迟，还能降低成本。

第七部分 评估、基准测试与未来展望 （78% - 100%）

  • 1. 评估与基准测试的重要性

    • Pipecat发布了基于话轮的STT、LLM和TDS（文本到语音）基准测试。所有工具和测试数据都是开源的，任何人都可以用新模型运行测试。
    • 实用性：可以在不与客户正式对接前，就用这些基准测试来评估客户可能的工作流。FDE们可以利用现有的云资源，根据讨论内容快速构建评估集并进行冒烟测试。

  • 2. 自托管小模型的优势

    • Smallest AI观察到，许多客户将他们的大模型与自托管的小语言模型“Electron”配对使用。
    • 优势：成本更低、延迟显著降低、可靠性更高。相比之下，OpenAI等API的延迟会波动且不受控制。自托管模型可以根据需求弹性伸缩。

  • 3. 对Sesame模型的讨论

    • 有人提到Sesame曾发布过令人印象深刻的演示，但之后销声匿迹。
    • 了解的信息：据称他们在转向开发硬件（可能是眼镜），CEO已经财务自由，只是想玩点新东西。

Top comments (0)