paint-brush
AIエージェントの背後にあるもの:自律性を支えるインフラストラクチャ@datastax
新しい歴史

AIエージェントの背後にあるもの:自律性を支えるインフラストラクチャ

DataStax11m2025/01/29
Read on Terminal Reader

長すぎる; 読むには

多くの可動部分にわたるオーケストレーションをサポートするインフラストラクチャと、エージェント システムの構築に必要なデータとコンテキストの長い履歴について学習します。
featured image - AIエージェントの背後にあるもの:自律性を支えるインフラストラクチャ
DataStax HackerNoon profile picture


AI エージェントとエージェント システムに関するほとんどの説明は、エージェントの想定される使用例のさまざまな状況において、ユーザーの介入なしにエージェントが自律的に行動する能力に焦点を当てています。一部のエージェントはヒューマン イン ザ ループ モデルで動作し、ユーザーが不確実性に遭遇した場合にのみユーザーと関わりますが、一般的な特定の状況下では自律的に行動します。


AIエージェントの主な特徴は自律性であるため、エージェントがユーザーの入力から独立して行動するために必要なサポート機能があります。 以前のブログ投稿、私たちはエージェント AI アーキテクチャに必要な 4 つの要件を特定しました。


  1. 能力とアクセス -権限や関連システムへの認証されたアクセスなど、ユーザーに代わって行動する能力。


  2. 推論と計画 -エージェントのアクションを導く構造化された思考プロセス (多くの場合、チェーン、ツリー、グラフ、またはアルゴリズムとして定義されます) 内で推論を使用して決定を下します。


  3. コンポーネント オーケストレーション -プロンプト、LLM、使用可能なデータ ソース、コンテキスト、メモリ、履歴、潜在的なアクションの実行とステータスなど、複数の部分の調整。


  4. ガードレール -エラーを回避したり、障害が発生した場合に役立つ診断情報を提供したりするための安全策を含む、エージェントの集中力と効率性を維持するためのメカニズム。


これら 4 つの要件にはそれぞれ異なるインフラストラクチャ ニーズがあります。能力とアクセスに関しては、主なニーズはソフトウェア統合と資格情報管理です。推論と計画は主に LLM やその他の AI モデルによってサポートされます。ガードレールのトピックは広範で、関連するユース ケースに固有のものであることが多いため、今後の記事で取り上げます。ここでは、オーケストレーションと、意思決定時に必要になる可能性のある多数の可動部分と長いデータ履歴およびコンテキストにわたるインテリジェントなオーケストレーションをサポートするために必要なインフラストラクチャに焦点を当てたいと思います。

AIエージェントにおけるコンポーネントオーケストレーションとコンテキストの役割

上記の最初の 2 つの要件 (能力、アクセス、推論、計画など) が意図したとおりに機能していると仮定すると、コンポーネント オーケストレーションの主な課題は知識管理になります。エージェント システムは、コア タスクと目標、さまざまな関連システムの状態、ユーザーや他の外部システムとのやり取りの履歴など、さまざまなレベルで認識を維持する必要があります。


LLM では、「コンテキスト ウィンドウ」という概念を使用して、通常はプロンプト時にモデルが利用できる情報セットを説明します。これは、プロンプト自体に含まれる情報とは異なり、モデルのトレーニング プロセス中に形成された LLM の内部知識セットとも異なります。


長いテキストでは、コンテキスト ウィンドウはプロンプト時に LLM が利用できる情報の「最近の履歴」と考えることができます。これは、LLM とプロンプトのアーキテクチャに暗黙的に含まれています。このように、ほとんどの LLM はコンテキストの 1 次元の概念を持ち、古いコンテキストは時間の経過とともにウィンドウから消えてしまいます。


エージェントが決定を下す必要があるときはいつでも、最も重要または緊急のコンテキストが優先されるように、エージェントにはコンテキストと知識を管理するためのより洗練されたシステムが必要です。単一のモノリシックなコンテキストではなく、AI エージェントはさまざまな重要度のレベルのさまざまな種類のコンテキストを追跡する必要があります。


