Google DiarizationLM 新模型：會議逐字稿的說話者標記可以如何修正？
Google 在 Hugging Face 提供 DiarizationLM-Gemma-4-E4B-v1，以語言模型修正既有逐字稿的說話者標記。本文解釋後處理流程、官方評測與語言限制，區分它與直接聽音檔的語音模型。
會議逐字稿的字可能轉對，說話者卻標錯：主管的回答被放到提問者名下，後續摘要就會連責任歸屬一起弄錯。Google 在 Hugging Face 提供 DiarizationLM-Gemma-4-E4B-v1，針對這類標記問題做後處理。
這是一個根據 Gemma 微調的模型。它讀取已有文字與說話者標籤，再嘗試修正分配，不是單獨把原始錄音轉成完整逐字稿的入口。
DiarizationLM 位於語音流程的後段
依 Google 官方模型卡，輸入需要上游自動語音辨識與說話者分離結果。說話者分離就是判斷錄音中的不同聲音分別屬於誰，常用 Speaker A、Speaker B 等標籤表示。
模型再利用對話文字的脈絡，調整可能不合理的標記。例如一個問答被切成零碎片段，後處理可嘗試讓文字與角色分配更一致。它依賴上游資訊，原始轉寫若已漏掉重要內容，後段模型也無法憑空還原聲音證據。
官方資料顯示改善幅度因資料而異
模型卡列出四組評測，Fisher 的字詞說話者錯誤率從 5.32% 降到 2.99%。這項指標衡量多少字被分給不正確的說話者，數值越低越好。
其他會議資料的改善則較小，例如 ICSI 從 14.70% 到 14.10%，AMI 從 15.68% 到 14.89%。這表示後處理有潛力，卻不能把單一效果較好的資料集當成所有會議的代表。
這些結果以官方評測條件為範圍，不足以保證繁體中文、多人插話或特殊口音都得到同樣改善。匯入臺灣會議前，應取少量已由人確認的錄音與逐字稿，逐句比較角色是否分配正確。
研究模型與正式 Google 產品不同
模型卡明確標示這不是官方支援的 Google 產品。對研究者而言，可用來測試與延伸；對正式工作流程，則還要處理模型執行、版本固定與例外檢查。
我會優先把它用在有清楚原音、有人工標記基準的流程。若會議結論涉及誰同意了什麼，最好保留時間點與原音核對，避免語言上「看起來合理」的修正掩蓋真正發言。
DiarizationLM 常見問題
可以直接上傳 MP3，讓它完成全部轉寫嗎？
這個模型是逐字稿與說話者標籤的後處理工具。原始音訊需要先經過語音辨識與說話者分離流程。
修正後就能確定每句是誰說的嗎？
仍可能標錯，尤其多人重疊或上游轉寫錯誤時。重要語句應連回原音核對，模型結果提供的是候選修正。
延伸閱讀：NVIDIA Nemotron 3 Diarization 是什麼？1 億參數模型標記 8 位說話者
結語：讓責任歸屬保留聲音證據
這項研究的實用性在於改善既有流程的一個常見弱點。成功標準應是角色分配更正確，而不是逐字稿更順口，尤其重要會議仍需能回到原始錄音查證。
