為什麼只譯暫時不做 AI 翻譯增強
讓翻譯品質更好，一直是只譯想解決的事情。
我們也持續關注同類產品。近來，越來越多產品開始提供「AI 翻譯增強」「高品質翻譯」或「語意重寫」：有的引入更多網頁語境，有的透過不同的 Prompt 強調更自然的表達。
這些功能很有吸引力，我們也一直想加入。之所以遲遲沒有實作，並不是沒有看到它們，而是早期嘗試就暴露了一個問題：翻譯結果很飄。
同一套 Prompt 換一個模型，結果可能完全不同；給某個模型增加幾句指令，品質可能明顯提高，換到另一個模型卻可能不升反降。有時增加標題和上下文能解決歧義，有時模型反而會被這些資訊干擾。只看幾句出色的譯文，很難判斷一套方案是否真的更好。
最近看到更多同類產品繼續在這條路上投入，我們決定不再只憑印象討論，而是認真做一次測試。
先把「更好」說清楚
開始實驗前，我們先為這項功能劃定邊界。
語意重寫或二次潤飾不應成為每一段翻譯的常態。大多數時候，我們只是想順暢讀完一篇文章，不需要把每段譯文都處理到可出版的程度。如果為了偶爾更自然的一句話，讓所有段落都多呼叫一次模型，延遲、Token 和介面費用都會明顯增加。
因此，我們希望找到的方案必須滿足：
- 預設仍然只呼叫模型一次；
- 不增加需要使用者理解的新設定；
- 不依賴某個專用翻譯模型；
- Token 和延遲不能發生質的變化；
- 在不同通用模型上，都能顯著、穩定地優於現有方案。
最後一項最重要。新方案如果只是「有時更好」，增加的就只有複雜度，而不是可靠的產品收益。
實驗一：更多上下文，能否讓一次翻譯明顯變好？
實驗假設
第一輪實驗從一個直觀想法開始：模型翻錯，可能是因為看到的資訊不夠。
如果把頁面標題、所在段落和目標文字的關係說得更清楚，再補充對準確性與自然度的要求，模型也許可以在不增加呼叫次數的情況下，減少歧義和翻譯腔。
實驗設計
我們以 1.8.2 的簡單翻譯方式作為基線 L，又準備了三套候選方案，用來拆開比較「上下文本身」「Prompt 寫法」和「目標位置」的作用：
- A：結構化上下文。 把頁面標題、目標文字和所在段落分開提供給模型。
- B：精簡上下文與自我檢查。 縮短 Prompt，同時要求模型兼顧準確、自然，並在輸出前自行檢查。
- C：原位標記目標。 在原段落中標記待翻譯文字的位置，協助模型理解指涉和詞義。
小樣本中，每種方案都有表現出色的時候，也都有明顯失誤。為了避免憑感覺挑選，我們把測試擴大為：
- 11 個真實文章來源，每個來源選取 5 個片段，共 55 個測試單元；
- 3 個通用翻譯模型；
- L、A、B、C 四套方案，溫度和呼叫參數保持一致；
- 共執行
55 × 3 × 4 = 660次翻譯。
評分時，方案名稱會被隨機替換為匿名標籤。每個被測模型產生的譯文，都交給另外兩個模型獨立排序，允許並列；最後再依文章來源彙總，避免把同一篇文章中的五個片段當成完全無關的樣本。我們也抽查爭議譯文，並記錄 Token、延遲、重大錯誤和格式異常。
實驗結果與反思
相對 L 的基準得分率 50%，三套候選方案的總體結果是：
| 方案 | 相對 L 得分率 | 主要問題 |
|---|---|---|
| A：結構化上下文 | 53.0% | 95% 信賴區間仍跨過 50%；平均總 Token 從約 100 增至 234 |
| B：精簡上下文與自我檢查 | 50.0% | 不同模型上的方向會反轉，重大錯誤率達到 15.2% |
| C：原位標記目標 | 31.8% | 格式失敗率達到 42.4%，較弱模型容易輸出標記或錯誤格式 |
這裡的 53.0% 不是「品質提高了 3%」。它只表示 A 在這次測試中略占上風，但差距還不足以讓我們確認 A 真的比基線更好。
第一輪沒有任何方案達到「穩定、顯著優於現有翻譯」的門檻。
A 是唯一表現出正向趨勢的方案，但優勢很小，Token 卻增加了一倍以上。B 說明更強的自然表達與自我檢查要求並不具備跨模型通用性；C 則說明一個理論上更準確的上下文結構，如果模型不能穩定遵守輸出協定，反而會直接變成產品故障。
這一輪最重要的結論不是「上下文沒用」，而是：某些句子從上下文中受益，不代表把上下文加入預設流程就能穩定提高整體品質。
實驗二：更克制地使用上下文，會不會更穩定？
實驗假設
我們沒有立刻停止。第一輪的問題也可能不是「上下文」本身，而是上下文太多、組織方式太複雜，或 Prompt 同時要求模型完成太多事情。
新的假設是：完整段落繼續作為翻譯單元，只在標題、選取文字和孤立短句中補充更有針對性的語境；Prompt 回到一次呼叫、準確優先、不得增刪的簡單約束。這樣也許能保留上下文消歧的收益，同時減少複雜指令帶來的波動。
實驗設計
第二輪繼續使用相同的 11 個來源、55 個片段和 3 個模型，只比較基線與新的候選方案：
- 每個片段分別產生一份基線譯文和一份候選譯文，共 330 次翻譯；
- 形成 165 組一一對應的比較；
- 繼續使用匿名排序與雙裁判，勝、平、負分別計 1、0.5、0 分；
- 除總體得分率外，也比較不同模型的方向、平均品質分和人工閱讀感受。
50% 表示候選方案與基線總體持平。只有明顯高於這條線，而且不同模型上的方向一致，才有資格成為新的預設方案。
實驗結果與反思
第二輪最好的候選方案取得：
| 結果 | 數量 | 占比 |
|---|---|---|
| 候選方案較好 | 52 | 31.5% |
| 兩者持平 | 90 | 54.5% |
| 基線較好 | 23 | 13.9% |
以勝一分、平半分計算，它相對基線的得分率是 58.8%，比 50% 持平線高 8.8 個百分點。這個數字不是「翻譯品質提高了 8.8%」，而是候選方案在這套配對規則下取得更多比較積分。平均品質分提高 0.23 分（5 分制）。從實驗數字看，這是我們測試過最有希望的結果。
但回到實際閱讀和人工複核，問題仍然存在：90 組、也就是超過一半的譯文沒有明顯差別；同一句話在不同模型上仍可能出現相反結果；23 組退步會直接表現為誤譯、遺漏或生硬改寫。
這讓我們區分了兩件事：實驗中總體更優，不等於產品裡穩定、可感知地更好。 58.8% 說明方案值得繼續研究，卻還不能證明使用者在連續閱讀時會明確感受到提升。
另一個假設：只最佳化使用者不滿意的段落
實驗假設
既然全域增強的成本太高，我們在實驗過程中又自行延伸出一個按需處理的設想：一般翻譯保持不變，使用者覺得某段不好時，再按一次「精譯」或「最佳化譯文」。這不是照搬某個同類產品已有的功能，而是我們嘗試在品質與成本之間尋找的另一條路。
這個方案把額外呼叫限制在少數段落，理論上不會拖慢整篇文章。
實際遇到的問題
新的問題很快出現：
- 模型經常只是換一種說法，更像重譯，而不是發現並修正明確問題；
- 標題、卡片、導覽和 GitHub 首頁這類非文章頁面，不知道應在哪裡提供「精譯」入口；
- 如果只在正文段落顯示，就要先可靠判斷什麼才是高可信度正文；
- 即使增加「先審校、再決定保留或修改」的結構化輸出，最終仍要面對模型判斷本身不穩定的問題。
我們的反思
一個按鈕很容易做出來，但要證明按下後大多數時候真的更好，並不容易。按需精譯減少了呼叫次數，卻沒有解決「如何確認結果真的改善」這個核心問題，還額外帶來入口位置與正文辨識的複雜性。
目前的答案：一般翻譯保持穩定，難點交給選取翻譯
最終，我們沒有把這套 AI 增強做成預設功能，也沒有保留效果尚不穩定的「精譯」入口。
目前更簡單、也更符合真實使用習慣的方案是：
- 一般網頁翻譯繼續追求穩定與速度。 頁面標題只作為弱上下文，模型只能輸出待翻譯文字。
- 遇到不滿意或難理解的內容時，使用選取翻譯。 使用者可以只選取一個詞、短語或句子，讓模型在所在段落的局部語境中重新理解它。
- 選取結果有範圍保護。 如果模型錯誤返回整段內容，只譯不會顯示或快取這個結果，而會移除段落上下文並自動重試一次。
選取翻譯不是換個名字的「高品質模式」。它的優勢在於目標明確、由使用者主動觸發，也只為真正需要理解的部分付出額外成本。相比在每篇文章、每個段落上持續增加 Prompt 和呼叫，這更符合只譯在品質、效能與成本之間的取捨。
持續關注，但暫不作為重點
我們仍會持續關注模型、Prompt 和上下文技術的最新發展，也會在適合的時候重新驗證新的方案。不過，根據目前的實驗結果，AI 翻譯增強在短期內不會成為只譯的重點。我們會把精力放在更穩定、更明確，也更容易被使用者感知的改進上。