これは、コンピュータ システムのメモリに例えることができます。コンピュータ システムでは、キャッシュ、RAM、ハード ドライブなど、さまざまな種類のストレージが、アクセス可能性と使用頻度に基づいてさまざまな目的に使用されます。AI エージェントの場合、コンテキストを概念的に 3 つの主要なレベルに構造化できます。


  1. 主要なコンテキスト –エージェントの中心的なタスク リストまたは目標。これは常に最優先に考え、すべてのアクションの指針となる必要があります。


  2. 直接的なコンテキスト -メッセージング システム、データ フィード、重要な API、ユーザーの電子メールやカレンダーなどのリソースを含む、接続された関連システムと直接的な環境の状態。


  3. 外部コンテキスト –一般的な知識、または関連性があるかもしれないが、エージェント システムのコア部分として明示的に設計されていない情報。外部コンテキストは、インターネットや Wikipedia の検索のような単純なものによって提供される場合があります。または、サードパーティのニュースや更新から生じる予期しない要因など、緊急かつ複雑なものになる可能性があり、エージェントが動的にアクションを適応させる必要があります。


これらのコンテキスト レベルは決定的なものではなく、それらの間の境界は非常に曖昧になる可能性があり、コンテキストの種類を説明する他の便利な方法もありますが、この概念構造はここでの議論に役立ちます。

コンテキスト管理のためのストレージインフラストラクチャ

AI エージェントのストレージのニーズは、管理されるコンテキストの種類によって異なります。プライマリ、直接、外部の各コンテキスト レベルには、異なるデータ構造、取得メカニズム、更新頻度が必要です。重要な課題は、エージェントの処理パイプラインに過負荷をかけずに、効率的なアクセス、長期的な永続性、動的な更新を確保することです。


AI エージェントは、コンテキストをモノリシックなエンティティとして扱うのではなく、構造化データ モデルと非構造化データ モデルを融合したハイブリッド ストレージ アーキテクチャのメリットを享受します。これにより、高速な検索、セマンティック検索、スケーラブルな永続性が可能になり、冗長なデータ処理を最小限に抑えながら、必要なときに関連コンテキストを利用できるようになります。

主なコンテキスト: タスク リストとエージェントの目標

プライマリ コンテキストは、エージェントのコア目標とアクティブなタスクで構成され、意思決定の基盤となります。この情報は、すべてのエージェントのアクションをガイドするため、永続的で、高度に構造化され、簡単にクエリ可能である必要があります。


潜在的なストレージのニーズ:

  • 構造化されたタスク リストと目標階層用のトランザクション データベース (キー値またはドキュメント ストア)
  • アクティブ タスクの迅速な検索をサポートする低レイテンシのインデックス作成
  • イベント駆動型の更新により、タスクがリアルタイムの進行状況を反映するようになります。


エージェントの実装例

タスク キューを管理するスケジュール アシスタントでは、次のものを保存する必要があります。

  • ステータス更新を含む永続的なタスク (例: 「Alex との会議をスケジュールする」)。
  • 実行履歴 (例: 「最初のメールを送信し、応答を待っています」)。
  • 優先順位と依存関係により、緊急のタスクが最初に表示されるようになります。


分散型の高可用性データ ストアにより、エージェントが新しいイベントやコンテキストの更新を処理している場合でも、タスクが確実に追跡されます。

直接的なコンテキスト: 接続されたシステムの状態

直接コンテキストには、カレンダー、メッセージング プラットフォーム、API、データベース、その他のリアルタイム データ ソースなど、関連システムの現在の状態が含まれます。プライマリ コンテキストとは異なり、直接コンテキストは動的であり、多くの場合、構造化ストレージ ソリューションとリアルタイム ストレージ ソリューションの組み合わせが必要になります。


潜在的なストレージのニーズ:

  • イベント ログとリアルタイムのステータス追跡のための時系列データベース
  • 頻繁にアクセスされるシステム状態のキャッシュ レイヤー
  • 最近のやり取りに関するコンテキスト クエリのベクトル ベースの検索


エージェントの実装例:

ライブユーザーインタラクションを追跡するカスタマーサポート AI エージェントは、以下を保存する必要があります。

  • メモリ内ストア内のリアルタイムの会話履歴
  • 時系列データベース内のセッション状態(進行中のサポート チケットの詳細など)。
  • 外部システム検索用のAPI 応答キャッシュにより、冗長なクエリを回避します。


