通販コールセンターチャットボットの品質向上を目指し、DPO（Direct Preference Optimization）による訓練を実施しました。8回の試行を通じて得られた知見をまとめます。
目標
- 丁寧で具体的な応対を学習する
- Chosen（良い応答）の確率を上げる
- Rejected（悪い応答）の確率を下げる
- 成功率70%以上を目指す
試行サマリー
データ構造の最適化フェーズ（試行1-4）
試行1: 学習率ミス（5e-6 → 5e-5に修正必要）- 結果: Chosen -10.10, Rejected -3.12, 成功率0%
- 結果: Chosen -10.02, Rejected -6.45, 成功率0%
- 問題点: Rejectedが良すぎる（10-20ワード）
- 結果: Chosen -9.85, Rejected -3.39, 成功率0%
- 問題点: Chosenが長すぎる（100-200トークン）
- 結果: Chosen -4.70, Rejected -3.20, 成功率0%
- 改善あり（-9.85→-4.70）だが依然失敗
エポック数調整フェーズ（試行5）
試行5: エポック数大幅増加- モデル: rinna/japanese-gpt2-medium (337M)
- 設定: SFT 20エポック、DPO 10エポック
- SFT結果: loss 2.04→1.25（38%削減）
- DPO結果: loss 0.70→0.08（89%削減）
- 検証結果: Chosen -8.30, Rejected -4.97, 成功率12.5% ✅
- 問題: DPO loss 0.08は過学習の兆候
モデルサイズ変更フェーズ（試行6）
試行6: 4倍大きなモデルで試行- モデル: llm-jp/llm-jp-1.3b-v1.0（1.3B、rinnaの4倍）
- 結果: Chosen -29.85, Rejected -30.84, 成功率0% ❌
- 結論: アーキテクチャが異なると悪化
成功事例分析とデータ改善（試行7-8）
成功事例の分析結果:- 過去に成功した52ペア（100%成功）を分析
- Chosen応答が平均102.2文字（我々は59.4文字しかなかった）
- 文体が説明的・教育的（我々は手続き的すぎた）
- データ: v2（Chosen 110文字、Rejected 3文字）
- DPO: エポック8で早期停止（loss 0.09）
- 結果: Chosen -24.12, Rejected -4.28, 成功率0% ❌
- 問題: データ延長で逆に悪化
- モデル: rinna/japanese-gpt-1b（1.3B、rinnaアーキテクチャ維持）
- データ: v2（Chosen 110文字）
- SFT: loss 1.01（健全範囲）
- DPO: エポック4で早期停止（loss 0.04）
- 結果: Chosen -0.36, Rejected +0.22, 成功率7.5% ❌
- 問題: Rejected変化が正の値（完全に逆方向）
全試行比較表
| 試行 | モデル | データ | Chosen変化 | Rejected変化 | 成功率 | 判定 | |------|--------|--------|-----------|-------------|--------|------| | 1-4 | rinna 337M | 最適化中 | -10.10〜-4.70 | -3.12〜-6.45 | 0% | ❌ | | 5 | rinna 337M | v1 (59文字) | -8.30 | -4.97 | 12.5% | 部分成功 | | 6 | llm-jp 1.3B | v1 (59文字) | -29.85 | -30.84 | 0% | ❌ | | 7 | rinna 337M | v2 (110文字) | -24.12 | -4.28 | 0% | ❌ | | 8 | rinna 1.3B | v2 (110文字) | -0.36 | +0.22 | 7.5% | ❌ |
学んだこと
1. データ品質の重要性
- Rejected応答を極端に短く（1-3ワード）: 必須
- Chosenの長さは短すぎても長すぎてもダメ
- 成功事例との比較分析が重要
2. モデルサイズの影響
- 単純に大きくすれば良いわけではない
- アーキテクチャの相性が重要（llm-jpで悪化）
- rinnaアーキテクチャを4倍にしても改善せず
3. 過学習の検出と対策
- 早期停止機能を実装（SFT < 0.8, DPO < 0.1）
- DPO lossが0.1以下で自動停止
- コスト削減にも貢献
4. エポック数の効果
- SFT 5→20エポック: 効果あり
- DPO 3→10エポック: 過学習リスク
- 最良結果（試行5）: 12.5%成功率
根本的な課題
8回の試行を経て、以下の根本的課題が浮き彫りに：
1. データ構造の問題: プロンプト形式の見直しが必要 2. タスクの難易度: 通販コールセンターの応対品質学習は難しい 3. 評価指標: 対数確率変化だけでは不十分かも 4. 手法の限界: DPO以外のRLHF手法の検討が必要
次回への展望
1. 成功事例（52ペア100%）の詳細分析 - データ構造、プロンプト形式の違いを特定 - 成功パターンに合わせたデータ再作成
2. プロンプトエンジニアリング - Q&A形式など構造変更 - システムプロンプトの最適化
3. ハイパーパラメータ調整 - Beta値の最適化（現在0.1） - 学習率スケジューリング
4. 別アプローチの検討 - PPO（Proximal Policy Optimization） - SLiC（Sequence Likelihood Calibration） - KTO（Kahneman-Tversky Optimization）
技術スタック
- モデル: rinna/japanese-gpt2-medium (337M), rinna/japanese-gpt-1b (1.3B), llm-jp/llm-jp-1.3b-v1.0
- 手法: SFT → DPO（2段階アプローチ）
- 効率化: LoRA（r=16, alpha=32）
- 環境: Lambda Labs GPU（GH200 480GB）
- コスト: 約$1.50
まとめ
8回の試行で最良12.5%の成功率に留まりましたが、多くの知見を得られました。DPOによる品質向上は想像以上に難しく、データ設計とプロンプトエンジニアリングの重要性を痛感しました。
次回は根本的なアプローチ変更を検討し、再挑戦します。
---
バックアップ: 全データをローカルに保存済み（37MB） ステータス: 一旦保留、次回はデータ・手法の根本的見直しから再開
