Local LLM開発日誌 02

2026年3月11日

少し時間が経ちました。プロジェクトや学業準備で忙しく、文章を書けずにいましたが、ようやく書いています。前の記事ではLocal LLMを活用したブログ記事翻訳機能の開発を始めました。今回はアーキテクチャ再設計について扱います。

前の記事 Local LLM開発日誌 01 では、ローカルLLMを活用したブログ記事翻訳機能の開発を始めました。

今回の記事ではアーキテクチャ再設計について扱います。

アーキテクチャ再設計

まず、個人ブログに書く記事はすべてMDXまたはMarkdown形式でローカル作成し、それをGitHubへpushするとVercelが自動でビルド・デプロイする形で運用しています。

自動翻訳のために思いついた方法は次の2つでした。

記事を書いてpushする前にローカルで翻訳を回し、翻訳した記事まで検収して一緒にpushする。
韓国語で書かれた投稿をGitHubへpushすると、それを別のプログラムが検知して翻訳する。その後、翻訳内容を検収し、en/jp言語としてそれぞれpushする。

効率的な方法は当然1番です。しかし、ローカルで翻訳する場合、翻訳中は自分のノートPCを使えないため、クラウドGPUを活用する方法を選びました。

念のためGTX1070TIで回そうとしてAIに聞いたところ、おすすめはしないとのことでした。

Docker Imageを作り、Hubへ上げ、RunPodまで使って翻訳をテストしましたが、結果が変でした。
そこで再度ローカルモデルでテストし、翻訳がうまくいくことを確認したあと、その環境のままImageを作って再デプロイしました。
ただ、記事は多くても週3本程度で、書かない週もあります。なら一度ローカルで回しながら待つほうが良いのではないかとも思いました。
もう少し悩んで決める必要がありそうです。ひとまずRunPodに10ドル入れたところ、追加で15ドルもらい、25ドルあります。ただ、記事を1本回しただけで0.09ドルかかりました。KR -> EN翻訳作業で、韓国ウォンに換算すると約130ウォン程度ですが、60秒で翻訳できました。翻訳されなかったコードコメント部分と、勝手に付け加えた部分を除けば翻訳は悪くありませんでしたが、スペースやインデントの問題がありました。

gemma4:latestモデルを使用しました。確かにうまくできました。しかし、pythonのようなコードブロックでは、という文字自体が消えることがありました。内部コードコメントはうまく翻訳できていたため、コードブロック部分だけを確実にPromptingすればよさそうです。

開発中、RunPodとローカルの両方で翻訳精度を上げようとしましたが、勉強してみると、この方向性で翻訳精度を上げるのは簡単ではなさそうでした。時間がかかっても、読んでみる価値のある論文や資料を探しながら、翻訳精度を上げる方法について考えてみようと思います。

2026年04月13日

ほぼ1か月ぶりです。他のプロジェクト、ポートフォリオ整理、学校の勉強で忙しく、途中途中で文章を埋めることができませんでした。翻訳システムを見直すことになったのは、ポートフォリオを作りながら足りない部分が多く目についたからです。2週間ほど前からずっと悩み、考えていました。

まず、読んだ論文や資料は韓国語-日本語翻訳について話しているものと、一般的に適用できる方法論に関する論文・資料でした。翻訳品質を決定する要素についても調べました。詳しい内容は別の記事で扱います。以下では簡単に書き、該当リンクを置いておきます。

翻訳の品質

まず、翻訳品質を扱う技術から紹介します。

n-gram一致度: 文をn個の単語単位に分け、2つの文で同じ断片がどれだけ重なるかを見る方法。

BLEU: 機械翻訳評価の代表的指標で、翻訳結果と参照文のn-gram一致度に基づいて点数を計算します。主に表面的なテキスト類似性を測定します。
ROUGE: もともとはテキスト要約評価のために開発された指標で、翻訳にも使われますが、BLEUより要約分野で多く活用されます。n-gramベース類似度を測定します。
METEOR: BLEUの限界を補うために提案された指標で、単語一致だけでなく語幹(stem)、同義語、意味的類似性を反映し、より精密な評価を行います。
BERTScore: BERTのような事前学習言語モデルを活用し、単語の意味をベクトルで比較することで文間の意味的類似性を測定する指標です。
COMET: 単純な類似度計算ではなく、人間評価データを基に学習された機械翻訳品質予測モデルです。意味保存、文脈、自然さなどを総合的に評価でき、近年最も強力な指標の一つとして使われています。

用語制約ベース翻訳 (Lexically Constrained Translation)

一般的なニューラル機械翻訳(NMT)は文を自由に生成するため、同じ用語が文書ごとに違って翻訳されたり、固有名詞が変形されたりする問題が発生します。

これを解決するため、研究では**Lexically Constrained Translation（用語制約ベース翻訳）**という方法を提案しています。

代表的にHokamp & Liu (ACL 2017)はGrid Beam Searchを通じて、翻訳過程で特定単語を必ず含めるよう強制できることを示し、この方法が翻訳品質を有意に向上させることを実験的に検証しました。

その後、Post & Vilar (NAACL 2018)はこれを改善し、constraint数に関係なく効率的に適用できる方法を提案し、実環境でも使える水準の性能と速度を確保しました。

2020年の研究では、Transformerベースモデルでもこのような制約を適用でき、特定用語を100%維持しながら全体翻訳品質も向上できることが確認されました。

[Lexically Constrained Neural Machine Translation with Levenshtein Transformer: https://aclanthology.org/2020.acl-main.325/]

モデル選択と適用

本プロジェクトでは、Qwen3-14Bモデルを翻訳モデルとして使用しました。オープンソースモデルの中で、韓国語-日本語間の翻訳性能が最も良いと出ていたモデルでした。

Qwen3-14BはTransformerアーキテクチャベースの大規模言語モデルで、Self-Attentionメカニズムを通じて文脈を理解し、自然な文を生成できます。この構造は翻訳作業でも高い性能を示し、特に多言語処理に強みがあります。同じ用語が文書ごとに異なって翻訳される、固有名詞が変形される、文脈によって翻訳が変わるなど、既存翻訳システムで発生する問題を解決するため、Qwen3-14BモデルにLexically Constrained Translation方式を適用しました。

手作業

まず、以前作ったglossary_backupから翻訳が変だったり間違っていたりするものをすべて除去し、良い翻訳だけを残す作業をしました。そして、モデルへ確実なデータを提供するためJSON形式で整理し、ルールを決めました。

    {
      "ko": "Baekjoon",
      "canonical": "Baekjoon",
      "en": "Baekjoon",
      "jp": "Baekjoon",
      "type": "proper_noun",
      "translate": false,
      "priority": "required",
      "status": "approved"
    }

Hun-Bot