从随机攒句子到覆盖全部音素：corpusgen 如何把语料设计变成可计算的选择题

英文题目：corpusgen: An Open-Source Toolkit for Phoneme-Coverage-Optimized Speech Corpus Design Across Languages

会议身份：conference:interspeech:2026:conference-paper-id:syed26_interspeech

来源为官方会议 PDF；图片依据原页像素，表格数字依据原文引用。PDF 文字层不视为原始 TeX，未可靠恢复的结构不作推断。

会议来源：官方记录 · 官方 PDF

标签：#开源工具 #数据集构建 #语音学与音系 #多语言 #文本到语音

评分：7.1/10 | 创新 1.2/2 | 技术严谨 1.0/1.5 | 实验充分 0.6/1.5 | 清晰度 0.7/1 | 影响力 1.0/1.5 | 开源 1.5/1.5 | 可复现 0.1/0.5 | 工程/实践 1.0/1.5

排名：前50% | 文档类型：系统技术报告

👥 作者与机构

• Muntaser Syed：机构信息未能从会议 PDF 纯文本可靠映射
• Marius Silaghi：机构信息未能从会议 PDF 纯文本可靠映射
• Sharun Akter Khushbu：机构信息未能从会议 PDF 纯文本可靠映射
• Fariha Jaigirdar：机构信息未能从会议 PDF 纯文本可靠映射

📌 核心摘要

该文面向低资源语言语音语料设计的输入输出难题，输入为任意文本池与目标语言码，输出为音素覆盖率最大且句数最少的待录制子集，难点在于跨语言字音转换不一致与集合覆盖的NP难优化。方法链分三步衔接：基础设施层先用espeak-ng经Phonemizer转写为国际音标，再经映射桥对齐至PHOIBLE典型音库，由覆盖追踪器维护计数并为后续模块提供统一符号输入。评估模块基于该计数输出音素、二音素、三音素覆盖率及分布指标，选择模块在同一计数上运行贪心与精确算法得到候选子集，生成模块再针对剩余缺口定向造句回填。与FestVox等单语贪心管线相比，差异在于语言无关架构加多目标与分布感知优化加可插拔生成后端，意义是降低新语言建库门槛。原文未提供可核对的关键定量结果。结论仅适用于有espeak-ng与PHOIBLE支撑的语言，转写错误大或无文本池时的外推尚未验证。原文未披露训练、推理或部署成本。

🔗 开源与复现资源

• 代码相关资源：https://github.com/jemsbhai/corpusgen — 链接可访问（HTTP 200） 可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

输入是什么，输出是什么：先把语料设计说成一句话任务

这篇解读的输入是论文正文与一张架构图，目标是让刚进入语音领域的研究生能复述 corpusgen 做了什么、在什么条件下成立、复现时先敲什么命令。必须保留的信息包括工具的 3 个用户命令、底层发音转换与清单来源、6 种选择算法的名字与分工、生成模块的 3 种后端，以及开源状态与验证规模。最终输出是一套按学习依赖展开的方法与实验说明，不做超出原文的效果承诺。

语音语料设计要解决的问题很具体：为文本转语音或语音识别准备录制文本时，希望用尽量少的句子覆盖一门语言的全部发音单元。如果句子是随机从网上抓的，常见音会反复出现，稀有音可能始终缺席，录完才发现某些音没有样本，补录成本很高。对于资源丰富的语言，以往有 FestVox 这类针对特定语言和文字的贪心选择流水线，但换一门语言往往要重写。对于低资源语言，实践者常常从零搭流程，容易留下覆盖缺口。

corpusgen 把这件事收敛为一个跨语言工具包。用户给的是文本语料加语言代码，工具先把文本转成国际音标，再对照该语言应有的音素清单算覆盖率，然后做三件事中的一件：评估现有语料有多全，从大池子里挑一个小的子集，或者针对缺失的音定向造新句子。最后输出的是优化后的语料加一份报告。论文报告该框架在 40 种语言 12 个语系上得到验证，代码当前可用，支持用包管理器安装并提供编程接口与命令行两种用法。

已有路线走到哪里：为什么还缺一个统一工具？

