結論から言うと、「でかいモデルを買えばいい」という時代は終わった。
Hugging Face のブログで読んだ論文が刺さった。Dharma AI が今年出したベンチマーク結果で、パラメータ数 30 億のモデルがすべての商用フロンティア API に勝ったという話だ。しかも精度で上回りながら、コストは約 50 分の 1。これは誤字じゃない。50 倍のコスト差が、逆方向に出た。
正直、自分もこれまで GPT-4 系や Claude 3 Opus を選ぶとき、「規模が一番の保険」という感覚で意思決定していた。投資家に AI コストの話をするとき、「最高スペックを使っている」と言うほうがプレゼンが通りやすかった側面もある。だけどそれは、比較対象に専門特化モデルがいなかったからに過ぎない。Dharma の論文が言っているのも同じことだ。スケーリング則が優位だったのは、その土俵に「同じタスクにファインチューニングした小型モデル」が上がっていなかっただけ、と。
ウチのサービスは B2B の SaaS で、クライアントの業種はほぼ 2 〜 3 セクターに集中している。エッジケースの幅が狭い。つまり、タスクが絞れる。この構造なら専門特化モデルの恩恵がそのまま ROI に乗る。従業員 8 人の体制で月次のモデル利用コストが今どのくらいかを先週改めて洗い出してみたら、API 費用だけで思ったより大きな額が飛んでいた。50 分の 1 という数値がフィクションじゃないなら、GTM フェーズで削れるコストの単位が変わってくる。
ウチのプロダクトに引きつけると、適用候補は 3 つある。
どれもタスクが狭い。分布が固定に近い。Dharma の論文でいう「トレーニング履歴をデプロイタスクに近づける」という条件を満たしやすいやつばかりだ。逆に、採用の書類スクリーニングや投資家向けのナラティブ構築は、まだ汎用モデルに頼む。そこは多様性がないと困る。
妻に「また何か乗り換えるの?」と聞かれた。先月も Notion AI から Claude に切り替えて、ワークフローをまた作り直したばかりだったから、さすがに呆れ顔だった。だけど今回は乗り換えではなく、使い分けの設計の話だと説明した。フロンティアモデルを捨てるわけじゃない。タスクごとに最適なモデルを割り当てるアーキテクチャを組む、という話だ。
これはツール選定の話じゃなくて、PMF 後の拡張コストをどう設計するかの話でもある。スタートアップがグロースするにつれて AI の呼び出し回数は線形以上に増える。そのとき単価を下げる手段を持っているかどうかは、Unit Economics に直結する。投資家にこう説明するとしたら、「インフラレイヤーに専門特化モデルを組み込むことで、スケール時の限界コストを抑える設計をしている」になる。これは刺さる話だと思っている。
まず Dharma のベンチマーク論文を読み込む。DharmaOCR のパイプラインが公開されているので、同じ構造を自社タスクに当てはめたときの試算を出す。社内の開発リソースは薄いが、「ファインチューニングパイプラインを構築できる体力のある企業なら再現できる」とわざわざ言及されているのが引っかかった。ウチのサイズでも手が届くのかどうか、まずそこを確認する。
「大きいモデルを買えばいい」という判断が合理的だった時代の前提が崩れているなら、その崩れ方を自分の目で確認してから次の意思決定をするのが筋だ。
Hugging Face のブログで読んだ論文が刺さった。Dharma AI が今年出したベンチマーク結果で、パラメータ数 30 億のモデルがすべての商用フロンティア API に勝ったという話だ。しかも精度で上回りながら、コストは約 50 分の 1。これは誤字じゃない。50 倍のコスト差が、逆方向に出た。
「大きいほど強い」という思い込みを疑うタイミング
正直、自分もこれまで GPT-4 系や Claude 3 Opus を選ぶとき、「規模が一番の保険」という感覚で意思決定していた。投資家に AI コストの話をするとき、「最高スペックを使っている」と言うほうがプレゼンが通りやすかった側面もある。だけどそれは、比較対象に専門特化モデルがいなかったからに過ぎない。Dharma の論文が言っているのも同じことだ。スケーリング則が優位だったのは、その土俵に「同じタスクにファインチューニングした小型モデル」が上がっていなかっただけ、と。
ウチのサービスは B2B の SaaS で、クライアントの業種はほぼ 2 〜 3 セクターに集中している。エッジケースの幅が狭い。つまり、タスクが絞れる。この構造なら専門特化モデルの恩恵がそのまま ROI に乗る。従業員 8 人の体制で月次のモデル利用コストが今どのくらいかを先週改めて洗い出してみたら、API 費用だけで思ったより大きな額が飛んでいた。50 分の 1 という数値がフィクションじゃないなら、GTM フェーズで削れるコストの単位が変わってくる。
専門特化の判断をどこに当てはめるか
ウチのプロダクトに引きつけると、適用候補は 3 つある。
- セールス資料の自動生成 (業種・フェーズ別のパターンが決まっている)
- チャーン予兆の分類タスク (入力データがほぼ定型)
- サポートメールのトリアージ (カテゴリが 10 種以下)
どれもタスクが狭い。分布が固定に近い。Dharma の論文でいう「トレーニング履歴をデプロイタスクに近づける」という条件を満たしやすいやつばかりだ。逆に、採用の書類スクリーニングや投資家向けのナラティブ構築は、まだ汎用モデルに頼む。そこは多様性がないと困る。
妻に「また何か乗り換えるの?」と聞かれた。先月も Notion AI から Claude に切り替えて、ワークフローをまた作り直したばかりだったから、さすがに呆れ顔だった。だけど今回は乗り換えではなく、使い分けの設計の話だと説明した。フロンティアモデルを捨てるわけじゃない。タスクごとに最適なモデルを割り当てるアーキテクチャを組む、という話だ。
これはツール選定の話じゃなくて、PMF 後の拡張コストをどう設計するかの話でもある。スタートアップがグロースするにつれて AI の呼び出し回数は線形以上に増える。そのとき単価を下げる手段を持っているかどうかは、Unit Economics に直結する。投資家にこう説明するとしたら、「インフラレイヤーに専門特化モデルを組み込むことで、スケール時の限界コストを抑える設計をしている」になる。これは刺さる話だと思っている。
次にやること
まず Dharma のベンチマーク論文を読み込む。DharmaOCR のパイプラインが公開されているので、同じ構造を自社タスクに当てはめたときの試算を出す。社内の開発リソースは薄いが、「ファインチューニングパイプラインを構築できる体力のある企業なら再現できる」とわざわざ言及されているのが引っかかった。ウチのサイズでも手が届くのかどうか、まずそこを確認する。
「大きいモデルを買えばいい」という判断が合理的だった時代の前提が崩れているなら、その崩れ方を自分の目で確認してから次の意思決定をするのが筋だ。