RW

Writing

用 Semantic Entropy 降低長文翻譯中的名詞飄移

AI,LLM,Translation · 2025-11-25 · Updated 2026-04-26

長文翻譯裡，有一個很常見但很煩的問題：名詞會飄。

同一個專有名詞，在第一章被翻成一種說法，到了後面又變成另一種。技術文件、小說、產品文檔都會遇到。文本越長，這件事越明顯。

這不一定是模型「不懂」。更多時候，是上下文太長、採樣有隨機性、前後語境又在變。模型每次都能給出看似合理的翻譯，但合理不等於一致。

我想整理的是一個比較白盒的解法：用 Semantic Entropy（語義熵）先找出容易飄的名詞，再把它們變成一份局部名詞表，最後交給翻譯模型強制套用。

問題不只是翻得好不好

傳統翻譯流程常常把重點放在「哪個譯法更好」。但在長文翻譯裡，另一個問題同樣重要：

哪些名詞本身是不穩定的？

如果一個名詞每次都被模型翻成差不多的語義，它就不需要太多干預。反過來，如果同一段文本跑多次翻譯後，某些名詞出現多種譯法，那些名詞才是真正需要被固定下來的地方。

Semantic Entropy 的價值就在這裡。它不是直接替你選最佳翻譯，而是幫你看到模型的不確定性輪廓。

語義熵在這裡怎麼用

直覺上，可以這樣理解：

  • 多次輸出語義接近，熵低，代表穩定。
  • 多次輸出分散，熵高，代表不穩定。
  • 在翻譯任務裡，高熵名詞通常就是名詞飄移的來源。

所以流程的第一步不是建立一份巨大 glossary，也不是一次就要求模型翻到最好。

第一步是重複採樣。

對同一段原文，讓模型產生多個翻譯版本。數量不需要很誇張，通常 5 份可以看到問題，7 到 10 份性價比比較好，14 份會更穩但成本也更高。

輸出可以保持成簡單的 JSON：

[
  { "version": 1, "translation": "..." },
  { "version": 2, "translation": "..." },
  { "version": 3, "translation": "..." }
]

抽取名詞，而不是處理整段翻譯

接著，從每個版本裡抽取名詞。

這一步可以用傳統 NLP，也可以用比較小的 LLM。重點不是要讓它理解整篇文章，而是把可能需要穩定的項目抓出來。

常見類別包括：

  • 專有名詞
  • 技術術語
  • 人名、地名
  • 產品名
  • 品牌名
  • 小說或世界觀裡的特定物件

抽取結果可以長這樣：

{
  "proper_nouns": ["EUV Lithography", "ASML"],
  "terms": ["光阻劑", "曝光"],
  "characters": ["John"]
}

這一步完成後，我們得到的不是最終譯文，而是一批名詞候選。

聚類，找出真正會飄的名詞

有了多個翻譯版本和名詞候選後，就可以做聚類。

做法不複雜：

  1. 把名詞或名詞短語轉成 embedding。
  2. 用 cosine similarity 計算距離。
  3. 用一個 threshold 把語義接近的譯法合成同一群。

如果同一個原始名詞在多次翻譯裡只形成一個 cluster，代表它很穩。反過來，如果它分裂成多個 cluster，就代表模型對它的處理不一致。

這時候就可以計算一個工程上可用的語義熵分數。

熵 = cluster 數量 × cluster 內部詞彙差異度 × 出現頻率差異

也可以先用更簡化的版本：

H(term) = (#clusters - 1) + variance(embedding) + frequency_divergence

公式不需要一開始就非常學術化。真正重要的是，它要能把「穩定名詞」和「不穩定名詞」分開。

名詞穩定表

高熵名詞會進入一份名詞穩定表。

{
  "EUV Lithography": "EUV 曝光機",
  "ASML": "ASML",
  "光阻": "光阻劑",
  "mask": "光罩"
}

這份表不是普通的人工 glossary。它的來源是模型多次翻譯後暴露出來的不穩定點。

最後翻譯時，只需要把這份表放進 prompt 裡，要求模型固定使用：

請強制使用以下名詞對照表中的翻譯，不得依情境變更。

這樣一來，模型仍然負責翻譯句子，但名詞的一致性由外部表約束。

真正關鍵的是局部名詞表

這個方案裡，我覺得最重要的部分不是「名詞表」本身，而是名詞表的使用方式。

大型名詞庫不應該每次都完整塞進 prompt。

如果一份全域名詞庫有幾千、幾萬個詞，直接放進上下文，只會增加 prompt 壓力。模型需要在大量無關詞裡找真正相關的幾個詞，反而更容易稀釋注意力。

更合理的方式是：

  1. 先掃描當前段落。
  2. 找出這一段可能出現的名詞。
  3. 從全域名詞庫裡取出局部子集。
  4. 只把這個小名詞表注入當前翻譯 prompt。

也就是說，名詞記憶不應該是全域灌入，而應該是段落局部動態注入。

這會讓 prompt 更短，也讓模型更容易遵守約束。

和傳統 glossary 的差別

傳統 glossary 的問題是，它通常依賴人工維護。你需要先知道哪些詞重要，再提前寫進表裡。

這套方法多了一層偵測：它先用多次採樣找出模型自己不穩定的地方，再決定哪些詞需要進表。

所以它更像是一個翻譯前的風險掃描流程。

它不保證譯文一定更優美。但它可以讓名詞一致性變得可觀察、可調試、可約束。

本地模型也能跑

這套流程不一定需要非常大的雲端模型。

一個比較現實的配置是：

  • 名詞抽取：7B 級模型或傳統 NLP。
  • 多次採樣與熵偵測：14B 級模型。
  • 最終翻譯：14B 或 32B 模型。

因為這不是訓練任務，而是 pipeline orchestration。成本主要來自多次推理，而不是模型訓練。

對本地翻譯工具來說，這個方向挺有吸引力。它不要求模型一次性記住整個語域，而是把名詞記憶拆出來，變成外部可控的結構。

小結

Semantic Entropy 在這裡的作用，不是替代翻譯模型。

它更像是一個檢測器：先找出哪些名詞容易飄，再把這些高風險名詞轉成穩定表，最後用局部名詞表約束翻譯模型。

整個流程可以概括成：

  1. 同段落多次翻譯。
  2. 抽取名詞。
  3. 聚類譯法。
  4. 計算語義熵。
  5. 生成名詞穩定表。
  6. 翻譯時動態注入局部名詞表。

它解決的不是「讓模型變聰明」的問題，而是把長文翻譯裡最容易失控的一部分，拆出來做成可觀察、可控制的工程流程。