RAG設計におけるトークン制限への対処法とは？情報量と生成精度を両立する工夫｜LLM入門 6.4

6.4 入力長・トークン制限との戦い

どれだけ関連性の高い文書をRetrieverが取得し、どれだけ巧みにプロンプトを設計しても、生成AIモデル（LLM）が受け取れる入力には必ず上限があります。この制限はトークン数という単位で表現され、モデルによってその上限値が異なります。

たとえば、OpenAIの gpt-3.5-turbo では 4,096 トークン、gpt-4 では最大で 128k トークン（2024年時点）とされており、Retrieverで得られた情報量がそのまま渡せるとは限らないのが実情です。

このセクションでは、トークン制限の仕組みとその影響を解説しつつ、限られた入力長の中で最も有効な情報を、最も効果的な形で伝えるための設計戦略を紹介します。

なぜトークン制限は問題になるのか？

トークン制限によって、以下のような問題が生じます：

• 有益な情報が入りきらず、生成結果が不完全になる

• 長い文書を取り扱えないために、Retriever出力が断片的になる

• プロンプトが複雑になるほど、System Promptやテンプレート部分だけで多くのトークンを消費する

• 出力もトークン制限内に収める必要があるため、長文応答が困難になることがある

このように、トークン制限は単なる「データ量の制限」ではなく、情報設計上の構造制約として現れます。

トークンとは何か？モデルによって異なる単位

「トークン」は単語よりも細かく、基本的には文字列の断片です。たとえば：

• 「退職後の健康保険」は、モデルによって 5〜7トークン程度

• 「This is a test.」は、通常 4トークン

• 日本語と英語で分割単位が異なる（日本語は形態素単位、英語はスペースで区切られる）

モデル別の入力制限例（2024年時点）：

トークン制限は「入力（プロンプト）」と「出力（回答）」を合算してカウントされるため、入力が長くなるほど、出力に割ける長さも制限される点に注意が必要です。

情報を取捨選択するための設計戦略

① Retriever段階でチャンク数を制限

• 類似度スコアの高い順に、必要最低限のチャンクを選出

• 上限トークン数を事前に計算し、プロンプト枠と合わせて設計

• LangChainの max_tokens_limit や TokenTextSplitter が有効

② チャンクの圧縮・要約を実施

• Retriever後にチャンクを「圧縮チャンク」に変換（例：LLMによる要点抽出）

• 情報密度を維持しながらトークン数を削減できる

• map-reduce型のRetrieverや CompressionRetriever が実装例

③ メタ情報でフィルタリング

• 文書の出典、カテゴリ、部署、日付などに応じて無関係なチャンクを排除

• 検索対象そのものを狭めることで不要なトークンを節約

④ プロンプトテンプレートの効率化

• System Promptを簡潔に設計（過剰な説明は削除）

• 「指示」→「文脈」→「質問」という構造を明示的かつ簡素に記述

• 定型パーツはテンプレート化し、コードで最小化

設計者が意識すべき「予算」の概念

プロンプト設計においては、トークン＝情報空間の予算であるという視点が重要です。

例：

• 合計使用可能トークン：8,000

  • System Prompt：1,000

  • 質問文：300

  • 文書チャンク：5,500（3〜5件）

  • 出力（回答）：1,200（約700〜1,000字）

このように、「誰がどれだけのスペースを使うか」をあらかじめ設計することで、トークン制限によるトラブルを回避できます。

入力制限との戦いは、設計力の問われる領域

トークン制限は避けられない物理的制約である一方で、その中で最も伝えるべき情報をどう優先し、整えるかという「情報設計」の力が問われる領域です。

生成AIを業務に活かすには、「与える情報量を増やすこと」ではなく、限られた情報枠の中で何をどう渡すかを考える力が不可欠です。

RAGの限界とこれから

第6章では、Retrieverの出力をどう整え、どう渡すかというプロンプト設計と文脈構築の現場を見てきました。
次の章「第7章　RAGの限界と、これから」では、そもそもRAGにはどのような限界があり、今後どのような技術的進化が予想されるのか──「RAGを使い続けるための現実的な視点」へと話を進めていきます。