Databricksにおけるエージェントメモリのご紹介

本日、Databricksのエージェント開発プラットフォームであるAgent Bricksにおいて「Agent Memory」を導入します。Agent Memoryは、エージェントが記憶すべき重要な事実、設定、ワークフローを保存することで、コストとレイテンシーを削減しながらエージェントの品質を向上させます。本日よりベータ版として利用可能で、高い信頼性と低レイテンシーを実現するLakebase上で動作し、Databricksの最新のメモリ研究に基づいて構築されています。

メモリがない場合、エージェントは重要な事実を再発見したり、ユーザーの設定を忘れたり、すでに修正された間違いを繰り返したりするリスクがあります。そのため、多くの開発者が独自のメモリソリューションを構築していますが、「メモリはどこに保存すべきか？」「メモリはどのように統合されるべきか？」「生成されたメモリはどのように取得されるべきか？」といった多くの設計上の課題に直面しています。

これに対処するため、Databricks Agent MemoryはDatabricks Researchによって開発されたMemCurrentアーキテクチャの上に構築されています。MemCurrentは、コンテキストを自動的に記録・読み込みするプラグイン、エージェントが必要に応じて呼び出すツール、バックグラウンドでメモリを統合するオフラインのドリーミングパイプラインという3つのアクセスパターンを組み合わせています。これらはすべてLakebaseを使用して非常に低いレイテンシーで提供されます。社内ベンチマークでは、このメモリアーキテクチャの実装により、実際のエンタープライズタスクにおけるエージェントの合格率が3倍に向上し、トークン消費量が31%削減されました。 

Agent Memoryは、エージェントホスティング、Databricks Sandbox、Unity Gateway、ビルドインMCPサーバー、トレースと評価など、Agent Bricksの既存機能に加わり、本番環境向けエージェントの構築に必要なすべてのインフラ機能を提供します。

課題：ステートレスなエージェントは同じコンテキストに対して二重のコストを払う

エージェントをデモから日常利用へと移行すると、すぐに2つの問題が発生します。

• 再発見のたびにコストが増大する。ステートレスなエージェントは、昨日把握したこと（どのテーブルに利用データが入っているか、社内略語の意味、実際に機能する結合条件など）を再び導き出そうとします。当社の研究における実際のセッションでは、ある製品の上位顧客に関する質問に答えるために、エージェントは11回のツール呼び出し、8つのサブエージェント、および約6分間を費やしました。翌日も、まったく同じことを繰り返すことになります。
• エージェントが個別化されない。ユーザーが設定を伝えたり、間違いを修正したり、チームによる指標の定義を説明したりしても、セッションが終了するとエージェントはそれを忘れてしまいます。その結果、ユーザーが同じ説明を繰り返すか、エージェントが同じ間違いを繰り返すことになります。

エージェント開発者や、エージェントを運用するプラットフォームチームには、よく使われる2つの回避策があります。しかし、それぞれ別の問題を引き起こします。

• 履歴全体をコンテキストに再入力する方法は、履歴が長くなるまでの間しか機能しません。オープンソースのメモリベンチマークでは、フルコンテキストを入力した場合、同じ精度でありながら適切に設計されたメモリと比較して、質問1つあたり約12倍の入力トークンを消費しました。さらに最も長い履歴では、無関係なやり取りによってエージェントが混乱し、スコアが悪化しました。
• オブジェクトストレージやベクトルデータベース上にメモリを自作する場合、抽出、重複排除、検索、アクセス制御の管理が必要になります。メモリは古くなり、矛盾する事実が蓄積され、どのメモリが悪い回答を引き起こしたのか分からなくなります。

チームが必要としているのは、別のシステムを立ち上げることなく、エージェントのコスト削減とパーソナライズを同時に実現するメモリです。

DatabricksにおけるAgent Memoryの仕組み

図1：Agent Bricks上のAgent Memory。エージェントは各会話ターンをマネージドセッションに追加し、メモリを直接呼び出しおよび保存します。メモリパイプラインはバックグラウンドでセッションを長期メモリへと抽出・要約します。

Agent Memoryは3つの部分で構成されています：

