[AWS]Bedrockのトークン削減の考え方

Knowledge Baseに登録するDB定義を減らし、SQL生成時のトークン数を削減すると事はシステムのパフォーマンスとコストに直結する非常に重要です。

今回はプロジェクtの知見から具体的かつ実践的な方法を複数提案します。重要なのは、単に情報を削るのではなく、「LLMがSQLを生成するために本当に必要な情報だけを、最も効率的な形で提供する」という視点です。

トークン削減のための戦略
推奨アクションプラン

トークン削減のための戦略

トークン削減は、大きく分けて

格納する情報を賢くする（意味的・論理的削減）
格納方法を効率化する（物理的削減）
検索プロセスを最適化する（段階的検索）

の3つのアプローチがあります。

① 格納する情報を賢くする（意味的・論理的削減）

これは最も効果的な方法でLLMの思考に最適化させます。

1. 不要なカラム定義を大胆に削除する
- 指摘: LLMがSQLを生成する上で、ユーザーが自然言語で質問しないカラムは不要です。
- 対策: 以下のカラム情報はKnowledge Baseから削除しましょう。
  - システム管理用のカラム: created_at, created_by, updated_at, updated_by, deleted_atなど、いわゆる「監査カラム」。
  - 内部的なフラグやID: ユーザーが直接の言葉で指定しない内部フラグ。
  - 主キー・外部キー: 主キーは、descriptionで「〇〇を識別するID」と説明すれば十分であり、PRIMARY KEYといった制約情報は不要です。
2. 質の高い「説明（Description）」と「別名（Aliases）」に注力する
- 指摘: LLMはカラム名そのものよりも、description（説明）やaliases（別名）から「どのカラムを使うべきか」を判断します。
- 対策:
  - ビジネス用語で説明: location_nameのカラム説明を「物件の場所名」とするだけでなく、「購入者が契約する物件の場所の正式名称」のように、業務上の意味を具体的に記述します。
  - よく使われる言葉を別名に: location_nmのaliasesに["物件", "物件名"]のように、ユーザーが使いそうな言葉を複数登録します。これにより、RAGの検索精度が向上し、余計なスキーマ情報をプロンプトに含める必要がなくなります。
3. データ型をシンプルにする
- 指摘: VARCHAR(15)やNUMERIC(8,0)といった詳細なデータ型は、SQL生成の精度にほとんど影響しません。
- 対策: VARCHAR, INT, DATE, TIMESTAMP のように、基本的な型に単純化しましょう。data_typeフィールドの情報を簡潔にすることで、トークン数を削減できます。
4. 具体的な「サンプル値」を提供する
- 指摘: カラムの役割を説明する最良の方法の一つは、具体的なデータの例を示すことです。
- 対策: descriptionの中に、「例: ’01’ (空き物件), ’02’ (契約済み物件)」のようにサンプル値を含めるか、sample_values: ["空き物件", "契約済み物件"]のような専用のキーを追加します。これにより、LLMはカラムの意味をより正確に理解できます。

② 格納方法を効率化する（物理的削減）

これは、Knowledge Baseに渡すテキストの形式を工夫する方法です。

1. DDL文ではなく、構造化データ（JSON）に統一する
- 指摘: CREATE TABLEのようなDDL文は、NOT NULLやDEFAULTなど、トークンを消費する多くの付帯情報を含みます。
- 対策: JSON形式に統一するのは非常に良いアプローチです。このJSONから、さらに不要なキー（length, not_null, other, default_valueなど）を削除し、「テーブル名、カラム名、説明、別名、データ型」といった最小限の構成にしましょう。
2. 1テーブル＝1ドキュメント（1チャンク）として分割する
- 指摘: Knowledge Baseは、アップロードされたドキュメントを「チャンク」という単位に分割してベクトル化します。もし複数のテーブル定義が1つのチャンクに混在すると、RAG検索の精度が低下し、不要なテーブル情報までプロンプトに含まれてしまいます。
- 対策: スキーマ情報をKnowledge Baseに登録する際、テーブルごとにファイルを分割するか、明確な区切り文字を入れて、1テーブルの定義が必ず1チャンクになるように設定してください。

③ 検索プロセスを最適化する（段階的検索：上級者向け）

これは、アプリケーション側のロジックを少し変更する、より高度ですが効果的な方法です。

2段階RAG（テーブル選択 → SQL生成）を導入する

指摘: 通常のアーキテクチャでは、一度のRAG検索で関連するテーブル・カラム情報をすべて取得し、SQLを生成しています。
対策: 処理を2段階に分割します。
1. フェーズ1（テーブル選択）: ユーザーの質問を、「テーブル名とその業務的な概要」だけを格納した専用のKnowledge Baseに問い合わせます。この段階の目的は、数十あるテーブルの中から、関連する可能性のある2〜3個のテーブル名を特定することです。
2. フェーズ2（SQL生成）: アプリケーションは、フェーズ1で特定されたテーブルの詳細なカラム情報だけを別の場所（別のKnowledge Baseやファイルなど）から取得します。そして、「ユーザーの質問」＋「絞り込まれたテーブルのカラム情報」という非常にコンパクトなプロンプトをLLMに渡し、SQLを生成させます。
効果: この方法により、最終的なSQL生成プロンプトに含めるスキーマ情報を劇的に削減でき、トークン数を最小限に抑えながら精度を維持することが可能になります。