AIにおけるアクティブメモリと永続メモリの違い：AIが記憶し、情報を取り出し、忘れる仕組み

アクティブメモリとは、AIシステムが現在取り組んでいるタスクで利用できる情報です。永続メモリとは、後で再び利用できるよう、AIを取り巻くアプリケーションが保持する情報です。両者の関係によって、アシスタントがプロジェクトを継続できるか、ユーザーの好みを反映できるか、古くなった前提を訂正できるか、あるいは忘れるべき情報を繰り返し持ち出さずに済むかが決まります。

アシスタントが調査レポートの作成を手伝っている場面を考えてみましょう。同じ会話の中であれば、アウトラインや直近の修正内容、たった今共有した資料を参照できます。しかし、1週間後に別の会話を始めた場合、その継続性は別の仕組みに左右されます。つまり、アプリケーションが関連情報を保存し、それを見つけて、再びモデルに渡せるかどうかです。

そのため、AIは同じやり取りの中で、ある情報は覚えているように見える一方、別の情報は忘れてしまうことがあります。記憶は一連の処理によって成り立っています。情報の取得、保存、検索、選択、解釈、更新のいずれの段階でも失敗が起こり得ます。

このガイドでは、その一連の処理を詳しく見ていきます。エピソード記憶、意味記憶、手続き記憶を含む、より広い分類については、AIエージェントの記憶の種類に関する入門記事をご覧ください。ここでは、現在有効な情報と、目の前のタスクを終えた後も保持される情報との境界に焦点を当てます。

アクティブメモリと永続メモリとは、実際には何を指すのか？

これらの用語は、アーキテクチャ上の有用な違いを示しますが、普遍的に標準化された一対の用語ではありません。製品のインターフェースや研究論文では、「ワーキングメモリ」「短期記憶」「コンテキスト」「状態」「長期記憶」が、意味を重ねながら使われています。そのため、正確に説明するには、まず用語を定義する必要があります。

この記事では、アクティブコンテキストを、現在の応答を生成するためにモデルへ渡される情報、すなわち指示、メッセージ、選択されたツールの出力、検索された資料、その他モデルが処理できる入力と定義します。アクティブなタスク状態は、これより広い概念です。計画やチェックリスト、アプリケーションが保持しているものの、まだモデルのコンテキストに挿入されていない変数などが含まれることがあります。ここでは、こうした現在の作業セット全体を実用上まとめてアクティブメモリと呼び、必要に応じて両者を区別します。

永続メモリとは、応答やセッションの区切りを越えて保持され、後から利用できる情報を指します。保存されたユーザーの好み、プロジェクトのメモ、イベントの記録、構造化データベースのフィールド、未完了のタスクを再開するためのチェックポイントなどが該当します。永続性が示すのは情報が保持されることです。すべての会話でその情報が共有されるとは限りません。

したがって、問うべきことは2つあります。情報は今も存在しているか？そして、必要なときにモデルへ渡されるか？保存された会話記録が答えられるのは、1つ目の問いだけであり、2つ目の問いの解決にはなりません。

重要な例外：短期的な状態も保存できる

「短期的」とは、必ずしも「揮発性RAMにしか保存されない」という意味ではありません。会話の作業状態をデータベースにチェックポイントとして保存すれば、中断後に再開できます。たとえば、LangChainのメモリに関するドキュメントでは、チェックポイントを通じて永続化されるスレッド単位の状態と、個別の名前空間に整理される長期メモリを区別しています。

顧客が領収書をアップロードするのを待つ間、処理を中断するサポートエージェントを想像してみてください。保存されたチェックポイントは、そのサポート案件に属します。チェックポイントは永続的に保存されますが、顧客に関する一般的な事実として自動的に扱ったり、無関係なリクエストに表示したりすべきではありません。

あらゆるメモリ機能を評価する際には、保持期間、適用範囲、現在のモデル呼び出しで利用できるかどうかという3つの観点から考えるとよいでしょう。「長期」といったラベルだけでは、これらの問いに十分に答えられません。

