直播翻译术语表怎么建：识别和翻译两层

术语表是开播前投入产出比最高的一项准备，前提是你配对了地方。它不是一份表，是两份：一份让系统听对这个词，一份让系统译成你要的说法。只做后者是最常见的错误。

两层分别在解决什么

层	输入	它能修的问题	典型实现
识别层	音频	品牌名、型号、生造词被听成别的词	Azure phrase list、Google PhraseSet
翻译层	已识别的文本	词听对了但译法不固定或不该翻	Azure dynamic dictionary、Google glossary

顺序是不可交换的。翻译层拿到的是识别层吐出来的字符串——如果那串字已经错了，翻译层的匹配规则再严密也无从下手。

Google 在语音识别的最佳实践文档里把这个前提写得很清楚：识别器的词汇量很大，但不在词汇表里的术语和专有名词不会被识别出来，所以要用词与短语提示把它们加进去。品牌名恰好是最典型的一类。

识别层：它是运行时偏置，不是训练

两家主流服务的做法是同一个思路，都不需要训练模型：

Azure AI Speech 的 phrase list 在开始识别之前提供一组词或短语，抬高它们被识别出来的概率。官方文档强调它是「just-in-time」的运行时特性，适用于实时转写，批量转写不支持。这一点对直播没有影响，但如果你打算用离线批量转写来做验证，要注意这条路上是没有 phrase list 的。

Google Cloud Speech-to-Text 的模型适配用 PhraseSet 资源承载短语。官方说明里有一条容易被忽略：提供多词短语时，系统不仅更容易按顺序识别出整个短语，也会提高识别出其中单个词的概率。所以「XX 精华二代」这样的完整说法，比拆成三个孤立词条更有用。

权重：官方给的区间，以及为什么不要拉满

这是最容易凭感觉乱调的一处，两家都给了明确数值。

Azure 的 phrase list weight 取值范围是 0.0 到 2.0，1.0 是默认权重，0.0 等于关闭，2.0 是最大影响。这个设置作用于整份列表，不是逐条设置。

Google 的 boost 必须是大于 0 的浮点数，官方标注的实用上限是 20，并且明确建议用二分法去找合适的值，同时在请求里保留带 boost 和不带 boost 两种写法。

真正重要的是官方文档里紧跟着的那句话：boost 越高，误识别为该词的概率也越高。 这解释了一个很常见的现象——加了术语表之后，品牌名对了，但别的地方冒出了新错误。发音接近的普通词被系统优先替换成了术语表里的条目。

所以调法是：先用默认权重，只有确认某个词仍然听不对时再单独提权，每次提完都要回归验证一遍。

翻译层：固定译法，或者干脆别翻

翻译层的能力边界比很多人以为的窄，值得逐条对照官方说明。

Azure Translator 的 dynamic dictionary 允许在请求文本里内联标注译法，写法是 <mstrans:dictionary translation="译文">原文</mstrans:dictionary>。它有两条硬性要求：源语言必须显式传 From 参数、不能用自动检测；源语言和目标语言之中必须有一个是英语。更关键的是文档里的这句限定——这个功能只对专有名词、产品名这类复合名词是安全的。也就是说，指望用它去固定一句口头禅或者一个动词短语的译法，是在用错工具。

Google Cloud Translation 的 glossary 是独立的资源，支持两种形态：单向词表（指定一个源语言到目标语言的译法）和等价词集（同一个词在多种语言里的对应写法）。有两个细节会直接影响命中率：

• 默认区分大小写。 你可以在应用词表时对全部条目忽略大小写，但如果表里既有需要区分的也有不需要的，官方建议保留默认行为，并把需要忽略大小写的词按两种写法都收进去。
• 停用词会被跳过。 Cloud Translation 有一份停用词名单，落在名单上的词即使写进了词表，匹配也会被忽略。

完全不翻译是另一条路。Azure 提供了 notranslate 类名和 translate="no" 属性两种标注方式，但官方注明这两种写法只在输入的 textType 设为 HTML 时生效——这是按设计如此，纯文本模式下写了也不起作用。

一条术语该记什么

一条有用的术语记录不止「原文—译文」两列。按上面两层的能力，至少要有四列：

列	作用	例子
标准写法	识别层期望输出的形态	品牌的正式中文名
常见误识	用来判断这条是否命中	上一场里它被听成了什么
是否翻译	决定走 dictionary 还是走不翻译标注	品牌名通常保留原样
固定译法	需要翻译时的唯一写法	目标语言里的官方叫法

「常见误识」这一列不是给系统用的，是给你自己用的：它是判断这条术语有没有生效的唯一依据。没有这一列，你只能凭感觉说「好像准了一点」。

规模控制

术语表不是越大越好，两家的官方文档都给了信号。

Azure 直接写了建议值：单份 phrase list 不应超过 500 条，需要更大规模的词表时应当转向自定义模型（Custom Speech）而不是继续往列表里加。Google 那边没有给同样直白的软上限，但 boost 会提高误识率这条本身就是规模的天花板——词条越多，互相干扰的机会越多。

实践上的判断标准很简单：一条术语如果连续三场都没有在直播里出现过，就该从表里删掉。 它对准确率没有贡献，只在增加误触发的面积。

怎么验证它真的生效了

不要靠开播时的主观感受，用一段固定音频做回归：

1. 从真实直播里截取一段包含全部目标术语的音频，五到十分钟即可；
2. 人工写出这段音频的准确文本，作为参照；
3. 在不加术语表的条件下跑一遍识别，导出结果；
4. 加上术语表再跑一遍，导出结果；
5. 对比两份结果里的三类变化：目标术语是否改对了、原本正确的词有没有被带错、译文里的品牌名是否统一。

第 4 步里的第二项才是重点。只统计「新加的词命中了几个」会系统性地高估术语表的收益，而偏置带来的新错误恰恰分布在你没有关注的地方。

跑完这一轮，你会得到一个具体的判断：这份术语表值不值得继续加词，还是已经到了该改用自定义模型的规模。