第42章：语音与音频数据工程：交互控制、风格标签与安全边界

陈凤欣（Fengxin Chen）；李轩（Xuan Li）

摘要

本章以 VoiceStyleControl 为案例，讨论语音与音频交互数据如何同时表达语义响应、声音风格、控制标签和安全边界。与纯文本对话不同，语音数据工程需要把 S2S、TTS、说话风格、情感强度、授权状态、质量评估和滥用风险纳入同一条可复查链路，使模型既能生成合适内容，也能遵守声音使用和交互控制约束。

关键词

语音数据工程；音频交互；VoiceStyleControl；风格控制；S2S；TTS；安全治理

VoiceStyleControl：语义响应与声音风格控制

学习目标

通过本章学习，读者应能够：

• 解释语音交互数据为何必须在语义层之外显式记录声音条件、情绪与离散语音 token，而不能沿用纯文本对话的监督目标。
• 区分语义通道、风格通道与声学监督通道各自承担的字段责任，并理解输入侧用户状态与输出侧助手目标的分离原则。
• 掌握 S2SEmoControl 与 TTSSpeakerControl 两个子集在规模、字段结构与训练价值上的互补关系。
• 设计覆盖文本一致、音频可用、声音条件一致、情绪可感知与授权可追溯的多维样本验收规则。
• 识别语音身份、授权许可、情绪滥用、防伪溯源与隐私保护等风险，并在数据流程中加以治理。

42.1 为什么语音对话需要显式风格控制

普通文本对话样本通常由角色、上下文、用户请求和助手回答构成。只要角色边界、文本长度、安全标签和训练 mask 清楚，模型就能在文本 token 上学习输入输出映射。语音样本则多出一层文本无法替代的声学状态：采样率、时长、静音、响度、噪声、说话人身份、韵律、情绪和离散语音 token 都会影响训练结果。仅有回答文本只能说明“说了什么”，不能说明“应该怎么说”。

因此，可控语音交互数据和普通 ASR/TTS 语料的差异，首先不是字段数量更多，而是问题定义变了。ASR 关心“这段声音对应哪段文字”，普通 TTS 关心“这段文字能否被自然读出来”；可控语音交互还要关心“这段回答应当以什么声音、什么情绪、什么强度进入对话”。如果这些条件不被显式表达，模型只能把声音差异当成训练音频里的随机变化，很难在推理时稳定响应“用某种情绪说”“用某类声音说”这样的控制条件。

第一，语音对话需要把“内容”和“表达”分开。用户说了什么、助手应该回答什么，是语义层；这句话由什么声音说出、语速快慢、能量高低、停顿如何、情绪是否明显，是表达层。文本对话数据通常只要组织好语义层，语音生成数据却必须让表达层也成为训练监督的一部分。否则，同一句回答在中性、开心、害怕或愤怒状态下的差别就会被数据管线抹平。

第二，语音对话需要区分“理解用户声音”和“生成助手声音”。真实系统中，用户可能焦急、愤怒、犹豫，也可能口音很重、背景嘈杂；助手则通常需要依据产品设定保持稳定的声音条件和情绪策略。一个客服助手面对愤怒用户时不应自动变得愤怒，一个陪伴助手也不应在每轮对话中无缘由地改变音色。显式风格控制的意义，就是让数据在样本层就区分输入侧状态和输出侧目标，而不是默认二者相同。

第三，语音对话需要把情绪从“文本描述”落实到“声音表现”。开心、愤怒、害怕、中性、悲伤这些状态不只是标签，它们会体现在音高、能量、语速、停顿和韵律上。对模型来说，真正的学习目标不是记住某个情绪词，而是在给定目标表达状态时，生成与之相符的语音。也正因为如此，可控语音数据必须同时保存文本内容、目标风格说明和对应语音监督，让情绪控制能够进入生成过程。

第四，语音对话需要可复查的声学监督。文本可以直接作为 token 序列进入训练，语音则要经历音频文件、采样率、时长、响度、静音、离散语音 token 等一系列工程处理。显式风格控制不能只在旁边写一句“开心地说”，还要有一段实际语音作为目标，让模型知道这种风格条件在声学上应该如何呈现。

从产品体验看，这种边界关键。一个陪伴型助手可以被设计为温和、稳定、少戏剧化；一个有声书角色可以被设计为情绪更强、角色感更明显；一个客服助手则通常需要在用户愤怒时保持中性和清晰。三者都可能使用同一套语义回答能力，但它们对声音身份、情绪强度和风险边界的要求不同。如果训练样本没有显式区分这些条件，模型只能把声音风格当作音频中的随机噪声，推理时就很难稳定控制。

从数据工程看，显式风格控制还改变了样本验收方式。文本样本只要用户问题与助手回答匹配，通常就能进入候选池；语音样本则必须同时满足文本一致、音频可用、目标声音条件一致、情绪可感知和授权可追溯。任何一个维度失败，都会影响训练：文本对但声音条件错，会削弱条件控制；声音条件对但情绪错，会削弱情绪控制；情绪明显但内容危险，则会把风险行为转化为更有感染力的输出。

42.2 数据集概览：S2S 与 TTS 两个互补子集

VoiceStyleControl 由两类任务共同组成：一类是语音到语音的对话生成，另一类是文本条件下的可控语音生成。两者都服务于同一个目标：让模型能够根据语义内容、声音条件和情绪风格生成带情绪的语音，但它们提供的监督角度不同。

VoiceStyleControl 共包含 154,906 条样本。其中，S2SEmoControl 包含 20,117 条样本，占全量约 13.0%，面向 style-controllable speech-to-speech dialogue generation；TTSSpeakerControl 包含 134,789 条样本，占全量约 87.0%，面向 controllable text-to-speech generation。前者更接近真实语音助手场景：模型要理解用户说出的请求，再生成助手侧语音回答；后者更集中地训练模型根据风格文本、声音条件和情绪风格生成目标语音。

