Programmation et développement logiciel

Ajout d’outils de routage et de basculement dans Microsoft.Extensions.AI

L’équipe .NET a annoncé quatre nouveaux types expérimentaux permettant de router les requêtes d’IA entre des modèles et des fournisseurs de services, d’effectuer un basculement lorsqu’un d’entre eux tombe en panne et de créer des politiques de routage personnalisées dans Microsoft.Extensions.AI.

2026-08-13
5 min de lecture
8 vues
فريق تحرير certi.news
Ajout d’outils de routage et de basculement dans Microsoft.Extensions.AI

Microsoft a ajouté à la bibliothèque Microsoft.Extensions.AI quatre types expérimentaux destinés à gérer le routage des requêtes d’IA et le basculement entre modèles ou fournisseurs de services. Tous ces types implémentent l’interface IChatClient, ce qui permet de les utiliser dans l’architecture actuelle de la bibliothèque pour gérer les contraintes de coût, de disponibilité et de temps de réponse.

Outils de routage et de basculement

RoutingChatClient constitue la classe de base qui sélectionne un client approprié pour chaque requête, puis lui transmet l’appel. Il peut être créé au moyen d’une simple fonction de rappel ou étendu en redéfinissant SelectClientAsync afin d’appliquer des politiques de routage plus complexes ou dépendantes de l’état de l’application.

SemanticRoutingChatClient, quant à lui, route les requêtes en fonction de leur sens. Le développeur fournit à la bibliothèque des exemples de phrases associés à chaque client ; le dernier message de l’utilisateur est ensuite converti en vecteur d’incorporation et comparé aux exemples afin de sélectionner le client présentant la similarité la plus élevée au-dessus du seuil défini. Si aucune correspondance ne dépasse le seuil, le client par défaut est utilisé.

Les vecteurs d’incorporation des exemples de routage sont créés à la demande et mis en cache. Des paramètres tels que scoreThreshold, topK et scoreAggregation permettent de contrôler la similarité minimale et le nombre d’exemples utilisés pour agréger le score, avec la possibilité d’utiliser la moyenne ou la somme. Par défaut, le type se charge également de supprimer les clients et le générateur de vecteurs d’incorporation lorsqu’il est supprimé ; ce comportement peut être désactivé au moyen de leaveOpen.

Basculement et suivi des tentatives

FailoverChatClient étend les capacités de routage en ajoutant une boucle de nouvelle tentative. Si le client sélectionné échoue avant qu’une sortie de diffusion ne soit transmise à l’appelant, le type réappelle SelectClientAsync afin de sélectionner un autre client. En revanche, après le début de l’envoi des sorties, l’échec est considéré comme définitif et le système n’effectue pas de récupération au milieu de la diffusion.

La classe fournit OnRoutingUpdateAsync pour suivre chaque tentative, qu’elle se termine par un succès, un échec ou un abandon. Le journal de la tentative comprend le client appelé, la durée d’exécution, l’exception éventuelle, ainsi que l’indication précisant si la réponse s’est terminée ou si une sortie de diffusion a été transmise à l’appelant, avec, le cas échéant, le délai avant la première mise à jour. Ces données peuvent servir à évaluer les performances des fournisseurs ou à créer des politiques telles que l’ouverture de circuit et le classement des clients selon le temps de réponse.

OrderedFailoverChatClient fournit une implémentation prête à l’emploi de ce mécanisme : il reçoit une liste ordonnée de clients et les essaie successivement. Lorsque toutes les options échouent, la dernière exception est propagée. MaximumAttemptsPerRequest définit le nombre maximal d’appels pour une requête, et la sélection d’un nouveau client s’arrête lorsque le jeton d’annulation de la requête est annulé.

Considérations pour la conception des politiques de routage

La publication met en garde contre le fait de rerouter chaque tour d’une conversation sans tenir compte de sa nature. Les modèles de raisonnement peuvent dépendre d’un contenu chiffré ou de jetons de continuation associés à un fournisseur spécifique ; en outre, le passage à un autre modèle ou fournisseur peut faire perdre le bénéfice de la mise en cache du préfixe et entraîner de nouveau le coût de son calcul.

Pour les conversations comportant plusieurs tours, la publication suggère de fixer le routage au moyen d’un identifiant de session géré par le service lui-même, plutôt que de dépendre du ConversationId propre au fournisseur. Le routage sélectionné peut être enregistré dans l’état de la session ou dans IDistributedCache, et il ne doit être fixé qu’une fois la réponse terminée avec succès.

Parmi les autres politiques pouvant être élaborées figurent le routage selon le temps de réponse, l’état de santé, le coût, les capacités et la région géographique, ainsi que la composition de plusieurs routeurs, puisque chacun d’eux fonctionne comme un IChatClient. Toutefois, ces outils n’implémentent pas le routage séquentiel fondé sur la qualité d’une réponse réussie, l’exécution de plusieurs clients et la fusion de leurs résultats, ni la mise en concurrence des clients pour sélectionner la première réponse ; ces scénarios nécessitent un client qui effectue plusieurs appels.

Disponibilité et statut expérimental

Les types RoutingChatClient, RoutingContext, FailoverChatClient, FailoverChatClientAttempt, OrderedFailoverChatClient et SemanticRoutingChatClient sont disponibles dans la version 10.9.0 de Microsoft.Extensions.AI. Ils sont tous marqués comme expérimentaux au moyen de l’identifiant de diagnostic MEAI001. Le package peut être ajouté avec la commande dotnet add package Microsoft.Extensions.AI.

Source de l’actualité
ف
Auteur

فريق تحرير certi.news

Dans la même catégorie

À lire également

Voir toutes les actualités