---
title: "直播翻译术语表怎么建：识别和翻译两层"
description: "按各家官方文档说明识别层与翻译层术语表的能力边界、条目数与权重上限，以及只配一层为什么修不好品牌名。"
canonical: https://obstrans.net/zh/blog/live-translation-glossary-setup
language: zh
topic: live-translation
published: 2026-08-08
keywords: 术语表, phrase list, 模型适配, 品牌名翻译, 实时翻译
---

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

> 术语表要在识别层和翻译层各配一份：识别层负责让系统听对词，翻译层负责让它译成固定说法。只配翻译层是最常见的误区，因为识别阶段已经听错的词，翻译层根本匹配不上。

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

## 两层分别在解决什么

| 层 | 输入 | 它能修的问题 | 典型实现 |
| --- | --- | --- | --- |
| 识别层 | 音频 | 品牌名、型号、生造词被听成别的词 | 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 步里的第二项才是重点。只统计「新加的词命中了几个」会系统性地高估术语表的收益，而偏置带来的新错误恰恰分布在你没有关注的地方。

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

## Steps

1. **先从录音里找出真正错的词** — 从上一场直播录一段真实音频，离线跑一遍识别，人工标出错的字词。术语表的条目应该来自这份错误清单，而不是凭印象列出的商品名。
2. **把词加进识别层的提示列表** — Azure AI Speech 对应的是 phrase list，在开始识别前提供，不需要训练模型；Google Cloud Speech-to-Text 对应的是模型适配里的 PhraseSet。两者都是运行时生效的偏置，不是重新训练。
3. **按官方上限调权重，不要一次拉满** — Azure 的 phrase list weight 取值范围是 0.0 到 2.0，默认 1.0，0.0 表示关闭；Google 的 boost 必须大于 0，官方标注的实用上限是 20，并建议用二分法找合适值。
4. **在翻译层把品牌名固定下来** — Azure Translator 可以用 dynamic dictionary 在请求里内联指定译法，Google Cloud Translation 则是建一份 glossary 资源。两者都要求你事先知道想要的译文，而不是让模型自由发挥。
5. **用同一段音频做回归验证** — 配置前后跑同一段录音，对比同一批词的识别与译文结果。只看新加的词是否命中还不够，要确认原本正确的词没有因为偏置而被带错。
6. **每场之后增量维护并控制规模** — 每场直播后从错误清单里补几条、删掉不再出现的条目。Azure 官方建议单份 phrase list 不超过 500 条，超过这个量级就应该转向自定义模型而不是继续堆词条。

## FAQ

### 只配翻译层的术语表行不行？

不行，这是最常见的误区。翻译层的术语表按输入文本做匹配，如果识别阶段已经把品牌名听成了别的词，翻译层拿到的就是错的字符串，匹配不上任何条目。识别层和翻译层必须各配一份。

### 术语表的词条是不是越多越好？

不是。Google 官方在 boost 参数的说明里写得很直接：提高偏置的同时也会提高误识别为该词的概率。词条越多、权重越高，把正常词错误地识别成术语的情况就越多。Azure 则直接给出了单份不超过 500 条的建议。

### 为什么加了术语表反而出现了新的错误？

典型的偏置副作用。系统被要求优先输出术语表里的词，发音接近的普通词就会被替换掉。处理办法是降权重，而不是继续加词。Google 官方建议用二分法找合适的 boost 值，并在请求里同时保留带权重和不带权重的写法。

### 价格和数字能靠术语表固定格式吗？

一般不能。识别服务通常带有逆文本规范化，会把口语数字自动转成书面符号形态，Azure 官方文档明确说明这个过程不可配置。数字的可靠做法是在话术上放慢、必要时重复一遍，而不是指望术语表。