顕著性（Salience）は継続価値（Carry Value）ではない

ほとんどの人は、エージェントのメモリ構築を間違えている。

彼らはストレージに固執する。ベクトルストアや巧妙な要約機能を使う。すべてを保存すれば、エージェントはすべてを知ることができると考えている。

それは間違いだ。

セッションが数百に及ぶとき、そのすべてを読み返すことはできない。エージェントが新しいセッションを「コールド（情報の蓄積がない状態）」で始めると、時間を浪費する。ノイズが多すぎると、ミスを犯す。

問題は「選択」だ。多くの人は、顕著性（Salience）と継続価値（Carry Value）を混同している。

  • 顕著性（Salience）は、前回のセッションで何が目立っていたかを示すもの。
  • 継続価値（Carry Value）は、次のセッションが機能するために何が必要かを示すもの。

変数名に関する激しい議論は、顕著性が高い。しかし、その名前が将来のコードに影響を与えないのであれば、継続価値はゼロだ。それを引き継いでしまうと、単にノイズを増やすことになる。

私は、以下のルールに基づいたメモリパイプラインを運用している：

  1. まずは機械的な顕著性（Mechanical salience）。 決定論的なスコアラーを使用して、重要な瞬間を見つけ出す。単純なコメントよりも、修正（corrections）の重みを高く設定する。すべてのハイライトは、生のトランスクリプトに紐付いていなければならない。モデルにソースなしで事実を捏造させてはならない。

  2. 次に合成（Synthesis）。 ハイライトに意味のレイヤーを加えるためだけにLLMを使用する。ハイライトの質が悪ければ、要約はただの「自信満々なデタラメ」になる。

  3. 検索時のブリーフィング（brief）を使用する。 プロジェクトごとに INDEX.md のようなファイルを作成する。エージェントはセッションの開始時にこのファイルを読み込む。モデルがその場でこのブリーフィングを捏造すべきではない。それは、手動で開いて編集できるプレーンなファイルである必要がある。

より良いメモリを構築するには、単なる「重要な事項のリスト」以上のものが必要だ。以下のものが必要になる：

  • 2つのスコア：どれほど目立っていたか（salience）と、後でどれほど重要になるか（carry value）。
  • メモリのクラス分け：アクティブな決定、運用上の制約、および未完了のループ（open loops）を分ける。
  • 有効期限：すべてのメモリには、消滅する理由がなければならない。有効期限がなければ、コンテキストがシステムを圧迫する。
  • トリガー：メモリがいつ表示されるべきかを正確に定義する。

目標はリカバリーコスト（recovery cost）を最小化することだ。

リカバリーコストとは、エージェントが中断した箇所まで追いつくのにかかるトークン数や時間のことを指す。メモリパイプラインが単なる「見せかけ」であれば、リカバリーコストは高いままだ。

ストレージを大きくするのはやめよう。より優れた「選択」の仕組みを作り始めるのだ。

Source: https://dev.to/jugeni/salience-is-not-carry-value-notes-from-a-running-session-memory-pipeline-4dda

Optional learning community: https://t.me/GyaanSetuAi