LLMコンテキストトークンの設計アプローチ

コンテキストとは？

LLM（大規模言語モデル）における「コンテキスト」とは、モデルがテキスト生成時に参照できる過去の情報領域を指します。これは、モデルにとっての「記憶」の役割を果たし、直前までの入出力履歴や関連ドキュメントを踏まえて、次にどう応答・動作するかを判断します。コンテキストの単位は、1文・1段落・1つのドキュメント、あるいは複数ドキュメントの集合まで、モデルの設計や用途によってさまざまです。

コンテキストは、モデルが現在のタスクを正確に理解し、過去情報に基づいた一貫性ある応答を生成するために不可欠です。たとえばチャットの場合、それまでの全やりとりがコンテキストとなり、会話の流れや雰囲気に沿った回答が可能になります。

ただし計算資源やメモリの制約から、ほとんどのLLMは「コンテキスト長」に上限があります。現在主流のモデルのコンテキスト長はおよそ128K〜100万トークン程度です。今後はより長いコンテキスト対応が進む一方で、コストやレスポンス速度、品質の観点からも効率的なコンテキスト管理が重要になっています。

注：「トークン」とは、単語や記号など自然言語処理上の最小単位を指します。

コンテキスト設計の基本方針

LLMに一度に渡せる情報量（=コンテキスト長）は有限です。その中でどの情報にどれだけリソースを割り当てるかは、エージェント設計において極めて重要なテーマです。 GPTBotsでは、コンテキストをユーザー質問,アイデンティティプロンプト,短期記憶,ナレッジデータ,ツールデータ,長期記憶の6種類に分類し、それぞれに優先度を持たせて管理します。1回のLLM呼び出しで、これら全てが含まれる場合もあれば、用途に応じて一部のみが使われる場合もあります。

注:1回のLLM呼び出し時に、全てのコンテキスト（ユーザー質問や履歴など）の合計トークン数がLLMの上限を超える場合、GPTBotsは優先度の低いコンテキストから順に自動でカット（省略）し、LLM呼び出しの成功率を維持します。

ユーザー質問

エージェントとの会話中、ユーザーが入力欄から送信した最新の内容を指します。ここには以下のような多様なメッセージタイプが含まれます。

• 手動で入力されたテキストメッセージ
• 音声で録音されたオーディオメッセージ
• 添付ファイルとしてアップロードされた画像,動画,ドキュメント,オーディオ,ファイルメッセージ

注:
「Agent-Configuration-Input-Attachment」オプションをシステム認識に設定すると、GPTBotsはアップロードされたすべての添付ファイルをテキストデータとして扱い、ユーザー質問として処理します。
ファイル形式のメッセージの場合は、そのファイルをURLリンクに変換し、同じくユーザー質問として扱われます。

アイデンティティプロンプト

GPTBotsエージェントで設定されるアイデンティティ情報は、AIエージェントの行動指針を決める重要な役割を持ちます。モデルのバージョンに応じて自動的にシステムメッセージや開発者メッセージとして設定されます。

• ビジネス利用の場合、アイデンティティプロンプトはAIの業務や応答の方向性を正しく導くため、明確かつ具体的に作成することが重要です。
• 基本的に、アイデンティティプロンプトの長さはあまり気にする必要はありません。文字数よりも質が重視されるため、必要に応じて十分なトークン数を割り当てましょう。
• プロンプトを作成する際は、分かりやすい表現や正しいロジック、具体的な指示を心がけてください。目的・原則・スキル・業務の進め方などを明確に伝え、曖昧な指示や表現は避けることが重要です。

短期記憶

ユーザーとエージェントの直近の会話内容が、毎回LLMへのリクエストとともに送信されます。
保持する会話履歴の件数は任意に設定できます。短期記憶をオフにしている場合や、会話を開始したばかりの場合は、ここには履歴が入りません。

設定時のポイント:

• エージェントの業務シナリオによっては、コンテキスト（短期記憶）が不要、もしくは逆にAIの応答品質を下げる場合があります。そのようなケースでは、短期記憶機能をオフにすることで、トークン消費を抑えつつパフォーマンスを向上させることができます。
• 一方で、質問応答などコンテキスト依存度が高いシナリオでは、できるだけ多くの直近会話を保持するように設定することが望ましいです。

