Kapa 社による RAG エージェントのための「トリマー」技術：文脈削減とコスト最適化

Kapa（カパ）は、膨大な製品知識ベースに対し複雑な質問に答える AI アシスタントを開発しています。技術ドキュメント、API リファレンス、PDF、フォーラムなどを対象とする本システムには、以下の検索 API 構造が採用されています。

• リリーバ（Retriever）：質問に関連する数十万の文書チャンクを抽出し、数百個候補に絞り込みます。
• ジェネレーター（Generator）：上位約 15 チャンクを読み込み、回答を作成します（通常最も高価なモデル）。

新しいアプローチ：第 3 の工程「トリマー」の導入

本稿では、従来の「リリーバ → ジェネレーター」というステップ間に新しい**トリマー（Pruner）**と呼ばれる第 3 の工程を追加しました。

トリマーの機能と成果

• 処理内容：低コストな小型 LLM が、高価な大規模モデルが処理する前に質問と全抽出チャンクを読み込みます。これにより**回答に不要なチャンクをフィルタリング（捨てる）**します。
• 主な成果：
  • 文脈データ量削減：約 68% 削減。
  • 再現率保持：約 96% を維持。
  • コスト削減：クエリ全体の請求額が約 3/10（33%） に低下しました。

---

なぜ既存の手法が失敗したのか？

問題：無視されたチャンクへの課金

• システムには「ノイズを無視する」役割がありますが、ジェネレーターが無視した各チャンクにつき請求が発生します。
• 現状では抽出されたチャンクのコストが全クエリコストの約 2/3 を占めており（回答・履歴・プロンプト合計より高価）、不要なチャンクを減らすだけでコスト削減が可能ですが、ここで課題は再現率です。

既存解決策 A：再ランク付けスコアベースフィルタリングの失敗

呼び出し元に再ランク付けスコアを開示し、固定しきい値でフィルタリングさせる案は以下の理由で機能しません。

• スコアの相対性：スコアは「A が B より優れている」程度の順序付けであり、固定しきい値での比較ができません。ランキングの唯一有効なしきい値は「位置（トップ N）」のみであり、必然的に最後のチャンク（ノイズであっても重要かも）を除外してしまいます。
• 文脈欠如の評価：多くの再ランク付け器は個別のクロスエンコーダーを使用するため、各チャンクを孤立して評価します。
  • 例：2 番目のチャンクには「Audit logs」という語句がないためノイズと判定されますが、実際には最初のチャンクとのセットになった回答の一部でした。
  • 結論：再ランク付け器は「単体の関連性」しか測れず、「集合として質問に答えるか」という真の問いを捉えられません。

既存解決策 B：アンカードキュメント法の失敗

人工的な「Essential」〜「Unrelated」のチャンクをランキングに植え付け、アンカーを下界としてフィルタリングする手法も機能しませんでした。

• 根本原因：スコア自体を修正できないため、再ランク付け器は依然として部分的な関連性を持つチャンクを「無関係」として低順位付けします。
• 結果：アンカーを下げてまで全チャンクを取り込むことになり、実質的に何もないトリム状態に戻ってしまいます。

---

Kapa のリリース戦略：リストウェア型 LLM による等級付け

我々は、質問とすべてのチャンクを同時に見比べるリストウェア（listwise）なアプローチを採用しました。

等級付けのプロセス

リリーバとジェネレーターの間に配置された低コスト LLM が、以下の 5 レベルの尺度 を用いて各チャンクに等級を割り当てます。

• レベル 5 (ESSENTIAL)：回答なしでは作成できない。直接の答え、定義、他チャンクの前提条件を含むもの。
• レベル 4 (CONTRIBUTING)：単独では不十分だが、他チャンクと組み合わせることで完全な回答に必要な要素を提供するもの。
• レベル 3 (SUPPORTING)：トピック関連の実用的情報だが、なくても回答は概ね完結するもの。
• レベル 2 (TANGENTIAL)：用語は共有するが、具体的な貢献がないもの。
• レベル 1 (UNRELATED)：意味のある関連性を持っていないもの。

しきい値以上のチャンクのみをジェネレーターに渡します。これにより、相対的なスコアではなく明確な言語定義に基づくフィルタリングが可能になり、部分的・間接的な関連性も正確に評価できます。

重要な実装パラメータ

• モデル選択：コスト削減効果を最大化するため、高価なトップモデルは除外。低推論負荷で動作し、最も高速・安価な軽量モデルを使用。
• しきい値調整：圧縮率と再現率のバランスを取るダイヤル。
• keep-top-k：評価ミスから最重要チャンクを守るため、上位少数チャンクは必ず通過させる保護機能。

デザイン上の誠実さ（Simple & Effective）

より複雑な手法への依存を避けつつ、以下の設計も導入しました。

• Budget-select：予算内で LLM が追加のチャンクを選ばせるが、予算上限に達すると強制終了する仕組み。
• Most Simple Pruner：LLM に「どのチャンクを残すべきか」と直接問い、等級付けを使わないシンプル設計。もしこれがスコアリング手法を上回れば、単純な質問の方が優れているという原則に従うため実装。

---

検証結果とコスト・レイテンシ分析

主要指標

• 横軸（圧縮率）：トリマーが廃棄する抽出チャンクの割合。
• 縦軸（再現率保持）：トリム後も回答に必要な全チャンクを維持できた割合。
• 最適解の位置：各戦略で得られた最もバランスの取れた点を実線で結びました。

達成された数値

• 最適な構成：96% の再現率を保持しつつ、約 68% のチャンクを廃棄する設定を選択。
  • 約 25 件の質問に対し、1 件のみ必要なチャンクを見失う（許容範囲内）。
  • 文脈データの 2/3 が削減され、トリマーのコストを含めても 1 クエリあたりの請求額は約 34% 低下。

レイテンシへの影響

• トリマーは検索と生成の間に位置するため、全てのクエリに追加で呼び出しが発生します。
• 最適な構成では 1 クエリあたり約 0.7 秒 の遅延を追加しました。
• 重い設定（高コストモデル）は遅延が急激に増加するため、軽量モデルの選定が重要でした。
• 結論：生成プロセス自体の加速効果（入力トークン減少による早期応答）は小数秒程度のみであり、トリマー自身の呼び出し分を相殺するには不足しています。極めて低い固定レイテンシ（1 秒未満） の犠牲を得たことになります。
  • 注記：シングルショットパスではコスト要因ですが、エージェント環境ではターンごとに複数のモデル呼び出しが既に発生しているため、追加の軽量呼び出しはマージナル（限界）のコストとなります。

---

適用開始場所と展開状況

我々はまず、検索機能が多様なツールの一つとして活用されるエージェント構築現場で展開しました。

• ターゲット顧客：多数のツールを備え、各出力が共通の文脈プールに流入するエージェントシステム。
• 利点：
  • 検索結果が 1/2 以下でも、残りの要素に対して十分な余地を提供できる。
  • 再現率の低下リスクは低く、不足を感じたエージェントは再度検索（リトライ）可能です。

製品化状況

• Product Agent SDK：知識ベース検索機能でデフォルト有効。
• 検索 API / MCP サーバー：オプションとして提供可能。