アプリケーションでは、会話のターンごとに異なる推論サービスのモデルを使用できます。 たとえば、アプリケーションは、ユーザーの選択、モデル機能、可用性、コストに基づいてモデルを変更する場合があります。
次の要求の宛先の変更は、ルーティングの一部にすぎません。 新しいモデルでは、前の会話も同じコンテキストで続行する必要があります。 そのコンテキストを受信できるかどうかは、チャット履歴が格納される場所と、そのコンテキストを制御するユーザーによって異なります。
チャット履歴ストレージによって移植性が決まる
推論サービスでは、会話状態に対するさまざまなアプローチがサポートされています。 一部の API では、呼び出し元がすべての要求に関連するメッセージ履歴を提供することを想定しています。 他の API は、推論サービスに会話を格納し、識別子を渡して呼び出し元が会話を続行できるようにします。
| 履歴モデル | メッセージが格納される場所 | 呼び出し元が送信する内容 |
|---|---|---|
| 呼び出し元が管理する | アプリケーションによって制御されるメモリまたは永続ストレージ内 | 関連するメッセージ履歴と、各リクエストに伴う新しいメッセージすべて |
| 推論サービス管理 | 推論サービスによって制御されるストレージ内 | サービス固有の会話または応答の識別子と、新しいメッセージ（があれば） |
一部の推論サービスでは、異なる API またはオプションによる両方のアプローチがサポートされています。 たとえば、OpenAI 応答には store パラメーターがあり、推論サービスで管理されるチャット履歴の true と、呼び出し元が管理する false に設定できます。
呼び出し元が管理する履歴でルーティングがサポートされる
呼び出し元が履歴を管理すると、以前のターンからのメッセージにアクセスできます。 ルーターは別のモデルまたは推論サービスを選択でき、呼び出し元は次の要求でそれらのメッセージを送信できます。
履歴はプロセス メモリに残る必要はありません。 アプリケーションが読み込んで選択したサービスに送信できる限り、アプリケーション所有の永続ストレージから取得できます。 宛先は、会話の前に使用したメッセージの内容と機能もサポートする必要があります。
推論サービスによって管理される履歴制限ルーティング
推論サービスが履歴を管理する場合、それが会話の真実のソースになります。 通常、呼び出し元はメッセージ自体の代わりに不透明な識別子を保持します。
その識別子は、元のサービスによって保持されている状態を参照します。 また、アクセスは、会話の作成に使用されるアカウント、プロジェクト、エンドポイント、資格情報によっても異なります。 別のサービスのクライアントは、識別子を使用してメッセージを取得することはできません。 同じサービスの別のクライアントが別のスコープを使用している場合、会話にアクセスできない場合もあります。
サービスは、独自に保存された会話の 1 つ内のモデルの変更をサポートする場合があります。 この動作はサービスに固有であり、移植可能なルーティングではありません。 一般的なルーターは、最初にメッセージを取得または再構築しないと、サービス側の会話を別のプロバイダーに転送できません。
| ルーティング シナリオ | 履歴モデル | Result |
|---|---|---|
| 1 つのプロバイダーからモデルを切り替える | 呼び出し元管理型 | 呼び出し元は、履歴を新しいモデルに再生できます。 新しいモデルでは、前のターンで使用したメッセージとコンテンツ タイプをサポートする必要があります。 |
| さまざまな推論プロバイダーを切り替える | 呼び出し元による管理 | 呼び出し元は、新しいプロバイダーに履歴を再生できます。 新しいプロバイダーは、ロール、コンテンツ タイプ、ツール呼び出しメッセージ、および以前のターンで使用されたツール結果メッセージを受け入れる必要があります。 |
| 1 つのサービス側の会話内でモデルを変更する | 推論サービス管理 | このスイッチは、推論サービスが既存の会話を新しいモデルで続行できる場合にのみ機能します。 ルーティング クライアントでは、この動作を有効にできません。 |
| 別の推論サービスに切り替える | 推論サービス管理 | 新しいサービスは、元のサービスの会話識別子にアクセスできません。 メッセージを取得または再構築し、呼び出し元が管理する履歴を使用して新しいルートを開始します。 |
これらのストレージ モデルの詳細については、「 ストレージ」を参照してください。
Agent Framework でランタイム ルーティングを実装する方法
Agent Framework は、ポータブル ルーティングに必要な呼び出し元管理の履歴を提供できます。 このルーティング パターンでは、チャット履歴プロバイダーが会話の真実のソースです。 エージェント セッションまたはアプリケーション所有のストレージにメッセージを格納できます。
Agent Framework では、呼び出し元が管理する履歴には、ローカル セッション状態とカスタム チャット履歴ストレージが含まれます。 推論サービスで管理される履歴は、サービスによって管理されるストレージに対応します。
ChatClientAgentの場合、ルーティング チャット クライアントはエージェント パイプラインのチャット クライアント レイヤーに配置されます。 エージェントとそのセッションは変わりませんが、ルーティング クライアントは要求ごとに複数の名前付き IChatClient インスタンスのいずれかを選択します。
ルーティング要求は、次の順序に従います。
- チャット履歴プロバイダーが会話履歴を読み込みます。
- エージェントは、履歴と現在のターンの入力を組み合わせます。
- ルーティング クライアントは、セッションのアクティブなチャット クライアントを選択します。
- 選択したクライアントが完全な要求を受け取ります。
- チャット履歴プロバイダーは、実行後に新しいメッセージを格納します。
選択したクライアントはプロバイダーによって読み込まれた履歴を受け取るため、アプリケーションは会話を手動で再構築することなくルートを変更できます。
.NET SDK は、試験的なRoutePersistingRoutingChatClientを提供します。
RoutePersistingRoutingChatClientOptions.DefaultRouteで初期ルートを設定し、GetActiveRouteを使用してセッションのルートを検査し、SetActiveRouteで変更します。 既定のルートを設定しない場合、クライアントは構築時に指定された最初のルートを使用します。
さらにルーティング戦略を可能にする Microsoft.Extensions.AI には、より多くのルーティング クライアントが存在します。
完全な C# 実装については 、マルチモデル ルーティングのサンプル を参照してください。
Important
ルートとして登録されたすべてのチャット クライアントは、チャット履歴プロバイダーによって提供される呼び出し元が管理する履歴を使用する必要があります。 プロバイダーは、その履歴をセッションまたはアプリケーション所有のストレージに格納できます。 推論サービスで管理される会話履歴を使用するルートを登録しないでください。
Pythonサポートは現在利用できません。
Go のサポートは現在利用できません。