ナレッジデータ

ユーザーの入力内容に基づき、エージェントは対応するナレッジベース（ナレッジデータベース）からベクトル検索を用いて関連する情報（ナレッジ）を取得します。エージェントがナレッジベースを持っていない場合や、検索結果が取得できない場合、この部分には情報が格納されません。

設定時のポイント:

• エージェントがナレッジベースへの検索を必要としない場合は、ナレッジ検索機能を無効にすることでトークン消費を抑えられます。
• エージェントがナレッジベースからの検索結果に強く依存するケース（たとえば、ドキュメントQ&A用途など）では、「ナレッジベース」の設定で、最大リコール件数や関連度スコアなどの各種パラメータを適切に調整することが重要です。これによりRAG（検索拡張生成）の情報量と品質の双方を担保できます。

長期記憶

ユーザーの入力内容をもとに、エージェント内のすべての会話からベクトル検索によって過去のやりとり（会話履歴）が取得され、この部分に格納されます。長期記憶機能がオフになっている場合や、会話が新規に作成されたばかりの場合は、ここには情報が格納されません。

設定時のポイント:

• エージェントが仮想キャラクターのように「過去の会話内容」を参照しながら動作する場合は、長期記憶機能を有効にしてください。
• 一方、過去の会話履歴を利用しない場合は、長期記憶を無効化することでトークン消費を抑えることができます。## ツールデータ
  システムがLLMへリクエストを送る際、エージェントで選択されたツールのデータも同時に送信します。これにより、LLMが必要なツールを正しく選択して呼び出せます。ツールの呼び出しが成功した場合、APIサービスから返された結果も再度LLMに渡します。なお、ツール機能が無効化されている場合、この項目には何も含まれません。

設定時の注意点:

• エージェントのシナリオでツールの利用が不要な場合は、ツール自体の追加を省略することでトークン消費を抑えることができます。
• 1つのツールに複数のAPIが含まれている場合は、設定画面で不要なAPIのみを無効化できます。無効化したAPIはLLMへのリクエスト時に送信されないため、さらにトークンを節約できます。

LLM出力

LLMの出力トークン数は、リクエスト時に指定した数だけあらかじめ確保されます。GPTBotsではレスポンストークン数を自由に設定できるため、この「LLM出力」の部分は、上記で説明した入力セクションのトークン数には影響されません。

ケーススタディ

具体例を使って、コンテキストトークンの割り当て方を見てみましょう。ここでは、コンテキスト上限が8,000トークンのLLMモデルを利用する場合を想定します。

シナリオ：カスタマーサービスアシスタント

オンラインのカスタマーサービスアシスタントエージェントには、次のような機能が求められます：

• ユーザーとの直近の会話内容を記憶する
• 商品ナレッジベースへの問い合わせを行う
• 注文状況照会用のインターフェースを呼び出す
• プロとしてふさわしいカスタマーサービスの対応を行い続けること

Token Handling Plan

最適化のポイント

1. 動的な割り当て
   • ユーザーからの質問が短い場合、その分のトークンをナレッジデータに自動的に振り分けることができます。
   • ツールが使用されない場合は、その分のトークン枠を短期記憶に自動的に回すことが可能です。
2. 優先度に応じた調整
   • 全体のトークン数が上限を超えた場合、優先度に従って次のようにデータを省略します：
   • 保持する項目：ユーザー質問、短期記憶、アイデンティティプロンプト、ナレッジデータ、ツールデータ
   • 圧縮・省略の対象：長期記憶
3. コア機能の確保
   • トークンが不足している場合でも、注文照会などの主要機能が確実に動作するようにします。
   • レスポンス品質を保つため、必要に応じて長期記憶の情報は省略します。

このような設計を行うことで、限られたトークンスペースの中でもカスタマーサービスアシスタントとして必要なコア機能を実現しつつ、会話の一貫性やプロフェッショナルな対応も維持できます。