普通识别
指令与口述单人指令、填单与口述，逐句返回最终文本。
- 实现
- TEN VAD 断句后正式解码；热词进入提示，号码、数数和车牌由规整层统一处理。起音帧数、阈值与句首补回按场景给出推荐值。
- 输出
- 每句一次 final，词项不带角色。
- 边界
- 有效发声不足 500 ms 的单字短词仍可能漏识，起音参数影响最大。
Skip to content
跳到项目内容普通、角色和目标说话人模式共享音频时间轴；热词构建独立于实时读取路径，模型结果由会话调度合并到兼容协议。 上一交付版本当前版本单位：秒 语音调试 · 文件回放与逐句结果逐句转写、说话人归属与流式会话状态。
- 01接入WebSocket
40 ms 帧、会话参数与并发准入
- 02断句TEN VAD
起音确认、句首补回与尾音
- 03识别ASR · NPU
提前解码与正式 final
- 04热词向量召回
按本句音频召回提示词
- 05角色Nemotron 流式
10 ms 说话人活动
- 06身份TS-ASR · 声纹
只保留注册机主
- 07规整ITN · 规则
号码、数数、车牌、金额
- 08返回兼容协议
逐句 final、rl 与终态
项目速览
业务背景
企业私有部署要求在已接入的 WebSocket 协议下提供流式识别：会议需要区分说话人，终端场景只转写注册机主，行业指令和身份证、手机号需要准确规整。服务运行在客户的 ARM64 服务器与单张昇腾 910B4 上，以加密镜像和授权文件交付，按客户问题清单逐轮回归、出包。
负责范围
- 协议兼容的会话网关、断句与终态调度
- 角色分离与目标说话人识别链路
- 热词召回、号码与数数规整
- 单卡并发调优与容器资源治理
- 加密镜像组包、蓝绿上线与版本回归
0.9 秒
16 路并发时延
不开角色，停止录音到最终结果 p50，上一版本 1.8 秒；52 路 8.0 → 4.6 秒。
50.37 → 40.92%
长会议 DER
复读中止修复后，同一 4 人会议录音的角色错误率复测。
3.40 → 3.32%
回归字错率
约 2.7 万条、50 小时语料经完整链路实时回放，与上一交付版本同口径。
01
核心业务
客户业务端已经接入既有 WebSocket 协议：音频按 40 ms 帧持续推送，服务端逐句返回最终结果，词项上带角色编号。私有化版本必须保持这些字段语义和断句结构，新能力只能在服务端内部实现，并以默认关闭的参数提供。
同一服务承担三类识别：普通识别、会议角色分离、只转写注册机主的目标说话人识别。三者共用断句、热词和文本规整，但对音频切分、身份归属和空结果的要求不同。运行环境是客户的 ARM64 服务器与单张昇腾 910B4，模型以加密包交付并绑定授权卡号，客户问题按编号逐轮回归、出包。
- 01协议兼容
- 保持句段、词项和 rl 角色字段的既有语义，不擅自合并或拆分句子；参数化能力的默认值与参数化前逐项一致。
- 02识别与身份
- VAD 断句、最终识别、说话人活动和声纹门控围绕同一音频区间合并，时间区间决定文字归属。
- 03单卡运行
- 识别、角色和声纹模型共用一张 NPU，热词召回与特征计算在 CPU 侧，并发需要在时延和角色完整之间取舍。
- 04迭代交付
- 客户原音取证、按真实参数复现、先写判据再修复，纯镜像验证后组包，公网蓝绿切换。
02
识别模式
角色分离
多人会议会议转写，词项标注说话人编号。
- 实现
- Nemotron-3-Diarization 流式推理（chunk 30 / lookahead 10）输出 10 ms 说话人活动；ASR 片段按区间匹配主通道，横跨多人的片段标 0 不猜测，后续以 speaker_revision 修订。
- 输出
- 词项 rl 角色编号；引擎与官方模型逐帧对照，72,000 次判定差 1。
- 边界
- 稳定支持 4 个角色；重叠讲话没有分离能力。
目标说话人
机主模式终端只转写注册机主，周围人声不进入结果。
- 实现
- 三段注册音频经 VAD 筛查后提取参考声纹，TS-ASR 以参考为条件解码；声纹波形门控（Speaker VAD）作为显式选项，默认关闭。
- 输出
- 机主不在场时应为空，机主与他人交替时逐句过滤。
- 边界
- 现场人声嘈杂或注册音频质量差时仍会漏放非机主片段；纯净条件下未出现泄漏。
03
技术栈
- 会话与协议
- GoWebSocketHTTP并发准入
- 语音模型
- TEN VADASR / TS-ASRNemotron-3-DiarizationERes2Net 声纹
- 热词与文本
- 向量召回OpenBLASITN 规整
- 私有运行
- Ascend 910B4OMARM64Python 模型服务Docker
- 验证与交付
- CER / DER 回归纯镜像验证加密模型包蓝绿切换
04
系统架构与部署
Go 会话服务
WebSocket / HTTP / Docker管理输入帧、模式、准入名额与会话终态；连接结束时清理尾部音频与待完成解码。
模型服务
Python / Ascend 910B4 / OMASR、TS-ASR、角色与声纹模型编译为 OM 在 NPU 执行；CPU 辅助组件使用受控线程配置。
热词与文本
CPU 向量召回 / OpenBLAS / ITN热词库后台构建快照，按句召回；号码、数数、车牌与金额由规整层统一处理。
交付物
加密模型包 / 授权文件 / 单个 zip镜像、模型密文和授权分层；组包后从 zip 内流式读回校验摘要。
05
热词体系：十万条词库与每句 50 个名额
词库容量和单句可用名额是两个量。识别模型每句只能接收有限的提示词，所以先按本句音频召回，再分配名额。
- 10 万条
- 热词库
- 50 个 / 300 字
- 每句提示名额
- 开始帧
- 会话热词
- 73–91 秒
- 十万条重载
每个库可存 10 万条；导入在后台编码并发布快照，识别继续读旧版本。
按本句音频相关度从词库召回；会话热词先占位，内置行业词表补位。
终端在会话开始时随参数下发，只对本会话生效。
隔离环境实测；重载期间普通与角色请求持续返回结果。
召回走 CPU 与 OpenBLAS，不占用 NPU。更换召回模型只替换适配层和镜像层工件，加密模型包与客户授权不变。
06
并发性能：停止说话到最终结果
5 人会议录音，所有路同时开始、按实时速度推送；指标为停止录音到收到最终结果的 p50，两轮取均值。所有档位 0 次会话失败、0 次角色异常。
不开角色
16 路−50%
32 路−47%
52 路−43%
开角色
16 路−55%
32 路−58%
52 路−37%
同一张卡上排查过资源去向：NPU 执行串行，多开推理进程只拉长单次时延（1 进程 31.6 ms/次，4 进程 139.7 ms/次，总吞吐反降 9.5%）。52 路开角色已超出单卡能力，放开会话内并发能把时延降到 8 秒，但只有 24/52 路识别出全部 5 人。
07
核心业务链路
句尾与会话结束不是同一个事件
- 1PCM 帧
- 2VAD 断句
- 3提前解码
- 4正式 final
- 5会话 terminal
句段确定后可以继续接收语音；客户端停止推流时仍需清理尾部音频与待完成解码。最终文本、角色归属和连接终态分开处理，避免关闭连接时丢掉最后一段，或把句末结果当作整场结束。提前解码卡住时限时等待后并行正式解码，结果不因单路慢请求挂起。
报读号码跨越断句和角色切点
- 1逐字报读
- 2停顿或角色切点
- 3片段各自解码
- 4号码检测
- 5整段重解或续段合并
18 位身份证号经常被停顿或角色切点拆开，前半段转成数字、后半段留作汉字，甚至丢位。切点两侧数字总量达到号码门槛时整段重解；以「身份证号」「电话」等提示词或数字结尾的上一句，紧跟的逐字数字句按号码续接，数数列表不受影响。
08
关键机制与取舍
01复读中止：保住循环前的文字
- 约束
- 最终识别触发复读刹车（「嗯嗯嗯…」「对对对…」）时，原路径返回空结果，前半句有效文字一起丢失；一场 4 人长会议实时回放丢失约 28% 语音。
- 做法
- 中止片段按停顿二分到 2 秒、最多 3 层重试，只拼接正常结束的子段；仍复读时保留循环前文字和一个循环单元。两项开关默认开启，可单独关闭。
- 效果
- 同一录音报错 100 → 1，DER 50.37% → 40.92%。剩余误差主要来自调用方把 rl=0 沿用上一角色；按 speaker_revision 生成 RTTM 后 DER 为 17.55%，官方模型同口径 16.37%。
02号码红线：被切开的号码重新拼回
- 约束
- 身份证、手机号是不能回退的红线。角色分离会在证据不足的位置切段，18 位号码被分进 6 个区间，每段只解出一截。
- 做法
- 相邻区间切断数字串且被切数字总量 ≥7 位时整段重解一次，只有恢复出更长连续数字才替换；门槛避免把两人各说的短号码误判为一串。所有数字规整改动先跑号码红线测试。
- 效果
- 客户原音完整率 0/3 → 3/3；69 条号码用例中分段报读的号码全部转为连续数字。
03数数与号码：用「十」划清界限
- 约束
- 模型会把「二十一」说成「二一」、把数数两两成组，残片再被长号码规则拼成半汉字半数字的串。
- 做法
- 以「逐字报读的号码从不含十」为判据：补省略「十」的拼法和最短解释回退，序列含「十」即按数数接受；拼接结果出现半汉字半数字时止损，保留原文。
- 效果
- 「十八、十九、二十二、十一」规整为「18、19、20、21」，号码红线测试保持通过。
04十万热词：把长任务移出词库写锁
- 约束
- 旧路径在重载期间持有管理写锁，实时识别等待词库操作，表现为连接超时与请求阻塞。
- 做法
- TXT 读取、向量编码和缓存准备移到后台，识别继续读取已发布快照，完成后短锁替换；增加容量与 UTF-8 校验，覆盖并发重载、失败及取消路径。
- 效果
- 隔离 NPU 环境中十万条重载约 73–91 秒，期间普通与角色请求持续返回非空文本和正常终态；失败、非法输入或取消保留旧版本。
05线程治理：同时约束库线程与可见 CPU
- 约束
- Go、Python、OpenMP 与 BLAS 组件叠加后，容器线程任务显著增多，只看主进程数量会漏掉资源消耗。
- 做法
- 核对容器 pids.current、线程归属和推理库配置，限制辅助 Worker 线程参数并设置 24 核 cpuset，重新检查 readiness 与真实 PCM 识别。
- 效果
- 同一验证环境线程任务约 2,813 → 1,621；资源配置与识别协议一起验证，不用线程数下降推断吞吐提升。
09
质量与交付
每轮从客户反馈到交付走同一条链路。交付二进制只从提交构建，换模型时同步换授权，组包前用客户卡号模拟启动。
- 1取证客户原音、参数与日志
- 2复现用客户真实参数重放
- 3定层级端侧、断句、模型或规整
- 4写判据先固定用例再修改
- 5纯镜像验证不挂载任何覆盖
- 6导出扫描镜像层 0 违规
- 7组包读回zip 内流式重算摘要
- 8蓝绿上线切换后公网回放确认
3.40 → 3.32%
整体字错率
约 2.7 万条、50 小时语料按 40 ms 帧实时回放，与上一交付版本同批样本、同一计分口径。
1.70 → 1.40%
车牌字错率
8,816 条车牌语料；修复规整层把车牌误判为号码的回退。
28.9 分钟
组包关键路径
按依赖并行导出、扫描、组包与验收，串行需要 45 分钟。
试过、验证无效的方向
- 多开推理进程单卡执行串行，4 进程总吞吐反降 9.5%。
- 短窗口与短历史 OM算力集中在固定长度 Transformer，收益约 4% 至 10%。
- 放开会话内并发时延下降，但大部分会话少识别说话人。
- 拼音改写兜底回归无收益且会改错，已回退。
- 整段角色模型接入流式链路与按区间流式归属的结构不兼容。
10
AI 协作开发
交付包的构建、打包、加密、上传和回归由 Agent 执行，交付邮件只起草不发送；仓库规则把协议、转写质量、说话人归属和性能拆成独立的验收项。
- Agent 负责
打包、回归与交付草稿
构建并加密交付包、上传对象存储，在 266 条现场音频上跑回归并保留失败证据；交付邮件保存为草稿，由人检查后发出。
- 仓库规则
证据不足不写已修复
固定分支与远端，保持现有协议兼容；不重置或清理任何工作树；打包前先列出阶段与预计耗时，过程中更新。
- 交付闸门
一台机器出包，逐份核对授权
客户制品只在一台机器上构建，每一份授权文件副本发出前核对 SHA-256，与目标机器一致才发送。
失败的尝试作为反例保留，并区分“方法不行”和“当时条件不对”：因时序失败的脚本不记成算法失败。
11
调试工具
12
阶段成果
- 普通、角色分离、目标说话人三种模式在同一兼容协议下交付，新增能力均以默认关闭的参数提供。
- 形成从客户原音到加密交付包的固定迭代链路，每个修复附判据、回归结果与否定结论。
- 并发时延、角色完整与文本质量分别有可复现的测量口径，调优不以单一指标掩盖其他回退。
继续浏览
别急，先让缓存热一下。