start	end	text
0	16320	開會更討厭什麼?除了開會本身,大概是會後整理錄音。一段一個小時的多人討論,導出錄音之後,你要把它變成會議記要。
16860	25800	傳統的語音轉寫工具,確實能幫你把話變成字,但馬上你就會撞上一個更頭疼的問題,誰在什麼時候說了什麼?
25800	28600	张三里四四个人轮流发言
28600	30000	还有插话强话
30000	32340	转写出来的文本是一锅粥
32340	35400	根本分不清哪句是谁说的
35400	38360	这就是所谓说话人分离难题
38360	42060	最近复旦的团队放出了一个开源模型
42060	44300	叫Mouse Transcribe Diaries
44300	48520	他把转写和分离这两件事捏成了一个模型
48520	50320	一次推理全部搞定
50440	52140	而且准确率把豆包
52140	53040	GPT
53040	53680	4O
53680	54400	Gemini
54400	55620	都甩在后面
55800	57800	这期就来拆一拆它
57800	59900	先把问题说清楚
59900	61920	语音转写这件事
61920	63840	技术上叫ASR
63840	65220	自动语音识别
65220	67640	单独看其实已经很成熟了
67640	70540	你手机输入法的语音转文字就是
70540	74800	但真实场景远比一个人对着话筒念要复杂
74800	78920	会议、播客、访谈、电话、讲座
78920	81300	这些录音有三个共同特征
81300	82860	第一、长
82860	85240	动不动几十分钟到一个小时
85240	89940	第二,人多,两个到十几个人不等,还互相打断
89940	96360	第三,杂,有背景噪音,有关门声笑声,还有大段沉默的停顿
96360	100000	对这种录音,光把话转成字远远不够
100000	104200	你还想知道每句话是谁说的,发生在哪一秒
104200	109440	后者,有个专门的名字,叫Dialization,说话人分离
109940	112620	传统做法怎么解决这个问题的?
113240	114140	拼流水线
114140	115360	第一步
115360	116340	用VAD
116340	118320	也就是语音活动检测
118320	121720	把录音切成一小段一小段有人声的片段
121720	122900	第二步
122900	124520	用ASR模型
124520	126080	把每段转成文字
126080	127520	第三步
127520	130140	再上独立的说话人分离模型
130140	132300	给每段贴上说话人标签
132300	133600	第四步
133600	135040	做时间戳对齐
135040	136000	把文字
136000	136920	说话人
136920	138880	时间这三样东西拼回去
138880	140740	听起来挺合理
140740	141820	问题在于
141820	143840	每一步都是独立的模型
143840	145360	每一步都会犯错
145360	147480	而且错误会一路累积
147480	149320	VAD切错了
149320	150720	后面全跟着错
150720	153100	ASR听差了一个词
153100	154920	分离模型也跟着乱
154920	156500	更要命的是
156500	158420	这些模型各自为正
158420	160000	谁也看不到全局
160000	164220	比如同一个人的两段画被切到了不同片段
164220	167500	分离模型很可能把它们当成两个人
167500	170160	这就是模块化方案的死学
170160	171880	局部每一步都最优
171880	173620	拼起来全局崩盘
173620	177380	这次放模型的团队叫OpenMOSS
177380	179420	中文名模斯智能
179420	183360	是从复旦大学邱熙鹏教授团队孵化出来的
183360	186340	邱熙鹏这个名字你可能不熟
186340	189720	但他写的那本神经网络与深度学习
189720	191880	是国内很多高校的教材
191880	195940	他带的团队之前做过一个很有名的对话大模型
195940	196940	也叫MOS
196940	201300	号称中国第一个LayChatGPT的开源模型
201300	205160	所以这支队伍在开源圈是有传统的
205160	208480	这次他们做的Mouse Transcribed Diaries
208480	210240	参数量0.9B
210240	212880	大约9亿完全开源
212880	215100	权重放在Hugging Face上
215100	217300	协议是Apache 2.0
217300	219540	意思是你可以拿去商用
219540	220920	不用交一分钱
220920	224060	这个体量加上这个开放程度
224060	227480	对个人开发者和中小团队特别友好
227480	231500	那它凭什么能把转写和分离捏在一起呢
231500	232760	看架构
232760	236800	它其实是把两个现成的墙模型做了架接
236800	238300	音频那一侧
238300	240980	用的是Whisper Medium的编码器
240980	244920	就是OpenAI那个Whisper的中等版本
244920	247320	负责把声音变成声学特征
247320	248780	文本那一侧
248780	251980	用的是QAM3 0.6B的解码器
251980	253720	通一千问的小模型
253720	255760	负责生成文字
255760	259200	中间用一个适配器把两者连起来
259200	261940	把音频特征做四倍的时间压缩
261940	264040	再塞进文本模型里去
264040	266740	这样做有两个直接的好处
266740	267780	第一
267780	270440	它能一口气吃下超长音频
270440	272860	上下文窗口12万8千
272860	274000	换算下来
274000	276520	大约能一次处理90分钟的录音
276520	277960	完全不用切片
277960	279020	第二
279020	283020	转写和分离是在同一个模型里联合训练的
283020	285840	模型天生就知道这段话是谁的
285840	288240	根本不存在事后拼接的问题
288240	291760	输入是16000赫兹的单声道音频
291760	295940	输出直接就是带说话人标签和时间戳的文本
295940	298400	输出的格式非常紧凑
298400	299800	一眼就能看懂
299800	303100	他把整段录音编码成一个时间流
303100	305420	每句话前面标两样东西
305420	307600	一个是方括号里的时间戳
307600	310260	一个是方括号里的说话人编号
310260	311700	举个例子
311700	312720	开头几秒
312720	314300	方括号0.48
314300	315920	方括号S01
315920	318560	意思是0.48秒开始
318560	320280	说话人1号发言
320280	321920	内容是欢迎各位
321920	323820	到1.66秒结束
323820	326880	紧接着跳到12.26秒
326880	328340	方括号S02
328340	330440	说话人2号接过话茬
330440	334040	这个格式可以直接为给后处理脚本
334040	336020	解析成结构化的段落
336020	338220	每段都带起始时间
338220	339360	结束时间
339360	340800	说话人
340800	342260	文本这四个字段
342260	346260	想导出城JSON还是字幕格式都行
346260	348220	对开发者很友好
348220	351560	你不用再自己写证则去硬抠时间戳了
351560	353660	到了最关键的环节
353660	355060	它到底有多准
355060	357940	团队在四个基准上做了评测
357940	364860	全是真实的长音频多人场景
364860	368340	横跨中文会议和英文播客电影
368340	371100	核心指标是字符错误率
371100	372200	越低越好
372200	375160	我挑几个最能说明问题的数字
375160	378840	在Azheil 4这个中文会议基准上
378840	382160	它的错误率是14.84%
382160	382940	作为对比
382940	384820	豆包是18.18%
384820	388240	Gemini 3 Pro是22.75%
388240	389020	也就是说
389020	391560	它一个0.9B的开源模型
391560	395280	把字节和谷歌的商业模型都压在了身下
395280	399040	在Movies这个英文电影基准上更夸张
399040	402100	它的错误率只有6.36%
402200	405600	而GPT4O是14.37
405600	407320	豆包是9.94
407320	410000	电影对白里有背景音
410000	410900	有口音
410900	411780	有重叠
411780	413360	是最难啃的骨头
413360	414560	它照样通吃
414560	417320	这里还要特别说一个指标
417320	418680	叫德尔塔CP
418680	422080	它衡量的是说话人分离的额外代价
422080	423300	通俗讲就是
423300	425160	为了分清是谁说的
425160	426780	你额外多错了多少
426780	429520	它的这个值只有0.99
429520	430720	几乎为0
430720	435140	意味着分清说话人这件事几乎不拖累转写准确率
435140	438760	这在传统流水线里是想都不敢想的
438760	443180	那它跟现在最流行的开源方案比到底差在哪
443180	447980	先说Whisper,OpenAI的老牌选手,能力很强
447980	449440	但他只管转写
449440	454500	不管分离,你想分清谁说的,得自己再外挂一个模型
454860	459620	再说WhisperX,这个是社区里用的最多的组合方案
459620	464860	他在Whisper基础上接了VAD和PiNote的分离模型
464860	467000	确实能做对齐和分离
467000	469500	但本质上还是拼接流水线
469500	471560	前面说的错误累积问题
471560	473040	他一个都没躲掉
488426	493826	你像个搬砖工一样把它们拼起来,每块砖之间都有缝隙。
493826	501826	Moth这套做法的价值就在于,他把这些砖直接烧成了一整块磁砖,从根上消除了缝隙。
501826	504426	这么能打,部署难不难?
504426	506126	他给了三条路。
506126	512526	第一条,研究用的,直接拿原生Transformers库加载,几行,Pytho。
512526	518326	N代码就能跑,适合你想看内部细节,做二次开发的场景。
518326	521426	第二条生产环境要高吞吐
521426	523606	用SGLine Omni部署
523606	526206	这是一个专门的服务框架
526206	529306	单张H100显卡就能跑起来
529306	530606	并发16路的时候
530606	533066	每秒能处理82秒的音频
533066	535986	换算成时时率是0.092
535986	540246	意味着处理速度是音频播放速度的10倍以上
540246	542406	如果走长音频单路
542406	545526	时时率最低能压到0.0197
545526	548926	也就是处理速度是音频时长的50倍
548926	552206	一个小时的录音一分多钟就处理完了
552206	553706	第三条
553706	555086	用VLLM
555086	557346	适合你的环境是Cuda12
557346	561166	因为SGLAM Omni目前要求Cuda13
561166	563806	VLLM的兼容性更好
563806	565246	三条路
565246	566606	从研究到生产
566606	569046	基本把各种需求都覆盖了
569046	572406	但不是所有人都愿意敲命令型
572406	576006	所以团队还做了一个字幕网页应用
576006	578066	叫MPD Subtitle Web
578066	580246	它就是个浏览器界面
580246	582606	你上传一段音频或视频
582606	584126	它自动跑模型
584126	587926	跑完你能在网页上直接审阅转写结果
587926	590106	谁说了什么一目了然
590106	592086	审完点一下导出
592086	593386	格式随你挑
593386	595406	JSON给程序用
595406	598466	SRT和S是标准字幕格式
598466	600546	直接位给播放器就行
600546	604946	甚至还能用Fpack把字幕稍录进视频
604946	607526	一键导出一个带字幕的MP4
607526	609966	界面支持中文和英文
609966	612626	会自动跟着你浏览器的语言走
612626	615526	还有个很实用的小功能叫热词
615526	617926	如果你录音里有专有名词
617926	618706	人名
618706	619846	行业术语
619846	621386	模型老式识别错
621386	624246	你可以在提示词里加几个热词
624246	626566	引导它往正确的方向认
626566	629846	这对行业内部的录音特别管用
629846	632626	这种能力到底能用在哪
632626	635246	我自己最看好的几个场景
635246	637326	第一会议纪要
637326	639146	一个小时的多人会议
639146	640086	扔进去
640086	643826	几分钟出来一份带说话人和时间戳的全文
643826	646706	秘书或者你自己再做摘要就行
646706	649726	省下来的时间是实打实的
649726	652446	第二播客和视频字幕
652446	656226	做内容的人最痛苦的就是给节目上字幕
656226	658706	这个工具能直接出SRT
658706	660866	连谁说的都给你雕好了
660866	662006	第三
662006	663206	访谈整理
663206	663986	记者
663986	665906	研究员做智性访谈
665906	668386	几十段录音要转写要编码
668386	670986	这是真正能解放生产力的工具
670986	672086	第四
672086	673526	更专业的领域
673526	674606	法庭记录
674606	675686	医疗口述
675686	676786	客服质检
676786	681546	这些对准确率和说话人识别要求都很高的场景
681546	685366	他的杀手检就是那90分钟的长上下文
685366	687746	意味着绝大部分真实录音
687746	689226	它能一口气吃完
689226	690846	不用你手动切块
690846	692326	想试的话
692326	693706	装起来不复杂
693706	696366	前提是Python 3.12
696366	698346	用UV这个包管理器
698346	699706	建一个虚拟环境
699706	702626	然后从GitHub客龙仓库
702626	705306	一行UVPIP Install装好依赖
705306	709006	它会自动帮你处理PyTorch的GPU后端
709006	710946	装完有两条路
710946	712986	想看代码细节的
712986	716386	直接用Transformers加在模型跑推里
716386	718186	想跑成服务的
718186	723826	用SGLang Omni或者VLLM启动一个API服务
723826	727406	调用方式兼容OpenAI那套音频接口
727406	730366	你原来用Whisper API的代码
730366	732986	改个地址就能直接迁移过来
732986	735646	模型权重从Hugging Face拉
735646	737166	第一次跑会下载
737166	738466	大约两个G
738466	742366	最后说一个让这个项目分量很重的头衔
742366	745186	这个模型7月9号才开源
745186	747046	到现在不到20天
747046	749946	GitHub已经冲到1300多star
749946	754646	还登上了Trendshift当日Python仓库的第11名
754646	756326	更硬的成绩是
756326	759806	2026年语音领域的鼎会Interspeech
759806	763626	办了第二届多语言低资源语音挑战赛
763626	766526	他拿了第一名覆盖14种语言
766526	769166	一个久易参数的开源模型
769166	773206	在长音频多说话人这个最难的真实场景上
773206	776806	同时打赢了准确率和效率两场仗
776806	779126	还把代码和权重都敞开了
779126	780726	代码在GitHub
780726	782406	搜OpenMOSS
782406	783486	斜杠
783486	786586	MouseTranscribedDiaries就能找到
786586	788146	权重在HuggingFace
788146	791226	如果你平时要跟长录音打交道
791226	792206	做字幕
792206	793126	做记要
793126	794446	做访谈整理
794446	797606	这个工具真的值得装一个试试
797606	799126	这期到这里
799126	800326	我们下期见