スクレイピングされた翻訳とLLMのコンセンサス、ブラインドベンチマークによる比較

当社のドメイン用語集には、非ネイティブ用語のソースとして2つの可能性がありました。ドメイン所有者が自ら公開している公式の多言語ページをスクレイピングするか、2つのモデルによるLLMコンセンサスパイプラインで翻訳を生成するかです。直感的には、公式ページがグラウンドトゥルースに違いないと思われました。実際に測定したところ、その直感は間違っていました。すべての不一致箇所をブラインド判定した結果、LLMの出力が9対1で勝利したのです。この記事では、実験計画、実際の数値、スクレイピングされた「公式」翻訳がなぜ劣るのか、そして稼働中のサービスを停止させることなくクローラーをどのように廃止したのかを順を追って説明します。

多言語用語集を収集する2つの方法

ドメイン用語集は、ソース言語の概念 (手順名、製品、症状など) を、各ターゲット言語での表示形式に対応付けます。再現率が重要です。用語が欠落していると、後工程の翻訳者は一般的な言葉遣いに頼ってしまい、ドメインのレジスターを失います。

最初のパイプラインでは、ペアになったページをクロールしました。各サイトについて、ソース言語のURLと各翻訳済みURLを登録し、同じバジェットで両サイドをクロールし、埋め込みの類似度でブロックをアライメントし、信頼度の高いアンカーペアを直接用語集に昇格させました。サイトの所有者がおそらく自身の翻訳をレビューしているであろうことから、これは理論上は魅力的です。

2番目のパイプラインは、翻訳済みのページを一切見ません。ソース言語の用語を取得し、2つの異なるLLMプロバイダーに独立して (互いの出力は見ずに) 翻訳させ、2つの回答が正規化後に一致するか、または小さな埋め込み距離内にある場合にのみ、その結果を受け入れます。生き残ったものは、次に逆翻訳ゲートを通過します。すなわち、プレーンなNMTサービスで候補をソース言語に逆翻訳し、正規化された完全一致か、または言語ごとのしきい値を下回るコサイン距離を要求します。その際、第3の判定が解決するグレーゾーンも設けます。

実験: ブラインド判定者と同一条件

パイプラインを公正に比較するということは、ソース以外のすべての変数を取り除くことを意味します。 私たちは、クロールが実際に機能した3つの言語にわたり、クローラーが主要な表示形として採用した136個の用語集エントリをサンプリングしました（それぞれ60、50、26エントリ）。各エントリについて、コンセンサスパイプラインを使用して同一の条件下で翻訳を再生成しました。つまり、本番環境で使用されているのと同じ2つのジェネレーターモデル、まったく同じ本番環境用プロンプト、同じバッチサイズの上限を使用し、比較ではセットアップではなくソースが測定されるようにしました。

次に、2つのことをスコアリングしました。

第一に、一致率です。2モデルのコンセンサスが、それ自体で、正規化（大文字小文字の統一、全角半角の正規化、空白と句読点のクリーンアップ、スクリプトレベルの統一）の後に、スクレイピングされた形をどのくらいの頻度で正確に再現したかです。

第二に、コンセンサスがスクレイピングされた形とは異なるものを生成したすべてのケースについて、ブラインド判定を実施しました。それぞれの不一致は、ソースを隠し、順序を決定論的にシャッフルしたA/Bペアになりました。これにより、判定者は「Aはクローラーを意味する」ということを学習できないようにしました。生成には関与していない2つのより強力なモデルが、用語集への適合性を目的としたルーブリック（これは専門家が実際に使用する用語か、マーケティング的なノイズがないか）を使用して、独立して判定しました。両方の判定者が合意した場合にのみ、勝者としてカウントしました。

数字が語ること

主な結果を、我々が驚いた順に示します。

4分の3のケースで、公式ページにアクセスできない2つの独立したモデルが、サイト所有者が公開した文字列と完全に一致する結果に収束しました。このことだけでも、コンセンサスメカニズムが「公式」の用語を一度も見ることなく復元できることを示しています。

意見が分かれたところで、話は一変します。19件の競合のうち、ブラインド判定者が満場一致でクロールされた形式を支持したのは、わずか1回でした。9回はLLMの形式が支持され、残りの9回は意見が分かれるか、同等に許容可能と判断されました。スクレイピング側は引き分けただけでなく、競合した領域で敗北したのです。

カバレッジが決定打となりました。クロールパイプラインは、サイトが実際に翻訳されたページを公開している場合にのみ機能します。我々のドメインでは、これは十分なボリュームのある3言語と、ほとんど何もない8言語を意味しました。コンセンサスパイプラインは、リストにあるすべての言語に対して生成します。測定時点で、長年のクロールよりも16.6倍多くの承認済みプライマリエントリーを生成していました。

なぜ公式ページは負けるのか：ノイズは構造的なものである

19件の不一致を一つずつ確認したところ、敗因が判明しました。クロールされた形式は、間違った翻訳ではありませんでした。多くの場合、それらはそもそも翻訳ですらありませんでした：

• 用語としてキャプチャされた言語コード：「body shape」の用語集エントリの表示形式は、言語スイッチャーからスクレイピングされたリテラル文字列「en」でした。
• メニューの連結：隣接する2つのナビゲーション項目が1つの文字列に融合し、実在しない、もっともらしい複合語を生成していました。
• プロモーション情報の算術的結合：「300ショット」のような数量を表す接頭辞が、料金表が見出しの隣に配置されているために施術名に付着していました。
• 専門用語ではなく、マーケティングコピーに属する、括弧書きの補足や成分の接尾辞。