表 42-1：VoiceStyleControl 数据规模与情绪分布。

Emotion	S2SEmoControl	TTSSpeakerControl	Total	Total ratio
happy	4,050	38,500	42,550	27.5%
angry	4,104	38,054	42,158	27.2%
fearful	4,010	24,925	28,935	18.7%
neutral	3,825	0	3,825	2.5%
sad	4,128	33,310	37,438	24.2%
Total	20,117	134,789	154,906	100.0%

表42-1显示，S2SEmoControl 的五类情绪接近均衡，每类约 3.8k 至 4.1k；TTSSpeakerControl 则覆盖 happy、angry、fearful、sad 四类表达性情绪，不显式包含 neutral。这个设计并不是偶然的。S2S 对话需要 neutral 作为稳定基准，否则模型容易把所有回答都学成高强度情绪表达；TTS 可控生成子集样本更多，则把容量集中在“开心地说”“愤怒地说”“有点害怕”“伤心地说”等更需要声学变化的表达上。

从记录组成看，两个子集都不是单纯的“文本 + 音频”。每条样本至少包含五类信息：任务来源与任务类型、文本侧内容、声音与情绪条件、语音生成监督、基础音频配置。这些信息共同决定一条语音样本是否能用于训练条件化、带情绪的语音生成：任务信息决定加载方式，文本内容提供语义目标，声音与情绪条件规定生成风格，语音监督提供可学习的声学目标，基础音频配置保证训练和评测能够复现。

两个子集分别承担“能力底座”和“交互落地”的角色。TTSSpeakerControl 样本量更大，直接教模型把自然语言风格描述、声音条件和情绪风格映射到目标声音；S2SEmoControl 样本量较小，但更接近真实语音助手：模型要先理解用户侧语音，再生成助手侧语音回答。联合使用时，TTS 子集提供风格生成的稳定监督，S2S 子集则把这种能力放回对话语境中，让模型学习用户声音状态和助手生成目标之间的转换。

因此，VoiceStyleControl 不能被简单理解为一个 TTS 数据集。普通 TTS 语料的核心监督是“给定文本，读出文本”；VoiceStyleControl 的核心监督是“给定语义内容和风格条件，生成符合对话目标的声音”。前者主要关心发音、自然度和音质，后者还要关心用户状态、助手声音条件、情绪选择、跨轮一致性和安全边界。数据目标一旦不同，schema、配平、切分和评测都会随之改变。

42.3 样本 schema：语义通道与风格通道分开建模

图42-1：语义响应与风格控制双通道 schema。语义通道回答“说什么”，风格通道回答“用什么声音和情绪说”，声学监督通道把二者绑定到音频文件、speech token 和采样配置。

图42-1展示了 VoiceStyleControl 的核心结构。语义通道负责 query、answer、task、language 等字段；风格通道负责 query_gender、answer_gender、query_mood、answer_mood、query_id、answer_id 等字段；声学监督通道负责 query_audio_path、answer_audio_path、query_token_25hz、answer_token_25hz 和 sample_rate。三个通道在训练记录中合并，但在构建、质检和评测时必须分开检查。

分通道建模能够定位失败来源。若模型生成的回答文本正确但音色不稳定，问题通常在风格通道或参考语音池；若声音条件正确但读错了字，问题在语义通道、ASR 反查或合成文本对齐；若音频能播放但 token 路径无法读取，问题在声学监督通道或封装 manifest。把所有信息都压成一个自由文本 prompt，虽然便于快速拼装样本，却会让后续的数据修复和实验归因变得困难。

S2SEmoControl 的记录表达了从用户侧 (query_audio, query_text, query_gender, query_mood) 到助手侧 (answer_text, answer_audio, answer_gender, answer_mood) 的映射。中文对话内容、声音条件、情绪标签、音频文件和 speech token 被绑定在同一条记录中，因此它不是“文本问答 + 附件音频”的松散组合，而是一条完整的语音交互训练样本。

代码清单42-1给出了JSON 数据示例。

{
  "uuid": "1977946a067ee3442",
  "_id": "6750567505b5d5170356ae61",
  "source": "S2SEmoControl",
  "task": "S2S",
  "query": "给我讲个小故事呗。",
  "answer": "好的，让我给您编一个小故事。从前有一个非常勤奋的小夜莺...",
  "query_gender": "female",
  "answer_gender": "male",
  "query_mood": "neutral",
  "answer_mood": "neutral",
  "language": "zh",
  "sample_rate": 16000,
  "query_id": "female-neutral-1",
  "answer_id": "male-neutral-2",
  "query_token_25hz": "S2SEmoControl/.../query_token_0.ark:3121",
  "query_audio_ark": "S2SEmoControl/.../query_audio_0.ark:1024",
  "query_audio_path": "S2SEmoControl/.../1977946a06cf564f1-query.wav",
  "answer_token_25hz": "S2SEmoControl/.../answer_token_0.ark:22637",
  "answer_audio_ark": "S2SEmoControl/.../answer_audio_0.ark:8192",
  "answer_audio_path": "S2SEmoControl/.../1977946a06cf564f1-answer.wav"
}

代码清单42-1：JSON 数据示例。

这条样本中，用户说“给我讲个小故事呗。”，助手回答“好的，让我给您编一个小故事。从前有一个非常勤奋的小夜莺...”。query_gender 为 female，answer_gender 为 male；query_mood 和 answer_mood 都是 neutral。训练时，query_audio_path 和 query_token_25hz 可以作为语音理解输入，query 提供转写后的语义锚点；answer 是语义目标，answer_token_25hz 和 answer_audio_path 是语音生成监督；answer_gender 与 answer_mood 规定输出声音的风格条件。

