はじめに
こんにちは！今回AWSが主催するプライベートイベントとして当社で開催された「DNP×AWS AI League 2025」に私たちDNPデジタルソリューションズの同じ部署の5人の仲間が参加しました。
AWS AI Leagueのコンペティションの一つである「Tune Whiz」を通じて、LLM再学習競技に個別参加しながらも情報共有や協力をして挑んだ体験をシェアします。
メンバー全員がLLM（大規模言語モデル）の学習やファインチューニングについてはまったくの未経験者でした。何から始めれば良いのかも分からない状態でしたが、「知見がない分、お互いの試行錯誤を共有し合おう」と決めて挑戦を始めました。コツをつかむまで各自が実験した結果や気づきを共有することで、効率的に学びを深めていったのです。
この協力体制が功を奏し、試行錯誤の末にメンバーの一人（以降Aさん）がGrand Final Gameshow（決勝戦）進出、私が7位という好成績を収めることができました。このブログでは、LLM学習の初心者だった私たちの取組みやハイパーパラメータ調整の過程、そして得た知見について紹介します。
大会概要
「DNP×AWS AI League 2025」は、参加者が自分だけの日本観光コンシェルジュのモデルを作り上げてランキングを競う大会です。SageMaker JumpStartを活用してノーコードでLLM（大規模言語モデル）を再学習させ、より優れたパフォーマンスを発揮するモデルを作ることが求められました。今回はMeta Llama 3.2 3B Instructをベースモデルとして使用しました。
私たちの取組み
初期段階：試行錯誤の始まり
Virtual Competition（予選期間）における最初の投稿では、メンバーの一人（以降Cさん）が90位というランキングでスタート。もう一人（以降Dさん）も92位からのスタートとなりました。参加者総数が336名という状況で、まずまずのスタートダッシュを切れたと言えるでしょう。
初めての投稿では、私は残念ながら圏外…
モデルについての基本情報
競技に使用したモデル（Meta Llama 3.2 3B Instruct）について、メンバーの一人（以降Bさん）が重要な情報を共有してくれました：
- 英語中心のモデル（3.2 3Bは全言語モデル）
- コンテキスト長は8000トークン（3.2 3Bは128000トークン）
- 3 70Bは良い応答を返せないため、チューニングのjsonの回答データはそこそこ良い応答で学習した方が有利
この情報共有のおかげで、メンバー全員はモデルの特性を理解し、より効果的なアプローチを検討することができました。
データセット作成の工夫
私たちは互いの結果を共有しながら、データセットの質が結果を大きく左右することに気づきました。何度も試行錯誤を重ねながら、最適なデータセットを探る挑戦が続きました。
Cさんはこう共有しています:
「今のところお試しで初回に作った添付したデータセットが一番成績が良いという・・・」
「WinRateが2%なので1回しか勝てていませんが」
日本語のみのデータと、英語を入れたデータでは結果が大きく異なることも発見しました。Dさんは「日本語のみで3%だったので英語入れたら・・・？」と試したところ、興味深い結果が出たようです。
Aさんは、さまざまなデータセット作成に挑戦しました：
とりあえず自作したデータ構成（数字は該当）：
- 観光地紹介: 2,000例
- 交通アクセス: 1,000例
- 予算相談: 500例
- 季節の推奨: 500例
- 文化・マナー: 500例
- トラブルシューティング: 500例
日本政府観光局の英語、中国、日本語をクロール記事スクレイピングしてmarkdownファイル化。各1500～2000url
1記事の内容から難易度ごとに2～5個程度、QAをLLMで生成データセットや観光apiをたたいてデータを作ることも思惑したが観光地や観光場所のトレンドも欲しい気がしたのでパス
また、Aさんは英語と中国語でのトレーニングにも挑戦し、メンバー間で次のようなやり取りがありました。
「英日中データにしてやったら2回しか勝てなくなった。逆に同じくらい量の日本語をトレーニングするとなぜか下がるのだな。」
この発見から、単純に多言語データを増やせば性能が向上するとは限らないことが分かりました。
モデルのテストを行う画面
これらの試行錯誤から、データセットの言語バランスと内容構成が、モデルの性能を大きく左右することが明らかになりました。特に多言語対応においては、単純に言語量を増やすだけでなく、適切なバランスが重要だと学びました。
モデル評価基準の理解
Aさんは評価基準について深く考察していました：
簡単な質問: "Where is Tokyo Tower?"
中程度: "3日間の京都プラン"
複雑: "車椅子で東京観光、予算10万円、桜の季節"私が利用者なら、場所聞いたらGoogle MapsのURLが含まれて欲しい
また、評価の重要な軸として「簡潔さ」「親しみやすさ」「実用性」「適切な言語での回答」などの基準を設け、自己評価を行っていました。特に「詳細すぎない回答」「友達のアドバイスのような親しみやすさ」「実際に使える情報」を重視していたようです。
ハイパーパラメータの調整
ハイパーパラメータ調整は私たちの中心的な課題となりました。特に以下のパラメータが重要でした：
- epochs
- learning_rate
- lora_r
- lora_alpha
- target lora modules
Bさんが共有した表では、さまざまなハイパーパラメータの組合せとそれぞれのスコアを示していました。例えば：
| epochs | learning rate | lora r | lora alpha | score |
|---|---|---|---|---|
| 3 | 0.0003 | 16 | 64 | 2.637 |
| 5 | 0.0003 | 16 | 64 | 0.546 |
| 3 | 0.0005 | 16 | 64 | 7.075 |
| 3 | 0.0002 | 256 | 512 | 7.627 |
特に注目すべきは、学習率（learning rate）の影響です。Cさんの分析によると：
「learning rateを0.001や0.0001に設定した場合、eval-pplが異常に高くなりパフォーマンスが非常に悪化します。（値が低ければ低いほど良い）」
「learning rateは『理想のゴールに近づく際の歩幅』が最も分かりやすいイメージで、小さいとゴールへたどり着くのも遅く大変ですが、大きくしてもゴールを通り越してしまい、逆に遠くなってしまう・・・という概念だそう。」
0.01を試した場合。過学習で性能が悪化
0.001を試した場合。いずれの数値も下がって性能が改善
これらの知見から、learning rateは0.0005～0.0002の範囲で調整するのがベストという結論に至りました。
とはいえ、何度かトライしたもののスコアは改善せず、図のように低迷が続きました。
運用上の発見
競技を進める中で、メンバー間でいくつかの運用上の発見も共有されました：
-
モデル評価の不確実性：Bさんは「サンプルのJSONファイルをそのまま使って学習+デプロイしてるユーザーって5%くらい。そのユーザーが0.8%の勝率ってことは、データを50例増やしても勝率5%超えないんじゃないかなーって感じ」と分析しました。
-
モデル提出の戦略：Aさんは「1位の人のトータルモデル提出数が56回もあるんだけど、これって異常に多くない？もしかしてプログラムでAPI使ってたくさんのモデル作って提出を試してるのかな？」と疑問を投げかけました。
-
評価結果の不安定性：Dさんは「successful judgments（正常に評価された回答数）が50とwin rate（勝率）あるのんな。successful judgmentsって何？」と疑問を呈し、「みんな困って不安になって(successful judgmentsが下がると主張)モデル提出すればいいのか」と懸念を示しました。
最終局面：ブレイクスルー
最終的にはAさんとBさんが大きなブレイクスルーを達成し、トレーニングに1時間かかったものの20%のwin rateを出すことに成功しました。具体的には以下のパラメータを使用しました：
| epochs | learning rate | lora r | lora alpha | target lora modules |
|---|---|---|---|---|
| 2 | 0.0002 | 8 | 32 | q_proj,v_proj,k_proj,o_proj,gate_proj,up_proj,down_proj |
この結果、私が7位、AさんがGrand Final Gameshow（決勝戦）に進出という素晴らしい成績を収めることができました！私たちの試行錯誤が実を結び、限られた時間内で大きな成果を上げられました。
得られた知見
-
データセットの質が重要:
- 日本語と英語の混合比率がパフォーマンスに影響しました
- マルチ言語にする際は1ファイルでランダムに混ぜて、適切なバッチサイズで学習すると良いことが分かりました
- 特定の内容に特化した学習をしすぎると、汎用性を失ってスコアが下がる可能性があります
-
ハイパーパラメータの最適値:
- learning rateは0.0005～0.0002の範囲が効果的でした
- epochs数は多すぎると過学習、少なすぎると学習不足になった。2～3回が適切でした
- lora_rとlora_alphaの組合せが大きく影響しました
- 学習データによって最適値が変わるので、情報を鵜呑みにせず、テストすることが重要でした
-
モデル評価の理解:
- 詳細で完璧な回答より、短くて親しみやすい回答の方が高評価を得やすい
- 回答は質問と同じ言語で行うことが重要である
- 小さな不正確さはOKだが、明らかに不正確な情報は評価を下げる
-
協力の重要性:
- 個別参加でもメンバー間の情報共有と協力が最終的な成功につながった
- さまざまな視点からのアプローチで問題解決の幅が広がった
おわりに
「DNP×AWS AI League 2025」への参加は、LLMの再学習について多くのことを学ぶ貴重な機会となりました。メンバー全員がゼロから始めましたが、情報共有と継続的な実験によって徐々にコツをつかみ、最終的には上位入賞という結果を残すことができました。
この経験から、AIの学習においても「チームワーク」と「知見の共有」が重要であることを実感しています。技術的なスキルだけでなく、コミュニケーションと情報交換が成功への鍵となったのです。
最後に、共に情報を共有し励まし合った仲間たち、そして大会を運営してくださったDNPとAWSの関係者の方々に感謝申し上げます。