本文へスキップ
AI-Papers

LatentPressとは?文脈を7.7倍圧縮し無圧縮超えの精度を出す新手法

LatentPressとは?文脈を7.7倍圧縮し無圧縮超えの精度を出す新手法
  • 長い対話履歴や文書を、テキスト要約でも画像でもない「連続メモリトークン」に書き込み、凍結したLLMが直接読み取る文脈圧縮手法 LatentPress の提案
  • LongMemEval で 7.70 倍圧縮時に精度 0.504 を記録し、無圧縮の 0.490、テキスト要約の 0.184、OCR 方式の 0.426 を上回った
  • 学習するのはアダプタの 4.2M〜26.2M パラメータ(デコーダの約 0.1%)のみで、書き込みは 1 会話 43ms、読み込みは 5〜9 倍高速

研究の背景

大規模言語モデル(Large Language Model、LLM)に長い会話履歴や文書を渡すとき、そのまま全文を入力すると計算コストとレイテンシが跳ね上がります。そこで一般的に使われるのが文脈圧縮で、履歴を短いテキスト要約に置き換えたり、最近では文書を画像としてレンダリングして視覚トークンとして読ませる手法(いわゆる OCR 圧縮)が試されてきました。

ただし、どちらのアプローチにも共通する前提があります。圧縮された情報が人間にも読める形式で保持されるという点です。テキスト要約は自然言語のまま、画像トークンは描画されたページのままで、いずれもモデル側が改めて意味を解釈し直す必要があります。

本論文の著者である Zhengze Zhou 氏と Hejian Sang 氏は、この前提そのものを問い直しました。圧縮された文脈の消費者が言語モデルである以上、人間が読める形式にこだわる理由はないという発想です。長文脈の効率化という点では Random Attentionとは?KVキャッシュをランダムに捨て推論を32-43%高速化 のように推論時のキャッシュを削る方向の研究もありますが、LatentPress は入力表現そのものを作り替えるアプローチをとります。

提案手法

LatentPress は、長い文脈を「連続メモリトークン」と呼ばれる第 3 の表現に書き込みます。これは離散的な単語トークンではなく、埋め込み空間上の連続値ベクトル(ソフトトークン)の短い列です。凍結された LLM は、この列を入力埋め込みのインターフェースを通じてそのまま受け取り、テキストへ復元する工程を一切挟まずに回答を生成します。

図1: LatentPress の全体像。長い会話履歴を 1 回の前向き計算でソフトトークン列に圧縮し、凍結された LLM が質問と連結して直接読み取る
図1: LatentPress の全体像。長い会話履歴を 1 回の前向き計算でソフトトークン列に圧縮し、凍結された LLM が質問と連結して直接読み取る(論文 Figure 1)

図1に示すように、処理の流れは 3 段階です。まず情報価値の異なるセグメントが混在する長い履歴を入力とし、次に 1 回の前向き計算(ほぼリアルタイム)でソフトトークン列へ圧縮します。最後に、凍結された LLM がソフトトークンと質問を連結した 1 本の系列を読み、そのまま回答をデコードします。

書き込み側は「reader-matched writer」と呼ばれる設計で、読み手となるデコーダと同じモデルを基盤にしつつ、学習するのは追加したアダプタだけです。パラメータ数は 4.2M〜26.2M で、デコーダ全体の約 0.1% にとどまります。デコーダ本体は凍結したままなので、大規模な再学習が不要で GPU 要件も低く抑えられます。圧縮率は 4 倍から 16 倍の範囲で設定できます。

実験結果

長期記憶を問う会話ベンチマーク LongMemEval での結果が中心的な成果です。7.70 倍に圧縮した状態で精度 0.504 を達成し、圧縮せずに証拠テキストをそのまま与えた場合の 0.490 を上回りました。圧縮したほうが精度が上がるという結果は、無関係な情報が削られることでモデルが要点に集中しやすくなった可能性を示しています。

手法

LongMemEval 精度

LatentPress(7.70 倍圧縮)

0.504

無圧縮のテキスト

0.490

OCR 方式(圧縮率による)

0.426〜0.312

テキスト要約

0.184

テキスト要約が 0.184 と大きく落ち込んでいるのは、要約の段階で質問に必要な細部が失われるためだと考えられます。画像としてレンダリングする OCR 方式は要約よりは健闘するものの、圧縮率を上げるほど 0.426 から 0.312 へ低下しました。

速度面では、1 会話あたりの書き込みが 43ms で完了します。読み込み時は生の文脈やキャッシュ済みの OCR 表現と比べて 5〜9 倍高速でした。文脈が短くなる分、Attention の計算量が減ることによる効果です。

汎化性能については、UltraChat で学習した writer を LongMemEval に適用する設定と、LongMemEval 由来の質問応答データで学習した writer を未知の LongBench ドメインに適用する設定という 2 つのゼロショット転移で検証されています。文書系ベンチマークの LongBench-QA では、ドメイン内で学習した writer が 4〜8 倍圧縮で生の文脈と同等以上の性能を示しました。

まとめと今後の展望

LatentPress は、圧縮した文脈を人間が読める形に保つ必要はないという割り切りによって、精度と速度を同時に改善しました。デコーダを凍結してアダプタのみを学習する構成のため導入コストが低く、コードも GitHub で公開されています。

一方で課題も残ります。LongBench-QA において 16 倍圧縮まで上げると、生の文脈を読ませた場合に性能が届きませんでした。圧縮率をどこまで押し上げられるかには限界があり、扱うタスクや文書の性質に応じた調整が必要になります。また、ソフトトークンは人間が中身を確認できないため、どの情報が保持され何が捨てられたのかを検証しづらいという運用上の制約もあります。監査や説明責任が求められる用途では、この不透明さをどう扱うかが論点になるでしょう。

論文情報: "LatentPress: Context Compression Beyond Text and Vision"(Zhengze Zhou, Hejian Sang, 2026) arXiv:2609.01507, CC BY 4.0

本記事の図(図1)とサムネイルは上記論文より引用しています(縮小・形式変換あり)。

シェア:

投稿には GitHub アカウントが必要です。投稿内容は公開され、利用規約に反するものは予告なく削除します。