2026-09-05·★ 会員·論文·18分で読めます

論文解説: LatentPress — 圧縮した文脈を、テキストにも画像にも戻さずLLMに直接読ませる

長い会話履歴や文書を「テキストの要約」でも「画像」でもなく、凍結したLLMがそのまま読める連続ベクトル（ソフトトークン）に書き込む手法。LongMemEvalで7.70倍圧縮しながら非圧縮を上回った論文を、前提知識ゼロから解説する。

#context-compression #long-context #soft-tokens #memory #inference

LatentPress: Context Compression Beyond Text and Vision

一次資料 — この記事の根拠

論文の発表 2026-09-01→この解説の公開 2026-09-05同月

LatentPress: Context Compression Beyond Text and VisionZhengze Zhou, Hejian Sang · 2026-09-01 · v2arXiv:2609.01507論文ページ·PDF

原文の要旨（Abstract）を読む

Compressed context is usually carried as human-readable text or as rendered images that must be decoded, even when its consumer is a language model. We introduce LatentPress, which writes conversational histories and long documents into a third representation: continuous memory tokens that a frozen decoder reads directly through its input-embedding interface, with no text reconstruction at inference. A small reader-matched writer compresses $4$-$16\times$ while training only an adapter (4.2M-26.2M parameters, $\sim\!0.1\%$ of the decoder). On LongMemEval, LatentPress reaches $0.504$ accuracy at $7.70\times$ compression versus $0.490$ for uncompressed evidence, outperforming text summaries (0.184) and OCR-based compression (0.426 to 0.312). On LongBench-QA, in-domain writers match or exceed raw-context reading at $4$-$8\times$ compression, while $16\times$ trails raw. Writing takes 43ms per conversation, roughly an order of magnitude faster than text summarization or OCR reconstruction, and reading is $5$-$9\times$ faster than raw context or cached OCR. We validate the interface under two transfer settings, zero-shot from UltraChat to LongMemEval memory QA and from LongMemEval-derived QA to unseen LongBench document domains, establishing direct soft tokens as a practical machine-facing context interface beyond text and vision. The implementation of the experiments could be found at: https://github.com/HJSang/LatentPress .

圧縮した文脈は、誰にとって読みやすいべきか

この記事で扱う論文の原題は "LatentPress: Context Compression Beyond Text and Vision"（Zhengze Zhou, Hejian Sang、arXiv:2609.01507、2026年9月公開）です。

論文の主張をアブストラクトに沿ってまとめると、こうなります。圧縮された文脈は、たとえ使う相手が言語モデルであっても、たいてい人間が読めるテキストか、あるいは復号が必要なレンダリング画像として運ばれている。LatentPress はそこに第三の表現を持ち込み、会話履歴や長文書を連続的なメモリトークンとして書き込む。凍結したデコーダはそれを入力埋め込みの口から直接読み、推論時にテキストへ戻す工程を持たない。読み手に合わせた小さなライタがアダプタだけを学習して4〜16倍に圧縮し、その学習パラメータは420万〜2620万個、デコーダの約0.1%にとどまる。LongMemEval では7.70倍圧縮で正解率0.504に達し、非圧縮の証拠を読ませた場合の0.490を上回った。テキスト要約（0.184）やOCRによる圧縮（0.426〜0.312）よりも良い。書き込みは1会話あたり43ミリ秒で、要約やOCR復元より約1桁速く、読み込みも生の文脈やOCRキャッシュより5〜9倍速い。

つまり論文が問うているのは、圧縮率の記録ではなく、「保存された文脈と、それを消費するモデルの境界を、何が渡るべきか」という表現の問題です。

比喩: 引き継ぎ資料の後任が、人間でないなら

長期間動くアシスタントやエージェントは、読み返すには高くつくほどの履歴を溜めます。指示、対話、計画、ツール呼び出し、観測、環境からのフィードバック。しかし後の判断が必要とするのは、たいていそのごく一部です。

いまの標準的なやり方は、退職時の引き継ぎに似ています。膨大な業務記録を、後任のために日本語の要約メモに書き直す。あるいは紙に印刷して写真に撮り、後任がOCRで文字に起こしてから読む。どちらも「最後に人間が読める形式へ落とす」ことを前提にしています。

でも後任が言語モデルなら、その前提は要りません。モデルが最終的に受け取るのは文字ではなく埋め込みベクトルだからです。テキストは人間に便利で、システム間の相互運用にも便利ですが、モデルは自分の保存文脈が人間可読であることを必要としない（§1）。この観察が論文の出発点です。

