1. 中文語音轉(zhuǎn)文本的核心價值與場景拆解中文語音轉(zhuǎn)文本這件事表面上看就是把一段錄音變成文字但真正動過手的人都知道這里面的水比想象中深得多。我最早接觸這個需求是在三年前當(dāng)時幫一個做在線教育的小團隊處理課程錄音他們每周產(chǎn)出幾十個小時的講課音頻想轉(zhuǎn)成文字做課程筆記和字幕。一開始覺得找個工具跑一下就行結(jié)果試了七八個方案要么識別率慘不忍睹要么時間軸對不上要么遇到中英混說的段落直接崩掉。后來花了將近兩個月時間把主流方案從架構(gòu)到參數(shù)全部摸了一遍才算真正把這件事跑通。中文語音轉(zhuǎn)文本英文叫 Speech-to-Text 或者 Automatic Speech RecognitionASR核心目標(biāo)是把連續(xù)的語音信號轉(zhuǎn)換成對應(yīng)的文字序列。它解決的問題很明確人說話的速度大概是每分鐘 150 到 200 個字而打字速度平均只有每分鐘 40 到 60 個字中間有三到四倍的效率差。對于需要大量文字產(chǎn)出的場景——比如會議記錄、采訪整理、課程字幕、播客轉(zhuǎn)寫、客服質(zhì)檢——這個效率差就是實打?qū)嵉臅r間成本。適合參考這套內(nèi)容的人大概分三類。第一類是開發(fā)者需要把語音轉(zhuǎn)文本能力集成到自己的產(chǎn)品里關(guān)心的是接口怎么調(diào)、模型怎么選、延遲和準確率怎么平衡。第二類是內(nèi)容創(chuàng)作者和運營人員不需要寫代碼但需要一套穩(wěn)定可靠的轉(zhuǎn)寫流程來處理日常素材。第三類是對技術(shù)感興趣的學(xué)習(xí)者想搞清楚中文語音識別到底是怎么工作的為什么有時候準有時候不準。不管你是哪一類下面這些從實際項目里摔打出來的經(jīng)驗應(yīng)該都能幫你少走一些彎路。2. 技術(shù)路線選型從云端API到本地部署的完整對比2.1 三種主流方案的本質(zhì)區(qū)別中文語音轉(zhuǎn)文本目前主要有三條技術(shù)路線每條路線的適用場景和成本結(jié)構(gòu)完全不同選錯了后面全是坑。第一條是云端API方案。代表產(chǎn)品包括國內(nèi)幾家大廠提供的語音識別服務(wù)以及一些專注語音領(lǐng)域的垂直廠商。你只需要把音頻文件傳上去或者推流過去對方返回識別結(jié)果。優(yōu)點是接入快、準確率高、維護成本低缺點是按量計費、有網(wǎng)絡(luò)依賴、數(shù)據(jù)要出本地。我實測下來短音頻5分鐘以內(nèi)的識別準確率普遍能到 95% 以上長音頻會有所下降。第二條是本地開源模型方案。以 Whisper 系列為代表包括各種社區(qū)微調(diào)版本。你需要自己準備算力模型跑在本地。優(yōu)點是數(shù)據(jù)不出本地、沒有調(diào)用費用、可以離線運行缺點是部署有門檻、推理速度取決于硬件、中文識別效果需要針對場景調(diào)優(yōu)。我拿一段 30 分鐘的會議錄音做過測試在帶獨立顯卡的機器上中等規(guī)模模型大概需要 3 到 5 分鐘完成轉(zhuǎn)寫準確率在 90% 到 94% 之間浮動。第三條是混合方案。用本地模型做初步轉(zhuǎn)寫再用云端API做校對和補充或者反過來。這種方案適合對準確率要求極高、同時又有數(shù)據(jù)隱私顧慮的場景。實際操作中我會用本地模型跑第一遍把置信度低的片段標(biāo)記出來再針對這些片段調(diào)用云端接口做二次識別。2.2 選型決策的關(guān)鍵參數(shù)選型的時候不能只看準確率一個指標(biāo)下面這幾個參數(shù)必須一起考慮。評估維度云端API本地開源模型混合方案首次接入時間1到2小時1到3天3到5天中文準確率95%到98%90%到95%96%到98%單小時音頻成本1到5元電費硬件折舊0.5到3元數(shù)據(jù)隱私需上傳完全本地部分上傳離線可用否是部分長音頻支持通常有上限取決于顯存靈活專業(yè)術(shù)語識別需定制可微調(diào)可微調(diào)這個表里的數(shù)據(jù)是我在多個項目中反復(fù)驗證過的平均值具體數(shù)字會因音頻質(zhì)量、說話人口音、背景噪聲等因素有較大波動。選型的時候我一般建議先問三個問題數(shù)據(jù)能不能出本地預(yù)算結(jié)構(gòu)是固定成本還是變動成本對延遲的容忍度是多少這三個問題的答案基本就能鎖定方案。2.3 為什么中文識別比英文更難很多人覺得中文語音識別應(yīng)該比英文簡單因為中文沒有復(fù)雜的詞形變化。實際情況恰恰相反中文語音轉(zhuǎn)文本有幾個特有的難點。首先是同音字問題。中文里同音字和同音詞的比例遠高于英文一個讀音可能對應(yīng)幾十個不同的字。比如“shi”這個音可以對應(yīng)“是、事、時、使、市、式、試、視、示、士”等等。模型必須依賴上下文才能判斷到底該用哪個字。英文雖然也有同音詞但比例低得多而且拼寫差異大更容易區(qū)分。其次是分詞和斷句。中文書寫沒有空格一句話里詞和詞的邊界是模糊的。語音識別輸出的文字需要經(jīng)過分詞處理才能用于后續(xù)的搜索、分析等任務(wù)。而分詞本身就是一個有歧義的問題不同分詞標(biāo)準會得到不同結(jié)果。第三是口音和方言的影響。中文的口音差異非常大同一個詞在不同地區(qū)的發(fā)音可能完全不同。雖然普通話有標(biāo)準發(fā)音但實際說話中很少有人完全標(biāo)準。模型訓(xùn)練時如果口音覆蓋不夠遇到帶口音的音頻就會頻繁出錯。第四是中英混說。這在技術(shù)類、商務(wù)類音頻里特別常見。一句話里夾雜幾個英文單詞模型需要在兩種語言之間無縫切換。我處理過一段產(chǎn)品經(jīng)理的會議錄音里面“這個 feature 的 priority 要重新 align 一下”這種句子比比皆是純中文模型和純英文模型都處理不好。3. 實操環(huán)境搭建與核心工具鏈配置3.1 音頻預(yù)處理被大多數(shù)人忽略的關(guān)鍵步驟在把音頻送進識別引擎之前預(yù)處理做得好不好直接決定最終準確率的上限。我見過太多人拿著手機錄的嘈雜音頻直接往模型里扔然后抱怨識別率低。其實很多問題在預(yù)處理階段就能解決。采樣率統(tǒng)一是第一步。大多數(shù)語音識別模型期望的輸入采樣率是 16000Hz。如果你手頭的音頻是 44100Hz 或 48000Hz需要先做重采樣。用 ffmpeg 一行命令就能搞定ffmpeg -i input.mp3 -ar 16000 -ac 1 -c:a pcm_s16le output.wav這條命令做了三件事把采樣率轉(zhuǎn)成 16000Hz把聲道數(shù)轉(zhuǎn)成單聲道把編碼格式轉(zhuǎn)成 16位 PCM。這三個參數(shù)是絕大多數(shù)語音識別模型的標(biāo)準輸入格式。降噪處理是第二步。如果音頻有明顯的背景噪聲空調(diào)聲、鍵盤聲、風(fēng)扇聲可以用譜減法或者基于深度學(xué)習(xí)的降噪工具先處理一遍。我常用的是一個叫 noisereduce 的 Python 庫用法很簡單import noisereduce as nr import soundfile as sf data, rate sf.read(input.wav) reduced_noise nr.reduce_noise(ydata, srrate) sf.write(output_denoised.wav, reduced_noise, rate)實測下來對于穩(wěn)態(tài)噪聲比如空調(diào)聲降噪能把識別準確率提升 3 到 5 個百分點。但對于非穩(wěn)態(tài)噪聲比如突然的咳嗽聲、關(guān)門聲降噪效果有限有時候反而會引入失真這種情況需要手動裁剪掉噪聲片段。音量歸一化是第三步。錄音音量太小會導(dǎo)致模型聽不清音量太大又會產(chǎn)生削波失真。用 ffmpeg 的 loudnorm 濾鏡可以做標(biāo)準化ffmpeg -i input.wav -af loudnormI-16:TP-1.5:LRA11 -ar 16000 output_normalized.wav這里的參數(shù)含義是目標(biāo)響度 -16 LUFS最大真峰值 -1.5 dBTP響度范圍 11 LU。這套參數(shù)是我在多個項目中驗證過的對語音識別比較友好。靜音切除是第四步。長音頻里往往有大量靜音段這些段落不僅浪費計算資源還可能影響模型對上下文的理解?？梢杂?ffmpeg 的 silenceremove 濾鏡ffmpeg -i input.wav -af silenceremovestart_periods1:start_duration0.5:start_threshold-40dB:stop_periods-1:stop_duration0.5:stop_threshold-40dB output_trimmed.wav注意靜音切除的閾值不要設(shè)得太激進-40dB 是一個比較安全的起點。如果設(shè)到 -30dB可能會把說話人換氣的聲音也切掉導(dǎo)致語句不連貫。3.2 本地模型部署從零跑通 Whisper 系列如果你選擇本地部署路線Whisper 系列是目前中文支持最好的開源選擇之一。下面是我在實際項目中總結(jié)的部署流程。硬件要求方面如果只是偶爾轉(zhuǎn)寫短音頻CPU 也能跑但速度很慢。一段 10 分鐘的音頻在普通筆記本 CPU 上可能需要 15 到 20 分鐘。如果有獨立顯卡速度會快很多。顯存方面中等規(guī)模模型大概需要 4 到 6GB 顯存大規(guī)模模型需要 10GB 以上。如果顯存不夠可以用量化版本代價是準確率會下降 1 到 2 個百分點。環(huán)境安裝用 pip 就能完成pip install openai-whisper pip install torch torchaudio如果需要 GPU 加速要確保 torch 的 CUDA 版本和顯卡驅(qū)動匹配。這一步經(jīng)常出問題建議先用torch.cuda.is_available()確認 GPU 是否可用?；A(chǔ)轉(zhuǎn)寫腳本大概長這樣import whisper model whisper.load_model(medium) result model.transcribe( audio.wav, languagezh, tasktranscribe, initial_prompt以下是普通話的句子。, temperature0.0, compression_ratio_threshold2.4, logprob_threshold-1.0, no_speech_threshold0.6 ) for segment in result[segments]: print(f[{segment[start]:.2f} - {segment[end]:.2f}] {segment[text]})這里有幾個參數(shù)值得展開說。initial_prompt是給模型的提示詞告訴它這是普通話內(nèi)容能顯著提升中文識別的穩(wěn)定性。temperature0.0表示用確定性解碼避免模型隨機發(fā)揮。后面三個閾值參數(shù)控制的是什么情況下模型認為“這段沒有語音”或者“這段識別結(jié)果不可靠”需要根據(jù)實際音頻質(zhì)量調(diào)整。模型規(guī)模選擇上我一般這樣建議tiny 和 base 適合快速預(yù)覽準確率勉強能用small 是速度和準確率的平衡點medium 是我最常用的中文準確率明顯好于 smalllarge 適合對準確率要求極高的場景但速度慢很多。如果音頻里有大量專業(yè)術(shù)語large 的優(yōu)勢會更明顯。3.3 云端API接入以通用流程為例云端API的接入流程各家大同小異核心步驟都是注冊賬號、獲取密鑰、構(gòu)造請求、處理響應(yīng)。下面是一個通用的調(diào)用示例import requests import json import base64 def speech_to_text(audio_path, api_key, api_url): with open(audio_path, rb) as f: audio_data base64.b64encode(f.read()).decode(utf-8) headers { Content-Type: application/json, Authorization: fBearer {api_key} } payload { audio: audio_data, format: wav, sample_rate: 16000, language: zh-CN, enable_punctuation: True, enable_itn: True } response requests.post(api_url, headersheaders, jsonpayload) result response.json() return result.get(text, )這里的enable_punctuation控制是否自動加標(biāo)點enable_itn控制是否做逆文本歸一化把“一百二十三”轉(zhuǎn)成“123”。這兩個參數(shù)對最終輸出的可讀性影響很大建議都打開。提示云端API通常對單次請求的音頻時長有限制常見的是 60 秒或 5 分鐘。處理長音頻時需要先做切分切分點最好選在靜音段避免把一句話切成兩半。4. 識別準確率優(yōu)化的實戰(zhàn)技巧4.1 熱詞與自定義詞表通用模型對專業(yè)術(shù)語、人名、產(chǎn)品名的識別往往不準。比如“卷積神經(jīng)網(wǎng)絡(luò)”可能被識別成“卷機神經(jīng)網(wǎng)絡(luò)”“Transformer”可能被識別成“傳絲佛魔”。解決這個問題最直接的辦法是使用熱詞功能。大多數(shù)云端API都支持傳入熱詞列表格式通常是“詞語權(quán)重”。權(quán)重越高模型越傾向于輸出這個詞。我一般會把項目相關(guān)的專業(yè)術(shù)語、產(chǎn)品名、人名整理成一個列表權(quán)重設(shè)置在 5 到 10 之間。權(quán)重太高會導(dǎo)致模型過度偏向熱詞把發(fā)音相近的普通詞也強行替換成熱詞反而降低準確率。本地模型的話可以通過initial_prompt參數(shù)傳入熱詞。比如initial_prompt 以下是關(guān)于機器學(xué)習(xí)的討論涉及卷積神經(jīng)網(wǎng)絡(luò)、Transformer、注意力機制、梯度下降等術(shù)語。這個提示詞會在解碼時給模型一個上下文偏向讓它在遇到相似發(fā)音時更傾向于輸出這些術(shù)語。實測下來對專業(yè)術(shù)語的識別準確率能提升 10 到 20 個百分點。4.2 標(biāo)點與斷句的后處理語音識別模型輸出的原始文本往往沒有標(biāo)點或者標(biāo)點位置不準。后處理階段可以用規(guī)則模型的方式做修正。規(guī)則方面可以根據(jù)停頓時間來判斷。如果兩個詞之間的靜音超過 0.5 秒大概率是一個句子的邊界可以插入句號或逗號。如果靜音超過 1.5 秒可能是段落邊界。模型方面可以用一個專門的中文標(biāo)點恢復(fù)模型來處理。這類模型通?；?BERT 架構(gòu)輸入無標(biāo)點文本輸出帶標(biāo)點的文本。我試過幾個開源方案效果最好的是在新聞?wù)Z料上微調(diào)過的版本對正式文本的標(biāo)點恢復(fù)準確率能到 85% 以上。但對于口語化內(nèi)容比如“然后那個就是說”標(biāo)點恢復(fù)的效果會差一些因為口語本身就沒有嚴格的標(biāo)點規(guī)則。4.3 時間軸對齊與字幕生成如果你需要生成字幕文件SRT 或 VTT 格式時間軸的準確性就很重要了。Whisper 輸出的 segments 自帶時間戳但粒度比較粗有時候一個 segment 包含好幾句話?？梢杂?forced alignment 工具做更精細的對齊。我常用的是一個叫 stable-ts 的庫它在 Whisper 基礎(chǔ)上做了時間軸優(yōu)化import stable_whisper model stable_whisper.load_model(medium) result model.transcribe(audio.wav, languagezh) result.to_srt_vtt(output.srt, word_levelTrue)word_levelTrue會輸出詞級別的時間戳生成的字幕更精確。不過詞級別對齊會稍微增加處理時間大概多 20% 到 30%。注意生成字幕后一定要人工過一遍。模型的時間軸偶爾會出現(xiàn)重疊或跳躍比如上一句還沒結(jié)束下一句就開始了或者中間突然空了 10 秒。這些問題在自動生成階段很難完全避免人工校對是最后一道防線。5. 常見問題排查與避坑指南5.1 識別結(jié)果亂碼或重復(fù)這是最常見的問題之一。表現(xiàn)是輸出的文字里出現(xiàn)大量重復(fù)的短語或者完全無關(guān)的字符。原因通常有三個音頻質(zhì)量太差、模型參數(shù)設(shè)置不當(dāng)、音頻格式不兼容。排查步驟是這樣的先檢查音頻能不能正常播放如果播放都有問題那識別肯定好不了。然后用音頻編輯軟件看一下波形確認沒有嚴重的削波或噪聲。如果音頻沒問題再檢查模型參數(shù)。Whisper 的compression_ratio_threshold參數(shù)控制的就是重復(fù)檢測默認值是 2.4如果經(jīng)常出現(xiàn)重復(fù)可以調(diào)低到 2.0 試試。另外temperature設(shè)成 0 可以減少隨機性但有時候適當(dāng)提高溫度比如 0.2反而能打破重復(fù)循環(huán)。5.2 長音頻處理超時或內(nèi)存溢出處理超過 30 分鐘的音頻時很容易遇到內(nèi)存不夠或者處理超時的問題。解決方案是分而治之先把長音頻切成 5 到 10 分鐘的片段分別識別最后再拼接結(jié)果。切分的時候要注意不能隨便按時間切否則會把一句話切成兩半。正確做法是先檢測靜音段在靜音段中間切?？梢杂?pydub 庫來實現(xiàn)from pydub import AudioSegment from pydub.silence import split_on_silence audio AudioSegment.from_wav(long_audio.wav) chunks split_on_silence( audio, min_silence_len500, silence_thresh-40, keep_silence200 ) for i, chunk in enumerate(chunks): chunk.export(fchunk_{i}.wav, formatwav)min_silence_len500表示靜音超過 500 毫秒才認為是切分點silence_thresh-40是靜音閾值keep_silence200表示切分后每段保留 200 毫秒的靜音避免切得太生硬。5.3 中英混說識別效果差中英混說是中文語音識別的一個老大難問題。純中文模型會把英文單詞強行識別成發(fā)音相近的中文純英文模型則會把中文部分識別成亂碼。解決方案有幾個。如果用的是云端API看看有沒有專門的中英混說模型或者語言自適應(yīng)功能。如果用的是本地模型可以在initial_prompt里明確說明“以下內(nèi)容包含中英文混合”給模型一個預(yù)期。另外Whisper 的 large 模型在中英混說上的表現(xiàn)明顯好于 smaller 模型如果這個場景是剛需建議直接上 large。還有一個取巧的辦法先用語言檢測工具判斷每個片段的語言然后分別用對應(yīng)的模型識別最后合并。但這個方案實現(xiàn)復(fù)雜而且語言切換點很難精確檢測實際效果不一定比直接用 large 模型好。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案輸出大量重復(fù)文字解碼參數(shù)不當(dāng)檢查 compression_ratio調(diào)低閾值調(diào)整 temperature識別結(jié)果為空音頻格式不對用播放器驗證轉(zhuǎn)成 16kHz 單聲道 WAV專業(yè)術(shù)語識別錯缺少熱詞對比原文和輸出添加熱詞或 initial_prompt處理速度極慢硬件不足查看 CPU/GPU 占用換小模型或啟用 GPU時間軸錯亂對齊粒度粗檢查 SRT 文件用詞級別對齊工具中英混說出錯模型語言限制分段測試換 large 模型或混合方案標(biāo)點缺失未開啟標(biāo)點功能檢查 API 參數(shù)開啟標(biāo)點或后處理6. 從轉(zhuǎn)寫到應(yīng)用下游任務(wù)的銜接6.1 文本后處理與格式化語音轉(zhuǎn)文本的輸出只是原材料要真正可用還需要后處理。最基本的后處理包括去除多余空格、統(tǒng)一標(biāo)點符號、修正明顯的識別錯誤、分段和加標(biāo)題。我一般會寫一個簡單的規(guī)則引擎來處理這些。比如把連續(xù)的多個句號合并成一個把英文標(biāo)點轉(zhuǎn)成中文標(biāo)點把“嗯”“啊”這類填充詞根據(jù)場景決定是否保留。如果是會議記錄填充詞可以去掉如果是采訪整理填充詞可能包含說話人的情緒信息需要保留。6.2 說話人分離多人對話場景下光有文字還不夠還需要知道每句話是誰說的。說話人分離Speaker Diarization是另一個技術(shù)模塊可以和語音識別配合使用。開源方案里pyannote-audio 是比較成熟的選擇?；玖鞒淌窍茸稣Z音活動檢測找出有語音的片段然后提取每個片段的聲紋特征最后做聚類把相同說話人的片段歸為一組。輸出結(jié)果是每個時間段對應(yīng)的說話人標(biāo)簽再和識別文本按時間軸合并就能得到帶說話人標(biāo)記的對話記錄。實際操作中說話人分離的準確率受錄音質(zhì)量影響很大。如果是單人麥克風(fēng)錄音不同人聲音差異明顯準確率能到 90% 以上。如果是遠場錄音或者多人同時說話準確率會大幅下降。我一般建議在錄音階段就盡量保證每個人用獨立麥克風(fēng)后期處理會省很多事。6.3 關(guān)鍵詞提取與摘要生成轉(zhuǎn)寫文本的另一個常見需求是提取關(guān)鍵詞和生成摘要。關(guān)鍵詞提取可以用 TF-IDF 或者 TextRank 算法也可以直接用大語言模型來做。摘要生成目前效果最好的是用大語言模型把轉(zhuǎn)寫文本按長度切分后分段摘要再合并成總摘要。這里有一個經(jīng)驗語音轉(zhuǎn)文本的輸出往往比書面文本更啰嗦重復(fù)內(nèi)容更多。直接拿去做摘要模型可能會被冗余信息干擾。我通常會在摘要之前先做一輪文本壓縮把明顯重復(fù)的句子去掉把口語化的表達轉(zhuǎn)成書面表達這樣摘要質(zhì)量會好很多。7. 成本控制與性能優(yōu)化的平衡7.1 云端API的成本優(yōu)化云端API按量計費用量大的時候成本很可觀。幾個優(yōu)化方向一是音頻預(yù)處理階段盡量切除靜音段減少實際需要識別的時長二是根據(jù)場景選擇不同的模型檔次比如內(nèi)部會議記錄可以用標(biāo)準版對外發(fā)布的字幕用高精度版三是利用各家提供的免費額度或包年套餐。我算過一筆賬一個每天產(chǎn)生 10 小時音頻的團隊如果用高精度API每月成本大概在 1500 到 3000 元之間。如果先做靜音切除通常能減少 20% 到 30% 的時長再根據(jù)內(nèi)容重要性分級處理成本能壓到 800 到 1500 元。7.2 本地部署的硬件選型本地部署的成本主要是硬件。如果只是偶爾用用現(xiàn)有電腦就行。如果需要批量處理建議配一臺帶獨立顯卡的機器。顯卡選擇上顯存比算力更重要因為顯存決定了能跑多大的模型。8GB 顯存能跑 medium 模型12GB 以上能跑 large 模型。如果不想買硬件也可以考慮按小時租用云端 GPU 實例。這種方式適合處理量波動大的場景用的時候開不用的時候關(guān)成本比長期持有硬件低。7.3 批量處理的流水線設(shè)計當(dāng)需要處理大量音頻時設(shè)計一個高效的流水線很重要。我的做法是把整個流程拆成獨立的步驟音頻預(yù)處理、識別、后處理、格式轉(zhuǎn)換。每個步驟之間用文件或者消息隊列傳遞數(shù)據(jù)。這樣做的好處是每個步驟可以獨立優(yōu)化和擴展比如識別步驟可以并行跑多個任務(wù)預(yù)處理步驟可以單獨調(diào)參。流水線工具方面簡單的用 shell 腳本就能搞定復(fù)雜的可以用 Airflow 或者 Prefect 這類工作流引擎。我個人的經(jīng)驗是如果每天處理的音頻不超過 100 小時shell 腳本加一個任務(wù)隊列就夠了沒必要上太重型的工具。8. 我踩過的那些坑說幾個印象深刻的教訓(xùn)。第一個是關(guān)于音頻格式的。有一次客戶給了一批 .m4a 格式的錄音我直接扔進模型結(jié)果識別出來全是亂碼。查了半天才發(fā)現(xiàn)是采樣率的問題m4a 默認是 44100Hz模型期望的是 16000Hz。轉(zhuǎn)格式之后問題解決。這件事之后我養(yǎng)成了一個習(xí)慣不管什么格式的音頻先統(tǒng)一轉(zhuǎn)成 16kHz 單聲道 WAV再進識別流程。第二個是關(guān)于熱詞權(quán)重的。有一次為了提升產(chǎn)品名識別率我把熱詞權(quán)重設(shè)到了 20結(jié)果模型把所有發(fā)音相近的詞都替換成了產(chǎn)品名正常對話被改得面目全非。后來把權(quán)重降到 8效果就正常了。熱詞權(quán)重這個東西不是越高越好找到平衡點很重要。第三個是關(guān)于長音頻切分的。早期我按固定時長切分每 5 分鐘切一刀。結(jié)果經(jīng)常出現(xiàn)一句話被切成兩半的情況前半句在上一段后半句在下一段拼接后語義完全變了。后來改成按靜音段切分問題就解決了。雖然實現(xiàn)起來麻煩一點但值得。第四個是關(guān)于模型選擇的。有一段時間我迷信大模型什么音頻都用 large 跑。后來發(fā)現(xiàn)對于清晰的單人錄音medium 和 large 的準確率差距不到 1 個百分點但速度差了一倍多?，F(xiàn)在我的策略是先快速跑一遍 small 模型看看整體質(zhì)量如果質(zhì)量好就直接用如果質(zhì)量差再上 large。最后一個坑是關(guān)于標(biāo)點恢復(fù)的。我一開始用規(guī)則做標(biāo)點根據(jù)停頓時間加逗號句號。結(jié)果發(fā)現(xiàn)說話人停頓的地方不一定需要標(biāo)點有時候停頓只是思考不是句子邊界。后來改用模型做標(biāo)點恢復(fù)效果好很多。但模型也有模型的問題遇到口語化嚴重的音頻標(biāo)點恢復(fù)會過度糾正把口語的節(jié)奏感破壞了。所以現(xiàn)在我的做法是正式內(nèi)容用模型標(biāo)點口語內(nèi)容保留原始停頓只做最基本的斷句。這些經(jīng)驗說到底就是一句話語音轉(zhuǎn)文本沒有銀彈每個場景都需要針對性地調(diào)優(yōu)。通用方案能解決 80% 的問題剩下的 20% 才是真正體現(xiàn)功力的地方。