こんにちは。AIボードルームへようこそ。今日はAIソリューションのスケーリングについてお話しします。エドガー、今日のトピックについて簡単に説明してもらえますか。
はい、もちろんです。皆さん、こんにちは。今日は私たちの大好きなトピックの1つである、実際の製品を構築し、それをスケールさせることについて少しお話ししたいと思います。1回のエピソードですべてをカバーすることはできませんが、今日は一般的な考え方についてお話しします。AIのプロトタイプから製品へと移行するとはどういうことか、実際に何をスケールする必要があるのか、そして最後に、社内でAIをスケールさせたい場合に、物事を構築するか購入するかについての考慮事項についても見ていきます。
では、プロトタイプと本格的な製品の違いは何か、なぜプロトタイプを本番レベルのシステムとみなすことができないのかについて掘り下げてみましょう。
これは、最初の本格的なAI製品を構築する前から、そしてその後も、多くの場面で遭遇したことです。今日のAIツールを使えば、説得力のあるプロトタイプを作るのがこれまで以上に簡単になりました。さらに興味深いのは、AIがあなたのために物事を構築できることです。
私のソフトウェアの場合、最初のプロトタイプは一晩で構築しました。AIの部分は数ヶ月を通してあまり変わりませんでした。もちろん、改良や最適化、プライバシーの問題などはありましたが。しかし、実際に人々がガイダンスなしで、誰かが隣に座っていなくても使える製品にするためには、周りのすべてが違います。
プロトタイプは非常に狭い範囲で動作しますが、それを数時間で簡単に作ることができます。しかし、そこから実際に異なるデータ、異なる文書、異なるタイプの文書で動作するものにするのは別物です。
私たちが作業した最初の4社は、文書のレイアウトなどが完全に異なっていました。プロトタイプは狭い範囲では魅力的に動作しますが、少しでも快適なゾーンから外れると、物事は激しく壊れてしまいます。
そうですね。プロトタイプでは、特定の目的に関連するいくつかのことを検証しているだけです。特定の問題から解決策に至る最短のパスを見つけようとしているだけで、ユーザーインターフェースや本番レベルの機能など、すべての機能を考慮しているわけではありません。
短時間では使用可能にならないのは、UX
のベストプラクティス、デザイン、ワークフローへの統合などを考慮していないからです。文字通り、誰かが直面している問題からAIで解決できることを実証するために、可能な限り短時間で解決策にたどり着こうとしているだけです。
そして、それが解決されたと考えたら、次は本番稼働の準備を整えるためにどうするかを検討します。そこで他のステークホルダーやさまざまな機能が関わってきて、セキュリティ、エクスペリエンス、製品化されたソリューションに必要なすべてのベストプラクティスの提供に焦点を当てることになります。
特にセキュリティの問題は非常に重要です。多くの場合、プロトタイプ作成時にはデータのサブセットや1つの文書、1つのデータ例を使用します。より多くのデータを取り込む段階で最初の疑問が生じます。AIが正しい解決策を提供しているかどうかという問題自体ではなく、実際にどのようにしてデータをセキュアな環境やソリューションに取り込むかという問題です。
プロトタイプを検討する際には、概念実証を行うためにどのようなデータが代表的かを考える必要があります。結局のところ、より多くのデータを投入し、うまく機能しないことを発見し、調整する必要があります。
私は今、16年以上前からプログラミングを始めて以来、製品を作り続けていますが、AIにおいてプロトタイプから製品に移行するのが、これほど難しかったことはありません。以前は入力があれば出力があるというものでしたが、AIはそうではありません。それは良いことですが、同時に独自の課題も伴います。
生成AIによってゲームが変わったと思います。実際、本番レベルに近い出力を得るのが以前よりも速くなりました。モデル自体や出力は大きく変わらないでしょう。必要なものはほぼ揃っていますが、カスタムデータに基づく機能、例えばインデックス作成や元のソースへのリンク、グラウンディングなどの機能は含まれていないかもしれません。これらは追加の要素ですが、情報や出力自体はモデルが変わるわけではありません。
本当に完全なソリューションを得たいと思い、それらの基本的な部分に取り組む意欲があれば、カスタムデータで動作するソリューションを非常に短時間で得ることができます。ただし、それは私たちが本番レベルと考えるものではありません。
私は「エンタープライズグレード」と呼ぶのが好きです。エンタープライズグレードとは、スケールで動作し、多くの介入なしで動作する必要があるということです。これは議論の余地がありますが、少なくとも私が目指していたものです。そして、使いやすさが悪くてはいけません。
もはやローカルなノーコードやリアルコードをプログラミングしたり構築したりしているわけではありません。Aを行うとBからDまで、場合によってはZまで得られます。あなたの仕事は基本的に、AからFまでのシステムを設定し、AからCまでを行い、残りのシステムがこの変動性で動作するようにすることです。
幻覚にどう対処するか、間違った回答をどうやって軽減するか、事前にフィルタリングするにはどうすればいいか。これらを行うことはできますが、それは何を意味するのでしょうか。ソリューションにより多くの複雑さを加えることになりますか。応答時間が増加しますか。まだ使用可能ですか。これらすべてを考慮する必要があります。
そして、これは単にアプリケーション部分だけではありません。私が大きく過小評価していた非常に大きな部分は、インフラストラクチャです。まず、モデルをどこにデプロイするかという問題があります。誰も企業のデータを外部に渡したがりません。エンタープライズレディとは、企業が許可なしにデータを渡さないということです。コンプライアンス部門や弁護士、そして物事を秘密に保つことに非常に興味を持つ多くのステークホルダーがいます。
ここで、ソリューションの一側面について考える必要があります。適切な出力を得ることは、実際に有用であるかどうかです。私は常に最低でも80%の時間を目標にしています。これが実際に有用になる閾値だと思います。それ以下は「4回中3回」のカテゴリーに入り、人々がまだ使用するかどうかを考える必要があります。完璧である必要はありませんが、人々が実際に何らかの信頼を置くのに十分良くなければなりません。
そうですね。その数字をどのように導き出すのかという点について補足させてください。私たちが使用した例の1つは、有用だと考えられるものと比較する、または根拠付けをする方法です。業界のベンチマークを使用することができます。誰かが同様の問題に取り組もうとした場合、どのような結果を得ているでしょうか。彼らが80%に達しているのに対して、あなたのソリューションが60%であれば、おそらくもう一度反復して強化し、少なくとも業界のベンチマークに到達できるように作業する必要があります。
既存のツールを刷新する場合は、既存のツールの出力精度を例として使用することもできます。たとえばルールベースのシステムで、包括性や正確性を評価する場合、データが古くて結果が出ないかもしれませんが、それは問題ありません。2つのシステムで比較可能な結果を出し、古いシステムがこのレベル、たとえば40%のパフォーマンスだったとします。それ以下にはできません。本番レベルと考える前に、それをわずかでも上回るパーセンテージが価値を提供したことになります。60%に達していれば、レガシーソフトウェアよりも20%多くの価値をAIソリューションで提供したことになります。
興味深いですね。十分に良いと考えられる基準や、実際に本番環境にプッシュする前の判断方法、そして潜在的に提供された価値を定量化する方法について、さまざまなアプローチがあります。
また、あなたが言及したことに付け加えると、特にAIの場合、モニタリングや説明可能性、バックグラウンドでのダッシュボードを持つことが非常に重要です。多くのクラウドプロバイダーは、モデルをデプロイしてモデルのモニタリングや説明可能性を行うためのツールを提供しています。これらのシステムを監視する人々のために、バックグラウンドで構築することもできます。
また、ユーザーエクスペリエンスに組み込まれるべきコンポーネントもあります。GDPRやその他の考慮事項のために、おそらくいずれにせよ考慮する必要があります。ユーザーはアルゴリズムがどのように決定に至ったかを知りたがるでしょう。そのため、より多くのシステムがソースへのリンクを開始しているのを目にします。これは、モデルが推奨事項をどのように導き出したかについての説明可能性の要件を満たすためです。
興味深いですね。それは確かに別の角度ですね。現在のソリューションが40%の時間しか有用でない場合、60%は大きな改善であり、実際に有用になります。これも重要なポイントです。物事がうまくいかなかったからといって、すぐに落胆しないでください。MVPとして「十分に良い」ことを目指し、そこから構築していってください。
私が犯した最大の間違いの1つは、完成した製品を人々に届けることすらできませんでした。最初の主要ユーザーやテストユーザーと話をし、彼らが多くのことを語り、これやあれが欲しいと言っていました。私はそれをすべて書き留め、素晴らしいシステムを思いつきました。しかし、その背後にある労力を完全に過小評価していました。まだ方法は分かっていると思いますが、すべての複雑さを含めてそれを機能する状態にするのは、想像以上に難しいのです。
すべての機能やベルアンドホイッスルを揃えようとすると、どんなソリューションにも到達できなくなります。最初に設定した使用事例に焦点を当て、それを機能させてから、徐々に慎重に追加していってください。これは現在のAIシステムでも、以前のすべてのソフトウェアシステムでも同じです。複雑さは加速度的に増加し、より小さなステップを踏んでいれば避けられたはずのエラーに遭遇することになります。
常に、本当にその機能が必要かどうか、それを追加せずに対処できないかを考えてください。まだ実際に有用であると考えられる最小限の機能セットを考え、そこから始めてください。
これを誰が担当するのかについて触れると、製品側の誰か、つまり製品マネージャーが担当することになります。戦略を決定し、何が十分に良いかを評価し、本番環境にプッシュし、フィードバックを収集する人です。製品担当者、製品マネージャー、製品オーナーなど、チームの誰かがフィードバックを見て優先順位をつけることができます。
すべてを提供するとは言わず、最初の構築の一部として、完全なソリューションと考えられるものについていくつかの成功指標を持つべきです。能力の観点から話し、ユーザーとしてXYZができるべきだと言います。これらの基準を満たせば、それがプロジェクトの第一段階として考えられ、相互に合意したものになります。それ以外のものは迅速なフォローアップになります。
製品のその段階の後のフィードバックについて話していましたが、それでも優先順位をつけて、次の反復ではXYZを行う必要があると言う必要があります。そうすることで、すべてが進んでいきます。これらの機能を決して提供しないということではなく、ユーザーエクスペリエンスにとって最も重要なもの、解決しようとしている問題に最も重要なものを優先順位付けする必要があるということです。
最終的にはロードマップを作成することになりますが、そのような継続的なフィードバックループが欲しいのです。時間が経つにつれて、予期していなかったことが出てくるかもしれません。私はそれらをエッジケースと呼んでいます。構築したものに対して、3ヶ月後に誰かが「最悪のシステムだ。100万回に1回しか起こらないことを考慮せずに、どうしてこれを本番環境にリリースできたのか」と言うようなことです。
予期できないことがあり、青い月に一度しか起こらないような出力があるかもしれません。それを解決したいと思いますが、影響も評価する必要があります。次に優先すべきか、他のものを優先すべきかを判断するために、複数の要素を評価する必要があります。
しかし、そのフィードバックはロードマップの構築を継続し、機能を強化し続けることになります。おそらくこれらの機能の多くを処理した後に何が起こるかというと、モデルを更新し、他の強化を行う必要が出てくるでしょう。サービスは古くなるので、常にやるべきことがあります。
フィードバックループがあるため、完全に停滞しているAIシステムはありません。常にやるべきことがあり、そのことを強調したいと思います。多くの機能や複雑さがあると言いましたが、それは大丈夫です。製品を管理し、優先順位付けを助ける人がいる限り、内部か外部かに関わらず、ユーザーに継続的に価値を提供し続けることができます。
そのため、多くのAI企業がロードマップを公開し始めたのだと思います。「あなたの声を聞きました。ロードマップを見れば、その機能がいつ導入されるかが分かります」というメッセージを伝えています。彼らが認識し、価値に応じて優先順位付けしていることを示しています。AIだけでなく、ソフトウェア企業全般がそうし始めています。
機能を構築しないでくださいと言っているのではありません。すべての機能から始めないでくださいと言っているのです。これが重要なポイントです。また、物事は大きく変化するので、この巨大な機能セットを思いつきました。
1つの例を挙げると、私は履歴サポートチャットを分析して応答を改善するために読み込もうとしていました。原則としては良いアイデアですが、まずこれらのサポートチャットを分類する必要があります。日付で分離することはできますが、結局のところ、AIソリューションを使ってテキストを分析し、新しい会話が始まったかどうかを判断しようとしました。もちろん、これは混乱を招き、全く必要ありませんでした。基本的な機能は、これがなくても十分に機能します。
これには何週間もかかり、プロジェクトの他のステークホルダーが出力を待っている間、私は「もうすぐ終わります」と言い続けていました。しかし、最初から必要なかった機能を正しく実装できなかったので、決して終わりませんでした。
これが私が言いたいことです。シンプルに保ち、実際のユーザーフィードバックを得た後、本当にそれを使用している人々からのフィードバックを得た後に、機能を追加していってください。
例えば、今私たちは自分たちでロードマップを作成し、この機能を見ました。来年でさえ実装するかどうか分かりません。それほど既にピボットしています。まだロールアウト段階ですが、大きく方向転換しました。
今では、例えば音声チャットの方がこのような機能よりも優先順位が高いと考えています。基本機能は、音声インタラクションを追加すればさらに有用になるでしょう。この全履歴機能は良いアイデアでしたが、プログラマーの夢のようなアイデアで、実際にはそれほど有用ではありませんでした。
これが、製品の計画で完全に的外れだった実世界の実践的な例です。今では、ソフトウェアの提供に直接関係のない開発を数歩後退させ、停止さえしました。今年は、既存のものを安定させ、改善することだけに注力します。安定したプラットフォームがあれば、その上に何でも構築できますが、まず第一に、スケーラブルなソリューションの前提条件である安定性を確保する必要があります。
そうですね。私はそれが大好きです。製品の観点から話せることがたくさんあります。ロードマップの実際の作り方について、誰かが興味があれば喜んでお話しします。あなたが行ったことについて言っているのではありません。多くの実験が行われ、過去にも多くの教訓があります。
時には、プロジェクトの最初に思いついたことは、ユースケースの理解だけに基づいた推測ゲームのようなものです。実際に本番環境に投入し、実際のユーザーフィードバックを得るまでは分かりません。そのため、時にはロードマッピング自体が欠陥があるかもしれません。12〜18ヶ月先のものを構築することがありますが、それに固執すると完全に的外れになる可能性があります。
だからこそ、タイプを再評価する必要があるのです。何か
を構築しようとしていて、1つか2つの間違いを犯さないのであれば、それは間違っています。常に教訓があり、「これだと思っていたけど、実際には人々がこれを評価する方法が全く異なる」と思うことがあるでしょう。
ピボットの準備をしておく必要がありますが、優先順位をつけてください。ここでの教訓は、短期的に知っていることを優先し、それに従い、最小限の重要な機能を実装し、本番環境にプッシュし、フィードバックを得て、反復を続けることです。
なぜなら、ユーザーフィードバックを得ずに推測ゲームで完全な機能セットを目指そうとすると、エクスペリエンスを間違える可能性があるだけでなく、多くの時間を投資してしまうからです。
そうです。その時間の損失は非常に痛いです。特に物事を外に出すという点で、時間は貴重です。出さないでいることは…
そして、最初のプレゼンテーションを作り始めると、約束しすぎて提供できなくなります。ただ「これが製品です。これがあなたのユースケースであれば役立ちます。そうでなければ、より大きな製品ができるまで待つ必要があるかもしれません」と言ってください。
あなたが解決しているソリューションが既に十分に良く、最初からすべてのベルとホイッスルは必要ないという自信を持ってください。その後、フィードバックを受け取り、それに基づいて構築し、拡張していきます。
最良のケースでは、スタートアップを持っていて新しいソリューションがある場合、既に販売を開始し、お金を得て、より多くの人を雇用し、より大きなチームでより複雑なことができるようになります。そのようにアプローチすべきです。
私の間違いを繰り返さないでください。各プロジェクトをミニスタートアップとして運営してください。
そのマインドセットが大好きです。なぜなら、スピードと提供される価値を最適化しているからです。スタートアップにいるなら、プロジェクトへの投資額が非常に限られており、できるだけ早く製品を市場に出す必要があります。
そのフレームワークでは、「この製品が最低限何をする必要があるか」と考えます。顧客にピッチしたときに「これが必要だ」と思わせるために、機能的で価値を提供し、ターゲットオーディエンスにとって望ましいものである必要があります。
将来のことにあまりこだわらないでください。包括的であることを確認しますが、やりすぎないでください。やりすぎると、追加の時間と投資を行う価値があるかどうかの推測ゲームになってしまいます。
ユーザーに語らせ、特定の機能をもっと欲しいかどうかを教えてもらいましょう。それがまた優先順位付けの演習になりますが、プロトタイプからスケールへの移行時間を短縮することもできます。
もちろん、物事を行う一つの方法は構築することですが、単に購入するという選択肢もあります。「なぜMicrosoftのCopilotとどう違うのか」と聞かれることもあります。Copilotがこれをできるかと聞くと、「いいえ」と答えます。それが違いです。そして、我々のコストは3分の1です。
これは、顧客だけでなく、あなた自身も考慮すべき点です。すべてを一から構築することは決して良いアイデアではありませんでした。多くのオープンソースやクローズドソースのものがあり、それらを考慮することができます。
例えば、自動化されたワークフローのために新しいZapierを構築するのではなく、既存のZapierを適応させて使用することができます。これは基本的に、プロトタイプ段階のすべてのAIソリューションに当てはまります。
最小限の労力でプロトタイプを構築しようとし、それがChatGPTに入力するだけであれば、それで完璧です。実際のソリューションに取り組む前に、最小限のアプローチをとってください。
Gen AIが始まったとき、大量の翻訳が必要なプロジェクトがありました。当時はGPT-3.5を使用しました。なぜなら、コンテキストの中で翻訳することができたからです。「これがコンテキストで、これがソースです。ドイツ語や英語に翻訳してください」と言うと、素晴らしい仕事をしてくれました。
コーディングを行う前にこれをテストする方法は、いくつかのキャプションをChatGPTに投げ込んで、結果を見ることでした。ほとんどの場合うまく機能することが分かったので、何かを構築することにしました。
これが当時のアプローチ方法でしたし、今でもそうするでしょう。自分で再び構築するでしょうか。そうは思いません。多くのオープンソースの翻訳ソリューションがあるので、それらの1つを使用して作業するでしょう。
構築対購入を考える際にも、スペクトルがあると思います。以前、LinkedInでこれに関する投稿をしたことがあります。興味があれば遡って見てみてください。
基本的に、ソリューションを購入する場合、複数の方法があります。購入する場合、既製のソリューションを購入できます。基本的にパッケージ化されたサブスクリプションを購入し、ログインして使用を開始し、文書をアップロードします。ChatGPTはその良い例です。
OpenAIのモデルをライセンス供与することもできます。基本的には既存のモデルを購入しますが、ソフトウェアレイヤーとカスタマイズを構築します。完全に購入というわけではありません。なぜなら、カスタマイズ作業を行うからです。ほとんど両者のミックスのようなものです。
独自のモデルを構築する必要がないため、ライセンス料を支払っています。そして、もちろん構築する場合は、既存のモデル、コード、オープンソースツールが、あなたが探している同じ利点を提供しないと考えています。
これは、「自分で再び構築するだろうか」というあなたのコメントに戻ります。時には、あなたがいる現在の状況で、あなたが必要とするものを行うツールがない場合があります。そして、時にはそれを実際に構築することが理にかなっています。
機械学習、コンピュータビジョン、独自のデータに基づいてカスタマイズする必要があるものについて話しています。時には、ビジネス価値を提供する場合には意味があります。しかし、多くのソリューションは、ビジネスでどこで機能する必要があるかに応じて、このスペクトルのどこかに落ち着くでしょう。
購入と構築のタイプのミックスは、現在のソフトウェアやAPIがこれらのプラットフォームを通じて非常に民主化されているという点でも現れると思います。以前話したように、Pythonライブラリが広く利用可能なので、これらの機能の多くを開発する必要さえありません。
カスタムAIソリューションの「構築」の現実は、既存のライブラリ、モデル、ツールをすべて1つのアプリケーションの下で統合することです。その一部は、既存のコード、モジュラーサービス、APIを使用し、その上に最小限のソフトウェアレイヤーを構築する経験があります。
これは可能です。実際には購入タイプのソリューションと考えられます。なぜなら、依然としてライセンス供与しているからです。しかし、一部のレイヤーをカスタマイズしているので、構築でもあります。
知的財産は実際にこれらのソリューションをどのように組み合わせるか、その背後にある論理、そして統合された顧客体験をサポートするために上に重ねるコードにあります。私はIP法の訓練を受けているので、これは興味深い点です。
ニュースのエピソードの1つで話したRabbit R1についても、彼らは単に物事を再パッケージ化しただけではありません。GPT-3.5を使用し、音声翻訳にElevenLabsを使用し、それらを再パッケージ化して何かを作り上げましたが、結局のところ、彼ら独自のプロンプト以外には多くのことをしていません。
これが最良の方法だとか、物事をどのように進めるべきだとは言いません。しかし、何を活用できるかを考えてください。最も重要なのは、提供されるビジネス価値に焦点を当て、そこに到達する最速の方法を見つけることです。
Sが言ったように、オーケストレーションはほとんどの場合、ゲームの半分です。それ以外の、適応や統合が必要なもの、個人的なものは、努力を費やす価値があります。しかし、最初のスケーラブルな実行に到達する前に、すべてを構築することは避けるべきです。
話すべきことがたくさんありますね。もっと深く掘り下げることができると思います。間違いなく、もっと多くの製品に関するエピソードが続くでしょう。
いつものように、特定のトピックや、サンプルアプリケーション、ユースケース、特定のニーズをAIでどのように解決するかについて興味があれば教えてください。そのトピックに深く掘り下げることを喜んでお手伝いします。あなたに価値を還元することを確実にしたいと思います。
購読を忘れないでください。私たちはあなたたちのためにこれを行っていて、あなたたちのサポートは私たちにとって非常に重要です。
はい、確かに。聞いていただきありがとうございます。製品開発について話すのが大好きです。コンセプトにどのようにたどり着くか、アイデアをどのように評価するかなど、話すべきことがたくさんあります。
コメントで次に何を聞きたいか教えてください。今日簡単に触れたトピックで、もっと聞きたいものがあれば教えてください。ここでも、LinkedInでも教えてください。
画面のどこかに、私たちの以前の話からおすすめの動画を表示します。ビジネスアプリケーションのAIについてもっと聞きたい場合は、次の動画をご覧ください。ありがとうございました。さようなら。
コメント