問題の切り分け: Write と Read

論文は文脈の利用を2つに分けます（§1）。

Write: テキストを、コンパクトな状態へ写す
Read: その状態を、凍結したデコーダへ供給して質問に答えさせる

この抽象は会話履歴にも長文書にも当てはまります。一方で論文は、検索（retrieval）、内省、更新方針、矛盾解消といった完全なメモリシステムの構成要素を置き換えるつもりはないと明言しています。扱うのはあくまで境界を渡る表現の形だけです。ここを混ぜて読むと、後の実験設定（証拠セッションを与える設定）に納得がいかなくなります。

仕組み(1): 埋め込みの口から、直接入れる

文脈 $x=(x_1,\ldots,x_T)$ を、対話ターンや文書チャンクといったセグメントの列とします。凍結デコーダ $f_\theta$ は、この文脈のコンパクトな表現から質問 $q$ に答えます。

m=\textsc{Write}_\phi(x;\pi),\qquad y=f_\theta\big([m;\mathrm{emb}(q)]\big)

(1)

式(1)を日本語に言い換えると、「ライタ（学習パラメータ $\phi$ 、圧縮率の指定 $\pi$ ）が文脈 $x$ を短い連続ベクトル列 $m$ に潰し、デコーダはその $m$ の後ろに質問の埋め込みをつなげた一本の列を読んで、そのまま答えを書く」です。 $m$ はデコーダの埋め込み空間に住むので、途中でテキストに戻す段はありません（§2.1）。

ここが JPEG のような非可逆圧縮と決定的に違うところです。JPEG は最後に必ず画像へ復元しないと使えません。次の図で、圧縮を強めるほど復元がどう壊れるかを触ってみてください。LatentPress が捨てているのは、この「復元」の工程そのものです。

FIG 1非可逆圧縮では、圧縮を強めるほど復元画像が崩れる。LatentPress はこの「復元」自体を推論時に行わない

仕組み(2): どこに予算を使うか — 役割ベースの圧縮率

圧縮率の規則 $\pi=(k_1,\ldots,k_T)$ は、隣り合う何個のトークン位置を1個のソフトトークンにまとめるかを決めます。論文はこの規則を意図的に単純な手書きヒューリスティックに留めています。目的は直接読みインタフェースの検証であって、圧縮スケジュールの最適化ではないからです（§2.2）。

規則は2種類です。一様プーリングはすべてのセグメントで $k_i=k$ とする。もう一方の役割ベースは、会話が持つ既知の構造を使ってターンごとに $k_i$ を変え、 $k_{\text{user}}=1$ 、 $k_{\text{assistant}}\in\{8,16,32\}$ とします。つまりユーザ発話はライタを迂回して生のトークン埋め込みのまま残し、アシスタント発話だけを符号化して潰す。

会話全体の圧縮率は、あらかじめ決めた目標値ではなく、役割と長さの混ざり方から結果として現れます（§2.2, A.5）。

\rho=|\mathcal{C}|\Big/\sum_i \lceil n_i/k_{r_i}\rceil

(2)

式(2)は「元の履歴トークン数 $|\mathcal{C}|$ を、注入したベクトルの本数で割ったもの」です。 $n_i$ はターン $i$ の長さ、 $k_{r_i}$ はその役割に割り当てた圧縮率。ユーザターンは $k=1$ なので1トークンにつき1ベクトルを消費し、 $\rho$ はアシスタント側の設定とユーザ/アシスタントのトークン比で決まります。論文が報告する4.62〜7.70倍は、評価セット上の平均値です。

仕組み(3): 何を残すかを教える損失

学習させるのはライタの頭だけです。アーキテクチャは、凍結デコーダの下位2層（ $L=2$ ）をディープコピーしてエンコーダとして借り、その上に $d\times d$ の線形アダプタを1枚載せる。アダプタは単位行列で初期化されるので、学習開始時点でライタは生のトークン埋め込みとほぼ同じ出力から始まり、必要な分だけそこから離れていきます（付録A.1）。学習パラメータは Qwen2.5-7B で1284.9万、Qwen3-8B で1678.1万、Qwen3-1.7B で419.6万、Qwen2.5-14B で2622.0万。借りた2層もデコーダ本体も凍結です。

汎用表現の学習には、次の目的関数を使います（§2.3）。

\mathcal{L}(\phi)=\mathcal{L}_{\mathrm{rec}}+\lambda\,\mathcal{L}_{\mathrm{fkl}}

(3)