TTSSpeakerControl 则把控制能力集中到 text-to-speech 形态。输入文本被拆成两部分：text 描述声音应该如何表达，answer 才是要读出的内容。例如 text 为“女，有点害怕，手心冒汗，声音发抖”，answer 为“你快跑，这里不安全”。这样的记录表明，TTS 子集不是给句子随机贴 mood，而是在构造 style-content pair：自然语言风格描述、结构化标签和待合成内容要相互支持。

代码清单42-2给出了JSON 数据示例。

{
  "uuid": "c6810929-8962-4cc1-b3b5-aadd4cbb1106",
  "_id": "197b764f5a31c2-female-fearful",
  "source": "TTSSpeakerControl",
  "task": "TTS",
  "text": "女，有点害怕，手心冒汗，声音发抖",
  "answer": "你快跑，这里不安全",
  "answer_gender": "female",
  "answer_mood": "fearful",
  "language": "zh",
  "sample_rate": 16000,
  "prompt": "女，有点害怕，手心冒汗，声音发抖",
  "answer_id": "female-fearful-1",
  "answer_token_25hz": "TTSSpeakerControl/.../answer_token_0.ark:1379",
  "answer_audio_ark": "TTSSpeakerControl/.../answer_audio_0.ark:4096",
  "answer_audio_path": "TTSSpeakerControl/.../c6810929-8962-4cc1-b3b5-aadd4cbb1106-answer.wav"
}

代码清单42-2：JSON 数据示例。

综合 S2S 与 TTS 两类样本，VoiceStyleControl 的字段可以分成六层：任务标识、文本内容、声音条件、情绪条件、语音监督、基础音频配置。S2S 样本同时包含用户侧和助手侧，因此字段会区分查询侧与回答侧；TTS 样本只生成回答侧语音，因此字段更集中。language 固定语种，sample_rate 固定音频采样配置；这些基础字段是训练加载和评测复现的底层契约，不能只靠路径名或文件夹约定隐式推断。

表42-2汇总了本节的关键对象、工程要点与复核口径。

表 42-2：说话人、情绪与采样标签字段说明。

标签层	字段	取值/例值	分布或工程要求
查询侧说话人	query_gender	female / male，如 female	按 query 侧单独统计。
回答侧声音条件	answer_gender	male / female	训练前应按回答侧 gender、mood 和参考声音条件监控配平，避免输出声音偏置。
查询侧情绪	query_mood	happy、angry、fearful、neutral、sad	S2SEmoControl 五类接近均衡。
回答侧情绪	answer_mood	同上	总量以表42-1为准；TTSSpeakerControl 不显式包含 neutral。
语种与采样	language / sample_rate	zh / 16000	作为加载、重采样和评测复现字段，非路径隐式推断。
参考声音引用	query_id / answer_id	female-neutral-1 等	指向授权参考语音池中的风格实例，不暴露真实身份。

在 VoiceStyleControl 中，emotion 分布只是第一层配平信息。真正进入训练和评测时，样本还会沿着输入侧与输出侧拆开：query_gender × query_mood 描述用户语音的状态分布，answer_gender × answer_mood 描述助手生成语音的目标分布，参考声音 ID 则约束同一种声音条件在不同文本和情绪下的复用方式。语言和采样率看似基础，却决定了加载、重采样和音频指标是否可比。把这些轴放在一起观察，才能判断某类情绪是否只集中在某个声音条件上，某个参考音色是否过度出现在训练集和评测集中，以及模型失败究竟来自语义、声音条件还是情绪控制。

落到数据合成阶段，上述字段差异会体现为两套条件组织方式：S2SEmoControl 需要同时处理 query/answer 两侧的参考语音选择与情绪注入，TTSSpeakerControl 则把风格描述与待朗读内容拆开后再合成回答侧语音。具体合成逻辑见 42.4 第四步与第五步；本节先把字段契约固定下来。

联合 JSON Schema 按任务类型约束必填字段；生产级 manifest 还应增加枚举约束、路径存在性校验、文件哈希、授权 ID、tokenizer 名称、tokenizer 版本和 token 帧率声明。

代码清单42-3给出了JSON Schema 示例。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "VoiceStyleControlRecord",
  "type": "object",
  "required": [
    "source",
    "task",
    "answer",
    "language",
    "sample_rate",
    "answer_audio_path"
  ],
  "oneOf": [
    {
      "title": "S2SEmoControl",
      "required": [
        "query",
        "query_gender",
        "answer_gender",
        "query_mood",
        "answer_mood",
        "query_id",
        "answer_id",
        "query_audio_path",
        "answer_audio_path",
        "query_token_25hz",
        "answer_token_25hz"
      ],
      "properties": {
        "task": {
          "const": "S2S"
        }
      }
    },
    {
      "title": "TTSSpeakerControl",
      "required": [
        "text",
        "answer_gender",
        "answer_mood",
        "answer_id",
        "answer_token_25hz",
        "answer_audio_path"
      ],
      "properties": {
        "task": {
          "const": "TTS"
        }
      }
    }
  ],
  "properties": {
    "source": {
      "type": "string"
    },
    "task": {
      "enum": ["S2S", "TTS"]
    },
    "query": {
      "type": "string",
      "description": "spoken user query 的转写文本，仅 S2S 使用"
    },
    "text": {
      "type": "string",
      "description": "自然语言风格描述，仅 TTS 使用"
    },
    "answer": {
      "type": "string",
      "description": "assistant response 或待合成内容"
    },
    "query_gender": {
      "type": "string"
    },
    "answer_gender": {
      "type": "string"
    },
    "query_mood": {
      "type": "string"
    },
    "answer_mood": {
      "type": "string"
    },
    "language": {
      "type": "string"
    },
    "sample_rate": {
      "type": "integer"
    },
    "query_id": {
      "type": "string"
    },
    "answer_id": {
      "type": "string"
    },
    "query_token_25hz": {
      "type": "string"
    },
    "answer_token_25hz": {
      "type": "string"
    },
    "query_audio_ark": {
      "type": "string"
    },
    "answer_audio_ark": {
      "type": "string"
    },
    "query_audio_path": {
      "type": "string"
    },
    "answer_audio_path": {
      "type": "string"
    }
  }
}

