Gemma 3 270M で「かな→漢字」IME向けモデルを開発してみた：SFT / DPO / GRPO 検証まとめ

iOS 上で動く 小型 LLM（270M）で、日本語 IME の かな→漢字変換候補を list 形式で返す用途を狙って、学習手法を変えた3系統（SFT / DPO / GRPO）＋ iOS 向け GGUF 配布までを検証した記録です。

公開モデル（Hugging Face）

• SFT（Full Fine-tune）: katsukiono/gemma3-270m-kana-fullft (Hugging Face)
• DPO: katsukiono/gemma3-270m-kana-dpo (Hugging Face)
• GRPO（実験）: katsukiono/gemma3-270m-kana-grpo (Hugging Face)
• DPO の GGUF 版: katsukiono/gemma3-270m-kana-dpo-gguf (Hugging Face)

---

1. 目的と前提

目的

• 日本語IME（かな→漢字変換）用途を想定し、かな入力から複数の変換候補を list 形式で生成する小型モデルを構築・評価する。

前提条件

• モデルサイズ制約：iOS 実行を想定（小型モデル必須）

• 形式制約：

  • 出力は必ず list 形式：[候補1, 候補2, …]
  • 単語のみ（説明文不可）

• 評価軸：

  • 形式維持
  • top1 正解率
  • 重複率
  • 候補のバラエティ
  • 実行速度（iOS / GGUF）

2. 使用データ

データセット

• katsukiono/kana-kanji-pairs（Mozc 辞書由来の「かな→漢字候補」ペア）

データの性質

• カラムは input（かな）, output（候補list）, count（候補数）で、output は最大10件の list になっている
• 規模：default/train で 約 754k rows
• ライセンス：BSD-3-Clause

学習時フィルタ

• 主に count >= 5
• 出力候補数は n = min(count, 10)

3. ベースモデル

• Base：google/gemma-3-270m-it
• Hugging Face 上で Gemma を扱うには Google の利用条件への同意が必要（ログインして承諾） (Hugging Face)

4. 固定プロンプトと出力仕様

各モデルの固定プロンプトは概ね同一で、list形式・単語のみを強制します。

推奨推論

• do_sample: false, temperature: 0
• stop string: ]

5. 学習手法別の観測結果

比較表

手法	形式安定	top1正解率	重複	バラエティ	コメント
SFT（Full FT）	安定	約0.30	高め	低め	データ分布に強く引きずられ、系列が偏りやすい
DPO	安定	約0.30	低下	改善	「明らかに悪い出力」は減るが、辞書語へ戻す力は限定的
GRPO（RL系）	不安定	—	—	—	フォーマット逸脱・stop不発などで実運用不可

---

5.1 SFT（Full Fine-Tuning）

設定

• Full parameter fine-tuning
• 固定プロンプトによる教師あり学習（SFT）

観測結果

• 出力形式：安定
• top1 正解率：約 0.30
• 重複率：高め
• 特定の漢字系列に候補が集中しやすい

例（かんじ）

• 出力が「勘◯」系列に寄る：['感じ', '勘地', '勘司', '勘治', '勘次', ...]

結論

• 形式維持は達成
• 候補の「質」がデータ分布に強く依存し、一般的な辞書語（幹事・漢字など）が上位に来にくいケースが出る

---

5.2 DPO（Direct Preference Optimization）

設定

• SFTモデルを初期値として DPO
• chosen：元データの候補列
• rejected：SFTモデルの生成結果（chosen が好まれるよう最適化）

観測結果

• 出力形式：安定
• top1 正解率：SFTと同等（約 0.30）
• 重複率：低下
• 候補のバラエティ：改善

例（かんじ）

• ['感じ', '勘次', '勘司', '官司', '勘治', '官二', ...]

結論

• DPOで「明らかに悪い出力」は減る
• ただし 辞書的に正しい語へ戻す力は限定的
• 「勘 → 官」など 別系列へ逃げる挙動を確認(Hugging Face)

---

5.3 GRPO

設定

• SFT / DPOモデルを起点に GRPO（実験）
• 報酬関数：形式、gold一致、重複率など

観測結果

• 出力形式が不安定（[ を出さず ( を出すなどフォーマット逸脱）
• stop string が効かず prompt 再生成が発生
• 実運用レベルでは使用不可

結論

• 小型モデル × 日本語 × 厳密フォーマット条件だと GRPO が不安定
• 調整コストに対するリターンが低い（少なくとも今回の条件では）

6. 推論・評価で効いた重要知見

形式抽出（実運用）

• 生成結果から 最初の [...] だけを抽出して使う
• それ以外は破棄すると安定

---

7. GGUF 変換と iOS 実行結果（DPOモデル）

公開GGUF（DPO）

• katsukiono/gemma3-270m-kana-dpo-gguf

• 提供ファイル：

  • ...-f16.gguf（FP16）
  • ...-q4_k_m.gguf（Q4_K_M：モバイル推奨）

• 参考サイズ（カード記載）：

  • Q4_K_M：253 MB
  • F16：543 MB

実行環境

• iOS

実測性能

• 12 ms / token
• 約 80.7 tokens / sec
• TTFT 約 54 ms

機能面評価

• 形式維持：問題なし
• 重複：低い
• バラエティ：十分
• 実行速度：実用レベルを大きく超過

8. 総合評価

達成できた点

• iOS上で高速に動作する
• list形式出力が安定
• 候補の多様性を確保（特にDPO）
• GGUF化・配布が可能（Q4_K_M がモバイル向けとして提示） (Hugging Face)

未解決の点

• 候補の「辞書的妥当性」

  • 幹事 / 漢字 / 監事 などが上位に来ないケースが残る

付録

• SFT（fullft）：SFTで list 形式の候補出力を狙ったモデル (Hugging Face)
• DPO：SFT起点に、形式安定・重複抑制を “好み学習” で強化 (Hugging Face)
• GRPO：RL系での最適化を試みた実験モデル（実運用は SFT/DPO 推奨） (Hugging Face)
• GGUF：DPOモデルを llama.cpp で変換した配布形態（Q4_K_M推奨） (Hugging Face)