Évaluations gérées par passerelle pour la sélection de modèles d'IA : favorisez des modèles moins chers ou plus rapides sans régressions silencieuses

Les équipes n'interrompent généralement pas les flux de travail de l'IA en remplaçant un modèle par un modèle manifestement mauvais. Ils les brisent en effectuant un changement de routage raisonnable qui semble moins cher, plus rapide ou plus disponible, puis en découvrant plus tard que les résumés sont moins fidèles, que les appels d'outils sont mal formés ou que le comportement de refus a changé pour une charge de travail de locataire petite mais importante.

La réponse pratique consiste à traiter les résultats d'évaluation comme un artefact de promotion à l'intérieur de la passerelle. Avant qu'un alias de modèle, un profil de locataire ou une politique de routage pointe vers un nouveau candidat, la passerelle doit être en mesure d'afficher quel ensemble de données a été utilisé, quels évaluateurs ont été exécutés, comment le candidat se compare à la référence actuelle, quel a été l'impact sur le coût et la latence, qui a approuvé la modification et comment l'annuler.

Cet article décrit un modèle de référence pour les évaluations gérées par la passerelle pour la sélection de modèles d'IA. Il se concentre sur le contrôle de la production, et non sur la recherche de références.

Faits, recommandations et prévisions

Faits : Les outils d'évaluation modernes peuvent définir des ensembles de données d'évaluation réutilisables, exécuter plusieurs configurations de modèles et renvoyer des résultats d'évaluation au niveau de sortie, un statut de réussite, un nombre de jetons et des métriques globales. Les types d'évaluateurs courants incluent les vérifications de chaînes exactes, les métriques de similarité, les vérifications de schéma ou de calcul et les évaluateurs basés sur un modèle. L'évaluation par paires peut comparer les réponses des candidats par rapport à une référence, tandis que l'évaluation ponctuelle note une réponse par rapport à une rubrique ou à une réponse attendue.

Recommandations : Utilisez des évaluateurs déterministes partout où la tâche a un contrat clair, comme un JSON valide, des champs obligatoires, des étiquettes autorisées, la forme de l'argument de l'outil, la présence d'une citation, une catégorie de refus ou une tolérance numérique. Utilisez des juges basés sur des modèles pour une qualité illimitée uniquement après les avoir comparés à un petit ensemble évalué par des humains. Ne promouvez pas un modèle à partir d’un seul référentiel public ; faites-en la promotion à partir de preuves liées à vos propres traces, locataires, outils, budgets et modes de défaillance.

Prédictions : la promotion du modèle passera des décisions d'application ad hoc aux plans de contrôle de passerelle, car les passerelles contiennent déjà le catalogue de modèles, les règles de routage, les traces d'utilisation, les politiques de locataire et les données de facturation nécessaires pour rendre les modifications du modèle vérifiables. Les équipes qui séparent les évaluations du routage exécuteront toujours des tests, mais elles auront du mal à prouver quelles preuves soutiennent un changement d'alias en direct.

Le problème du lecteur : les modifications de routage nécessitent des preuves

Une API multimodèle facilite la modification du modèle cible. C’est utile, mais cela crée aussi un problème de contrôle. Une équipe peut vouloir remplacer un modèle de résumé de support coûteux par un modèle moins coûteux, ajouter un modèle de secours pour la disponibilité, déplacer les tâches de codage vers un modèle plus rapide ou acheminer les locataires de faible priorité vers un niveau moins coûteux.

Chaque changement a un profil de risque différent. Un synthétiseur moins cher peut omettre les détails de l'escalade. Un classificateur plus rapide peut mal gérer les étiquettes rares. Un modèle de secours peut utiliser un format d'appel d'outil différent. Un modèle de raisonnement plus récent pourrait améliorer les cas difficiles tout en augmentant la latence p95. Les notes de version des fournisseurs et les classements publics ne peuvent pas déterminer si ces compromis sont acceptables pour une application spécifique.