アクティブメモリと永続メモリの違いをひと目で確認

同じ事実が両方の列に現れることもある。保存されたプロジェクトの設定は永続メモリーであり、今日のプロンプトに挿入されたその複製はアクティブメモリーだ。その複製をプロンプトから取り除いても、保存された元の情報が必ず削除されるとは限らない。

AIの応答が1回生成される間に何が起きるのか

一般的な言語モデルのアプリケーションでは、周辺のソフトウェアが入力を組み立て、モデルが出力を生成し、その後の処理をソフトウェアが決定する。入力には画面に表示されている会話が含まれる場合があるが、システム指示、ツールの説明、検索で取得したメモ、チャットの記録上ではユーザーに見えない情報が含まれることもある。

こうして組み立てられたコンテキストが、モデルにとって直ちに利用できる根拠となる。以前のメッセージがすでに含まれていない場合、アプリケーションがかつてそのメッセージを表示していたというだけでは、モデルはその正確な内容を確実に復元できない。周囲の手掛かりからもっともらしい答えを推測することはできるかもしれないが、推測と想起は異なる。

ツールを使うと、システムがアクセスできる範囲が広がる。モデルはプロジェクトファイルを要求し、その内容を受け取り、後続の応答で利用することがある。そのファイルは、モデルが利用できる根拠となる前から、アプリケーションがアクセスできる状態にあった。この違いがあるため、エージェントは大規模なアーカイブにアクセスできても、やり取りのたびにそのすべてを読む必要はない。

内部では、Transformerの実装も、処理の繰り返しを避けるためのキャッシュなど、計算状態を保持している。こうした仕組みは推論を効率化するうえで役立つが、ユーザーの好みやプロジェクトの履歴を記録し、編集や権限管理ができる仕組みと混同すべきではない。応答が速くなったからといって、個人用メモリーが作成されたとは限らない。

コンテキストウィンドウを広げてもメモリーの問題が解決しない理由

コンテキストウィンドウが大きくなれば、アプリケーションは一度により多くの情報をモデルに渡せる。長い文書や複数の関連資料にまたがる関係性が答えを左右する場合には、それが役立つこともある。しかし、どの情報を残すべきか、どのバージョンを正式なものとするか、ユーザーがその情報にアクセスしてよいかは決まらない。

また、情報をコンテキストウィンドウに収めても、モデルがそれを正しく使うとは限らない。「中間で見失う」研究では、検証対象のモデルの性能が、長い入力のどこに関連する根拠が現れるかによって異なりうることが示された。この結果は、うたわれている容量を想起の保証とみなすのではなく、コンテキストを実際にどれだけ有効活用できるかを評価すべきだという警告である。ただし、これは新しいモデルすべての性能を一律に予測するものではない。

あるプロジェクトのアーカイブに、公開日の議論が40件あるとする。そのうち39件では当初の日付が言及され、最後に承認された変更で日付が変更されている。この40件すべてを提示すると、情報を読み解く負担と、どの情報を正式とみなすかという問題が生じる。承認済みの変更とひも付けた最新状況の記録を適切に維持すれば、該当する答えを確認しやすくなる。

したがって、長いコンテキストと選択的な情報検索は互いに補完し合う。検索によって有用な根拠を集め、十分に大きなコンテキストによって、モデルがそれらをまとめて検討できるようにする。どの方法を選ぶかは、タスク、元資料の量、条件の見落としがもたらす影響によって異なる。

情報が永続メモリーになるまで

永続的なメモリーは、情報を保存する判断から始まる。アプリケーションは、ユーザーの明示的な指示を保存したり、会話から候補となる事実を導き出したり、出来事を記録したり、要約を作成したりできる。方法によって、得られる根拠の種類は異なる。

