ハクソク

世界を動かす技術を、日本語で。

δ-mem: 大規模言語モデルのための効率的なオンラインメモリ

2026年5月16日原文(arxiv.org)

概要

  • 長期的なアシスタントやエージェントシステムにおける履歴情報の蓄積と再利用の重要性
  • 単純なコンテキストウィンドウ拡張の限界
  • $\delta$-mem による軽量なメモリ機構の提案
  • 固定サイズの状態行列による効率的な情報圧縮と更新
  • メモリ負荷の高いベンチマーク での顕著な性能向上

長期記憶のための軽量メモリ機構「$\delta$-mem」

  • 大規模言語モデル （LLM）における長期的な履歴情報の蓄積・再利用の必要性
  • コンテキストウィンドウの単純な拡張は
    • 計算コスト増大
    • 効果的な文脈利用の保証困難
  • $\delta$-mem の提案
    • フルアテンションのバックボーンを 凍結
    • 小規模なオンライン状態の 連想メモリ を追加
  • 過去情報を 固定サイズ状態行列 へ圧縮
    • デルタルール学習 で逐次更新
    • 読み出し結果をアテンション計算へ 低ランク補正 として活用
  • 8×8 の小型オンラインメモリ状態のみで動作
  • 平均スコア
    • バックボーン単体比1.10倍
    • 最強非$\delta$-memメモリベースライン比 1.15倍
  • メモリ依存度の高いベンチマーク
    • MemoryAgentBench：1.31倍
    • LoCoMo：1.20倍
  • 一般能力の大部分を維持しつつ 大幅な性能向上 を実現

$\delta$-memの技術的特徴

  • フルファインチューニング不要
    • バックボーンの 置換や再学習不要
  • 明示的なコンテキスト拡張なし でメモリ強化
  • アテンション計算と 直接連携 する コンパクトなオンライン状態 による効果的な記憶実現
  • 計算効率 と メモリ効率 の両立

今後の展望と意義

  • 長期対話エージェント や 履歴依存タスク での応用拡大
  • 低リソース環境 や オンデバイス実行 での有用性
  • メモリ機構の設計指針 として新たなアプローチの可能性

Hackerたちの意見

LLMに記憶力を持たせるための技術がたくさん提案されてるけど、AIコーディングエージェント用のメモリープラグインも結構見かけたし、自分でもいくつか試してみたよ。実際に役立つと証明されたものを見てみたいな、特にコーディングエージェントにとって。

└

この場合、リコールをどう考える？ 現在のコードやgitの履歴を検索するだけじゃ足りないの？

└

コーディングエージェントにはメモリはあんまり必要ないよ。エージェントのスキル、ルール、gitの履歴、ドキュメントの方がずっと効率的で透明性があって管理しやすい。これらのメモリフレームワークは、消費者向けのエージェントを作る場合にのみ意味があると思う。

明らかにエネルギーを節約する方法は、他の人の過去の検索を活用することだね。多くの人がやるタスクは似たようなものが多いから、毎回ゼロから始めるのは無駄すぎるよ。（もちろん、そもそもそのタスクをやる必要があるかどうかを観察するのが一番のエネルギー節約だけど。）

└

LLMを使ってる人たちがやってることの多くは、[スクリプト]でより安く、確実にできると思う。「sedを試してみた？」みたいな検索エンジン風の提案があれば、いいと思うな。

└

こんなことを考えて、https://pushrealm.com を作ったんだ。これは基本的にエージェントが書いたスタックオーバーフローみたいなもの。僕の理論は、エージェントがトレーニングデータにない問題を解決するのに30分かかるなら、その解決策を投稿することで他のエージェントが同じ思考ステップを踏むのを防げるんじゃないかってこと。

面白いポイントだね： - メモリの固定サイズは、現在の制限を克服するための良いアイデアに思える - ざっと見た感じ、コストについての言及が見当たらない？ - これが本当に正当なもので、単なる過剰適合やテストデータでのトレーニングの派手な形じゃないかを確認するには、もっと時間が必要だな。

δ-memは過去の情報を固定サイズの状態行列に圧縮し、デルタルール学習で更新する これじゃメモリの容量問題は解決しないよね。1つのコンテキストウィンドウにもっと詰め込むことはできるけど、結局それを入力クエリに関連付ける必要がある。それがすごく難しいのは、入力のわずかな変化が全く違うアクティベーションを生むから。だから、実際にはキャッシングを改善するわけじゃない。この論文はコンテキストウィンドウの圧縮限界を近似することはできるかもしれないけど、どれだけの情報を入れられるかには根本的な限界がある。必要なのは、同じ抽象や意味を持つ異なるイベントやオブジェクトが同じ反応を引き出せるようなコンテキスト検索なんだ。そうすれば効果的にキャッシュできる…この点に関しては、この論文は「メモリ」を意味のある形で改善することはほとんどないね。

└

今、動的に生成された正規表現を使って、関連するコンテキストブロックだけを引き出す深いコンテキストクエリに取り組んでるんだ。軽量な正規表現パターンマッチングを使って、意味的な意図を検出し、構造化されたコンテキストセクションを適切にフィルタリングすることで、意味的に冗長な情報をウィンドウに詰め込むことによる注意力の低下を避けられるよ。 https://jdsemrau.substack.com/p/tokenmaxxing-and-optimizing-...

└

Ferriculaみたいな感じだね。 https://deepbluedynamics.com/ferricula （サイト/ドキュメントはまだ進行中）。

└

つまり、メモリ管理にFIFOアプローチを使う代わりに、どんどんデータが劣化していくってこと？入れるほどに詳細が失われたり、変な風になったりするの？

└

モデルのコンテキストやメモリデータについて、逆の視点で何か書いたことがあるんだ。情報の重力的引力は管理がすごく難しい。ここ30日間「機能的な傷」を使ってみて、セッション間の繰り返しミスに対して良い結果が出てるよ。 https://github.com/VDP89/fscars

Hacker Newsで議論の続きを見る