Model routing : concevoir un routeur de modèles qui réduit le coût sans dégrader le risque

Ce qu’il faut retenir

• Un routeur de modèles n’optimise pas un classement abstrait de modèles. Il choisit une voie d’exécution pour une demande donnée, sous des contraintes explicites de qualité, de risque, de données, de délai et de coût.
• La politique la plus simple qui respecte les contraintes constitue la baseline : règles métier, petit modèle avec abstention, cascade ou prise en charge humaine. Un routeur appris n’est justifié que s’il améliore cette référence sur un jeu indépendant.
• Le coût pertinent comprend toutes les voies, les secondes tentatives, la vérification, les files d’attente et les échecs. Le prix du premier appel ne suffit pas.
• Une mesure moyenne masque les cas rares et les impacts différents. La recette porte sur la qualité par tâche et segment, ainsi que sur la gravité des erreurs, la couverture et le respect du budget.
• Le routeur doit pouvoir être rejoué, désactivé et remplacé par une politique de secours. Sa décision est journalisée sans dupliquer inutilement les données du dossier.

Définir la décision de routage avant de choisir un algorithme

Le model routing est souvent présenté comme un aiguillage entre un modèle économique et un modèle plus capable. Cette image est trop étroite. Dans un service d’assurance, les destinations possibles comprennent aussi une règle déterministe, un extracteur spécialisé, une recherche documentaire, un formulaire, une file humaine et l’abstention. La première étape consiste donc à lister les routes autorisées, pas à entraîner un classifieur.

Chaque demande reçoit un contexte de décision borné : type de tâche, canal, langue, produit, longueur, présence des pièces minimales, sensibilité, délai attendu et niveau d’impact. Le routeur ne doit pas lire plus d’informations qu’il n’en faut. Lorsqu’une caractéristique est inconnue, elle reste inconnue ; la politique ne la remplace pas silencieusement par la valeur la plus fréquente. La séparation entre règle déterministe, estimation probabiliste et génération aide à attribuer chaque fonction avant de router.

La sortie du routeur est un objet exploitable : identifiant de route, version de politique, contraintes appliquées, motif synthétique, budget restant et voie de secours. Elle ne constitue ni un avis sur le dossier ni une décision contractuelle. Cette séparation empêche qu’un score technique devienne, par raccourci, une autorisation métier.

Dessiner des routes complètes, pas une liste de modèles

Une route décrit toute la chaîne entre l’entrée et la réponse utilisable. Elle précise la préparation des données, le modèle et sa version, les outils appelés, la validation du schéma, les contrôles métier, les conditions d’abstention et le destinataire final. Deux modèles identiques, exécutés avec des contextes ou des garde-fous différents, forment deux routes différentes.

Route	Usage borné	Contrôle avant sortie	Repli
Règle	format, présence, calcul ou seuil réglementé	tests unitaires et table de décision versionnée	file d’exception
Modèle compact	classification ou extraction sur taxonomie stable	schéma, seuil par classe, contrôle des champs	modèle de recours ou humain
RAG spécialisé	réponse documentaire localisée	sources admissibles, citations et contradictions	recherche assistée
Modèle généraliste	formulation complexe dans un périmètre autorisé	format, preuves, règles de contenu et revue	file humaine
Traitement humain	cas ambigu, impact élevé ou données manquantes	compétence, délai et journal de décision	escalade opérationnelle

Le graphe peut comporter plusieurs étapes. Un premier modèle produit une sortie structurée ; un validateur décide de l’accepter, de demander une nouvelle tentative ou de l’escalader. La profondeur est limitée. Sans plafond de tentatives, une cascade apparemment économique peut créer une boucle lente, coûteuse et difficile à diagnostiquer.

Les dépendances sont inscrites dans le registre des routes : région d’hébergement, sous-traitants, modèles appelés, type de données envoyé, durée de conservation, quotas et version des prompts. Une route techniquement disponible mais incompatible avec une contrainte de données est retirée avant tout calcul de préférence.

Choisir des signaux disponibles au bon moment

