プロダクションAIエージェントは、多くの場所からメモリを蓄積する。ユーザー入力。APIレスポンス。システムログ。過去のインタラクションから導き出された推論。ほとんどのエージェント実装は、これらすべてを同じプールに格納し、区別なくクエリする。
デモではそれで問題ない。プロダクションでは、検出が難しく、回復コストの高い障害クラスを生み出す。エージェントが信頼すべきでないメモリに基づいて行動するのだ。
核心的な問題
メモリのソースは同等ではない。検証済みの外部APIから取得したファクトは、ユーザーがチャットセッションでエージェントに伝えたファクトとは異なる。エージェントがパターンから導き出した推論は、下流システムからの構造化ログエントリとは異なる。
エージェントがこれらをすべて同等に扱うと、信頼性の高いソースを低いソースより優先するメカニズムが存在しない。最も信頼できるメモリではなく、最も新しい、最もアクセスしやすい、または現在のクエリに最も構文的に類似したメモリを使用してしまう。
解決策はメモリを増やすことではない。メモリ信頼レベルだ。書き込み時に適用される分類スキームで、各メモリが読み取り時に何に影響を与えられるかを制御する。
ほとんどのプロダクションケースをカバーする4つの信頼レベル
検証済みソースメモリは、権威ある外部システムから取得される。CRMレコード、署名済みAPIレスポンス、既知のタイムスタンプを持つデータベース読み取りなどだ。このメモリは、アウトバウンドメッセージの送信、レコードの更新、ワークフローのトリガーといった重要なアクションを駆動できる。
推論メモリはエージェント自身が生成する。観察されたパターンから導き出された結論、非構造化入力に適用された分類、過去のコンテキストの要約などだ。このメモリは推論を補助すべきだが、独立してアクションを承認すべきではない。出力を駆動する前に、より高い信頼レベルからの裏付けが必要だ。
ユーザー主張メモリは、システム検証なしに人がエージェントに直接伝えた内容だ。有用なコンテキストではある。しかしグラウンドトゥルースではない。エージェントは検証済みソースデータより低く重み付けし、競合を暗黙的に解決するのではなくフラグを立てるべきだ。
エフェメラルメモリは、永続化すべきでないセッションスコープのコンテキストだ。一時的な設定、タスク途中の状態、作業上の仮定などだ。このメモリが長期ストレージに漏れると、古いまたはコンテキスト外のデータで将来のセッションを汚染する。
各レベルは異なる権限セットを持つ。検証済みソースメモリは承認できる。推論メモリは提案できる。ユーザー主張メモリはコンテキスト化できる。エフェメラルメモリは期限切れになるべきだ。
障害シナリオ
信頼レベルがない場合に何が起きるかを示す。
エージェントがアウトバウンドのプロスペクトフォローアップを処理している。CRMからの検証済みソースレコードがある。プロスペクトの会社は従業員200名、3日前に更新済みだ。また、過去のセッションからの推論メモリもある。エージェントは会話サマリーに基づいて、その会社が「最近拡大」し、現在は500名に近いと結論付けていた。
推論メモリの方が新しい。エージェントには検証済みソースレコードを優先するメカニズムがない。アウトバウンドメッセージで推論上の数値を使用し、実際の2.5倍の会社規模を引用してしまう。
プロスペクトは自社を誤って表現したメッセージを受け取る。商談は進まない。エラーはログに記録されない。エージェントは設計通りに動作した。
これはハルシネーションの問題ではない。エージェントはデータを作り出していない。システムがどのソースを信頼すべきかを伝えていなかったため、自身のメモリプールから誤ったデータを選択したのだ。
実践における信頼レベルの実装方法
信頼レベルはメタデータであり、別個のストレージシステムではない。各メモリエントリは書き込み時に信頼ラベルを取得し、ソース識別子とタイムスタンプも付与される。
読み取り時に、エージェントの検索ロジックは関連性によるランキングの前に信頼フィルターを適用する。検証済みソースメモリと推論メモリが同じファクトで競合する場合、エージェントは暗黙的に解決するのではなく競合を表面化させる。人間またはより高い権限を持つシステムがそれを解決する。
ほとんどの実装で適用される運用ルールをいくつか示す。
- 推論メモリが検証済みソースメモリを上書きしないようにする。 共存はできる。しかし上書きはできない。
- ユーザー主張メモリとエフェメラルメモリにTTLを設定する。 古いユーザー主張はメモリがない状態より悪い。誤った確信を生み出すからだ。
- すべての信頼レベル競合をログに記録する。 これらのログは、メモリプールが現実から乖離しているシグナルだ。
- アウトバウンドアクションの前に検証済みソースの裏付けを必須とする。 エージェントがアクションを支持する検証済みソースレコードを見つけられない場合、一時停止してエスカレーションすべきだ。
アウトバウンドAIシステムにとってこれが重要な理由
上記の障害モードは仮定の話ではない。アウトバウンドコミュニケーションに関わるエージェント、プロスペクトリサーチ、フォローアップシーケンシング、アカウントコンテキストなど、は信頼性プロファイルが異なる複数のソースからのメモリで動作している。
DK1.AIのAI Brand Presenceおよびアウトバウンドプロダクトは、ソースレベルのメモリ分類を後付けではなくベースライン要件として構築されている。エージェントがあなたの代わりにメッセージを送信する際、そのメッセージを駆動するデータには監査可能なプロベナンスチェーンが必要だ。
メモリ信頼レベルは、エージェントシステムにおける目立たない設計上の決定の一つだ。しかし同時に、システムが大規模に無人で安全に運用できるかどうかを決定する要素の一つでもある。
アウトバウンドアクションを処理するエージェントシステムを構築または評価しているなら、困難な形で気づく前に、現在のメモリアーキテクチャがソース競合をどのように処理するかを監査する価値がある。