第四章:采集人员与话术设计

好,咱们接着聊。上一章讲了采集设备怎么搭,这一章咱们聊聊「人」和「话」。

说实话,很多团队在车载语音项目上栽跟头,不是技术不行,而是人没找对,话术没设计好。我见过一个项目,采集了500小时的方言数据,结果模型训练出来,唤醒率不到60%。为什么?因为所有发音人都是20多岁的年轻人,说的都是「标准方言」——你想想看,真实开车场景里,哪有那么多年轻人?

4.1 发音人招募:别只盯着「好找」的人

发音人招募,说白了就是找「真人」。但真人之间差别太大了。

4.1.1 年龄分层:覆盖全生命周期

我个人习惯把年龄分成四层:

年龄段 占比建议 典型特征
18-25岁 20% 语速快,爱用网络词,发音清晰
26-40岁 40% 主力驾驶人群,语速适中,用词规范
41-55岁 30% 语速偏慢,可能有口音,音量不稳定
55岁以上 10% 语速明显慢,常有颤音,方言更重

我在项目中遇到过一件事:一个55岁的大叔,说「导航到火车站」,结果「站」字发音特别轻,几乎听不见。模型一开始死活识别不出来。后来我们专门补采了一批中老年数据,问题才解决。

注意: 千万别只招大学生!他们好找、便宜,但数据偏差会让你后期付出更大代价。

4.1.2 性别平衡:别让模型「重男轻女」

男女比例建议6:4或5:5。为什么?因为女性发音的基频更高,共振峰分布和男性差异很大。如果女性数据太少,模型对女声的识别率会明显下降。

我记得有一次,客户反馈说「我家女主人说话车机不理」。一查数据,女性发音人只占15%。嗯,这就是教训。

4.1.3 方言覆盖:不是越多越好

很多新手觉得「方言越多越好」,其实不是。车载场景下,方言覆盖要讲究「精准」。

  • 核心方言: 北方官话(占比50%以上)、西南官话、吴语、粤语
  • 次要方言: 闽语、客家话、湘语、赣语
  • 特殊方言: 根据车型销售区域决定(比如卖到四川的车,四川话必须重点覆盖)

我曾经犯过一个错:为了追求方言种类,每个方言只录了5个人。结果模型训练出来,每种方言都「半生不熟」。后来我学乖了——宁缺毋滥,每种方言至少20人,才能保证数据质量。

小技巧: 招募时让发音人先录一段30秒的自由说话,听听口音纯不纯。有些人自称「会说方言」,其实已经「普通化」了。

4.2 话术设计:脚本是数据的灵魂

话术设计,说白了就是「让发音人说什么」。这部分我踩过不少坑,分享几个关键点。

4.2.1 唤醒词脚本:简单但要有变化

唤醒词一般就几个词,比如「你好,小X」「小X同学」。但设计时要注意:

  • 不同语速: 正常语速、快速、慢速各占1/3
  • 不同距离: 近场(30cm)、中场(1m)、远场(2m+)
  • 不同情绪: 平静、急切、不耐烦(模拟真实驾驶场景)

举个例子,唤醒词脚本可以这样设计:

# 唤醒词采集脚本示例
## 第一部分:标准唤醒(每人20遍)
1. 你好小X(正常语速)
2. 你好小X(快速)
3. 你好小X(慢速,带拖音)

## 第二部分:变体唤醒(每人10遍)
1. 小X同学(正常)
2. 小X小X(快速重复)
3. 嘿小X(带语气词)

我建议每个发音人至少录30遍唤醒词。为什么?因为唤醒词是模型的第一道门槛,数据量不够,误唤醒率会很高。

4.2.2 命令词脚本:覆盖高频场景

命令词是车载语音的核心。我一般按场景分类:

场景 示例命令 采集数量
导航 导航到XXX、我要去XXX、附近加油站 50条/人
音乐 播放XXX、下一首、音量调大 30条/人
电话 打电话给XXX、接听、挂断 20条/人
空调 温度调低、风量大点、吹脚 20条/人
车窗 打开车窗、天窗翘起、全关 15条/人

这里有个坑:很多人只录「标准命令」,比如「导航到天安门」。但真实场景里,用户会说「我要去天安门」「天安门怎么走」「帮我导航到天安门」。这些变体必须覆盖。

核心原则: 每个命令词至少设计3-5种自然语言变体。别让模型只会「听标准话」。

4.2.3 自由对话脚本:模拟真实交互

自由对话是最难设计的,但也是最有价值的。我一般用两种方式:

  1. 场景引导法: 给发音人一个场景,让他自由发挥。比如「你刚下班,很累,想听点轻松的音乐,然后回家」。
  2. 半结构化对话: 设计一个对话框架,但具体内容让发音人自己填。比如「先唤醒,然后说一个导航命令,再说一个音乐命令,最后说一个空调命令」。

我记得有一次,一个发音人在自由对话里说了一句「这破导航,又给我导到死胡同了」。这句话后来成了我们测试集里的经典案例——模型一开始识别成「导航到死胡同」,笑死。

注意: 自由对话时长建议每人5-10分钟。太短了没有统计意义,太长了发音人会疲劳,数据质量下降。

4.3 实战避坑指南

最后,分享几个我踩过的坑:

  • 坑1: 发音人招募时只看「会说」,没看「会演」。有些人读脚本像念课文,完全没有驾驶场景的感觉。我后来加了试录环节,不合格的直接淘汰。
  • 坑2: 话术设计太「书面化」。比如「请将空调温度调节至26摄氏度」——正常人谁这么说话?改成「空调调到26度」就好。
  • 坑3: 忽略了「多轮对话」。很多项目只录单轮命令,结果模型一遇到连续对话就懵。自由对话脚本一定要包含多轮交互。

嗯,这一章就到这里。下一章咱们聊聊采集过程中的质量控制——说白了,就是怎么保证录进来的数据能用。