DeepL 說它最強。GPT 說它最強。你的詞彙表對兩者都不以為然——從第一批到最後一批之間，「Plan」的核准譯法悄悄變成了別的東西，而客服工單在任何人發現之前就已經湧進來。
AI 翻譯是 2026 年最容易被忽略的本地化瓶頸：業界正積極地拿 LLM 與神經機器翻譯（NMT）做基準比較，但開發者端的 pipeline——詞彙表強制執行、分塊、品質門檻、每百萬字的成本——仍然大多沒有文件記錄。供應商的行銷說「我們的模型最強」，學術論文量測的是你無法上線的東西，而真正在正式環境運行的中間層，卻付之闕如。
這份指南涵蓋兩半：供應商基準測試實際顯示了什麼（以及自己跑一套的方法論），還有我們打造出來的正式環境 pipeline——詞彙表 → 分塊 → 翻譯 → 強制執行 → 品質檢查——再加上讓每月百萬字維持可負擔的成本控制。
LLM 翻譯實際改變了什麼
重點：LLM 翻譯把「正確」換成了「在語境中正確」——而這改變的是整條 pipeline，不只是引擎。
神經機器翻譯（MT）翻譯句子。LLM 則帶著上下文翻譯：它們能遵守詞彙表、維持品牌語氣、尊重風格指南，並處理句子級系統會抹平的歧義。三項能力造成了差異：
- 術語控制。 詞彙表是輸入，不是期望。模型可以被要求對產品名稱或法律用語使用核准譯法——是強制執行，不是請求。
- 上下文視窗。 一個段落、一頁、一份文件——模型看到的不只一句話，這修正了困擾 MT 的跨句指涉錯誤。
- 可指令的輸出。 語氣、正式程度、受眾——「法律文件用正式語氣，新手引導用親切語氣」是一段 prompt，不是換一個模型。
必須破除的誤解：LLM 翻譯不是「更好的 MT」。它是成本結構不同的另一種工具——每字成本更高、掌控力更強。下面這條 pipeline，正是為了讓這份成本值得而存在。
為什麼要自己打造翻譯 Pipeline
重點：這條 pipeline 之所以存在，是因為供應商賣的是引擎，不是保證——詞彙表控制、可量測的品質、持續下降的模型成本，全都得靠你自己打造。
三個理由，讓擁有 pipeline 勝過租用翻譯供應商：
- 術語是一份契約。 品牌名稱、法律術語、產品字串——你的詞彙表是商業資產，而只有 pipeline 能在每一批、每一種語言之間一致地強制執行它。
- 品質必須可以量測。 「看起來沒問題」撐不過產品審查。帶有自動化品質檢查階段的 pipeline，會產出每一批、每一種語言的分數——這正是我們的測試指南套用在其他一切事物上的 eval 紀律。
- 模型成本持續下降。 每一代模型都會降低每字價格。把模型當成可設定元件的 pipeline 會自動承接這些降幅；供應商合約不會。
另一個選擇——翻譯供應商——買到的是方便，賣給你的是鎖定。本系列的價值對決說明了為什麼模型層應該保留為你能掌控的決策，同樣的邏輯也適用於翻譯。
供應商基準測試：依語言組合的品質、成本與延遲
重點：品質排名是依語言組合而定的，而且幾個月內就會過期——請自己跑語料，並把每一份公開排名（包括我們的）都當成快照。
2026 年的版圖競爭激烈：像 intlpull 的 LLM 翻譯基準測試與 Lokalise 的 2026 模型調查這類獨立評測，顯示前沿模型依語言組合與任務類型互有勝負，而預算級模型正在常見語言組合上縮小差距。結構上成立的事實：
- 前沿模型在低資源語言組合上領先，在細膩語域上也是——訓練資料稀薄的地方，差距是真實的。
- 預算級與開放權重模型在高資源語言組合上很接近——英語↔西班牙語、法語、德語、日語——在這些語言上，「夠好」已經走完通往「很棒」的大部分路程。
- 供應商之間的差距，小於 prompt 設計之間的差距。 在大多數語言組合上，詞彙表注入與分塊對品質的影響，大於模型選擇。
成本那一面：每百萬字定價隨模型層級與快取行為而變——前沿層級的價格是預算層級的好幾倍，而對穩定區段（固定樣板文字、重複字串）做快取可以壓縮實際費率。目前可用性以模型目錄為準；採購時請在供應商頁面核對費率，因為翻譯預算對這些數字特別敏感。
自己跑一輪基準測試，一個下午就夠：每種目標語言挑 20 個具代表性的字串，用兩個候選模型加上你現有的 MT 各跑一遍，再請母語者以盲測方式評分。業界文章用的就是同一套方法，而它回答的是唯一重要的問題——對你的產品、你的語言而言，誰最強。
如何打造 Pipeline：詞彙表 → 分塊 → 翻譯 → 強制執行 → 品質檢查
重點：五個階段，一份契約——詞彙表是資料，品質檢查階段是一道關卡，中間的一切都是機制。
骨架程式碼，跑在統一 chat endpoint上：
import json
from openai import OpenAI
client = OpenAI(base_url="https://api.tokspan.com") # unified endpoint — one key for every model
GLOSSARY = [ # enforced, not suggested
{"source": "Checkout", "target": "Finalizar Compra", "lang": "es"},
{"source": "Plan", "target": "Tarifa", "lang": "es"},
]
def translate(text, lang, model="gpt-4o-mini"):
sys = (
"You are a professional translator. Use the glossary exactly; "
"never translate glossary terms differently. Keep the brand voice."
f"\n\nGlossary: {json.dumps(GLOSSARY)}"
)
return client.chat.completions.create(
model=model,
messages=[{"role": "system", "content": sys},
{"role": "user", "content": text}],
).choices[0].message.content
# Stage 5: the gate
def qa(original, translated, lang):
verdict = client.chat.completions.create(
model="gpt-4o", # a different model as judge — never the translator
messages=[{"role": "user", "content":
f"Rate this translation 0-10 for accuracy, terminology, and tone: "
f"\nSource: {original}\nTarget: {translated}"}],
).choices[0].message.content
return float(verdict) >= 7五個階段，各有各的規則：
- 詞彙表——結構化資料，注入 system prompt。契約是「精確照用」，不是「盡量採用」。
- 分塊——以段落為單位，不是以句子為單位，讓上下文存活；含有術語的區段保持完整。
- 翻譯——模型層級是一個路由決策：固定樣板用預算級，行銷文案用前沿層級（自訂路由讓這件事可以逐區段決定）。
- 強制執行——掃描輸出中的詞彙表術語；任何漏掉的地方，都會在詞彙表重點標示後重新翻譯。正是這個迴圈，讓術語從期望變成保證。
- 品質檢查——一道 LLM-as-judge 關卡，使用與翻譯不同的模型，逐區段以門檻分數把關。沒通過關卡的批次不上線；上面連結的 eval 方法論同樣適用。
如何控制品質與成本
重點：每百萬字成本是一個設計參數——分層、快取與批次處理，通常能在完全不碰品質的情況下砍掉 60-80%。
成本模型，一句話講完：每百萬字成本 = 模型費率 × token 膨脹係數（翻譯會膨脹 token：一份 1M 字的語料，加上 prompt 開銷後通常變成 1.3-1.6M tokens）。三個槓桿：
- 依區段類型分層。 固定樣板、UI 字串與法律樣板文字跑在預算級模型上；行銷與品牌文案跑在前沿層級。這樣的組合通常比全部用前沿層級便宜 50-70%。
- 快取那穩定的 80%。 選單、標籤、重複的區塊——在重複出現的區段上維持穩定的 prefix，就能以輸入費率的零頭命中快取定價。翻譯是最適合快取的工作負載之一，因為同樣的字串會在每一種語言的批次中重複出現。
- 批次處理離線流程。 整份文件翻譯、字串匯出與夜間同步都容許延遲——本系列批次指南的折扣模式，正是把這 50% 折扣套用在這些工作負載上。
同一枚硬幣的品質那一面：品質檢查關卡的分數門檻與評審模型，都像程式碼一樣做版本管理。每一次模型升級，都要先重跑 eval set 才能碰正式環境——正是這份紀律，讓「模型變好了」不會變成「詞彙表變糟了」。
會毀掉翻譯品質的常見錯誤
重點：四種失敗——每一種在 demo 裡都看不見，在正式環境裡都很昂貴。
- 詞彙表漂移。 沒有強制執行迴圈、沒有輸出掃描——核准譯法就變成「通常」。強制執行是一個階段，不是一種偏好。
- 扼殺上下文的分塊。 句子級分塊會切斷跨句指涉，並拆散含有術語的片語。以詞彙表感知的邊界做段落級分塊，是基本要求。
- 單一指標評估。 只用 BLEU，會獎勵「字面正確」、懲罰「自然道地」。請改用評審評分加上母語者抽樣——與其他所有 LLM 輸出評估相同的雙軌模式。
- 被機器翻譯抹平的本地化。 翻譯不是本地化：日期、貨幣、單位與文化指涉需要在翻譯之後做 locale 處理，而不是用翻譯取代。pipeline 的最後一個階段是 locale 改編，跳過它，正是「定價頁面」變成客服工單的原因。
常見問題
LLM 翻譯比 DeepL 或 Google 翻譯更好嗎？
在術語控制與語域上，是的——LLM 能遵守 MT 無法做到的詞彙表與風格指令。在每字成本與簡單的高資源語言組合上，MT 仍然勝出。這個決策是「掌控力 vs 成本」，不是「好 vs 壞」。
如何評估翻譯品質？
評審制評分（使用與翻譯不同的模型）加上在固定 eval set 上做母語者抽樣。只用 BLEU 會誤導——它量測的是字面重疊度，不是自然度。請為 eval set 做版本管理，並在每次模型升級時重跑。
每百萬字的翻譯成本是多少？
大約是模型費率乘以 1.3-1.6 倍的 token 膨脹——預算層級遠低於前沿層級，而快取加上批次處理會進一步壓縮實際費率。用模型計算，不要靠猜；這份指南裡的公式就是起點。
如何強制執行術語？
詞彙表注入加上輸出強制執行掃描：每一個區段都會與詞彙表比對，漏掉的地方會在術語重點標示後重新翻譯。「盡量採用」是期望；「掃描後重試」是保證。
我應該把翻譯任務批次化嗎？
離線翻譯——字串匯出、文件同步、夜間流程——是典型的批次工作負載：容許延遲、數量龐大，而且在每家主要供應商的批次層級上都有 50% 折扣。互動式 UI 翻譯則維持即時。
預算級模型能處理翻譯嗎？
在高資源語言組合上可以——訓練資料充足的地方，與前沿模型的差距很小。低資源語言組合與細膩語域仍然值得用前沿層級。逐區段的路由決策，正是這條 pipeline 的用途。
總結
用 LLM API 做 AI 翻譯，比的是掌控力，不是比模型：詞彙表強制執行讓術語成為契約，評審制品質檢查關卡讓品質可以量測，而分層、快取與批次處理讓成本成為設計參數。供應商排名只是快照——請用每一份嚴肅基準測試都在用的方法，在你的語言組合上跑你自己的語料。然後把 pipeline 蓋好一次，每一代新模型都會讓它更便宜。
你的語言、你的語料、你的判決。立即取得你的 TokSpan API Key，把同樣的字串丟進好幾個模型跑一輪；$5 免費額度足以支付第一輪基準測試。