AI语音助手出海：支持希伯来语波斯语乌尔都语

客户打电话来，语音助手听懂了，但转成文字后一团糟：品牌名、产品型号、地名全错。更麻烦的是，当你把业务拓展到以希伯来语、波斯语（波斯语/法尔西语）和乌尔都语为主的市场，这个问题会被放大——不仅因为语言本身复杂，还因为它们属于从右到左（RTL）书写体系，很多团队在“最后一公里”的集成、标点、显示与质检上踩过坑。

这也是为什么我对 Deepgram Nova-3 新增希伯来语（he）、波斯语（fa）、乌尔都语（ur）的支持很看重：它不是“多了三种语言”这么简单，而是让中小企业也能用一套语音识别 API，把语音助手和自动化工作流扩展到中东与南亚的真实业务场景里。

本文放在「人工智能在媒体与内容产业」系列里聊，因为语音转写已经不只是客服工具：它正在成为内容生产、媒体剪辑、用户洞察和内容审核的入口。你把语音变成结构化文本，就等于把“声音”接入了你的内容引擎。

为什么 RTL 语言支持会直接影响你的自动化效率

**答案先说清楚：RTL 语言支持决定了你能不能用同一套语音自动化栈跑通跨市场业务。**一旦你需要为不同语言切不同供应商、不同 SDK、不同标注规范，成本会以“隐形工时”的方式爆炸。

中小企业最常见的失败路径是这样的：

• 客服系统用 A 家语音识别（英文/中文还行）
• 进入以色列或海湾地区后，又接 B 家（阿语/希伯来语）
• 内容团队为了做媒体转写，再接 C 家（批处理更便宜）
• 最后你得到三套计费、三套质量指标、三套词表机制，外加三倍的运维与法务审核

Nova-3 把希伯来语、波斯语、乌尔都语放进同一个平台的意义是：减少“供应商拼接”带来的集成复杂度。从工程管理角度看，这比单点准确率提升更能省钱。

这对媒体与内容团队意味着什么

在内容产业里，语音识别通常被用来做三类事：

1. 媒体转写：访谈、播客、会议、新闻素材快速成稿
2. 内容分析：从大量音频里提取主题、情绪、人物、品牌提及
3. 内容审核与合规：在呼叫录音或UGC语音里识别敏感词、投诉点、风险表达

当语言覆盖不全时，你的内容管线会被迫分叉；管线一分叉，数据就难以统一沉淀，后续训练推荐、用户画像与内容治理都会受影响。

三种新增语言，分别解决哪些真实场景

**结论：这三种语言覆盖了大量跨境电商、客服外包、媒体机构与本地化团队的关键市场。**而且它们的“口语习惯 + 书写体系 + 专有名词”组合，正是语音识别最容易翻车的地方。

希伯来语（he）：以色列市场的客服与企业系统

希伯来语全球使用者超过 1000 万，在以色列的商业、媒体和数字沟通里是绝对主力。对很多 SaaS、小型跨境电商来说，进入以色列市场最先遇到的往往不是营销问题，而是：

• 客服外呼/来电需要记录与质检
• 语音助手要能识别快速口语、夹杂英文品牌名的表达
• 工单系统要把通话内容自动摘要成可检索的文本

我见过最典型的需求是：把“电话里说的产品型号/序列号”准确转写出来，直接触发售后流程。只要识别错一个字符，自动化工作流就会把工单分配错、配件发错，后面的人工返工更贵。

波斯语（fa）：跨地区媒体与企业运营

波斯语使用者约 1.3 亿，覆盖伊朗、阿富汗、塔吉克斯坦及海外社群。它常见的难点是：表达更依赖上下文，企业对话里会混杂大量外来词、简称与行业术语。

对内容团队来说，波斯语语音转写能直接带来两类收益：

• 媒体素材规模化：把采访音频批量转写并生成时间戳，剪辑效率明显提升
• 舆情与反馈分析：把电话/语音留言汇总成文本后做主题聚类、负面点归因

把语音转成文本后，你就能把它当作“可检索、可标注、可审核”的内容资产，而不是一堆难以复用的音频文件。

乌尔都语（ur）：南亚客服与多语市场的“高吞吐”需求

乌尔都语使用者超过 2.3 亿，在南亚商业、媒体与客服场景非常常见。它使用 Nastaliq 书写体系，并受波斯语和阿拉伯语影响较深，专有名词与外来词也很多。

乌尔都语最典型的企业需求往往是“量大”：

• 电商订单咨询与退换货
• 金融/保险的电话核验与录音留存
• 呼叫中心质检与坐席培训

这类场景需要的是生产级稳定性 + 可控的术语偏置，不然你每天都会被“错误转写导致的误判”拖慢。

