長期メモリとコンテキストの管理

保存されている情報と、モデルが今見ている情報

前の節では、一つの会話の状態を保存する仕組みを学びました。ここでは、保存した情報のうち何を今回の入力へ渡すかと、別の会話でも使う情報をどこへ置くかを分けて考えます。

モデルが一回の生成で参照する入力全体を、ここではコンテキストと呼びます。回答方針、今回の質問、会話履歴、検索した資料、ツールの結果などが含まれます。アプリケーションのどこかにデータを保存していても、その情報を今回のモデル入力へ渡さなければ、モデルはその内容を参照できません。

このため、「覚えている」という言葉には二つの意味が混ざります。一つは、アプリケーションが情報を保存していること。もう一つは、今回のモデル呼び出しでその情報を参照できることです。メモリの設計では、何を残すかだけでなく、いつ取り出し、どの範囲を渡すかも決めます。

短期メモリと長期メモリは、使う範囲が違う

短期メモリは、主に一つの会話や処理のまとまりに属する状態です。「今は大阪出張の交通費について相談している」という文脈が当てはまります。前の節で説明したcheckpointerは、このthreadに属する状態を保存・復元するために利用します。

長期メモリは、別の会話でも再利用したい情報です。たとえば「回答は簡潔にしてほしい」という利用者の希望は、会話が変わっても使いたいかもしれません。LangChainの関連基盤では、Store（ストア）という保存・取得の仕組みを利用できます。利用者や組織ごとの区画に当たる「名前空間」と、その区画内で項目を見つけるための「キー」などで情報を整理します。

ここでのキーは、保存した項目を見つけるための名前です。第3節のAPIキーはサービスへ接続するための秘密の認証情報で、役割が異なります。同じ言葉が出てきても、何を識別し、何のために使うかを見ると区別できます。

短期・長期という名前は、主に情報を使う範囲の違いです。長期メモリでも、保存先が実行中だけの記憶領域なら再起動で失われます。会話をまたぐことと、アプリケーションの再起動をまたいで保存できることは、別々に確認します。

長期メモリを作ることは、モデル本体を追加学習することとは異なります。情報を外部に保存し、必要なときに取り出して入力へ含める構成です。保存内容を更新したり削除したりできるのは、この外部データとしての性質によります。

何でも保存すると、誤りも長く残る

会話中にモデルが「この人は営業部だろう」と推測しただけなのに、それを本人の確定情報として保存すると、次の会話でも誤った前提が使われます。利用者が明示した事実、システムから確認できた事実、モデルの推測は区別する必要があります。

長期的に残す情報には、確認した時点、根拠、更新の可否が重要です。部署や勤務形態のように変わる情報を、一度保存したから永久に正しいと扱うことはできません。記憶を増やす機能だけでなく、訂正する、期限を設ける、不要になったものを消すという扱いも必要です。

コンテキストの選択には、目的がある

「日帰りの場合は？」という追加質問では、直前の出張相談を渡す必要があります。しかし、昨日の別件の相談全文まで渡す必要はありません。一方、申請の例外条件が前の会話で確定しているなら、その条件を落とすと誤った回答になります。単純に古い順で切るだけでは、必要な情報が欠ける場合があります。

直近の会話を残す方法は単純ですが、以前に決まった条件を失いやすい面があります。要約は入力を短くできますが、要約自体に省略や誤りが入り得ます。重要な条件を項目として状態へ保持する方法は、内容を明示しやすい一方、どの項目を残すかの設計が必要です。これらは目的に応じて組み合わせます。

会話の記憶と、資料の検索は役割が違う

利用者が何を相談しているかを保つことと、最新の社内規程を調べることは同じではありません。会話の記憶は質問の文脈を補い、規程の検索は回答の根拠を補います。以前の会話に出てきた規程の説明が、現在も有効だとは限らないため、根拠資料の更新は別に扱います。

長期メモリに保存した情報を探す際にも、資料検索と似た方法を使う場合があります。仕組みが一部重なっていても、「利用者の希望を思い出すためか」「規程の根拠を取得するためか」という目的を分けると、保存や更新の方針を決めやすくなります。

次の章のRAGは、この「必要な外部情報を検索して入力へ加える」構成です。短期メモリ、長期メモリ、RAGは同時に使えますが、それぞれ何を保存・検索し、何のためにモデルへ渡すのかを分けて理解すると、混乱せずに組み合わせられます。