- ファインチューニングがAI開発方法論の中心として再び浮上しており、これは Thinking Machines Labs の Tinker 発表と、自前で管理するオープンソース LLM デプロイへのパラダイムシフトによって促進されている
- かつて AI 推論ワークロードの 10%未満に減少していたファインチューニングが、GPU-as-a-service プラットフォーム、安定化したモデルエコシステム、オープンウェイトモデルの普及によって再び注目されている
- LoRA(Low-Rank Adaptation) 技術は、数十億のパラメータを再学習する代わりに小さな低ランク行列だけを追加することで、コストを大幅に削減しつつ性能を維持または改善する
- Tinker は オンライン強化学習による継続学習アーキテクチャを提供し、事前に書かれた応答を模倣する代わりに、モデル自身の応答を評価して改善する形でファインチューニングの未来を示している
- ファインチューニングは単なる技術的ステップを超え、所有権、アラインメント、継続的改善のための戦略的レイヤーへと進化しており、パーソナル AI コンピュータと特化型エージェント運用の中核的な原動力になると見られている
ファインチューニングの歴史的背景
- Thinking Machines Labs が Tinker を発表し、ファインチューニング-as-a-platform をめぐる議論が再燃
- OpenAI の元 CTO である Mira Murati が設立したこのスタートアップは、設立から6カ月で 120億ドルの評価額を得た
- 大学との研究協力の基盤としてファインチューニングプラットフォームを位置付けている
- Hugging Face の Clément Delangue は、自前管理・オープンソース・特化型 LLM デプロイへのパラダイムシフトを感知している
- NVIDIA の DGX Spark のような専用ハードウェアがこれを支えている
- a16z の Personal AI Workstation は、このトレンドを示すマーケティング事例だ
- ファインチューニングは大規模言語モデルの第1波の後に一時注目されたものの、現在は AI 推論ワークロードの10%未満を占めるにとどまり、急速に姿を消していた
Transformer 以前の時代
- Transformer 革新以前の NLP は 特化型モデルに依存していた
- RNN や LSTM のような再帰アーキテクチャが初期の進展を支えた
- 初めて、手作業の言語特徴ではなく 単語列から直接学習した
- 各アプリケーションはタスク別データでゼロから始める必要があった
Transformer の登場とファインチューニング方法論の確立
- 2017年の Google の Attention Is All You Need 論文が Transformer アーキテクチャを紹介した
- 再帰と畳み込みをセルフアテンションだけで置き換えた
- 7カ月後、ULMFiT は事前学習済み言語モデル（当時はまだ LSTM ベース）をさまざまなタスクにファインチューニングできることを実証した
- Transformer を実用化するための 方法論的基盤を確立した
- 1年後、BERT と GPT-1 がこの設計を実際に適用した
- BERT は理解のために双方向アテンションを持つエンコーダ側面を活用した
- GPT は生成のために単方向アテンションを持つデコーダ側面を用いた
- BERT はとりわけ NLP の文化を再編した
- すべてのモデルをゼロから構築する代わりに、研究者は 事前学習済み Transformer をファインチューニングすることで、数カ月の手作業による特徴量エンジニアリングを要していた成果を達成した
Full Fine-Tuning の限界と LoRA の登場
- パラメータ数が数百万から 数千億へと急増するにつれ、ファインチューニングはもはや賢明な選択ではなくなった
- Full Fine-Tuning(FFT) は、すべてのレイヤーと重みを再学習することを意味する
- 精度は得られたが、莫大なコストがかかった
- かつては数時間の GPU 作業で済んだものが、大規模な産業作業へと変わった
- 2021年、Microsoft Research が LoRA(Low-Rank Adaptation of Large Language Models) を紹介した
- 数十億のパラメータを再学習する代わりに、LoRA は元の重みを凍結し、選択したレイヤーに 小さな低ランク行列を追加する
- 学習されるのはそれだけで、コストを一桁削減しながら FFT の性能を維持または改善した
- LoRA はデフォルトの方式になった
- 2024年までには Hugging Face の PEFT ライブラリのおかげで、1行のコマンドで実装できるようになった
ハイパーパラメータチューニングの複雑さ
- ファインチューニングは、デプロイして保守するパッケージ以上のものだ
- チューニングそのものこそ本当の魔法が起こる場所であり、あらゆるものに当てはまる単一の設定など決してない
- ハイパーパラメータチューニングそのものがモデルの成否を左右する
- ランク、学習率、アルファ比率のバランスを取る作業は、科学というより錬金術に近い
- アダプタの過学習や、モデルが既に知っていることを忘れてしまう現象（catastrophic forgetting）を避けなければならない
- うまく動くものが得られたとしても、評価は 検証というより占いに近く感じられる
- 一方で LLM はほぼあらゆるタスクで改善を続け、全能に近づいている
- 2023年までに、多くのチームはコンテキストウィンドウの拡大によって、プロンプトエンジニアリングでファインチューニング性能の約90%を達成できると気づいた
- RAG(Retrieval-Augmented Generation) もモデルに外部知識ベースへのアクセスを与える
- どちらのアプローチも再学習を必要とせず、運用負荷をはるかに抑えながら十分な結果を提供する
ファインチューニングが再び注目される理由
- かつてファインチューニングを無関係または非効率にしていた要因が、今では 一つずつ解消されつつある
- Together.ai のような GPU-as-a-service プラットフォームにより、最小限の摩擦で LoRA ファインチューニングパイプラインを開始できる
- 新しいモデルは依然として速いペースで登場しているが、変化は今や革命的というより 進化的だ
- Mistral、Llama、Falcon、Yi、Gemma といった オープンウェイトエコシステムは、ベンダーロックインなしに、ファインチューニング済み変種を所有・検査・維持できる多くの選択肢を組織に提供する
- 企業は、プロンプティングだけで達成できることの 限界に達したのかもしれない
- ファインチューニングは流行の機能ではなく、制御、差別化、組み込みインテリジェンスのための戦略的レバーとして、ゆっくりと再評価されている
Thinking Machines Lab の Tinker と LoRA 改善点
- Thinking Machines Lab の Tinker は、定理証明、化学推論、マルチエージェント強化学習、AI 安全性に焦点を当てている
- 同社のブログ記事 LoRA Without Regret では、より効果的にファインチューニングする方法が共有されている
- 元論文のようにアテンションレイヤーだけでなく、すべての線形モジュールに LoRA を適用することを推奨
- 見落とされがちなハイパーパラメータである LoRA ランクの重要性を強調
- より高い学習率（少なくとも10倍）と、より小さいバッチサイズ（一般的な慣行とは逆）の設定を勧めている
- 数学的または論理的検証によって 報酬関数を明示的に定義するよう助言している
- すべての推奨事項は Hugging Face の TRL で明確に説明され、再現可能だ
現代のファインチューニングパイプラインのモジュール性
- 現代のファインチューニングパイプラインは、5年前とはまったく異なる
- モジュール化され、サーバーレス化され、オーケストレーションされている
- 単一のデプロイで、ベースモデルとともに 数十個の LoRA アダプタを実行できる
- それぞれが特定のトーン、機能、またはドメインを表す
- 推論時には、システムは静的なモデルファイルに依存する代わりに、適切なアダプタの組み合わせへクエリをルーティングする
- このモジュール性は独自の課題も生む
- Together.ai のようなオールインワンプラットフォームは大半の重い作業を処理するが、多くのチームが必要とする 細かな構成や可観測性が不足している
- 大規模ではコストが急速に膨らむ可能性がある
Tinker の独自アプローチ
- Tinker は 両方の利点を提供しているように見える
- 現代的でフルマネージドなファインチューニングスタックの快適さと、研究者向けの細かな制御を組み合わせている
- ユーザーが最も深いレベルで学習ワークフローやカスタムアルゴリズムをオーケストレーションできるよう、低レベル学習プリミティブへの直接 API アクセスを提供する
- 同時に面倒な作業も処理する
- 現在、Tinker は研究目的にのみ限定されているが、他のプラットフォームに影響を与えると期待されている
- インフラの問題は徐々に過去のものになりつつあるが、評価という主要な難題は残っている
モデル評価の難しさとオンライン強化学習
- モデルの評価は非常に難しい
- 人間による評価は一貫性がなく、遅く、何より高コストだ
- ベンチマークは急速に陳腐化し、データ汚染によって関連性を失う
- G-Eval や Chatbot Arena のような自動化アプローチでさえ独自の問題を生み、しばしば バイアスを増幅し、不安定なスコアを生成する
- Benjamin Anderson は、Tinker が解決策の一部を持っている可能性があると示唆している
- Tinker はユーザーに オンライン強化学習を実行する権限を与える
- 現在のモデル重みから生成結果を取り出してその生成結果を採点し、良かったか悪かったかに応じてモデルを更新する
- 教師ありファインチューニングは事前に書かれた応答を模倣するようモデルに教えるのに対し、オンライン RL は自身の応答を採点して改善する
- このアーキテクチャでは、ファインチューニングの未来は従来のファインチューニングのようには見えないかもしれない
ファインチューニングの戦略的進化
- Moyai.ai の Robert Hommes は次のように述べる
- 「理論上、ファインチューニングは常に合理的だった。しかし、クローズドソースのラボがモデル知能を拡張する速度が、これを 実質的に悪い選択にしていた」
- 「今では、コンピュート、データ、より良いフレームワークによって、再び特化へと傾いている」
- 自前ホスティングへの移行は、予想よりも近いかもしれない
- Exxa の Constant Razel は「パーソナル AI コンピュータはもはや遠いアイデアではない」と語る
- 技術は改善され、より利用しやすくなっている
- セキュリティとコストが初期導入を後押しする可能性が高い
- ファインチューニングは、その上で特化した高性能エージェントが動作することを可能にするだろう
- ファインチューニングは、限界精度を力任せに追求するものから、近接性と制御に根ざした所有権、アラインメント、継続的改善のためのフレームワークへと変化している
- もはや単なる技術的ステップではなく、インテリジェンスがどのように構築され、所有されるかを左右する戦略的レイヤーなのかもしれない
2件のコメント
むしろ人間のほうがAIの発展の妨げになっているんですね。これは面白いジレンマですね。笑
Hacker Newsの意見
1年前までは私は楽観的だった。RLベースのファインチューニングに意味があった事例も実際に一度はあった。だが、これを実際の業務に適用しようとすると、既存の業界技術との衝突が多い。周囲のMLエンジニアを見ていると、特にLLM登場以降に入社した人たちは、本当のML知識が不足していることが多い。実質的にはAI開発者、またはAI DevOps職だ。ML自体が、データエンジニアリングや分析のように、徐々にプラットフォームツールを使う仕事へと変わりつつある。実際、ぱっと見ただけでもクラウドプラットフォームのAI製品の中には、評価指標すら提供せず、まともなMLソリューション開発が不可能なものも多い。この点を大きな問題として捉える人もほとんどいない。RLファインチューニングには、数多くの細部、監視ポイント、データのrefinementが必要だ。単純なMLモデルでさえ、今ではみんなあまり学ばなくなっているのに、RLファインチューニングの学習ギャップはそれよりはるかに大きい。実際に良い事例が少ないので、実務で先輩から学ぶ機会もない。専門家のアサインやデータlabelingのコストも削る傾向にある。会社がこうした技術支援をどれだけ長く続けてくれるのか、自分が辞めた後に誰が交代で引き継ぐのかにも懐疑的だ。AutoMLも大衆化には失敗したし、RLもおそらくプラットフォーム化は簡単ではないと思う。現実には、ほとんどの会社が大規模にスケール可能な劣った製品に、より多くの費用を払うことをいとわない。業界でいう「経験」とは、結局は独占的プラットフォームの経験だ。技術スタックにたまに
pytorchを要求することはあるが、実際に使える社員はほとんどいない。仮にいても、運用負荷のため使えないラベリングは、モデルを学習しない場合でも、システムを素早く客観的に検証するうえで本当に不可欠だ。だが、ラベルの確保は常に困難の連続だ。たまにSMEリソースを確保できても、一貫した基準を厳格に適用してもらうよう求めるコミュニケーションが難しく、最終ラベルも使いづらい形で出てくる。結局、私は一人で自発的にラベリングすることがよくあった。専門分野の理解は不足していても、「ニューラルネットワークが何を好むか」はだいたい分かるので、待ち時間は大きく減らせた。大規模モデルをチューニングするのは、今でも正当化しにくい。むしろ6か月待てば、より良い基盤モデルが出てくることが多い。ただし、大きなモデルが高価すぎて効率が悪い領域なら、小型モデルを目的に合わせてファインチューニングするのは確かに価値がある
本当のエンジニアリング、つまり複雑な理論を実際に動くシステムへ移す技術が、本当の意味でかなり弱くなったと感じる。今では、時間をかけてエンジニアリングの熟練度を高めるより、すでに整ったエンジニアリングサービスに乗る傾向のほうが強い。ハッカー精神からすれば、曖昧なGPUで自分でモデルを学習してみることにROIを求めたりはしない。個人のエンジニアが知識の獲得を渇望しているからだ
結局、誰かが実際の成果測定を通じてきちんとした結果を出し、Michael Lewisがこれをテーマに本を書けば、新しいサイクルがまた始まるのだろうと思う
私も、ファインチューニングで大きな効果を期待していたチームが、実際には漸進的あるいはごく小さな改善しか得られなかった例を多く見てきた。結局プロダクト化までしたものの、最新のSOTAアップデートを追い切れず後悔することが多かった。私は意図的にファインチューニングを避けている。モデル自体の進歩があまりにも速く、大企業のプロダクト開発速度では追いつけないからだ
最近Twitterで、LLMファインチューニングによって経済的価値を生んだ事例についてアンケートを取った。この質問は約6か月ごとにしているのだが、たいていは毎回がっかりする結果だった。今回は以前より少し信頼できる回答が集まった。主要な事例は私のTwitter スレッドにまとめてあり、Twitter未登録の人向けには スレッドビューア のリンクも共有している。印象的な事例として、Datadogが自然言語検索クエリ機能で500ms未満のレイテンシを達成したことが挙げられる関連ツイート、公式ドキュメント参照。VercelはNext.js自動生成のためにカスタムのファインチューニングモデルを運用しておりブログもある。Shopifyは商品画像分析向けにファインチューニングされたVision LLMを活用している記事参照
回帰(regression)タスクでは、ファインチューニングはほぼ必須だ。分類(classification)でも、Yes/Noの閾値調整のために確率値を直接使えるので有用だ
ほとんどの会社にとって、ファインチューニングのリスクに対するリターンは期待より悪いと思う。プロンプトにデータをさらに放り込むだけで済むなら、そのほうがむしろ楽だ
もしファインチューニングが大きな変化をもたらせる事例のアイデアはあるが、自分で実験する時間やリソースがないなら、そうしたアイデアの共有は歓迎する。私は今こうした事例を集めているが、現時点では実在し確認できた事例は3件しかない
LLMにドメイン知識をファインチューニングしようとする多くの人が、たとえば心理学の書籍を切り分けて、そのままテキストだけを入れるというミスを犯している。そうしたやり方では、「心理学を適用する行動」を教えるのではなく、単にそれについて「紹介文を書く」方法だけを学習させてしまう。データセット設計の誤りが、多くのファインチューニング失敗の原因だ。逆に、データセット構成が適切なら、7Bモデルで180Bモデルを上回る効率を出せる
最近見たいくつかの事例を挙げると、OPの意見に同意する。PaddleOCRは0.9Bパラメータで、テキスト、表、数式、チャート、手書き文字までSOTA精度に近い論文。また、3B/8BモデルがHTMLをJSONに変換するタスクで、GPT-5級の精度、40〜80倍安いコスト、より高速な推論速度を達成しているReddit。特定タスクの効率を高めたいなら、ファインチューニングには意味がある
PaddleOCRを実際に使ってみたのか気になる。Amazon TextractやAzure Document Intelligence（LayoutLM v3ベース）と比較せずにSOTAと主張するのは不思議だ。私が文書認識を試したときは、この2つが最高レベルだった
この議論はSLMとLLM、つまりモデルサイズの問題にもつながる。SLMは特定業務向けに最適化でき、その課題に限ればLLMに勝てる。ただし、1. 精度が非常に重要か、2. トラフィックが非常に多いのでなければ、時間と労力に対する価値は低い
LaminiというLLMファインチューニングのスタートアップを創業した立場から言うと、OPの意見には同意しない。私たちの仮説は、ファインチューニングはディープラーニングをゼロから学ぶよりずっと簡単に使われるだろう、というものだった。すでに非常に強力なLLMから始められるので、より簡単だと予想していた。しかし20件あまりの実プロジェクトを進めた結果、ファインチューニングはディープラーニングと同じくらい難しく、参入障壁も高かった。現在の市場構造では、ディープラーニングベースのファインチューニングに長けたMLエンジニアなら、スタートアップを起業するか、AnthropicやOpenAIなどに簡単に加われる。ところが、実際にLLMソリューションを作るチームでは、優秀なエンジニアが歓迎されにくい。結果として、Claude、GPT、Qwenなどを作る専門チームのほうが、個々のユーザーによるファインチューニングの試みより競争力がある。今はRAG、プロンプトエンジニアリング、推論、AIエージェント、メモリ、SLMのほうが、はるかに簡単で強力なソリューションだ
AnthropicやOpenAIは、LLMファインチューニングができる人なら誰でも採用したがっているのだろうか
当時ファインチューニングしていたモデルがどんな種類だったのか、そのモデルはうまくチューニングできるほど成熟していたのか、catastrophic forgetting（破滅的忘却）の問題があったのか気になる。今はより良いオープンソースモデルも増えた。ファインチューニングを念頭にアーキテクチャを設計すれば、前世代の欠点も克服できると思う。企業は他人のモデルを借りるより、自分のモデルを直接所有したがる
ファインチューニングはツールボックスにぜひ入れておくべき良い技術だ。ただ、実際には適用できる用途は思ったより狭い。一方で、多くのNLP課題はすでにLLMの素の性能だけでも精度がかなり高く、ファインチューニングは不要だ。逆に、本当に複雑な課題では、ファインチューニングは非常に難しく、データ収集も非常に高価だ。結局、ファインチューニングは、難易度がちょうどよく、データ収集も現実的な、その中間あたりのタスクで使えるソリューションだ
適切なユースケースは数十万種類あると思う
その「中間に当たる」タスクには、たとえばどんな事例があるのか気になる
このウェブサイトはヨーロッパからアクセスしても本当に読み込みが速い。スクロールに応じて動的にコンテンツを読み込み、画像も高圧縮なのに画質が良い。サイト構成が本当に印象的だ
最近、似たテーマでブログ記事を書いたブログ。7BモデルをファインチューニングしてGPT-4を上回った大規模実証研究「LoRA Land」と、ここ6か月でファインチューニングのトレンドがどう変化したかを論じた
LoRAアダプタで、これまで既存プロンプトに必ず入れなければならなかった作業標準、ネーミングスタイルの好み、参照資料、MCP定義など、さまざまなコンテキスト要素をモデル内部に入れられるのではないかと気になっている。データは、まず既存のコンテキストをできるだけ多く入れ、さまざまなプロンプトを試して、応答がbaselineとどう違うかを見る形で作れば楽だ。その結果を、ファインチューニングに input=
refactor {base model output}、output={full-context model output}の形で入れることもできる。LoRAはもともと組み合わせて使うよう設計されているので、MCPもアダプタとして配布してオン・オフできるかもしれない。この方式なら、コンテキスト汚染(context poisoning)の防止にもなると思うinference.netとschematronの開発者だ。企業はLLMを実プロダクトに適用するにあたり、効率性をますます重視している。開発者の立場では、GPT-5-Super-AGI-Thinking-Maxのような高価なモデルに課金するとしても、実際のビジネスでは効率性も問われる。もし80億パラメータのLlamaモデルを48時間以内にGPT-5データでファインチューニングして月10万ドル節約できるなら、当然みんなその機会を取りに行く
今ではほとんどの企業が、単純なプロンプトだけで達成できる限界点に達したように見える。その企業固有の語彙、トーン、分類体系、コンプライアンス規定を正確に理解したモデルが必要だ。速度とコストが重要なのも事実で、それがファインチューニングの主な理由だ。ただし、コンテキスト管理の手法でも協調は可能になっている。コンテキストサイズが大きくなるにつれてRAGがファインチューニングを代替し、最近ではより良いプロンプト設計だけでも活用度が大きく上がっている。FPGAとCPU/GPUの議論のように、最高性能を得るための開発費と納期リスクのために、ほとんどの企業はハイエンドなファインチューニングの恩恵を受けられていない