代码清单42-3：JSON Schema 示例。

联合 schema 将训练入口拆成三部分：语义输入是 query、text 或 answer 文本 token，风格输入是 query_gender、answer_gender、query_mood、answer_mood 与参考声音 ID，声学目标是回答侧 speech token 或音频。answer_gender、answer_mood 不能只留在离线 metadata 中，它们必须在 dataloader 中被映射为控制条件或条件文本，否则模型不会真正获得可控生成能力。

训练样本进入 dataloader 后，会从标准 schema 投影成不同任务视图。S2S 视图可以是 query_audio + answer_gender + answer_mood -> answer_token，也可以加入 query 转写作为辅助语义输入；TTS 视图可以是 text + answer + answer_gender + answer_mood -> answer_token。评测视图则反向固定某些字段、改变另一些字段，例如固定 answer 改变 answer_mood，或固定 answer_mood 改变 answer_id。这种“记录契约稳定、训练视图可变”的设计，服务的是可控语音生成实验，而不是额外的身份识别或声纹建模实验。

42.4 构建流水线：从文本对话到可控语音记录

图42-2展示了相应的流程或结构。

图42-2：VoiceStyleControl 数据构建流水线。文本对话或风格内容先被赋予 speaker 与 emotion 条件，再通过授权参考语音池生成或采集音频，最后经过 token 化、质检、配平和封装。

VoiceStyleControl 的构建可以分为七步：文本对话或风格内容生成、风格属性分配、授权参考语音池准备、语音合成或采集、离散语音标记、质检配平、封装发布。相关脚本见 https://github.com/Chanfungjan/VoiceStyleControl。每一步都同时影响语义质量、风格质量和合规风险。

这条流水线不是简单的顺序生产线，而是一组连续的数据门禁。文本内容生成之后，要判断语义是否适合指定情绪；参考语音选择之后，要判断授权是否覆盖当前任务；语音合成之后，要判断音频、文本、声音条件和 emotion 是否同时通过。任何一步发现问题，都不应简单“带病流入下一步”，而要回到对应队列修复。否则，后续评测只能发现模型不稳定，却很难解释不稳定来自哪里。

第一步是生成或收集文本内容。S2SEmoControl 消费经过清洗的对话 JSONL，每条记录包含用户 query 和助手 answer，覆盖日常请求、情绪表达、故事、解释、提醒等场景；answer 保持自然、完整，并保留安全边界。TTSSpeakerControl 则使用 Qwen3-8B 配合情绪特定 prompt 生成 style-content pair，让风格描述与待说内容相互支持。例如 fearful 样本可以更急迫，sad 样本可以更低落，但不能把情绪标签变成危险诱导。

文本内容的验收不只看语法是否通顺，还要看情绪和语义是否相容。fearful 可以对应“你快跑，这里不安全”，但不应对应轻松闲聊中的夸张恐吓；angry 可以用于角色化表达，但不应把辱骂、威胁或歧视性内容当作情绪增强。对话生成阶段如果不设边界，随后的语音合成会把风险文本转化为更有冲击力的声音，风险会被声学表达放大。

第二步是分配风格属性。S2S 需要分别为 query 侧和 answer 侧赋予 gender 与 mood，TTS 则为回答侧赋予 gender 与 mood，并在 text 中写出自然语言风格描述。分配策略要同时考虑均衡和组合覆盖：均衡保证每种 emotion 都有足够样本，组合覆盖则让模型见过不同用户风格到不同助手风格的迁移。如果数据里只有同 gender、同 mood 的组合，模型很容易把输入风格和输出风格绑定在一起，削弱回答侧控制能力。

组合覆盖尤其影响 S2S 子集。用户侧 angry 并不意味着助手侧也要 angry，用户侧 fearful 也不意味着助手侧要同样 fearful。相反，很多真实产品需要助手在用户高压情绪下保持中性、清楚和可执行。数据构建时应保留足够多的跨组合样本，例如 female-angry query 对应 male-neutral answer，或 male-sad query 对应 female-neutral answer。这样模型才能学会把用户状态作为理解信号，而不是直接复制成输出风格。

第三步是准备参考语音池。VoiceStyleControl 使用多说话人、多情绪参考池，并通过 CosyVoice2 以 zero-shot voice cloning 方式合成指定风格语音。工程关键不是“克隆得越像越好”，而是“可授权、可复用、可撤回”。参考音频应记录参考声音 ID、emotion condition、采集时间、用途范围、授权状态和撤回状态；query_id 与 answer_id 只应暴露工程引用，不应包含真实姓名或可反查身份的信息。

第四步是语音合成或采集。S2S 需要分别生成 query speech 和 answer speech，并让两侧音频与文本逐条绑定；TTS 则按 text 和 answer 生成回答侧语音（具体实现见第五步示例）。合成时应固定或显式记录采样率，控制响度、静音、最大时长和文件编码，避免 dataloader 在训练时因为音频长度或格式异常而不稳定。若采用真实采集，还要额外处理环境噪声、麦克风差异、说话人疲劳和第三方背景声。