重要なのは、これがクリーンアップ後も残存したという点です。私たちは数ヶ月前に、クロールされたデータに対して専用のノイズ除去パスを実行し、汚染された数百の行を削除していました。上記の例は、その作業の後にも残ったものです。クロールノイズは構造的なものです。なぜなら、ページレイアウトがそれを生成し続けるからです。一方で、生成パイプラインはそもそもナビゲーションバーを出力することはありません。

正直な注意点が1つあります。クロールが勝った唯一のケースは、ブランド化されたデバイスの、現地で好まれる音訳でした。これは、マーケティングチームが決定し、モデルが推測できない類いのものです。もしあなたの用語集が、公式な現地のスペルを持つブランドの音訳で占められている場合は、まさにそれらのエントリのために手動オーバーライド層を維持してください。私たちのものにはそれがあり、移行の際に維持されました。

クローラーに取って代わったコンセンサスゲート

後継のパイプラインは、説明も実行も安価です：

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

実際に重要だった設計上の選択肢：

• 2つのジェネレーターは独立して実行され、互いの出力を決して見ません。 コピーによる合意は合意ではありません。
• 比較前の正規化は、意味のない差異（全角/半角、大文字/小文字、空白、書記体系レベルの等価性）を吸収します。これがないと、一致率が低下し、誤った不一致のコストを支払うことになります。
• 逆翻訳ゲートは、自信を持って生成された無意味な出力を捕捉します。2つのモデルが流暢だが誤ったレンダリングに合意することがあります。プレーンなNMTサービスを介したラウンドトリップは、誤ったレンダリングがソース用語に戻らないため、それを明らかにします。
• ドロップは試行カウンターと共に記録されます。3回失敗したスロットは母集団から除外されるため、夜間バッチが同じ困難なケースを永久に再議論して予算を浪費することはありません。後でジェネレーターモデルをアップグレードした際、最後の失敗が不一致または逆翻訳の失敗であったスロットのみを選択的にリセットし、「両方のモデルがノイズと判断」および「重複」のドロップはクローズしたままにしました。アップグレードされたモデルは、そのリセットから最初のパスでさらに297エントリを回復しました。

ライブサービス下でのスクレイパーの廃止

測定によって私たちは決断を下しました。それでも移行は、用語集をリアルタイムで読み取るサービスを破壊することを避ける必要がありました。最終的に、個々のステップよりも操作の順序が重要になりました:

1. まず、クローラーを夜間スケジュールから削除するコードをシップしてデプロイしてください。古いクローラーがまだスケジュールされている間にデータを削除すると、次の実行で、削除したばかりのすべてが再スクレイピングされ、再プロモートされてしまいます。

2. 再生成する前に、バッチワーカー上のモデル名の環境変数を新しいジェネレーターに向けてください。そうしないと、夜間ジョブが古いモデルで欠落しているスロットを黙って埋め戻してしまいます。ここで恐れるべき障害モードは、デフォルトモデルへのサイレントなフォールバックであるため、私たちは最初の小さなバッチの後、監査ログに記録されたモデルタグを検証しました。

3. 削除しようとしているすべての行について、外部キーのカスケードによって一緒に削除される行も含め、データベースレベルのバックアップを取得してください。プライマリテーブルのCSVは、ロールバック計画にはなりません。

4. ロックタイムアウトを設定してバッチで削除し、次に再生成し、その後、リグレッションベンチマークを再実行してください。私たちのベンチマークは、移行前の値（ペアヒット率0.88）とまったく同じ値を維持しました。この数値によって、私たちは移行が完了したと判断することができました。

FAQ

2つではなく、1つの強力なモデルだけを使用しないのはなぜですか？ 単一のモデルには、「推測している」という内部シグナルがありません。2つの独立したモデルは、推測が発生するエントリーで正確に不一致となり、その不一致がフィルターとなります。我々のデータでは、不一致を破棄し、残りをゲートすることで、1パスあたり約40%の候補をスキップするコストで、コンタミネーションを実質的にゼロに削減しました。これらの候補のほとんどは、後の試行で成功します。

これは用語集以外にも一般化できますか？ このパターン（独立した二重生成、正規化された一致、ラウンドトリップ検証、有界リトライ）は、出力が短く検証可能な文字列であるあらゆるタスクに適合します。例えば、エンティティ名、コード識別子、カテゴリラベルなどです。出力が長い自由形式のテキストである場合は、正規化後の一致が意味をなさなくなるため、このパターンはうまく適合しません。

スクレイピングにはまだ価値がありますか？ はい、ソース言語側については価値があります。公式ページは、あるドメインにどのような概念が存在するかを知るための良い情報源であり続けます。我々の代替システムも、新しい用語を発見するためにソース言語のページをクロールします。我々がやめたのは、それらのページの翻訳された側をグラウンドトゥルースとして信頼することです。

サイトが公開しなかった言語についてはどうですか？ それが決定的な論拠でした。スクレイパーは、サイトが公開していないものを生成することはできません。我々の11のターゲット言語のうち8つは、クロール可能なカバレッジがほぼゼロでした。そのため、選択肢は「スクレイピングされた品質か、生成された品質か」ではなく、「生成されたカバレッジか、何もないか」でした。