面向低资源语言的AI语音技术栈选择：以阿塞拜疆语为例

2026年7月6日

每个实时语音AI演示都是用英语运行的。延迟神奇，轮换感觉像人类，供应商的定价页面有让CFO满意的计算器。但当你改变一个参数——用户实际使用的语言——你上个月做的整个技术栈评估就毫无价值了。

我在为阿塞拜疆的一家金融控股公司构建AI面试平台时发现了这一点。阿塞拜疆语约有2400万使用者，采用拉丁字母，形态清晰。它并非小众语言，但在唯一重要的意义上属于低资源语言：所有主要STT和语音转语音模型的训练语料库中转录语音数据的数量。

这一事实重塑了整个架构决策：

语音转语音模型（OpenAI Realtime、Gemini Live）提供最佳延迟和最自然的对话，但你受制于模型的语言覆盖范围，当它不覆盖时无法更换组件。

级联流水线（LiveKit、Pipecat、Vapi配合自定义供应商）允许你插入任何能找到的STT/TTS，但你需要自己处理延迟预算、语音检测逻辑以及整合存在的阿塞拜疆语语音模型。

在高资源语言中，这只是偏好问题。在低资源语言中，这是一条岔路：一条路可能根本行不通，另一条路可能只在生产环境中才能发现其糟糕表现，而那时已有真实候选人在真实电话线上。

这篇文章是我希望在我开始之前就存在的评估：实际上什么会崩溃，在哪个技术栈中，以及适用于任何演示未涵盖的语言的决策框架。

语音转语音路径——很好，直到它失效

从每个人都希望可行的选项开始：一个单模型接收音频并输出音频。OpenAI Realtime和Gemini Live。无需组装流水线，亚秒级响应，自然中断处理免费。

吸引力是真实的。在英语中，两者都是该领域最接近解决方案的存在。所以第一个问题不是“哪个更好”，而是“它们真的会说阿塞拜疆语，还是只是声称会？”

存在不同的失败级别，供应商文档只告诉你第一级：

未列出。语言不在支持页面上。简单——你结束了。

列出但降级。语言“支持”，在干净、慢速语音上理解良好，但在电话质量音频、地区口音、俄语代码切换（每个真实阿塞拜疆语使用者都会做的）、领域词汇时崩溃。这是会在生产环境中杀死你的级别，因为你的演示会通过。

不对称。模型理解语言，但以外国口音、错误重音模式或漂移音系输出。对于面试平台，听起来像外国人的机器人对候选人来说是可信度问题。

我的发现：

OpenAI Realtime：在级别3失败。理解尚可，但输出的阿塞拜疆语有扭曲口音——错误音系、错误重音。对于随便使用，可以容忍。但对于在金融机构进行面试的系统来说，是致命的：候选人在第一句话就听出口音，这为之后的一切定下基调。没有语音调整或发音控制可以解决——失败在于模型，而模型不是你的。

Gemini Live：惊喜。理解和输出质量真的很好——它通过了所有三个级别。但杀死它的是我自己分类中遗漏的第四个失败模式：延迟。响应延迟足够长，打破了对话节奏。在聊天界面中只是一个旋转图标；在语音中，候选人会想知道是否掉线，然后打断模型，轮换从此崩溃。实时语音有严格的感知预算——一旦超过，其他地方的品质就不再重要。

因此，2026年中的语音转语音得分榜：一个模型说得不好，一个说得很好但太慢。两种失败都无法从API端修复。这是你对语音转语音做出的结构性赌注——当它有效时，是最佳选项；当它在任何维度上错过你的语言时，你只能等待别人的路线图。

这迫使你走上另一条路：自己组装流水线。

级联路径——你拥有每一毫秒

如果语音转语音对你语言无效，后备方案是经典流水线：语音活动检测→语音转文本→LLM→文本转语音，由编排层拼接。卖点是控制：每个组件都可更换，所以如果一个环节不支持阿塞拜疆语，你替换那个环节而不是放弃整个技术栈。