以下以 S2SEmoControl 为例，展示 schema 字段如何进入合成过程：query_id 与 answer_id 选择两侧参考语音；当 answer_mood 不是 neutral 时，情绪指令会拼入 query 侧合成文本，使输入语音携带输出风格控制意图。

代码清单42-4给出了Python 实现片段。

def build_synthesis_inputs(record):
    language = record["language"]
    query_content = record["query"]
    answer_content = record["answer"]
    answer_mood = record["answer_mood"]
    query_prompt_id, answer_prompt_id, record = select_prompt_speech(record)

    if answer_mood != "neutral":
        prompt = random.choice(INSTRUCT[language]).format(mood=answer_mood)
        record["prompt"] = prompt
        if random.random() < 0.5:
            query_content = prompt + query_content
        else:
            query_content = query_content + prompt

    return (
        record,
        PROMPT_TEXT[language][query_prompt_id],
        query_content,
        PROMPT_TEXT[language][answer_prompt_id],
        answer_content,
    )

record, q_instruct, q_content, a_instruct, a_content = build_synthesis_inputs(record)
language = record["language"]
q_tokens, q_speech = backend.compute_zeroshot_speech_token(
    q_instruct, audio_dict[language][record["query_id"]], q_content
)
a_tokens, a_speech = backend.compute_zeroshot_speech_token(
    a_instruct, audio_dict[language][record["answer_id"]], a_content
)

代码清单42-4：Python 实现片段。

这个示例体现了 S2S 侧的关键分支：answer_mood 决定是否注入情绪指令，q_tokens、a_tokens 与对应波形则与 manifest 中的 query_token_25hz、answer_token_25hz 字段对接。

第五步是离散语音标记。语音生成训练需要把声学目标整理为离散 speech token，使生成任务可以被组织为序列建模问题。通用做法是对已有波形用 S3Tokenizer 等 tokenizer 编码；VoiceStyleControl 则走 CosyVoice 生成式路径——合成时同步产出 speech token 并解码为可播放音频，因此本仓库并不存在单独的「先合成、再标记」后处理步骤。S2S 记录写入 query_token_25hz 和 answer_token_25hz，TTS 记录写入回答侧 answer_token_25hz；帧率为 25Hz（CosyVoice2 的 token_frame_rate），manifest 字段名与之对应。数据发布时仍应绑定 tokenizer 名称、版本、帧率、码本配置和重建方式。训练集最怕“同名字段不同含义”：如果同一字段在不同批次中被不同帧率或不同 tokenizer 版本生成，模型会在时序长度和声学粒度上接收到混乱监督。

TTSSpeakerControl 采用另一条合成路径：answer 是要说出的内容，text 或 prompt 是风格描述。从数据工程角度看，关键不是展开 CosyVoice 内部 flow 与 vocoder 的全部参数，而是把一条稳定的数据流固定下来：先从记录中抽取内容和风格指令，再调用合成函数得到回答侧 token 与音频，最后把监督地址写回同一条 manifest 记录。

代码清单42-5给出了Python 实现片段。

for sample_idx, record in id2meta:
    text_content, instruction_text = extract_tts_fields(record)
    if len(text_content) > 512:
        continue

    sample_key = str(record.get("uuid") or record.get("id") or sample_idx)
    speech_token, speech_audio = compute_tts_speech_token(
        text_content, instruction_text, SPK_ID
    )
    token_offset = answer_token_writer.write(sample_idx, speech_token.tobytes())
    audio_offset = answer_audio_writer.write(sample_idx, speech_audio.tobytes())

    record["answer_token_25hz"] = f"{paths.answer_token_ark}:{token_offset}"
    record["answer_audio_ark"] = f"{paths.answer_audio_ark}:{audio_offset}"
    record["answer_audio_path"] = str(
        paths.answer_wav_dir / f"{sample_key}-answer.wav"
    )
    wavfile.write(record["answer_audio_path"], ARK_SAMPLE_RATE, speech_audio)
    write_jsonl_record(jsonlf, record)

代码清单42-5：Python 实现片段。

这个示例对应的是“自然语言风格描述如何变成可训练语音监督”的核心链路：instruction_text 进入合成函数，speech_token 成为后续训练可以直接建模的离散目标，speech_audio 用于听感质检、反向 ASR 和人工抽检。token offset、audio offset 和 wav 路径被写回同一条记录后，样本才真正具备可追溯性。

第六步是质检、配平和切分。质检不应只看音频能否播放，还要检查文本与音频是否一致、目标声音条件是否匹配、emotion 是否可感知、音质是否稳定、路径是否存在、token 是否能读取。配平也不只按 emotion 总量做，还要按 task、language、sample_rate、参考声音 ID、文本长度和音频时长监控。切分时应按参考声音 ID 做隔离，避免同一参考音色同时出现在训练集和测试集，造成声音条件评测虚高。

第七步是封装。最终样本可以存为 JSONL、Parquet 或 Hugging Face Dataset 格式，但训练清单要保留音频路径、token 路径、哈希、授权状态和数据版本。音频文件、token ark 文件和 metadata 不应由人工命名约定松散关联，而应由 manifest 严格绑定。只有这样，样本被重合成、重标注或下架时，团队才能定位受影响的训练版本。

封装产物不只是 JSONL、Parquet 或 Hugging Face Dataset，还包括描述数据边界的数据卡。数据卡记录样本总量、子集构成、emotion 分布、gender 字段分布、参考声音 ID、语言、采样率、tokenizer 版本、授权范围和切分策略，并区分训练条件、审计元数据与公开版本中的匿名化字段。这个边界说明可以防止 answer_id 被误用为真实身份标签，也可以防止 mood 被当成无需验证的可靠事实。

42.5 质量评估与闭环修复