Un signal de pré-routage existe avant l’appel : taille, langue, produit, canal, type de pièce, structure attendue ou disponibilité d’une source. Il peut éviter un appel inutile. Un signal de post-routage apparaît après une première exécution : validité du JSON, citation manquante, désaccord entre extracteurs, score calibré ou règle métier violée. Les confondre conduit à évaluer une politique avec des informations qu’elle n’aura pas en production.

Le texte intégral n’est pas forcément une bonne caractéristique de routage. Il augmente l’exposition des données, rend l’explication moins stable et peut permettre à un contenu hostile d’influencer le choix d’outils. Une architecture prudente commence par des attributs structurés et des contrôles déterministes. L’usage d’un modèle pour décider du modèle est ensuite testé comme un composant à part entière.

Les signaux doivent conserver leur provenance. Le produit vient-il du dossier, d’une saisie ou d’une prédiction ? La langue a-t-elle été détectée ou déclarée ? Un niveau d’impact a-t-il été calculé automatiquement ? Le journal contient la valeur utile et sa source, mais pas une copie intégrale du courrier ou de la pièce.

1. Admissibilité : exclure les routes interdites par les droits, la région, la tâche ou l’état du dossier.
2. Pré-routage : sélectionner une première voie à partir de signaux disponibles et versionnés.
3. Validation : contrôler structure, preuve et règles sans demander au modèle de s’auto-certifier.
4. Escalade : appliquer une seule voie de recours bornée, puis transmettre à une personne si le contrat n’est toujours pas respecté.

Construire une baseline contrôlable

La première politique peut tenir dans une table. Les demandes de formulaire incomplet sont retournées, les langues non couvertes vont à une file dédiée, les tâches stables passent par un modèle compact et les cas d’impact élevé restent humains. Cette référence mesure déjà la distribution des routes, les coûts et les reprises. Elle révèle souvent que le problème principal vient de données manquantes ou d’une taxonomie imprécise, pas du choix du modèle.

Une baseline « tout vers le modèle le plus capable » est utile pour mesurer un plafond de qualité, mais ce n’est pas forcément la référence opérationnelle. Une deuxième baseline « politique métier simple » est nécessaire pour savoir si la sophistication du routeur apporte quelque chose. Les deux sont évaluées sur exactement les mêmes demandes et avec les mêmes critères de sortie. Le choix d’un petit modèle sur une tâche bornée dépend donc de la recette de l’artefact réel, pas de son étiquette.

Le jeu d’évaluation est séparé des exemples utilisés pour rédiger les prompts, fixer les seuils ou définir les règles. Il inclut des demandes fréquentes, rares, incomplètes, contradictoires, longues, multilingues et hors périmètre. Les volumes sont rapportés avec les métriques ; une excellente performance sur dix cas rares ne compense pas une absence de preuve.

Comparer règles, cascades et routeurs appris

Règles explicites

Les règles sont adaptées lorsque les signaux et les frontières sont stables : longueur, type de tâche, produit, droits ou présence d’une pièce. Elles s’auditent facilement et réagissent immédiatement à une interdiction. Leur limite tient aux interactions nombreuses et aux zones grises. Un registre de priorités empêche que deux règles applicables envoient la même demande vers des routes différentes.

Cascade avec validation

La cascade appelle une voie économique, puis escalade si un test échoue. Elle convient quand le résultat possède une forme vérifiable : schéma JSON, champs obligatoires, preuve documentaire, cohérence de montants ou accord avec une règle. Le validateur doit être indépendant de la prose du modèle. Une déclaration du type « confiance élevée » ne constitue pas une preuve de qualité.

Routeur appris

Un routeur appris estime quelle route satisfera le contrat pour une demande. Les travaux RouteLLM étudient des routeurs entre modèles à partir de préférences, tandis que FrugalGPT explore des stratégies de cascade et de sélection pour des services de modèles. Ces résultats portent sur leurs jeux, modèles, prix et critères. Ils démontrent des méthodes de recherche, pas un gain garanti dans l’assurance.