「Project Cedarでは、メートル法を使う」は、明示されたプロジェクトの設定だ。「ユーザーはメートル法を好むようだ」は推測である。「直近のCedarのレポート3件では、メートル法が使われていた」は観察結果だ。将来のすべてのタスクに当てはまると無条件に断定するのではなく、こうした違いを記録に残すことが重要である。

有用な記録に含まれる情報

仮想的なプロジェクトアシスタントの場合、記録には、記述内容、プロジェクト識別子、その情報が属するユーザーまたは組織、情報の出所となったやり取り、タイムスタンプ、有効性の状態、例外事項を含めることができます。これらの項目があれば、情報の出所や、現在も適用されるかどうかを確認できます。

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

これはあくまで一例として示すスキーマであり、普遍的な標準ではありません。メモリに文だけでなく、より多くの情報を持たせる理由を示すことが目的です。出典の参照情報があれば検証に役立ち、適用範囲を定めれば過度な一般化を防げます。また、状態の項目があれば訂正が可能になります。

即時書き込みとバックグラウンド処理

即時に書き込めば、明示的な訂正内容を次のリクエストから利用できるようになります。バックグラウンド処理では、完了したやり取りを調べ、重複をまとめたり、より熟慮した要約を作成したりできます。LangChainのドキュメントでは、両方の方法とそれぞれのトレードオフについて説明しており、即時応答の処理経路に追加の作業が生じる点も取り上げています。

実用的な設計では、確認済みの設定をすぐに保存し、長時間にわたる調査セッションは後から処理する方法が考えられます。その場合でも、この2つの処理の間の時間を適切に扱う必要があります。書き込みが成功する前に、設定を保存したとシステムがユーザーに伝えてしまうと、次の会話で継続性の不具合が明らかになる可能性があります。

メモリへの書き込みには、失敗時の対応方針も必要です。ストレージが一時的に利用できない場合、アプリケーションは保存が完了しなかったと伝えるか、保留中の操作であることを明確に示して保持できます。書き込みを試みただけなのに、メモリへの保存が成功したものとして扱うと、ユーザーに誤解を与えます。

永続メモリからアクティブなコンテキストに情報を戻す方法

情報の取得では、利用資格、関連性、証拠について一連の判断が行われます。まずシステムは、参照を許可された記録の対象となるユーザー、テナント、プロジェクト、またはタスクを特定する必要があります。次に候補となる記録を見つけ、応答のコンテキストに含める情報を選びます。

取得方法は質問に合わせる必要があります。「Cedarで承認された期限はいつですか？」という質問には、プロジェクトの該当項目を正確に検索する方法が適しているでしょう。「このデプロイエラーは以前にも発生しましたか？」という質問には、過去のインシデントを対象とするキーワード検索や意味的類似性の検索が役立つ可能性があります。ベクトルデータベースはこの処理で利用できる選択肢の1つであり、すべてのメモリに必須というわけではありません。

表現が変わる場合、意味検索が特に役立ちます。「レポートを簡潔にする」という検索語から、「短い経営要約」という設定が保存された記録が見つかることがあります。ただし、関連する記述が別のクライアントに関するものだったり、プロジェクトの放棄されたバージョンに関するものだったりする可能性もあります。類似性によって候補は特定できますが、その情報が正しいことや、利用が許可されていることまでは証明できません。

情報が見つからない場合の結果も必要

「先月、私が承認した支出上限はいくらでしたか？」という質問を考えてみましょう。承認された金額が見つからない場合は、証拠が不足していることを伝え、確認を求めるのが適切です。もっともらしい数字を提示すれば、記憶に情報がない状態を、承認を捏造する結果に変えてしまいます。

したがって、メモリーインターフェースでは、一致が確認された場合、不確かな一致、矛盾、裏付けとなる記録がない場合を区別する必要があります。それぞれの結果に応じて、直接回答する、確度に留保を付けて回答する、確認を求める、裏付けのない前提に基づく行動を控えるなど、異なる対応が求められます。

