豆包语音
豆包语音
文档指南
请输入
- 文档首页
豆包语音最佳实践热词与上下文
复制全文
下载 pdf热词与上下文
文档反馈
问问助手本文面向豆包大模型流式语音识别（ASR）的客户和集成开发者，聚焦热词（hotwords）和上下文（context_data）两大能力，帮助你快速理解其作用、限制和正确用法，避免常见误区。
一、热词（hotwords）
1.1 热词的作用
热词用于提升特定专有名词的识别准确率。当你的业务中存在模型不易正确识别的领域词汇（品牌名、产品型号、人名、术语等）时，通过配置热词可以一定程度提升这些词的转写准确率。
核心原则
热词是"提示"而非"强制"。模型会优先考虑热词，但不保证所有热词都 100% 被正确转写。
1.2 两种配置方式
对比项 | Context 直传热词 | 热词表 |
配置方式 | 请求级、细粒度的个性化热词，随每次请求context字段动态传入 | |
双向流式容量 | 100 tokens （从前往后截断） | 100 tokens （从前往后截断） |
非流式/二遍容量 | 5000 个词（每词不限字数） | 5000 个词（单个热词长度，中文是10个字，英文是30个字母） |
优先级 | 高 注意
| 低 |
适用场景 | 适用于用户通讯录、个人私有词等无法预先统一配置，需要随用户或请求实时传入的个性化词汇 | 适用于品牌名称、行业术语等相对固定，需要批量管理并对所有调用方统一生效的通用词汇 |
1.3 Context 直传热词示例
在请求的 corpus.context 字段中，按以下格式传入热词：
"corpus": {
# === 热词直传 + 上下文（写在同一个 context 字段中） ===
"context": "{\"hotwords\":[{\"word\":\"豆包\"},{\"word\":\"火山引擎\"},{\"word\":\"奥迪A4L\"}],\"context_type\":\"dialog_ctx\",\"context_data\":[{\"text\":\"最近一轮助手的回答\"},{\"text\":\"最近一轮用户的提问\"},{\"text\":\"更早一轮助手的回答\"},{\"text\":\"更早一轮用户的提问\"}]}",
# === 以下为词表方式 ===
# "boosting_table_id": "热词表ID",
# "correct_table_id": "替换词表ID",
# "regex_correct_table_id":"正则替换词表ID"
}
1.4 热词配置最佳实践
应该放什么
- 领域特有的专有名词：品牌名、产品型号、人名、地名、术语等
- 中英混合词汇：如"奥迪A4L"、"iPhone16"，按照希望模型输出的格式添加即可，无需转换为纯中文
- 中文数字混合：如"V8发动机"，直接按期望输出格式添加
不应该放什么
- 通用词汇：如"打开"、"帮我"、"你好"等日常用语
- 过多无关热词：添加过多无关热词会增加误识别风险，模型可能在不该出现热词的地方错误匹配
正确示例
用户说"帮我打开飞书"，只需要添加热词"飞书"即可，不要把"帮我打开"也加进去。
精简原则
- 热词以短语或单词为主，一般 2~6 个字为佳
- 宁缺毋滥：只添加模型容易识别错误的领域词，而非把所有业务词汇都塞进去
- 定期维护：根据实际识别效果增删热词，去掉已经能正确识别的词
1.5 热词 vs 替换词
当热词仍无法满足要求时，可以考虑使用替换词作为补充。替换词是"命中即强替"的规则。
对比项 | 热词 | 替换词 |
机制 | 引导模型优先输出，不保证 100% 命中 | 后处理阶段精确匹配并强制替换 |
示例 | 添加"SU7"→ 模型更可能输出"SU7" | 规则\"苏七\":\"SU7\"→ 识别为"苏七"时强替为"SU7" |
注意 | 作用范围广，可能误触发 | 需枚举所有可能的错误形式（如"苏柒"、"书七"需单独配规则） |
配置方式 | context 直传 / 热词表 | 替换词表（控制台配置 + 接口传 ID） |
1.6 热词效果说明
- 非流式/二遍链路效果优于双向流式链路
- 热词对准确率的提升是概率性的，不是确定性的
- 建议接入后实测，根据效果微调热词列表
1.7 实操建议
- 将难识别的词语添加为热词
对于容易识别错误的词语，首先可以将其添加到热词列表中。热词相当于向 ASR 提供一组需要重点关注的候选词，使模型听到相似发音时，更倾向于输出这些词。
热词主要适用于以下类型：
- 人名、地名和机构名
- 品牌名、产品名和菜品名
- 行业术语、业务黑话和专有名词
- 生僻词、网络用语和近期出现的新词
- 经常被识别成同音词或近音词的表达
- 热词效果不佳时，补充解释信息
有些词即使被添加为热词，识别效果仍可能不理想。常见原因包括：
- 目标字较为生僻；
- 存在多个高频同音词；
- 目标词脱离上下文后缺乏明确含义。
- 此时，可以为热词增加一段容易识别的解释，利用解释中的高频词帮助模型锁定目标字。
- 例如，要识别的词是“逐玉”，可以将孤立的“逐玉”扩充为：
逐玉，追逐的逐，玉石的玉。
其中，“追逐”和“玉石”都是更常见、更容易识别的词。模型可以借助解释建立发音、字形和目标词之间的联系。
类似的表达还有：
- “韬定律，韬略的韬”
- “秧bot，秧歌的秧”
- 这种方式尤其适合人名、生僻字和自造词。
- 为热词补充背景知识
除了直接解释单个字，还可以增加与目标词高度相关的背景，让模型知道这个词属于哪个领域、品牌或话题。
例如，“覃海洋”单独出现时，可能被识别成更高频的“秦海洋”，可以扩充为：
蛙泳冠军覃海洋。
对于“疯四”，可以扩充为：
肯德基的疯四，指疯狂星期四。
- 有条件时，优先传入用户的对话历史
在多轮语音交互中，历史对话通常是最直接、最有效的 Context。用户当前说出的内容往往会延续之前的话题，其中还可能包含省略、指代或重复出现的专有名词。
可作为 Context 的信息包括：
- 助手上一轮的回复
- 用户此前的 ASR 识别结果或纠错文本
- 用户输入的纯文本
- 无法传入对话历史时，提供场景描述
如果系统无法获取多轮对话历史，可以在 Context 中传入简短、明确的场景描述。例如：
这是肯德基点餐场景。用户可能会说菜品名称、套餐名称、数量、规格、堂食、外带、优惠券和支付方式。
还可以增加可能出现的实体类型和表达范围，使 Context 更具体：
这是肯德基点餐场景，可能涉及原味鸡、香辣鸡腿堡、蛋挞、全家桶、疯狂星期四、疯四、堂食、外带和优惠券。
这样做相当于提前为 ASR 划定识别范围。当用户发音不够清楚时，模型可以优先从点餐领域的候选词中进行判断，而不是在所有通用词汇中搜索。
二、上下文（context_data）
2.1 上下文的作用
上下文允许你将对话历史、业务背景信息、个性化信息等传入模型，帮助模型在语音转写时做出更准确的判断。核心原理：
- 当上下文中包含语音中可能出现的词汇时，效果最明显
- 模型具备一定的基于上下文推理的能力，但推理效果不保证，预期优于无上下文输入
2.2 上下文的格式
上下文通过 corpus.context 字段传入，使用 dialog_ctx 类型。context_data 按从新到旧排列，需序列化为 JSON 字符串（转义引号）。
{
"context": "{\"context_type\":\"dialog_ctx\",\"context_data\":[{\"text\":\"最近一轮的回答\"},{\"text\":\"最近一轮的提问\"},{\"text\":\"更早的回答\"},{\"text\":\"更早的提问\"}]}"
}
限制
- 总量限制：800 tokens，20 轮（含）以内
注意
如果传满20轮会对性能有影响，800token以内对延时的影响在平均50-100ms以内。
- 超出限制时：按照从新到旧的顺序截断，优先保留更新的对话
- 图片支持（仅 2.0 模型）：可传入 1 张图片（500KB 以内，jpeg/jpg/png），通过 image_url 字段传入
含图片的示例
{
"context": "{\"context_type\":\"dialog_ctx\",\"context_data\":[{\"text\":\"请描述这张图片\"},{\"image_url\":\"https://example.com/image.jpg\"},{\"text\":\"这是一张产品图片\"}]}"
}
2.3 上下文如何提升准确率
场景一：对话历史中包含正确答案
当用户第一次说某个词被识别错误，但大模型回复中包含了正确写法时，将对话历史传入上下文，后续识别就更可能输出正确结果。
第 1 轮用户："秦海洋最近怎么了？"（ASR 识别错误）
第 1 轮 LLM："覃海洋最近被爆料……"（包含正确写法）
将上述对话传入上下文 → 第 2 轮用户："覃海洋得过冠军吗？"（识别准确率显著提升）
场景二：上下文帮助模型推理
即使上下文中没有直接出现正确词汇，模型也能基于语义关联进行推理。
第 1 轮用户："介绍一下风四活动。"（ASR 识别错误）
第 1 轮 LLM："是肯德基的吗？"（关联信息）
将上述对话传入上下文 →第 2 轮用户："对，介绍一下疯四活动。"（模型基于"肯德基"推理出"疯四"）
2.4 上下文最佳实践
- 优先传入对话历史：多轮对话场景下，把最近几轮对话传入是最直接有效的方式
- 背景信息尽量包含领域词汇：如果知道语音中会出现哪些专有名词，把它们写进背景信息中
- 控制长度：800 tokens 上限不大，传入最相关的信息即可，不要灌入大段无关文本
- 从新到旧排列：context_data 中最新的对话放在最前面，超出限制时系统会截断旧的内容
三、热词 + 上下文的组合使用策略
3.1 推荐组合方式
在实际业务中，热词和上下文通常配合使用效果最佳：
场景 | 推荐方案 |
固定领域词汇（产品名、品牌名） | 热词（直传或热词表） |
多轮对话，纠正前轮识别错误 | 上下文（传入对话历史） |
领域背景 + 专有名词 | 上下文（传业务背景） + 热词（传专有名词） |
动态变化的关键词 | 热词直传（每次请求动态调整） |
3.2 同时传入热词和上下文的示例
"corpus": {
# === 热词直传 + 上下文（写在同一个 context 字段中） ===
"context": "{\"hotwords\":[{\"word\":\"覃海洋\"},{\"word\":\"巴黎奥运会\"}],\"context_type\":\"dialog_ctx\",\"context_data\":[{\"text\":\"覃海洋是中国游泳运动员，曾在巴黎奥运会获得金牌\"},{\"text\":\"介绍一下覃海洋\"}]}",
# === 以下为词表方式 ===
# "boosting_table_id": "热词表ID",
# "correct_table_id": "替换词表ID",
# "regex_correct_table_id":"正则替换词表ID"
}
3.3 注意事项
- 热词直传和上下文可以在同一个 context 字段中同时传入，两者互不冲突
- 上下文 + 热词的组合在非流式/二遍链路中效果最优
四、常见问题与避坑指南
Q1：热词加了很多但效果不好？
- 检查是否添加了过多无关热词，精简到只保留领域专有名词
- 确认热词格式是否正确（中英混合按期望输出格式添加）
- 考虑使用非流式或二遍模式，热词在这些模式下效果更好
Q2：热词和替换词应该用哪个？
- 优先尝试热词，热词是"软引导"，对整体识别准确率影响小
- 如果某个词始终无法正确识别，再使用替换词做"硬替换"
- 替换词需要枚举所有可能的错误形式，维护成本较高
Q3：上下文传了但没有效果？
- 检查上下文是否包含语音中可能出现的关键词汇（这是效果最明显的场景）
- 确认 context_data 的排列顺序（从新到旧）
- 检查是否超出 800 tokens 限制导致关键信息被截断
Q4：context 直传热词的 100 tokens 限制具体是多少词？
- tokens 不等于词数，中文一般 1 个字约占 1~2 个 token
- 建议在双向流式场景下控制在 30~50 个短词以内
- 非流式场景支持 5000 个词，限制宽松得多
Q5：二遍模式下上下文和热词如何生效？
- 一遍（流式）结果：上下文和热词均生效，但流式链路热词效果有限
- 二遍（非流式）结果：上下文和热词效果更优，最终定稿建议以二遍结果为准
五、速查表
参数 | 双向流式 | 非流式/二遍 |
热词直传容量 | 100 tokens | 5000 个词 |
热词表容量 | 100 tokens | 5000 个词 |
上下文容量 | N/A | 800 tokens / 20 轮 |
图片上下文 | N/A | 仅 2.0 模型支持 |
推荐接口 | bigmodel_async | bigmodel_nostream & bigmodel_async |
热词效果 | 有效但有限 | 效果更优 |
最近更新时间：2026.09.29 11:54:59
这个页面对您有帮助吗？
有用
有用
无用
无用