ブログ | CTO オフィス

AI アプリケーション アーキテクチャを理解する

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2024年7月23日公開

AI アプリケーションは実際にはどのようなものなのでしょうか? いくつか構築した後は、それを(多くの)部分に分解し、運用上の影響を検討するのに良い時期であると思われます。 

これまで、 AI アプリケーションについて、何が同じなのか (多くの点)、何が異なるのか (多くの点) について検討してきました。 AI アプリケーションを「予測的または生成的なAI を活用するアプリケーション」と定義するのは簡単です。 

それは本当ですが、これらの新しい種類のアプリケーションを構築、展開、提供、保護、運用する必要がある人々にとって、それは何を意味するのでしょうか? 

まず、それは新しい可動部品を意味します。 推論サービスだけではありません。 ベクター データベースなど、アプリケーション アーキテクチャへの標準追加になりつつある他の新しいコンポーネントもあります。 また、 APIへの依存度が高まることも意味します。 

これらのコンポーネントのほとんどがコンテナ化されていることも事実です。 新しい AI アプリケーション プロジェクトをセットアップするときは、ベクター データ ストアとして使用するために PostgreSQL を実行するコンテナーを起動します。 これは、複数の業界レポート(たとえば、 Databricks のレポート)によると、AI アプリケーションのかなりの割合で使用されている RAG (検索拡張生成) をサポートするためです。 それは、自分でモデルを微調整したりトレーニングしたりすることなく、好きなデータを使用して標準の AI モデルを拡張できるからです。 かなりの数のユースケースでは、これが AI アプリケーションを実装する最良の方法です。 

また、通常は Neo4J のようなコンテナ化されたグラフ データベースを実行して、ナレッジ グラフを起動することもあります。 グラフ データベースは、ソーシャル ネットワーク、推奨エンジン データ、不正検出などのグラフ アファイン データを扱う場合に特に役立ちます。 今年初めに判明したように、これらは政策生成に関連する幻覚を軽減するのにも役立つことが判明しました。 グラフ データベースを組み込むと、新しいプロトコルである GraphQL が「保護が必要な新しいもの」のリストに追加される可能性があります。 

次に、どの推論サービスを使用するかを決定します。 選択肢はあります。 クラウド プロバイダー サービスや AI as a Service (ChatGPT など) を使用することも、ローカル サービスを実行することもできます。 たとえば、私の最近の作業では、MacBook でOllamaphi3 を使用しました。 この場合、推論サーバーのコピーを 1 つだけ実行しています。複数実行すると、持っているリソース以上のリソースを消費してしまうためです。 もちろん、生産段階では、需要に対応できるようにするために、さらに多くのインスタンスが必要になる可能性があります。 

私は phi3 を使用する予定なので、推論サービスにアクセスするためのフレームワークとしてphidata を選択します。 私は AI をサービスとして活用する際にもlangchain を使用しました。これは人気のある選択肢ですが、運用の観点から見ると、フレームワークはコア AI アプリケーション自体の外部で動作するものではないという良い点があります。 

AI アプリケーションの運用への影響

まだ 1 行もコードを書いていないのに、すでに複数のコンポーネントが実行されており、それぞれが API 経由でアクセスされ、独自のコンテナーで実行されています。 そのため、私たちは、AI アプリケーションは最新のアプリケーションであり、配信、セキュリティ、運用に関して、これまでと同じ課題をすべて伴うという前提から始めます。 また、AI モデルの導入により、配信とセキュリティを必要とする API の数が大幅に増加すると私たちは考えています。 

アプリケーションアーキテクチャグラフィック
運用上の課題は付加的であり、新しいアーキテクチャごとに新たな課題が追加されたり、既存の課題が拡大したりします。

AI アプリケーションは、すでに複雑な環境に別の層を追加するため、当然ながら複雑さが増します。 つまり、AI アプリケーション アーキテクチャにより、セキュリティから SRE、ネットワークに至るまで、すべての運用機能の負荷が増加することになります。 これらの各コンポーネントには、独自のスケーリング プロファイルもあります。つまり、一部のコンポーネントは他のコンポーネントよりも高速にスケーリングする必要があり、ほとんどのコンポーネントが異なる API と、場合によってはプロトコルを活用しているため、リクエストの分散方法は異なります。 

さらに、AI アプリケーション アーキテクチャは内部的に大きく変化することになります。 つまり、私が構築する AI アプリケーションは、あなたが構築する AI アプリケーションとは異なるローカル トラフィックの特性とニーズを示す可能性があります。 そして、異質性が増すということは、当然複雑さが増すことを意味します。それは、同質性を促進する標準化とは逆だからです。 

標準化は、何十年もの間、企業が新しい機能を市場へ提供することを加速し、運用効率を高めながら、AI アプリケーション アーキテクチャの多様性に対処するために必要な人的リソースを解放するための手段となってきました。 

このため、一部の共有サービス、特にアプリと API のセキュリティが、サービスとしてのセキュリティのようにエッジに移行しつつあります。 このような共有サービス セットは、すべての環境 (コア、クラウド、エッジ) にわたってワークロードをより適切に保護できるだけでなく、AI アプリケーション全体の標準として機能する共通のサービス セットも提供します。 

AI アプリケーションの構造を理解することで、必要なアプリケーション配信およびセキュリティ サービスの種類だけでなく、それらが必要な場所も判断できるようになります。