github.devotd.
新着RAG・検索

fudan-generative-vision/remory — 要約の後ろに付く学習済み残余記憶

fudan-generative-vision/remory は、要約に条件づけられたソフトメモリを後付けし、エージェントが圧縮後も作業を続けられるようにする Python 実装である。

リポジトリ情報fudan-generative-vision/remory ↗

Remory: Learning Residual Memory for Context Compaction

スター
★ 268
フォーク
26
言語
Python
ライセンス
MIT
原文を見る ↗GitHub で見る ↗

fudan-generative-vision/remory は、コンテキスト圧縮のための残余記憶学習を扱う Python リポジトリだ。リポジトリの説明によれば、要約で圧縮したあとに学習済みのソフトメモリを後付けし、エージェントが元の文脈をすべて保持しなくても作業を続けられるようにする手法である。FACITS にはリリースバージョンが記録されていないため、特定バージョンの変更内容は確認できない。リポジトリは MIT ライセンスで、スターは 268 件だ。

エージェントが生成した要約は、残余記憶を生成する条件として使われる。そのため同じ要約でも異なる残余記憶が後付けされる可能性があり、元のモデルは凍結したまま使う。関連文書を検索して見つけるのではなく、連続埋め込みを注入するアプローチだ。論文は Qwen3.8-27B と GLM-5.3-Flash をバックエンドに使い、BrowseComp や Terminal-Bench 2.1 などの長期エージェントベンチマークで残余記憶の使用有無を比較した。SummHay では入力位置の 5.2% だけを使いながら、全体コンテキストに近いスコアを出したと報告している。デプロイは SGLang に接続する形であり、Qwen3.8-27B には 80GB 以上の GPU が 2 枚以上必要だと明記している。

性能の数値はグラフと論文にあり、README 本文には表として示されていない。また README によれば、デプロイ用の GLM エンコーダチェックポイントは 1.24B で、論文に記されたエンコーダは 1.502B だ。そのため、デプロイ用チェックポイントを用いた評価を論文の数値と同じ条件とみなすことはできない。必要な GPU 条件まで考えると、このアプローチは参考になるが、再現と結果の比較には制約がある。