AWS、小型モデルでRAGの根拠を先に圧縮：入力tokenを10分の1に削減する一方、リクエスト遅延は12〜19%増加

AWSは、Amazon BedrockのRAGパイプラインに挿入できるquery-aware compressionパターンを公開した。その中核は検索結果の件数を減らすことではなく、高再現率の検索後に小型モデルを追加する点にある。Lambdaはまず、質問とすべてのtop-k chunksをClaude Haikuに送り、関連する文や一節を原文どおりに抽出し、chunk IDを保持し、要約や言い換えを行わないよう指示する。その後、短縮された根拠をClaude Sonnetに渡して回答を生成する。どちらの呼び出しもBedrock Converse APIを使用するため、Nova Micro／Nova Proなど同一シリーズの組み合わせに置き換えられるほか、rerank、prompt caching、Intelligent Prompt Routingと組み合わせることもできる。

このカスケード構成が成立するのは、小型モデルが検索内容全体を読み込むコストが、メインモデルのtoken削減による節約額を下回る場合に限られる。元の検索量を`R`、圧縮倍率を`c`とすると、メインモデルの入力は`R`から`R/c`に減る一方、システムには小型モデルへの`R`個の入力tokenと、約`R/c`個の出力tokenが追加される。AWSは、9カテゴリー、50万件超の企業文書と500件の質問を用いてテストした。圧縮のみの場合、メインモデルに送るtokenはベースラインの12%に、コストは67%に低下した一方、エンドツーエンドの遅延は19%増加した。先にrerankを行ってから圧縮した場合は、それぞれ10%、64%、12%増だった。4つの品質指標による総合スコアは約97.5%を維持した。少なくとも1つ、ソースの裏付けがない主張を含む回答の割合は51%から44%に低下し、rerankを追加した場合は38%となった。

実装上の本当のリスクはAPIの接続ではなく、根拠の欠落である。`temperature=0`でも、モデルが必要な情報を漏れなく抽出する保証はない。特にmulti-hop questions、否定条件、表、chunkをまたぐ参照については、個別の検証が必要になる。チームは同じ検索結果を固定してA/Bテストを実施し、完全性、引用精度、faithfulness、コスト、P95 latencyを同時に測定すべきだ。範囲の狭い質問や約5,000 tokenを超えるコンテキストでは最も効果が見込まれる一方、短いコンテキストやサブ秒の応答が求められる対話型サービスでは、追加のモデル呼び出しによってかえって遅くなる可能性がある。