语音识别、语音合成这类 AI 模型要支持方言，需要大量「方言语音 +
对应文本」的高质量训练数据。方言种类多、口音差别大，自动识别不准，只能靠大批标注人员人工转写和录音，再经过质检把关。这些工作以前分散在表格和人工流程里，存在几个问题：任务分配和进度很难统计，质检抽样没有统
一标准，重复劳动和数据冲突很多，产出的数量和质量都没法核算。本平台面向方言语料采集和标注团队，把任务下发、标注、质检、统计放在同一个系统里完成，为方言语音模型持续提供可追溯、可度量的训练数据。
- 任务管理：按方言创建标注任务，支持「语音转文本」和「文本转语音」两类。可以批量导入音频或文本（Excel 或压缩包），把任务分配给指定团队，导入失败的数据会单独列出来便于排查。
- 标注工作台
- 语音转文本：标注员听音频写转写文本。方言配置了转写服务的，会先自动转写一版，人工在此基础上修改。
- 文本转语音：标注员对照文本录音并上传。
- 两类都支持丢弃无效数据、驳回后重新标注，每一次标注都留有历史版本。
- 质检管理：可以按比例或按条数抽检，可以按团队抽样，支持盲检（质检员看不到标注员是谁）。质检员逐条判定通过或驳回，驳回时选择预设的驳回原因，被驳回的数据回到原标注员手里重新处理。系统会实时显示最多还能抽检
多少条、已经质检了多少条。
- 团队与方言管理：维护标注团队和成员，维护方言字典和对应的转写服务地址，任务和质检都可以按团队圈定人员范围。
- 数据中心与统计：按任务、方言、人员统计标注条数、音频时长、丢弃量、质检通过和驳回量，有个人数据看板，支持导出明细。另外有定时统计脚本，按部门生成报表并发邮件。
- 系统管理：基于 RuoYi 的用户、角色、部门、菜单权限管理，按部门隔离数据，记录操作日志。
架构与技术栈
- 前后端分离，基于 RuoYi-Vue 3.8.9 二次开发。
- 后端：Spring Boot 2.5 + Spring Security + JWT 认证，Maven 多模块（接口层 admin、基础设施 framework、业务层 system、公共 common、定时任务 quartz、代码生成 generator）。
- 持久层同时用 MyBatis 和 MyBatis-Plus：统计类复杂 SQL 写在 XML 里，简单的增删改查用 Wrapper 拼。分页用 PageHelper，连接池是 Druid，支持主从数据源动态切换，缓存和会话放在 Redis。
- 前端：Vue 2 + Element UI。音频批量导入、方言自动转写由独立的 Python 服务提供，前端直接调用。
- 部署：Shell 脚本一键打包启停。数据库变更用按日期命名的补丁 SQL 管理。
亮点与难点
1. 多人同时质检时的并发控制：多个质检员同时抽数据，容易抽到同一条、重复提交、或者提交时标注员已经重新标注过。这里做了三层防护：
- 抽取时给数据加锁，锁有过期时间，超时会自动释放，别人可以接管；
- 提交时先用 SELECT … FOR UPDATE 锁住这条标注记录，让同一条数据的并发提交排队执行，并检查是否已经质检过；
- 再用版本号做比较后更新（CAS）：只有「锁还在本人手里，而且标注版本没变」时才允许提交，否则拒绝并提示重新抽取。
这样避免了重复质检，也避免了质检员审的是旧版本。
2. 质检抽样：抽检上限按「已标注、未质检或已通过」的数据动态计算，同时支持按比例和按条数两种方式，并按团队成员过滤。抽人时优先选被抽检次数少的标注员，保证每个人都会被抽到。
3. 统计口径统一：文本转语音的数据，一个文本会有几十个人分别录音，而且驳回重录会生成新的记录，很容易统计错。平台把进度类指标统一定义为「按文本 +
标注员去重」，把工作量类指标定义为「按被质检的录音版本去重」，并用真实数据核对过，保证列表、抽检提示和导出报表的数字一致。
4. 标注历史可追溯：已标注、未质检的数据被重新标注时，先把上一版存到历史表，再在原记录上更新；被驳回后重录则新建一条记录。主表只放当前有效的数据，统计查询不会被历史版本干扰，同时又能查看完整的修改记录。
5. 大数据量下的统计性能：数据中心和报表脚本用「多个统计来源分别查询，再 UNION ALL
合并，最后按条件求和」的写法，单表只扫一遍就算出多个指标。先在小表上缩小范围再关联，并给常用查询路径建了联合索引，保证几十万条记录也能快速出报表。
评论