OpenAIの内蔵検索を解剖する：ストレージの制約、性能のギャップ、コストの懸念を明らかにする
OpenAIから最新の発表があった後、私はOpenAI Assistantsがプロダクションレベルのアプリケーションに適しているのか疑問を持ち始めた。特に、20ファイルの制限と1GBあたり0.2ドル/日という制限がある。これを念頭に置いて、私は3つのトピックに焦点を当てた記事を書いた。
OpenAIアシスタントのナレッジベースに$0.2/GB/日は高いか？
OpenAIの公開情報をもとに、OpenAIの内部ソリューションを掘り下げる。
AIアシスタントのナレッジベースのインフラはどのような方向に進化すべきか？
注：以下の内容にはいくつかの計算が含まれています。これらの詳細な計算をご覧になることもできますし、ハイライトされた結論に焦点をあてて簡単に概観することもできます。
OpenAIアシスタントの知識ベースのコスト
簡単な計算をしてみよう：
Office 365は1TBあたり月額6円。Google Workspaceは1TBあたり月額8ドル。
OpenAI Assistantsの場合は、0.2(GB)×30(日)×1024(GB)=6,144円/TB/月となります。
したがって、OpenAI Assistantsを使って私のオフィス文書にAIアシスタントを追加すると、従来の文書サービスよりも3桁高いコストがかかることになります（￢6ドル vs￢6,144ドル）。これは高いのか？私は「そうだ！」と言いたい。
| サービス内容 | ----------------------------- | ------------ | | 従来のドキュメント・サービス｜6ドル/TB | OpenAIアシスタント｜6,144ドル/TB
OpenAI側の運用コストも簡単に計算してみよう。以下の分析は少し複雑ですが、結論はシンプルです：1GBのドキュメントを処理するためには1.5GBのベクトルを生成する必要があり、このベクトルを処理するためのサーバーコストは1日あたり約1,000円です。高い？1GBあたり0.20ドルですから、それに比べれば安いものです。面白いですね！
| プライシング | | --------------------- | ----------------- | | OpenAIのコスト | 0.2/GB/日
これが見積もりです：
OpenAIのtext-embedding-ada-002モデルを使って、検索用のvectorsを生成する1GBのテキストを考えます。1KBのテキストごとに、このモデルは1536次元の埋め込みを作成します。各ベクトルの次元はfloat32に対応し（したがって1ベクトルあたり6KB）、入力テキストと出力ベクトルのサイズ比は1:6、すなわち1GBのテキストは6GBのベクトルに対応する。つまり、1GBのテキストは6GBのベクターに相当します。量子化によってベクターを圧縮すると、4:1の圧縮比になり、1GBのテキストは1.5GBのベクターに相当します。
1.5GBのベクトルを提供するためのサーバーコストを考えてみましょう。経済的なAWS EC2インスタンスを選ぶと、1.5GBのメモリごとに毎日約0.30ドルのコストがかかる。このシナリオは、ベクターの保存と検索のみを想定しているため、妥当以上である。メタデータ、モニタリング、ログ、インデックスファイル、マルチレプリカによる高可用性のコストなど、本番環境で必要となる他の要素は含まれていない。
コスト分析の結論
OpenAIの新機能「Assistants」は、1GB/1日あたり"＄0.2 "の価格設定に対し、"＄0.3 "とサーバーコストが高いため、利益以上のコストがかかっています。しかし、アシストを利用したい開発者は、従来のドキュメントサービスの1,000倍以上の料金を支払わなければなりません。そのため、コストを正当化するためには、従来のドキュメントサービスよりも3桁高いビジネス価値を生み出さなければならない。
この価格モデルは、B2Cビジネスでは正当化できるかもしれない。月数十ドルのコストがかかる数GBのデータは、個人ユーザーにとって大きな問題にはなりにくいからだ。しかし、大規模なデータを扱うB2Bビジネスでは、このコストは事業収益を大きく損なうか、事業価値を上回る可能性さえある。例えば、パーソナライズされた顧客サービスや、特許や法律文書のインテリジェントな検索システムを構築するには、法外なコストがかかる可能性がある。
OpenAIのソリューションを掘り下げる
OpenAIアシスタントの現在のスキームを分解してみよう。公開されている情報を紹介しよう：
アシスタント1人あたり最大20ファイル
1ファイルあたりの上限は512MB
1ファイルあたり200万トークンという隠れた制限。
テキストのみサポート。
OpenAI DevDayの後、サーバーのトラフィックが大幅に増加しました。トライアルユーザーの数と作成されたアシスタントの数は公表されていませんが、かなりの数になるはずです。
OpenAIの検索サービスを解剖する
上記の公開情報をもとに計算してみよう。
- ユーザーは20ファイルまでで、それぞれの上限は200万トークン。1チャンク（ベクターに対応）あたり200トークンと仮定すると、1ユーザーあたり20万ベクターが上限となる。
| ユーザーあたりのファイル数｜トークン数｜ベクター数｜の制限 | -------------------- | ------------------------ | ----------------- | | / | 200 | 1 | | 1ファイル｜2,000,000（上限）｜10,000｜｜です。 | 20ファイル｜40,000,000（上限）｜200,000｜｜。
- ほとんどのユーザーは1ファイルあたり200万トークンの制限に達しないので、各ユーザーのファイルには平均400,000トークンが含まれると見積もることができ、これは2,000ベクトルに相当する。ユーザーあたりの上限200,000ベクターと平均2,000ベクターを考慮すると、1000:1のオーバーセル比率を達成することは可能です。
| -------------------- | -------------------- | ----------------- | | / | 200 | 1 | | 20ファイル｜400,000（平均）｜2,000｜です。
さらに、OpenAIは相当数のユーザーを抱えているため、安定したシステムを維持し、あらゆる災害の影響を効果的に管理する必要がある。そのため、OpenAIアシスタントの開発の初期段階では、超大規模なクラスターソリューションを選択する可能性は低い。その代わりに、OpenAIは、より良い安定性のために、各ユーザーグループがマイナーなベクトルデータベースインスタンスを共有できるシステム(下図)を作成する可能性が高い。
OpenAIアシスタントの検索機能の簡易アーキテクチャ](https://assets.zilliz.com/A_Simplified_Architecture_of_Open_AI_Assistants_Retrieval_Feature_b369e8f292.png)
各物理ノードが32GBのメモリを持ち、4つのPodに分割されているとします。各Podは個別のベクトルデータベースインスタンスをホストし、Podには8GBのメモリが割り当てられる。3GBはベクターデータベースシステム専用で、5GBはユーザーベクターデータ提供用に予約されている。
1ユーザーあたりのベクターの上限を20万とすると、量子化されたベクターとそのインデックスは約500MBのメモリーを必要とする。したがって、各Podはオーバーセルすることなく10ユーザーを収容することができます。しかし、オーバーセルの比率が1000:1であれば、1つのPodで最大10,000人のユーザー（少なくとも数百人のアクティブユーザー）にサービスを提供できます。その結果、4つのPodで構成される1つのサーバーで40,000ユーザーを収容できます。
このアーキテクチャーは、トライアルユーザーをサポートするには十分と思われる。しかし、各物理ノードには、有料顧客向けに最大20GBのベクトルとインデックスを保存できる可能性があり、これは原文の約8GBに相当する。総容量では、1日あたりの収益の可能性は1.6ドルと控えめで、際立って低い。
注：大きなファイルを持つ複数のユーザーが単一のPodを共有する極端なケースでは、スケジューリングによって潜在的な課題を軽減することができます。例えば、新しいPodをデプロイすることで、これらの大規模ユーザーからの負荷を効率的に移行することができます。
クイック・サマリー
OpenAIの検索サービスアーキテクチャは、トライアルユーザーにはうまく機能するが、より広範なデータを必要とする大企業をサポートするには十分に拡張できない可能性がある。
現在のアーキテクチャーはユーザーデータにストレージの制限を課しており、潜在的な利益を減らし、コストを増加させている。
さらに、顧客によっては各クライアントに個別のアシスタントを必要とする場合があるため、このアーキテクチャはアプリケーションレイヤーマルチテナンシーには不適切です。OpenAIフォーラム](https://community.openai.com/t/assistants-api-retrieval-pricing-how-much-does-this-cost/485188/3)のディスカッションをもっと見る。
OpenAIアシスタントの知識ベースが十分でない理由
前回、OpenAIアシスタントの限界とそのアーキテクチャについて説明しました。では、どうすればこの課題に対処し、コストを削減できるのだろうか？最も効果的な解決策は、サービスのアーキテクチャを最適化することだろう。
解決策を掘り下げる前に、最適化されたシステム・アーキテクチャへの道を開く重要な要因を考えてみよう。
洗練されたベクター・データベース・ソリューション：ハイブリッド・ディスク／メモリー・ベクトル・ストレージ
ベクターデータベースは通常、クエリ応答を高速化するために、ベクターとインデックスをメモリにロードする。しかし、アシスタントアプリケーションは典型的なRAG（Retrieval Augmented Generation）ユースケースであるため、パフォーマンスのボトルネックはベクトルデータベースのクエリプロセスではなく、大規模言語モデル（LLM）の推論にある。このような場合、超高速なベクトル検索応答は必要ない。LLMに合わせてベクトルデータベースの性能を意図的に落とすことで、費用対効果とストレージ機能の拡張のバランスをとることができる。有望な手段のひとつは、ホットデータのみをメモリにロードするディスクベースのベクトルデータベースソリューションの検討である。このアプローチは、ハードウェアコストを大幅に削減するだけでなく、システム全体のストレージ容量を増強する。
災害復旧の合理化：システムデータのプール
現在、OpenAI Assistantはディザスタリカバリのためにやや強引なアプローチを採用しており、各Podに個別のベクターデータベースインスタンスを割り当て、各Podのメモリの1/3以上をシステム用に割り当てています。しかし、分離が必要なのはユーザーデータだけであることを考慮すると、より微妙な戦略として、システムコンポーネントを一緒にプールする必要があります。このアプローチは高可用性を強化し、これらのコンポーネントが個々のPodから切り離されずに独立して機能することを可能にします。
多様なユーザーベースに対するマルチテナントのサポート
アーキテクチャーフレームワークは、多数の小規模ユーザーと大規模データを持つ大企業の両方にシームレスに対応する必要があります。アプリケーションレイヤーでのマルチテナンシーサポートは、エージェントアプリケーション、特に大規模なユーザーベースを持つアプリケーションの基本要件です。
この考え方に従って、アーキテクチャ図をスケッチしてみましょう。
OpenAIアシスタントの検索機能の最適化アーキテクチャ](https://assets.zilliz.com/The_optimized_architecture_of_Open_AI_Assistants_retrieval_feature_2a78677985.png)
主な修正点にスポットを当ててみよう：
システム・コンポーネントとクエリ・コンポーネントの分離。**以前は各Pod内に同居していたが、システム・コンポーネントは独立してプールされるようになり、リソース・フットプリントは以前のスキームと比較して1/3から1/10以下に削減された。
クエリ・コンポーネントの柔軟性の向上**：クエリーコンポーネントは、異なるPod番号に基づいて動的に割り当てられるようになり、物理的に分離された独立したスケーラビリティを享受できます。ブラスト半径の制御は、クエリーコンポーネントの粒度で細かく管理されます。シンプルな構造により、複雑なシステムコンポーネントと比較して信頼性が向上しています。
ハイブリッド・メモリ/ディスク・アーキテクチャ**：ハイブリッド・メモリー／ディスク・アーキテクチャーの導入は、メモリーがもっぱらホット・データをロードする、もう一つの重要な変更である。この強化により、同じ量のメモリで、以前のソリューションと比較して5倍から10倍のオリジナル・テキストを処理できるようになった。
マルチテナンシーのためのマルチパーティション・サポート：*** マルチパーティション・サポートの追加は、アプリケーション層でのマルチテナンシーに対応します。各上位ユーザーは独立したデータ・パーティションを割り当てられるようになり、アプリケーション層で低コストのソリューションを提供できるようになりました。物理的な分離は、ユーザー・グループごとに1つのクエリー・コンポーネントを割り当てることで達成されます。
このアーキテクチャでデータサポートを再計算すると、32GBのメモリを持つクエリノードは、ディスクスペースによって増強され、320GBのベクトルとインデックスを効率的にサポートすることができる。これらのクエリノードに割り当てられたプールされたシステムコンポーネントリソースは、クエリノードとは物理的に異なる3GBに相当する。合計で35GBのメモリが128GBのユーザーデータを収容でき、1GBのメモリあたり約3.6GBのユーザーデータを収容できることになる。一方、以前の設計では、32GBのメモリで8GBのユーザーデータをサポートしており、メモリ1GBあたりのユーザーデータの平均は250MBでした。**これは効率が15倍向上したことを意味する。
一般的なベクトルデータベースの概要：Milvus、Chroma、Qdrant
ベクターデータベースは、OpenAIアシスタントのアーキテクチャを最適化する上で極めて重要な役割を果たすため、最も堅牢なオプションを選択することが最も重要です。ここでは、3つの著名なオープンソースベクターデータベース-Milvus、Chroma、Qdrant-を掘り下げ、OpenAIアシスタントのアーキテクチャを強化する上での強みと限界を評価します。
Milvus
Milvusは最も成熟したオープンソースのベクトルデータベースであり、大規模分散システムで広く採用されています。特筆すべき機能として、システムコンポーネントとクエリコンポーネントの効果的な分離、リソースグループ機能によるクエリコンポーネントの分離、ハイブリッドメモリ/ディスクアーキテクチャ、RBACとパーティション機能によって促進されるアプリケーションレベルのマルチテナンシーなどがあります。
短所:** Milvusはその長所にもかかわらず、リソース・グループをベースとしたクエリ・コンポーネントの分離による完全な異常の分離を達成するには不十分である。さらに、EtcdやMinIOのようなサードパーティの依存関係が導入されるため、導入コストや運用コストが上昇します。
Chroma
長所：*** Chromaは、新しくユーザーフレンドリーなプロジェクトとして登場し、そのシンプルさが評価されている。迅速なプロトタイピングと素早いAIアプリケーションのイテレーションに適しており、個人開発者の間で人気を博している。
短所：** Chromaは小規模なシナリオでは優れているが、大規模なエンタープライズ・アプリケーション向けには設計されていない。分散デプロイメント、コンポーネント分離、ハイブリッド・メモリ／ディスク・アーキテクチャ、アプリケーション・レベルのマルチテナンシーといった主要な機能が欠けている。
Qdrant
長所:** Qdrantは新規参入で、小規模な分散デプロイをサポートし、セットアッププロセスが合理化されている。また、メモリとディスクのハイブリッドアーキテクチャを採用しており、最新のデータベース要件に対応しています。
現在のところ、Qdrant はコンポーネント分離やアプリケーションレベルのマルチテナンシーといった重要な機能をサポートしておらず、特定のユースケースでの適用が制限されている。
これらのベクターデータベースを評価すると、それぞれのソリューションが独自の長所とトレードオフをもたらすことが明らかになり、OpenAIアシスタントのアーキテクチャを最適化するという文脈の中で、特定の要件と優先順位によって選択が左右されることになります。
まとめ
今回のブログポストでは、OpenAI Assistantsの価格、アーキテクチャ、そしてコスト効率とストレージ機能強化のための最適化の可能性を探りながら、その複雑さを掘り下げてみた。ベクターデータベースインフラストラクチャのコストは、ナレッジベースとエージェントアプリケーションの展開に大きく影響するという重要な事実が明らかになりました。
OpenAIのAssistantsに関するコストと利益を分析したところ、支出が潜在的な収益を上回るという顕著な不均衡が明らかになりました。これはトライアル段階では正当化できるかもしれませんが、新しい顧客やコミュニティの拡大に対応するためには、より持続可能なバランスが不可欠です。
このブログでは、アーキテクチャを最適化するソリューションを提案し、既存のソリューションと比較して、これらのアプリケーション・タイプのコストを10分の1に削減できる見通しを示している。この最適化プロセスにおけるベクトル・データベースの極めて重要な役割が強調されており、利用可能な選択肢の中でもMilvusが特に適した選択肢として浮上している。
とはいえ、既存のベクターデータベースには固有の限界があることを認識した上で、この投稿では、単一のベクターデータベースソリューションですべての課題に包括的に対処し、差し迫ったインフラ開発の設計要件をすべて満たすことはできないことを強調する。ベクターデータベースの選択は、OpenAIアシスタントのアーキテクチャを最適化する複雑さを効果的にナビゲートするために、特定の要件に合わせて調整されるべきである。
Robert GuoRobert Guo is a Partner and Director of Product Management at Zilliz and one of the architects behind Milvus, an open-source vector database revolutionizing AI data analysis. With a Ph.D. in Computer Software and Theory from Huazhong University of Science and Technology, he has presented influential work at prestigious conferences and journals, including SIGMOD, VLDB, USENIX ATC, ICS, DATE, and IEEE TPDS. Previously a key developer for Huawei's ModelArts platform, Robert is skilled at crafting efficient and scalable AI data solutions.
読み続けて
Context Engineering Strategies for AI Agents: A Developer’s Guide
Learn practical context engineering strategies for AI agents. Explore frameworks, tools, and techniques to improve reliability, efficiency, and cost.
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.