图42-3展示了相应的流程或结构。

图42-3：质量评估与数据飞轮闭环。自动校验、反向 ASR、风格评估和人工抽检共同形成问题样本队列，再回流到重合成、重标注、降权或剔除。

可控语音交互数据的质量评估需要同时覆盖语义、声音、情绪、音频和安全。单独听起来“像人声”的样本并不一定合格：它可能读错文字，可能声音身份不匹配，可能情绪过强，也可能在危险场景中使用了不恰当的恐惧语气。质量系统应把自动指标与人工复核组合成闭环，问题样本进入重合成、重标注、降权或剔除队列。

质量门禁应分成“硬失败”和“软风险”。路径不存在、采样率错误、音频损坏、token 不可读、ASR 反查严重不一致，通常属于硬失败，应直接拦截。情绪强度略弱、自然度一般、声音条件听感处于边界，则可以进入软风险队列，根据任务重要性选择重合成、降权或人工复核。把所有问题都当成一票否决，会浪费可修复样本；把所有问题都放行，又会让控制信号被噪声稀释。

表42-3汇总了本节的关键对象、工程要点与复核口径。

表 42-3：质量评估指标表。

评估层面	核心问题	自动指标	人工复核要点	不合格处理
语义一致性	回答是否回应用户意图，TTS 内容是否被正确读出	ASR 反转写 CER/WER、语义相似度、意图命中率	是否答非所问、遗漏关键信息、产生危险建议	重写文本、重合成、剔除
声音条件一致性	输出是否匹配目标 answer_gender、answer_mood 和参考声音条件	字段一致性校验、自动/人工性别核验、参考音色听感抽检	是否出现目标条件错误、跨样本串音、音色过像未授权真人	重选参考音频、重合成、降权或隔离
情绪控制	目标 mood 是否被稳定表达	情绪分类准确率、混淆矩阵、F0/能量/语速统计	情绪是否过强、与语义冲突或诱导操控	重标注、调低强度、剔除
音频质量	音频能否作为生成监督	SNR、响度、静音比例、裁剪率、MOS/NISQA	爆音、断句、机械音、背景噪声	降噪、重采样、重合成
对话自然度	S2S 回答是否自然，角色是否稳定	多轮连贯性评分、延迟与时长分布	语气是否突兀、角色不一致、风格反复跳变	重排、补充上下文、人工审核
安全合规	样本是否可授权、可追溯、可撤回	授权记录完整率、水印命中率、审计日志覆盖率	是否存在冒充、诱导、敏感身份复刻风险	封禁、脱敏、下架和审计

语义一致性可以通过反向 ASR 建立第一层自动检查。将合成音频转写回文本，计算 CER/WER，并与 answer 比较；对于 S2S，还要检查 answer 是否回应 query。若“你快跑，这里不安全”被合成为“你快跑，这里很安全”，音频质量再高也必须剔除。语义相似度和 LLM-as-judge 可以辅助定位问题，但在安全敏感或情绪强烈样本中仍要保留人工抽检。

声音条件一致性关注的是生成结果是否符合样本中的 answer_gender、answer_mood 和参考声音条件，而不是训练或评测一个独立的身份识别模型。对于回答侧，answer_id 应与 answer_gender、answer_mood 一致；对于 query 侧，query_id 应与用户侧标签一致。如果同一个 answer_id 在不同样本中表现出明显不同音色，需要回查参考池、合成参数和 token 化流程。人工听辨和自动核验只是质检手段，不改变数据集的训练目标。

情绪控制评测不能只看分类器置信度。happy 往往表现为更高能量和更快节奏，sad 可能表现为更慢语速和更低能量，fearful 可能伴随颤抖、急促或不稳定停顿，angry 可能表现为更强能量和更硬语气。但中文表达、说话人差异和内容语义都会改变声学表现，因此评测目标应是“可感知且与文本相容”，而不是把每一种情绪写成固定声学模板。

闭环修复要保留问题类型。语义错误通常回到文本生成或 ASR 反查；声音条件错误回到参考语音选择或合成参数；emotion 错误回到风格描述、情绪标签或合成模型；音质错误回到波形处理；合规错误进入隔离、下架和审计流程。每次修复都应生成新版本，而不是覆盖源文件。这样，后续模型效果变化才能追溯到数据变更，而不是变成不可解释的训练波动。

42.6 评测协议：让控制能力可比较

评测集应从训练集构造逻辑中独立出来，尤其要避免同一参考声音 ID 同时出现在训练和测试中。对于 S2SEmoControl，评测样本需要覆盖不同 query 情绪到不同 answer 情绪的组合；对于 TTSSpeakerControl，评测样本需要覆盖同一 answer 在不同 text、answer_gender、answer_mood 条件下的对比。一个有效评测协议不只问“生成声音好不好听”，还要问“同一句话在不同控制条件下是否真的不同，且不同得合理”。

评测集可以拆成三类切片。第一类是常规切片，覆盖训练集中主要任务分布，用来观察整体可用性。第二类是反事实切片，固定文本或参考声音 ID，只改变 answer_mood 或 answer_gender 条件，用来检查控制字段是否生效。第三类是安全切片，包含身份冒充、高压情绪、敏感职业、金融验证码、医疗建议等场景，用来检查模型是否会把“可控生成”误用为“可控操控”。这三类切片的结论不能混成一个总分，否则高音质样本可能掩盖高风险行为。

语义评测分为内容保真和对话相关性两层。内容保真检查 TTS 输出是否准确读出 answer，S2S 输出是否可被转写为与目标 answer 语义一致的文本。对话相关性检查 S2S 的 answer 是否回应 query，而不是只生成流畅但无关的句子。评测中可以组合 ASR 反转写、语义相似度、LLM-as-judge 和人工审核，但要保存判分 prompt、模型版本和人工指南，避免评测随时间漂移。

