RAG 粵語語音應用：由知識庫到開聲答你，點樣建一個粵語問答服務

一句答你： RAG（檢索增強生成）令 AI 有根據咁答嘢，加上粵語 TTS 就變成「有根據咁開聲答」——鏈路係「查資料 → 組稿 → 開聲」，語音層用平均每分鐘約 240 字符去計成本，開戶每月免費 5,000 字符已經夠試一個完整原型。

Key Takeaways

• RAG 解決嘅係答嘢有冇根據；語音輸出解決嘅係答嘢用咩語言同形式。兩個問題分開解，鏈路先穩。
• 響 RAG 場景，TTS 唔使全文朗讀——常見問題預先錄定、動態答案即場生成，兩條軌並行。
• RAG 輸出通常係書面腔，直接讀出嚟就係「機器人讀新聞」；播報稿要專門轉寫先至入耳。
• 播報用三段式：一句直接答案、一兩句根據、一句指向下一步。
• 用戶等幾秒先聽到第一句，係體感速度嘅決定位；短句先行先至有「答得快」嘅感覺。
• 每月 5,000 字符（約 21 分鐘音頻）夠你試完整原型；要上生產先至揀付費方案。

RAG 同語音：兩個問題，一條鏈

RAG 係咩，語音加咩落去

RAG 嘅原理唔複雜：用戶問一個問題，系統先去一個指定嘅知識來源——文件、資料庫、常見問題庫——搵出相關段落，然後要 AI 只根據呢啲段落組織答案。答案唔係模型靠記憶自由發揮，而係有出處咁答。呢個架構嘅最大價值係答案可控：內容來自你俾佢嘅材料，唔係佢自己估。

咁語音喺邊？喺整條鏈路最尾一節：答案組好之後，交畀粵語 TTS 讀出嚟。兩者互補——RAG 負責「答咩」，TTS 負責「點講」。唔好將兩件事混埋一齊諗：先穩住答案嘅根據，再處理聲音；聲音做得再好，根據唔穩一樣冇用。反過嚟講，答案好但冇聲，服務覆蓋唔到唔便利文字嘅受眾。

點解香港場景一定要語音加粵語

好多 RAG 服務第一版出嚟只係文字框對答，因為文字最容易做。但香港嘅實際場景，語音唔係錦上添花：查詢熱線、長者服務、展館導覽、工場同司機等免手持場景——受眾唔方便睇屏，或者根本唔想打字。對呢啲受眾，一個答得好但只出文字嘅服務，等於半個服務。而粵語係呢批受眾嘅母語——普通話或者英文播報，等於將最需要幫助嗰批人拒諸門外。AI 粵語語音嘅整體能力，可以先由廣東話 TTS 完全指南睇起。

完整鏈路拆解

第一節：檢索（搵啱材料）

檢索品質決定一切。要將企業嘅文件拆成有意義嘅段落單位——一段講一件事——配上清晰標題同關鍵詞。常見錯誤係將成份文件當一個單位丟入去：檢索返嚟嘅嘢太長，答案就會又長又散。粵語場景仲有一個加分位：用戶嘅口語問句（「點樣」「幾時」）同書面文件用詞（「如何」「何時」）唔同，檢索層最好預先將常見口語問法納入關鍵詞，否則會明明有資料、卻查唔返嚟。

第二節：組稿（組答案）

檢索到段落之後，AI 會根據呢啲段落組答案。呢度要落一條鐵律：答案只可以用檢索材料內嘅資訊，材料冇嘅就答「暫時冇呢方面資料」。呢條規距令答案唔會虛構，亦令成個服務可信。同時，答案格式要為語音而設計——佢之後要先變成聲音畀人聽，唔係畀人望。呢個位好多團隊做漏，下面開兩節專門講。

第三節：語音化（開聲答）

稿交畀 TTS 之前，要過一層「播報稿轉寫」：將 AI 輸出嘅書面中文，轉成可以用把口講嘅粵語稿。呢層唔可以慳——直接將書面答案掟入 TTS，出嚟就係「新聞錄音腔」，用戶一聽就覺得疏離。轉寫嘅深入方法可以參考書面語轉口語指南。

生成策略上，句子層處理係 RAG 語音化嘅關鍵：唔使等成個答案組好先開始讀，可以一句一句出。第一句就係直接答案嗰句，用戶幾秒內已經聽到重點；體感速度由第一句嘅長度決定，唔係由全段長度決定。等位、語速、分段呢啲播報細節，全部喺稿層控制，唔使靠剪接後期救。