理解 corpusgen 的位置，需要区分 3 条已有路线。第一条是面向特定语言的录音脚本构造，例如 FestVox 提供的贪心选择流水线，它能工作，但通常与特定语言和文字绑定，换语言时复用困难。第二条是集合覆盖的算法理论，把选最少句子覆盖全部语音单元对应到集合覆盖问题，该问题是 NP 难问题，贪心算法具有对数级近似保证，子模性带来的惰性求值可以加速，多目标情形可以用遗传算法处理覆盖、自然度与录制成本的权衡。第 3 条是发音资源本身，包括发音合成器、音素数据库与发音特征库，它们各自解决转写、目标清单与音距离计算，但没有把评估、选择与生成串起来。

论文的判断是算法景观已经成熟，但缺少语言无关的统一框架。也就是说，缺的不是某一个更强的选择公式，而是把发音转换、清单管理、覆盖追踪、多种选择器和缺口生成放在同一个可安装包里，并对 100 多种语言开箱可用。corpusgen 的定位正是补这个缺口，它不提出新的语音学理论，而是做工程集成与跨语言适配。对于初学者，关键是不要把该工具理解成新的声学模型，它不训练声学参数，也不直接提升合成音质，它改善的是进入模型之前的文本选择环节。

同输入同目标的对照应该是同样输入文本池与语言代码、同样输出固定规模子集、在同样覆盖定义下比较所需句子数或覆盖率。论文把贪心作为标准基线，把精确整数规划作为小规模实例的真值对照，把随机基线作为下限参照，这种安排符合集合覆盖文献的惯例。需要提醒的是，原文没有给出跨语言的完整数字表，因此不能把某一语言上的趋势直接推广为所有语言都成立。

问题如何形式化：最小句子集合与覆盖率怎么算？

把任务形式化后更容易复述。设候选池中有若干句子，每个句子经过发音转换后对应一个音素集合，全语言的目标是 PHOIBLE 给出的规范音素全集。选择问题的目标是用最少句子使得并集等于或尽量接近全集，这正是最小集合覆盖。评估时分子是语料中实际出现的不同音素数，分母是清单中的音素总数，由此得到音素覆盖百分比。论文还把同一思想扩展到双音素与三音素，即相邻两个或 3 个音素组成的序列的覆盖率，以及覆盖随语料规模增长的饱和曲线。

举一个教学例子帮助理解，但例子中的数字是示意而非论文报告。假设某语言清单有 40 个音素，随机挑 100 句可能只覆盖 35 个，因为稀有音始终没被抽到，而优化选择可能用 30 句就覆盖全部 40 个，因为它每一步都优先挑带来新音最多的句子。这个例子只说明边际增益的思想，不代表任何真实语言的结果。真实的难点在于符号不一致：发音工具输出的符号与数据库的规范符号可能写法不同，还有宏语言代码需要解析，例如某种马来语代码要对应到标准马来语。

因此问题包含两个子任务。第一是表示对齐，即把可计算的转写结果映射到可比较的规范清单，否则覆盖率无从算起。第二是组合选择，即在池子很大时快速找到接近最优的子集。论文用映射桥与系统性符号归一化处理前者，用贪心及其加速变体与精确求解处理后者。初学者应先记住覆盖率的分母来自外部清单，而不是从语料中统计出来的最大值，否则会把有缺口的语料误判为已覆盖完全。

方法全景：三条命令如何共享同一套底层？

corpusgen 在概念上只有 3 条用户命令：评估、选择与生成。评估回答现在有多全，选择回答从大池子里留哪些，生成回答池子里没有时如何补。它们共享同一层基础设施，包括发音转换、音素清单管理与覆盖追踪。这样的安排理由是三者都需要同一套符号与计数，否则各自算出的覆盖口径会不一致。

从数据流看，输入的文本与语言先同时进入发音转换与清单查询，转换结果与目标清单都进入覆盖追踪器，追踪器维护音素、双音素与三音素的出现计数，并支持常数时间的边际增益查询。然后流程分叉到评估、选择或生成，最终都产出优化语料加报告。生成到追踪器之间还有一条虚线，表示用新生成的句子更新覆盖状态后再做下一轮缺口判断。

下图是理解该分工的最直接依据，建议先看主路径再看反馈回路。图中左侧输入经过中间转换与追踪后分为 3 路，右侧汇聚为同一类输出，虚线是唯一的回路。

看图路径： 1. 从左侧文本加语言输入出发，沿实线箭头数出经过转换与追踪再分叉的三条路径；2. 确认绿色评估、橙色选择、红色生成三个方框内的英文关键词与正文命令是否对应；3. 找到从生成框回到覆盖追踪器的唯一虚线箭头，理解它表示覆盖反馈回路；4. 观察三条路径最终是否都汇入右侧优化语料加报告框

