もうハードルは高くない！Vertex AIで超速LLMファインチューニングを実践してみた

こんにちは。SCSKの松渕です。

Google Cloudでファインチューニングが簡単に実装できると聞いたので、実践してみたいと思います。

はじめに
事前準備
1. やりたいことを整理
2. データの準備
ファインチューニング実施
1. ファインチューニング開始
2. 学習待ち
結果確認とテスト
まとめ

はじめに

ファインチューニングとは

ファインチューニングとは、事前学習済みの大規模言語モデル（LLM）を、特定のタスクやデータセットに合わせて、追加で学習・調整することです。

これは、モデルの基本的な知識や言語能力を活かしつつ、特定の用途（例：社内文書の要約、特定のトーンでの応答、固有の知識の習得）に特化させるために行われます。

なんだか、RAGとの違いがよく分からないですね。ということでRAGとの違い、使い分けを整理します。

RAGとの違い

Geminiに整理いただきました。

特徴	RAG (検索拡張生成)	ファインチューニング (モデル調整)
目的	最新・専門の外部情報に基づいて、正確な回答を生成すること。	モデルの振る舞い（スタイル、トーン、出力形式）やドメイン知識を改善すること。
仕組み	質問と関連性の高い外部文書を検索し、その文書をプロンプトに追記してLLMに入力する。モデル自体は変化しない。	カスタムデータを使ってモデルの重み（パラメータ）を更新し、モデルを恒久的に変更する。
必要なデータ	検索対象となる参照文書（PDF、社内文書、データベースなど）。	高品質な質問と回答のペアや指示データ。
コスト/時間	低い。主に検索システム（ベクトルデータベースなど）の構築・維持費用。	高い。大量のGPUリソースと時間が必要（特にベースモデルが大きい場合）。
更新頻度	容易。参照文書を更新するだけで、即座に結果に反映される。	困難。データが更新されるたびに、トレーニングをやり直す必要がある。
学習限界	モデルが参照文書にない情報を生成することはできない。	モデルが学習データに含まれない知識（新しい事実）を知ることはできない。

RAGのほうが向いているケース

情報が頻繁に更新される
情報の出典を明確化したい
※どのドキュメントの何ページ目　まで出典明記したい場合、チャンク化やメタデータ設計を適切に実施する必要あり
事実の正確性が最重要（ハルシネーション対策）

ファインチューニングのほうが向いているケース

特定のスタイルやトーンの統一（jsonなどの出力形式の固定なども可能）
トークン効率の改善。モデルのプロンプトサイズを削減し、コストとレイテンシを改善したい場合

ハイブリッド（RAG + ファインチューニング）

上記参照いただくとわかる通り、RAGとファインチューニングは二者択一のものではありません。これら二つを組み合わせることで、

ファインチューニングでモデルに出力形式とスタイルを学習させ、RAGでモデルに最新かつ正確な事実を提供する、カスタムAIシステムを構築できます。

今回実装する方式について

今回は、Google Cloudで簡単にファインチューニングできる教師ありファインチューニングサービスを利用します！

ベースとなるモデルは、GeminiとGemma、Llamaなどの一部のOSSのモデルでした。
詳細は以下参照ください。
Gemini モデルの教師ありファインチューニングについて(Google Cloud ドキュメント)

事前準備

やりたいことを整理

何より大事ですね。RAGとの使い分けの部分の調査から、Geminiの応答口調を調整してみようと思います。
小難しいカタカナ英語ばっかり使うようにファインチューニングします。
データさえあれば、「〇〇さんっぽく応答してくるAI」とかは盛り上がること間違いなし！

データの準備

学習大規模言語モデル（LLM）のファインチューニングには、対話形式のデータセットを学習用データとして準備する必要があります。
特定のタスク（この場合は要約）をモデルに学習させるための入力（ユーザーのプロンプト）と、それに対する理想的な出力（モデルの応答）のペアとして構成されています。

Google社が提供している学習データのサンプルがこちら。JSON Lines形式で記載されています。

私が準備した学習データの一行抜粋します。（私は今回、Gemini使って400行程度準備してもらいました）

{“contents”: [{“role”: “user”, “parts”: [{“text”: “業務の引き継ぎで失敗しないためには？”}]}, {“role”: “model”, “parts”: [{“text”: “タスクのスコープとネクストアクションをマストで文書化し、クリティカルなプロセスは複数のメンバーでコンセンサスを取るべきです。”}]}]}

実際に言われたら、私なら思わず聞き返してしまうかもしれません。

1行で対話のひとつのターン（発話）を表しています。

"role": "user"：この発話がユーザー（入力側）からのものであることを示しています。
"parts": [...]：発話の内容（テキストや画像など）を格納する配列です。
"text": "..."：ユーザーがモデルに与えた指示（プロンプト）の本文です。
この例では、「業務の引き継ぎで失敗しないためには？」という文章です。

"role": "model"：この発話がモデル（出力側）の理想的な応答であることを示しています。
"text": "..."：モデルがこのプロンプトに対して学習すべき正解の回答です。
小難しい横文字ばかり使ってますね。

データ準備についての各種注意事項は以下参照ください。
データ数としては、100 個のサンプルから始めて、必要に応じて数千にスケールすることをおすすめします。データセットは量よりも質のほうがはるかに重要です。
Gemini モデルの教師ありファインチューニングデータを準備する(Google Cloud ドキュメント)