時間に敏感なデータ ストアと長期データ ストアを組み合わせて直接コンテキスト ストレージを構築することにより、AI エージェントは過度の遅延なしに環境を認識して動作できます。

外部コンテキスト: 知識の検索と適応

外部コンテキストには、エージェントの直接制御外のソースからの一般的な知識と予期しない更新が含まれます。これは、オンデマンドの検索クエリから動的に取り込まれる外部データまで多岐にわたる可能性があり、保存と取得には柔軟なアプローチが必要です。エージェントの進行中のタスクや接続されたシステムに密接に結びついているプライマリ コンテキストや直接コンテキストとは異なり、外部コンテキストは構造化されておらず、広範で、関連性が非常に多様であることが多いです。


潜在的なストレージの考慮事項:

  • 永続的で構造化された参照資料のためのドキュメント ストアとナレッジ ベース
  • 内部または外部のドキュメントの大規模なデータセットをクエリするためのベクトル検索
  • 応答する前に関連する知識を取得するための検索拡張生成 (RAG )
  • 外部データ ソースからのリアルタイム更新のためのストリーミングとイベント駆動型の取り込み


エージェントの実装例:

気候変動研究における最新の科学的発見に関するレポートをまとめるパーソナル アシスタントには、次のことが求められます。

  • 外部ソースから科学論文を取得し、キーワードやベクトルの類似性に基づいて関連性をフィルタリングします。
  • ナレッジグラフを使用して傾向を特定し、論文間の関係を分析します
  • LLM ベースの検索拡張生成を使用して重要な洞察を要約します
  • リアルタイムの公開フィードとニュースソースを購読して、最新の更新を追跡します


高速な検索とセマンティックな編成を中心に外部コンテキスト ストレージを構築することで、AI エージェントは、取得したデータの関連性、信頼性、および実行可能性を維持しながら、新しい情報に継続的に適応できます。

コンテキスト認識型 AI エージェント向けハイブリッド ストレージ

コンテキスト認識型 AI エージェントを設計するには、重要な情報への効率的なアクセスとメモリや処理の過負荷の回避との間で慎重にバランスを取る必要があります。AI エージェントは、意思決定を最適化するために、コンテキストを動的に保存、取得、処理するタイミングを決定する必要があります。


トランザクション、ベクトル、時系列、イベント駆動型モデルを統合したハイブリッド ストレージ アーキテクチャにより、AI エージェントはコンテキストの永続性、検索効率、適応型インテリジェンスを維持できます。これらはすべて、大規模な自律性にとって重要です。このバランスを実現するには、次の 3 つの主要な側面にわたる構造化された戦略が必要です。


  1. レイテンシと永続性 -頻繁にアクセスされるコンテキスト (アクティブなタスク状態など) は低レイテンシのストレージに保存する必要がありますが、頻繁には必要とされないが重要な知識 (履歴インタラクションなど) は長期ストレージからオンデマンドで取得する必要があります。


  2. 構造化データと非構造化データ -タスク、目標、システム状態は構造化ストレージ (キー値データベースやドキュメント データベースなど) の恩恵を受けますが、より広範な知識検索には、コンテキストを効果的にキャプチャするための非構造化埋め込みとグラフ関係が必要です。


  3. リアルタイム認識と履歴認識 -一部のコンテキストでは継続的な監視が必要ですが (例: ライブ API 応答)、その他のコンテキスト (例: 以前の決定やレポート) は、エージェントの現在のタスクに関連する場合にのみ取得する必要があります。


これらの異なるタイプのコンテキストを考慮すると、AI エージェントは情報を保存およびアクセスするための構造化されたアプローチを必要とします。LLM コンテキスト ウィンドウのみに依存するのは非効率的です。エージェントが長期的なインタラクションや変化する状況を追跡する能力が制限されるからです。代わりに、コンテキストは永続的に保存され、動的に取得され、関連性と緊急性に基づいて優先順位が付けられる必要があります。


  • 主要なコンテキスト (タスクと目標) -構造化された追跡のためにトランザクション データベースに保存され、すべての推論サイクルで参照されます。


  • 直接コンテキスト (システム状態とアクティブ データ) -キャッシュ、時系列ストレージ、またはイベント駆動型更新を通じてリアルタイムで維持されます。


  • 外部コンテキスト (知識と動的更新) -ベクトル検索、検索拡張生成 (RAG)、またはグラフベースの知識表現を介してオンデマンドでクエリされます。