但问题在于，这个卖点假设替换部件存在。所以，在比较编排器之前，先进行组件搜索——因为如果没有可用的阿塞拜疆语STT或TTS，编排器比较就是装饰。

对于阿塞拜疆语，2026年中，搜索比一年前更令人鼓舞：

TTS：Azure Neural TTS多年来一直提供普遍可用的阿塞拜疆语语音——主力选项，企业友好，平淡但可靠。ElevenLabs也支持阿塞拜疆语，包括地区口音适应，价格更高，自然度上限明显更高。

STT：历史上是薄弱环节——Whisper技术上包含阿塞拜疆语但其低资源性能像彩票，俄语代码切换会迷惑一切。当ElevenLabs的Scribe将阿塞拜疆语纳入99语言ASR模型，且2026年初Scribe v2增加专门针对代理用例的实时变体时，情况发生了实质性变化——实时是语音代理的硬性要求。

因此，组件存在。你从级联技术栈得到的是使用它们的权利，而你付出的是对延迟预算的所有权。每次交接增加延迟：端点检测、STT最终化、LLM首词生成时间、TTS首字节时间、它们之间的网络跳数。语音转语音模型将这个总和隐藏在一个模型内；在流水线中，你需要工程化它——流式传输每个阶段并重叠一切可能重叠的部分——以回到Gemini无法达到的对话阈值。

编排器选择主要取决于你需要掌握多少工程：

Vapi：托管，最快演示，对低资源语言迫使你调整的细粒度参数（自定义STT/TTS供应商、轮换调整）控制最少。

LiveKit Agents：基础设施级WebRTC加代理框架；控制最多，操作面最大。

Pipecat：开源流水线框架；最大灵活性，社区维护的连接器，你自己运行一切。

我最终选择了LiveKit。两个配置通过测试：Deepgram STT + Cartesia TTS配合Gemini 2.5，以及全ElevenLabs流水线配合Gemini 2.5 Flash——两者对话表现都很好。决定因素是成本：依赖本地组件的设置大约每10分钟对话0.02美元，而ElevenLabs技术栈大约每10分钟0.90美元——约45倍差价，当你大规模面试时就不再是理论问题。

从练习中得出的通用规则：目标语言在训练数据中越少，你被迫在技术栈中下沉越深。高资源语言可以购买抽象层。低资源语言必须在抽象层之下构建。

评估任何演示忽略的语言的技术栈清单

将以上内容压缩成我第一天就会执行的协议，适用于任何语言：

首先测试语音转语音，但要对抗性测试。不是愉快路径——电话质量的8 kHz音频、快速语音、地区口音、本地第二语言的代码切换、你的领域词汇。在四个失败级别上评分每个模型：未列出、列出但理解降级、不对称输出（理解但说得差）、延迟。在供应商语言支持页面上通过是级别零，总共四级。

如果任何级别失败，检查是否可以从API端修复。对于语音转语音，答案几乎总是否定的——一个不可修复的失败，在任何级别，都意味着这条路关闭，无论其余部分多好。

在选择编排器之前进行组件搜索。找到至少一个生产可用的STT和TTS用于你的语言，并确认STT有流式/实时模式——仅批处理转录质量对对话无关。每隔几个月重复此搜索；低资源领域变化很快，去年的结论很可能过时。

预算端到端延迟，而不是每个组件。设置语音到语音目标低于约一秒，将其分配到端点检测、STT、LLM首词、TTS首字节，拒绝任何不能流式的组件。单独良好的组件组成的流水线仍然可能对话死寂。

权衡切换成本，而不仅仅是当前质量。今天的正确答案可能在下个模型更新后变得错误。级联技术栈的真正产品不是质量——而是无需重建即可更换任何环节的选项。在低资源语言中，这个选项值得你为之付出的延迟工程。

元教训：语言支持不是定价页面上的布尔值。它是失败模式的分布，对于世界上大多数语言，只有通过真实使用者的真实音频进行测试，你才能知道自己落在哪里。演示从来不是为你做的。据此构建。

此处描述的模型行为和供应商语言支持反映了我截至2026年中期的测试；两者变化很快——在依赖它们之前请重新验证。