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

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

概要

  • 長期的なアシスタントやエージェントシステムにおける履歴情報の蓄積と再利用の重要性
  • 単純なコンテキストウィンドウ拡張の限界
  • $\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

固定サイズの状態に収められる情報量には限界があるけど、理論的な上限はかなり高いよ。ヘッブ型の連合行列(最もシンプルで弱いメモリ構造の一つ)は、パラメータごとに約0.7ビットの情報を保存できる。300Mのパラメータを持つ状態(Llama 3の8B KVキャッシュで10Kコンテキスト長)と、トークンごとに2.1ビットのエントロピーを持つコンテキスト(妥当な推定)を考えると、その状態は1億トークン分の情報をエンコードできる。実際のモデルは限界で動作するほどの力はないけど、これが有望な研究方向である理由はわかるよね。

ヘッドラインがΔ-Memを示してるのに、論文ではδ-memを使ってるのが面白いね。小文字から大文字への変換が行われてるのかな?

正解!

うーん、これはHNのタイトルの改変で意味が変わっちゃったケースだね。小文字のデルタ(δ)は意図的に使われてるんだ。HNが非ASCII文字の大文字小文字を自動で変更するべきじゃないと思う。

ASCII文字でも、数学や物理の用語は通常、大文字小文字を区別するからね。

提出者には、提出後数分間の編集猶予があるから、HNのやり方を変える必要はないよ。

hn@ycombinator.comにメールすれば、直してくれるよ。

モデルを読み込んで実行するのに必要なメモリ量を、他の指標と一緒にバイト単位で常に報告するのがスタンダードになってほしいな。最初のトークンまでの時間やトークンのスループット、レイテンシも見たいけど、まずは上記のメモリサイズが知りたい。要するに、多くの人が特定のモデルを動かすのに必要な最小メモリ量を知りたいんだ。パラメータ数だけでは重要な詳細が見えにくい。パラメータのサイズはどうなってるの?パラメータは厳密に定義されてないから、4BパラメータのFP16モデルと4BパラメータのINT4モデルは全然違う。前者は明らかに後者よりもずっと良いはずだよね。これ、MOEモデルにも役立つと思う。もしメモリが制約なら、(もっと大きなRAMが必要な)MOEバージョンが速いとか評価が良いとか関係ないし。怒っている誰かが、PyTorchによるとパラメータが4GBの単一パラメータの1パラメータモデルを出すのを待ってるよ。

基本的に、既存のLLMにDeltaNetハイパーネットワークを追加しただけだね。特に新しいことはないけど、まあまあ興味深い読み物だよ。

例えば、エージェントがリポジトリのガイドラインを覚えておくためのメモリ機能みたいなものってあるの?毎回セッションの最初に4つのマークダウンファイルを読み込ませて、その分のトークンを消費しなくても済むように。

いや、全部プロンプトだけだよ。記憶を簡潔に要約してエージェントに長いマークダウンファイルを指し示すことはできるけど、いつそれを適切なタイミングで読むかなんて誰にもわからないよ。

未来は、モデルがジャーナルを読むように過去のトークンを振り返ることができる、大量のトークン履歴を持つ固定サイズの状態だと思う。このようにモデルを再構築することで、本質的に無限のコンテキストを持つ新しいタイプのエージェントが生まれる。GPUに完璧に収まって、比較的簡単に保存・取得できて、基本的に永遠に動かせる。固定サイズはθ1トークンを意味する。周りを見渡すことができるモデルは、過去のトークンのジャーナルを見ているかのようにメモリを見渡すことができる無限のメモリを追加できるってこと。ガイド付きの注意ウィンドウがこれをほとんど実現できて、他のトリックが残りを補うことができるよ。