AWSはBedrockサービスにクエリ認識型圧縮（query-aware compression）を追加しました。これにより、開発者は言語モデルに到達する前に、無関係なドキュメントのチャンクを削ぎ落とすことができます。モデルに送信されるトークン数を削減することで、この機能は検索拡張生成（RAG）パイプラインの計算コストを抑えることができます。

なぜRAGパイプラインはコストがかさむのか

RAGシステムは、まずナレッジベースからテキストの断片を抽出し、次にそれらの断片を生成モデルに渡してユーザーの質問に回答します。ほとんどの実装では、テキストの大部分がクエリと無関係である場合でも、取得したすべてのチャンクをそのままモデルに送ってしまいます。余分な単語はすべてトークンとなり、モデルが処理するトークンが増えるたびに、基盤となるAPIの料金が加算されます。サポートボットや社内検索ツールを運用している中小企業にとって、トークン消費量はモデル呼び出し自体のコストをすぐに上回ってしまうことがあります。

クエリ認識型圧縮の仕組み

新しいBedrockの機能は、検索と生成の間にフィルタリングのステップを挿入します。

  • システムは、クエリに対してこれまでと同じドキュメントセットを抽出します。
  • モデルがテキストを見る前に、軽量なプロセッサが各断片を特定の質問に照らして評価します。
  • 関連性があると判断された部分のみが保持され、それ以外はノイズとして破棄されます。

新しいインデックスや埋め込みモデル、あるいはファインチューニング済みの言語モデルを用意する必要はありません。変更点は、圧縮レイヤーを呼び出すようにパイプラインを再構成するだけです。

ビジネスへの影響

モデルに送信されるテキスト量に応じてトークン料金が上昇するため、無関係なスニペットを削除することで、請求額を項目ごとに削減できます。利用規模の拡大に伴いRAGコストの膨張に直面してきた企業にとって、最大のメリットとなります。

今後の注目点

  • 自社データで機能を試行する: 標準的なRAGフローと、クエリ認識型圧縮を含むフローを並行してテストしてください。トークン数、レイテンシ、回答の関連性を測定します。
  • ベンダーの透明性: サードパーティのRAGプラットフォームを評価する際は、検索パイプラインに圧縮やフィルタリングを採用しているか確認してください。生のチャンクをそのまま送るベンダーは、月々の請求額が高くなる可能性があります。

結論

モデルに届く前に無関係なテキストをフィルタリングするという、わずかなパイプラインの調整だけで、隠れた費用を管理可能な項目に変えることができます。すでにBedrockベースのRAGを利用している組織にとって、クエリ認識型圧縮の有効化は手間のかからない実験ですが、実際にどれほどの節約になるかは、使用するデータに依存します。