【ITニュース解説】Prompt engineering vs fine-tuning: which one do you need?

大規模言語モデル（LLM）を活用したシステム開発において、モデルの振る舞いを制御するための主要なアプローチとして、「プロンプトエンジニアリング」と「ファインチューニング」の二つが存在する。これらは、私たちがAIにどのようなタスクを実行させたいか、どのような出力をしてほしいかという要求に対し、異なる方法でモデルを調整する技術である。

まず、プロンプトエンジニアリングについて解説する。これは、LLMに与える「プロンプト」、つまり指示や質問の内容を工夫することで、モデルの出力を調整する技術だ。例えば、「あなたは親切なアシスタントです。以下の文章を要約してください」といった具体的な指示をモデルに与え、その応答を得る。この手法の大きな特徴は、モデル本体には一切変更を加えず、モデルへの入力、すなわち「コンテキストウィンドウ」の内容だけを変える点にある。そのため、非常に手軽に始めることができ、特別なインフラやGPU（高性能な計算装置）といったコストは不要で、調整にかかる時間は数秒程度だ。プロンプトを修正するだけで簡単に試行錯誤ができ、もし期待通りの結果が得られなくても、すぐに別のプロンプトに書き換えられるため、「可逆性」が非常に高い。また、現在使っているLLMを別のモデルに切り替えたとしても、調整したプロンプトはそのまま使えることが多い。LLMアプリケーション開発の初期段階では、まずこのプロンプトエンジニアリングから着手するのが一般的である。なぜなら、モデルが元々どのような能力を持っているかを、低コストで迅速に把握できるからだ。多くの初期の機能変更や振る舞いの調整は、プロンプトを工夫するだけで対応できる場合が多い。

次に、ファインチューニングについて説明する。これは、LLMの内部にある「重み」と呼ばれる多数の数値パラメータを、特定のデータセットを使って再学習させることで、モデルそのものの振る舞いを変更する技術である。プロンプトエンジニアリングがモデルに「何を言うか」を変えるのに対し、ファインチューニングはモデルの「脳」自体を調整するようなイメージだ。この手法を実行するには、GPUの時間と、モデルを学習させるための専門的なパイプラインといったインフラが必要となり、プロンプトエンジニアリングと比較してコストと時間がかかる。また、モデルを再学習させるためには、特定の入力に対する望ましい出力例が「ラベル付け」されたデータが数千件単位で必要となる。一度ファインチューニングでモデルの重みが変更されると、その変更は永続的であるため、元の状態に戻すには再度トレーニングを行う必要があり、プロンプトのように即座に元に戻すことはできない。しかし、ファインチューニングによってモデルは特定のタスクに対して非常に高い精度で特化できる可能性を秘めている。プロンプトエンジニアリングが比較的早く性能の限界に達するのに対し、ファインチューニングは質の高いデータがあれば、より高いレベルの性能を実現できる。

LLMを使ったシステムを構築する際、開発チームが最初にプロンプトエンジニアリングを選ぶのは、その効率性の高さゆえだ。まずはプロンプトの調整を繰り返し、モデルが期待通りの応答をするか、どこに改善の余地があるかを低リスクで探る。そして、このプロンプト調整による改善が頭打ちになったと感じたときに、ファインチューニングを次のステップとして検討する。これは一度の決断ではなく、開発の進行に合わせて繰り返されるサイクルと捉えるべきだ。もしモデルに新しい振る舞いをさせたい場合、最初はプロンプトの変更を試みる。その変更によってモデルの評価スコアが改善するなら、引き続きプロンプトの調整を続ける。しかし、3〜4回プロンプトを変更しても評価スコアがほとんど向上しなくなり、かつ対象となるタスクが明確で狭い範囲に限定されており、数千件規模のラベル付きデータが手元に用意できている場合は、ファインチューニングを検討すべき時期が来たと判断できる。もし評価が頭打ちになっても、タスクが広範すぎたり、適切なラベル付きデータが不足している場合は、まず必要なデータセットを構築することから始めるのが賢明だ。

プロンプトエンジニアリングは、いつか限界に直面する。その兆候はいくつかの形で現れる。一つは「頭打ち」と呼ばれる現象で、どんなにプロンプトを調整しても評価スコアの改善が見られなくなる。次に「モグラ叩き」のような状況だ。ある問題に対処するためにプロンプトを変更すると、別の場所で予期せぬ問題が発生し、その繰り返しに陥る。また、「プロンプトの肥大化」も問題となる。モデルへの指示が増えすぎてプロンプトが非常に長くなり、モデルの応答が遅くなったり、長い指示の一部が無視されたりすることがある。そして、最も避けたいのは「同じ修正を毎回送る」状態だ。これは、根本的な解決策が見つからず、モデルに毎回同じような指示を繰り返して送ることで、本質的な改善がなされていない状態を指す。このような段階に至ると、プロンプトエンジニアリングはもはや安価な手法とは言えず、多くのエンジニアリング時間とコストを無駄にしている可能性が高い。

ファインチューニングを検討すべきなのは、以下の条件が満たされたときである。第一に、対象となる「タスクが狭い」ことだ。ファインチューニングは、モデルの汎用的な能力を向上させるよりも、特定の限られたタスクにおいて、より正確で望ましい振る舞いをするようにモデルを特化させる目的で行われる。第二に、「実際のデータがある」こと。理想的には、実際のユーザーとのやり取りなど、本番環境から得られた数千件規模のラベル付きデータが望ましい。合成データよりも実際のデータの方が、モデルの性能向上には効果的である。第三に、「コストやレイテンシ（応答速度）が重要」な場合だ。プロンプトが長大化した大きな汎用モデルは、毎回長い指示を処理するため、応答が遅くなったり、推論コストが高くなりがちである。しかし、特定のタスク向けにファインチューニングされた比較的小さなモデルは、長いプロンプトが不要になることで、より高速に応答し、低いコストで同等かそれ以上の性能を発揮することがある。ファインチューニングによってモデルが特定の振る舞いを「デフォルトで」行うようになるため、毎回長い指示を送る必要がなくなるのだ。

LLMを活用したシステム開発において、プロンプトエンジニアリングとファインチューニングは、それぞれ異なる強みを持つ重要な技術である。プロジェクトの現在のフェーズ、目標とする性能レベル、利用可能なリソースに応じて、これらの手法を適切に選択し、あるいは組み合わせて適用することが、効率的で効果的な開発プロセスを構築する鍵となる。開発の初期段階では手軽なプロンプトエンジニアリングでモデルの可能性を探り、その限界が見えてきたら、具体的なデータと明確なタスクに基づいてファインチューニングに移行するという流れが、成功への道筋と言えるだろう。