论文图 1。原论文 Figure 1：“Architecture of corpusgen. Solid arrows show data flow; the dashed arrow indicates coverage feedback from gen- eration.”。

该架构图显示左侧文本语料加语言框分出两条实线，分别进入发音转换与清单框，两者再汇入覆盖追踪器。追踪器向右分出 3 条实线，分别指向评估框、选择框与生成框，每个框内标注了各自包含的方法关键词。三框再向右汇入优化语料加报告框。图中还有一条从生成框底部返回覆盖追踪器的虚线，图注明确说明虚线表示来自生成的覆盖反馈。颜色上评估、选择、生成用不同底色区分，但汇聚目标相同，说明三者是同一覆盖口径下的不同操作。

初学者复述时可以沿一个句子走完全程：句子先被转写为音标序列，再被映射到规范符号，然后更新计数器，最后被评估、选中或成为生成时的参照。

底层如何算覆盖：转写、清单与计数器各自做什么？

基础设施层解决表示与计数问题。发音转换流水线通过发音工具包实现，论文报告支持 100 多种语言的国际音标转写。清单管理提供特定语言的音素集合，来源数据库覆盖 2186 种语言。两者之间有一个映射桥，处理宏语言解析与符号归一化，并展示未映射符号，让用户在构造语料前先看清目标是否可计算。发音特征库提供音素的发音特征向量，用于计算音素间距离。覆盖追踪器维护运行中的音素、双音素与三音素计数，使选择算法在每一步能快速查到某候选句能带来多少新单元。

字形到音素转换 × 音素清单： 字形到音素转换负责把某语言的文本变成国际音标序列，回答语料里实际出现了什么音；音素清单负责给出该语言理论上应该出现什么音，以 PHOIBLE 的规范清单为目标。两者搭配的理由是只有把实际输出映射到同一套规范符号，才能计算覆盖率，组合后新增的作用是让覆盖追踪器可以逐句统计已覆盖、缺失和边缘符号。

这一层的关键动作是先检查清单与映射。如果某语言的清单显示有目标音，但发音工具从未输出对应符号，覆盖率就永远无法达到 100%，此时问题不在选择算法，而在转写或映射。论文演示的第一步正是先查询清单，例如查看孟加拉语的音素集、映射关系与未映射符号，再开始构造语料。这个顺序值得模仿：先确认分母与符号对齐，再谈优化。原文未报告每个语言的具体映射成功率，这是一个缺项，复现时需要自己记录未映射符号表。

计数器的设计直接影响选择速度。如果每次评估候选句都要重新扫描已选集合，开销会随规模快速增长。论文称追踪器支持常数时间的边际增益查询，含义是已选集合的统计量被增量维护，新候选只需查它相对当前状态的新增部分。这种设计是贪心加速的前提，但原文没有给出该数据结构的具体内存占用与更新伪代码，复现时只能按增量计数的常规做法实现并测量。

选择器全家桶：六种算法何时用哪一个？

选择模块实现 6 种算法，初学者可以按精度与规模记住它们。贪心集合覆盖是标准基线，每一步选新增覆盖最多的句子，具有对数级近似保证。CELF 利用子模性做惰性评估，达到与贪心等价的覆盖但更快，论文称可带来最多两个数量级的加速。随机贪心通过采样候选子集实现线性时间扩展，用于大池子。整数线性规划用优化建模库做精确集合覆盖，用于小实例的真值对照。

分布感知选择在覆盖目标上加入散度项，使选中语料的音素分布接近目标分布。NSGA-II 给出覆盖、规模与自然度等冲突目标下的帕累托解集。

集合覆盖 × 贪心算法： 集合覆盖负责把语料设计形式化为用最少句子覆盖全部音素单元的组合问题，贪心算法负责每一步选当前边际增益最大的句子。搭配理由是该问题是 NP 难问题，难以精确求解大规模实例，而贪心在该目标上有多项式时间的近似保证，组合意义是得到可直接运行的基线选择器。

CELF 加速 × 子模性： 子模性负责刻画音素覆盖的边际收益递减性质，即越到后期新句子带来的新音素越少；CELF 加速负责利用该性质做惰性求值，跳过本轮不可能反超的候选。搭配理由是不改变贪心选择结果而减少重复计算，组合后新增的作用是在保持等价覆盖的前提下显著降低选择过程的计算量。