L’apprentissage exige des labels propres : route acceptable, gravité de l’erreur, coût observé et contexte de décision. Les réponses comparées sont évaluées à l’aveugle autant que possible. Si le juge automatique privilégie le style d’un fournisseur, le routeur reproduira ce biais. Un sous-ensemble relu selon une grille métier permet de mesurer cet écart.

Politique	Force	Risque principal	Preuve de passage
Règles	lisibilité et réaction rapide	angles morts et conflits	tests de décision exhaustifs sur les frontières
Cascade	économie sur cas simples	validateur faible ou escalades nombreuses	qualité-couverture et coût total
Routeur appris	frontière adaptée aux données	dérive, labels biaisés, opacité	gain indépendant contre les deux baselines
Hybride	contraintes dures plus préférence apprise	complexité de diagnostic	ablation de chaque étage

Mesurer qualité, couverture et gravité

Le routeur est correct si la route choisie produit une sortie acceptable selon le contrat de la tâche. Il ne suffit pas qu’il prédise le modèle que des annotateurs préfèrent. Pour une extraction, la mesure peut porter sur les champs et les erreurs critiques ; pour une réponse documentaire, sur le support des affirmations ; pour une rédaction, sur le respect du schéma, des faits fournis et des interdictions.

La qualité-couverture décrit le compromis entre la fraction traitée par une route et la qualité sur cette fraction. Lorsque le seuil d’acceptation monte, la couverture du modèle compact doit généralement baisser. La courbe est calculée sur un jeu indépendant, par segment. Un seuil unique peut être inadéquat si une confusion sur un produit a un impact différent de la même confusion sur un autre.

La matrice d’erreurs pondère les conséquences : information à reformuler, reprise interne, retard, exposition de données, communication erronée ou influence sur une décision. Les poids ne sont pas appris à partir du coût fournisseur ; ils sont arbitrés avec le métier, la conformité et les opérations. Les cas d’impact élevé peuvent être rendus inéligibles au traitement automatique même si leur score moyen est bon.

L’abstention est un résultat normal. Elle est évaluée sur deux axes : le système s’abstient-il sur les cas dangereux et accepte-t-il encore une fraction utile des cas maîtrisés ? Une politique qui envoie tout à l’humain ne crée pas d’erreur automatique, mais ne répond pas à la promesse d’efficacité. Une politique qui accepte tout cache son incertitude.

Calculer coût et latence de bout en bout

Le coût par demande additionne préparation, appels, tokens ou temps machine, recherche, validation, nouvelles tentatives, journalisation, supervision et reprise humaine. Les prix externes sont versionnés à la date de la simulation ; les mesures locales incluent amortissement, capacité réservée et exploitation. L’article sur le coût, la latence et les pics d’inférence détaille le dimensionnement de la capacité.

La latence est mesurée par percentile et par route. Une cascade augmente le temps des demandes escaladées, même si sa médiane paraît faible. Le tableau de bord distingue attente, préparation, première exécution, validation et recours. Cette décomposition permet de savoir si le routeur, le fournisseur ou la file humaine crée le délai.

Mesure	Calcul de recette	Piège à éviter
Coût complet	somme de toutes les étapes divisée par les demandes reçues	ignorer échecs et reprise humaine
Qualité contrainte	erreurs par gravité sur demandes acceptées	moyenne unique sur tâches différentes
Couverture	part réellement terminée par chaque route	compter une sortie rejetée comme traitée
Latence	p50, p95 et p99 par issue et segment	publier seulement la moyenne
Escalade	part, motif, seconde issue et délai total	masquer les doubles appels

Scénario synthétique : orienter des messages de sinistre

Scénario pédagogique, sans résultat de production. Un flux reçoit des messages associés à un dossier existant. L’objectif n’est pas de décider une indemnisation. Il consiste à reconnaître quelques intentions administratives, extraire les références présentes et préparer une orientation pour un gestionnaire.

La règle écarte d’abord les messages sans dossier, les langues non couvertes et les pièces protégées par une politique spécifique. Une route compacte traite les intentions courantes définies par la taxonomie. Sa sortie doit respecter un schéma et citer les segments du message qui soutiennent les champs. Les sorties invalides, les intentions multiples et les termes contradictoires sont escaladés.