Keyterm Prompting：让语音助手听懂你的品牌词

**一句话：Keyterm Prompting 是不训练模型也能提高业务词命中率的办法。**对中小企业尤其友好，因为你不想维护一套复杂的自定义词表训练流程。

在呼叫中心和媒体转写里，真正决定可用性的往往不是日常词，而是这些：

• 品牌名、产品线、SKU、型号
• 人名、地名、门店名
• 行业术语（保险条款、药品名、金融产品名）

Keyterm Prompting 的价值在于“推一把模型”：在推理时动态告诉系统你希望哪些词被更认真对待。对 RTL 语言来说，这个能力更关键，因为许多专有名词会混写英文或音译，容易被识别成相近发音的常见词。

我对语音项目的判断标准很简单：如果一个方案不能稳定识别你最在乎的 50 个词，它就不适合进生产。

把 Keyterm Prompting 接到自动化工作流里

在「AI 语音助手与自动化工作流」的语境下，你可以把提示词做成“业务配置”，而不是写死在代码里：

1. 每个业务线维护自己的关键词列表（例如“售后/物流/财务”）
2. 来电识别到意图后，动态切换对应的 Keyterm Prompting
3. 转写结果进入工单系统与知识库，自动打标签、自动摘要

这样做的好处是：当你上新产品或更换品牌策略时，不需要重新训练模型，只要更新关键词配置即可。

开发与落地：一套 API 覆盖实时与批量

**直接答案：同一套 Nova-3 API 支持实时流式转写和批处理转写，语言切换只需要换语言代码。**这对小团队很重要——你不想为“客服实时字幕”和“媒体批量转写”维护两套系统。

你可以用同样的请求结构，把 language 改成 he/fa/ur：

curl --request POST \
  --header "Authorization: Token YOUR_DEEPGRAM_API_KEY" \
  --header "Content-Type: audio/wav" \
  --data-binary @youraudio.wav \
  "https://api.deepgram.com/v1/listen?model=nova-3&language=he"

我建议的上线顺序（别一口气全量切换）

想把多语言语音识别放进生产，我更推荐这套节奏：

1. 选 1 个高价值流程：例如“客服通话自动摘要 + 工单字段回填”
2. 定义 3 个指标：WER（或更贴近业务的“关键字段准确率”）、人工返工率、平均处理时长 AHT
3. 先做 5% 流量灰度：用真实来电数据对比旧方案
4. 把错误分成两类：通用识别错误 vs 业务词错误（后者优先用 Keyterm Prompting 修）

对内容团队也一样：先从“每周固定栏目/固定主播”的素材做起，术语更稳定，收益更快。

常见问题：多语言语音识别做不好，问题通常不在模型

**核心观点：80% 的质量问题来自数据与流程，而不是“模型不行”。**下面是我最常见的排查清单，尤其适合 RTL 语言项目。

1）你在评估“可用性”，还是只看 WER？

WER（词错误率）有参考价值，但业务更在乎：

• 订单号/手机号/地址等字段是否正确
• 品牌词、产品词是否命中
• 句子边界与标点是否足够好，能不能直接进摘要模型

建议你额外定义一个指标：Top 50 关键术语命中率。这比只盯 WER 更接近 ROI。

2）RTL 文本在你的系统里显示正常吗？

很多团队忽略了“显示与存储层”的 RTL 支持：

• 数据库与前端是否正确处理 RTL 排版
• 混写英文数字时是否出现顺序错乱
• 导出到 CSV/BI 报表是否可读

如果这些没处理好，识别再准也会在交付层面翻车。

3）你有没有把转写接进内容管线？

在「人工智能在媒体与内容产业」里，语音转写的正确打开方式是：

• 转写 → 分段与时间戳 → 摘要/标题生成 → 主题标签 → 推荐与搜索

当这条链路跑通，你会发现语音不再是“成本中心”，而是内容资产的入口。

下一步：让语音助手真正“会说客户的语言”

希伯来语、波斯语、乌尔都语加入 Nova-3 这种企业级语音识别平台，对中小企业是个很现实的利好：更少的供应商、更少的集成分叉、更快把语音接入自动化工作流。如果你正在做跨境客服、媒体转写或语音内容分析，这三种 RTL 语言会直接决定你的覆盖面。

如果你要立刻行动，我建议从一个小但闭环的场景开始：选一条业务线，拿真实录音做灰度评测，重点盯“关键术语命中率”和“人工返工率”。然后用 Keyterm Prompting 把最痛的专有名词问题先解决。

当语音助手能稳定听懂客户的语言，你会把更多精力放回到真正值得做的事：产品、服务、内容本身。下一次你准备进入一个新市场时，你的第一个问题会变成——我们的自动化栈，能在一周内支持这门语言吗？