情報を取得した後も、その解釈が重要です。「提示された上限予算：5,000ドル、承認待ち」と記録されているものを、「承認済み予算：5,000ドル」としてはなりません。保存された情報と提供されたコンテキストの両方で条件や留保を維持することは、正しい文書を見つけることと同じくらい重要です。

具体例：プロジェクトの記憶を時間をかけて維持する

チームがCedarの調査レポートを作成するのをアシスタントが支援する場面を想像してください。以下の例は仮定上のものですが、メモリー設計でよく見られる選択肢をいくつか浮き彫りにします。

セッション1：プロジェクトを開始する

ユーザーはレポートの作成を依頼し、メートル法の単位を指定して3つの資料を提供し、草稿の締め切りは金曜日だと伝えます。アクティブコンテキストには、これらの指示と資料の抜粋が含まれます。アクティブなタスク状態には、完了したセクションと、まだ検証が必要な主張が記録されます。

永続的に保存する候補の記録には、それぞれ異なる用途があります。メートル法を使うという希望はプロジェクトに属します。草稿の締め切りは現在のマイルストーンに属します。提供された資料は、プロジェクトの根拠資料アーカイブに保存します。未検証の主張は、不確実性を保ったまま、調査待ちリストに記録します。

セッション2：適切な根拠を使って作業を再開する

3日後、ユーザーは方法のセクションを仕上げるよう依頼します。アシスタントには、最新のアウトライン、関連資料、現在のタスク状況、適用される書式ルールが必要です。以前のブレインストーミングで破棄された文をすべて必要とするとは限りません。

チェックポイントに文献レビューが完了したと記されていても、アシスタントはその周辺を編集する前に、保存された成果物を開いて確認するべきです。「完了」は進捗についての主張であり、実際の文書こそが何を完了したかを示す根拠です。成果物への永続的な参照情報は、その全内容を再現しようとする要約よりも役立つ場合があります。

セッション3：すべてを書き直さずに例外を適用する

ユーザーは、メートル法とヤード・ポンド法の両方の単位を使ったクライアント向け版を依頼します。今回のタスクでは、両方の単位を使う必要があります。プロジェクト全体のルールも変更するかどうかは、ユーザーの表現と適用範囲によって決まります。「この版では」は、「今後は両方を使って」の場合よりも適用範囲が狭い表現です。

慎重なアシスタントは、特定の版に限った例外として記録します。一般化しすぎるアシスタントは全体に適用される希望を書き換え、その後のレポートに誤りを持ち込みます。データベースへの書き込みや情報の取得がすべて成功していても、これはメモリーの失敗です。

セッション4：作業を完了し、一時的な状態を整理する

納品後、マイルストーンを完了として記録します。「レポートを続けて」という指示を受けた場合、アシスタントは古くなったチェックリストから作業を再開するのではなく、納品済みの版を確認し、どのような修正が必要かを尋ねるべきです。一時的な作業メモはプロジェクトの方針に従って期限切れにできますが、最終レポートや重要な決定は引き続き参照できる状態にしておきます。

ここに、永続的なメモリーの価値が表れています。説明を繰り返す手間が減り、継続性が高まります。同時に、そのコストも明らかです。アプリケーションは、希望、例外、成果物、変化するタスク状況の間の関連性を維持しなければなりません。

要約、圧縮、そして例外を失うリスク

長いやり取りでは、次の応答に役立つ量を超えて情報が蓄積することがあります。圧縮では、履歴の一部をより小さな表現に置き換えます。要約には、目的、決定事項、未解決の質問、元の作業への参照情報などを残すことができます。

Anthropicのコンテキストエンジニアリングに関する指針では、長期にわたる作業の継続性を保つ方法として、圧縮と、コンテキストウィンドウの外部に保存したメモに言及しています。どちらの手法も、将来の応答で利用できる情報を変えるため、その品質が重要です。

