從 Google 翻譯遷移到 Claude API 的機械翻譯｜運用 LLM 翻譯所得到的心得

大約兩個月前，我們將公司的文章翻譯從 Google 翻譯改為 LLM。

為什麼選擇 Claude？它的運作機制是什麼？而且，為什麼不選擇成本更低廉的 Gemini，反而選擇了 Claude？

雖然仍在實驗階段，但我們整理了目前的架構和思路。

Google 翻譯當然也能翻譯

首先要說明的是，Google 翻譯並非不好。

翻譯速度很快，日常使用也足夠了。過去也沒出現過什麼大問題，但當要翻譯整篇文章時，光是將日文替換成其他語言就不夠了。相比現今 AI 的精度，我們感到遠遠不足。

逐句看沒有錯誤，但整篇文章讀起來略顯生硬。同一詞彙的譯法會中途改變，像是按字元分割的標題或文案會被破壞得一塌糊塗。

我們需要的不只是意思通順的翻譯，而是能自然流暢地作為文章讀物的翻譯。

於是，我們終於改用 LLM 進行機械翻譯了。

去年用Google翻譯進行多語言展開，DR從30下降到19

切換到LLM的原因不僅僅是翻譯品質。

使用Google翻譯進行文章多語言展開時，我們也改變了許多SEO相關的設計，但由於一次支援8種語言，反向連結權重急劇下降。

Ahrefs的DR從30下降到19。😨

下降了11個百分點。

下降得相當厲害。

當然，DR下降並不是單純因為使用Google翻譯所致，問題在於多語言網站側包含URL和內部連結等的SEO設計。我們需要緊急重新檢視包括翻譯方法和翻譯文章架構在內的整個多語言化機制！

目前DR應該已經回升到30以上，但我們計畫進行更多實驗，所以預計可能會再次下降。w

上升或下降～

經過比較，Claude在我們的文章中表現最佳

在切換到LLM翻譯時，我們研究了多個模型，並實際進行了文章翻譯測試。

我們主要關注以下幾個方面。

• 翻譯後的文章是否自然易讀
• 長篇文章是否能保持語境連貫性
• 術語和表記是否能統一
• 是否能理解標題與正文的關係
• 是否遵循指定的翻譯規則
• 是否擅自添加原文中沒有的內容

經過比較，Claude的翻譯對我們的文章效果最佳。

這並不是說「Claude在世界上所有翻譯中都最優秀」。

這些結果完全是根據本公司的評估標準在特定文章上進行測試所得，實際結果會因翻譯文章的類型、長度和所需文體而異。

這次我們優先考慮文章的自然性，選擇採用 Claude API。

就成本而言，Gemini 更便宜。

在翻譯品質方面 Claude 表現更好，但從成本來看，Gemini 更具優勢。

我們並未從一開始就決定要持續使用 Claude，但首先我們決定使用翻譯品質更好的 Claude 進行運營！

之後如果 Gemini 也能達到必要的品質標準，就切換過去！
或者根據文章類型選擇不同的模型使用。

我們也在考慮這樣的運營方式。

由於 LLM 變化迅速，目前最好的模型在半年後不一定還是最好的。
模型的性能和價格都會變動。

使用目前最好的工具，當情況改變時就切換。

現今的 AI 應用就應該保持這樣的距離感比較恰當呢！

只對未翻譯的文章調用 Claude API

並非每次顯示文章時都會調用 Claude API。

構建時會快取翻譯版文章，之後則返回已保存的翻譯。僅對尚未翻譯的文章調用 Claude API。

每次訪問同一篇文章時都進行翻譯，會每次產生 API 費用。顯示速度也會變慢。

只翻譯必需的文章，已翻譯過的內容重複利用。

這樣的方式可以同時控制 API 使用費用和顯示速度。

文章更新後重新翻譯

快取翻譯結果時，需要處理原文章更新的情況。

修正日文文章後，只有翻譯版仍顯示之前的內容就麻煩了。

因此，當原文發生變化時，不使用已保存的翻譯，而是透過 Claude API 重新翻譯。

這部分目前正在實際使用中進行調整。

總結

關於翻譯品質，我目前認為選擇 Claude 是正確的決定，但考慮到成本和精度，當然也存在未來某個時機切換到 Chat GPT 或 Gemini 等模型的可能性。

實驗還在繼續！SEO 相關的詳細內容我會另外寫文章介紹！！