下表把 6 种算法放在同一比较框架下，比较问题是给定同一文本池与同一覆盖定义，哪种策略更适合哪种规模与目标。公平条件要求候选池、语言、转写与清单完全相同，指标方向是覆盖率越高越好、达到目标覆盖所需句子数越少越好、墙钟时间越短越好。表中信息来自正文对每种算法的定性描述，未补充原文没有的速度数字。

该表的主要收益是把可部署策略与参照策略分开。贪心、CELF、随机贪心与分布感知是实际可运行的选择器，整数线性规划是小规模真值参照，NSGA-II 是多目标参照。代价是不同算法优化的目标并不完全相同，直接比较覆盖率可能不公平，例如分布感知可能用稍多的句子换取更自然的分布。未胜出项方面，精确求解在大池子上不可扩展，随机贪心在大池上快但不保证等价于贪心，论文未报告它们在统一大池上的完整胜负，这是使用时需要自己补测的边界。

没有神经网络训练时，真正的计算发生在哪里？

这是 1 篇工具论文，没有训练新的声学模型或语言模型，因此不存在梯度更新、参数冻结或训练轮次。本节的任务是讲清实际发生的 3 类计算。第一类是检索与计数，包括发音转换、符号映射与覆盖统计，这是评估与选择的基础。第二类是组合搜索，包括贪心迭代、惰性求值、采样与精确求解，这是选择模块的优化过程。第 3 类是受控生成与打分，包括按缺失音素检索现成句子、用云端大模型按语音约束提示生成、用本地量化变换器模型做推理时引导，以及用语音打分器与 n 元音位模型验收候选。

分布感知选择 × NSGA-II 多目标优化： 分布感知选择负责在覆盖目标之外加入分布匹配项，让选中语料的音素分布接近目标分布；NSGA-II 多目标优化负责同时处理覆盖率、语料规模、自然度等互相冲突的目标并给出帕累托前沿。搭配原因是只追求覆盖最小集合可能得到生硬或偏斜的语料，组合意义是把录制成本与可用性一起纳入可比较的权衡框架。

音位可控文本生成 × 覆盖反馈： 音位可控文本生成负责在没有合适文本池时针对缺失音素造新句子，覆盖反馈负责把生成模块的缺口信息送回覆盖追踪器做下一轮评估。搭配理由是选择只能从已有池子里挑，无法补全池子本身没有的音，组合后新增的作用是形成评估缺口、定向生成、再评估的闭环。

生成模块的工作方式值得展开。生成循环遍历缺失的语音目标，把请求分发到 3 种可插拔后端。仓库后端在现有数据集仓库中搜索包含目标音素的句子，大模型接口后端通过轻量路由库向云端模型发送带语音约束的提示，本地后端运行量化变换器模型并做推理时引导。生成的候选在接受前要经过语音打分器与 n 元音位模型两道评分，分别看语音内容是否补上缺口、音位序列是否合乎该语言的拼合习惯。原文未报告提示模板、采样温度、打分阈值与接受率等超参数，这是复现生成环节时最需要补记的缺项。

需要纠正一个常见误解：无训练不等于确定性求解。贪心与随机贪心中有采样与平局打破，生成后端中有模型采样，即使底层计数是确定的，最终输出仍可能因随机种子与后端状态而变化。复现时应固定随机种子、记录后端版本与解码参数，并区分代码开源与系统可运行：代码可用不代表本地一定能跑通发音工具与大模型接口，还需检查系统依赖与网络条件。

实验条件是什么：在哪些语言上测、用什么指标？

论文的验证逻辑分为演示流程与多语言验证两层。演示流程用命令行走完 4 步：查看清单、评估基线、优化选择、缺口生成。示例语言包括英语、孟加拉语、阿拉伯语等类型差异较大的语言，目的是说明操作与语言无关。评估模块输出结构化报告，包括音素、双音素与三音素相对清单的覆盖百分比，分布质量指标包括散度、熵与综合多样性分数，文本质量统计包括词汇多样性与可读性，以及覆盖随规模增长的饱和轨迹。报告支持 3 种详细程度并可导出为结构化格式。

