https://yennj12.js.org/yennj12_blog_V4/tags/speech/Recent content in Speech on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part1-asr-zh/Sun, 21 Jun 2026 14:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part1-asr-zh/大多數人以為語音辨識就是「把錄音丟給 API 拿文字」。 但真正的工程挑戰是：如何在 300ms 內完成辨識、處理口音與噪音、控制串流延遲？ 不懂聲學特徵與解碼策略，你只是在呼叫別人的黑盒子。 理解 ASR 架構，才能在延遲、準確率、成本之間做出有根據的取捨。 面試情境 你正在設計一個線上教育平台的即時字幕系統，需要支援 10,000 位同時在線的學生。系統要求：辨識延遲 < 500ms、WER < 10%、支援中英文混合語音。請說明你的 ASR 架構選擇，以及如何在 POC 到 Scale 的過程中演進這個系統。 一、核心問題：語音辨識的工程挑戰 語音辨識（Automatic Speech Recognition，ASR）聽起來簡單：輸入聲音、輸出文字。但工程上的挑戰遠比想像中複雜。 三大核心張力 準確率 vs 延遲：離線 batch 辨識可以拿到最好的準確率（Whisper large-v3 WER 4.2%），但需要等音訊結束後才能處理。串流辨識要求 < 300ms 的 partial result，但準確率可能下降 15–30%。 通用性 vs 領域適應：預訓練模型在 clean speech 上表現優秀，但在特定領域（醫療術語、程式碼朗讀、帶口音的中文）WER 可能飆升至 30%+。Fine-tune 需要標注資料，成本每小時約 $50–200。 成本 vs 自建：呼叫雲端 ASR API 每分鐘約 $0.006–0.024，自建 Whisper 在 GPU 上每分鐘約 $0.001–0.003，但需要維運成本。 語音訊號的本質困難 時間 (秒) 0.0 0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part2-tts-audio-models-zh/Sun, 21 Jun 2026 15:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase6-part2-tts-audio-models-zh/大多數工程師把 TTS 當成「呼叫 API、播放音訊」的黑箱。 真正的 AI 工程師理解聲學模型與聲碼器的分工、延遲來源、以及為何同一句話用不同架構品質差距達 0.8 MOS。 他們能設計零樣本語音克隆系統、控制情感韻律、並在 200ms 內完成整條推論鏈。 本文帶你從模型架構到線上服務，逐層拆解語音合成工程的每一個決策點。 面試情境 你的公司要推出有聲書朗讀功能，支援繁體中文與英文雙語、使用者可上傳 30 秒聲音樣本克隆自己的聲音、整體端對端延遲需低於 300ms。請說明你會如何設計這套 TTS 系統，包含模型選型、聲碼器、語音克隆架構、以及上線後如何持續改善音質。 一、核心問題：語音合成的工程挑戰 語音合成表面上是「文字轉音訊」，但工程挑戰遠比想像中複雜： 三大矛盾張力 維度 極端 A 極端 B 工程取捨 自然度 vs 延遲 Tortoise-TTS（MOS 4.5）推論 30s FastSpeech2 < 50ms 互動場景選速度，有聲書選品質 個人化 vs 資料量 傳統 clone 需 1 小時錄音 XTTS v2 只需 6 秒樣本 零樣本 clone 改變商業模式 表達力 vs 穩定度 情感模型偶爾產生雜音 平坦語調安全但無趣 情感強度需可調參數 延遲分解（300ms 預算） 文字前處理（正規化/分詞）： ~10ms G2P（字素轉音素）： ~15ms 聲學模型（Mel 頻譜生成）： ~80ms ← 最大瓶頸 聲碼器（Mel → 波形）： ~60ms 音訊編碼/傳輸： ~30ms 緩衝播放首包： ~20ms ───────────────────────────────── 總計： ~215ms ✓ 低於 300ms 核心工程問題清單https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/Mon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/大多數人：把 GPT-4V 的 API 呼叫包一層，傳圖片進去，輸出文字就叫「多模態應用」。 真正的做法：從模態路由、串流融合、延遲預算分配到降級策略，每一層都有可量測的 SLA。 差距不在模型能力，而在系統設計——隨機拼接各模態模型的 P99 延遲 8.4s vs 精心設計的多模態管線 1.9s，用戶留存率相差 2.7 倍。 本文是 AI 工程從零開始系列的 Capstone 收官之作，從 POC 到 Scale，完整走完多模態 AI 平台的工程之路。 面試情境 你負責一個 B2B SaaS 的商業智慧平台，客戶需要一個 AI 助理能同時分析：PDF 財務報告中的圖表、上傳的截圖、語音指令，以及結構化的 Excel 數據。目前你們每月有 50K 活躍用戶，高峰期同時在線 3,000 人，計劃六個月後擴展到 500K 用戶。請設計端對端的多模態 AI 系統架構，說明你如何處理不同模態的延遲差異（文字 200ms、圖片 800ms、語音 1200ms）、模態融合策略選擇依據、以及當某個模態服務降級時整個系統如何維持可用性。 一、專案目標：多模態商業智慧分析平台需求 這個 Capstone 專案整合了本系列所有核心技術：語言模型（Phase 7–9）、RAG（Phase 11）、Agent（Phase 13）、效能優化（Phase 17–18）、語音處理（Phase 6）、視覺理解（Phase 19 Part 1–2），最終構建一個真實可用的多模態商業智慧分析平台。 1.1 功能需求 輸入能力 模態 具體場景 典型檔案大小 預期延遲 文字 問題查詢、上下文指令 < 4KB 200ms 圖片 截圖、圖表、掃描文件 100KB–5MB 600–1200ms PDF 財務報告、合約文件 1–50MB 2000–8000ms 語音 口頭指令、語音備忘 10–120 秒音訊 800–2000ms 結構化資料 Excel/CSV 數據 < 10MB 300–600ms 輸出能力