Overview
標準のAIインタラクションはステートレスです。セッションが終了すると、モデルは対話に関するすべてのコンテキストを失います。エージェント メモリは、複数の対話にまたがる永続的な知識ストアをエージェントに提供することで、ステートレスなインタラクションをステートフルで適応型のワークフローに変換します。エージェントは環境から学習してこのストアを更新し、後続のタスクに必要な情報を呼び出します。
各セッションの後にリセットされる一時的なコンテキストウィンドウとは異なり、エージェントメモリにより、エージェントが空白のスレートに戻らないことが保証されます。そうしないと、エージェントはユーザー、以前の決定、または確立されたワークフローを返すことを覚えていないです。
MongoDB Atlas Agent Engine では、プロジェクト全体でこの永続性を管理するための専用メモリ サービスが導入されています。このサービスは、アプリケーションが ストアにメモリを書込む間に、バックグラウンドで通信を解析して永続的な情報を取得します。
メモリの仕組み
メモリは、データの有効期限と構造によって区別される、短期間メモリと長期メモリの 2 つの異なるレイヤーで動作します。バックグラウンドの抽出パイプラインは、短時間のやり取りを長期的な知識に処理します。
短期間メモリ
短縮メモリ(STM)には、未加工のチャット履歴が時系列で保存されます。プラットフォームは、各オンをリアルタイムで記録します。エージェントが最近の対応からの即座の対話コンテキストを必要とする場合、 SPM から読み取ります。
からメモリへの変換
Atlas Agent Engine は、次の 3 ステージのライフサイクルを通じてやり取りを耐久性のあるメモリに変換します。
レコードを返却する:エージェントがユーザーと対話する際に、プラットフォームはそれぞれのタームを短期間メモリにレコードします。
スナップショット生成: セッションが設定されたメッセージ数またはアイドルしきい値に達すると、バックグラウンド プロセスは通信履歴を要約スナップショットにコンパイルします。
LM 抽出:大規模言語モデル(LVM)はスナップショットを分析し、永続的な知識を適切な長期メモリ型に抽出します。
抽出は非同期で実行されるため、タームを記録してもエージェントの応答がブロックされることはありません。セッションから抽出された知識は、次の展開ではなく、後続のセッションで使用されるように長期メモリで使用可能になります。最近の対応は短期間のメモリを通じてすぐに利用可能になり、抽出された知識はその後すぐに表示されます。
長期メモリ
長期メモリはセッション全体に保持され、チャットから分離された永続的な知識を保持します。プラットフォームは、短期間メモリを生成するか、直接書き込みによって長期メモリを作成します。
プラットフォームに配置されたエージェントの場合、プラットフォームは自動的に通信を短期間メモリとして記録し、そのサーバーから長期メモリを除算しますが、エージェントは必要に応じて長期メモリを直接書き込むことができます。外部アプリケーションは通常、プラットフォーム分離のためにソフトウェア開発キット(SDK)を使用して短期間のメモリを書込みます。 SDK またはメモリ モデル コンテキスト プロトコル(MFP)を介して、長期メモリを直接書き込むこともできます。
長期メモリ型
プラットフォームは長期メモリを 4 つの専用タイプに整理します。
セマンティック メモリ: ラベル付けされたファクトを保存します。
エポック メモリ: 過去のインタラクションやディスカッションを個別の回として保存します。
手順メモリ: 再利用可能なステップ別手順の手順とワークフローを保存します。
分類メモリ: ドメインタームとその定義を保存します。
次のセクションでは、各タイプについて詳しく説明します。
セマンティック メモリ
セマンティック メモリは、 ユーザー またはアプリケーションに関するラベルの付いたファセットを保存します。ファクトは、それを生成した対話を超えて関連性を保つ知識です。例、ファセットはユーザーの自宅のフィールドやウィンドウシートの優先順位をキャプチャできます。
Atlas Agent Engine は、バックグラウンド抽出と直接書込み (write) によってセマンティック メモリを作成します。
バックグラウンド抽出: やり取りのスナップショットから詳細を抽出し、重複した情報や更新された情報を一定の期間統合します。
直接書込み:
save_semantic(label=..., text=...)を使用してファセットを保存します。
ファセットを検索するには、get_semantic を使用してラベルで検索するか、search_semantic を使用して意味のある単語を検索します。セマンティック メモリはデフォルトで build_context に含まれているため、エージェントが検索するコンテキストに関連するファセットが表示されます。
次の例では、ファクトを保存し、ラベルで検索し、次の意味でチャットを検索しています。
from agentic_platform_memory import ( Memory, MemoryRequestContext, ) memory = Memory( api_key="<your-access-token>", project_id="<your-project-id>", ) chat = memory.bind( MemoryRequestContext( user_id="user_1", session_id="thread_123", ) ) chat.save_semantic( label="home-airport", text="The user's home airport is Boston.", ) fact = chat.get_semantic("home-airport") hits = chat.search_semantic("home airport")
エポック メモリ
エポック メモリには、過去のやり取りを要約された回として保存します。例えは、行われた決定とそれに続く結果など、やり取りで発生した状況をキャプチャします。エポック メモリは、ユーザーの過去のインタラクションについてエージェントが知っている必要があることに答えます。
Atlas Agent Engine は、バックグラウンド抽出と直接書込み (write) によってエポック メモリを作成します。
バックグラウンド抽出: チャット スナップショットからイベントとその参加者を抽出します。
直接書き込み:
save_episode(title=..., content=...)を使用してサンプルを保存します。
インスタンスは、対話間で保持されます。エージェントは、後の対話中にある通信で発生した内容を呼び出すことができます。
回を検索するには、search_episodes を使用して意味を検索するか、list_episodes を使用してユーザーの回を一覧表示します。エポック メモリは build_context のデフォルトソースの 1 つであるため、関連する回が含まれます。
次の例では、回を保存し、それを検索して、ユーザーの回を一覧表示します。
from agentic_platform_memory import ( Memory, MemoryRequestContext, ) memory = Memory( api_key="<your-access-token>", project_id="<your-project-id>", ) chat = memory.bind( MemoryRequestContext( user_id="user_1", session_id="thread_123", ) ) chat.save_episode( title="Vacation planning", content="Planned a summer trip to Lisbon.", ) episodes = chat.search_episodes("trip to Lisbon") recent = chat.list_episodes()
手順メモリ
手順メモリには、再利用可能な手順が保存されます。つまり、特定のタスクを完了するためにエージェントが従うステップ別ワークフローです。手順では、航空会社のオプションの比較や 返金リクエストの処理 などの操作を行う方法をキャプチャします。
Atlas Agent Engine は、バックグラウンド抽出と直接書込み (write) によって手順メモリを作成します。
バックグラウンド抽出: 通信スナップショットから再利用可能な手順を抽出します。
直接書き込み:
save_procedure(procedure=..., description=..., content=...)を使用して手順を保存します。
手順を検索するには、discover_procedures を使用してクエリによって候補を検索するか、get_procedure を使用して名前付きで完全な手順を読み込みます。手順メモリには、セマンティックおよびエポックなデフォルトではなく、build_context の明示的なオプトインが必要です。
次の例では、手順を保存し、それを検索します。
from agentic_platform_memory import ( Memory, MemoryRequestContext, ) memory = Memory( api_key="<your-access-token>", project_id="<your-project-id>", ) chat = memory.bind( MemoryRequestContext( user_id="user_1", session_id="thread_123", ) ) chat.save_procedure( procedure="compare-flights", description="Compare flight options.", content="Rank flights by price, stops, and total travel time.", ) candidates = chat.discover_procedures("compare flights") full = chat.get_procedure("compare-flights")
分類メモリ
分類メモリには、ドメインタームとその定義が保存されます。タームは、移動管理における red-eye とは異なる、ドメイン内の単語の意味を定義します。ユーザースコープのメモリとは異なり、分類メモリはプロジェクト内のすべてのユーザーと対話全体で利用可能な共有ドメイン知識です。
Atlas Agent Engine は、バックグラウンド抽出と直接書込み (write) を通じて分類メモリを作成します。
バックグラウンド抽出: チャット スナップショットからタームとそのドメインを抽出します。
直接書込み:
save_taxonomic(domain=..., term=..., definition=...)を使用してタームを保存します。
タームを検索するには、get_taxonomic_term を使用してドメインとタームで検索するか、search_taxonomic を使用してタームを検索します。プロジェクトが持つドメインを一覧表示するには、list_domains を使用します。分類メモリには build_context での明示的なオプトインが必要です。
次の例では、 というタームを保存し、読み取りをして検索します。
from agentic_platform_memory import ( Memory, MemoryRequestContext, ) memory = Memory( api_key="<your-access-token>", project_id="<your-project-id>", ) chat = memory.bind( MemoryRequestContext( user_id="user_1", session_id="thread_123", ) ) chat.save_taxonomic( domain="airline", term="red-eye", definition="An overnight flight that lands the next morning.", ) definition = chat.get_taxonomic_term("airline", "red-eye") matches = chat.search_taxonomic("overnight flight", domain="airline") domains = chat.list_domains()
メモリ型の選択
1 回の対話を超えて情報を保持する必要があると判断したら、データの形状と使用目的に基づいて長期メモリ型を選択します。
メモリ型 | 保存内容 | スコープ | キーの質問 |
|---|---|---|---|
セマンティック | 永続的なラベル付けされたファセット | user | エージェントはtrue を認識していますか。 |
エポック | 要約されたインタラクション履歴と結果 | user | 過去のやり取りではどのようなことがありましたか。 |
手順 | 再利用可能なステップバイステップワークフロー | user | エージェントはこのタスクをどのように実行する必要があるか。 |
分類 | ドメイン用語と定義 | プロジェクト全体(共有) | このドメインタームは何を平均か。 |
型の区別
情報が複数のカテゴリにまたがるように表示される場合は、次の運用上の境界に該当する場所を評価してください。
ファセットとイベント(セマンティックとエピリオド): セマンティック メモリは、移動者の好みのシートや自宅のプールなど、現在の状態や真実を保存します。エポック メモリには、その設定が説明されたり使用されたりしたやり取りの履歴が保存されます(過去の航空会社の予約など)。
知識と実行の比較(セマンティックと手順): セマンティック メモリは、大容量の制限など、エージェントが呼び出す結果を提供します。手順メモリは、航空会社を検索して比較するために必要なステップのシーケンスなど、エージェントが実行する指示を提供します。
ユーザーコンテキストとドメイン標準の比較(セマンティックとされたドキュメントの両方): セマンティック メモリは、移動のフリープラクティスの階層など、ユーザー固有の詳細を追跡します。課税 メモリは、プロジェクト全体で共有される標準的な用語を定義します。たとえば、どの資格条件がマッピングで、シリアル階層やレプリカセットを定義するかなど、 プロジェクト 全体で共有される標準的な用語を定義します。
メモリ型の組み合わせ
メモリ型は、相互に排他的ではなく、補完的です。単一のエージェントが、同じワークフロー内の複数のメモリ型を頻繁にクエリします。例、移動予約エージェントはを参照。
移動者のプライベートコレクション、シートの優先順位、頻繁にスローされる番号を呼び出すためのセマンティック メモリ。
ディスカッション、予約済みの行程、過去の移動のキャンセルを検討するためのエポック メモリ。
フライト オプションを比較したり、キャンセルされた接続を再予約したりするためのステップ別ワークフローを実行するための手順メモリ。
航空会社の用語を解釈するための分類メモリ。
open-jaw routinglayover、 、red-eyeなど。
データが 4 つの組み込みタイプのいずれにも収まらない場合は、代わりにカスタム メモリタイプを宣言できます。方法については、 エージェントにメモリを追加するガイドの「 カスタム メモリ タイプの宣言 」を参照してください。
メモリ抽出の構成
project-config.yaml の memory.extraction ブロックで有効になっているメモリ型のバックグラウンド抽出が実行されます。メモリ型を抽出するには、それを enabled リストに追加します。
memory: extraction: enabled: - semantic - episodic - procedural - taxonomic
有効になっている各タイプは独自の抽出ハンドラーを実行し、その種類のメモリを通信スナップショットから分離します。
enabled リストは自動バックグラウンド抽出に適用されます。アプリケーションは、そのタイプの自動抽出がオフになっている場合でも、SDK に任意の組み込みメモリ タイプを保存することができます。
メモリ サービスを有効にし、 配置されたプロジェクトに抽出構成を適用するには、 「エージェントへのメモリの追加」ガイドを参照してください。
メモリの検索
エージェントは、アセンブルされたコンテキストと未加工レコードの 2 つの異なる検索モードでメモリをクエリし、読み取ります。
アセンブルされたコンテキスト:エージェント用に、プロンプトに対応する単一のテキスト ブロックをフォーマットします。
build_contextbuild_context_from_sourcesメソッドと メソッドは、選択したメモリ型、一致のランク付けと重複を解除し、結果をトークンの予算に削除します。Raw レコード: カスタムアプリケーションロジック用の構造化データ オブジェクトを返します。コード内のレコードを検査またはフィルタリングするには、
searchまたはタイプごとの検索メソッドを使用します。
デフォルトでは 、コンテキスト ビルダはエポック メモリとセマンティック メモリを検索します。短期間のメモリ、プロシージャのメモリ、または分類のメモリを含めるには、それらのソースを enabled_sources にリストします。
次の例では、手順メモリを含むチャット セッションのコンテキストを構築します。
from agentic_platform_memory import ( Memory, MemoryRequestContext, ) memory = Memory( api_key="<your-access-token>", project_id="<your-project-id>", ) chat = memory.bind( MemoryRequestContext( user_id="user_1", session_id="thread_123", ) ) context = chat.build_context( query="What is relevant to the next trip-planning task?", enabled_sources={"episodic", "semantic", "procedural"}, )
注意
プラットフォームに配置されたエージェントは、ランタイムによって ID がすでに設定されている事前に構築された app.memoryクライアントを受け取ります。スタンドアロンアプリケーションはMemory を構築し、user_id と session_id 自体をバインドします。
メモリのスコープと可視性
すべてのメモリ レコードは、それが作成されているプロジェクトに分離されます。データはプロジェクト境界をまたがることはありません。プロジェクト内では、プラットフォームは 2 つの可視性スコープでレコードアクセスを制御します。
プライベート:レコードに関連付けられたユーザーIDのみがアクセスできます。セマンティック メモリ、エポック メモリ、手順メモリはデフォルトで
privateになります。組織:プロジェクト内のどのユーザーもアクセスできます。ドメイン定義と用語はプロジェクト全体で共有されることを目的としているため、分類メモリのデフォルトは
orgです。
エージェントが読み取りまたは検索を実行する場合、プラットフォームは呼び出し元のプロジェクトとユーザー スコープへの読み取りを制限するため、結果には呼び出し元が読み取れるレコードのみが含まれます。
重要
サービス アカウント メモリ ID
サービス アカウントが 配置されたエージェントを呼び出す場合、Atlas Agent Engine はサービス アカウントの ID をランタイムメモリの ID として使用します。プラットフォームは、呼び出しリクエストまたは agentengine invoke --user-id フラグが提供するエンドユーザーの user_id 値を無視します。
この解決済み ID は、自動変換、記録、抽出、統合、app.memory 操作で使用されます。その結果、同じサービス アカウントを認証する呼び出しは 1 つのメモリ ユーザー スコープを共有します。
この制限は、サービス アカウントが呼び出す配置されたエージェントにのみ適用されます。スタンドアロンの、プロジェクトスコープのメモリ サービスは影響を受けません。このサービスは、呼び出し元からの明示的な user_id と session_id 値を引き続き受け入れます。
エンドユーザーごとにメモリを分離するには、アプリケーションからスタンドアロンのメモリサービスを呼び出し、各呼び出しに明示的なuser_id とsession_id 値を渡します。詳しくは、「 スタンドアロン メモリ サービスの使用 」を参照してください。
次のステップ
エージェントのメモリを有効にする 方法については、「 エージェントにメモリを追加する 」を参照してください。
エージェントを完全に配置せずにメモリを使用する方法については、「 スタンドアロン メモリ サービスの使用 」を参照してください。