播報稿寫法：三段式

結構逐段拆

RAG 答案嘅播報稿，最穩陣係三段式：

• 第一段（直接答案）：「係嘅，呢部機仲有兩日保養。」一句講完結論。
• 第二段（根據）：「根據購買條款，保養期由購買日計一年。」講清根據由邊度嚟。
• 第三段（下一步）：「想知詳情，可以去服務頁面，或者直接致電熱線。」點用戶去下一步。

呢個結構有三個好處：用戶第一秒就得到答案；根據永遠跟喺答案後面，唔會先繞圈後揭盅；最後一句令服務有出口，答完唔會斷尾。

播報稿要剪走嘅嘢

三段式定咗結構，跟住要做減法。播報稿要剪三樣嘢：冗長修飾（「值得注意嘅係」「首先需要說明」呢類開場廢話），成串例子（播報版留一個例子已經夠，三個例子用戶會跳線），還有需要睇字先明嘅內容——表格、連結、編號引用，全部唔可以原樣讀出嚟，要轉成句子講（「表格喺網頁有顯示，你可以話我知要哪一項，我講畀你聽」）。

中英夾雜嘅統一寫法

香港服務場景嘅答案，產品名、機構名、部門名好多時係英文，混入粵語句子。稿寫規律同所有中英夾雜稿一樣：同一個對象全篇統一一個寫法；冇官方中文譯名就保留英文原名。統一寫法係讀音穩定嘅前提——呢條規律一樣適用於播報稿。

生成策略：預錄定與即場的兩條軌

常見問題預先錄定

「常見問題」——營業時間、地點、基本流程——係固定答案，值得預先錄定：稿穩定之後，一次過生成晒所有常見答案，運行時直接播音檔。好處有兩層：零生成延遲，用戶即問即聽；同埋運行時零字符成本，用量壓力大幅下降。一個中型服務嘅常見問題庫，通常幾十條答案、幾分鐘音頻就夠覆蓋大部分查詢量。

動態答案即場生成

含個人資料（賬戶狀態、預約記錄）或者即時數據（今日貨量、臨時安排）嘅查詢，答案由即場組：RAG 根據個人材料組答案，語音即場生成。呢條軌嘅播報稿要特別注意：個人資料讀出嚟無得「望返轉頭」，所以關鍵資訊要重複一次，日期、時間要用最清晰嘅講法，關鍵位重複一次。

兩條軌點樣共存

分流規則好簡單：答案文本喺唔同用戶之間一樣 → 預錄；答案文本隨人隨時變 → 即場。預錄庫要有版本管理：稿改一個字就重生成、歸檔，所有渠道只播最新版。批內容一次過重生成可以用批量方式處理。

追問輪次嘅聲音設計

RAG 語音服務好少一問一答就完：用戶會追問。播報結尾要有「歡迎追問」嘅設計——「仲有咩想知，隨時問」一句就夠。同一條主線嘅追問，要沿用同一條聲線同一組風格，令用戶感覺係同一個「講者」一路伴住。多講者或者轉講者場景嘅處理。

預錄庫嘅版本管理細節

版本管理要落到三個位。第一，記錄位：每條預錄答案記低稿本、生成時間、用喺邊幾個渠道，日後追查先有得翻。第二，歸檔位：重生成之後，舊檔收埋但唔即刻刪——渠道更新可能有時間差，舊檔留幾日做後備，出事都有得返轉頭。第三，核聽位：重生成唔係生成完就算，要逐條聽返一次先上播——批量重生成之後逐條試聽，係上線前最後一道關，唔可以慳。

呢三個位唔使複雜系統支撑，一個共用表格已經做到。重點唔係工具，係規距：有記錄、有後備、有核聽，預錄庫先至可以一路長大而不亂。好多服務嘅預錄庫聽日同今日「把聲唔同晒」，就係因為重生成無規距，逐次漂移累積。

聲線同播報細節

聲線要求：可信第一

RAG 服務聲線嘅第一要求唔係「幾靚」，係「幾可信」——穩定、咬字清晰、唔浮誇。語速中速偏慢，因為播報內容帶資訊量，太急用戶要逐段重聽。情感層面要克制：情緒調控可以令播報有溫度，但幅度要細——服務播報唔係表演。想調節演繹，喺平台嘅演繹風格入面逐組試。

標點同等位

