最近在做一個(gè)客服錄音質(zhì)檢項(xiàng)目ASR 選型是繞不開的一環(huán)。沒接觸過的人可能覺得語音識(shí)別就是把聲音轉(zhuǎn)成文字難度不大。但真正跑到工程落地就會(huì)發(fā)現(xiàn)普通話標(biāo)準(zhǔn)、環(huán)境安靜、單人說話的理想條件只是少數(shù)情況。真實(shí)業(yè)務(wù)里帶口音的普通話、方言對白、嘈雜的呼叫中心錄音、會(huì)議室的混響遠(yuǎn)場聲往往才是常態(tài)。這也是騰訊混元 Hy ASR 3.0 preview 發(fā)布的時(shí)候我第一眼注意到“通用識(shí)別、方言覆蓋、場景魯棒性全面提升”這三個(gè)關(guān)鍵詞的原因。這篇內(nèi)容不打算只做一個(gè)發(fā)布會(huì)式的羅列解讀而是圍繞 Hy ASR 3.0 preview 的技術(shù)定位拆解它到底解決了哪些工程痛點(diǎn)然后給出一套從環(huán)境準(zhǔn)備、接口調(diào)用、效果評估到生產(chǎn)落地的完整方法。無論你是在做會(huì)議轉(zhuǎn)寫、客服質(zhì)檢還是智能化硬件上的語音交互都可以用這篇文章作為選型和評估的參考。1. ASR 到底在解決什么問題1.1 ASR 的基本概念與典型場景ASR 是 Automatic Speech Recognition 的縮寫含義是自動(dòng)語音識(shí)別即把一段語音信號(hào)轉(zhuǎn)換成對應(yīng)的文字序列。很多人搜索 ASR 時(shí)會(huì)被其他同名工具干擾這里先統(tǒng)一口徑本文討論的 ASR 是語音識(shí)別方向的算法能力。在實(shí)際業(yè)務(wù)中ASR 通常不是獨(dú)立存在的模塊而是整個(gè)語音鏈路的第一環(huán)。比如會(huì)議紀(jì)要系統(tǒng)需要先把多人的發(fā)言轉(zhuǎn)換為文字客服質(zhì)檢平臺(tái)需要把錄音轉(zhuǎn)成文本后再做關(guān)鍵詞匹配和情緒分析語音輸入法、智能音箱、車載助手則需要在極低延遲內(nèi)把用戶指令變成文本再交給語義理解模塊。可以說ASR 的識(shí)別質(zhì)量直接決定了后續(xù) NLP 任務(wù)的可用上限。也正是因?yàn)閳鼍氨姸嗖煌瑯I(yè)務(wù)對 ASR 的需求并不一樣有的追求低延遲有的追求長音頻穩(wěn)定有的對敏感詞識(shí)別要求高有的則更看重方言和口音下的準(zhǔn)確率。選擇模型時(shí)不能只看一個(gè)“通用準(zhǔn)確率”而是要結(jié)合自己的業(yè)務(wù)場景去驗(yàn)證。1.2 從傳統(tǒng)語音識(shí)別到端到端模型再到大模型傳統(tǒng) ASR 系統(tǒng)的結(jié)構(gòu)通常是“聲學(xué)模型 發(fā)音詞典 語言模型”三層。聲學(xué)模型負(fù)責(zé)把音頻幀映射到音素或拼音語言模型負(fù)責(zé)給候選詞序列打分各部分配合起來完成解碼。這種方案的問題在于模塊之間錯(cuò)誤傳導(dǎo)明顯而且對于口音、噪聲、新詞的泛化能力比較弱。端到端模型則直接學(xué)習(xí)“音頻特征 - 文本序列”的映射把中間的復(fù)雜建模交給神經(jīng)網(wǎng)絡(luò)。早期的端到端方案通過 CTC 或者注意力機(jī)制實(shí)現(xiàn)了識(shí)別后來逐漸發(fā)展出基于 Transformer 的大規(guī)模預(yù)訓(xùn)練語音模型。大模型的好處一方面是通過海量數(shù)據(jù)學(xué)習(xí)到了更強(qiáng)的音頻表征另一方面是具備更強(qiáng)的上下文理解和糾錯(cuò)能力。這也讓 ASR 從單純“聽寫”逐步演進(jìn)為“理解后再輸出”對不完整表達(dá)、語氣詞、口語化內(nèi)容都有更好的處理方式。騰訊混元 Hy ASR 3.0 preview 走的就是大模型語音識(shí)別路線。從命名來看Hy 是騰訊混元 Hunyuan 方向的語音模型系列3.0 則體現(xiàn)了整個(gè)技術(shù)棧的迭代。我們在第二章會(huì)具體分析這次更新的三個(gè)關(guān)鍵詞。1.3 當(dāng)前 ASR 落地的核心瓶頸如果回顧這兩年 ASR 項(xiàng)目的踩坑經(jīng)歷瓶頸基本集中在三個(gè)方向。其一是方言和口音。中文方言種類多同一方言在不同地區(qū)的口音差異也很大而公開語料里普通話占比偏高導(dǎo)致模型對方言的覆蓋率不穩(wěn)定。其二是聲學(xué)環(huán)境。城市街道噪聲、多人說話、會(huì)議室混響、電話信道壓縮都會(huì)讓模型效果顯著下降這就是所謂的“魯棒性”問題。其三是領(lǐng)域術(shù)語。醫(yī)療、法律、技術(shù)等垂直領(lǐng)域有大量專有名詞通用模型很容易在關(guān)鍵業(yè)務(wù)詞上翻車。因此在看騰訊混元 Hy ASR 3.0 preview 的時(shí)候我建議大家不要只盯著“準(zhǔn)確率提升了多少”而是從通用識(shí)別、方言覆蓋、場景魯棒性三個(gè)維度結(jié)合自己的語料做針對性測試。這比任何榜單數(shù)字都更有參考價(jià)值。2. 騰訊混元 Hy ASR 3.0 preview 的亮點(diǎn)拆解2.1 通用識(shí)別從“能聽清”到“能聽懂”“通用識(shí)別”這個(gè)詞看起來很簡單但在語音識(shí)別領(lǐng)域它往往意味著模型對跨領(lǐng)域、跨說話人、跨設(shè)備的泛化能力。很多模型在標(biāo)準(zhǔn)測試集上效果很好換到真實(shí)會(huì)議錄音或者手機(jī)錄制的語音準(zhǔn)確率立刻出現(xiàn)明顯下滑。通用識(shí)別能力強(qiáng)的模型應(yīng)該在不同性別、不同年齡段、不同情緒狀態(tài)、不同語速下都能保持穩(wěn)定輸出。Hy ASR 3.0 preview 在通用識(shí)別上強(qiáng)調(diào)提升背后的工程價(jià)值是減少業(yè)務(wù)側(cè)的適配成本。過去做一款應(yīng)用可能要針對安靜場景、電話場景、遠(yuǎn)場場景分別調(diào)模型或調(diào)參數(shù)如果通用能力足夠強(qiáng)一套模型就能覆蓋大部分主流程場景只需要在極端場景做補(bǔ)充策略。當(dāng)然通用識(shí)別能力強(qiáng)不等于所有場景都能直接上車。預(yù)覽版本意味著功能形態(tài)基本確定但距離穩(wěn)定生產(chǎn)環(huán)境可能還有一段距離。在實(shí)際接入之前建議先用自己業(yè)務(wù)中的真實(shí)音頻做一輪小樣本評估而不是直接用公開 Demo 的結(jié)果做決策。2.2 方言覆蓋最難啃的硬骨頭漢語方言識(shí)別的難點(diǎn)主要體現(xiàn)在三個(gè)方面。第一是語料稀疏很多方言缺少大規(guī)模轉(zhuǎn)寫數(shù)據(jù)模型很容易出現(xiàn)“聽得見、認(rèn)不出”的情況。第二是文字系統(tǒng)特殊比如粵語、上海話在轉(zhuǎn)寫為文本時(shí)既有標(biāo)準(zhǔn)漢字寫法也有地方慣用字同一個(gè)發(fā)音可能存在多種合理寫法。第三是方言連續(xù)體現(xiàn)象相鄰地區(qū)的口音漸變很難用一個(gè)簡單的標(biāo)簽區(qū)分“某方言”和“帶口音的普通話”。Hy ASR 3.0 preview 提到的“方言覆蓋”提升我理解主要得益于訓(xùn)練數(shù)據(jù)的擴(kuò)展和模型容錯(cuò)能力的增強(qiáng)。對于業(yè)務(wù)方來說方言覆蓋能力更需要驗(yàn)證的問題包括是否支持方言和普通話混合說能不能在方言中夾帶專業(yè)術(shù)語時(shí)保持穩(wěn)定轉(zhuǎn)寫結(jié)果是否使用用戶習(xí)慣的文字表達(dá)這些問題的答案需要結(jié)合具體的方言類別和測試音頻來判斷。假如你的業(yè)務(wù)主要面向四川、廣東、福建等地區(qū)建議單獨(dú)準(zhǔn)備這些區(qū)域的真實(shí)對話音頻進(jìn)行測評并特別關(guān)注數(shù)字、姓氏、地點(diǎn)等關(guān)鍵信息是否準(zhǔn)確。2.3 場景魯棒性如何在真實(shí)環(huán)境里不翻車“魯棒性”來自英文 Robustness在語音識(shí)別領(lǐng)域指的是系統(tǒng)在噪聲、混響、語速變化、信道差異等干擾下仍然保持穩(wěn)定的能力。實(shí)驗(yàn)室環(huán)境里測試效果不錯(cuò)的模型到了真實(shí)場景往往因?yàn)楸尘耙魳贰⒖照{(diào)噪聲、多人同時(shí)說話而產(chǎn)生大量字符錯(cuò)誤。這也是為什么發(fā)布會(huì)或技術(shù)文檔中經(jīng)常單列魯棒性指標(biāo)。做魯棒性評測通常會(huì)把音頻按場景分桶安靜室內(nèi)、戶外街道、車內(nèi)、電話渠道、多人會(huì)議、重口音說話人。然后分別計(jì)算識(shí)別指標(biāo)觀察模型在哪些分桶上掉點(diǎn)嚴(yán)重。Hy ASR 3.0 preview 在場景魯棒性上的提升意味著它的聲學(xué)前端和訓(xùn)練策略對這些問題做了針對性的優(yōu)化。對開發(fā)者而言更實(shí)際的做法是把自己最容易出現(xiàn)的噪聲環(huán)境樣本喂給模型做壓力測試。2.4 對開發(fā)者的落地預(yù)期綜合上面三點(diǎn)我對 Hy ASR 3.0 preview 的定位判斷是它面向的是“真實(shí)業(yè)務(wù)場景識(shí)別”這個(gè)大方向目標(biāo)是把通用識(shí)別、方言支持和復(fù)雜環(huán)境下的穩(wěn)定性統(tǒng)一到一個(gè)模型中減少開發(fā)者組合多個(gè)語音模型或堆疊大量規(guī)則的成本。不過作為預(yù)覽版以下幾點(diǎn)需要特別留意第一接口和能力可能還會(huì)調(diào)整生產(chǎn)項(xiàng)目建議鎖定版本發(fā)布后再上線第二具體支持哪些方言、支持哪些音頻參數(shù)、并發(fā)限制是多少需要以騰訊官方的最新文檔和公告為準(zhǔn)第三由于大模型語音識(shí)別帶有生成式能力在嚴(yán)肅場景下要增加人工抽檢和糾錯(cuò)機(jī)制。3. 環(huán)境準(zhǔn)備與接入前檢查3.1 接入前需要準(zhǔn)備什么在開始調(diào)用 Hy ASR 3.0 之前我們需要先明確接入的基本條件。通常來說大模型服務(wù)或者云平臺(tái)的 ASR 服務(wù)會(huì)要求你先具備三樣?xùn)|西賬號(hào)、API 密鑰、以及一個(gè)用于調(diào)試的測試音頻文件。關(guān)于賬號(hào)和密鑰不同階段的預(yù)覽計(jì)劃可能采用不同的申請方式有的需要內(nèi)測白名單有的通過控制臺(tái)開通服務(wù)后即可獲得。具體流程建議以官方文檔為準(zhǔn)這里提醒大家兩點(diǎn)一是不要把密鑰硬編碼到前端或代碼倉庫里建議放到環(huán)境變量或者配置中心二是申請服務(wù)后先查看免費(fèi)額度和并發(fā)限制避免在壓測時(shí)被限流誤判為故障。對于測試音頻建議準(zhǔn)備三類樣本一段安靜的普通話對話、一段帶背景噪聲的現(xiàn)場錄音、一段方言或者明顯口音的語音。這樣可以在接入的第一時(shí)間快速判斷模型是否滿足你的核心場景。3.2 音頻格式與基礎(chǔ)要求ASR 服務(wù)對音頻輸入通常有統(tǒng)一的規(guī)范這里給出常見的參考值。音頻格式方面wav、mp3、m4a、flac 基本都可以支持但如果對延遲和穩(wěn)定性要求高推薦使用 wav 或 pcm 原始音頻采樣率方面常見設(shè)置是 16000 Hz 單聲道電話錄音則通常使用 8000 Hz時(shí)長方面單次請求能處理的音頻長度取決于具體接口實(shí)時(shí)會(huì)議轉(zhuǎn)寫可能需要按流式方式持續(xù)發(fā)送數(shù)據(jù)。在工程上建議統(tǒng)一在調(diào)用前把音頻轉(zhuǎn)為標(biāo)準(zhǔn)格式這樣既能避免格式參數(shù)不匹配導(dǎo)致的報(bào)錯(cuò)也能讓整個(gè)處理鏈路更可控。轉(zhuǎn)換工具可以用 FFmpeg命令示例如下ffmpeg -i input.m4a -ac 1 -ar 16000 -f wav output.wav這條命令把任意輸入格式轉(zhuǎn)換為 16000 Hz 單聲道 wav。如果你先用了 44.1kHz 的立體聲音樂文件請先做好混音和重采樣否則識(shí)別效果會(huì)受到明顯影響。3.3 Python 環(huán)境準(zhǔn)備接下來的示例代碼使用 Python 3.8。建議在獨(dú)立虛擬環(huán)境中執(zhí)行下面的安裝命令python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install requests websocket-clientrequests 用于 HTTP 方式的文件轉(zhuǎn)寫調(diào)用。websocket-client 用于流式實(shí)時(shí)識(shí)別示例。如果你還需要處理音頻格式可以另外安裝 pydub但這不是必須的因?yàn)槲覀兛梢灾苯佑?FFmpeg 完成音頻轉(zhuǎn)換。4. 核心調(diào)用代碼與參數(shù)拆解4.1 HTTP 方式音頻文件一次轉(zhuǎn)寫對于已經(jīng)錄制完成的音頻文件最常見的調(diào)用方式是 HTTP POST。下面是示意圖代碼重點(diǎn)關(guān)注調(diào)用流程和參數(shù)組織方式實(shí)際的 endpoint、鑒權(quán)頭和請求結(jié)構(gòu)請以官方文檔為準(zhǔn)# -*- coding: utf-8 -*- Hy ASR 3.0 HTTP 文件轉(zhuǎn)寫示意代碼 import base64 import json import os import requests API_KEY os.environ.get(HY_ASR_API_KEY, ) # 占位地址請?zhí)鎿Q為官方提供的接口地址 ENDPOINT https://your-endpoint.example.com/asr/v3 def transcribe_file(file_path: str) - dict: 讀取音頻文件并請求 ASR 轉(zhuǎn)寫 with open(file_path, rb) as f: audio_bytes f.read() payload { audio: base64.b64encode(audio_bytes).decode(utf-8), config: { sample_rate: 16000, output_type: text, }, } headers { Content-Type: application/json, Authorization: fBearer {API_KEY}, } resp requests.post(ENDPOINT, jsonpayload, headersheaders, timeout60) resp.raise_for_status() return resp.json() if __name__ __main__: result transcribe_file(output.wav) print(json.dumps(result, ensure_asciiFalse, indent2))這段代碼做了三件事讀取音頻文件并進(jìn)行 Base64 編碼、在 config 中聲明采樣率、最后通過 POST 請求獲取轉(zhuǎn)寫結(jié)果。需要注意真實(shí)接口可能會(huì)對音頻大小有限制比如超過幾 MB 的文件要求先上傳或者使用異步任務(wù)接口。遇到這種情況就不宜用上面這種直傳方式而應(yīng)該根據(jù)文檔改用分段上傳、任務(wù)提交加輪詢結(jié)果的方式。4.2 WebSocket 方式流式實(shí)時(shí)識(shí)別如果你的場景需要實(shí)時(shí)轉(zhuǎn)寫比如會(huì)議實(shí)時(shí)字幕或者語音助手通常會(huì)用 WebSocket 建立長連接邊說話邊發(fā)送音頻片斷。下面給一個(gè)簡化的流式識(shí)別框架強(qiáng)調(diào)數(shù)據(jù)流組織思路# -*- coding: utf-8 -*- Hy ASR 3.0 流式識(shí)別示意代碼 import json import os import threading import time import websocket API_KEY os.environ.get(HY_ASR_API_KEY, ) WS_URL wss://your-endpoint.example.com/asr/v3/stream def on_message(ws, message): data json.loads(message) if result in data: print(識(shí)別結(jié)果:, data[result]) def on_error(ws, error): print(連接出錯(cuò):, error) def on_close(ws, status, reason): print(連接關(guān)閉:, status, reason) def on_open(ws): def send_audio(): # 這里演示從 pcm 文件分塊發(fā)送實(shí)際項(xiàng)目可替換為麥克風(fēng)數(shù)據(jù) with open(audio.pcm, rb) as f: while True: chunk f.read(3200) if not chunk: break ws.send_binary(chunk) time.sleep(0.1) ws.send(json.dumps({type: end}, ensure_asciiFalse)) threading.Thread(targetsend_audio, daemonTrue).start() if __name__ __main__: ws websocket.WebSocketApp( WS_URL, header{Authorization: fBearer {API_KEY}}, on_openon_open, on_messageon_message, on_erroron_error, on_closeon_close, ) ws.run_forever()需要說明的是3200 字節(jié)在 16kHz 采樣率、16bit 位深、單聲道條件下正好是 0.1 秒的音頻數(shù)據(jù)。代碼里 sleep 0.1 秒模擬實(shí)時(shí)發(fā)包。真實(shí)場景中麥克風(fēng)采集的音頻往往是按塊到達(dá)的我們需要做的是把采集到的數(shù)據(jù)盡快轉(zhuǎn)發(fā)給 WebSocket而不是在本地積累太多。流式識(shí)別比一次性請求復(fù)雜的地方在于音頻邊界如何處理、靜音檢測與話輪切分、中間結(jié)果的合并與去重、以及連接中斷后的重連策略。建議在實(shí)際項(xiàng)目中把這些邏輯單獨(dú)封裝成模塊避免在主流程里耦合大量狀態(tài)判斷。4.3 常見參數(shù)與配置項(xiàng)雖然不同版本的接口參數(shù)有差異但從語音識(shí)別項(xiàng)目的通用經(jīng)驗(yàn)來看下面這些配置項(xiàng)值得關(guān)注配置項(xiàng)作用建議采樣率告訴模型音頻的采樣規(guī)格電話場景 8000通用場景 16000聲道數(shù)涉及是否多聲道分離語音識(shí)別通常使用單聲道標(biāo)點(diǎn)預(yù)測是否自動(dòng)補(bǔ)充標(biāo)點(diǎn)會(huì)議轉(zhuǎn)寫建議開啟數(shù)字/日期格式化是否將數(shù)字轉(zhuǎn)為規(guī)范寫法客服質(zhì)檢場景建議開啟熱詞表提升專有名詞識(shí)別概率按業(yè)務(wù)動(dòng)態(tài)維護(hù)方言參數(shù)部分接口需要指定方言類別看官方支持列表是否返回時(shí)間戳用于對齊說話時(shí)間會(huì)議紀(jì)要場景需要這里需要提醒一下具體哪些參數(shù)存在、參數(shù)名如何拼寫、取值范圍是什么請以當(dāng)前版本的接口定義為準(zhǔn)。不要直接把其他平臺(tái)的參數(shù)照搬過來。5. 如何系統(tǒng)評估 ASR 效果5.1 核心指標(biāo)CER / WER評估 ASR 最常用的指標(biāo)是字錯(cuò)誤率 CER 和詞錯(cuò)誤率 WER。中文場景里由于分詞標(biāo)準(zhǔn)不統(tǒng)一大家更常用 CER即把識(shí)別文本與人工轉(zhuǎn)寫文本按“字”為單位對齊計(jì)算編輯距離占總字?jǐn)?shù)的比例。公式可以簡單寫成CER (替換錯(cuò)誤 插入錯(cuò)誤 刪除錯(cuò)誤) / 參考文本總字?jǐn)?shù)下面給一個(gè)純 Python 實(shí)現(xiàn)方便你在本地快速評估一批結(jié)果# -*- coding: utf-8 -*- 簡化版 CER 評估代碼 def edit_distance(a, b): m, n len(a), len(b) dp [[0] * (n 1) for _ in range(m 1)] for i in range(m 1): dp[i][0] i for j in range(n 1): dp[0][j] j for i in range(1, m 1): for j in range(1, n 1): if a[i - 1] b[j - 1]: dp[i][j] dp[i - 1][j - 1] else: dp[i][j] min(dp[i - 1][j - 1], dp[i - 1][j], dp[i][j - 1]) 1 return dp[m][n] def cer(reference: str, hypothesis: str) - float: ref_chars list(reference.replace( , )) hyp_chars list(hypothesis.replace( , )) return edit_distance(ref_chars, hyp_chars) / max(len(ref_chars), 1) if __name__ __main__: ref 今天下午三點(diǎn)召開項(xiàng)目評審會(huì) hyp 今天下午三點(diǎn)召開項(xiàng)目評審會(huì) print(CER:, cer(ref, hyp))這個(gè)實(shí)現(xiàn)是教學(xué)用途適合做小樣本快速評估。CER 越低越好0 表示完全正確。在正式評測時(shí)建議引入成熟工具庫進(jìn)行標(biāo)準(zhǔn)化計(jì)算尤其是包含英文和數(shù)字時(shí)需要考慮大小寫和格式規(guī)范化的問題。5.2 構(gòu)建分層評測集只給出一句語音的 CER 沒有統(tǒng)計(jì)學(xué)意義。更合理的方法是把測試集按業(yè)務(wù)特征分層每一層單獨(dú)統(tǒng)計(jì)。對中文 ASR 來說我通常會(huì)把評測集至少分為五類場景類型示例關(guān)注點(diǎn)普通話安靜場景辦公室單人朗讀基礎(chǔ)準(zhǔn)確率普通話噪聲場景街道采訪、車內(nèi)對話魯棒性電話信道客服錄音、VoIP 通話信道適配能力帶口音普通話四川、廣東口音普通話口音容錯(cuò)能力方言對話粵語、閩南語、上海話等方言覆蓋能力每一類建議至少準(zhǔn)備 100 條真實(shí)音頻并保證人工轉(zhuǎn)寫文本的質(zhì)量。如果預(yù)算有限也可以先用 30 條做快速篩選效果明顯差于預(yù)期的模型直接排除效果接近再擴(kuò)大樣本量做進(jìn)一步對比。5.3 除了準(zhǔn)確率還要看什么CER 是核心指標(biāo)但它不能反映全部問題。在工程落地時(shí)還需要關(guān)注識(shí)別結(jié)果是否帶標(biāo)點(diǎn)、時(shí)間戳精度、數(shù)字和英文是否被正確處理、語氣詞和重復(fù)詞會(huì)不會(huì)干擾后續(xù)語義分析、長音頻后半段的穩(wěn)定性是否下降。舉個(gè)例子做客服質(zhì)檢時(shí)即使整體 CER 能接受如果“退款 500 元”被識(shí)別成“退款 5000 元”就屬于嚴(yán)重業(yè)務(wù)錯(cuò)誤。這類問題建議單獨(dú)用關(guān)鍵詞糾錯(cuò)率來評估而不是只看平均 CER。簡單說評估指標(biāo)要根據(jù)業(yè)務(wù)風(fēng)險(xiǎn)來設(shè)計(jì)不能唯一個(gè)指標(biāo)論。6. 實(shí)戰(zhàn)中文會(huì)議錄音轉(zhuǎn)寫與質(zhì)量評估6.1 場景與需求假設(shè)我們有這樣一個(gè)小需求有一段 10 分鐘的中文會(huì)議錄音需要把語音轉(zhuǎn)成文字然后統(tǒng)計(jì)識(shí)別質(zhì)量。錄音格式是手機(jī)錄制的 m4a采樣率大概率是 44.1kHz聲道可能是雙聲道。這個(gè)案例很典型因?yàn)槭謾C(jī)錄音通常不是 ASR 服務(wù)最友好格式。我們的流程分成四步音頻格式統(tǒng)一、調(diào)用轉(zhuǎn)寫接口、保存識(shí)別結(jié)果、計(jì)算 CER 并與真實(shí)文本對比。6.2 完整處理流程首先用 FFmpeg 把 m4a 轉(zhuǎn)換成 16kHz 單聲道 wavffmpeg -i meeting.m4a -ac 1 -ar 16000 -f wav meeting.wav然后調(diào)用前面寫好的 transcribe_file 函數(shù)將識(shí)別結(jié)果保存為 JSONpython transcribe_demo.py假設(shè)參考文本是標(biāo)準(zhǔn)人工轉(zhuǎn)寫結(jié)果下面給出一個(gè)簡單的批量評估腳本# -*- coding: utf-8 -*- 批量 CER 評估腳本