AIは、従来ソフトウェアでは手の届かなかった市場を破壊する大きな可能性を秘めています。たとえば自然言語、画像、物理的な空間など、ナビゲートするためにこれまで人間に頼ってきた市場です。こうした市場は巨大な機会であり、世界的に何兆ドルもの価値がある可能性があります。
しかし、前回の記事「AI ビジネスと従来のソフトウェアビジネスとの違い」(日本語訳)で説明したように、従来のソフトウェアと同じような魅力的な経済的特性を持つAI企業を構築することが困難な場合があります。AI企業は、粗利益率が低く、スケールアップが難しく、常に強力な防御の壕を持っているわけではないことが多いのです。私たちの経験からすると、課題の多くは問題領域に固有のものであるように考えられ、すべてのケースで従来のソフトウェアの経済性を保証するシンプルなプレイブックはまだ見つかっていません。
とはいえ、多くの経験豊富なAI企業の構築者は、素朴なアプローチと比較して、自社の財務状況を改善することについての多大な進歩を遂げています。彼らはデータエンジニアリング、モデル開発、クラウド運用、組織設計、製品管理、その他多くの分野にまたがる様々な方法でこれを行っています。これらの手法に共通しているのは、解決すべき問題を深く実践的に理解していることです。
前回の記事では、AIビジネスが直面している課題について概説しましたが、今回の記事の目的は、それらにどうやって取り組むかについての指針を提供することです。私たちは、何十もの主要な機械学習チームとの公式および非公式の会話を通して学んだ教訓、ベストプラクティス、および獲得した秘密の一部を共有しています。ほとんどの場合、これらは彼らの言葉であり、私たちの言葉ではありません。最初のパートでは、問題理解がなぜ重要なのか、特にロングテールのデータ分布の存在下で、前回の記事で提起した経済的な課題とリンクさせて説明します。第2部では、MLチームがよりパフォーマンスの高いアプリケーションを構築し、より収益性の高いAIビジネスを構築するのに役立つ戦略をいくつか紹介します。
私たちは、AIのビジネスの可能性に非常に強気であり、この分野に多額の投資を続けています。この記事が議論の火付け役となり、永続的なAI企業を構築するためのファウンダーをサポートすることを願っています。
注:この記事の焦点は、コア機能の大部分を機械学習(主に教師付き学習)に依存しているAI企業や製品であり、MLツール/インフラストラクチャやアドオンのML機能を含む従来のソフトウェアではありません。
第一部:解決すべき問題を理解する
ビルディング vs 実験(または、ソフトウェア対AI)
ある後発のデータスタートアップのCTOが言うように、AI開発はソフトウェア工学よりも「製薬における化合物の発見に近い」*と感じることが多くあります。
これはAI開発が化学や物理学のように、実験のプロセスだからです。AI開発者の仕事は、統計モデルをデータセットに適合させ、そのモデルが新しいデータでどれだけうまく機能するかをテストし、それを繰り返すことです。これは本質的に、現実世界の複雑さを抑制する試みです。
一方、ソフトウェア開発は、構築とエンジニアリングのプロセスです。アプリケーションの仕様と全体的なアーキテクチャが定義されると、完全なビジョンが形になるまで、一度に一行のコード、ライブラリ、またはAPIコールを追加して、新しい機能を少しずつ追加していくことができます。このプロセスの大部分は開発者の管理下にあり、モジュール化、計装、仮想化、適切な抽象化の選択などの標準的なコンピュータサイエンスのプラクティスを使用して、結果として得られるシステムの複雑さを抑制することができます。
ソフトウェア工学とは異なり、AIアプリケーションでは開発者がコントロールできることはほとんどありません。そして多くの自然なシステムでは、データはしばしば乱雑で、ヘビーテールで、予測不能で、非常にエントロピーなものになります。さらに悪いことに、開発者によって書かれたコードは、プログラムの動作を直接変えるものではありません。ある経験豊富な創業者はこのような比喩を使いました。「MLは本質的にコードを作成するコードです(入力データの関数として)。これにより、理解を難しくする非直接的な追加レイヤーが作られます」
AI開発者の仕事は、統計モデルをデータセットに適合させ、そのモデルが新しいデータでどれだけうまく機能するかをテストし、それを繰り返すことです。これは本質的に、現実世界の複雑さを抑制する試みです。
クリックしてツイートする
ロングテールと機械学習
効率的なAI企業を構築する上での困難の多くは、多くの自然システムや計算システムで十分に文書化されているデータのロングテール分布に直面したときに起こります。
概念の正式な定義はかなり濃密なものになりますが、その背後にある直感は比較的単純です。もしあなたがロングテール分布からデータ点をランダムに選んだ場合、そのデータ点はテールにある可能性が非常に高い、ということです(この記事では、少なくとも50%以上、おそらくそれ以上としましょう)。
インターネットの検索キーワードを例に考えてみましょう。分布の "先頭 "と "中間 "にある人気のあるキーワード(下の青で示されている)は、全キーワードの30%未満を占めています。残りの7割のキーワードは「テール」にあり、月間検索数は100件以下です。分布のどこに位置するキーワードであっても、クエリの処理には同じ量の作業が必要であると仮定すると、ヘビーテールシステムでは作業の大部分はテールに集中することになります。しかしそこはクエリの価値は比較的低いのです。
ロングテール分布は機械学習においても非常に一般的であることが明らかになってきており、これは現実世界の状況と典型的なデータ収集の慣行を反映しています。例えば、これらのチャートは、いくつかの一般的なAI研究データセットにおけるモデルクラスの頻度を示しています。
このようなタイプの分布は必ずしも悪いものではありません。しかし、インターネット検索の例とは異なり、現在のML技術はこれらを扱うのに十分な装備を持っていません。教師付き学習モデルは、一般的な入力(すなわち分布の先頭)ではうまくいく傾向がありますが、例がまばらな場合(末尾)には苦戦します。末尾部がすべての入力の大部分を占めることが多いため、MLの開発者は新しいデータを収集し、エッジケースを考慮して再学習を行うというループを繰り返してしまいます(それが無限に続くように見えることもあります)。そして、テールケースを無視することも同様に苦痛です。なぜなら結果として、顧客の機会を逃したり、経済性が悪くなったり、ユーザーが不満を感じたりすることになるからです。
テールがすべての入力の大部分を占めることが多いため、MLの開発者は、新しいデータを収集し、エッジケースを考慮して再学習を行うという、一見無限に見えるループに陥ってしまいます。
クリックしてツイートする
AIの経済性への影響
ロングテールとそれが生み出す作業は、AIビジネスを構築する際の経済的な課題の主な原因であることが判明します。
最も直接的な影響は、データと計算リソースのコストです。正確な結果を得るためには、非常に多くのデータ、非常に多くの実験、そして非常に多くのパラメータが必要となるため、これらのコストは従来のソフトウェアよりもMLの方がはるかに高くなることが多くなります。逸話によると、AIアプリケーションの開発コスト(および失敗率)は、一般的なソフトウェア製品の3~5倍になることがあります。
しかしクラウドのコストに焦点を絞ると、ロングテールがもたらす2つの悪影響を見逃してしまいます。第一に、ロングテールはインフラ以外にも高い変動コストをもたらす可能性があることです。例えば、チャットボットに送信される質問が顧客によって大きく異なる場合、つまり質問の大部分がロングテールである場合、正確なシステムを構築するためには、顧客ごとにかなりの作業が必要になる可能性があります。残念ながら、ソリューションスペースの分布にもよりますが、この作業と関連するCOGS(商品販売コスト)は、技術的には難しいかもしれません。
さらに悪いことに、ロングテールの問題に取り組んでいるAIビジネスは、実際にスケールの不経済(日本語訳)を示すことがあります。データには、収集、処理、維持するためのコストがかかります。このコストはデータ量に比べて時間の経過とともに減少する傾向にありますが、データポイントの追加による限界利益ははるかに早く減少します。実際、この関係は指数関数的であるように見えます。ある時点で、開発者は主観的な改善を2倍にするために10倍のデータが必要になるかもしれません。処理性能を劇的に向上させ、コストを削減するムーアの法則に類似したAIを期待したくなりますが、それは実現していないようです(アルゴリズムの改善はともかく)。
以下では、これらの問題をどのように考え、取り組むべきかについて、多くの実務家から集められたガイダンスを紹介します。
第二部:より良いAIシステムの構築
解決に向けて
多くのAIシステムは、複雑な基礎となるシステムの相互作用を予測するように設計されており、その結果、入力データのロングテール分布が得られます。開発者は通常、データを完全に特性化することができないため、一連の(教師付き)学習実験を通してデータをモデル化します。このプロセスは膨大な量の作業を必要とし、かつパフォーマンスの点では漸近点に達する可能性があり、AI企業が直面している経済的な課題の多くを引き起こしたり、悪化させたりします。
これがAIビジネスのジレンマの核心です。この経済性が問題の特性であり、技術そのものではないとしたら、どのようにして問題を改善することができるのでしょうか。
簡単な答えはありません。ロングテールはある意味では、解決しようとしている問題の複雑さの尺度であり、つまりそれがそもそも自動化を必要とする理由であり、それに取り組むために必要な労力と直接相関しています。しかし、ロングテールを一次的な関心事として扱い、それに向けて構築する方法があります。
私たちは、このトピックについてMLのエンジニアや研究者から多くの素晴らしいアドバイスを聞きました。以下では、その中から最も優れた、最も革新的なアドバイスをいくつか紹介します。
ロングテールは、ある意味では、解決しようとしている問題の複雑さを表す指標であり、それに取り組むために必要な労力と直接関係しています。しかし、これを一次的な関心事として扱い、それに向けて構築する方法もあります。
クリックしてツイートする
イージーモード: 境界のある問題
最も単純なケースでは、問題を理解するということが、つまり実際にロングテール分布を扱っているかどうかを識別することを意味します。もしそうでない場合、例えば、問題が線形または多項式制約で合理的に記述できる場合、メッセージは明確です:機械学習を使用しないでください!特に深層学習は使わないようにしましょう。
これは、AIの専門家のグループからの奇妙なアドバイスのように見えるかもしれません。しかし、前回の記事(日本語訳)で説明したコストは相当なものである可能性があり、その背後にある原因は、この記事の最初の部分で説明したように、回避するのが難しいという現実を反映しています。これらの問題はまた、モデルの複雑さが増すにつれて悪化する傾向があります。また不適切に使用された場合には、単純な手法よりもパフォーマンスが悪くなり、小さなデータセットをオーバーパラメー タライズしたり、本番では急速に劣化する脆弱なモデルを生成したりする傾向があります。
MLを使用する場合、ロジスティック回帰やランダムフォレストが人気があるのには理由があるとShopifyのエンジニアは指摘しています。大規模でより洗練されたモデルの方が、多くの場合、より良いパフォーマンスを発揮します(例:言語理解や生成、動きの速いソーシャルメディアのトレンドを把握するためなど)。しかし精度の向上がトレーニングやメンテナンスコストの大幅な増加を正当化するかどうかを見極めることが重要です。
別のMLリーダーが言うように、「MLは宗教ではなく、科学であり、工学であり、ちょっとしたアートです。MLのアプローチの語彙は非常に多く、私たち科学者はすべての問題を完成したばかりのハンマーに合う釘と見なしがちですが、正確に見れば問題は時にはネジであるかもしれません」***
より難しい問題: グローバルロングテール問題
ロングテールの問題、たとえば最も一般的なNLP(自然言語処理)、コンピュータビジョン、その他のMLタスクを含む問題に取り組んでいる場合、顧客、地域、セグメント、その他のユーザコホート間での一貫性の度合いを決定することが重要です。重複度が高い場合は、グローバルモデル(またはアンサンブル)でほとんどのユーザーにサービスを提供できる可能性があります。これは、粗利益とエンジニアリング効率に大きなプラスの影響を与える可能性があります。
このパターンは、大規模なユーザー・データセットにアクセスできるB2Cのテック企業でよく見られます。また、自律走行車、不正検知、データ入力などの比較的エントロピーの低い環境で、制約のないタスクに取り組んでいるB2Bベンダーでも、同じような利点があることがよくあります。そうした領域では、デプロイメント時の設定がユーザーの行動に与える影響が軽微だからです。
このような状況では、(大手顧客などの)ある程度のローカルトレーニングが必要になることがよくあります。しかし、グローバルなコンテキストで問題をフレーム化し、ロングテールを中心に積極的に構築することで、その必要性を最小限に抑えることができます。これを行うための標準的なアドバイスは以下の通りです。
- より多くのトレーニングデータ(顧客データを含む)を追加したり、ハイパーパラメータを調整したり、モデルアーキテクチャを微調整したりしてモデルを最適化する。
- ユーザーがシステムに入力できる内容を明示的に制限することで問題を絞り込みます。これは問題が「ファットヘッド」(高価値の連絡先に焦点を当てているデータベンダーなど)であったり、ユーザーエラーの影響を受けやすい場合に最も有効です(例:Linkedinでは、オートコンプリートを実装するまではIBMに関連するエンティティが17,000件あったとされています)。
- 問題を変換して、シングルターンのインターフェース(コンテンツフィード、製品提案、「あなたが知っているかもしれない人」など)にしたり、ユーザーの入力を促す/例外的なケースをカバーするために人間のフェイルオーバーを設計する(自律走行車のテレオペなど)。
しかし現実世界の多くの問題では、このような方法では実現できない場合があります。そのような場合には、経験豊富なMLビルダーがコンポーネント化と呼ばれるより一般的なパターンを共有しています。
例えば、CloudflareのMLエンジニアは、ボット検出に関連した例を共有していました。彼らの目標は膨大なログファイルを処理して、何百万ものウェブサイトへの人間以外の訪問者を識別する(そしてフラグを立てたりブロックしたりする)ことでした。「ボット」という概念には、検索クローラー、データスクレーパー、ポートスキャナなど、ユニークな行動を示す何百もの異なるサブタイプが含まれていたため、これを単一のタスクとして扱うことは、規模的に効果的ではありませんでした。しかしクラスタリング技術を使用し、様々なレベルの粒度の実験を行った結果、最終的には6~7種類のボットを発見し、それぞれが独自の教師付き学習モデルで対応できるようになりました。彼らのモデルは現在、インターネットの重要な部分で実行されており、ソフトウェアビジネスのような粗利でリアルタイムの保護を提供しています。
コンポーネント化は、広告の不正検知、ローンの引受、ソーシャルメディアのコンテンツモデレーションなど、多くの大規模なプロダクションMLシステムで使用されています。重要な設計要素は、各モデルが特定の顧客ではなく、グローバルなデータのスライスに対応していることと、サブ問題が比較的限定されていて推論が容易であることです。深い専門知識に代わるものはありません。
コンポーネント化では、各モデルはグローバルなデータのスライスに対応しており、サブ問題は比較的限定されており、推論が容易です。
クリックしてツイートする
本当に難しい問題: 局所的なロングテール問題
多くの問題は、顧客や他のユーザの間でグローバルな一貫性を示さないことが多く、私たちが話を聞いたほとんどすべてのMLチームは、少なくともいくつかのローカルな問題があることがいかに一般的であるかを強調していました。また、(特に企業の場合)入力データは、商業的な理由や規制上の理由で分離されている場合があるため、重複を判断することは容易ではありません。グローバルな問題とローカルな問題の違いは、利用可能なデータの範囲にあることがよくあります。
局所的なMLの問題は、まだ多くの場合、対処しなければならないロングテールの分布を持っています。しかし局所的なばらつきの程度に応じて、作業はあっという間に増えてしまうことがあります。例えば、ある大手音楽ストリーミング会社は、事業を展開している国ごとに独自のプレイリスト生成モデルが必要であることを発見しました。工場のフロア分析ベンダーも同様に、サービスを提供する顧客や組立ラインごとに独自のモデルが必要になることがよくあります。これを簡単に解決することはできませんが、いくつかの戦略を使えば、グローバルモデルの利点をローカルな問題空間にもたらすことができます。
近い将来の実用的な選択肢として、メタモデルパターンがあります。これは、単一のモデルを学習して、さまざまな顧客やタスクをカバーするものです。この手法は、研究の場(マルチタスクロボットなど)で最もよく議論される傾向があります。しかし、AIアプリケーション企業にとっては、維持しなければならないモデルの数を大幅に減らすこともできます。例えば、あるマーケティングのスタートアップ企業は、何千ものオフラインの顧客固有のモデルを1つのメタモデルにまとめることができました。その結果、とても少ないお金で再訓練することができました。
もう一つの新しいソリューションは、転移学習です。MLチームの間では、事前に学習されたモデル、特にBERTやGPT-3のようなアテンションベースの言語モデルを使用することで、全体的にトレーニングの必要性を減らして簡素化することができ、最終的には少量のデータで顧客ごとにモデルを微調整することがはるかに容易になるという熱狂的な声が広がっています。これらの技術の可能性を疑う余地はありません。しかし現在、これらのモデルを本番で多用している企業は比較的少なく、その理由の一つにはモデルのサイズが大きいために運用が難しくコストがかかること、また多くのアプリケーションで顧客固有の作業が必要なことが挙げられます。この有望な分野の利点は、まだ広くは実現されていないようです。
最後に、大規模なテック企業の数人の実務家は、トランクモデルに基づいた転移学習の一種であると述べています。例えば、Facebookは何千ものMLモデルを保持していますが、そのほとんどは特定のタスクのために別々に訓練されています。しかし時間が経つにつれて、似たような機能を共有するモデルを共通の「トランク」で結合して複雑さを軽減することができるようになります。目標は、トランクモデルを可能な限り「太い」(つまり、ほとんどの作業を行う)ものにする一方で、タスク固有の「枝」モデルを可能な限り「細い」ものにし、精度を犠牲にせずにすることです。公表された例では、自動化された製品説明に取り組んでいるAIチームは、家具用、ファッション用、自動車用など、7つの垂直方向に特化したモデルを1つのトランク付きアーキテクチャに統合し、2倍の精度と実行コストを実現しました。
このアプローチは、限定的に言えば、グローバルモデルのパターンによく似ています。同時に、並行してモデルを開発し、高度なローカル精度を実現することができます。また、データサイエンティストが作業するためのより豊富なデータを提供し、いくつかのO(n^2)問題(言語翻訳のように、n個の言語のそれぞれをn個の他の言語に翻訳しなければならない)を、O(n)複雑さに変換することができます。これは、ML開発プロセスの基本的な構成要素やAPIを定義するのに役立つ、将来の方向性を示しているかもしれません。
自動化された製品説明に取り組んでいるAIチームは、家具、ファッション、自動車などの7つの垂直方向に特化したモデルを1つのトランク型アーキテクチャに統合し、2倍の精度と実行コストを実現した。
クリックしてツイートする
最低限必要なこと: オペレーション
最後に、多くの経験豊富なMLエンジニアは、AIの経済性を向上させるための運用上のベストプラクティスの重要性を強調していました。これらは、最も説得力のある例です。
データパイプラインを統合する。モデルのスプロールはパイプラインのスプロールを意味する必要はありません。グローバルモデルが実現不可能な場合、ある創業者は、ほとんどの顧客を単一のデータ変換プロセスに統合することで、システムのレイテンシへの影響を比較的軽微に抑え、効率性の向上を実現しました。他のグループでは、再トレーニングの頻度を減らし(毎晩のキューや十分なデータが蓄積されたときなど)、データに近いところでトレーニングを実行することでコストを削減しました。
エッジケースエンジンを構築する。ロングテールが見えなければ、ロングテールには対応できません。例えば、テスラは、オートパイロットモデルをトレーニングするために、奇妙なストップサインの膨大なデータセットを構築しました。ロングテールデータを再現可能な方法で収集することは、ほとんどのMLチームにとって重要な能力です。通常、本番では分布のないデータを特定し(統計的テストや異常なモデルの挙動を測定することで)、類似した例を調達し、新しいデータにラベルを付け、インテリジェントな再学習(多くの場合、能動学習を使用)を行います。
インフラを所有する。多くの先進的なML組織では、独自のMLクラスタを運用しています(設計もしています)。あるCEOは、AWSからコロケーション施設でホストされている自社のGPUボックスに切り替えることで、年間1000万ドルを節約したそうです。創業者にとって重要なのは、どの程度の規模でコスト削減がメンテナンス負担を正当化するのか、また、クラウドの価格カーブがどの程度のスピードで下がるのかを見極めることです。
圧縮、コンパイル、最適化。モデルの大規模化が進むにつれ、効率的な推論とトレーニングをサポートするテクニック(量子化、蒸留、プルーニング、コンパイルなど)が不可欠になってきています。これらの技術は、事前に訓練されたモデルや自動化されたAPIによっても利用できるようになってきています。これらのツールは、ほとんどのAI問題の経済性を変えるものではありませんが、スケールでのコスト管理を支援することができます。
テスト、テスト、テスト。これは当たり前のことのように聞こえるかもしれませんが、複数の専門家はMLチームにテストを優先させるよう奨励しています。F値のような古典的なメカニズムに基づくものではありません。機械学習のアプリケーションは、しばしば非決定論的な方法でパフォーマンスを発揮する(そして失敗する)ことがあります。「バグ」は直感的ではなく、不良データや精度の不一致、暗黙のプライバシー侵害などによってもたらされることがあります。また、アップグレードは日常的に何十ものアプリケーションに触れており、下位互換性はありません。これらの問題は、データ分布、期待されるドリフト、バイアス、敵対的な戦術、その他のまだ成文化されていない要因のロバストなテストを必要とします。
—
人工知能と機械学習は、その形成段階から、より実用的で効率的な開発と運用の時代へと、誇大広告サイクルのピークを迎えようとしています。ロングテールやその他の問題については、まだ膨大な量の作業が残っており、ある意味ではソフトウェア開発の慣れ親しんだ構造を再発明しなければなりません。AIの経済性が従来のソフトウェアと完全に一致することはないでしょう。しかし、このガイドが会話を進め、経験豊富なAIビルダーからの素晴らしいアドバイスを広める一助となることを願っています。
著者紹介 (本記事投稿時の情報)
Martin Casado は Andreessen Horowitz のジェネラルパートナーです。彼は以前、2012年に VMWare に買収された Nicira の共同創業者で CTO でした。VMWare で、Martin はNetworking and Secruity Business のVPならびにGMでした。
Matt Bornstein は Andreessen Horowitz のエンタープライズディールチームのパートナーです。現在の人工知能の波を支える新しいデータシステムとテクノロジーに焦点を当てています。彼は、AI/MLの新しいアプリケーションを発見し、創業者がこの新しいクラスの製品がもたらすビジネス上の課題を解決するのを支援することを使命としています。
a16zに入社する前、Matt はシードステージのベンチャーキャピタルであるBlumberg Capitalのメンバーとして、Pachyderm、SigOpt、SmithRxなどの企業への投資を率いていました。また、LinkedInのBizOpsチームで働き、Monitor Groupで経営コンサルタントを務め、2つのスタートアップをブートストラップで共同設立しました。
Mattはハーバード・ビジネス・スクールでMBAを、ブラウン大学で数学の理学士号を取得しています。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: Taming the Tail: Adventures in Improving AI Economics (2020)