La passerelle est l'endroit naturel pour combler cet écart, car elle voit les demandes, les réponses, les locataires, les clés, les alias, les coûts, la latence, les taux d'erreur, les appels d'outils et les décisions politiques. Les évaluations gérées par la passerelle transforment ce contexte opérationnel en un workflow de promotion reproductible.

Architecture de référence

Une architecture pratique comporte sept parties :

1. Échantillonneur de traces : sélectionne les éléments d'évaluation des candidats dans le trafic de production, les demandes ayant échoué, les demandes coûteuses, les échantillons approuvés par les locataires et les cas extrêmes connus.
2. Caviardage et contrôles de consentement : supprime ou masque les champs sensibles, applique la journalisation et la rétention des locataires. et bloque les échantillons qui ne peuvent pas être utilisés pour les évaluations.
3. Registre des ensembles de données d'évaluation : stocke les versions immuables des ensembles de données avec le type de tâche, la portée du locataire, la version du modèle d'invite, la version du schéma de l'outil, les résultats attendus lorsqu'ils sont disponibles et la provenance.
4. L'exécuteur de modèle candidat : relit les éléments de l'ensemble de données par rapport à la référence actuelle et à un ou plusieurs modèles candidats à l'aide de paramètres contrôlés.
5. Évaluateurs : appliquer vérifications déterministes, métriques basées sur le calcul et jugement calibré basé sur un modèle.
6. Enregistrement de la décision de promotion : capture l'ID d'exécution d'évaluation, la version de l'ensemble de données, l'ID du modèle de base, l'ID du modèle candidat, les versions de l'évaluateur, les seuils, les résultats, le propriétaire, l'approbation et la cible d'annulation.
7. Mise à jour de l'alias ou de la politique de routage : met à jour la passerelle en direct uniquement une fois que la décision de promotion a atteint le niveau requis. gates.

Cela maintient les évaluations connectées au déploiement. L'exécution d'évaluation n'est pas un rapport collé par quelqu'un dans un fil de discussion.Il s'agit d'un objet de plan de contrôle requis avant de modifier un alias tel que support-fast, coding-default ou summarize-cheap.

Créer trois classes d'ensemble de données

1. Cas de régression en or

Les cas en or sont des exemples sélectionnés avec des réponses attendues ou des critères de réussite stricts. Ils sont suffisamment petits pour être examinés manuellement et suffisamment stables pour être exécutés sur chaque promotion proposée.

Utilisez-les pour des tâches avec des contrats clairs : classification, extraction, résumés structurés, décisions politiques, sélection d'outils, étiquettes de routage et comportement de refus. Un élément clé doit inclure l'entrée, la sortie ou la rubrique attendue, la variation autorisée, les métadonnées de la tâche et tous les schémas d'outils nécessaires pour reproduire l'appel.

Exemples de champs :