RAG 答案逐段講，段同段之間要有等位。標點影響 TTS 停頓，用得啱，播報節奏自然。句同句之間停頓大啲，令「直接答案」同「根據」清楚分開，用戶唔會以為答案仲未講完就開始分心。

錯誤同冇答案嘅播報

完整服務一定遇到「檢索唔到」或者「組稿失敗」。呢啲位要預先錄好：一句「呢個位我暫時答唔到你」，加一句「可以換個方式問，或者搵真人同事」。錯誤體驗由人設計好，唔好等系統臨場亂講——錯誤對話嘅好壞，係用戶對服務觀感嘅分水嶺，亦係好多人忽略嘅位。

成本同啟動路徑

字符預算點計

語音成本由字符計：平均語音每分鐘約 240 字符。一個典型 RAG 播報答案（三段式、三至五句）約 80 至 150 字符，即約 20 至 35 秒音頻。一個中型服務嘅月度帳：常見問題預錄 50 條答案約 5,000 至 7,000 字符（一次過做），動態答案假設每日 30 條、每條約 100 至 130 字符，月度全部加埋大約 100,000 字符上下——入門方案嘅 200,000 字符已可完全覆蓋，仲要留有改稿重生成嘅餘量。字符同方案匹配嘅通用算法，可以睇粵語 TTS API 成本計算。開戶每月免費 5,000 字符約 21 分鐘音頻，用嚟試原型：揀十條真會遇到嘅問題，撰稿、生成、試播、修正，一次過走晒全個流程。呢個階段的確唔使掂付費方案；唔夠位，最細字符包（HK$50、約 62,500 字符、每千字符 HK$0.80）已經可以補。付費方案仲有年繳折讓：入門年繳平均每月 HK$102，專業 HK$270，工作室 HK$550。方案對照如下：

接入方式同品牌聲線

原型階段用平台介面完全足夠；到服務要嵌入自己嘅系統（電話熱線、站內搜尋、語音亭），可以經 API 接入：提交文稿、取回音頻、由自己系統播。API 嘅上手流程可以睇粵語 TTS API 快速上手。另一個常用位：機構想服務用返「品牌把聲」播報，可以用一段現有品牌錄音做參考樣本，用聲音複製功能生成相似聲線；四個方案都有呢項功能。用之前記住要攞到該段錄音嘅使用授權，尤其係真人唔喺陣嘅機構資產。

常見問題 FAQ

RAG 加粵語 TTS，要寫程式先做到？

原型階段唔使。用平台介面，將常見問題答案一段段生成，預錄庫由簡單檔案管理開始，已經可以推出「查詢—播放」嘅第一版服務。要動態生成或者大規模接入，先至需要程式開發；由零代碼開始係最穩陣嘅路。

RAG 答案點樣避免亂作？

靠「根據鐵律」：答案只可以用檢索材料內容，材料冇就答「暫時冇呢方面資料」。播報稿仲要保留「根據由邊度嚟」一節，令答案有追蹤位。呢條規距寫入系統要求之後，答案質素先有底。

已有普通話嘅 RAG 服務，可以直接改成粵語嗎？

語音層可以，但播報稿要重寫：粵語播報嘅句式、語氣詞、節奏同普通話唔同，普通話稿直接由粵語引擎讀，聽感一定怪。正確做法係攞住答案材料，用粵語語感重寫播報稿，再入引擎。

一條答案播報應該幾長？

20 至 35 秒最舒服，約 80 至 150 字符。重點係三段式結構清楚，唔係求長。用戶要知下一步做咩，多過要知每一個細節；細節留返畀文字頁面補上。

常見問題預錄定好過即場生成？

常見問題一定係預錄好：運行零延遲、零字符成本、品質逐條錄定。只有含個人資料或者即時數據嘅回答先至即場生成。所有都即場生成嘅服務，字符用量會白白多幾倍，用戶等嘅時間都長啲。

粵語語音品質點評估？

用真問題試聽：攞十條你服務真會遇到嘅問題，由頭到尾播一次，聽三件事——咬字準唔準、句式自然唔自然、播報節奏明唔明確。。

服務升級嗰陣，預錄庫點搞？

版本化管理：每條預錄答案記低稿本同生成時間，內容改動就重生成加歸檔，所有渠道同一時間只播最新版。批量內容一次過重生成，令升級日零手工作業。

[!CTA]

由一條問題開始：開戶試第一個粵語問答原型

每月 5,000 字符額度，夠你揀十條常見問題，一次過試晒撰稿、語音化同試播全條鏈路。