好的，我将按照您要求的格式分析文本并输出文章摘要，关键字，概述，分节阅读，相关工具和参考文献。
语言： 中文
关键字： Voice AI, LLMs, Latency, Function Calling, Multimodality
概述： 本文深入探讨了2025年对话式语音AI的发展现状与未来趋势。文章指出，大型语言模型（LLMs）在语音AI领域展现出强大的会话能力和非结构化数据处理能力，推动了语音AI在医疗、销售、客服等行业的广泛应用。构建生产级别的语音AI代理面临诸多挑战，如延迟、模型选择、上下文管理和功能调用可靠性等。文章详细分析了语音AI的核心技术和最佳实践，包括延迟优化、LLM选择、语音转文本、文本转语音、音频处理、网络传输、轮流检测、中断处理、上下文管理、功能调用和多模态等方面。此外，文章还讨论了如何利用多个AI模型构建更强大的语音AI系统，以及如何通过脚本和指令遵循实现更复杂的任务。最后，文章强调了语音AI评估的重要性，并展望了2025年语音AI的发展趋势，包括延迟优化、多模态融合、音频特定功能、上下文缓存API和新型语音代理平台等。
分节阅读：
- 1. Conversational Voice AI in 2025
- 大型语言模型（LLMs）擅长对话，使人机交互更加自然和实用。LLMs也擅长将非结构化信息转化为结构化数据，为语音AI应用提供了基础。新一代语音AI代理利用LLMs的会话能力和数据提取能力，创造了全新的用户体验。
- 2. About this guide
- 本指南旨在提供语音AI技术的最新概况，帮助开发者了解构建生产级语音代理的复杂性。构建语音AI应用通常需要依赖框架，但理解各个组成部分如何协同工作至关重要。本文的代码示例使用了Pipecat开源框架，该框架被广泛应用于实时AI领域。
- 3. The basic conversational AI loop
- 语音AI代理的核心任务是倾听人类的语音，并以有用的方式做出回应，然后重复这个过程。目前，生产级别的语音代理通常采用相似的架构，即在云端运行语音代理程序，协调语音到语音的循环。该程序利用多个AI模型，并使用LLM功能调用或结构化输出来与后端系统集成。
- 4. Core technologies and best practices
- 构建语音代理在很多方面与其他AI工程类似，但最大的区别在于延迟。人类期望在对话中得到快速响应，通常为500毫秒，过长的停顿会让人感到不自然。因此，准确测量从最终用户角度出发的延迟至关重要。
- 4.1. Latency
- 构建语音代理与构建其他类型的AI工程相似，但最大的区别在于延迟，人类期望快速响应，通常为500ms。准确测量延迟至关重要，建议目标为800ms的语音到语音延迟。通过优化模型和基础设施，Pipecat代理已实现500ms延迟。
- 4.2. LLMs for voice use cases
- GPT-4的发布开启了语音AI的新纪元，GPT-4o是目前语音AI的主流模型，其他模型也在不断进步。语音AI对LLM的要求很高，通常需要使用最佳模型，Gemini 2.0 Flash因其速度快、指令遵循好和价格优势而备受关注。LLM的延迟、成本和开源性是选择模型的重要因素。
- 4.2.1 LLM Latency
- LLM的延迟是语音AI的关键因素，500ms或更短的time-to-first-token (TTFT) 对于大多数语音AI用例来说是足够的。GPT-4o和Gemini Flash的TTFT通常在400-500ms之间。Claude Sonnet 3.5虽然性能优秀，但延迟较高。
- 4.2.2 Cost comparison
- LLM的推理成本在不断下降，Gemini 2.0 Flash的价格比GPT-4o降低了10倍。会话成本随着会话时长的增加而超线性增长，可以通过缓存和上下文总结等技术来降低成本。OpenAI的自动token缓存功能值得推荐。
- 4.2.3 Open source / open weights
- Meta的Llama 3.3和4.0在基准测试中表现优于GPT-4，但对于商业用例，除非必须本地运行LLM，否则不如GPT-4o和Gemini。预计2025年开源模型将取得更多进展，Llama 4是一个很好的起点，未来来自阿里巴巴、DeepSeek、谷歌和微软的开源模型也将成为语音AI的良好选择。
- 4.2.4 What about speech-to-speech models?
- 语音到语音模型是一种令人兴奋的新发展，它可以直接使用音频进行提示并生成音频输出，从而消除了语音到文本和文本到语音的环节。语音到语音模型的潜在优势包括更低的延迟、更好的理解能力和更自然的语音输出。然而，目前的语音到语音模型和API尚未成熟到足以满足大多数生产语音AI用例的需求。
- 4.3. Speech-to-text
- 语音转文本是语音AI的“输入”阶段，也称为转录或ASR（自动语音识别）。对于语音AI用例，我们需要非常低的转录延迟和非常低的词错误率。然而，优化语音模型以降低延迟会对准确性产生负面影响。
- 4.3.1 Deepgram
- Deepgram是目前大多数生产语音AI代理使用的语音转文本服务，它在低延迟、低词错误率和低成本方面表现出色。Deepgram的模型可以通过API或Docker容器的形式使用，通常用户首先通过API使用Deepgram的语音转文本功能，其TTFT通常为150ms。
- 4.3.2 Prompting can help the LLM.
- Deepgram转录错误通常是由于实时流中可用的上下文信息非常少造成的。LLM可以通过访问完整的对话上下文来解决转录错误，例如，可以告诉LLM输入是用户语音的转录，并据此进行推理。
- 4.3.3 Other speech-to-text options
- 预计2025年语音转文本领域将出现许多新进展，包括OpenAI发布新的语音转文本模型、Gladia在法语语音AI中的广泛应用、Speechmatics和AssemblyAI开始关注对话语音用例、NVIDIA发布开源语音模型以及Groq托管的Whisper Large v3 Turbo实现低于300ms的TTFT。大型云服务也提供语音转文本API，但目前不如Deepgram。
- 4.3.4 Transcribing with Google Gemini
- 利用Gemini 2.0 Flash的优势，可以使用Gemini 2.0同时进行对话生成和转录。通过运行两个并行推理过程，一个生成对话响应，另一个转录用户语音，可以实现最佳效果。在每个对话轮次结束时，将用户音频上下文条目替换为该音频的转录。
- 4.4. Text-to-speech
- 文本转语音是语音到语音处理循环的输出阶段。语音AI开发者根据语音的自然程度、延迟、成本、语言支持、单词级时间戳支持以及自定义语音的能力来选择语音模型/服务。
- 语音选项在2024年显著扩展，涌现出新的初创公司，最佳语音质量大幅提高，每个提供商都提高了延迟。与语音转文本一样，所有大型云提供商都有文本转语音产品，但大多数语音AI开发者没有使用它们，因为初创公司的模型目前更好。
- 4.5. Audio processing
- 一个好的语音AI平台或库会隐藏音频捕获和处理的复杂性。但如果构建复杂的语音代理，最终会遇到音频处理中的错误和极端情况。因此，有必要快速了解音频输入管道。
- 4.5.1 Microphones and automatic gain control
- 如今的麦克风是极其复杂的硬件设备，与大量的底层软件相结合。通常情况下，这是非常棒的——我们可以从内置于移动设备、笔记本电脑和蓝牙耳机中的微型麦克风获得出色的音频。但有时这种底层软件并不能满足我们的需求。
- 4.5.2 Echo cancellation
- 如果用户将手机放在耳边，或者戴着耳机，则无需担心本地麦克风和扬声器之间的反馈。但是，如果用户正在使用扬声器电话，或者使用没有耳机的笔记本电脑，那么良好的回声消除就非常重要。
- 4.5.3 Noise suppression, speech, and music
- 用于电话和WebRTC的音频捕获管道几乎总是默认为“语音模式”。语音比音乐可以压缩更多，并且噪声降低和回声消除算法更容易为窄带信号实现。
- 4.5.4 Encoding
- 编码是将音频数据格式化以便通过网络连接发送的一般术语。实时通信的常见编码包括：16位PCM格式的未压缩音频、Opus和G.711。
- 4.5.5 Server-side noise processing and speaker isolation
- 语音转文本和语音活动检测模型通常可以忽略一般的环境噪声，因此对于许多人与人之间的用例至关重要的传统“噪声抑制”算法对于语音AI并不那么重要。但是，一种音频处理对于语音AI特别有价值：主扬声器隔离。
- 4.5.6 Voice activity detection
- 语音活动检测阶段是几乎每个语音AI管道的一部分。VAD将音频段分类为“语音”和“非语音”。我们将在下面的“转弯检测”部分详细讨论VAD。
- 4.6. Network transport
- 网络传输是语音AI的重要组成部分，WebSockets和WebRTC是常用的音频流传输技术。WebSockets适用于服务器之间的通信，而WebRTC更适合客户端与服务器之间的实时媒体连接。HTTP仍然在语音AI中发挥作用，但QUIC有望成为未来媒体流传输的重要协议。
- 4.6.1 WebSockets and WebRTC
- WebSockets和WebRTC都被AI服务用于音频流传输。WebSockets非常适合服务器到服务器的用例。它们也适用于延迟不是主要问题的用例，并且非常适合原型设计和通用黑客攻击。
- 4.6.2 HTTP
- HTTP对于语音AI仍然有用且重要！HTTP是互联网上服务互连的通用语言。REST API是HTTP。Webhooks是HTTP。
- 4.6.3 QUIC and MoQ
- QUIC是一种新的网络协议，旨在成为最新版本HTTP（HTTP/3）的传输层，并灵活地支持其他互联网规模的用例。
- 4.6.4 Network routing
- 无论底层网络协议是什么，长途网络连接对于延迟和实时媒体可靠性都是有问题的。对于实时媒体传输，您希望您的服务器尽可能靠近您的用户。
- 4.7. Turn detection
- 轮流检测是指确定用户何时完成讲话并期望LLM做出响应。在学术文献中，这个问题的各个方面被称为短语检测、语音分割和端点检测。
- 4.7.1 Voice activity detection
- 目前，语音AI代理进行轮流检测的标准方法是假设长时间的停顿意味着用户已经完成讲话。语音AI代理管道使用小型、专门的语音活动检测模型来识别停顿。
- 4.7.2 Push-to-talk
- 基于语音停顿进行轮流检测的明显问题是，有时人们会停顿但并未完成讲话。个人说话风格各异。人们在某些类型的对话中比其他对话中停顿更多。
- 4.7.3 Endpoint markers
- 您还可以使用特定单词作为回合结束标记。（想想卡车司机在CB无线电上说“over”。）识别特定端点标记的最简单方法是针对每个转录片段运行正则表达式匹配。
- 4.7.4 Context-aware turn detection
- 当人类进行轮流检测时，他们会使用各种线索：识别诸如“um”之类的填充词，这些词可能表示持续的语音。语法结构。了解模式，例如电话号码具有特定数量的字母。
- 4.8. Interruption handling
- 中断处理是指允许用户中断语音AI代理。中断是对话的正常组成部分，因此优雅地处理中断非常重要。要实现中断处理，您需要管道的每个部分都可以取消。
- 4.8.1 Avoiding spurious interruptions
- 值得注意的是，有几个意外中断的来源。被归类为语音的瞬态噪声。良好的VAD模型在将语音与“噪声”分离方面做得非常出色。
- 4.8.2 Maintaining accurate context after an interruption
- 由于LLM生成输出的速度快于实时，因此当发生中断时，您通常会有LLM输出排队等待发送给用户。通常，您希望对话上下文与用户实际听到的内容相匹配（而不是您的管道生成的速度快于实时的内容）。
- 4.9. Managing conversation context
- LLM是无状态的。这意味着对于多轮对话，您需要将所有以前的用户和代理消息以及其他配置元素反馈给LLM，以便每次生成新的响应。
- 4.9.1 Differences between LLM APIs
- 这种通用设计对于当今所有主要的LLM都是相同的。但是，各种提供商的API之间存在差异。OpenAI、Google和Anthropic都具有不同的消息格式，工具/功能定义的结构差异以及指定系统指令的方式差异。
- 4.9.2 Modifying the context between turns
- 必须管理多轮上下文会增加开发语音AI代理的复杂性。另一方面，追溯修改上下文可能很有用。对于每个对话轮次，您可以准确地决定要发送给LLM的内容。
- 4.10. Function calling
- 生产语音AI代理严重依赖LLM函数调用。函数调用用于：获取信息以进行检索增强生成。与现有后端系统和API交互。
- 4.10.1 Function calling reliability in the voice AI context
- 随着语音AI代理被部署用于越来越复杂的用例，可靠的函数调用变得越来越重要。SOTA LLM在函数调用方面越来越好，但是语音AI用例倾向于将LLM函数调用能力扩展到其极限。
- 4.10.2 Function call latency
- 函数调用会增加延迟，原因有四个：当LLM确定需要函数调用时，它会输出一个函数调用请求消息。您的代码然后执行特定于所请求函数的任何操作，然后再次调用推理，并带有相同的上下文以及函数调用结果消息。
- 4.10.3 Handling interruptions
- LLM经过训练，可以期望函数调用请求消息和函数调用响应消息作为匹配对。这意味着：您需要停止语音到语音推理循环，直到所有函数调用完成。
- 4.10.4 Streaming mode and function call chunks
- 在语音AI代理代码中，您几乎总是以流模式执行对话推理调用。这使您可以尽快获得前几个内容块，这对于语音到语音的响应延迟非常重要。
- 4.10.5 How and where to execute function calls
- 当LLM发出函数调用请求时，您该怎么办？以下是一些常用的模式：直接在您的代码中使用与请求的函数同名的函数调用。
- 4.10.6 Asynchronous function calls
- 有时您不想立即从函数调用返回。您知道您的函数将花费不可预测的长时间才能完成。也许它根本不会完成。
- 4.10.7 Parallel and composite function calling
- 并行函数调用意味着LLM可以在单个推理响应中请求多个函数调用。复合函数调用意味着LLM可以灵活地连续调用多个函数，将函数链接在一起以执行复杂的操作。
- 4.11. Multimodality
- LLM现在除了文本之外，还可以消费和生成音频、图像和视频。我们之前讨论过语音到语音模型。这些模型能够将音频作为输入并生成音频作为输出。
- SOTA模型的多模态能力正在迅速发展。GPT-4o、Gemini 2.0和Claude Sonnet 3.5都具有非常好的视觉能力，它们都接受图像作为输入。
- 5. Using multiple AI models
- 当今的生产语音AI代理结合使用了多个深度学习模型。典型的语音AI处理循环使用语音转文本模型转录用户的语音，将转录的文本传递给LLM以生成响应，然后执行文本转语音步骤以生成代理的语音输出。此外，许多生产语音代理今天以复杂和多样的方式使用多个模型。
- 5.1. Using several fine-tuned models
- 大多数语音AI代理使用来自OpenAI或Google（有时是Anthropic或Meta）的SOTA模型。使用最新的、性能最佳的模型非常重要，因为语音AI工作流程通常位于模型能力的锯齿状前沿。
- 经过微调的模型通常可以“学习”两个重要类别中的内容：嵌入式知识——模型可以学习事实。响应模式——模型可以学习以特定方式转换数据，这也包括学习对话模式和流程。
- 5.2. Performing async inference tasks
- 有时您想使用LLM执行需要相对较长时间才能运行的任务。请记住，在我们的核心对话循环中，我们的目标是响应时间约为一秒（或更短）。
- 5.3. Content guardrails
- 语音AI代理具有几个漏洞，这些漏洞会导致某些用例出现重大问题。提示注入。幻觉。过时的知识。生成不适当或不安全的内容。
- 5.4. Performing single inference actions
- 对于AI工程师来说，学习如何利用LLM是一个持续的过程。该过程的一部分是我们在思考这些新工具时思维方式的转变。
- 5.5. Towards self-improving systems
- 当我们通过API访问SOTA“模型”时，我们不是在访问单个工件。API背后的系统使用各种路由、多阶段处理和分布式系统技术来快速、灵活、可靠地执行推理，并以非凡的规模执行推理。
- 6. Scripting and instruction following
- 一年前，仅仅能够构建能够在自然人类延迟下进行开放式对话的语音代理就令人兴奋了。现在，我们正在部署语音AI代理来执行复杂的现实世界任务。
- 对于当今的用例，我们需要指示LLM在会话期间专注于特定目标。通常，我们需要LLM按特定顺序执行子任务。
- 7. Voice AI Evals
- 一种非常重要的工具是eval，即evaluation的缩写。Eval是机器学习术语，指的是评估系统能力并判断其质量的工具或过程。
- 7.1. Voice AI evals are different from software unit tests
- 如果您来自传统的软件工程背景，那么您习惯于将测试视为（主要是）确定性练习。语音AI需要与传统软件工程不同的测试。
- 7.2. Failure modes
- 语音AI应用程序具有影响我们如何设计和运行eval的特定形状和故障模式。延迟至关重要（因此在文本模式系统中可以接受的延迟对于语音系统来说是失败的）。
- 7.3. Crafting an eval strategy
- 基本的eval过程可以像包含提示和测试用例的电子表格一样简单。一种典型的方法是在每次测试新模型或更改系统的主要部分时运行每个提示，使用LLM来判断响应是否落在预期参数的某个定义范围内。
- 8. Integrating with telephony infrastructure
- 当今增长最快的语音AI用例大多涉及电话呼叫。AI语音代理正在大规模地接听和拨打电话。
- 9. RAG and memory
- 语音AI代理通常从外部系统访问信息。例如，您可能需要：将有关用户的信息纳入LLM系统指令中。检索以前的对话历史记录。
- 10. Hosting and Scaling
- 语音AI应用程序通常具有一些传统的应用程序组件——Web应用程序前端、API端点和其他后端元素。但是，代理进程本身与传统的应用程序组件有很大的不同，因此部署和扩展语音AI面临着独特的挑战。
- 11. What’s coming in 2025
- 说到AI工程的增长，语音AI在2024年实现了巨大的增长，我们预计这种情况将在2025年继续。这种不断扩大的兴趣和采用将在一些重要的核心领域创造持续的进步：来自所有模型构建者和服务提供商的更多延迟优化。
相关工具：
- Pipecat: https://pipecat.ai
- WebRTC For the Curious: https://webrtcforthecurious.com
- Deepgram: https://deepgram.com
- Gladia: https://gladia.io/
- Speechmatics: https://speechmatics.com/
- AssemblyAI: https://assembly.ai/
- Groq: https://groq.com/
- Cartesia
- ElevenLabs
- Rime
- Krisp: https://krisp.ai
- WebTransport: https://w3c.github.io/webtransport/
- llama-stack: https://github.com/facebookresearch/llama-stack
- NeMo Guardrails: https://github.com/NVIDIA/NeMo-Guardrails
- Coval: https://coval.dev
- Pipecat Flows: https://github.com/pipecat-ai/pipecat-flows
参考文献：
- WebRTC For the Curious: https://webrtcforthecurious.com
- New Realtime API Voices and Cache Pricing: https://community.openai.com/t/new-realtime-api-voices-and-cache-pricing/998238
- OpenAI audio API docs: https://platform.openai.com/docs/guides/audio
- Introducing our next-generation audio models: https://openai.com/index/introducing-our-next-generation-audio-models/
- New standard for speech recognition and translation from the NVIDIA NeMo Canary model: https://developer.nvidia.com/blog/new-standard-for-speech-recognition-and-translation-from-the-nvidia-nemo-canary-model/
- Build Fast with Text-to-Speech: https://groq.com/build-fast-with-text-to-speech/
- Realtime Transcription Sessions: https://platform.openai.com/docs/guides/realtime-transcription#realtime-transcription-sessions
- Semantic VAD: https://platform.openai.com/docs/guides/realtime-vad#semantic-vad
- Pipecat open source smart turn detection model: https://github.com/pipecat-ai/smart-turn
- Pipecat code for context-aware turn detection: https://github.com/pipecat-ai/pipecat/blob/main/examples/foundational/22d-natural-conversation-gemini-audio.py
- Pipecat VAD input audio exponential smoothing code: https://dub.sh/voice-agents-030
- Language Models are Few-Shot Learners: https://arxiv.org/abs/2005.14165
- Engineering AI Agents: https://dub.sh/voice-agents-040
- IETF Media Over QUIC working group: https://datatracker.ietf.org/group/moq/about/
- Pipecat Discord: https://discord.gg/pipecat
- Pipecat contributors: https://github.com/pipecat-ai/pipecat/graphs/contributors
- A Comprehensive Survey of Few-shot Learning
原文链接： https://voiceaiandvoiceagents.com/
一致性检查：
已进行一致性检查，确保整个输出不会出现前后矛盾与原文不符的地方，同时保证段落顺序的一致性。