目錄（18 節）
電話錄音轉文字：8 kHz 音質下，轉寫前要修嘅五件事
同一段對話，用電話系統錄同用會議室收音，轉寫出嚟可以差一個檔次。差距唔在引擎，在 300 至 3,400 Hz 呢條頻寬。
熱線錄音聽落好似幾清楚。同事戴住耳機聽，一字一句都聽到。
但同一個檔案餵去轉寫，出嚟嘅字會突然多咗錯：地址變咗另一個號碼，姓氏變成另一個姓，英文品牌名變成一串冇意思嘅音節。
原因唔係引擎水皮，而係你一直在聽一條只剩一半頻寬嘅錄音。
電話網絡由設計第一天起，就係為「聽得明人講嘢」而做，唔係為「機器讀得準」而做。呢個分別，決定咗電話錄音嘅錯誤分佈同會議錄音完全唔同。
重點摘要
- 傳統電話語音取樣率 8 kHz，理論上限 4 kHz；英文同粵語嘅 /s/、/f/ 等高頻子音主要能量在 4 kHz 以上，會被切走。
- 聲調資訊（F0 大約 100 至 250 Hz）反而完整保留，所以電話錄音嘅錯，多數錯在子音同近音字，唔係錯在聲調。
- 錄音係雙聲道（每邊一個 channel）嘅話，講者分離係零成本；混成單聲道之後，就要靠講者分辨，成本同錯誤一齊升。
- 等候音樂、IVR 提示、按鍵音（DTMF）要先切走，唔好當內容餵入引擎。
- 電話錄音嘅驗收唔應該只看字錯率，要看「關鍵欄位命中率」：訂單號、地址、金額、日期有冇錯。
- 8 kHz 升頻做 16 kHz 唔會多返任何資訊，只會令檔案大兩倍。
一句話答案
電話錄音唔係「唔可以轉」，係「要接受一個唔同嘅錯誤分佈」。修完之後，錯誤會集中在一小撮音，而集中就有得救：加詞表、加人工複核、加回讀確認，全部有效。
【獨家觀察】 大部分「引擎唔準」嘅投訴，追問落去第一句都係同一個答案：你餵咗咩音頻。電話錄音嘅問題，多數在檔案本身，唔在模型選擇。所以換引擎通常解決唔到，換錄音設定才解決得到。
電話頻寬到底少咗乜
傳統電話語音用 8 kHz 取樣、每個樣本 8 bit，對應 64 kbit/s 嘅通道（ITU-T G.711，1988 年版，2026-10-31 查閱）。8 kHz 取樣率，按取樣定理，可表達嘅最高頻率係 4 kHz。
實際通話頻帶更窄，大約 300 Hz 至 3,400 Hz。低過 300 Hz 嘅濁音基礎被削，高過 3,400 Hz 嘅全部消失。
呢件事有兩個後果。
好消息：粵語六個聲調靠基頻（F0）分辨，男性約 100 至 150 Hz，女性約 180 至 250 Hz，全部在保留範圍內。所以電話錄音唔會令「詩／史／試」變成同一個字。
壞消息：分辨近音字很大部分靠高頻子音。「三」同「生」、「四」同「死」，差距就在開頭嗰零點幾秒。頻寬一窄，這段就模糊。
所以電話錄音嘅典型錯誤長這樣：聲調對、韻母對、開頭子音錯。
五個轉寫前修正位
以下五個位按性價比排。頭兩個幾乎零成本，最後兩個要改錄音系統。
一、雙聲道一定要拆開
企業電話系統同雲端電話平台錄音，預設多數係雙聲道：客戶一條 channel，客服一條（Twilio Recordings 文件，2026-10-19 更新，2026-10-31 查閱）。
拆開之後，你根本唔需要做講者分辨 — 邊條 channel 講嘅話，就係邊個人講。
一旦混成單聲道，你就把「已知」變成「要估」。講者分辨在電話頻寬下特別易錯，尤其兩個人同時講嘅時候；一份針對雙人電話對話語料嘅實驗回顧，比較八種方法後指出重疊語音、長對話同資料量不足都會令表現下滑（arXiv 2305.18074，2023 年，2026-10-31 查閱）。方法同限制見講者分辨實務。
實際做法：保留原始雙聲道檔，轉寫時分兩次送，或者用平台支援嘅 channel 參數。唔好先混音再上載。
二、切走等候音樂同提示音
等候音樂係通話被保留時播放、唔屬於任何一方發言嘅音頻。它係轉寫最常見嘅假陽性來源：引擎被要求講出「呢段音頻講咗咩」，音樂就變成一段冇人講過嘅句子。
同樣問題出現在：
- IVR 選單 — 通常要保留，但要同真人對話分開處理。
- 按鍵音（DTMF）— 唔應該出現在逐字稿。
- 轉接同錄音提示音 — 保留與否係政策問題，唔係技術問題。
做法係用能量同頻譜特徵先做一次分段，把「似音樂」「似單音」嘅段標走，再只送人聲段落。呢一步用現成工具已經做得到，唔需要自己寫。
三、響度統一，但唔好壓爆
同一通電話，客戶可能在港鐵站講，也可能在安靜辦公室講；客服戴耳機音量穩定，客戶用免提就忽大忽小。差距太大時，細聲部分會被當成靜音或者被雜訊蓋過。
響度正規化係指把整段音頻嘅平均音量推到同一目標水平。做法係做一次正規化，但唔好重手壓縮：壓縮會把子音同背景雜訊一齊推大，反而更差。例如客戶在巴士上講「三」同「生」，本來只差開頭子音，壓縮之後更難分。
四、靜音要剪，但要留邊
長停頓會浪費計費時間，亦會令部分引擎在長靜音後「斷片」。
但剪得太貼，會切走字頭。粵語入聲字（-p、-t、-k）收尾極短，開頭嘅爆破音亦只有幾十毫秒。
做法：剪靜音時前後各留 150 至 250 毫秒緩衝。呢個數字唔係定律，係一個安全起始值，你用自己嘅錄音試兩三個設定就知。
五、採樣率：唔好假裝升級
很多轉寫服務接受 8 kHz 或 16 kHz 輸入。例如 Azure 語音 SDK 嘅串流輸入，明確支援 8,000 或 16,000 samples per second、16 bit、單聲道（官方文件，2026-06-05 更新，2026-10-31 查閱）。
但 8 kHz 升頻到 16 kHz，只係在原有樣本之間插值。4 kHz 以上本來就冇資訊，插值唔會無中生有。
升頻唯一好處係符合某些服務嘅硬性格式要求。唔係提升準確度嘅手段。
真正影响準確度嘅係編碼。電話系統常用嘅壓縮編碼係有損嘅，解碼之後高頻已經冇咗，再轉格式都補唔返。
轉寫時要改嘅三個設定
修好音頻之後，設定仲有三個位。
第一，唔好在短句上開自動語言偵測。 電話錄音多數係短句、夾雜英文品牌名，幾秒音頻上判斷語言會前後不一致。直接指定粵語。
第二，詞表要放真正會出現嘅專名。 客戶姓名、屋苑名、產品代號、分店編號。呢類詞在電話頻寬下最易錯，而詞表正好補這類錯。我們嘅詞表上限係 50 詞、每詞 30 字元 — 所以要先揀，唔好把所有客戶名都倒進去。規則細節見詞表跨平台對照。
第三，決定要唔要時間戳。 質檢用途通常要「邊分鐘講咗乜」，方便主管跳去聽。但如果服務只回純文字，你就要另外做對齊，成本要計入。輸出格式嘅取捨，見逐字稿交付格式。
驗收：唔好只計字錯率
電話錄音嘅字錯率一定會比會議錄音差，呢個係物理限制，唔係邊個引擎唔得。
呢點有公開數據支持：同一套英語電話對話系統，在 Switchboard 語料嘅字錯率係 5.5%，在 CallHome 語料係 10.3%（arXiv 1703.02136，2017 年，2026-10-31 查閱）。兩個都係電話語音，但後者更接近真實長途通話 — 收音更差、語速更快、背景更雜。同一模型，差距接近兩倍。
所以驗收要換指標。關鍵欄位命中率係指「真正影響業務嘅欄位有幾多條完全正確」，例如訂單號、地址、金額，而唔係全篇字數嘅平均。我們建議三層：
| 層次 | 計咩 | 合格線怎麼定 |
|---|---|---|
| 關鍵欄位 | 訂單號、電話、地址、金額、日期有冇錯 | 逐欄計命中率；數字類要求 100%，錯一個就計錯 |
| 專名 | 人名、公司名、屋苑名、產品名 | 用你真實客戶名單抽樣；錯就入詞表再測 |
| 整體可讀 | 一段話讀完知唔知講咩 | 兩人各自讀，標記「要重聽」嘅段落比例 |
抽樣唔好只用靚錄音。按三個維度分層：通話長度（短／中／長）、時段（繁忙／非繁忙）、客戶類型（新客／舊客／投訴）。
每層至少 10 通，總數 30 通以上，才勉強夠看趨勢。呢個規模同準確度測試方法一致：寧願樣本少但分層清楚，唔好隨機抽 200 通全部同一類。
【獨家分析】 最誤導嘅驗收報告係一個漂亮嘅總分：「整體準確度 94%」。拆開之後，訂單號命中率可能只有七成，其餘三成錯一個位。總分睇落靚，正因為短句、招呼、應對佔咗大部分字數，而真正要核對嘅欄位只佔幾個字。用平均數掩蓋關鍵少數，係質檢最常見嘅陷阱。
咩情況下唔應該用轉寫
三種情況，老實講，轉寫幫唔到你。
兩個人在大半段時間同時講。 重疊發言在單聲道下係無解的，任何引擎都只能選擇其中一把聲。
錄音本身爆音。 如果客戶在嘈雜環境用免提，音量已經頂到上限，訊息已經冇咗，後處理補唔返。
需要逐字引述作法律用途。 這種情況要可核對嘅人工謄寫、時間碼同覆核人簽名。機器轉寫可以做初稿，但唔應該當最終版本。要求見錄音轉逐字稿實務。
合規：錄音本身先要合法
技術上修得好，唔代表可以錄。同意、告知、保留期係另一個問題，唔係調參數解決得到。
通話錄音交外部處理，重點會轉去合約：資料去邊、保留幾久、誰可以查閱。見轉寫委外合約同查閱流程。
常見問題
電話錄音一定要轉成 16 kHz 才準？
唔係。8 kHz 原生輸入已經包含全部可用資訊。轉 16 kHz 只係格式符合，唔會提升準確度。相反，反覆轉檔會累積壓縮損失。
單聲道錄音可以補救嗎？
可以做講者分辨，但唔可以「補回」被混掉嘅資訊。如果兩個人同時講，任何方法都只能盡量估。最實際嘅補救係改錄音設定，而唔係改轉寫流程。
一小時熱線錄音，轉寫要幾久？
取決於走同步定非同步。我們嘅同步路線上限 8 分鐘、請求體 4.5 MB；長通話要走去非同步，上限 200 MB／4 小時。斷點處理見長會議錄音轉寫流程。
質檢要 100% 全量轉寫，成本怎麼算？
按音頻秒計，我們檔案轉寫係 HK$0.80／小時。一條 6 分鐘通話大約 HK$0.08。全量转寫嘅成本通常遠低於抽樣人工聽錄音，但仍然要計「失敗重跑」同「人工複核」兩項，唔好只乘單價。
關於呢篇文
本文由港嘢內容團隊整理；關於港嘢嘅粵語語音工作，見關於港嘢。頻寬同取樣率依據 ITU-T G.711，串流格式依據 Azure 語音 SDK 文件，雙聲道設計依據 Twilio Recordings 文件，講者分辨同字錯率落差引用兩篇公開論文。外部連結查閱日期 2026-10-31。產品限制取自 API 文件。發現錯漏，歡迎聯絡我們。
資料來源：ITU-T G.711（1988 年版）；Microsoft Learn「Speech SDK audio input stream concepts」（2026-06-05 更新）；Twilio「Recordings resource」（2026-10-19 更新）；arXiv 2305.18074（2023）、1703.02136（2017）；港嘢 /v1/docs（同步 8 分鐘、4.5 MB、200 MB／4 小時、50 詞、HK$0.80／小時）。