実際には、スケーラブルな AI エージェント アーキテクチャには、短期キャッシュ、永続データベース、外部取得メカニズムを組み合わせた多層メモリ モデルが必要です。ハイブリッド ストレージ アプローチを活用することで、AI エージェントは次のことが可能になります。


  • アクティブなシステムのリアルタイム認識を維持します。
  • 関連する場合にのみ履歴知識を取得します。
  • 変化するニーズに基づいて優先順位を動的に調整します


これらのストレージ戦略を統合することで、AI エージェントは自律的に機能し、長期間にわたってコンテキスト認識を維持し、新しい情報に動的に応答できるようになり、真にインテリジェントでスケーラブルなエージェント システムの基盤が築かれます。

ハイブリッドストレージソリューション

AI エージェント用のハイブリッド ストレージ アーキテクチャを実装するには、さまざまなタイプのコンテキストを効率的に処理するために適切なデータベースとストレージ ツールを選択する必要があります。最適な選択は、レイテンシ要件、スケーラビリティ、データ構造の互換性、取得メカニズムなどの要因によって異なります。


適切に設計された AI エージェント ストレージ システムには通常、次のものが含まれます。

  • 構造化された永続的なタスク追跡のためのトランザクション データベース
  • リアルタイムのシステム状態監視のための時系列およびイベント駆動型ストレージ
  • 柔軟な非構造化データ アクセスのためのベクトル検索と知識取得
  • 短期メモリへの迅速なアクセスを実現するキャッシュとメモリ内データベース


それぞれの要素を詳しく見てみましょう。

トランザクションおよび分散データベース

AI エージェントには、タスク、目標、構造化メタデータを確実に保存するための、スケーラブルで可用性の高いトランザクション データベースが必要です。これらのデータベースにより、プライマリ コンテキストが常に利用可能になり、効率的にクエリできるようになります。


  • Apache Cassandra® – 高可用性とフォールト トレランスを実現するように設計された分散型 NoSQL データベース。構造化されたタスク リストの管理やエージェントの目標追跡を大規模に行うのに最適です。


  • DataStax Astra DB Cassandra 上に構築されたマネージド データベース サービス (DBaaS) で、高い耐久性を必要とする AI アプリケーションに弾力的なスケーラビリティとマルチリージョン レプリケーションを提供します。


  • PostgreSQL –強力な一貫性保証を備えた人気のリレーショナル データベース。構造化されたエージェント メタデータ、永続的なタスク ログ、ポリシーの適用に適しています。

時系列およびイベント駆動型ストレージ

リアルタイムのシステム監視を行うには、AI エージェントに、ログ記録、イベント追跡、状態の永続性に最適化されたデータベースが必要です。

  • InfluxDB –高速な取り込みと効率的なクエリを実現するように設計された、最先端の時系列データベース。AI エージェントのアクティビティや外部システムの更新を記録するのに最適です。


  • TimescaleDB –時系列ワークロード向けに最適化された PostgreSQL 拡張機能。AI エージェントのワークフローやシステム イベントの変更を追跡するのに適しています。


  • Apache Kafka + kSQLDB – AI エージェントがリアルタイム イベントを効率的に消費、処理、反応できるようにするストリーミング データ プラットフォーム。


  • Redis Streams –リアルタイムのイベント処理とメッセージ キューイングのための軽量ソリューション。新しい更新が発生したときに AI エージェントに通知するのに役立ちます。

知識検索のためのベクトル検索