圧縮は、情報を選別して行います。「メートル法の単位を使う」という要約は、「クライアント向け版では両方の単位が必要なため、それ以外ではメートル法の単位を使う」より短くなります。しかし、プロジェクトの重要なケースの一つに照らせば、誤りでもあります。失われた例外は、その後の要約にも気づかれないまま引き継がれ、原因をたどるのが難しくなることがあります。

Cedarのアシスタントにとって、より適切な引き継ぎ情報には、全体に適用されるルールとその例外、完了したセクション、残っている検証作業、最新ファイルへの参照を含めるべきです。承認額や識別子など、正確さが重要な詳細は、近似すると問題が生じる場合、構造化された記録または元の文書に残しておく必要があります。

要約では、不確実性も維持する必要があります。「Survey Bの使用を検討した」が、「Survey Bを選定した」に変わってはなりません。圧縮された履歴によって暫定的な決定が確定事項のように見えるなら、システムはコンテキストを節約しようとする過程で、誤った記憶を作り出したことになります。

AIのメモリーは訂正や矛盾にどう対処すべきか

変化できなければ、永続メモリの有用性は低下します。プロジェクトは進行し、好みは変化し、以前の情報が誤りだと判明することもあります。訂正を、特に位置づけを示さないまま別の記録として追加すると、検索システムが矛盾する2つの記述のどちらを選ぶべきか判断できなくなる可能性があります。

より有用な更新では、新しい根拠によって何が置き換えられるのかを明確にします。プロジェクト責任者が開始日を11月15日から11月29日に変更した場合、古い記録を「置き換え済み」として扱い、新しい決定に関連づけることができます。現在の期限についての質問には新しいバージョンを使い、当初の計画についての質問には過去のバージョンを参照できます。

新しさだけですべての矛盾を解決できるわけではありません。最近の草案メモより、古くても承認済みの方針のほうが権威を持つ場合があります。ユーザーは個人的な好みを変更する権限を持っていても、組織全体に適用されるルールを変更する権限はないことがあります。更新方針では、事実の種類と情報源の権限を考慮する必要があります。

人が明確にするまで、解決せずに残しておくべき矛盾もあります。2人のプロジェクト責任者が、明示的な置き換えの指示なしに両立しない日付を示した場合、アシスタントは両方の情報源を提示し、どちらを優先すべきか尋ねることができます。最も似ている記録や最も新しい記録を黙って選ぶと、システムに決定する権限がないかもしれない事柄について、判断を下したことが隠れてしまいます。

AIが「忘れる」とはどういう意味か？

忘却は、単一のスイッチで切り替わるものではありません。製品は、ある事実をプロンプトに挿入しないようにしたり、通常の検索対象から除外したり、古い情報として扱ったり、メモリの記録を削除したり、保持されているほかのコピーを削除したりできます。これらの操作は、今後の動作や保持データにそれぞれ異なる影響を与えます。

アクティブなコンテキストから外れる

古いメッセージが省略または要約されると、次のモデル入力から事実が消えることがあります。その結果、モデルが直ちに利用できる情報は減ります。ただし、元の会話記録やメモリの記録は残っている可能性があり、その後の検索を通じて再び取り込まれることもあります。

想起の期限切れまたは抑制

期限切れになった締め切りは、アーカイブに残したまま、現在の作業に関する検索対象から除外できます。過去の記録を保持する目的がある場合、抑制は有用ですが、完全な削除と説明すべきではありません。過去の記録を検索する機能や管理業務の手順からは、引き続きその記録にアクセスできる場合があります。

保存されたメモリを削除する

長期保存された記録を削除する際は、そこから派生した検索用表現にも対処する必要があります。プロフィールから文を削除しても、検索可能な要約にその文が残っていれば、アシスタントが後になって同じ好みを再構成する可能性があります。アーキテクチャによっては、元の記録、埋め込み、要約、キャッシュ、レプリカについて、それぞれ個別に削除作業が必要になることがあります。

