This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
A16Z: 大規模モデル アプリケーション向けの新たなアーキテクチャ
編集者注: 生成型人工知能の爆発的な普及は、多くの業界に混乱をもたらす可能性がありますが、その 1 つがソフトウェア業界です。大規模言語モデル (LLM) の台頭により、関連アプリケーションが爆発的に増加しました。テクノロジー大手や新興企業がさまざまな LLM アプリケーションを立ち上げました。では、これらのアプリケーションはどのようなツールやデザイン パターンを使用しているのでしょうか?この記事はそれをまとめたものです。記事はまとめからのものです。
大規模言語モデル (LLM) は、ソフトウェア開発のための強力な新しいプリミティブです。しかし、LLM は非常に新しく、通常のコンピューティング リソースとは動作が大きく異なるため、LLM の使用方法が必ずしも明らかであるとは限りません。
この記事では、新しい LLM アプリケーション スタックのリファレンス アーキテクチャを共有します。このアーキテクチャでは、AI スタートアップやトップ テクノロジー企業で使用されている最も一般的なシステム、ツール、設計パターンを紹介します。このテクノロジー スタックはまだ比較的原始的なものであり、基盤となるテクノロジーの進歩に応じて大きな変更が生じる可能性がありますが、現在 LLM 開発に取り組んでいる開発者にとって有益な参考資料となることを願っています。
この作品は、AI スタートアップの創業者やエンジニアとの会話に基づいています。特に、Ted Benson、Harrison Chase、Ben Firshman、Ali Ghodsi、Raza Habib、Andrej Karpathy、Greg Kogan、Jerry Liu、Moin Nadeem、Diego Oppenheimer、Shreya Rajpal、Ion Stoica、Dennis Xu、Marei などの人々からの意見に依存しています。ザハリアとジャレッド・ゾーンライヒ。ご協力いただきありがとうございます！
LLM テクノロジー スタック
LLM アプリケーション スタックの現在のバージョンは次のようになります。
以下は、クイックリファレンスとして各項目へのリンクのリストです。
LLM を使用した開発には、モデルを最初からトレーニングする、オープンソース モデルを微調整する、マネージド API を活用するなど、さまざまな方法があります。ここで紹介するテクノロジー スタックは、ほとんどの開発者が活用し始めている (現在はベース モデルでのみ可能である) 設計パターンであるインコンテキスト学習に基づいています。
次のセクションでは、この設計パターンについて簡単に説明します。
設計パターン: コンテキスト学習
コンテキスト学習の中心的な考え方は、既製の LLM を (つまり、微調整なしで) 活用し、プライベートな「コンテキスト」データに対する賢いヒントと条件付けを通じてその動作を制御することです。
たとえば、一連の法的文書に関する質問に答えるチャットボットを開発しているとします。簡単な方法としては、すべてのドキュメントを ChatGPT または GPT-4 プロンプトに貼り付けて、関連する質問をすることができます。これは非常に小さなデータセットでは機能する可能性がありますが、拡張できません。最大の GPT-4 モデルは、約 50 ページの入力テキストしか処理できず、このいわゆるコンテキスト ウィンドウの制限に近づくと、パフォーマンス (推論時間と精度によって測定) が大幅に低下します。
コンテキスト学習は、巧妙なトリックでこの問題を解決します。LLM プロンプトが入力されるたびにすべてのドキュメントを送信するのではなく、最も関連性の高い少数のドキュメントのみを送信します。どれが最も関連性の高い文書かを決定するのに誰が協力しますか?ご想像のとおり...LLM。
非常に高いレベルで、このワークフローは 3 つのフェーズに分類できます。
これらは大変な作業のように思えるかもしれませんが、通常は他の方法よりも実装が簡単です。LLM のトレーニングや LLM 自体の微調整は実際にはより困難です。コンテキスト学習を行うために機械学習エンジニアの専任チームは必要ありません。また、独自のインフラストラクチャをホストしたり、OpenAI から高価な専用インスタンスを購入したりする必要もありません。このモデルは、AI の問題を、大企業だけでなくほとんどのスタートアップ企業もすでに解決方法を知っているデータ エンジニアリングの問題に効果的に還元します。また、特定の情報を記憶するために LLM を微調整するには、トレーニング セット内で特定の情報が少なくとも約 10 回発生する必要があり、コンテキスト学習には新しい情報を組み込むこともできるため、比較的小さなデータセットの微調整よりも優れたパフォーマンスを発揮する傾向があります。ほぼリアルタイムのデータで。
コンテキスト学習における最大の疑問の 1 つは、基礎となるモデルを変更してコンテキスト ウィンドウを増やすとどうなるかということです。それは確かに可能であり、活発な研究分野です。ただし、これにはいくつかのトレードオフが伴います。主に推論のコストと時間は、ヒントの長さに応じて二次関数的に変化します。現在、線形スケーリング (最良の理論的結果) でさえ、多くのアプリケーションにとってコストが高すぎます。現在の API レートでは、10,000 ページを超える単一の GPT-4 クエリには数百ドルの費用がかかります。したがって、拡張コンテキスト ウィンドウに基づくスタックへの大規模な変更は予想されませんが、これについては後ほど詳しく説明します。
この記事の残りの部分では、上記のワークフローをガイドとして使用して、このテクノロジー スタックについて説明します。
データ処理/埋め込み
LLM アプリケーションの コンテキスト データ には、テキスト ドキュメント、PDF、さらには CSV や SQL テーブルなどの構造化フォーマットが含まれます。私たちがインタビューした開発者が採用したデータの読み込みと変換 (ETL) ソリューションは多岐にわたりました。ほとんどは、Databricks や Airflow などの従来の ETL ツールを使用します。 LangChain (Unstructed を利用) や LlamaIndex (Llama Hub を利用) など、オーケストレーション フレームワークに組み込まれたドキュメント ローダーを利用するものもあります。ただし、テクノロジー スタックのこの部分は比較的未開発であり、LLM アプリケーション専用のデータ レプリケーション ソリューションを開発する機会があると考えています。
埋め込みに関しては、ほとんどの開発者が OpenAI API、特に text-embedding-ada-002 モデルを使用しています。このモデルは使いやすく (特に他の OpenAI API をすでに使用している場合)、かなり良い結果が得られ、さらに安価になっています。一部の大企業も Cohere を検討しています。Cohere の製品は埋め込みに重点が置かれており、一部のシナリオではパフォーマンスが向上しています。オープンソースを好む開発者にとって、Hugging Face の Sentence Transformers ライブラリは標準です。ユースケースに応じて、さまざまなタイプの埋め込みを作成することも可能です。これは今日では比較的ニッチな実践ですが、有望な研究分野です。
システムの観点から見ると、前処理パイプラインの最も重要な部分は ベクター データベース です。ベクトル データベースは、最大数十億のエンベディング (別名ベクトル) を効率的に保存、比較、取得する役割を果たします。市場で最も一般的なオプションは松ぼっくりです。これはデフォルトであり、完全にクラウドでホストされており、大企業が本番環境で必要とする多くの機能 (大規模なパフォーマンス、シングル サインオン、稼働時間 SLA など) を備えているため、簡単に始めることができます。
ただし、利用可能なベクトル データベースも多数あります。注目すべきものには次のようなものがあります。
今後、ほとんどのオープンソース ベクトル データベース企業がクラウド製品を開発しています。私たちの調査によると、クラウドで堅牢なパフォーマンスを達成することは、想定されるユースケースの広範な設計空間において非常に困難な問題であることがわかりました。したがって、オプションセットは短期的には劇的に変化しないかもしれませんが、長期的には変化する可能性があります。重要な問題は、ベクトル データベースが OLTP データベースや OLAP データベースと同様の 1 つまたは 2 つの一般的なシステムを中心に統合されるかどうかです。
ほとんどのモデルで利用できるコンテキストのウィンドウが拡大するにつれて、埋め込みデータベースとベクトル データベースがどのように進化するかという未解決の問題もあります。コンテキスト データをプロンプトに直接入れることができるため、埋め込みの重要性が薄れると簡単に主張できます。しかし、このテーマに関する専門家からのフィードバックは、事実は逆であること、つまり組み込みパイプラインが時間の経過とともにより重要になる可能性があることを示唆しています。大きなコンテキスト ウィンドウは確かに強力なツールですが、かなりの計算コストも必要になります。したがって、この窓口を有効に活用することが不可欠です。さまざまなタイプの埋め込みモデルが普及し、モデルの関連性を直接トレーニングし、これを可能にして活用するように設計されたベクトル データベースが登場する可能性があります。
プロンプトのビルドと取得
LLM を促進し、コンテキスト データを組み込む戦略はより洗練されており、製品差別化の源泉としても使用されており、その役割の重要性が増しています。ほとんどの開発者は、直接的な命令 (ゼロショット ヒント) またはいくつかの例を含む出力 (フューショット ヒント) を含む単純なヒントを試して、新しいプロジェクトを開始します。これらのヒントは通常、良好な結果をもたらしますが、運用環境の展開に必要な精度のレベルには達しません。
ヒント トリックの次のレベルは、モデルの応答を何らかの真実の情報源に基づいて行い、モデルがトレーニングされていない外部コンテキストを提供することです。キュー エンジニアリング ガイドには、思考連鎖、自己一貫性のある生成的知識、思考ツリー、方向性刺激などを含む、十数 (!) ものより高度なキューイング戦略がリストされています。これらの戦略を組み合わせて、ドキュメント Q&A、チャットボットなどのさまざまな LLM ユースケースをサポートできます。
ここで、LangChain や LlamaIndex などのオーケストレーション フレームワークが登場します。これらのフレームワークは、ヒント チェーンの詳細の多くを抽象化し、外部 API との対話 (API 呼び出しが必要なタイミングの決定を含む)、ベクター データベースからのコンテキスト データの取得、複数の LLM にわたる呼び出し間のメモリの維持を行います。また、上記の一般的なアプリケーションの多く用のテンプレートも提供します。その出力は、言語モデルに送信された 1 つまたは複数のヒントです。これらのフレームワークは、愛好家だけでなく、アプリケーション開発を検討しているスタートアップ企業にも広く使用されており、そのリーダーが LangChain です。
LangChain はまだ比較的新しいプロジェクト (現在バージョン 0.0.201) ですが、LangChain を使用して開発されたアプリケーションがすでに運用され始めています。一部の開発者、特に LLM の初期導入者は、追加の依存関係を削除するために実稼働環境で生の Python に切り替えることを好みます。しかし、従来の Web アプリケーション スタックの場合と同様、この日曜大工のアプローチはほとんどのユースケースで減少すると予想されます。
鋭い読者は、レイアウト ボックスに奇妙な見た目のエントリ ChatGPT があることに気づくでしょう。通常の状況では、ChatGPT は開発者ツールではなくアプリです。ただし、API としてアクセスすることもできます。そして、よく見ると、カスタム ヒントの必要性の抽象化、状態の維持、プラグイン、API、またはその他のソースを介したコンテキスト データの取得など、他のオーケストレーション フレームワークと同じ機能の一部を実行します。 ChatGPT はここにリストされている他のツールの直接の競合相手ではありませんが、代替ソリューションと考えることができ、最終的にはプロンプト ビルドの実行可能で簡単な代替手段となる可能性があります。
ヒントの実行/推論
現在、OpenAI は言語モデルの分野のリーダーです。私たちがインタビューしたほぼすべての開発者は、OpenAI API を使用して新しい LLM アプリケーションを起動しました。通常、彼らは gpt-4 または gpt-4-32k モデルを使用します。これは、アプリのパフォーマンスに最適なユースケース シナリオを提供し、幅広い入力ドメインを使用でき、多くの場合、微調整や自己ホスティングが必要ないため使いやすいです。
プロジェクトが実稼働に入り、規模が拡大し始めると、より幅広いオプションが利用できるようになります。よく聞かれる質問には次のようなものがあります。
これは通常、オープンソースの基本モデルの微調整と組み合わせるのが最も合理的です。この記事ではこのツール スタックについては詳しく説明しませんが、Databricks、Anyscale、Mosaic、Modal、RunPod などのプラットフォームがエンジニアリング チームによって使用されることが増えています。
オープンソース モデルは、Hugging Face と Replicate のシンプルな API インターフェイス、主要なクラウド プロバイダーからの生のコンピューティング リソース、および上記のようなより明確な設定を持つクラウド製品 (独自のクラウド) など、複数の推論オプションを使用できます。
現在、オープンソース モデルはプロプライエタリ製品に比べて遅れをとっていますが、その差は縮まり始めています。 Meta の LLaMa モデルは、オープンソースの精度の新しい標準を設定し、さまざまな亜種を生み出しました。 LLaMa は研究用途のみにライセンスされているため、多くの新しいプロバイダーが代替ベース モデル (Togetter、Mosaic、Falcon、Mistral など) のトレーニングを開始しています。 Meta は、LLaMa 2 の真のオープンソース バージョンをリリースするかどうかをまだ議論しています。
オープンソース LLM が GPT-3.5 に匹敵する精度レベルに到達すると (そうでない場合ではありません)、大規模な実験、共有、実稼働環境へのモデルの微調整が行われ、テキストにも独自の安定拡散モーメントが生じることが期待されます。 Replicate のようなホスティング会社は、ソフトウェア開発者がこれらのモデルをより利用しやすくするためのツールを追加し始めています。開発者は、より小型で細かく調整されたモデルが、狭い範囲のユースケースに対して最先端の精度を達成できると信じています。
私たちがインタビューした開発者のほとんどは、LLM の 運用ツール について深く理解していませんでした。キャッシュはアプリケーションの応答時間を改善し、コストを削減するため、比較的一般的です (多くの場合 Redis に基づいています)。 MLflow を使用した重みとバイアス (従来の機械学習から移植) や Helicone を使用したレイヤー (LLM 用に構築) などのツールも、かなり広く使用されています。これらのツールは、多くの場合、チップ構造の改善、パイプラインの調整、モデルの選択を目的として、LLM の出力を記録、追跡、評価できます。また、LLM 出力を検証したり (ガードレールなど)、ヒント挿入攻撃 (Rebuff など) を検出したりするための新しいツールも多数開発されています。これらの運用ツールのほとんどは、独自の Python クライアントに LLM 呼び出しの実行を促すため、これらのソリューションが時間の経過とともにどのように共存するかを見るのは興味深いでしょう。
最後に、LLM アプリケーションの静的な部分 (つまり、モデル以外のすべて) もどこかにホストする必要があります。私たちがこれまでに見た中で最も一般的なソリューションは、Vercel や大手クラウド プロバイダーなどの標準オプションです。ただし、2 つの新しいカテゴリが出現しています。 Steamship のようなスタートアップは、オーケストレーション (LangChain)、マルチテナント データ コンテキスト、非同期タスク、ベクトル ストレージ、キー管理などの LLM アプリケーションのエンドツーエンド ホスティングを提供します。 Anyscale や Modal などの企業では、開発者がモデルと Python コードを 1 か所でホストできるようにしています。
プロキシについてはどうですか?
このリファレンス アーキテクチャに欠けている最も重要なコンポーネントの 1 つは、人工知能エージェント フレームワークです。 AutoGPT は「GPT-4 を完全に自動化するための実験的なオープンソースの試み」と言われており、この春には歴史上最も急成長している Github リポジトリとなり、今日のほぼすべての AI プロジェクトやスタートアップには何らかの形式の AI が組み込まれています。 。
私たちが話を聞いた開発者のほとんどは、プロキシの可能性に非常に興奮していました。この論文で説明するコンテキスト学習モデルは、幻覚やデータの鮮度の問題に効果的に対処できるため、コンテンツ生成タスクをより適切にサポートできます。一方、エージェントは、AI アプリケーションにまったく新しい機能セットを提供します。つまり、複雑な問題を解決し、外部世界に作用し、導入後のエクスペリエンスから学習します。これは、高度な推論/計画、ツールの使用、記憶/再帰/内省的思考の組み合わせを通じて行われます。
そのため、エージェントは LLM アプリケーション アーキテクチャの中核部分になる可能性があります (再帰的な自己改善を信じている場合は、テクノロジ スタック全体を引き継ぐことさえ可能です)。 LangChain などの既存のフレームワークには、プロキシの概念の一部がすでに組み込まれています。問題が 1 つだけあります。それは、プロキシがまだ実際には機能していないことです。現在のほとんどのエージェント フレームワークはまだ概念実証の段階にあり、素晴らしいデモンストレーションを提供していますが、タスクを確実かつ反復的に実行することはできません。私たちは、このプロキシが近い将来どのように発展するかを注視しています。
未来を見据えて
事前トレーニングされた AI モデルは、インターネット以来、ソフトウェア アーキテクチャにおける最も大きな変化を表しています。これにより、個人の開発者は数日で驚異的な AI アプリケーションを作成できるようになり、大規模なチームによる開発に数か月かかった教師付き機械学習プロジェクトさえも上回ります。
ここにリストするツールとパターンは、LLM を統合するための開始点であり、最終的な状態ではありません。また、重大な変更 (モデル トレーニングへの移行など) があった場合も更新し、意味のある場合は新しいリファレンス アーキテクチャを公開します。