粵語 ASR 詞表規則對照：50 詞、100 詞、1000 詞背後係三種設計

你打開四家平台嘅文件，搵同一個功能。第一家寫「50 個詞」。第二家寫「100 個 keyterm」。第三家寫「1000 個」。第四家寫「200 或 1000，睇型號」。

同一個需求，四個數字，差二十倍。

多數人嘅反應係「咁當然揀 1000」。但呢個數字唔係容量承諾，係工程產物。詞表點樣入模型，決定咗上限，亦決定咗你加第 51 個詞之後會發生咩事。

本文只做一件事：把四家規則排埋一齊，然後解釋點解會差咁遠。

重點摘要

• 詞表 係指一串詞去偏推解碼結果，唔係重新訓練模型；佢提高命中率，但唔保證一定出。
• 四家上限：我哋 50 詞／每詞 30 字元；Deepgram 100 詞但合共 500 token；ElevenLabs 批次 1000、實時 50；AssemblyAI 200 或 1000，每個短語最多 6 個字。
• 上限差異源於三種路線：prompt 注入、檢索過濾、解碼 boosting。路線唔同，詞表嘅「有效區間」亦唔同。
• 學術界一致見到：清單越大，邊際效益越低。同一個模型，細清單嘅實體字錯誤相對減幅 30.7%，大清單跌到 18.0%。
• 實務建議：由 20 至 30 個真正會出現嘅專名開始，逐批加，每次都做 A／B。加詞係實驗，唔係設定。

四家規則放埋一齊

以下全部取官方頁，查閱日期 2026-10-31。

兩個容易睇漏嘅位。

第一，Deepgram 嘅 100 同 500 token 係兩條閘。詞數未爆，token 可能已經爆；爆咗係回錯誤，唔會靜靜幫你剪。官方文件仲加咗一句建議：留喺 20 至 50 個最重要嘅詞就好（Keyterm Prompting 文件，2026-10-31 查閱）。

第二，AssemblyAI 嘅 1000 只限 U3.5 Pro。而粵語唔喺 U3.5 Pro 嘅語言清單內，非同步粵語要跌返 U2，上限就係 200（API 參考、模型與語言頁 同定價頁，2026-10-31 查閱）。睇規格唔好只睇最大值。

ElevenLabs 嘅 1000 亦只限批次，實時收窄到 50 個、每詞 20 字元（官方文件，2026-10-31 查閱）。實時場景根本用唔到四位數。

上限嘅來源：三種技術路線

Token 上限 係指模型嘅提示窗可以容納幾多字，唔係資料庫容量。

路線一：Prompt 注入

把詞表砌成一句提示，塞入解碼上下文。好處係改動最小，任何模型都用得。壞處係受上下文長度限制，而且詞越多，注意力越分散。

我哋走呢條路：50 個詞組成一句 200 字元以內嘅提示。Deepgram 嘅 500 token 亦係同一類限制。

路線二：檢索過濾

檢索過濾 係指先由大詞表篩出相關候選，再交給模型，所以名義上限可以很大。

先由大詞表檢索出「同呢段音頻相關」嘅候選，再注入。呢個做法可以食大列表，因為真正入模型嘅只有少量。

AssemblyAI 同 ElevenLabs 嘅四位數上限，本質上係呢條路線。學術界嘅 BR-ASR 更誇張，講到 20 萬條目都可以靠檢索撐住（arXiv 2505.19179，2026-10-31 查閱）。

路線三：解碼 boosting

直接喺解碼搜索樹上面加詞語路徑，唔經提示窗。NVIDIA 嘅 TurboBias 報稱可以處理兩萬個短語（arXiv 2508.07014，2026-10-31 查閱）。

所以「1000」唔代表佢認得 1000 個詞。佢代表「我可以用呢個方法塞 1000 個候選入去」。兩件事。

多唔一定好：三份研究同一方向

第一份，微軟嘅 prompt biasing 研究做咗一組對照：同一模型，細實體清單嘅實體字錯誤相對減幅 30.7%，大清單只有 18.0%（arXiv 2506.06252，2026-10-31 查閱）。

同一個方法，清單一大，效果打七折。

第二份，CMT-LLM 喺重疊語音測試集上面，biasing 清單開到 1000 時，LibriMix 係 7.9%，AMI 遠場會議係 32.9%（arXiv 2506.12059，2026-10-31 查閱）。同一組設定，場景一換，數字差四倍。詞表救唔到收音。

第三份就係我哋自己嘅實驗。

我哋自己嘅實測：26 條片段、20 個詞

【實測】2026-10 我哋做過一次詞表 A／B：26 條粵語片段，20 個專有名詞，同一批音檔跑「無詞表」同「有詞表」兩個條件，逐句人手核。