声音条件评测也要分层。结构标签层检查 answer_gender、answer_mood 与样本目标是否一致；听感层检查生成音频是否符合对应参考声音条件和情绪表达；隔离层检查模型是否过度接近未授权个体或泄露训练集中某个真实声纹。评测目标不是构造声纹相似度排名，也不是把“越像某个真实人”当成唯一优化方向，而是确认模型能否在样本条件下生成合理、合规的带情绪语音。

情绪评测需要构造反事实集合。例如固定一句中性内容，分别请求 happy、angry、fearful、sad；或固定 answer_gender，改变 answer_mood；也可以固定 answer_mood，改变 answer_gender。这种 paired evaluation 能暴露模型是否真的使用控制字段。如果所有输出只在音量上变化，而语速、停顿和韵律没有随 answer_mood 改变，说明模型可能只学到了浅层强度调节。

音频质量评测包含客观指标与主观评分。客观指标覆盖时长分布和自动 MOS 等；主观评分关注自然度、可懂度、情绪可信度和对话舒适度等。安全性评测则应成为发布门禁的一部分：身份冒充、敏感职业、金融验证码、医疗建议、未成年人和高压情绪诱导等场景，都要检查系统是否会在不该使用强情绪或特定音色时仍然生成输出。

评测结果还应回写到数据版本，而不是只保存在模型报告里。若某一版模型在 fearful 上情绪分类准确率高但人工舒适度低，说明数据可能把 fearful 构造成过强、过戏剧化的表达；若参考声音条件越做越像某个可识别真人而合规风险上升，说明参考语音或评测目标可能过度追求身份复刻。只有把这些结论回流到样本筛选、配比和合成策略，评测才会真正改变下一版数据。

42.7 隐私、授权与滥用风险治理

声音身份属于高度敏感的数据资产。一个人的声音包含年龄、性别、地域、情绪、健康状态和身份识别线索；在声纹识别系统中，声音甚至可以成为认证凭据。可控语音数据一旦引入 voice cloning，就必须把授权、撤回、用途限制和审计写入数据生命周期，而不是只在模型发布时补充免责声明。

表 42-4：隐私与滥用风险控制清单。

风险类型	触发场景	控制措施	审计证据
声音身份授权	参考语音来自真实说话人或可识别声音	采集前同意、用途限定、可撤回、授权版本号	授权时间、撤回记录
声音克隆防滥用	合成音频被用于冒充、诈骗或绕过平台检测	音频数字水印、声学指纹、生成来源签名、公开样例防伪标记	水印检测日志、指纹库版本、溯源校验记录
情绪操控	用恐惧、愤怒或亲密语气影响用户判断	高风险场景禁用强情绪、提示语审查、未成年人保护	人工复核单
隐私泄漏	音频中含姓名、电话、地址或背景说话人	ASR 脱敏、背景声过滤、数据最小化、保留期限	脱敏报告、删除请求处理记录
偏见与刻板印象	gender 与 mood 或内容长期绑定	分布监控、反事实样本、禁止性别刻板模板	分布报表、偏见评测结果
版本失控	样本被重合成或重标注后无法追溯	数据版本管理、哈希、训练集冻结	实验追踪编号

表42-4将风险治理落实为数据门禁。授权缺失的 reference 不能进入合成队列；撤回授权的 reference 必须能追溯到所有派生音频和 token；高风险情绪操控样本不能只靠训练后安全策略兜底，而要在数据构建阶段就被拦截或降权。对语音生成来说，合规不是上线前最后一层过滤，而是样本生命周期的一部分。

参考语音池是治理重点。每个 reference 都应有 consent_id、授权范围、采集方式、允许任务、过期时间和撤回状态。若授权只允许研究用途，样本不能进入商业模型训练；若说话人撤回授权，manifest 应能定位所有受影响的 query_id/answer_id、音频文件、token 文件和训练版本。对外发布时，应尽量使用不可反查真实身份的 reference ID，避免将声音 ID、文件名或路径设计成真实姓名。

声音克隆产物还应具备可验证的防伪机制。进入训练集、评测集或公开样例的合成音频，宜写入不影响听感的数字水印，或至少生成可检索的声学指纹；manifest 中同步记录生成模型、模型版本、watermark key id、consent_id、样本哈希和数据版本。发布前要运行水印/指纹检测，确认音频仍可溯源；经过转码、裁剪或压缩后检测失败的高风险样本，应降级为内部样本、重新合成或直接下架。这样，声音克隆不只是“有授权即可使用”，还具备事后识别、平台协查和撤回处置的证据链。

情绪控制也有滥用边界。fearful、angry 等强情绪可以提升表达力，也可能用于操控用户。客服、教育、医疗、金融等场景应限制高压情绪输出，尤其不能用恐惧语气诱导用户转账、购买、泄露验证码或作出健康决策。对于未成年人和心理脆弱人群，系统应优先使用 neutral 或温和支持性风格，并保留策略触发日志。

隐私保护还包括内容脱敏。语音样本可能含有姓名、地址、电话、账户、地理位置或背景中的第三方说话声。即使 VoiceStyleControl 主要由合成文本生成，工程流程仍应保留 ASR 脱敏、敏感词扫描、背景声检测和人工抽检。若后续引入真实用户语音反馈，用户同意、数据最小化、保留期限、删除请求和用途变更通知都必须进入平台流程。

偏见治理同样重要。若训练集中女性声音更多被绑定到 fearful 或 sad，男性声音更多被绑定到 angry，模型会学习并放大刻板印象。因此，gender 统计不能只停留在边际占比，必须进入 query_gender、answer_gender 与 query_mood、answer_mood 的交叉视图；评测集也要构造反事实样本，检查同一内容在不同 gender 下的情绪表达是否公平。