バックアップやログには、独自の保持スケジュールが適用される場合があります。製品はこうした制約を明確に説明し、復元時に削除済みのデータが再び有効にならないようにする必要があります。「今後このメモリを使用しない」と「保持されているコピーをすべて削除した」は、異なる約束です。

モデルの重みを変更する

外部メモリを削除しても、それだけではモデルのパラメーターは変わりません。情報が学習に使われていた場合、モデル内でその情報に対処するには、学習とデプロイのプロセスに関わる別の対応が必要です。同様に、個人のメモリを削除しても、一般知識や新しいプロンプトで与えられた手掛かりから、モデルが似た事実を生成する可能性をなくせるとは限りません。

したがって、意味のある忘却テストでは、システムがその情報をまだ保存しているかどうかと、通常の検索経路を通じてその情報が再び呼び出される可能性があるかどうかの両方を確認する。一度のチャット応答で「忘れました」と言っただけでは、どちらも証明できない。

メモリ、RAG、学習、キャッシュ：それぞれの境界

検索拡張生成（RAG）は、生成時にモデルへ外部の証拠を提供する。初期のRAG研究では、モデルのパラメーターと、検索可能な文書インデックスが組み合わされていた。個人向けメモリシステムも検索を利用できるが、それに加えて、やり取りから得た記録を作成、更新、廃止するための方針も必要となる。

会社のマニュアルは、ユーザーの記憶ではなくても検索できる。過去のやり取りに関するメモは、ベクトルインデックスがなくても、単純なファイルから検索できる。検索はあくまで仕組みであり、基盤となる記録の目的とライフサイクルによって、構築されるシステムの種類が決まる。

学習とファインチューニングは、モデルのパラメーターを変更する。一方、通常の外部メモリは、モデルに与える証拠を変える。新たに保存された好みに従うアシスタントは、モデルの重みが変わらなくても、異なる振る舞いをすることがある。

プロンプトキャッシュと推論キャッシュは、対応している場合、過去の計算を再利用する。これらは効率を高めることはできるが、記憶された主張が最新か、利用を許可されているか、今後のタスクに適しているかを、それだけで判断するものではない。こうした各層は併存しうるため、問題の原因を調べるには、観察された挙動の責任がどの層にあるのかを特定する必要がある。

MemGPTは、影響力のあるアーキテクチャの例を示している。オペレーティングシステムになぞらえ、限られたコンテキストと外部メモリの各階層との間で情報を移動させる方法を探った。ここから得られる重要な教訓は、情報の移動を明示的に管理することであり、保存領域を増やせば制限なくモデルの即時コンテキストも自動的に拡張されると考えることではない。

永続メモリによって誤りが長く残る理由

誤った応答は一度のやり取りに影響することがある。誤った記憶は、多くのやり取りに影響する可能性がある。アシスタントが、ユーザーはある決定を承認したと推測し、その推測を事実として保存して、後に保存した記録を根拠として挙げた場合、以前の誤りが、独立した証拠に裏付けられているかのように見えてしまうことがある。

私たちのプロジェクトアシスタントでは、元の情報源とモデルによる解釈を区別できる状態にしておくべきだ。決定の要約は内容を探す際に役立つが、重大な結果を伴う行動の根拠となるのは、承認された決定そのものであるべきだ。生成された複数のメモに同じ内容が繰り返し記載されても、裏付けのない一つの推測が、複数の独立した確認に変わるわけではない。

永続メモリは、指示が汚染される経路にもなりうる。信頼できない文書に、アシスタントの今後の振る舞いを変えるよう求める一文が含まれているかもしれない。その一文を運用ルールとして保存すれば、外部コンテンツを権限の境界を越えて持ち込むことになる。アプリケーションは、メモリストアに含まれているからといって信頼された指示に格上げするのではなく、情報源に応じてその内容を扱うべきだ。

