今回の論文
今回取り上げるのは、Huiqiang Jiangらによる「LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models」です。2023年12月のEMNLP 2023で発表された、LLMの入力プロンプト圧縮を扱う論文です。公開元はAssociation for Computational Linguistics、URLは https://aclanthology.org/2023.emnlp-main.825/ 、研究分野はLLM推論最適化とプロンプト圧縮です。
選んだ理由は、長いコンテキストを「全部入れるか、捨てるか」の二択にせず、小型モデルを前段に置いて重要度に応じて削る具体的な設計を示しているためです。RAG、長い会話履歴、ツール出力など、入力トークンが費用と遅延を支配しやすいアプリへ応用しやすい考え方です。
どんな技術か
LLMLinguaは、大きな生成LLMに渡す前に、より小さい言語モデルでプロンプトを圧縮する技術です。各トークンを「この文脈を復元・理解するためにどれだけ必要か」という観点で採点し、限られたトークン予算に収まるよう、重要な箇所を残します。
単なる要約とは異なります。文章を新しく言い換えるのではなく、元の入力から不要度が高いトークンを選んで落とす、extractiveな前処理です。まず命令文・質問・デモ例・文書といった構造を粗く配分し、次にトークン単位で細かく削ります。圧縮後の断片的な入力にもターゲットLLMが適応できるよう、圧縮器側を命令形式へ整合させる点が特徴です。
課題
CoT、few-shot例、RAGの検索結果、会話履歴を組み合わせると、LLMへ送る入力はすぐ数千〜数万トークンになります。入力長はAPI費用、prefillの待ち時間、GPUメモリ消費を増やします。コンテキスト長の上限に近づけば、そもそも実行できないこともあります。
既存の短縮方法には限界があります。文単位で抜き出す方法は、固有名詞・数値・否定・コードのように、文の一部だけが答えに必要な情報を落としやすいです。逆に、トークンを独立に削るだけでは、前後関係が変わって意味が壊れます。また小型モデルが自然だと判断した圧縮文が、大型の指示追従LLMにとって読みやすいとは限りません。
この問題は、社内文書を多数投入するRAG、長いチケットとログを読むAI開発支援、ツール結果が増え続けるエージェントで実際に起きます。回答モデルを大きくする前に、入力の情報密度を上げられるかが重要になります。
用語解説
- プロンプト圧縮
- 生成前の入力を短くしつつ、下流タスクに必要な情報を残す処理です。本論文では要約で書き換えるのではなく、重要度に基づき元のトークンを選択します。
- Perplexity（PPL）
- 言語モデルが次のトークンをどれほど予測しにくいかを表す尺度です。LLMLinguaは小型モデルのPPLを、文脈から外すと不自然になるトークン、すなわち残す候補を見積もる信号として使います。
- トークン予算
- 圧縮後に許す入力トークン数です。予算を先に決めることで、単に各部分を同じ割合で削るのではなく、命令や質問へ必要な容量を確保できます。
- In-context learning（ICL）
- モデルを追加学習せず、プロンプト内の例から出力形式や解法を学ばせる方法です。例が長くなりやすいため、LLMLinguaが圧縮対象として重視する構成要素です。
- 分布整合（distribution alignment）
- 圧縮で生じる不自然な断片と、ターゲットLLMが学習時に見た自然な命令文とのずれを小さくする考え方です。本論文では圧縮器となる小型モデルを命令データで調整し、重要度推定をターゲットの利用形態へ寄せます。
技術の仕組み
LLMLinguaの基本設計は、「高価な生成モデルに全文を読ませず、軽量な補助LMに選別させる」二段階処理です。対象LLMがAPIのみのブラックボックスでも、入力文字列を置き換えるだけで利用できます。
1. プロンプトを構造に分け、予算を割り当てる
最初にプロンプトを、命令、質問、few-shotのデモ例、文書コンテキストなどの部分へ分けます。Budget Controllerは、例えば質問と命令を保護し、デモ例や文書には残りの予算を配るように、構成要素ごとの圧縮率を決めます。
この粗い段階が必要なのは、全トークンを一律に比較すると、長い文書が予算を使い切ったり、タスクを指定する短い命令が欠けたりするためです。デモ例は重要度が低い順に丸ごと落とすこともあり、強い圧縮率でも最低限の意味構造を保とうとします。
2. 小型LMでトークンを反復的に選ぶ
次に、GPT-2 smallやLLaMA-7Bのような圧縮器が、残った各部分のトークンをPPLベースで評価します。あるトークンを外したときに後続トークンの予測がどれだけ変わるかを見て、文脈をつなぐ上で効くトークンを優先します。
重要なのは、一度の独立判定ではなく、選んだトークンで文脈を更新しながら反復する点です。すでに削った語に依存して次の語の重要度が変わるため、圧縮済みのprefixを条件に再評価します。これにより、局所的には不要に見える語を連続して消し、文全体を壊す失敗を減らします。
3. 命令追従モデルとのずれを抑える
PPLを測る小型LMは、自然文の尤度をよく推定できても、圧縮された断片をGPT-3.5やGPT-4などの命令追従LLMがどう利用するかを完全には表せません。そこで論文は、命令チューニングデータで圧縮器を調整するInstruction Tuning Based Distribution Alignmentを導入します。
実装上は、圧縮後の文字列をそのまま本番LLMへ渡す前段サービスとして置けます。ただしJSON、コード、URL、テーブル、システム命令のように一文字でも欠けると壊れる部分は、圧縮対象から除外するルールを別途設けるべきです。論文の対象は主に自然言語であり、構造化データの完全性までは保証しません。
実験と結果
論文は、算数推論のGSM8K、複雑な推論タスク集BBH、対話要約に近いShareGPT、論文要約のArxiv-March23という4種類のシナリオで検証しました。ターゲットにはGPT-3.5-TurboやGPT-4などを用い、圧縮率、下流タスク性能、入力コストと遅延を比較しています。
高圧縮でも性能を維持できるか
主要な結論は、最大20倍の圧縮でも性能低下を小さく抑えられる条件がある、というものです。特に長い会話文脈を扱うShareGPTでは、同じトークン制約でSentence SelectionやSelective-Contextと比較して、LLMLinguaが高いROUGE指標を示しました。
例えば論文のShareGPT評価では、175トークン制約でLLMLinguaは元入力に対して約9倍圧縮しつつ、ROUGE-L 34.94、BERTScore 89.03を報告しています。比較したSelective-Contextは約8倍圧縮でROUGE-L 26.72、BERTScore 87.09でした。これは、文単位の削減よりトークン間依存を考慮した圧縮が、厳しい予算で効くことを示す結果です。
速度・費用の読み方
入力が短くなれば、ターゲットLLMの入力課金とprefill計算は減ります。一方、圧縮器を実行する時間と計算費用が新たに発生します。論文は長い入力での最大20倍圧縮を示しますが、短い問い合わせまで必ず高速・低コストになることを意味しません。
評価結果から言えるのは、圧縮率だけで採否を決めず、圧縮前処理を含むエンドツーエンド遅延、質問応答の正確性、検索根拠の欠落率を同時に測る必要があることです。入力が長く、同じ形式の問い合わせを繰り返すほど、前処理コストを回収しやすくなります。
何に使える？
LLMLinguaは、生成モデル自体を再学習せず、入力手前を差し替えるため、既存アプリへ段階的に導入できます。
RAGの検索後コンテキスト
検索上位の文書をそのまま連結する代わりに、質問・引用元ID・数値・固有名詞を保護して圧縮します。検索のrecallを落とさずにtop-kを増やしたい場面で、文書全体を捨てる前の中間層になります。根拠表示が必要なら、圧縮後トークンと原文オフセットの対応を保存しておくことが大切です。
エージェントのツール結果と会話履歴
ログ、Web検索結果、過去ターン、観測値が積み上がるエージェントでは、現在の依頼に不要な説明が多くなります。自然言語のレポート部分を圧縮し、直近の状態、エラーコード、ファイルパスなどを保護すれば、コンテキスト枯渇を遅らせられます。ツール引数やJSONそのものは圧縮せず、別の構造化フィルタで扱うのが安全です。
長い問い合わせを扱う業務支援
契約相談、障害報告、研究メモのように、ユーザーが長い文章を貼るアプリで使えます。入力を機械的に先頭・末尾だけ切り詰めるより、要件、制約、数値、質問文へ予算を残す圧縮器の方が、回答に必要な情報を維持しやすくなります。
開発や事業へのヒント
この論文の実務的な価値は、LLMコストを「モデル選定だけの問題」にしないことです。入力構造の設計と選別層に、測定可能な改善余地があります。
圧縮前に情報の型を分ける
小規模なRAGでも、システム命令、質問、引用、メタデータ、JSONを同じ圧縮器に入れない方がよいです。LLMLinguaの予算配分の発想を使い、破壊不可の部分は保護、冗長な自然言語だけを圧縮対象にすることで、導入リスクを下げられます。
段階的なフォールバックを設計する
まず文書単位の再順位付け、次に安全な自然言語圧縮、最後に元プロンプトへ戻すフォールバックを用意します。圧縮後に引用IDが消えた、抽出すべき数値がない、といった検査を置けば、品質劣化を検知しやすくなります。これは論文のブラックボックス前処理という性質を、運用可能なガードレールへ拡張する考え方です。
観測すべきKPIを増やす
「平均トークン削減率」だけでは不十分です。圧縮前処理の時間、ターゲットモデルの入力トークン、最終遅延、タスク成功率、根拠に必要な語句の保持率をリクエスト種別ごとに記録してください。圧縮が有益な長文RAGと、オーバーヘッドが勝つ短いチャットを分けて運用できます。
限界
LLMLinguaは、削除された情報を後から完全に復元できません。質問との関係が遠い情報、稀な固有表記、例外条件が削られると、もっともらしいが根拠不足の回答につながります。特に法務・医療・障害対応のように原文の完全性が必要な用途では、圧縮版だけを最終根拠にしてはいけません。
また、圧縮器のPPLは下流タスクの正解率そのものではありません。小型モデル、対象言語、ドメイン、ターゲットLLMを変えれば重要度推定の質も変わります。日本語、専門用語、コード混在のプロンプトでは、自社データで削除率と正答率を検証する必要があります。
実装面では、反復的なトークン選択には計算時間がかかります。短い入力、十分に安い入力価格、出力生成が主な遅延要因であるタスクでは、圧縮しても得にならない場合があります。圧縮率を高くしすぎず、原文との比較評価とフォールバックを持つことが重要です。
よくある質問
Q. LLMLinguaは要約モデルと何が違いますか？
A. 要約は新しい文章へ言い換える生成処理ですが、LLMLinguaは元のトークンを選んで削る処理です。原文の表現を残しやすく、ブラックボックスLLMの前段に置きやすい一方、削った情報を補って説明する用途には向きません。
Q. RAGでは検索件数を減らせば、プロンプト圧縮は不要ですか？
A. 検索件数の削減は有効ですが、関連文書の中にも冗長な説明が含まれます。LLMLinguaは検索後の文書内部を詰める層として使えます。ただし、検索失敗は圧縮で直せないため、retrievalの評価とは分けて測定してください。
Q. JSONやソースコードも圧縮できますか？
A. そのままの適用は勧めません。JSONの括弧やコードの記号が欠けるとパース・実行に失敗するためです。構造化部分は完全保護し、長いコメント、ログ本文、ドキュメントなど自然言語部分だけを対象にするのが安全です。
Q. どの程度の長さから導入を検討すべきですか？
A. 固定の閾値はありません。圧縮器の実行時間と料金を含め、長文と短文を分けて計測してください。入力トークンが多く、同種のリクエストが継続し、prefillや入力課金が支配的なら候補になります。
Q. 圧縮率を高くすればするほど得ですか？
A. いいえ。圧縮率を上げるほど、答えに必要な条件や根拠を失う危険が増えます。論文の最大20倍は特定の評価条件での結果です。実務ではタスク成功率、引用保持、エスカレーション率を見ながら、用途ごとに予算を決めるべきです。
今日の学び
この論文は、長いプロンプトがLLMの費用、待ち時間、コンテキスト制約を大きくする課題を扱いました。LLMLinguaは、小型LMによる粗い予算配分と反復的なトークン選別で、必要な情報を残しながら入力を圧縮します。
得られるヒントは、長文対応をコンテキスト長の拡大だけで考えず、入力を「保護すべき構造」と「圧縮できる自然言語」に分けることです。RAGやエージェントでは、圧縮率だけでなく、原文根拠の保持とエンドツーエンドの品質・遅延を一緒に計測する設計が役立ちます。