下表把评估维度整理成同一框架，比较问题是给定文本语料与目标语言，报告应回答哪些可核对的问题。公平条件是同一转写、同一清单与同一计数口径，指标方向是覆盖百分比越高越好，分布散度越小表示越接近参照，熵与多样性分数需结合目标分布解读而非越大越好。表中语言规模数字来自原文，算法细节来自正文描述。

该表的主要收益是把覆盖、分布与成本分开看，避免只看单一覆盖率。代价是原文没有给出每种语言的划分、采样方式、聚合方法与统计显著性，也没有报告硬件预算与运行时间表。论文明确提到比较达到 95 百分比与 100 百分比覆盖所需的句子数，并展示 CELF 与贪心等价覆盖但用时更少，但未给出可逐格复述的数字表。因此该节只能说明比较设计，不能引用不存在的精确胜负数字。复现时应自己固定候选池大小、随机种子与目标阈值，并分别记录句子数与墙钟时间。

主结果支持什么：更少句子达到接近完全覆盖吗？

论文报告的中心趋势是覆盖优化选择能以显著更少的句子实现接近最优的音素覆盖，优于随机基线。演示中从同一文本池出发，比较不同算法达到高覆盖所需的句子数，并显示加速版本在等价覆盖下用时更少。论文还报告框架已在 40 种语言 12 个语系上验证，支持开箱处理 100 多种语言，清单库覆盖 2186 种语言。这些陈述支持该工具具有跨语言可操作性，但由于缺少逐语言逐算法的数字表，无法判断每种语言上节省了多少句子，也无法判断节省是否在所有语系上一致。

表达上要区分报告、支持与推测。论文直接报告的是工具功能、算法集合与验证规模，有限支持的是优化选择优于随机的趋势，未验证的推测是该趋势能直接转化为合成或识别性能提升。原文没有报告下游语音合成或识别的听感或错误率实验，因此不能把覆盖率提高等同于音质或识别率提高。总体趋势不等于每组都成立，某些音素高度集中的语言可能随机基线也不差，某些转写质量差的语言可能瓶颈在映射而非选择。

复述时应保留实际可运行策略。贪心、CELF 与分布感知是演示中可直接运行的策略，随机是基线，精确求解是小规模参照。不能用事后最优值代替可部署收益，也不能把加速比的上限表述推广为所有规模都成立。论文对加速的表述是最多两个数量级，这应理解为上限而非平均值，实际加速取决于池子大小与覆盖饱和程度。

对照与反证：拿掉哪一块会发生什么、哪条路走不通？

虽然论文没有以消融表形式给出数字，但可以从方法设计中读出 3 组对照含义。第一组是选择策略对照：贪心对随机，检验优化是否真比随机挑更省句子；CELF 对贪心，检验加速是否改变选择结果，原文称两者覆盖等价，差异应在时间而不在覆盖。第二组是精确对照：小实例上用整数规划给出真值，用于衡量贪心解与最优解的差距，超出小规模后精确方法不再可用，这本身就是可扩展性的反证。第 3 组是分布与多目标对照：纯覆盖目标对分布感知与多目标，检验为自然度与分布付出的额外句子代价。

失败条件也值得初学者记住。如果候选池本身缺少某些音，再强的选择器也无法达到 100% 覆盖，此时必须切换到生成补缺。如果转写与清单映射有大量未映射符号，覆盖率的分母与分子口径不一致，评估报告会虚高或虚低。如果只看音素覆盖而忽略双音素与三音素，可能出现单音全覆盖但上下文组合缺失的情况，下游合成仍会遇到未见过的音过渡。论文的评估模块同时报告 3 级覆盖与饱和轨迹，正是为了暴露这类问题：当增加同源文本不再提升覆盖时，说明应换数据源或转入生成，而不是继续扩大随机池。

原文未报告去掉映射桥、去掉音位打分或去掉分布项后的定量下降，因此不能写拿掉后必然怎样。能说的是这些组件的安排理由：映射桥保证可比性，打分保证生成可用性，分布项保证可用性。复现时若要补消融，应固定同一池子与同一阈值，分别记录覆盖率、所需句子数与分布散度，并单独报告未映射符号数，避免把符号问题误读为算法问题。

边界在哪里：哪些关键数字与成本没有报告？

