はじめに
DPO（Direct Preference Optimization）という技術を使って、ECサイトのコールセンター向けAIチャットボットを作ろうとした3日間の記録です。結論から言うと、うまくいきませんでした。でも、その過程で多くのことを学んだので、記録として残しておきます。
前提：成功していたこと（試行18）
実は、その直前に汎用的なQ&Aでは成功していました：
- モデル: rinna/japanese-gpt2-small (110M parameters)
- データ: 日本語の一般的な質問12ペア
- 結果: 成功率75.0% ✅
- 例: 「今日の天気は？」→ 詳しい回答 vs 短い回答
この成功体験があったので、「ECコールセンターでもいけるだろう」と思ったのが、そもそもの始まりでした。
挑戦1日目：データ量の問題？（試行19）
やったこと
- ECコールセンター向けデータ12ペアで訓練
- 例: 「この商品の在庫状況を教えてください」→ 丁寧な回答 vs 短い回答
結果
- Chosen変化: -25.46 ❌（本来は正の値であるべき）
- Rejected変化: -2.78 ✅
- 成功率: 0.0% ❌
仮説
「データが多すぎるのでは？」試行18は12ペア、でもECデータは最初40ペアあった。削減したけど、それでも何か違うのかも。挑戦2日目午前：データ品質の改善（試行20）
発見した4つの問題点
データを詳しく分析したところ、試行18の成功データとの違いが見えてきました：
#### 1. プロンプト構造の違い
- 試行18（成功）: 92%が疑問文（「〜ですか？」）
- ECデータ（失敗）: 33%しか疑問文がない
#### 2. 応答の複雑さ
- 試行18: 平均88文字、シンプルな説明
- ECデータ: 平均121文字、謝罪+手順+敬語の複合構造
#### 3. ドメイン特異性
- 試行18: 一般語彙（天気、プログラミング、レストラン）
- ECデータ: 業界用語満載（在庫、発送、返品、交換、サイズ表）
#### 4. 選好基準の抽象性
- 試行18: 「情報量の多い/少ない」という明確な基準
- ECデータ: 「丁寧さ」「共感」という抽象的な基準
改善内容（v3データ作成）
1. ✅ プロンプトを100%疑問文化 2. ✅ Chosen応答を121文字→80文字に簡潔化 3. ✅ 感情的要素を削除（謝罪、共感の表現を除去） 4. ✅ 選好基準を「情報量の違い」に統一結果
- Chosen変化: -22.65 ❌（+2.81改善したが、依然として負）
- 成功率: 0.0% ❌
挑戦2日目午後：ドメインの一般化（試行21）
やったこと
「ECドメイン語彙そのものが問題では？」と考え、専門用語を一般語彙に置き換え：- 「在庫状況」→「状況」
- 「配送」→「お届け」「送付」
- 「返品」→「返却」
- 「サイズ交換」→「サイズ変更」
結果
- Chosen変化: -21.88 ❌（+0.77改善、でも焼け石に水）
- 成功率: 0.0% ❌
重要な気づき
3つの改善を試した結果： 1. データ量削減: 効果なし 2. データ品質改善: わずかな改善（+2.81） 3. ドメイン一般化: わずかな改善（+0.77）
総合改善: -25.46 → -21.88（+3.58改善）でも、試行18の成功（Chosen +0.69）とは22.57ポイントの差がある。
結論: 小型モデル（110M-337M parameters）では、ECドメイン特化タスクは無理。挑戦3日目：最後の賭け - 大型モデル（試行22）
戦略転換
「モデルが小さすぎるのでは？」- 試行18-21: rinna（110M-337M parameters）
- 試行22: llm-jp-3-13b（13B parameters、rinnaの39倍！）
遭遇した問題1：LoRAモジュール名エラー
エラー:ValueError: Target modules {'c_attn'} not found
原因:
- rinnaモデル: GPT-2系アーキテクチャ →
c_attnモジュール - llm-jp-3-13b: LLaMA系アーキテクチャ →
q_proj,v_projモジュール
if "llm-jp" or "llama" in model_name:
→ q_proj, v_projを使用
else:
→ c_attnを使用遭遇した問題2：DPO訓練クラッシュ（致命的）
状況:- SFT訓練: ✅ 成功（Loss 0.5270、約40分）
- DPO訓練: ❌ 失敗（初期化成功も、訓練開始時にクラッシュ）
📚 エポック 1/5
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Epoch 1/5: 0%| | 0/6 [00:00- プロセス: 実行中のプロセスなし
- メモリ: 476GB空き（十分）
- GPU: 1MB使用のみ（ほとんど使われていない）
- エラーメッセージ: なし
根本原因の考察
なぜECドメインは失敗したのか？
#### 1. ドメイン知識の深さ ECコールセンターには、特有の「暗黙知」が必要：
- 「30日以内なら返品無料」といったルール
- 「破損時は写真が必要」といった手順
- 「着払いで」といった業界慣習
小型モデルにはこの知識を保持する容量がない。
#### 2. 語彙の特殊性 rinnaモデルの事前訓練データに、ECドメインの語彙が十分含まれていない可能性：
- 在庫状況、配送手配、サイズ交換、返品手続き
- これらの単語の組み合わせや文脈理解
#### 3. 選好基準の抽象性 「丁寧さ」「共感」という選好基準は、AIには学習困難：
- 情報量の違い: 明確（文字数、情報の数で判定可能）
- 丁寧さ・共感: 抽象的（何が丁寧？何が共感的？）
#### 4. モデルサイズの限界
- 13Bモデルなら可能性はあったが、技術的制約（CPU訓練限界）で断念
- GPU環境があれば...でも現実的ではない
学んだこと
1. ドメイン特化の壁は高い
汎用タスク（天気、プログラミング）では成功しても、ドメイン特化（ECコールセンター）では失敗する。この壁は想像以上に高かった。2. データの質 > データの量
データを削減・改善しても、ドメイン特異性という本質的問題は解決できない。表面的な調整では不十分。3. モデルサイズには意味がある
- 110M parameters: 汎用タスク OK、ドメイン特化 NG
- 337M parameters（3倍）: それでもドメイン特化 NG
- 13B parameters（39倍）: 技術的に訓練できず
モデルサイズは、単なる数字ではなく、「理解できる世界の広さ」を表している。
4. 技術的制約の現実
理論的には可能でも、現実の環境（CPU/GPU、メモリ、時間）が制約になる。13Bモデルは「動かない」わけではなく、「現実的に訓練できない」。最終結論
ECコールセンタードメイン特化DPOは、現環境では達成不可能実験結果のまとめ
| 試行 | モデル | データ | Chosen変化 | 成功率 | 状態 | |------|--------|--------|-----------|--------|------| | 18 | rinna 110M | 汎用QA | +0.69 | 75.0% | ✅ 成功 | | 19 | rinna 337M | EC 12ペア | -25.46 | 0.0% | ❌ 失敗 | | 20 | rinna 337M | EC v3（品質改善） | -22.65 | 0.0% | ❌ 失敗 | | 21 | rinna 337M | EC v4（一般化） | -21.88 | 0.0% | ❌ 失敗 | | 22 | llm-jp 13B | EC v4 | - | - | ⚠️ 訓練不可 |
今後の方針
Option 1（採用）: 汎用QAに限定- 試行18で75%成功を確認済み
- 現実的で実用的
- ドメイン特化は諦める
- コスト・時間が大きい
- 成功保証なし
- 現時点では非現実的
- RLHF（Reinforcement Learning from Human Feedback）
- 別のモデル（GPT-4、Claude など商用API）
- プロンプトエンジニアリングで対応
おわりに
3日間、試行錯誤しましたが、結果は「できなかった」。でも、この「できなかった」の理由を、データ量、データ品質、ドメイン語彙、モデルサイズと、段階的に特定できたことは大きな収穫でした。
技術的な限界は、諦めることではなく、「どこまでできて、どこからできないか」を知ることだと実感しました。
汎用QAでの75%成功は、それはそれで価値があります。ECドメインは、もっと大きなリソース（GPU環境、大型モデル、時間）が必要なタスクだったということです。
失敗から学ぶことは、成功から学ぶことと同じくらい価値がある。---
技術スタック:- DPO (Direct Preference Optimization)
- LoRA (Low-Rank Adaptation)
- 2段階アプローチ（SFT → DPO）
- Python, PyTorch, Transformers, PEFT
- ローカル: MacBook（検証用）
- リモート: Lambda GPU Labs（訓練用）
- 監視: Discord通知システム（tmux + Python）
