逐字稿文字預覽
开会更讨厌什么?除了开会本身,大概是会后整理录音。一段一个小时的多人讨论,导出录音之后,你要把它变成会议纪要。 传统的语音转写工具确实能帮你把话变成字,但马上你就会撞上一个更头疼的问题,谁在什么时候说了什么? 张三里四四个人轮流发言 还有插话强话 转写出来的文本是一锅粥 根本分不清哪句是谁说的 这就是所谓说话人分离难题 最近复旦的团队放出了一个开源模型 叫Mouse Transcribe Diaries 他把转写和分离这两件事捏成了一个模型 一次推理全部搞定 而且准确率把豆包 GPT 4O Gemini 都甩在后面 这期就来拆一拆它 先把问题说清楚 语音转写这件事 技术上叫ASR 自动语音识别 单独看其实已经很成熟了 你手机输入法的语音转文字就是 但真实场景远比一个人对着话筒念要复杂 会议、播客、访谈、电话、讲座 这些录音有三个共同特征 第一、长 动不动几十分钟到一个小时 第二,人多,两个到十几个人不等,还互相打断 第三,杂,有背景噪音,有关门声笑声,还有大段沉默的停顿 对这种录音,光把话转成字远远不够 你还想知道每句话是谁说的,发生在哪一秒 后者,有个专门的名字,叫Dialization,说话人分离 传统做法怎么解决这个问题的? 拼流水线 第一步 用VAD 也就是语音活动检测 把录音切成一小段一小段有人声的片段 第二步 用ASR模型 把每段转成文字 第三步 再上独立的说话人分离模型 给每段贴上说话人标签 第四步 做时间戳对齐 把文字 说话人 时间这三样东西拼回去 听起来挺合理 问题在于 每一步都是独立的模型 每一步都会犯错 而且错误会一路累积 VAD切错了 后面全跟着错 ASR听差了一个词 分离模型也跟着乱 更要命的是 这些模型各自为正 谁也看不到全局 比如同一个人的两段画被切到了不同片段 分离模型很可能把它们当成两个人 这就是模块化方案的死学 局部每一步都最优 拼起来全局崩盘 这次放模型的团队叫OpenMOSS 中文名模斯智能 是从复旦大学邱熙鹏教授团队孵化出来的 邱熙鹏这个名字你可能不熟 但他写的那本神经网络与深度学习 是国内很多高校的教材 他带的团队之前做过一个很有名的对话大模型 也叫MOS 号称中国第一个LayChatGPT的开源模型 所以这支队伍在开源圈是有传统的 这次他们做的Mouse Transcribe Diaries 参数量0.9B 大约9亿完全开源 权重放在Hugging Face上 协议是Apache 2.0 意思是你可以拿去商用 不用交一分钱 这个体量加上这个开放程度 对个人开发者和中小团队特别友好 那它凭什么能把转写和分离捏在一起呢 看架构 它其实是把两个现成的墙模型做了架接 音频那一侧 用的是Whisper Medium的编码器 就是OpenAI那个Whisper的中等版本 负责把声音变成声学特征 文本那一侧 用的是QAM3 0.6B的解码器 通一千问的小模型 负责生成文字 中间用一个适配器把两者连起来 把音频特征做四倍的时间压缩 再塞进文本模型里去 这样做有两个直接的好处 第一 它能一口气吃下超长音频 上下文窗口12万8千 换算下来 大约能一次处理90分钟的录音 完全不用切片 第二 转写和分离是在同一个模型里联合训练的 模型天生就知道这段话是谁的 根本不存在事后拼接的问题 输入是16000赫兹的单声道音频 输出直接就是带说话人标签和时间戳的文本 输出的格式非常紧凑 一眼就能看懂 它把整段录音编码成一个时间流 每句话前面标两样东西 一个是方括号里的时间戳 一个是方括号里的说话人编号 举个例子 开头几秒 方括号0.48 方括号S01 意思是0.48秒开始 说话人1号发言 内容是欢迎各位 到1.66秒结束 紧接着跳到12.26秒 方括号S02 说话人2号接过话茬 这个格式可以直接为给后处理脚本 解析成结构化的段落 每段都带起始时间 结束时间 说话人 文本这四个字段 想导出城JSON还是字幕格式都行 对开发者很友好 你不用再自己写证则去硬抠时间戳了 到了最关键的环节 它到底有多准 团队在四个基准上做了评测 全是真实的长音频多人场景 横跨中文会议和英文播客电影 核心指标是字符错误率 越低越好 我挑几个最能说明问题的数字 在Azhel 4这个中文会议基准上 它的错误率是14.84% 作为对比 豆包是18.18% Gemini 3 Pro是22.75% 也就是说 它一个0.9B的开源模型 把字节和谷歌的商业模型都压在了身下 在Movies这个英文电影基准上更夸张 它的错误率只有6.36% 而GPT4O是14.37 豆包是9.94 电影对白里有背景音 有口音 有重叠 是最难啃的骨头 它照样通吃 这里还要特别说一个指标 叫德尔塔CP 它衡量的是说话人分离的额外代价 通俗讲就是 为了分清是谁说的 你额外多错了多少 它的这个值只有0.99 几乎为0 意味着分清说话人这件事几乎不拖累转写准确率 这在传统流水线里是想都不敢想的 那它跟现在最流行的开源方案比到底差在哪 先说Whisper,OpenAI的老牌选手,能力很强 但他只管转写 不管分离,你想分清谁说的,得自己再外挂一个模型 再说Whisper X,这个是社区里用的最多的组合方案 他在Whisper基础上接了VAD和PiNote的分离模型 确实能做对齐和分离 但本质上还是拼接流水线 前面说的错误累积问题 他一个都没躲掉 最后说PiNote 他是专门的分离工具 做得相当好 但他只管分离 转写的另找别人 你看出规律了吗 传统的整个生态是被切碎的 转写归转写 分离归分离 你像个搬砖工一样 把它们拼起来 每块砖之间都有缝隙 Moth这套做法的价值就在于 他把这些砖直接烧成了一整块瓷砖 从根上消除了缝隙 这么能打 部署难不难 他给了三条路 第一条 研究用的 直接拿原生Transformers库加载 几行Pytho N代码就能跑 适合你想看内部细节 做二次开发的场景 第二条 生产环境要高吞吐 用SGLine Omni部署 这是一个专门的服务框架 单张H100显卡就能跑起来 并发16路的时候 每秒能处理82秒的音频 换算成时时率是0.092 意味着处理速度是音频播放速度的10倍以上 如果走长音频单路 时时率最低能压到0.0197 也就是处理速度是音频时长的50倍 一个小时的录音一分多钟就处理完了 第三条 用VLLM 适合你的环境是Cuda12 因为SGLANG OMNI目前要求Cuda13 VLLM的兼容性更好 三条路 从研究到生产 基本把各种需求都覆盖了 但不是所有人都愿意敲命令型 所以团队还做了一个字幕网页应用 叫MPD Subtitle Web 它就是个浏览器界面 你上传一段音频或视频 它自动跑模型 跑完你能在网页上直接审阅转写结果 谁说了什么一目了然 审完点一下导出 格式随你挑 JSON给程序用 SRT和S是标准字幕格式 直接位给播放器就行 甚至还能用Fpack把字幕稍录进视频 一键导出一个带字幕的MP4 界面支持中文和英文 会自动跟着你浏览器的语言走 还有个很实用的小功能叫热词 如果你录音里有专有名词 人名 行业术语 模型老式识别错 你可以在提示词里加几个热词 引导它往正确的方向认 这对行业内部的录音特别管用 这种能力到底能用在哪 我自己最看好的几个场景 第一会议纪要 一个小时的多人会议 扔进去 几分钟出来一份带说话人和时间戳的全文 秘书或者你自己再做摘要就行 省下来的时间是实打实的 第二播客和视频字幕 做内容的人最痛苦的就是给节目上字幕 这个工具能直接出SRT 连谁说的都给你雕好了 第三 访谈整理 记者 研究员做智性访谈 几十段录音要转写要编码 这是真正能解放生产力的工具 第四 更专业的领域 法庭记录 医疗口述 客服质检 这些对准确率和说话人识别要求都很高的场景 他的杀手检就是那90分钟的长上下文 意味着绝大部分真实录音 它能一口气吃完 不用你手动切块 想试的话 装起来不复杂 前提是Python 3.12 用UV这个包管理器 建一个虚拟环境 然后从GitHub客龙仓库 一行UVPIP Install装好依赖 它会自动帮你处理PyTorch的GPU后端 装完有两条路 想看代码细节的 直接用Transformers加在模型跑推里 想跑成服务的 用SGLang Omni或者VLLM启动一个API服务 调用方式兼容OpenAI那套音频接口 你原来用Whisper API的代码 改个地址就能直接迁移过来 模型权重从Hugging Face拉 第一次跑会下载 大约两个G 最后说一个让这个项目分量很重的头衔 这个模型7月9号才开源 到现在不到20天 GitHub已经冲到1300多star 还登上了Trendshift当日Python仓库的第11名 更硬的成绩是 2026年语音领域的鼎会Interspeech 办了第二届多语言低资源语音挑战赛 他拿了第一名覆盖14种语言 一个久易参数的开源模型 在长音频多说话人这个最难的真实场景上 同时打赢了准确率和效率两场仗 还把代码和权重都敞开了 代码在GitHub 搜OpenMOSS 斜杠 MouseTranscribedDiaries就能找到 权重在HuggingFace 如果你平时要跟长录音打交道 做字幕 做记要 做访谈整理 这个工具真的值得装一个试试 这期到这里 我们下期见
本次執行流程與問題處理
下達指令
預期流程
- 自動字幕優先，Whisper 作為備援
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：641.0 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：43.7 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.8 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.9 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：1.0 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：140.9 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：1.0 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：1.1 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。