- 多くのAI製品は、ChatGPTのような外部モデルをAPIで呼び出すラッパーにとどまり、差別化・コスト・速度・カスタマイズのリスクを製品内部に持ち込んでいる
- 単純なLLM呼び出し方式は素早く作れる一方で、誰でも複製でき、OpenAIが同じ機能をChatGPTに組み込めば固有の価値を守るのが難しい
- 汎用LLMは実行コストが高く、GitHub Copilotのように月額$10を受け取りながら平均$20、一部ユーザーでは月額$80のコストがかかる構造になりうる
- BuilderのVisual Copilotは、Figmaデザインをコードに変換する過程でLLMだけを使う方式を試したが、応答遅延と品質の限界から独自ツールチェーンへ切り替えた
- 実務的には、まず通常のコードで問題を解き、標準的なコードでは扱いにくい狭い領域にだけ特化AIモデルを組み合わせるほうが、より速く、より安く、より制御しやすい
単純なLLMラッパー方式の限界
- 現在作られている多くのAI製品は、他のモデルの上に載ったラッパーに近く、ChatGPT APIに自然言語入力を送り、自然言語出力を受け取る方式で動作している
- 実装が簡単で、興味深い機能を素早く作れるが、製品固有の価値が高度なAI技術にあるなら、複製リスクは大きくなる
- PDFチャットアプリのように、1人が作れば複数人が似たアプリを作り、その後OpenAIがChatGPTに直接組み込むという流れは、差別化された技術が不足しているときに起こる
- 製品がボタン1つでChatGPTにリクエストを送り、その応答をユーザーに見せる程度なら、防御力は最も弱い
- 独自技術が十分にあり、LLMが小さいが重要な一部だけを補助しているなら、より良い立ち位置にあるが、コストと速度の問題は依然として残る
コストと速度は製品化の現実的な制約
- LLMは広い汎用性を得るために大規模かつ複雑になっており、その分だけ実行コストも高い
- Wall Street Journalによれば、GitHub Copilotはユーザーから月額$10を受け取っていたが、平均コストは$20で、一部のユーザーはGitHubに最大月額$80のコストを発生させていた
- 多くの製品には、インターネット全体を学習した巨大モデルは必要なく、学習範囲の99.9%は特定のユースケースと無関係である可能性がある
- ユーザーが支払う意思のある金額より、LLMベースのサービス運用コストのほうが大きくなる状況が起こりうる
- 速度も製品体験を大きく左右する
- ChatGPTのように単語を1つずつ読む体験では、遅い出力もある程度許容される
- ワークフローの次のステップに進む前に完全な応答が必要なアプリでは、遅延がそのまま使い勝手の低下につながる
- BuilderのVisual Copilotは、デザインを高品質なコードに変換するためにLLM変換を試みたが、デザイン仕様全体を入力し、トークン単位で新しい表現を受け取る過程に数分かかり、実用的ではなかった
- LLMが返す表現は人が読む形ではなかったため、ローディング状態も単なるスピナーに近く、ユーザー体験は良くなかった
fine-tuningだけでは十分にカスタマイズしにくい
- LLMはfine-tuningをサポートしているため、望む方向に近づくよう一部を調整できる
- Builderは、Figmaデザインを入力しコードを出力する方式にfine-tuningを適用したが、多くの例を提供しても品質は改善しなかった
- 結果として、遅く、高価で、品質も低いアプローチとなり、別の方法が必要になった
- 選んだ代替手段は独自ツールチェーンを作ることだった
- 今では独自モデルの学習は、データサイエンティストや機械学習Ph.D.だけができる仕事ではなく、ある程度の経験を持つ開発者でも可能だ
- このアプローチは、より高速で信頼性が高く、より安価で差別化された製品を作るのに役立つ
複雑なAI製品は1つの巨大モデルではなくツールチェーンで構成される
- AI製品に関するよくある誤解は、中核技術を1つの賢いモデルがすべて処理するという考え方だ
- 自動運転車も、カメラ、センサー、GPS入力を1つの巨大AIが受け取り、すぐに右折のような行動を出力する構造ではない
- 実際には、複数の特化モデルと通常のコードが連携している
- コンピュータビジョンモデルは物体を見つけて識別する
- 予測意思決定モデルは他者の行動を予測する
- 自然言語処理モデルは音声コマンドを理解する
- 多くの通常コードとロジックが最終結果を作る
- 自動運転車ははるかに複雑な事例であり、一般的なAI製品を始めるときにそこまでの複雑さが必要なわけではない
- 車の機能も最初から一度に完成したわけではなく、自動駐車や近接自動停止のような機能から始まり、車線逸脱補正や走行全体の意思決定へとレイヤーが追加されてきた
- ソフトウェアと同様に、AI機能も1つのレイヤーの上に次のレイヤーを積み上げる形で作られる
まず通常のコードで解き、必要な場所にだけ特化AIを組み合わせる
- Visual Copilot方式で重要な出発点は、最初からAIを使わないことだ
- 通常のプログラミング方式で問題空間を探索し、実際に特化モデルが必要な領域がどこかを先に見つけるべきだ
- Figmaデータを大量にモデルへ投入し、完成したコードをそのまま受け取る「スーパーモデル」方式は複雑すぎる
- 対応すべきフレームワークが多様
- スタイリングオプションやカスタマイズが多い
- 新しいデータを反映して継続的に再学習するのが難しい
- 複雑で遅く高価になり、製品リリース自体が難しくなる可能性がある
- Builderはまず、AIなしでどこまで行けるかを探った
- 各デザインノードをコードで表現可能な対象へ変換する必要があった
- 画像、背景、前景のような要素を細かく理解する必要があった
- どんな入力でもレスポンシブにする方法を精密に扱う必要があった
- 手書きのロジックで、縦に積まれた項目はflex column、横に並んだ項目はflex rowになるよう処理するなど、さまざまな精巧なアルゴリズムを作った
- 標準コードの限界に達した時点でAIを追加した
- どのレイヤー群を1つの画像として結合すべきかを自動検出する問題は、人間の知覚では簡単でも命令型JavaScriptコードでは容易ではなかった
- オブジェクト検出のように十分確立されたモデルタイプは、Google Vertex AIのような製品でGUIから選び、データを用意してアップロードする形で学習できる
- データ生成にはインターネットを活用できる
- puppeteerでウェブサイトをブラウザで開き、スクリーンショットを撮る
- HTMLを走査して
imgタグを探す
- 画像位置を出力データに、ウェブページのスクリーンショットを入力データに使う
- こうして下位画像の座標と元画像を確保し、オブジェクト検出モデルの学習データとして使う
- コードと特化AIモデルを組み合わせれば、デザインを選んでGenerate codeをクリックしたあと、約1秒待つだけでBuilder.ioへ移動できる
- Builderでは、完全にレスポンシブなウェブサイトとカスタマイズ可能な高品質コードを得られ、さまざまなフレームワークとオプションをサポートする
独自モデルを制御すると生まれる製品上の利点
- 独自モデルを持てば、外部モデルを単に包むだけで終わらず、モデルを継続的に改善できる
- OpenAIのような外部モデルだけに依存すると、特定ユースケースでより賢く、より速く、より安くなる時期を保証できない
- プロンプトエンジニアリングとfine-tuningだけで制御できる範囲にも限界がある
- Visual Copilotはベータ版のため、まだうまく取り込めないデザインもあるが、ユーザーフィードバックをもとに毎日改善をデプロイしている
- 独自技術を制御できれば、プライバシー要件にもよりよく対応できる
- 大規模でプライバシー重視の企業からは、OpenAIやOpenAIを利用する製品は使えないというフィードバックをよく受ける
- データが許可されていないシステムへ入ってはいけないという要件がある
- Builderは技術全体を制御しているため、高いプライバシー基準を適用できる
- LLMの段階は必須ではなく、むしろ選択肢に近いため無効化できる
- 企業は独自のLLMを接続することもできる
- 完全な社内モデル
llama2フォーク- 独自のenterprise OpenAIインスタンス
- その他のモデル
- AIは可能な限り少なく使い、通常コードは高速で信頼性が高く、決定的で、デバッグ・修正・管理・テストがしやすい基盤として残すべきだ
- 製品の魔法は、全体をAIで置き換えることではなく、小さいが決定的な領域にAIモデルを使うことで生まれる
1件のコメント
Hacker Newsの意見
記事全体の趣旨には共感するが、著者が提案した実装方法は選ばない気がする
私が得た結論は、LLMに過度に依存しないようにしようということだ。任せる作業範囲という意味でも、特定のLLMひとつに縛られるのを避けるという意味でもそう思う
たとえば社内でOpenAIを使うとしても、ChatGPTと真正面から競合する製品は長期的には不利になりうる。ホテルや航空券をチャットボットで予約するアプリを作れば、いつかChatGPTやMicrosoft、Googleが同様の機能をより上手く提供して、小規模事業を無力化する可能性が高い
OpenAI SDKのようなものに過度に依存するのも時間の無駄だと思うし、直接REST APIを呼ぶほうが柔軟だ
ただし、ツールチェーンにコンパイラを追加するのは別問題だ。コンパイラを入れるたびに不要な複雑さと特定ツールへの依存が増す。ReactやSvelteで十分なのにコンポーネントのクロスコンパイラを使うのは、Webアプリを作るために学ぶべきことがひとつ増えるように見える
記事の最終メッセージは「目標達成に最も効率的なツールチェーンを作れ」であるべきだと思う。ツールをたくさんつなげたからといって価値が生まれるわけでもなく、他人がやっているやり方に従ったからといって価値が生まれるわけでもない。これはLLMアプリ統合だけでなく、ソフトウェアエンジニアリング全般にも当てはまる
AIがこれをどう変えるのか、そして結局同じ制約にぶつからないのか、よく分からない
独特で簡単には複製されないだろうが、対応言語を考えると保守コストは莫大になるはずだ
この追加の抽象化レイヤーには少しファクトリー・ファクトリー・ファクトリー感がある
むしろAIのほうが航空券検索より専門化の余地は大きい
専門作業向けチャットボットでは、基礎的な言語解釈が今や十分に良くなっているので、汎用言語モデルの品質が最重要要素ではない。私の好みに合わせられ、関連するニッチなAPIと統合された旅行予約チャットボットは、質問を少しだけうまく解析するが何でもExpediaで予約しようとする汎用ツールに簡単には負けない
こうした市場では、一度良い推薦や悪い推薦を受けたという理由だけでブランド忠誠心や嫌悪感も生まれるので、勝者総取りに近いとは言いがたい
ブログ記事の核心は実際にはそこではなかった
彼らの製品は、FigmaのデザインファイルをReactコードへ自動変換するツールだ。この問題を普通のコードで解く手段がまさにコンパイラなのだ
みんなにコンパイラを使えと言っているわけではない
この文脈では、コンパイラ一般への批判はあまり当てはまらない。代替案はChatGPTをコンパイラのように使うことだが、記事ではそれがより悪いとかなり説得力をもって述べている。あるいは、Reactコードを生成する製品そのものが悪いと言いたいのか気になる
考えさせられる記事で、「できるだけ長くAIを使うな」という要旨には同意する
AIはAIでしかできないことに使うのが最もよい。機能を作ったり問題を解決したりするのにAIなしで可能な方法があるなら、そのほうがよい
今では誰もが最上位モデルにほぼ同じようにアクセスできるので、良い製品は結局AI以外のもの、つまりワークフロー、UI、ユーザー体験、性能のような古典的な要素で定義されるしかない
ただし、「独自モデルを訓練しろ」という助言には確信が持てない。製品を早く陳腐化させる道かもしれない。一時的に差別化できても、6〜12か月以内にOpenAIや莫大な資金を持つ競合がはるかに優れたモデルを出せば、その差別化されたモデルはそのまま技術的負債になる
小さなスタートアップがモデルで競争しようとするのは、大きな気の散り方に見える。PostgresやMySQLを使わずに独自データベースを作るのに近い。もちろん堀や複製しにくい製品は必要だが、持っているリソースで現実的に最高を目指せる領域であるべきだ
ところがChatGPTが登場すると、競合の仕事は一瞬で古くなり、彼は数週間でAI機能に追いつけた
何を作るべきかは当たっていたが理由は外れていて、結果的には事業にとって非常に大きな利益になった
差別化は実際かなり重要な要素だ
良い文章で、ほとんどの新しいAIスタートアップに刺さると思う。自分の助言は、そもそもAI製品を作らないことだ
「X製品」という枠組みは、顧客への価値追加につながることがめったにない。たとえば web3製品、可観測性製品、マシンビジョン製品、AI製品といった具合だ
まともなスタートアップのアイデアはどれもそうだが、重要なのは、新しい技術を使いたいから問題に当てはめることではなく、実際のユーザーニーズから始めることだ。期待が膨らみすぎた技術にUIを載せても、ユーザーニーズは満たされない
LLMが嫌いで言っているわけではないが、オフラインで知っている人の大半は、製品としてのチャットボットとやり取りするのを嫌っている。最近引っ越しをした際に、電気・水道・インターネット事業者のカスタマーサポートボットを相手にしたが、どれもひどかった
「GPTがすごい」から出発してカスタムチャットボットを作るのは、実際のユーザーニーズを解決したり、持続可能な事業につながったりしにくいと思う
技術にコストをかけるだけの本物の問題を見つけること自体、多くの技術者にとっては居心地のよい領域の外にある。私たちは問題が本物だと仮定したり、もっと悪い場合は本物であってほしいと願ったりしながら、すぐ解決に飛びつく。作ることのほうが慣れた領域だからだ
こうした態度やプロセス自体が間違っているわけではない。技術者が実際の問題を解決した多くのケースでは、その本物の問題は、作って、繰り返して、やめる過程で偶然に姿を現した
だから技術者にとって本物の問題を見つける最良の方法は、問題発見の段階に長くとどまることではなく、より優れたリリース・反復・中止のサイクルを持つことかもしれない。現在の利用状況を見て未来を推定し、何を作らないかを素早く決めるサイクルのことだ
複数の技術リーダーの伝記を読んだあとで、彼らを分ける中核的な能力は、ごく基本的なMVPから始めて、短時間で将来需要への直感を指数関数的に磨き上げる力なのだと思うようになった
数年前にもチャットボットはあり、ほぼすべての大企業が戦略を立てていた対象だった。コールセンターの人員を大幅に減らし、顧客体験を改善できるという発想だった
問題は会話の質だけではなかった。多くのユーザーにとって重要なのは、問題の答えを得ることだけでなく、誰か人が聞いてくれているという人間的なつながりでもあった
求めているのは、物事ができるだけ早く処理されることであって、実際に人と話すかどうかは重要ではない
これまでチャットボットが役に立たなかった理由は、プロセスに時間と苛立ちを追加したからだ。最初の段階が、チャットボットに電話番号を吐かせるか、ようやく担当者につなぐことだった
OpenAI以前のチャットボットがひどかったのは当然だ。しかしOpenAI以後のチャットボットが本当に素晴らしいなら、人々が使わない理由がわからない
数年前はブロックチェーンだった。次が何かはわからないが、すでに LinkedIn の「技術者」ネットワークが暗号資産スタートアップからAIスタートアップへ移っているのが見える
リリース速度と大きく引き換えにする選択に見える
6〜12か月かけてリリースするころには、他のチームはすでにホスティングモデルを直接使って2回は反復し、実際の顧客基盤を作っているかもしれない。そのときあなたは最初の顧客に v0.1 を見せ、顧客からは実は別のものを望んでいたと言われるかもしれない
そうなると、プロンプトを少し調整する程度ではなく、コンパイラとツールチェーン、スタックの上下を再コーディングしなければならない
顧客と要件を本当によく理解しているなら筋は通るが、これほど簡単な状況で、汎用的で高価だとしてもホスティングモデルで早期に概念検証をしないのはなぜなのか、というほうにより懐疑的だ。早すぎる最適化が諸悪の根源だという話に近い
技術やパイプラインの話は多かったが、作る製品と解く問題がなければ何の意味もない
ユーザーに SOAP がよいか REST がよいかを議論するのに似ている。ユーザーはどう作ったかなど気にしない
競争の観点から考えすぎている。簡単に複製されないものを作ればよい
方法はいろいろあるが、競争の観点で必要なルールはそれだけだ
ほぼすべての垂直市場で、市場全体の100%近い部分がまだ開かれたままだ
技術的差別化は小さな一片にすぎず、まず重要なのは到達範囲だと思う
10億ユーザーへ向かうレースであり、私たちのようなB2Bならおそらく100万ユーザーへ向かうレースだ。同時に、最高の価値、つまり解決される問題とユーザー体験のレースであって、最高の技術仕様を競うレースではない
差別化のポイントが、他者が OAI を使っても複製できないものなら、OAI を使っても安全だ
唯一の差別化要因が OAI を使っていることだけなら、どうせ失敗している
結論として示された内容にはおおむね同意する。私たちの製品も状態機械のような制御フローの中で LLM を使っていて、うまく機能している
ただし、著者のトーンには同意しない。ChatGPT のWeb UIしか触ったことがない開発者なら、「AIラッパー」技術を100%触って作ってみるべきだ
最上位モデルの限界を自分で見つけるまでは、従来のソフトウェアスタックの中で LLM をどこにどう使うべきか見えにくいからだ
著者の会社も結局この道をたどったように見える。最初は Figma からコードへの変換という LLM ベースのプロトタイプを作り、ある程度動いたあとでプロセスの隙間を見つけた
だから GPT-4-Vision のようなもので「AIベースのトレーディングカード等級判定システム」でも何でも作ってみて、その次に builder.io のように実際の製品として動かす方法を見つけるほうがよいと思う
まもなくAIはさまざまなソフトウェアに組み込まれるようになりそうだ。そのとき、本当にすごくもあり、同時に恐ろしくもあるだろう。
簡単な例はメールクライアントだ。誰かが判断や確認を求めてきたら、AIが質問を抽出してラジオボタンを提示できる。
例: 提案された予定を承諾: [金曜日 10:00] [月曜日 11:30] [別の時間を提案]
Georgeが下書きを発表できるか尋ねている: [はい] [いいえ]
Zendeskのようなカスタマーサポートのチケットソフトウェアには、すでにAIが入っているようだ。多くのサポート依頼には、すでにほぼ自動で回答されている可能性が高い。
人事部門でもAIで応募書類を選別し、インターネットで応募者に関する追加情報を調べさせたうえで、標準化されたデータベース項目を作れるだろう。もちろん、非常に欠陥が多い可能性はある。
興味深いのはこういう種類のアプリケーションであって、また別のChatGPT拡張やプラグインではない。
新しいメールごとにパイプラインを実行して、いくつかのアクションを提案させようと考えている。
まだいくつかのアプローチを頭の中で検討しているが、すでに十分実現可能に見える。
序文は少し華美すぎて、大げさな文体に見える。たとえば、LLMはそこまで高価でもないし、Copilotがユーザーごとに赤字を出しているというWSJの主張もあまり信じがたい。また、LLMが常に「耐えがたいほど遅い」とも言い切れない。
それでも、記事の実際の提言はかなり妥当だ。
できるだけ多くの部分をコードで処理し、コードではできない部分に特化型AIを使え、ということだ。
妥当ではあるが、特別に新しい話ではない。
実際に有用で優れたAI製品をどう作るかについて、もっと深く扱ってくれることを期待していた。最近もHumaneの発売のような試みは多かったが、まだ成功例は多くないように見える。
この記事はAI製品をどう作るかにかなり焦点を当てているが、個人的には「AI製品」の成功と失敗は、差別化、コスト、速度、モデルのカスタマイズよりも、本当に役に立つのかにかかっていると思う。
残念ながら、これまで見てきた製品の大半は、問題を探している解決策のように感じられる。
今、企業が進むべき道は、製品を使うときに最も退屈で反復的な部分を見つけて、それをAIで安定的に単純化する方法を探すことだと思う。
どんな過熱サイクルでもそうだが、手元にあるのが金づちだけなら、すべてが釘に見える。
少し前の金づちはブロックチェーンで、今はAIだ。
ブロックチェーンの約束にだまされるほど世間知らずだったなら、AIが時間もエネルギーも独創的な思考も不要で何百万ドルも稼がせてくれる一攫千金のねずみ講ではないと知って失望するのも当然だ。
そんなものばかり探しているなら、これからも失望し続けるだろうし、それ相応だ。
AIにはブロックチェーンよりはるかに多くのものがある。両者を同列に比較するのは、どちらのこともきちんと理解していないという意味だ。