Le recours n’est pas automatiquement un grand modèle. Une référence manquante déclenche une demande structurée ; une pièce illisible rejoint une file Document AI ; un message émotionnel ou ambigu va à une personne ; une formulation complexe mais autorisée peut être préparée par un modèle plus généraliste. Le routeur choisit une procédure adaptée au motif d’échec.

La recette contient notamment des négations, corrections, numéros ressemblants, citations d’un ancien message et pièces annoncées mais absentes. Les annotateurs indiquent l’intention admissible, les champs présents, le degré de gravité d’une erreur et la voie acceptable. Aucun seuil ni gain n’est inventé ici : ils doivent venir de la distribution, du coût réel et des décisions du propriétaire métier.

Passer de l’évaluation hors ligne au pilote

1. Geler les contrats. Versionner tâches, routes, exclusions, jeux et grille de gravité.
2. Mesurer chaque route. Évaluer les candidats séparément avant de créditer le routeur.
3. Comparer les politiques. Politique simple, cascade et routeur appris utilisent les mêmes demandes.
4. Tester les contraintes. Droits, région, budgets et impact doivent bloquer une route même si elle serait préférée.
5. Faire des ablations. Retirer un signal ou un validateur pour comprendre sa contribution et son risque.
6. Rejouer les échecs. Vérifier les routes, motifs, versions et issues sur les cas critiques.
7. Observer en mode silencieux. Le routeur propose sans influencer le traitement réel ; les désaccords sont relus.
8. Ouvrir par palier. Limiter tâche, population et volume ; conserver un groupe de référence et un coupe-circuit.

Une comparaison en ligne peut devenir trompeuse si les politiques ne voient pas les mêmes cas. Le mode silencieux permet une première comparaison commune. Après ouverture, des échantillons aléatoires et des demandes sentinelles servent à détecter la dérive, sans envoyer un dossier vers une route inéligible pour les besoins d’une expérimentation.

Le dossier de passage contient les résultats par segment, les intervalles ou volumes, les erreurs graves, le coût complet, les percentiles de délai et la liste des limites. Une amélioration de coût n’autorise pas le déploiement si un seuil de qualité, de droits ou d’impact échoue. La feuille de route AI Act pour l’assurance complète ce dossier sans remplacer l’analyse juridique du système concerné.

Exploiter, versionner et revenir en arrière

Le journal de routage conserve identifiant de demande, version de politique, signaux non sensibles nécessaires, routes admissibles, route choisie, motif, validateur, escalade et issue. Les contenus restent dans les systèmes prévus ; le journal ne devient pas un entrepôt secondaire de courriers et de documents.

Une mise à jour de modèle, de prix, de prompt, de taxonomie ou de règle crée une nouvelle version de route. Les résultats historiques restent attribuables à leur version. Le déploiement progressif compare les distributions de routes, la qualité, les coûts et les erreurs graves. Une hausse soudaine d’escalades est un incident même si le service répond encore.

Le mode de secours est testé : règles statiques, route unique sûre ou traitement humain selon la tâche. Le coupe-circuit peut viser une route, un fournisseur, une population ou toute politique apprise. Le retour arrière ne doit pas dépendre du modèle indisponible qu’il cherche précisément à contourner.

Le cadre NIST AI RMF organise la gestion du risque autour des fonctions Govern, Map, Measure et Manage. Son profil consacré à l’IA générative précise des risques et actions à contextualiser. Il ne certifie pas une architecture particulière, mais fournit un langage utile pour relier propriétaires, mesures, événements et réponses.

Sources et références primaires

• RouteLLM: Learning to Route LLMs with Preference Data — méthode de recherche et évaluations propres au protocole des auteurs.
• FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance — étude primaire de stratégies de sélection et cascade.
• Language Models (Mostly) Know What They Know — recherche sur prédictions et confiance ; aucune calibration assurance n’en est déduite.
• NIST AI Risk Management Framework et profil Generative AI — documents officiels de gestion du risque.
• Règlement (UE) 2024/1689 — texte officiel ; l’applicabilité à un système donné nécessite une analyse juridique et factuelle.