非構造化知識を扱う AI エージェントには、セマンティック検索、類似性マッチング、検索拡張生成 (RAG) などのタスクの埋め込みを効率的に保存、検索、取得する方法が必要です。最適化されたベクトル検索システムにより、エージェントはメモリやコンテキスト ウィンドウに過負荷をかけることなく、関連する過去のやり取り、ドキュメント、または事実を思い出すことができます。


  • DataStax Astra DB – Cassandra 上に構築されたスケーラブルなマネージド ベクトル データベースで、高性能な類似性検索とマルチモーダル検索を提供します。Astra は分散レジリエンスとベクトル検索機能を組み合わせており、グローバルなスケーラビリティと高可用性を確保しながら埋め込みを効率的に処理する必要がある AI エージェントにとって最適な選択肢です。


  • Weaviate –セマンティック検索とマルチモーダル データ取得用に設計されたクラウドネイティブ ベクトル データベース。ハイブリッド検索方法をサポートし、ナレッジ グラフと適切に統合されるため、コンテキスト推論に依存する AI エージェントに役立ちます。


  • FAISS (Facebook AI 類似検索) –高性能な最近傍検索用のオープンソース ライブラリ。大規模なデータセットの高速ベクトル検索のために AI パイプラインに組み込まれることが多い。完全なデータベースではありませんが、FAISS はローカル類似検索用の軽量で高速なソリューションを提供します。

キャッシュとメモリ内ストレージ

AI エージェントは頻繁に参照されるコンテキストへの低遅延アクセスを必要とするため、キャッシュはハイブリッド ストレージ アーキテクチャの重要なコンポーネントになります。


  • Redis – AI エージェントの短期的なコンテキスト キャッシュとセッション管理に広く使用されている、高性能なインメモリ キー値ストア。


  • Memcached –頻繁に使用される AI エージェント データへの迅速なアクセスを提供する、シンプルでありながら効果的な分散キャッシュ システム。


これらの多様なストレージ ソリューションを統合することで、AI エージェントは短期記憶、永続的な知識、リアルタイム更新を効率的に管理し、大規模でシームレスな意思決定を実現できます。トランザクション データベース、時系列ストレージ、ベクトル検索、キャッシュを組み合わせることで、エージェントは速度、スケーラビリティ、コンテキスト認識のバランスを取り、新しい入力に動的に適応できます。


AI 駆動型アプリケーションが進化し続ける中、複雑で絶えず変化する環境で確実に動作できる自律的で応答性に優れたインテリジェントなエージェント システムを実現するには、適切なハイブリッド ストレージ アーキテクチャを選択することが重要になります。

ハイブリッドデータベースを備えた AI エージェントの未来

AI システムが複雑化するにつれて、短期および長期のメモリ、構造化データと非構造化データ、リアルタイムおよび履歴の洞察を管理するためにハイブリッド データベースが重要になります。検索拡張生成 (RAG)、セマンティック インデックス、分散推論の進歩により、AI エージェントはより効率的でインテリジェントになり、適応性も高まります。将来の AI エージェントは、継続性を維持し、長期にわたって情報に基づいた意思決定を行うために、高速でスケーラブルなコンテキスト認識型ストレージに依存するようになります。

ハイブリッド データベースを使用する理由

AI エージェントには、速度、スケーラビリティ、回復力を確保しながら、さまざまな種類のコンテキストを効率的に管理するストレージ ソリューションが必要です。ハイブリッド データベースは、高速な構造化データと詳細なコンテキスト検索という両方の長所を兼ね備えており、インテリジェント AI システムの基盤となります。ハイブリッド データベースは、長期的な知識ストレージのためのベクトルベースの検索、低レイテンシのトランザクション検索、リアルタイムのイベント駆動型更新、フォールト トレランスのための分散スケーラビリティをサポートします。

スケーラブルなAIデータインフラストラクチャの構築

インテリジェントな AI エージェントをサポートするには、開発者はシームレスなコンテキスト管理のために複数のデータ モデルを組み合わせたストレージ アーキテクチャを設計する必要があります。

  • ベクトル検索と列データ –構造化されたメタデータとともに意味的コンテキストを保存し、高速検索を実現します。

  • イベント駆動型ワークフロー– リアルタイム更新をストリーミングして、AIエージェントが変化するデータを認識できるようにします。

  • グローバルな規模と回復力 -分散ネットワーク全体に展開して高可用性とフォールトトレランスを実現


トランザクション処理、ベクトル検索、リアルタイム更新を統合することで、 DataStax Astra DBのようなハイブリッドデータベースAI エージェントのメモリ、コンテキスト認識、意思決定に最適な基盤を提供します。AI 駆動型アプリケーションが進化するにつれて、動的でデータ集約的な環境で確実に動作する自律的でコンテキストが豊富な AI エージェントを実現するために、ハイブリッド ストレージ ソリューションが不可欠になります。


著者:Brian Godsey、DataStax