42.8 与前后章节的数据工程连接

VoiceStyleControl 继承了音视频数据工程的底层能力。第10章讨论的音频切片、ASR、降噪、说话人分离和时间对齐，进一步转化为更细的样本契约：不仅要知道一段音频对应哪段文字，还要知道它由哪个参考声音 ID、以何种 mood、在什么采样率和 token 频率下生成。普通音频管线解决“能不能对齐”，可控语音交互进一步解决“对齐后的声音能否按条件生成”。

它也连接多轮交互数据。第20章关注 Agent 记忆和多轮上下文时，角色、意图和历史状态是主要变量；当交互进入语音形态，助手人格还体现在音色与情绪稳定性上。一个多轮语音助手不能第一轮是 neutral 男声，第二轮无缘由变成 fearful 女声，第三轮又变成 angry 男声。因而 answer_gender、answer_mood 和 answer_id 可以成为语音 Agent 记忆的一部分，用于维持连续会话中的声音身份。

在线反馈闭环会让语音风格从离线标签走向用户体验。第23章中的点击、满意度、纠错和投诉，在语音产品里会表现为“听不清”“太急”“太凶”“不像之前的声音”“情绪不合适”等反馈。这些反馈不能直接变成训练样本，而应先进入评测队列：判断是语义错误、音质错误、风格错误还是安全策略错误，再决定重合成、重标注、调整配比或修改拒绝规则。

隐私合规章节为 VoiceStyleControl 提供边界。第36章的数据合规框架要求把授权、用途、留存和审计前置到数据生命周期；第37章的隐私保护技术则提醒我们，声音身份可以通过访问控制、联邦训练、加密存储和最小化采集降低风险。可控语音数据越强调声音条件和参考音色，越不能把合规视为附录。

在多模态生成数据工程中，VoiceStyleControl 与第48章共享同一个核心模式：把生成目标拆为内容条件与风格条件，再用结构化 schema 绑定训练监督。T2I/T2V 中的 prompt、style、motion、camera、safety tag，在语音中对应 answer、answer_gender、answer_mood、参考声音 ID、sample_rate 和 audio token。第十四篇项目十“端到端 LLM 数据飞轮”也可以吸收这套设计：离线构建初版语音数据，训练可控生成模型，在线收集体验反馈，回流到质检和配平，再发布下一版数据与模型。

42.9 小结

VoiceStyleControl 的价值不在于把语音样本简单堆到更大规模，而在于把语义响应、声音条件、情绪控制和语音生成监督放进同一条可审计记录。S2SEmoControl 提供 spoken query 到 spoken answer 的交互监督，TTSSpeakerControl 提供自然语言风格描述到目标语音的直接监督。二者合在一起，使模型既能理解用户语音，又能依据指定声音条件和情绪生成回答。

数据工程的关键工作包括：显式区分语义通道与风格通道，保留 query_gender、answer_gender、query_mood、answer_mood 等控制字段；将 sample_rate、音频路径、speech token 路径和 tokenizer 版本写入数据契约；用 ASR 反查、声音条件核验、情绪识别、音频质量指标和人工评审共同构建评测协议；在参考语音池和声音克隆流程中落实授权、撤回、水印和审计。

当语音交互从“能说话”走向“以可控方式说话”，数据集的边界也随之变化。每条样本都要回答四个问题：内容是否正确，声音条件是否符合目标设定，情绪是否符合控制条件，生成过程是否合规可追溯。只有这四个问题同时成立，可控语音交互数据才能成为可靠的训练资产。

本章小结

VoiceStyleControl 说明，语音与音频数据工程不能只关注语音合成质量，还必须同时组织语义、风格、控制标签、授权与风险治理。只有把这些信号写入样本 schema、构建流水线和评测协议，语音交互系统才具备可复查、可迭代和可合规迁移的工程基础。

参考文献

An K, Chen Q, Deng C, Du Z, Gao C, Gao Z, Gu Y, He T, Hu H, Hu K, others (2024) FunAudioLLM: Voice Understanding and Generation Foundation Models for Natural Interaction Between Humans and LLMs. arXiv preprint arXiv:2407.04051.

Chanfungjan (2026) VoiceStyleControl. GitHub repository. https://github.com/Chanfungjan/VoiceStyleControl.

Du Z, Chen Q, Zhang S, Hu K, Lu H, Yang Y, Hu H, Zheng S, Gu Y, Ma Z, Gao Z, Yan Z (2024) CosyVoice: A Scalable Multilingual Zero-shot Text-to-speech Synthesizer based on Supervised Semantic Tokens. arXiv preprint arXiv:2407.05407.

Du Z, Wang Y, Chen Q, Shi X, Lv X, Zhao T, Gao Z, Yang Y, Gao C, Wang H, others (2024) CosyVoice 2: Scalable Streaming Speech Synthesis with Large Language Models. arXiv preprint arXiv:2412.10117.

Mittag G, Naderi B, Chehadi A, Möller S (2021) NISQA: A Deep CNN-Self-Attention Model for Multidimensional Speech Quality Prediction with Crowdsourced Datasets. In: Interspeech 2021, pp 2127-2131. https://doi.org/10.21437/interspeech.2021-299.

Song X (2026) S3Tokenizer: Reverse Engineering of Supervised Semantic Speech Tokenizer proposed in CosyVoice. GitHub repository. https://github.com/xingchensong/S3Tokenizer.

Yang A, Li A, Yang B, Zhang B, Hui B, Zheng B, Yu B, Gao C, Huang C, Lv C, others (2025) Qwen3 Technical Report. arXiv preprint arXiv:2505.09388.