ECoRAG: Evidentiality-guided Compression for Long Context RAG

生成日: 2026-05-24 02:20

# ECoRAG: Evidentiality-guided Compression for Long Context RAG
- 長い検索拡張生成（Retrieval-Augmented Generation; RAG）で得られる文書を、答えを支える証拠性にもとづいて圧縮する手法である。
- 文ごとに強い証拠、弱い証拠、妨害文を区別し、必要な文だけを読解モデルへ渡す。
- Natural Questions、TriviaQA、WebQuestions で、既存の圧縮法より高い Exact Match を示し、入力トークン数と処理時間も抑えた。

## 論文の面白いところ

この論文は、RAG の文脈圧縮を単なる短縮として扱わない。中心に置かれるのは「その文が正答生成を実際に支えるか」という証拠性である。検索結果には、語が似ているだけの文書や、答え候補を含むが文脈としては誤った文書が混じる。長い文脈をそのまま大規模言語モデル（Large Language Model; LLM）へ渡すと、こうした文が回答を乱すことがある。ECoRAG は、その乱れを圧縮の段階で除く。さらに、最初から固定の圧縮率を決めず、圧縮後の文集合が答えに十分かを判定してから追加の証拠を足す。この設計により、短くしすぎて答えを失う場合と、長く残しすぎて雑音を入れる場合の双方を避けようとする。抽象的な要約を生成するのではなく、文を順位づけて取り出す点も実装上扱いやすい。

## 問題設定

対象はオープンドメイン質問応答（Open-Domain Question Answering; ODQA）における長文脈 RAG である。RAG では、質問に対して検索器が多数の文書を集め、LLM がそれらを読んで答えを生成する。文書数を増やせば、正答を含む証拠に当たる可能性は上がる。一方で、関係の薄い文書や紛らわしい記述も増えるため、生成品質が落ちることがある。既存の文脈圧縮法は、質問との関連性や一般的な重要度を見て短くすることが多い。しかし、答えを導くために必要な証拠と、単に似ているだけの情報は同じではない。また、質問ごとに必要な証拠量は異なるため、固定した圧縮率では不足や過剰が生じる。論文はこの二つ、すなわち雑音の除去と圧縮量の調整を同時に扱う。

## 提案手法

ECoRAG は、証拠性にもとづく圧縮器と、圧縮結果を判定する評価器から成る。まず検索された文書を文に分割し、各文について、正答生成に不可欠な強い証拠、補助的ではあるが妨げにならない弱い証拠、回答を妨げる妨害文をラベル付けする。強い証拠は、その文がなければ LLM が正答できず、その文があれば正答できる文として定義される。弱い証拠は、それ単独では決定的でないが、強い証拠の働きを妨げない文である。妨害文は、誤答を誘うなど、証拠の利用を阻む文である。このラベルを用いて、質問と文の類似度を学習する二重エンコーダ型の圧縮器を訓練する。圧縮器は文を証拠性の高い順に並べる。次に Flan-T5-large による評価器が、上位文から作った文集合が十分な証拠かを <EVI> または <NOT> で判定する。不十分なら次の文を加え、この操作を十分と判定されるまで繰り返す。

## 結果

主実験では、DPR が検索した 100 文書を用い、読解モデルとして GPT-4o-mini を使った。Natural Questions では、ECoRAG は 632 トークンで Exact Match 36.48、F1 49.81 を得た。これは標準 RAG の Exact Match 36.09 をわずかに上回り、入力は約 13,905 トークンから大きく減っている。TriviaQA では 441 トークンで Exact Match 65.34、F1 75.37 となり、比較した圧縮法の中で最も高い値を示した。WebQuestions でも 560 トークンで Exact Match 30.17、F1 46.13 であり、CompAct や RECOMP を上回った。HotpotQA の人手証拠文との整合では、NDCG@1 が 75.53、NDCG@10 が 81.92 で、答えを含むかだけを見る基準や Leave-One-Out より高かった。アブレーションでは、証拠性ラベルを外すと性能が落ち、評価器を使わない固定的な圧縮でも Exact Match が下がった。遅延の比較では、Natural Questions において標準 RAG が合計 12.28 時間であったのに対し、ECoRAG は圧縮と推論を合わせて 4.96 時間であった。

## 具体例

たとえば、質問が「映画 Den of Thieves の最後で死ぬ人物は誰か」であるとする。検索結果には、Merrimen が撃たれて倒れる場面と、Donnie が逃げ延びて後に別の強盗を企てる場面が一緒に含まれる。単純に長い文書をそのまま読ませると、モデルは何度も現れる Donnie という名前に引かれ、Donnie と答えることがある。ECoRAG は文書を文単位に分け、「Merrimen lies on the ground dying」のように答えを直接支える文を高く順位づける。一方、Donnie が逃げたことやバーで働くことを述べる文は、質問に対する証拠ではなく、むしろ誤答を誘う文として低く扱われる。最初に取り出した文だけで十分かを評価器が判定し、不十分であれば関連する追加文を足す。最終的に読解モデルへ渡される文脈は、Merrimen の死亡場面を中心に短くまとまる。期待される出力は Merrimen である。間違えやすい点は、物語上重要な人物と、質問が尋ねる「最後に死ぬ人物」を混同することであり、この論文の手法はその混同を文脈圧縮で減らそうとする。

