網路爬取翻譯對比 LLM 共識，一項盲目基準測試

我們的領域詞彙表有兩種非原生術語的可能來源：爬取領域擁有者自行發布的官方多語言頁面，或是透過雙模型 LLM 共識管線生成翻譯。直覺上，官方頁面必定是真實標竿。我們實際測量後，發現這個直覺是錯的：在針對每項差異的盲測中，LLM 的輸出以 9 比 1 的案例勝出。這篇文章將逐步說明實驗設計、實際數據、為何爬取來的「官方」翻譯會輸，以及我們如何在不中斷線上服務的情況下淘汰爬蟲程式。

取得多語言詞彙表的兩種方法

領域詞彙表會將來源語言的概念（例如程序名稱、產品、症狀）對應到各個目標語言的顯示形式。完整性至關重要：當詞彙表中缺少某個詞彙時，下游的翻譯人員會退而使用通用措辭，從而失去該領域的專業語域。

第一種流程是爬取成對的頁面。針對每個網站，我們註冊其來源語言 URL 和每個翻譯後的 URL，以相同的預算爬取雙方頁面，利用嵌入相似度對齊區塊，並將高信度的錨點對直接提升至詞彙表中。這個方法在理論上很有吸引力，因為網站擁有者想必已經審核過他們自己的翻譯。

第二種流程則完全不看翻譯後的頁面。它會取來源語言的詞彙，要求兩個不同的 LLM 供應商獨立進行翻譯（彼此看不到對方的輸出），並且只有在兩個答案經過正規化後一致，或是在很小的嵌入距離內時，才會接受該結果。通過篩選的項目接著會經過一個反向翻譯關卡：使用一個普通的 NMT 服務將候選詞翻譯回來源語言，並要求結果必須是精確的正規化匹配，或是餘弦距離低於每個語言設定的閾值，而落在灰色地帶的項目則由第三方判斷來解決。

實驗：盲審與相同條件

要公平地比較各個管線，就必須移除來源以外的所有變數。 我們抽樣了 136 個詞彙表條目，這些條目是爬蟲程式在三種實際成功爬取的語言中，提升為主要顯示形式的 (分別為 60、50 和 26 個條目)。我們在相同條件下，為每個條目使用共識管線重新生成翻譯：使用與生產環境中相同的兩個生成模型、完全相同的生產提示，以及相同的批次大小上限，如此一來，比較的便是來源，而非設定。

接著，我們對兩件事進行評分。

首先是「一致率」：雙模型共識本身，在經過正規化 (大小寫摺疊、全半形正規化、空白與標點符號清理、腳本層級的統一) 後，有多常能完全重現爬取到的形式？

其次，對於共識結果與爬取形式不同的每個案例，我們都進行了盲審。每個衝突的案例都會成為一個 A/B 組，來源會被隱藏，順序會以確定性的方式隨機排列，如此一來，評審員就無法得知「A 代表爬蟲程式的結果」。兩個未參與生成的、更強的模型，根據旨在評估詞彙表適用性的標準獨立進行評審：這是否為專業人士實際會使用、且沒有行銷雜訊的術語？只有當兩位評審員都同意時，我們才判定勝負。

數據告訴我們的事

重點結果，依據讓我們驚訝的程度排序：

在四分之三的情況下，兩個無法存取官方頁面的獨立模型，得出了與網站所有者所發布字串完全相同的結果。 僅此一點就說明了，共識機制能夠在從未見過「官方」術語的情況下將其還原。

意見不合之處，則是故事翻轉的地方。在 19 項衝突中，盲測評審只有一次一致偏好抓取的形式。有九次他們偏好 LLM 的形式，而其餘九次則是意見分歧或被判定為同樣可接受。抓取方不僅僅是平手；它在有爭議的部分落敗了。

覆蓋率是決定的關鍵。抓取流程只有在網站實際發布了翻譯頁面的情況下才能運作，這在我們的領域中意味著，有三種語言有實際的量，而八種語言幾乎沒有內容。共識流程能為列表上的每種語言生成內容。在測量當下，它產生的已接受主要條目，是多年抓取成果的 16.6 倍。

官方頁面為何會輸：雜訊是結構性的

逐一閱讀這 19 個衝突點後，便解釋了失敗的原因。抓取到的形式並非錯誤的翻譯。在許多情況下，它們根本就不是翻譯：

• 語言代碼被當成術語擷取：詞彙庫中「body shape」的條目，其顯示形式是從語言切換器抓取到的字串「en」。
• 選單串接：兩個相鄰的導覽項目融合成一個字串，產生了一個看似合理但實際不存在的複合詞。
• 促銷算術：「300 shots」這類數量前綴被加到療程名稱上，因為價目表就放在標題旁邊。
• 屬於行銷文案而非術語的括號補充說明和成分後綴。