共有環境では、別の境界も加わる。ある事実が質問に関係していても、別の顧客やプロジェクトに属する可能性がある。情報がモデルに届く前に、アクセス制御によって検索対象を制限すべきだ。許可されていない記録をすでに渡した後で、無視するようモデルに求める設計は、それよりも脆弱である。

メモリが実際に機能しているかを評価する方法

説得力のあるデモでは、保存した好みを一つ、アシスタントに繰り返させることがよくある。本格的な評価では、複数のセッションにわたって変化する情報を追跡し、メモリによってタスクの完了度が向上するかを確認する。

LongMemEvalは、情報抽出、セッションをまたぐ推論、時間に関する推論、知識の更新、回答の差し控えを評価する。これらの評価項目は、長期メモリの品質が、単に一致する一文を検索する能力にとどまらない理由を示している。公開されているベンチマーク結果は、あらゆる現行製品に当てはまるとみなすのではなく、テスト対象となったシステムと設定に照らして解釈すべきだ。

Cedarのワークフローでは、好みを提示し、プロジェクトを再開し、例外を追加し、期限を変更し、メモを削除したうえで、古くなった情報や裏付けのない記憶の呼び出しが表面化するよう設計した質問をする評価が考えられる。また、システムの追加によって成果が向上するかを確かめるため、同じモデルをメモリ機能なしでもテストすべきだ。

• 書き込み精度：システムは、適用範囲や条件を含め、意図した内容を保存したか？
• 検索の有用性：無関係な履歴でコンテキストをあふれさせることなく、タスクに必要な証拠を見つけたか？
• 更新への対応：有用な過去の情報との区別を保ちながら、訂正内容で現在の事実を置き換えたか？
• 回答の差し控え：裏付けとなる記録が存在しない場合、そのことをアシスタントは認めたか？
• 分離：記録は適切なユーザー、テナント、プロジェクトの範囲内にとどまっていたか？
• 忘却：削除や期限切れによって、派生した要約を含め、意図した将来の想起を防げたか？
• 運用コスト：遅延、モデル呼び出し、ストレージ、保守の増加に見合うだけの改善があったか？

失敗の原因は、どの段階で起きたのかを特定する必要があります。回答が得られない場合、書き込みの失敗、検索範囲の誤り、不適切な順位付け、条件の抜け落ち、あるいはモデルが適切な根拠を誤読したことが原因かもしれません。コンテキストのサイズを大きくしても、こうした問題がすべて解決するわけではありません。

適切なメモリ設計の選び方

一度限りの文書要約なら、対象の文書と指示だけで十分な場合があります。中断した分析には、タスクのチェックポイントが役立ちます。継続的なプロジェクトを支援するアシスタントには、バージョン管理された決定事項や成果物への参照が必要になることがあります。多くのユーザーセッションをまたいで作業するアシスタントには、独立した編集可能な設定ストアが必要になる場合があります。

まず、そのメモリが将来どのような質問に答えるためのものなのかを明確にしましょう。「未完了の作業は何か」という質問には、タスクの状態が必要です。「このクライアントが求める形式は何か」には、対象を限定した設定情報が必要です。「なぜこの方法を採用しなかったのか」には、裏付けとなる証拠を含む決定記録が必要です。質問が異なれば、適した情報の表現方法も異なります。

パーソナライズと称して無差別にアーカイブするよりも、明確で出所を追跡できる記録を少数に絞ることを優先しましょう。現在の状態と過去の出来事を分け、元の成果物へのリンクを保持してください。また、設計の初期段階から、訂正や削除も組み込んでおきましょう。

アクティブメモリは、AIシステムに一貫した現在の状態をもたらします。永続メモリは、時間をまたいだ継続性をもたらします。その継続性の質は、両者の間でどのような判断を下すかに左右されます。何を保存し、何を呼び戻し、どのバージョンを優先し、何を消去できるようにするかが重要です。