会話を続けるAIには、過去を覚えていてほしい。 けれど、すべての会話をそのまま渡し続けると、必要な情報が埋もれ、コストも判断のぶれも増えていく。
記憶の設計で考えたいのは、何を保存できるかではない。 次の会話で本当に必要になる情報は何かである。
会話ログと、次に使う記憶は別にする#
会話ログには、発言の流れや検証の過程が残る。 問い合わせ対応の監査や、あとで問題を確認するためには役に立つ。 ただし、毎回の応答に必要なのは全文ではないことが多い。
次の会話に渡す記憶は、用途別に短く持つ。
- 事実：利用者が明示した所属、対象、制約
- 判断：すでに決めた方針、保留した論点
- 好み：文章の長さ、回答形式、避けたい提案
- 進行中の作業：次に確認すること、期限、担当
この分類を混ぜると、「以前そう言っていた」という記録と、「今もその方針でよい」という判断を取り違えやすい。 会話の途中で変わりうる情報は、事実として固定しないほうがよい。
要約には、更新する条件を持たせる#
要約は一度作れば終わりではない。 古い要約を積み重ねると、現在の状態が分からなくなる。
たとえば旅行の相談なら、予算や日程の変更は新しい値で置き換える。 カスタマーサポートなら、問い合わせの結論と次の対応だけを更新する。 要約の項目ごとに「いつ確認したか」と「どの発言から得たか」を残しておけば、矛盾が出たときに戻れる。
AIに要約を作らせる場合も、以前の要約と今回の会話を比較し、追加、更新、削除を分けて出させると確認しやすい。 全文を一つの段落へ圧縮するより、差分として扱うほうが記憶は育てやすい。
忘れることも、機能の一部にする#
保存してはいけない情報や、保存し続ける理由のない情報がある。 個人情報、機微な事情、一時的な感情、完了済みの手続きは、利用目的に応じて保持期間を決める。
利用者が内容を確認し、修正や削除を選べる経路も必要だ。 記憶を便利にするほど、何を覚えているかを見せない設計は不安を生む。
記憶の品質は、答えの自然さだけでは測れない#
以前の話を覚えているように見えても、古い前提で提案していたら役に立たない。 評価では、会話が自然につながるかに加え、不要な情報を持ち出さないか、更新後の方針を優先できるか、削除要求を反映できるかを確認する。
記憶は、会話を長くするための保存庫ではない。 利用者が同じ説明を繰り返さず、今の判断に集中するための短い作業台である。