• マネージドセッション：メッセージ、ツール呼び出し、実行結果の順序付き履歴として、お使いのフレームワークのネイティブ形式で各会話を記録します。 
• マネージドメモリ：プロファイル、設定、ドメイン知識、ワークフローなど、記憶する価値のある内容を保持します。セッション開始時に、エージェントはメモリ内の既知内容のインデックスを読み込みます。セッション中は、キーワード検索とセマンティック検索を組み合わせたハイブリッド検索で詳細を見つけ出します。
• メモリパイプライン：オンデマンドまたは定期的に、バックグラウンドでセッションからメモリへと抽出・要約を行います。永続的な事実や設定情報を抽出し、重複を削除し、新しい会話によって矛盾が生じた事実を更新します。

すべてはワークスペース内にプロビジョニングされ、Databricksによって運用されるサーバーレスPostgresであるLakebase上で動作します。これにより、メモリの保存と検索が非常に高速化され、エージェントのトラフィックに応じてストレージをスケールさせることができます。

当社のメモリ研究に基づいて構築

Agent Memoryは、MemCurrent: Designing Memory for Enterprise Agentsで説明されているメモリシステム「MemCurrent」のプロダクション実装です。当社の研究者の主要な発見は、メモリは2つのレイヤーで最も効果的に機能するということです。1つは何が起きたかの未加工の記録、もう1つは記憶する価値のある情報の抽出記録であり、これらはタスク途中でエージェントがその都度書き込むのではなく、バックグラウンドプロセスによって最新状態に維持されます。

この構造により、メモリは品質と効率の両方を同時に向上させました。メモリを備えたエージェントは、メモリのないエージェントの約3倍のタスクを完了し、より迅速に終了し、消費トークン数も削減されました。同じインフラストラクチャは、ビジネスユーザー向けの自然言語エクスペリエンスであるGenieのメモリ機能にもすでに活用されています。

図2：エンタープライズデータタスクに関するDatabricksの社内メモリベンチマークにおける、メモリありとメモリなしのエージェントの比較。出典：MemCurrentの研究。

エージェントにどのような変化をもたらすか

• タスクあたりのコストを削減。エージェントはすでに実行した作業をスキップします。上記の例では、ワークフローがメモリに保存された後、エージェントは関連する追加の質問に対して、以前の11回のツール呼び出しと約6分間から、わずか2回のツール呼び出しと41秒で回答しました。 
• 持続するパーソナライズ。設定、修正内容、チーム固有の定義がユーザーごとにセッションを跨いで引き継がれるため、ユーザーが何度も同じ説明をする必要がなくなります。
• 修正された間違いが繰り返されない。エージェントは過去の間違いを記憶しているため、同じ間違いを二度繰り返すのを防ぎ、貴重な時間とトークンを節約できます。
• ご自身で所有・管理できるメモリ。セッションとメモリは特定の単一エージェントフレームワークに依存せず、お客様のLakebaseプロジェクト内に保持されます。開発者はエージェントがユーザーごとに保存しているエントリの読み取り、エクスポート、削除を行えるほか、「永続的な顧客の設定を維持し、単発のデバッグノートは無視する」などの指示をメモリパイプラインに与えて保持内容を制御できます。
• 一連のサイクルを統合する1つのプラットフォーム。同じエージェントがUnity Gatewayを介してモデルを使用し、Agent Bricks CLIでデプロイされ、メモリ機能も含めてAgent Bricksのトレース機能でトレース・評価されます。

はじめに

お客様側で新たなインフラを用意する必要はありません。Agent Bricks CLIを使用すれば、メモリとセッションを備えたエージェントを数分でデプロイできます。

それ以降、各ユーザーとのエージェントの次の会話は、以前の会話から学んだ内容から始まります。詳細については、メモリ付きの新しいエージェントを作成するための クイックスタート、または既存のエージェントにメモリを追加するための チュートリアルを参照してください。

Agent Memoryは、あらゆるモデル、フレームワーク、ハーネスを用いて大規模なカスタムエージェントを構築、実行、改善するためのDatabricksのエージェント開発プラットフォーム「Agent Bricks」の一部です。 Agent Bricksを見るでプラットフォームのその他の機能をご確認ください。

その他のリソース

• 10分未満でステートフルエージェントを構築： Agent Bricks CLIのドキュメントをご覧ください。
• 既存のエージェントにメモリとセッションを追加： エージェントのメモリとセッションに関するドキュメントをご覧ください。
• 背景にある研究を読む： MemCurrent: Designing Memory for Enterprise Agentsをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事