ファインチューニングは依然として価値があるか？
本文の状態
日本語全文を表示中
詳細モードで約4分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
Hamel Husain
ハメル・フサイン氏は、ファインチューニングへの失望の声が増える中、多くの状況で依然として非常に価値があるとの見解を示した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
このツイートで私が提示した質問に対する私の個人的な見解は以下の通りです。
ファインチューニングへの幻滅を表す声が増えています。
私は、より一般的な感情について興味を持っています。（現時点では私の意見は共有しません）
以下のツイートは @mlpowered, @abacaj, @emollick 氏からのものです pic.twitter.com/cU0hCdubBU
— Hamel Husain (@HamelHusain) 2024年3月26日
ファインチューニングは多くの状況において依然として非常に価値があると考えています。さらに詳しく調査した結果、ファインチューニングが有用ではないと言う人々は、実際にはファインチューニングが有用になる可能性の低い製品に取り組んでいることが多いことが分かりました。
彼らは開発者向けツールを作成しています。基盤モデル（foundation models）はコーディングタスクに対して広範にトレーニングされています。
彼らは基盤モデルを構築し、最も一般的なケースについてテストを行っています。しかし、基盤モデル自体もまた最も一般的なケースのためにトレーニングされています。
彼らは特定のドメインやユースケースに限定されないパーソナルアシスタントを構築しており、これは本質的に基盤モデルを構築している人々と同じグループです。
もう一つの共通のパターンは、多くの人が製品開発の初期段階でこのように言うことです。人々が非常に初期段階にいることを示す兆候の一つとして、ドメイン固有の評価ハーンチ（eval harness）を持っていないことが挙げられます。
評価システムなしに効果的にファインチューニングを行うことは不可能であり、この前提条件を完了していないとファインチューニングを無効視してしまう可能性があります。また、長期的には製品を改善するためにも優れた評価システムが不可欠であり、ファインチューニングの有無にかかわらずこれは変わりません。
ファインチューニングを行う前に、可能な限り多くのプロンプトエンジニアリングを実施すべきです。ただし、それはあなたが考えるような理由によるものではありません！膨大な量のプロンプトエンジニアリングを行う理由は、それが評価システム（eval system）のストレステストに最適な手段だからです。
もしプロンプトエンジニアリングがうまく機能していることが分かり（かつ体系的に製品を評価している場合）、そこで止めても問題ありません。私は問題を解決するために最もシンプルなアプローチを採用すべきだと強く信じています。しかし、まだファインチューニングを無効視するのは早計だと思います。
私がファインチューニングが効果的に機能したと確認した事例
一般的に、ファインチューニングは構文（syntax）、スタイル、およびルールを学習させるのに最も適しており、RAG（Retrieval-Augmented Generation）などの手法は、モデルにコンテキストや最新の事実を提供するのに最も適しています。
これらは私が携わった企業からのいくつかの事例です。今後さらに詳細をお伝えできることを願っています。
Honeycomb の自然言語クエリアシスタント - 以前は、Honeycomb クエリ言語のための「プログラミングマニュアル」が多くの例とともにプロンプトに追加されていました。これは許容範囲でしたが、ファインチューニングを行うことで、モデルがこのニッチなドメイン固有の言語（domain-specific language）の構文とルールを学習させることがはるかに効果的になりました。
ReChat の Lucy は、既存の不動産 CRM システムに統合された AI 不動産アシスタントです。ReChat では、フロントエンドがチャットインターフェースにウィジェットやカード、その他のインタラクティブ要素を動的にレンダリングできるように、構造化データと非構造化データを織り交ぜた非常に個性的な形式で LLM の応答を提供する必要があります。これを正しく動作させる鍵となったのがファインチューニングでした。本講演ではさらに詳細が述べられています。
P.S. ファインチューニングは、オープンソースや「小規模」モデルに限定されるものではありません。Perplexity.AI や CaseText など、GPT-3.5 をファインチューニングしている事例は数多くあります。
原文を表示
Here is my personal opinion about the questions I posed in this tweet:
There are a growing number of voices expressing disillusionment with fine-tuning.
I'm curious about the sentiment more generally. (I am withholding sharing my opinion rn).
Tweets below are from @mlpowered @abacaj @emollick pic.twitter.com/cU0hCdubBU
— Hamel Husain (@HamelHusain) March 26, 2024
I think that fine-tuning is still very valuable in many situations. I’ve done some more digging and I find that people who say that fine-tuning isn’t useful are indeed often working on products where fine-tuning isn’t likely to be useful:
They are making developer tools - foundation models have been trained extensively on coding tasks.
They are building foundation models and testing for the most general cases. But the foundation models themselves are also being trained for the most general cases.
They are building a personal assistant that isn’t scoped to any type of domain or use case and is essentially similar to the same folks building foundation models.
Another common pattern is that people often say this in earlier stages of their product development. One sign that folks are in really early stages is that they don’t have a domain-specific eval harness.
It’s impossible to fine-tune effectively without an eval system which can lead to writing off fine-tuning if you haven’t completed this prerequisite. It’s also impossible to improve your product without a good eval system in the long term, fine-tuning or not.
You should do as much prompt engineering as possible before you fine-tune. But not for reasons you would think! The reason for doing lots of prompt engineering is that it’s a great way to stress test your eval system!
If you find that prompt-engineering works fine (and you are systematically evaluating your product) then it’s fine to stop there. I’m a big believer in using the simplest approach to solving a problem. I just don’t think you should write off fine-tuning yet.
Examples where I’ve seen fine-tuning work well
Generally speaking, fine-tuning works best to learn syntax, style and rules whereas techniques like RAG work best to supply the model with context or up-to-date facts.
These are some examples from companies I’ve worked with. Hopefully, we will be able to share more details soon.
Honeycomb’s Natural Language Query Assistant - previously, the “programming manual” for the Honeycomb query language was being dumped into the prompt along with many examples. While this was OK, fine-tuning worked much better to allow the model to learn the syntax and rules of this niche domain-specific language.
ReChat’s Lucy - this is an AI real estate assistant integrated into an existing Real Estate CRM system. ReChat needs LLM responses to be provided in a very idiosyncratic format that weaves together structured and unstructured data to allow the front end to render widgets, cards and other interactive elements dynamically into the chat interface. Fine-tuning was the key to making this work correctly. This talk has more details.
P.S. Fine-tuning is not only limited to open or “small” models. There are lots of folks who have been fine-tuning GPT-3.5, such as Perplexity.AI: and CaseText, to name a few.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み