重點是：這些東西在清理後仍然存在。幾個月前，我們已經對抓取到的資料進行過專門的雜訊清除程序，並移除了數百個受污染的資料列。上述範例就是那次清理後所剩下的東西。抓取雜訊是結構性的，因為頁面排版會不斷產生它，而生成管線從一開始就不會產生導覽列。

有一個必須坦承的例外情況。抓取唯一勝出的案例，是一個品牌裝置的當地慣用音譯，這類東西是由行銷團隊決定，模型無法推斷出來的。如果您的詞彙庫主要由具有官方本地拼法的品牌音譯詞所組成，請為這些特定條目保留一個手動覆寫層。我們的系統就有一個，而且在遷移過程中也保留了下來。

取代爬蟲的共識閘門

此替代管線的說明與執行成本皆相當低廉：

term -> generator A (model 1)   -> agree after normalization? -> accept
     -> generator B (model 2)   -> else: embedding distance <= 0.20? -> accept
accepted -> back-translate -> exact match OR cosine <= threshold(lang)
         -> gray zone (<= 0.50) -> single judge yes/no -> insert or drop

在實務上很重要的設計抉擇：

• 兩個生成器獨立運行，且絕不會看到彼此的輸出。 透過複製達成的共識，並非真正的共識。
• 比較前的正規化會吸收無意義的差異：全形半形、大小寫、空白字元、腳本層級的等價形式。若沒有正規化，一致率會下降，且您會為錯誤的不一致付出代價。
• 反向翻譯的關卡能捕捉到看似可信的無稽之談。兩個模型可能會對一個流暢但錯誤的呈現結果達成共識；透過一個普通的 NMT 服務進行來回翻譯便能揭露此問題，因為錯誤的呈現結果不會還原回來源詞彙。
• 捨棄的項目會用一個嘗試計數器來記錄。一個失敗三次的欄位就會離開群體，這樣夜間批次處理就不會耗費預算去永無止盡地重複處理同一個困難案例。當我們後來升級生成器模型時，我們選擇性地只重設那些最後一次失敗原因是不一致或反向翻譯失誤的欄位，而讓「兩個模型都判定為雜訊」和「重複」而被捨棄的項目保持關閉狀態。升級後的模型在第一次處理重設項目時，就找回了 297 個額外的條目。

在線上服務下汰除爬蟲

測量結果讓我們做出了決定；遷移過程仍需避免中斷一個會即時讀取詞彙表的服務。結果，操作的順序遠比任何單一步驟都來得重要：

1. 首先，發布並部署將爬蟲從夜間排程中移除的程式碼。如果你在舊爬蟲仍在排程中時刪除資料，下一次執行時它會樂意地重新抓取並重新提升你剛移除的所有東西。
2. 在重新生成之前，將批次工作單元上的模型名稱環境變數指向新的生成器，否則夜間作業將會悄悄地用舊模型填補遺失的位置。在此，靜默回退到預設模型是需要擔心的失敗模式，因此我們在第一個小批次處理後，驗證了稽核日誌中記錄的模型標籤。
3. 對你即將刪除的每一列資料進行資料庫層級的備份，包括那些會因外鍵級聯而一併被刪除的資料列。主資料表的 CSV 檔並不是一個回滾計畫。
4. 使用鎖定逾時分批刪除，然後重新生成，再重新執行你的回歸基準測試。我們的測試結果完全維持在遷移前的值（配對命中率為 0.88），這個數字讓我們得以宣告遷移完成。

常見問答

為何不只用一個強大的模型，而要用兩個？ 單一模型沒有「我正在猜測」的內部訊號。兩個獨立的模型恰好會在發生猜測的條目上產生分歧，而這種分歧就是過濾器。在我們的資料中，捨棄分歧並篩選其餘部分，能將污染降至幾乎為零，代價是每次傳遞約略跳過 40% 的候選項目，而其中大部分會在稍後的嘗試中成功。

這能推廣到詞彙表以外的領域嗎？ 此模式（獨立雙重生成、正規化一致性、來回驗證、有限重試）適用於任何輸出為簡短、可檢查字串的任務：實體名稱、程式碼識別碼、類別標籤。它不適用於輸出為長篇自由文本的情況，因為正規化後的一致性將失去意義。

抓取資料是否仍然值得？ 是的，對於來源語言端而言。官方頁面仍然是了解某個領域存在哪些概念的良好來源，而我們的替代方案仍會抓取來源語言的頁面以發現新術語。我們所淘汰的是將那些頁面的翻譯版本視為真理的做法。

對於網站從未發布過的語言該怎麼辦？ 那正是決定性的論點。抓取工具無法產生網站未發布的內容。在我們的十一個目標語言中，有八個的可抓取覆蓋率近乎為零，因此選擇並非「抓取品質 vs 生成品質」，而是「生成覆蓋率 vs 零覆蓋率」。