結果：8 個詞得到修正，零回歸，整體正規化字錯率由 0.1015 降到 0.0895。方法同驗收細節喺 自訂詞彙測試協議。

同一批測試亦撞到一個失效模式。當音檔碼率低過 32kbps、而詞表又太短，引擎會傾向「照讀詞表」，即輸出詞表內容而唔係轉寫音頻。呢個情況喺 4 個樣本上全部重現，唔係隨機。

呢個發現改變咗我哋寫文件嘅方式：詞表唔係「加咗就一定好」，佢係一個要驗收嘅介入。

限制要講清楚。26 條係細樣本，唔可以外推成「加詞平均減幾多百分比」。所以本文冇寫「粵語詞表平均提升 X%」呢類數字。測試方法本身見 廣東話語音轉文字實測；中英夾雜嘅情況，另見 中英夾雜 IVR 實測。

香港場景：50 個位點分配

如果你手上有一份 200 個專名嘅清單，第一步唔係問邊個平台食得落，係問邊 50 個最值得。

以下係一個實際可用嘅分配（總數 50）：

三個唔好放嘅類別：

1. 常用詞。譬如「今日」「開會」，模型本身唔會錯。
2. 單字。單字冇上下文，偏推效果弱，而且容易引發假命中。
3. 你唔肯定會唔會出現嘅詞。詞表越鬆，越容易干擾。

例如「陳」同「曾」喺電話頻寬下經常互換，寫「陳大文」比寫「陳」有效得多。同理，「HKMA」要決定你想出「HKMA」定「金管局」，兩者只可以揀一個寫法。

搬詞表去另一個平台，要改三樣

很多人以為詞表係純文字，copy-paste 就得。實際上有三個位會靜靜出事。

第一，長度。我哋 30 字元，ElevenLabs 批次 50 字元、實時 20 字元。一句長公司名搬去實時會直接被截。

第二，分隔方式。我哋收換行、逗號、頓號；Deepgram 要重複 keyterm 參數；ElevenLabs 同 AssemblyAI 收 JSON 陣列。用錯分隔，多數平台唔會報錯，只會當成一個超長詞。

第三，重量語法。舊式 keyword 功能有 詞:0.15 呢種加權寫法，Deepgram 新嘅 keyterm 明確唔支援。你照抄舊格式，佢唔會報錯，只會當成一個字面詞，靜靜乜都唔 boost。

第三點係最陰險嘅，因為冇錯誤訊息。

【獨家觀察】搬平台出事嘅個案，幾乎都唔係「詞表唔夠大」，而係「詞表靜靜失效」。文件寫明嘅限制通常有人睇，冇寫明嘅靜默行為冇人測。所以搬完一定要抽 20 條重跑一次 A／B，唔好靠「應該一樣」。

揀平台時要問嘅四條

1. 上限係「詞數」定「token」？兩條閘邊條先爆？
2. 超出上限係報錯，定靜靜截斷？
3. 詞表係每次請求帶，定存喺帳戶？兩者嘅版本管理完全唔同。
4. 實時同批次嘅上限係唔係一樣？

如果對方答唔到第二條，你嘅測試結果會無辦法解釋。

常見問題

詞表係唔係越多越好？

唔係。多數平台嘅偏推係「相對權重」，詞越多，每個詞分到嘅注意力越少。先用 20 至 30 個，逐批加，每次都做 A／B。

我嘅專名超過 50 個，點算？

分兩層。核心 50 個長駐，其餘按場景切換（例如按客戶、按項目開不同詞表）。我哋嘅帳戶詞表係 PUT 換整份，所以切換等於換一份清單，唔係逐個加。

加詞之後準確度跌，係唔係平台壞？

多數係詞表污染。常見原因有三個：詞表太短但音檔碼率低、詞語互相競爭、或者放咗常用詞。先減一半再測，通常就見到答案。

關於呢篇文

本文由港嘢內容團隊整理。對手規則全部取自官方文件，查閱日期 2026-10-31；學術數字取自 arXiv 原文，同樣日期核對。想睇我哋點樣測自己嘅引擎，可以讀 廣東話語音轉文字實測；想知詞表喺接入層嘅位置，讀 廣東話 ASR API 選型。發現錯漏，歡迎 聯絡我們；公司背景見 關於港嘢。

資料來源：Deepgram Keyterm Prompting 文件（100 詞、500 token、20–50 詞建議）；ElevenLabs Speech to Text 文件（批次 1000／實時 50、字元上限）；AssemblyAI API 參考與定價頁（2026-10-27 更新）；arXiv 2506.06252、2506.12059、2508.07014、2505.19179；港嘢 /v1/docs（50 詞、30 字元、200 字元提示句）。