ECoRAG: Evidentiality-guided Compression for Long Context RAG

長い検索拡張生成（Retrieval-Augmented Generation; RAG）で得られる文書を、答えを支える証拠性にもとづいて圧縮する手法である。
文ごとに強い証拠、弱い証拠、妨害文を区別し、必要な文だけを読解モデルへ渡す。
Natural Questions、TriviaQA、WebQuestions で、既存の圧縮法より高い Exact Match を示し、入力トークン数と処理時間も抑えた。

論文の面白いところ

この論文は、RAG の文脈圧縮を単なる短縮として扱わない。中心に置かれるのは「その文が正答生成を実際に支えるか」という証拠性である。検索結果には、語が似ているだけの文書や、答え候補を含むが文脈としては誤った文書が混じる。長い文脈をそのまま大規模言語モデル（Large Language Model; LLM）へ渡すと、こうした文が回答を乱すことがある。ECoRAG は、その乱れを圧縮の段階で除く。さらに、最初から固定の圧縮率を決めず、圧縮後の文集合が答えに十分かを判定してから追加の証拠を足す。この設計により、短くしすぎて答えを失う場合と、長く残しすぎて雑音を入れる場合の双方を避けようとする。抽象的な要約を生成するのではなく、文を順位づけて取り出す点も実装上扱いやすい。

問題設定

対象はオープンドメイン質問応答（Open-Domain Question Answering; ODQA）における長文脈 RAG である。RAG では、質問に対して検索器が多数の文書を集め、LLM がそれらを読んで答えを生成する。文書数を増やせば、正答を含む証拠に当たる可能性は上がる。一方で、関係の薄い文書や紛らわしい記述も増えるため、生成品質が落ちることがある。既存の文脈圧縮法は、質問との関連性や一般的な重要度を見て短くすることが多い。しかし、答えを導くために必要な証拠と、単に似ているだけの情報は同じではない。また、質問ごとに必要な証拠量は異なるため、固定した圧縮率では不足や過剰が生じる。論文はこの二つ、すなわち雑音の除去と圧縮量の調整を同時に扱う。

提案手法

ECoRAG は、証拠性にもとづく圧縮器と、圧縮結果を判定する評価器から成る。まず検索された文書を文に分割し、各文について、正答生成に不可欠な強い証拠、補助的ではあるが妨げにならない弱い証拠、回答を妨げる妨害文をラベル付けする。強い証拠は、その文がなければ LLM が正答できず、その文があれば正答できる文として定義される。弱い証拠は、それ単独では決定的でないが、強い証拠の働きを妨げない文である。妨害文は、誤答を誘うなど、証拠の利用を阻む文である。このラベルを用いて、質問と文の類似度を学習する二重エンコーダ型の圧縮器を訓練する。圧縮器は文を証拠性の高い順に並べる。次に Flan-T5-large による評価器が、上位文から作った文集合が十分な証拠かを <EVI> または <NOT> で判定する。不十分なら次の文を加え、この操作を十分と判定されるまで繰り返す。

結果

主実験では、DPR が検索した 100 文書を用い、読解モデルとして GPT-4o-mini を使った。Natural Questions では、ECoRAG は 632 トークンで Exact Match 36.48、F1 49.81 を得た。これは標準 RAG の Exact Match 36.09 をわずかに上回り、入力は約 13,905 トークンから大きく減っている。TriviaQA では 441 トークンで Exact Match 65.34、F1 75.37 となり、比較した圧縮法の中で最も高い値を示した。WebQuestions でも 560 トークンで Exact Match 30.17、F1 46.13 であり、CompAct や RECOMP を上回った。HotpotQA の人手証拠文との整合では、NDCG@1 が 75.53、NDCG@10 が 81.92 で、答えを含むかだけを見る基準や Leave-One-Out より高かった。アブレーションでは、証拠性ラベルを外すと性能が落ち、評価器を使わない固定的な圧縮でも Exact Match が下がった。遅延の比較では、Natural Questions において標準 RAG が合計 12.28 時間であったのに対し、ECoRAG は圧縮と推論を合わせて 4.96 時間であった。

具体例

たとえば、質問が「映画 Den of Thieves の最後で死ぬ人物は誰か」であるとする。検索結果には、Merrimen が撃たれて倒れる場面と、Donnie が逃げ延びて後に別の強盗を企てる場面が一緒に含まれる。単純に長い文書をそのまま読ませると、モデルは何度も現れる Donnie という名前に引かれ、Donnie と答えることがある。ECoRAG は文書を文単位に分け、「Merrimen lies on the ground dying」のように答えを直接支える文を高く順位づける。一方、Donnie が逃げたことやバーで働くことを述べる文は、質問に対する証拠ではなく、むしろ誤答を誘う文として低く扱われる。最初に取り出した文だけで十分かを評価器が判定し、不十分であれば関連する追加文を足す。最終的に読解モデルへ渡される文脈は、Merrimen の死亡場面を中心に短くまとまる。期待される出力は Merrimen である。間違えやすい点は、物語上重要な人物と、質問が尋ねる「最後に死ぬ人物」を混同することであり、この論文の手法はその混同を文脈圧縮で減らそうとする。