这篇工作的边界首先是证据粒度。论文给出了验证规模与功能清单，但没有给出逐语言的覆盖率表、逐算法的句子数表与墙钟时间表，也没有给出词汇多样性、可读性与分布指标的完整定义与计算公式。综合多样性分数被提到，但原文片段未给出它的数学形式，因此不能复述其计算步骤。对于刚入门的读者，这意味着可以复述趋势，但不能引用不存在的精确数字。

其次是外部依赖。发音转换依赖外部语音合成器，发音特征依赖外部特征库，大模型生成依赖云端接口或本地量化模型，数据集检索依赖外部仓库。这些依赖的版本、语言覆盖与调用成本都会影响复现。论文未报告推理开销、输出速度与实际延迟，也未报告生成环节的接受率与人工质检量，因此不能承诺省句子就一定省总成本，生成与质检可能引入新成本。

第三是评价边界。覆盖是文本层面的语音学覆盖，不是录音质量、说话人多样性、标注准确性或下游任务性能的保证。未测量误判率、延迟或成本时，不应承诺这些量得到改善。论文的生成式人工智能使用声明也值得注意：声明称生成式工具用于文稿格式与拼写检查，以及软件测试与文档格式辅助，作者对内容负责。这提示读者在复现时应把文档描述与代码实现分开核对，以代码与运行日志为准。

复现先做什么：从清单检查到四步命令

复现的第一步不是直接选句子，而是做环境与清单检查。按论文描述安装包并确认命令行可用，检查发音工具在目标语言上能否正常转写，查询目标语言的清单与映射，记录未映射符号。如果未映射符号很多，应先解决符号对齐，否则后续覆盖率不可比。建议从演示提到的语言入手，例如先跑通清单查询命令，再换到自己的目标语言。

第二步跑基线评估。给定一份已有文本语料，运行评估命令得到音素、双音素与三音素的覆盖报告、分布比较与饱和轨迹。重点看缺失表与饱和曲线：如果曲线早早走平，说明同源文本的边际收益已耗尽，继续加量意义不大。如果缺失集中在特定音，记下这些目标音作为后续选择与生成的检验点。报告可导出为结构化文件，便于与后续优化结果对比。

第三步做优化选择。从同一文本池出发，分别运行贪心、加速版本与分布感知选择，固定随机种子与目标阈值，记录达到高覆盖所需的句子数与墙钟时间，并与随机基线对比。注意保留候选池、语言代码、转写版本与清单版本完全一致，否则比较不公平。小规模子集上可用精确求解做参照，但不要指望它能扩展到大池子。第 4 步处理剩余缺口，调用生成命令针对缺失的双音素或三音素补句子，并用语音与音位打分验收，验收后再回灌覆盖追踪器复算覆盖率。代码仓库当前可用，论文同时提到包索引与持久标识，复现时应记录具体版本号与提交哈希。

何时值得尝试：给新手的三条判断与下一步验证

当同时满足 3 个条件时，这个工具最值得尝试。第一，目标是为录制或训练准备文本，且关心稀有音是否被覆盖。第二，目标语言有可用的发音转换与清单映射，或至少能检查并接受当前的未映射比例。第三，有较大的候选文本池需要压缩，或已有语料怀疑存在缺口需要诊断。在这些条件下，用评估先诊断、用选择压缩、用生成补缺的顺序是合理的。反之，如果目标是直接提升合成自然度或识别错误率，还需要补下游实验，不能只靠覆盖率做结论。

对新手而言，最容易误解的是把覆盖百分比当成质量分数。覆盖只回答有没有，分布、可读性、录音条件与说话人设计回答好不好用。另一个误解是把加速版本当成更优的选择结果，原文的含义是等价覆盖下更快，而不是覆盖更高。还有一个误解是把支持 100 多种语言理解为在所有语言上同样准确，实际准确性受转写与映射质量制约，清单库覆盖 2186 种语言不等于每种语言都能高质量转写。

还需补的验证很具体：固定候选池与阈值后补测逐算法的句子数与时间表，补测未映射符号对覆盖率的影响，补测生成句子的接受率与人工可读性，必要时补下游合成或识别的小规模对照。只有补上这些，才能把显著更少句子从定性趋势变成可复述的定量结论。记住这条链条：先沿一个样本走完输入到表示到组件到目标再到输出，再谈公式与平均数，任何跳过符号对齐与公平条件的比较都不值得信任。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1
• 评分模型：muse-spark-1.3-contributor
• 评分请求协议：openai_responses

← 返回 interspeech-2026 论文汇总