{
  "dataset_item_id": "support-summary-0421",
  "task": "support_summary",
  "tenant_scope": "shared_redacted",
  "input_messages": [...],
  "expected_schema": "support_summary_v3",
  "required_facts": ["refund_requested", "order_id_present", "escalation_reason"],
  "disallowed_content": ["invented_refund_status"],
  "prompt_template_version": "support_summary_prompt_2026_08_14"

2. Cas extrêmes dérivés de la production

Les cas dérivés de la production détectent les échecs que les tests synthétiques manquent généralement. Les bonnes sources incluent les requêtes coûteuses, les tentatives, les remplacements manuels, les corrections utilisateur, les sorties du classificateur peu fiables, les échecs de schéma, les appels à contexte long, les requêtes proches des limites de latence et les flux de travail de locataire avec une utilisation inhabituelle des outils.

La règle de confidentialité est simple : les traces de production ne sont utiles que si elles sont autorisées. La passerelle doit appliquer le consentement du locataire, la politique de conservation des données, la rédaction et les contraintes de résidence avant qu'une trace n'entre dans un ensemble de données d'évaluation. Les locataires sensibles peuvent avoir besoin d'une exécution d'évaluation dans l'environnement, d'équivalents synthétiques ou de traces rédigées qui suppriment les invites et les identifiants bruts.

3. Cas contradictoires et politiques

Les cas contradictoires testent les comportements qui échouent sous la pression : mauvaise utilisation d'un outil, injection rapide, divulgation dangereuse, limites de refus, conflits d'instructions cachés, fichiers mal formés, citations invalides et demandes d'utilisateurs ambiguës. Ces cas n’ont pas besoin d’être dramatiques. Ils doivent représenter la manière dont vos applications peuvent causer des dommages lorsqu'un modèle devient trop permissif, trop obéissant ou trop imprudent.

Pour les workflows agents, incluez des historiques complets de messages et le contexte des appels d'outils, et pas seulement des invites à tour unique. Un candidat qui répond bien à une question à tour unique peut quand même échouer s'il doit inspecter les résultats de l'outil, préserver les limites d'autorité et produire des arguments valables pour une action en aval.

Utilisez d'abord les évaluateurs déterministes

Commencez avec des évaluateurs qui ne nécessitent pas de jugement. Ils sont moins chers, plus rapides, plus faciles à déboguer et moins susceptibles de dériver.

Les contrôles déterministes utiles incluent :

• JSON analyse avec succès et correspond au schéma requis.
• Les champs obligatoires sont présents et aucun champ interdit n'apparaît.
• La sortie de classification est l'une des étiquettes autorisées.
• La réponse numérique s'inscrit dans une tolérance acceptée.
• Le nom de l'outil est autorisé pour le locataire et workflow.
• Les arguments de l'outil passent la validation du schéma et les contrôles de politique.
• La réponse inclut les citations ou les identifiants de source requis.
• La réponse n'inclut pas les expressions interdites connues, les secrets ou les marqueurs internes.
• La catégorie de refus correspond au résultat politique attendu.

Ces vérifications doivent être des portes de promotion strictes. Si un candidat ne peut pas produire un résultat structuré valide ou des appels d'outils sûrs, une bonne note d'écriture ouverte ne devrait pas le sauver.

Utilisez soigneusement les juges basés sur des modèles

Les tâches ouvertes nécessitent toujours un jugement de qualité. Les résumés peuvent être fidèles mais pas exacts. Les réponses d'assistance peuvent nécessiter du ton, de l'exhaustivité et de l'alignement des politiques. L'aide au codage peut nécessiter une comparaison par paire avec une réponse de base.

Les juges basés sur des modèles sont utiles pour cette couche, mais ils ne doivent pas être traités comme une vérité objective. Calibrez-les par rapport à un petit échantillon évalué par des humains avant de bloquer ou d’approuver les modifications de production. Vérifiez si le juge est d'accord avec les étiquettes humaines assez souvent pour le niveau de risque du flux de travail.Pour les juges par paires, surveillez les biais de position, la préférence de verbosité et l'incapacité de remarquer que les deux réponses sont inacceptables.

Une rubrique pratique de juge pour le résumé de l'assistance pourrait marquer :

• Fidélité : Le résumé évite-t-il d'ajouter des faits non présents dans la conversation ?
• Exhaustivité : Inclut-il le problème du client, l'action demandée, les détails de la commande pertinents, etc. étape ?
• Actionnabilité : un agent peut-il l'utiliser sans relire l'intégralité du fil de discussion ?
• Ajustement à la politique : évite-t-il de promettre des remboursements, des crédits ou des escalades qui n'ont pas été approuvés ?

Pour la promotion, combinez les scores minimum par point avec une comparaison par paire. Le taux de victoire par paire est utile lors du remplacement d'une ligne de base, mais il peut masquer des échecs absolus si les deux réponses sont mauvaises. Un candidat doit satisfaire aux critères minimum de réussite/d'échec avant que la qualité par paire ne décide si elle est meilleure, équivalente ou pire que le modèle actuel.

Définir une carte de score de promotion

Une carte de score de promotion de passerelle doit combiner qualité, latence, coût et sécurité opérationnelle. Les seuils exacts dépendent de la charge de travail, mais le tableau de bord doit être explicite avant le début de l'exécution.

Pour chaque modèle candidat, suivez :

• Taux de réussite de la qualité : le pourcentage d'éléments de l'ensemble de données réussissant les étapes déterministes et les rubriques requises.
• Taux de victoire par paire : candidat par rapport à la référence actuelle sur la qualité ouverte.
• Latence p95 : mesurée sous une passerelle représentative. paramètres.
• Coût estimé par tâche réussie : coût total estimé divisé par les sorties acceptées, et non par les appels bruts.
• Validité des sorties structurées : taux de réussite des schémas et taux de réparation.
• Validité des appels d'outils : utilisation autorisée de l'outil, arguments valides et sélection d'actions conformes à la politique.
• Échecs de sécurité ou de politique : refus, achèvements dangereux, marqueurs de fuite de données ou violations de la politique des locataires.
• Compatibilité opérationnelle : comportement de streaming, séquences d'arrêt, limites de jetons, délais d'attente et champs de réponse spécifiques au fournisseur.

Le coût par tâche réussie compte plus que le coût par jeton. Un modèle moins cher qui échoue à la validation du schéma dans 12 % des cas peut devenir plus coûteux après de nouvelles tentatives, des réparations, une révision manuelle et des escalades de support. La passerelle dispose des analyses de facturation et d'utilisation nécessaires pour calculer cela correctement.

Exemple : Remplacement d'un modèle de synthèse du support

Supposons que l'alias actuel support-fast pointe vers un modèle coûteux utilisé pour résumer les conversations des clients dans un objet JSON strict. L'équipe souhaite promouvoir un candidat moins cher.

Le flux de travail de promotion pourrait ressembler à ceci :

1. Créer une version d'ensemble de données support_summary_eval_2026_09_02 avec 200 cas privilégiés, 300 cas limites de production expurgés et 100 cas de politique contradictoires.
2. Exécuter la référence actuelle et le candidat le moins cher avec le même modèle d'invite, le même schéma, jetons de sortie maximum et disponibilité des outils.
3. Appliquez des portes déterministes : validité JSON à 99 % ou plus, couverture des faits requise à 97 % ou plus, aucune promesse de remboursement interdite et aucune action d'outil invalide.
4. Appliquez le jugement par paire basé sur un modèle uniquement aux éléments qui réussissent les contrôles déterministes.
5. Exigez que le candidat ne perde pas plus d'une marge de qualité définie par rapport à la ligne de base, reste en dessous du budget de latence p95 actuel et réduit coût estimé par résumé accepté.
6. Enregistrez l'ID d'exécution d'évaluation, la version de l'ensemble de données, les versions de l'évaluateur, l'ID du modèle candidat, l'ID du modèle de base, les seuils, l'approbateur et la cible de l'alias d'annulation.
7. Canaries l'alias d'un groupe de locataires limité, surveillez les échecs de schéma en direct et prenez en charge les corrections, puis développez ou annulez.

Le point clé est que le candidat n'est pas accepté car il est moins cher. Il n'est accepté que si les preuves d'évaluation montrent que le modèle le moins cher reste dans le contrat de tâche.

Rendre les enregistrements de promotion immuables

La passerelle doit conserver suffisamment de détails pour répondre à une question d'incident ultérieure : pourquoi ce modèle a-t-il été promu ?

Un enregistrement de décision de promotion doit inclure :

• ID de promotion et ID d'exécution d'évaluation immuable.
• ID de l'ensemble de données, version de l'ensemble de données et provenance de l'ensemble de données.
• Référence de référence ID de modèle et ID de modèle candidat.
• Version du modèle d'invite et jeu de paramètres.
• Versions de schéma d'outil et contraintes de routage.
• Noms, versions, seuils et notes d'étalonnage des évaluateurs.
• Résultats agrégés et références d'éléments défaillants.
• Estimations des coûts et de la latence.
• Portée du locataire et portée du déploiement.
• Approbateur, horodatage et restauration. target.

Ceci est particulièrement important pour les alias.Si les équipes d'application appellent support-fast au lieu d'un identifiant de modèle de fournisseur, elles gagnent en stabilité, mais la passerelle a désormais le devoir de prouver que les changements d'alias ont été régis.

Contrôles de confidentialité et de rétention

Les évaluations de trace de production introduisent des obligations de confidentialité. Un échantillonneur de trace ne doit jamais contourner la stratégie du locataire simplement parce que les évaluations sont internes. Avant de stocker ou d'exporter un élément d'évaluation, vérifiez si les invites brutes peuvent être conservées, si les outils d'évaluation hébergés par le fournisseur sont autorisés, si les données doivent rester dans une région spécifique et si l'échantillon contient des secrets, des données réglementées ou des identifiants client.

Pour les charges de travail sensibles, utilisez l'un des trois modèles les plus sûrs :

• Exécutez des évaluations dans l'environnement de passerelle sans envoyer de traces brutes aux produits d'évaluation hébergés.
• Utilisez des traces rédigées qui préservent la structure et mode de défaillance mais supprimez les champs sensibles.
• Créez des cas synthétiques à partir de modèles de défaillance observés sans copier le contenu de production.

Le compromis est réel. Les évaluations dérivées de la production détectent les régressions spécifiques à la charge de travail. Les évaluations synthétiques réduisent l’exposition. La plupart des équipes ont besoin des deux.

Liste de contrôle de mise en œuvre

• Définissez la promotion du modèle comme un flux de travail de plan de contrôle, et non comme un exercice de bloc-notes.
• Ensembles de données de version, invites, schémas d'outils, évaluateurs et seuils.
• Séparez les cas privilégiés, dérivés de la production et contradictoires.
• Exécutez des évaluateurs déterministes avant les cas basés sur un modèle. juges.
• Calibrez les juges par rapport à des échantillons évalués par des humains pour des workflows à fort impact.
• Mesurez le coût par tâche acceptée, et pas seulement le coût par jeton.
• Exigez des cibles de restauration avant les modifications d'alias ou de politique de routage.
• Conservez les enregistrements de promotion pour l'audit et l'examen des incidents.
• Respectez le consentement des locataires, la rétention et les contraintes de résidence pour les évaluations basées sur la trace.
• Surveillez les canaris en direct, car Les évaluations réduisent les risques mais ne les éliminent pas.

Conclusion

La sélection du modèle d'IA ne doit pas dépendre de tests de performances publics, de notes de version ou d'une comparaison manuelle d'un seul développeur. Dans une passerelle API multimodèle, les modifications du modèle affectent les locataires, les budgets, la latence, le comportement des outils, les sorties structurées et la politique de sécurité. Cela fait des évaluations un élément de la gouvernance de la production.

Le modèle exploitable est simple : échantillonnez des traces représentatives, rédigez-les et filtrez-les par politique, versionnez l'ensemble de données d'évaluation, exécutez la ligne de base et les candidats, notez d'abord avec des contrôles déterministes, utilisez des juges calibrés pour une qualité illimitée, combinez la qualité avec la latence et le coût, et exigez un enregistrement de promotion immuable avant de modifier les alias ou les règles de routage.

Le résultat n'est pas une adoption du modèle plus lente. C’est l’adoption d’un modèle avec des preuves. Les candidats les moins chers et les plus rapides peuvent toujours passer à la production, mais ils doivent prouver que les économies ne proviennent pas d'une régression silencieuse des tâches.

Lecture connexe

• alias de modèles internes et promotion prête pour le rollback
• runbooks de tests de dépréciation de modèles et de migration
• traces de passerelle et journalisation sécurisée des invites