AIで翻訳品質を自動検証する仕組み

往復翻訳（Back-Translation）とは

このブログでは、日本語で書いた記事をAIで英語に翻訳しています。ただ翻訳するだけではなく、翻訳の品質を自動で検証する仕組みを組み込んでいます。

やり方はシンプルです。「日本語 → 英語 → 日本語」と往復翻訳して、元の日本語と戻ってきた日本語を比較します。意味がズレた翻訳は、往復したときに元と大きく異なる文章になって戻ってきます。いわば翻訳の「検算」です。

具体例

例えば、こんな文章を翻訳するとします。

原文: 「この映画は心に響いた」

GPT で翻訳した場合:

英訳: "This movie touched my heart"
再和訳: 「この映画は私の心に触れた」
→ 元の意味がほぼ保持されている ✅

別のモデルで翻訳した場合:

英訳: "This film resonated with me"
再和訳: 「この映画は私の共感を呼んだ」
→ 意味は通じるが、ニュアンスが変わっている ⚠️

この「元の日本語との近さ」を数値化するのが、次に説明する embedding と cosine similarity です。

基本フロー

原文（日本語）をAIの翻訳モデルで英訳
英訳を同じモデルで日本語に戻す（往復翻訳）
元の日本語と戻った日本語を embedding 化（Gemini Embedding）
PostgreSQL の pgvector で cosine similarity を算出
スコアが高い = 意味が保持された良い翻訳

embedding とは

embedding とは、テキストを数百次元の数値ベクトル（数値の配列）に変換することです。意味が近い文章は、ベクトル空間上で近い位置に配置されます。

「この映画は心に響いた」と「この映画は私の心に触れた」は意味が近いので、ベクトルも近くなります。一方、「この映画は私の共感を呼んだ」は少し意味がズレているので、ベクトルの距離も少し離れます。

この距離を cosine similarity（コサイン類似度）で数値化し、PostgreSQL の pgvector 拡張を使って DB 上で自動計算する予定です。

なぜ「正解訳」がいらないのか

ポイントは「正解訳がいらない」ことです。従来の翻訳評価手法は、人間が作った正解訳との比較が前提でした。しかしこの方式は、原文との往復だけで翻訳の品質を判定できます。正解訳を用意するコストがゼロなので、個人ブログでも気軽に導入できます。

従来の翻訳評価手法との比較

手法	年代	概要	正解訳
BLEU	2002〜	単語の並び（n-gram）の一致率で評価	必要
METEOR	2005〜	BLEU の改良。同義語や語幹の一致も考慮	必要
BERTScore	2019〜	BERT の embedding で意味的類似度を評価	必要
COMET	2020〜	ニューラルベースの翻訳評価モデル	必要
LLM-as-Judge	2023〜	GPT-4 等に「この翻訳を採点して」と頼む	不要
本ブログ	—	往復翻訳 + embedding の cosine similarity	不要

本ブログのアプローチは BERTScore に近い発想（embedding で意味の近さを測る）ですが、「正解訳なしで自己完結する」点が異なります。

LLM-as-Judge でよくない？

GPT-4 等に「この翻訳の品質を10点満点で評価して」と頼む LLM-as-Judge という手法があり、こちらも正解訳は不要です。なので「AIに翻訳を採点させればそれで終わりでは？」という気もします。ただし、いくつか懸念があります。

評価基準がブラックボックス — 何をもって「良い翻訳」と判断しているのか、外からはわからない
モデルのバイアス — GPT-4 に評価させると、GPT-4 自身の翻訳を高く評価しがちという報告がある
再現性が低い — 同じ入力でも毎回スコアが微妙に変わる
コストが二重 — 翻訳 + 評価で2回 API を叩く必要がある

一方、往復翻訳 + cosine similarity のアプローチは:

数学的に明確 — ベクトル距離という客観的な指標で評価する
再現性が高い — 同じ embedding からは必ず同じスコアが出る
評価がモデルに依存しない — embedding モデル（物差し）は翻訳モデルとは独立している

もちろん、まだ実際に運用してみないとわからない部分もあります。往復翻訳のスコアが本当に「人間が感じる翻訳の良さ」と相関するのか、実験しながら検証していく予定です。「無料で」とはいきませんが、結局は LLM-as-Judge 使うのが正解、という結論もアリかもしれません。

複数モデル比較

同じ原文を Gemini、Llama（Groq）、DeepSeek などで翻訳して、スコアをランキング化します。日常系ブログの自由な文章では、モデルごとの得意・不得意が顕著に出るのではないかと予想しています。特に DeepSeek は中国語訳には強そうです。完全無料で3モデル比較（Gemini + Llama + DeepSeek）ができるので、まずは色々と実験していきます。

embedding モデルの統一

数値化のための embedding モデルは Gemini に統一しています。翻訳モデル（腕）は複数使い分けますが、embedding モデル（物差し）が違うと公平な比較ができないためです。

異なる embedding モデルは異なるベクトル空間を生成します。例えば GPT の embedding と Gemini の embedding で出したベクトルを比較しても、意味のある結果にはなりません。物差しを揃えることで、初めて「どのモデルの翻訳が一番意味を保持しているか」を公平に評価できます。

翻訳結果の管理

翻訳結果は、公開用・研究用を分けたハイブリッド方式で管理しています。

Supabase（研究用） — 全モデルの翻訳結果とスコアを保存。ダッシュボードで比較・分析
Git（公開用） — ベストスコアの翻訳を posts/en/ に Markdown として自動 commit。読者が見るのはこちら

裏側では複数モデルの翻訳が蓄積されていて、品質の推移やモデル間の比較を追える設計です。

今後の展望

プロンプト調整の自動化（スコアが低い場合に「もっと意訳して」等のフィードバックを自動追加）
記事ジャンル別の分析（映画レビュー vs テック記事でモデルの得意分野が変わるか）
中国語など他言語への展開（DeepSeek が強いかも？）

このブログの技術スタックや設計についてはこちらの記事で紹介しています。