La politique du routage des modèles
Le petit interrupteur que personne n'a mis à l'ordre du jour
La réunion d'achat portait sur un assistant IA pour une grande organisation de services. L'ordre du jour contenait les habituels noms sérieux : qualité, confidentialité, coût, adoption, conformité, feuille de route. La démonstration s'est déroulée sans accroc. Un utilisateur posait une question, la réponse apparaissait, les sources étaient citées, et l'interface semblait assez calme pour passer devant plusieurs comités. Puis un ingénieur a mentionné que les requêtes passeraient par un routeur de modèles. Simple, a-t-il dit. Le routeur choisirait le meilleur modèle disponible pour chaque tâche.
« Simple » est souvent l'endroit où la politique entre en jeu, vêtue d'une polaire. La salle a entendu un problème d'optimisation. Le routeur équilibrerait coût, vitesse, capacité, disponibilité, et peut-être sensibilité des données. Cela semblait technique. Cela semblait aussi pratique, et c'est le son que font beaucoup de lacunes de gouvernance avant d'obtenir un budget. Ce n'est que plus tard que quelqu'un a demandé ce que « meilleur » signifiait. Le moins cher. Le plus rapide. Le plus précis sur un benchmark en anglais. Le plus disponible pendant les heures de bureau en Europe. Le plus contrôlable. Le plus inspectable. Le moins dépendant d'un fournisseur unique. Le moins susceptible d'envoyer des données confidentielles au-delà d'une frontière que personne ne pouvait expliquer.
Le routeur n'était pas un composant mineur. C'était le point où la politique institutionnelle devenait un comportement d'exécution. Chaque requête passerait par lui. Il déciderait si un modèle local traitait une classification, si un modèle distant rédigeait une réponse, si un modèle spécialisé voyait un texte juridique, si un modèle général recevait le contexte client, si un repli traversait les régions, si un point de terminaison moins cher était autorisé pour un travail à faible risque, et si un cas à fort impact ralentissait pour recueillir des preuves. Le routeur était une surface de gouvernance avec une API.
C'est la politique du routage de modèles. Pas la politique partisane, pas les discours, pas les drapeaux dramatiques dans un document stratégique. La politique plus discrète des compromis encodés comme valeurs par défaut. Une règle de routage peut dépenser l'argent public à l'étranger ou maintenir la capacité localement. Elle peut préserver la localité des données ou l'éroder cas par cas. Elle peut rendre un fournisseur indispensable ou maintenir les portes de sortie ouvertes. Elle peut valoriser l'explicabilité au détriment de la latence, ou la latence au détriment du recours. Elle peut transformer la souveraineté en contrainte opérationnelle ou en paragraphe dans un texte d'appel d'offres.
Le routage n'est pas une tuyauterie neutre
Il est tentant de considérer le routage comme de la plomberie. Une requête arrive. Le système classe la tâche. Il choisit un modèle. La réponse revient. Si la réponse est bonne et la facture moins élevée, tout le monde félicite la plomberie. Mais la plomberie porte un pouvoir. Une conduite d'eau décide quel quartier reçoit la pression. Un routeur de modèles décide quelle capacité reçoit le travail. Le fait que la décision soit automatisée ne la rend pas neutre. Cela rend seulement la politique moins conversationnelle.
Le routeur contient une théorie de la valeur. S'il classe les modèles principalement par prix, l'organisation a choisi le coût comme valeur dominante. S'il les classe par score de référence, il a choisi une définition étroite de la compétence. S'il les classe par latence, il a choisi la vitesse. S'il filtre par juridiction, auditabilité, droits contractuels, transparence des sources ou minimisation des données avant de noter la capacité, il a choisi le contrôle. Aucun de ces choix n'est automatiquement mauvais. Le problème est de prétendre que ce ne sont pas des choix.
Le routage distribue aussi l'apprentissage. Le modèle qui reçoit du trafic reçoit des exemples opérationnels, des rapports d'erreur, de l'attention d'évaluation, des efforts d'intégration et des justifications budgétaires. Le modèle qui reçoit rarement du trafic paraît moins bon avec le temps parce qu'il est moins adapté au travail de l'organisation. C'est ainsi qu'un routeur peut fabriquer l'avenir qu'il prétend simplement mesurer. Si un modèle local ou ouvert n'est toujours utilisé que pour des tâches triviales, il ne construira jamais la base de preuves nécessaire aux tâches sérieuses. Si un modèle général distant reçoit tous les cas difficiles, la dépendance devient une mesure qui se réalise d'elle-même.
Le même effet apparaît dans les équipes. Si la politique de routage est cachée dans un portail fournisseur ou un petit groupe de plateforme, les propriétaires de domaine perdent la visibilité sur les raisons pour lesquelles leur travail va là où il va. Le juridique voit une revue de confidentialité. Les finances voient une ligne de coût. Les opérations voient la qualité des réponses. La sécurité voit les journaux d'accès. Les achats voient les clauses contractuelles. Le routeur voit toute la décision. Celui qui gouverne le routeur gouverne le compromis entre ces perspectives. Ce n'est pas de la plomberie. C'est un arbitrage institutionnel avec une latence plus faible.
Le mot meilleur a besoin de témoins
Meilleur est un mot trop petit pour le routage de modèles. Un modèle peut être le meilleur pour la traduction, le pire pour le traitement de sources confidentielles, adéquat pour la synthèse, médiocre pour l'extraction structurée, excellent pour la vitesse, coûteux pour le volume, faible pour la traçabilité et politiquement délicat pour un organisme public qui doit expliquer où sont allées les données des citoyens. Un classement unique masque le fait que la capacité est multidimensionnelle. Il masque aussi le fait que chaque dimension compte différemment selon la tâche.
Un assistant de revue de contrat doit router différemment d'un message d'accueil de service d'assistance. Un outil de soutien au triage médical doit router différemment d'un résumé de réunion. Un chatbot municipal répondant aux heures d'ouverture doit router différemment d'un système rédigeant des lettres de mise en demeure. La tâche, les données, la base juridique, la réversibilité, la revue humaine et la personne concernée changent toutes la route. Traiter la même politique de routage comme appropriée pour tout le travail n'est pas de l'efficacité. C'est de la commodité déguisée en schéma de systèmes.
Le mot meilleur a donc besoin de témoins. Une décision de routage devrait pouvoir montrer quelles contraintes ont été appliquées avant la sélection du modèle. Elle devrait montrer pourquoi certains modèles étaient éligibles, pourquoi d'autres étaient bloqués, quelles preuves soutenaient le choix et quelle solution de repli serait utilisée si la route choisie échouait. Si le coût a primé sur la localité, dites-le. Si la localité a primé sur la capacité, dites-le. Si un cas à fort impact exigeait un modèle inspectable plutôt que le modèle le plus rapide, dites-le. Les compromis cachés ne deviennent pas moins politiques en étant cachés. Ils deviennent moins responsables.
Il y a une petite cruauté dans les tableaux de bord qui présentent le succès du routage comme un score unique et global. La qualité moyenne des réponses augmente. Le coût moyen diminue. La latence moyenne est acceptable. Pendant ce temps, des cas sensibles peuvent franchir une frontière, un travail d'expert peut être routé vers un modèle incapable de fournir des preuves fiables, et un repli peut silencieusement envoyer des requêtes vers une région que personne n'a approuvée. Les moyennes sont rassurantes de la même manière qu'un générateur de brouillard crée une ambiance. Ce n'est pas là que devrait vivre une gouvernance sérieuse.
Le routage par coût a une longue traîne
Le routage par coût est attrayant car il produit rapidement des économies visibles. Envoyez les tâches simples vers des modèles moins chers. Utilisez les modèles coûteux uniquement lorsque c'est nécessaire. Mettez en cache les réponses répétées. Repliez-vous lorsqu'un fournisseur ralentit. Rien de tout cela n'est insensé. En fait, refuser la discipline des coûts est une forme d'irresponsabilité en soi. L'erreur consiste à laisser le coût unitaire à court terme devenir le seul chiffre sérieux de la politique de routage.
La longue traîne commence avec l'évaluation. Une route bon marché qui augmente la charge de relecture peut ne sembler bon marché que parce que cette charge de relecture se trouve dans un autre service. Un modèle rapide qui produit des erreurs légèrement plus plausibles peut augmenter les coûts de correction, le traitement des réclamations, l'effort d'audit ou la fatigue professionnelle. Un repli qui évite les temps d'arrêt en traversant une région peut créer du travail juridique plus tard. Un modèle bon marché aujourd'hui peut devenir coûteux une fois que l'organisation a construit autour de lui des invites, des évaluations, un réglage fin, une surveillance et des habitudes d'exploitation. La dépendance a l'habitude de s'introduire après la remise de bienvenue.
Le routage par coût façonne également le marché. Les grandes organisations ne sont pas des acheteurs passifs. Leur trafic forme les priorités des fournisseurs et finance certains écosystèmes. Si un travail institutionnel sérieux est toujours routé vers un petit nombre de points de terminaison externes, la capacité locale s'affaiblit. Si les tâches à faible risque mais à fort volume sont réservées aux modèles locaux, ces modèles gagnent des preuves opérationnelles et de l'oxygène économique. Cela ne signifie pas que chaque organisation doit subventionner une technologie dont elle n'a pas besoin. Cela signifie que la politique de routage est l'un des endroits où les choix d'approvisionnement deviennent des choix industriels.
Il existe aussi une version opérationnelle de ce système. Si une équipe ne voit jamais ce que le routeur a fait, elle ne peut pas apprendre où des modèles plus petits suffisent. Elle ne peut pas identifier les tâches qui devraient devenir des flux de travail déterministes. Elle ne peut pas trouver le point où de meilleures données permettraient un routage moins coûteux. Le routeur devient une boîte noire qui économise de l'argent au niveau central tout en rendant la compétence locale uniquement accidentelle. C'est un mauvais marché. Un bon routeur devrait rendre les coûts suffisamment visibles pour que les équipes puissent améliorer le travail, et pas seulement la facture.
La localité est une contrainte pratique, pas une humeur
La localité des données est souvent évoquée dans un langage enflé, comme si chaque décision de routage était un référendum sur la civilisation. C'est inutile et, surtout, ennuyeux. La localité est une contrainte pratique. Où les données se déplacent-elles. Où sont-elles traitées. Où les journaux sont-ils stockés. Quelles lois s'appliquent. Quel personnel peut inspecter la trace. Quel fournisseur peut voir le matériel dérivé. Quelle demande de suppression ou de correction peut être satisfaite. Quel système continue de fonctionner si une route est bloquée. Ces questions déterminent si une organisation contrôle son travail sous pression.
Certains travaux peuvent quitter l'organisation en toute sécurité. D'autres ne le devraient pas. Certains travaux peuvent partir après rédaction. Certains travaux ne peuvent partir qu'après un contrôle de politique. Certains travaux devraient être effectués localement parce que les données sont sensibles, que la latence est importante, que le modèle est suffisamment bon ou que les preuves doivent rester sous contrôle direct. Certains travaux devraient être effectués à distance parce que la tâche nécessite réellement des capacités qui ne sont pas locales. Le but n'est pas la pureté. Le but est un placement délibéré avec un reçu.
La localité inclut également les preuves. Il ne suffit pas de savoir que la réponse est revenue. L'organisation doit savoir quelle route a été choisie, quelles contraintes ont été vérifiées, quels extraits de source ont été envoyés, quelle version de modèle a répondu, quelle solution de repli était disponible et si des données dérivées ont été conservées. Si la trace n'est visible que via le tableau de bord d'un fournisseur, l'organisation peut découvrir pendant un incident que sa responsabilité dépend d'une file d'attente de support. Une file d'attente de support n'est pas une stratégie de souveraineté, même si le numéro de ticket est très rassurant.
Une bonne politique de localité rend la route sûre moins chère à utiliser. Si la rédaction, l'extraction locale, les contrôles de politique et la capture de preuves sont pénibles, les équipes trouveront des raccourcis. Si le routeur peut appliquer ces contrôles automatiquement, les équipes n'ont pas à devenir des spécialistes amateurs de juridiction avant le déjeuner. Le gain pratique n'est pas la propreté idéologique. C'est la réduction de la friction pour faire la chose contrôlée.
Les benchmarks ne sont pas des mandats
Le routage de modèles emprunte souvent sa confiance aux benchmarks. Ce modèle obtient de meilleurs scores en raisonnement. Celui-là est meilleur en codage. Un autre est moins cher pour les contextes longs. Les benchmarks sont utiles, mais ils ne sont pas des mandats. Ils représentent rarement les documents réels de l'organisation, le mélange linguistique, les contraintes de politique, la tolérance aux erreurs, le schéma de révision humaine ou la frontière juridique. Un benchmark peut vous dire qu'un modèle est généralement solide. Il ne peut pas vous dire qu'il devrait voir un fichier citoyen particulier à 14h07 un jeudi sous une exception de politique temporaire.
L'évaluation des tâches doit donc se situer dans la boucle de routage. Quel modèle a produit des sorties structurées correctes sur vos formulaires. Quel modèle a moins halluciné sur vos archives de politique. Quel modèle a préservé la nuance néerlandaise dans les textes de réclamation. Quel modèle a géré les anciens documents scannés. Quel modèle a échoué en toute sécurité lorsque les sources étaient en conflit. Quel modèle a donné de meilleures réponses après la récupération. Quel modèle a augmenté la dérogation humaine. Quel modèle a réduit le travail de reprise. La bonne réponse peut changer par trimestre, par qualité de source, par politique et par effectif.
Le routage doit aussi reconnaître les solveurs non basés sur un modèle. Certaines tâches relèvent de règles, de requêtes de base de données, de recherche, de solveurs de contraintes, de modèles ou de bureaux humains. Envoyer un travail déterministe à un modèle génératif parce que le routeur est déjà là, c'est comme appeler un taxi pour traverser le bureau. Il peut arriver, mais vous avez mal compris le bâtiment. Le routeur doit pouvoir dire qu'aucun modèle n'est nécessaire. Ce n'est pas un échec de l'adoption de l'IA. C'est le début d'une architecture saine.
La constitution cachée du routeur
Chaque routeur a besoin d'une constitution, même si le document ne s'appelle pas ainsi, parce que les organisations deviennent nerveuses quand un logiciel ressemble à un pays. La constitution précise quelles règles sont des contraintes strictes et lesquelles sont des préférences. Les données personnelles sensibles ne doivent jamais franchir une frontière définie. Les décisions à fort enjeu peuvent exiger des routes inspectables. Les résumés à faible risque peuvent optimiser le coût. Les solutions de repli peuvent dégrader les capacités, mais pas la confidentialité. Les règles d'urgence peuvent expirer. Les humains ne peuvent passer outre le routage qu'avec une raison enregistrée.
Cette constitution doit être lisible par la politique, l'ingénierie, les opérations, les achats, le juridique, la sécurité et l'audit. Cela ne signifie pas que chaque personne lit du code. Cela signifie que les règles de routage ont une couche politique compréhensible et une couche technique testable. Une règle que le juridique comprend mais que l'ingénierie ne peut pas tester est du théâtre. Une règle que l'ingénierie peut tester mais que la politique ne peut pas comprendre est un gouvernement privé. Ni l'un ni l'autre n'est une bonne image, même si le second a souvent un YAML plus joli.
La constitution doit aussi définir le changement. Qui peut ajouter un modèle. Qui peut en retirer un. Qui peut modifier les pondérations. Qui approuve un nouveau repli. Quelles preuves sont requises avant qu'un modèle moins cher reçoive plus de trafic. Que se passe-t-il quand un fournisseur change ses conditions, la version du modèle, ses pratiques de conservation ou sa région. Quels indicateurs déclenchent un examen. Quels incidents suspendent une route. Sans règles de changement, la politique de routage dérive à travers une série de petites décisions pratiques jusqu'à ce que personne ne se souvienne quand la constitution a bougé.
Il y a ici une politique humaine. Les équipes feront pression pour des routes qui facilitent leur travail. La finance aimera les routes bon marché. La sécurité aimera les routes contenues. Les utilisateurs aimeront les routes rapides. Les experts du domaine aimeront les routes capables. Les achats aimeront les routes conformes aux contrats. Les dirigeants aimeront les routes qui gardent les options ouvertes sans coûter visiblement plus. Ces intérêts sont légitimes. Le routeur est l'endroit où ils doivent être conciliés explicitement, plutôt que de les faire passer en contrebande dans une valeur par défaut appelée équilibré.
Le repli est l'endroit où les principes sont mis à l'épreuve
Il est facile de gouverner le routage quand tout fonctionne. Le moment le plus difficile, c'est la panne, la surcharge, la pression budgétaire ou l'attention du public. Un fournisseur distant ralentit. Un modèle local échoue à un test de version. Un point d'accès à haute capacité devient indisponible. Une nouvelle politique restreint une région. Un fournisseur modifie ses conditions de conservation. L'organisation a encore du travail à faire. Les règles de repli décident si les principes survivent à l'inconvénient.
Une politique de repli sérieuse indique ce qui peut se dégrader et ce qui ne le peut pas. La latence peut se dégrader. La capacité peut se dégrader pour les tâches à faible risque. Certains travaux non urgents peuvent faire la queue. Certaines tâches peuvent revenir à des modèles ou à des règles. Certaines routes à fort impact peuvent s'arrêter plutôt que de franchir une limite. Certaines exceptions d'urgence peuvent exiger une approbation humaine et expirer après un délai défini. Le routeur ne devrait pas découvrir ces choix pendant la panne. C'est ainsi que les institutions commencent à écrire la gouvernance dans le fil de discussion de l'incident, un genre littéraire d'une dignité limitée.
Le repli a aussi besoin de preuves. Si une requête a emprunté une route d'urgence, le journal doit le mentionner. Si des données ont été masquées différemment, il faut le dire. Si un modèle de moindre capacité a été utilisé, il faut le dire. Si un humain a dû examiner la requête parce que la route normale était indisponible, il faut le dire. L'évaluation ultérieure doit séparer les performances normales des performances de repli. Sinon, un compromis temporaire devient invisible, puis normal, puis défendu comme une tradition par quelqu'un qui n'était pas à la réunion d'incident.
C'est une des raisons pour lesquelles le routage relève de la gouvernance, et pas seulement de l'ingénierie de plateforme. Les ingénieurs peuvent construire le mécanisme. L'institution doit décider ce qui est autorisé sous pression. Un routeur qui maintient toujours le service en mouvement peut sembler résilient. S'il continue en ignorant les limites, il n'est pas résilient. Il est simplement complaisant.
Une boucle de décision, pas un interrupteur magique
Les systèmes de routage les plus sains fonctionnent comme des boucles de décision. Ils observent le type de requête, la sensibilité des données, la qualité de la source, les performances du modèle, les retours des utilisateurs, le coût, la latence, les dérogations et les incidents. Ils interprètent si la route actuelle convient toujours à la tâche. Ils décident s'il faut modifier les pondérations, les contraintes, les modèles, les invites, la préparation des données ou l'examen humain. Ils consignent la raison du changement. Ils testent si les résultats se sont améliorés. Ils enseignent à l'organisation ce qui a été appris.
Cette boucle est importante parce que le monde ne reste pas immobile pour un routeur. Les modèles changent. Les prix changent. Les réglementations changent. Les contrats changent. Les données changent. Les utilisateurs modifient leur comportement une fois que l'assistant devient normal. Les tâches expérimentales deviennent essentielles. Les tâches qui semblaient simples révèlent des exceptions. Un routeur figé au lancement n'est pas de la gouvernance. C'est un fossile avec un accès réseau.
La boucle devrait inclure des personnes proches du travail. Elles savent quand une réponse de modèle est techniquement correcte mais opérationnellement inutile. Elles savent quand une réponse plus rapide augmente les appels de suivi. Elles savent quand un modèle local est suffisant si l'entrée est nettoyée au préalable. Elles savent quand un spécialiste distant est justifié. Un routage qui ignore les retours du domaine optimisera les chiffres visibles, puis fera semblant d'être surpris quand le vrai travail n'est pas d'accord.
Les questions dérangeantes de l'acheteur
Toute organisation qui achète ou construit une couche de routage devrait se poser des questions dérangeantes dès le début. Pouvons-nous voir la politique de routage sous une forme que nos équipes de gouvernance comprennent. Pouvons-nous la tester. Pouvons-nous prouver quelle route a été utilisée pour un cas. Pouvons-nous exclure des modèles selon la classe de données, la juridiction, la tâche, l'impact ou l'exigence de preuve. Pouvons-nous imposer une route pour l'évaluation. Pouvons-nous comparer les coûts cachés, et pas seulement les coûts de jetons. Pouvons-nous conserver des enregistrements lorsqu'un fournisseur change. Pouvons-nous partir sans perdre notre historique de routage.
Ces questions ne sont pas contre l'innovation. C'est ainsi que les institutions sérieuses évitent de transformer le choix du modèle en tableau d'humeur. Un routeur flexible sans gouvernance peut se déplacer rapidement vers des endroits que personne n'a approuvés. Un routeur rigide sans apprentissage peut figer de mauvais choix. L'objectif n'est ni le chaos ni le ciment. L'objectif est une couche de route qui peut s'adapter sous des règles, et des règles qui peuvent être contestées par des preuves.
Il vaut aussi la peine de se demander qui profite de l'opacité. Si le routeur est impossible à inspecter, l'organisation peut se faire dire que le meilleur modèle a été sélectionné sans pouvoir voir quelles valeurs ont été utilisées. Cela peut être acceptable pour une application jouet. Ce n'est pas acceptable pour un travail impliquant des données sensibles, des tâches publiques, des décisions réglementées, un jugement professionnel ou une dépendance stratégique. Faites-moi confiance, le routeur sait n'est pas un modèle de gouvernance. C'est une phrase qui devrait pousser une équipe d'approvisionnement à tendre la main vers un autre biscuit.
La leçon
Le routage de modèles est politique parce qu'il transforme les priorités institutionnelles en choix d'exécution. Il décide où vont les données, quels modèles reçoivent du travail, quels fournisseurs gagnent en dépendance, quelles capacités mûrissent, quels risques sont tolérés, quelles preuves sont conservées et quelles solutions de repli sont autorisées sous pression. Le mécanisme technique peut être un classifieur, un moteur de politique, une fonction de score ou un flux de travail. Les conséquences sont organisationnelles.
Un bon routage commence par admettre que meilleur est pluriel. Le meilleur pour le coût n'est pas toujours le meilleur pour le contrôle. Le meilleur pour la capacité n'est pas toujours le meilleur pour la localité. Le meilleur pour la latence n'est pas toujours le meilleur pour l'auditabilité. Le meilleur pour aujourd'hui n'est pas toujours le meilleur pour la valeur de sortie. Un routage mature applique d'abord des contraintes strictes, évalue l'adéquation localement, enregistre la route, examine les résultats et modifie la politique avec des preuves. Il inclut des règles, des modèles, des humains et parfois la sage décision de ne pas utiliser de modèle du tout.
La politique ne disparaît pas si le routeur est caché. Elle se déplace simplement dans les réglages par défaut, les paramètres du fournisseur et les compromis non documentés. Mieux vaut la mettre au grand jour. Un routeur de modèles devrait être une carte des mouvements institutionnels autorisés, et non un interrupteur magique entre des points de terminaison. Une fois qu'une organisation comprend cela, le routage cesse d'être une note technique en bas de page et redevient ce qu'il a toujours été : un plan de contrôle pour la souveraineté.