Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les applications peuvent utiliser des modèles provenant de différents services d’inférence pour différents tours d’une conversation. Par exemple, une application peut modifier des modèles en fonction du choix de l’utilisateur, des fonctionnalités de modèle, de la disponibilité ou du coût.
La modification de la destination pour la requête suivante n’est qu’une partie du routage. Le nouveau modèle a également besoin de la conversation précédente pour continuer avec le même contexte. S’il peut recevoir ce contexte dépend de l’emplacement où l’historique des conversations est stocké et qui le contrôle.
Le stockage de l’historique des conversations détermine la portabilité
Les services d’inférence prennent en charge différentes approches de l’état de conversation. Certaines API s’attendent à ce que l’appelant fournisse l’historique des messages approprié avec chaque requête. Les autres API stockent la conversation dans le service d’inférence et permettent à l’appelant de continuer en transmettant un identificateur.
| Modèle d’historique | Emplacement où les messages sont stockés | Ce que l’appelant envoie |
|---|---|---|
| Géré par l’appelant | Dans la mémoire contrôlée par l’application ou le stockage durable | L’historique des messages pertinent ainsi que tout nouveau message avec chaque requête |
| Gestion du service d’inférence | Dans le stockage contrôlé par le service d’inférence | Identificateur de conversation ou de réponse spécifique au service, ainsi que tous les nouveaux messages. |
Certains services d’inférence prennent en charge les deux approches par le biais d’API ou d’options différentes. Par exemple, OpenAI Responses dispose du paramètre true que vous pouvez définir sur store pour un historique des conversations géré par le service d’inférence, et sur false pour un historique géré par l’appelant.
L’historique géré par l’appelant prend en charge le routage
Lorsque l’appelant gère l’historique, il a accès aux messages des tours précédents. Un routeur peut sélectionner un autre modèle ou service d’inférence, et l’appelant peut envoyer ces messages avec la requête suivante.
L’historique n’a pas à rester dans la mémoire du processus. Il peut provenir du stockage durable appartenant à l’application, tant que l’application peut la charger et l’envoyer au service sélectionné. La destination doit également prendre en charge le contenu et les fonctionnalités de message utilisés précédemment dans la conversation.
Routage basé sur les limites d’historique gérées par le service d’inférence
Lorsqu’un service d’inférence gère l’historique, il constitue la source de référence de la conversation. L’appelant conserve généralement un identificateur opaque au lieu des messages eux-mêmes.
Cet identificateur désigne l’état géré par le service d’origine. L’accès peut également dépendre du compte ou du projet, du point de terminaison et des informations d’identification utilisés pour créer la conversation. Un client pour un autre service ne peut pas utiliser l’identificateur pour récupérer les messages. Un autre client pour le même service peut également ne pas pouvoir accéder à la conversation s’il utilise une autre étendue.
Un service peut prendre en charge la modification de modèles dans l’une de ses propres conversations stockées. Ce comportement est spécifique au service et ne correspond pas au routage portable. Un routeur général ne peut pas transférer la conversation côté service vers un autre fournisseur sans d’abord récupérer ou reconstruire les messages.
| Scénario de routage | Modèle d’historique | Résultat |
|---|---|---|
| Basculer entre les modèles d’un fournisseur | Géré par l’appelant | L’appelant peut relire l’historique au nouveau modèle. Le nouveau modèle doit prendre en charge les types de message et de contenu utilisés à des tours précédents. |
| Basculer entre différents fournisseurs d’inférence | Géré par l’appelant | L’appelant peut relire l’historique au nouveau fournisseur. Le nouveau fournisseur doit accepter les rôles, les types de contenu, les messages d’appel d’outils et les messages de résultat de l’outil utilisés à des tours précédents. |
| Modifier des modèles au sein d’une conversation côté service | Gestion du service d’inférence | Le commutateur fonctionne uniquement si le service d’inférence permet à la conversation existante de continuer avec le nouveau modèle. Le client de routage ne peut pas activer ce comportement. |
| Basculer vers un autre service d’inférence | Gestion du service d’inférence | Le nouveau service ne peut pas accéder à l’identificateur de conversation du service d’origine. Récupérez ou reconstruisez les messages, puis démarrez la nouvelle route avec l’historique géré par l’appelant. |
Pour plus d’informations sur ces modèles de stockage, consultez Stockage.
Comment Agent Framework implémente le routage du runtime
Agent Framework peut fournir l’historique managé par l’appelant nécessaire pour le routage portable. Dans ce modèle de routage, un fournisseur d’historique de conversation est la source de vérité pour la conversation. Il peut stocker des messages dans la session de l’agent ou dans le stockage appartenant à l’application.
Dans Agent Framework, l’historique géré par l’appelant inclut l’état de session local et le stockage d’historique des conversations personnalisé. L’historique managé par le service d’inférence correspond au stockage géré par le service.
Pour un ChatClientAgent, un client de chat de routage se trouve dans la couche chat-client du pipeline d’agent. L’agent et sa session restent identiques pendant que le client de routage sélectionne l’une des instances nommées IChatClient pour chaque requête.
Une requête routée suit cette séquence :
- Le fournisseur d’historique de conversation charge l’historique des conversations.
- L’agent combine l’historique avec les données d’entrée du tour en cours.
- Le client de routage sélectionne le client de conversation actif pour la session.
- Le client sélectionné reçoit la demande complète.
- Le gestionnaire de l’historique des conversations stocke les nouveaux messages à l’issue de l’exécution.
Étant donné que le client sélectionné reçoit l’historique chargé par le fournisseur, l’application peut modifier les itinéraires sans regénérer manuellement la conversation.
Le SDK .NET fournit la fonctionnalité expérimentale RoutePersistingRoutingChatClient. Définissez l’itinéraire initial avec RoutePersistingRoutingChatClientOptions.DefaultRoute, inspectez l’itinéraire d’une session avec GetActiveRoute, puis modifiez-le avec SetActiveRoute. Si vous ne définissez pas d’itinéraire par défaut, le client utilise le premier itinéraire fourni lors de la construction.
D’autres clients de routage existent dans Microsoft.Extensions.AI ce qui permet d’autres stratégies de routage.
Consultez l’exemple de routage multimodèle pour une implémentation C# complète.
Importante
Chaque client de conversation inscrit en tant qu’itinéraire doit utiliser l’historique géré par l’appelant fourni par un fournisseur d’historique de conversation. Le fournisseur peut stocker cet historique dans la session ou dans le stockage appartenant à l’application. N’inscrivez pas d’itinéraire qui utilise l’historique des conversations gérées par le service d’inférence.
La prise en charge de Python n’est actuellement pas disponible.
Le support Go n’est actuellement pas disponible.