Un assistant de documentation peut cesser de répondre dans le délai imparti après une modification de routine du système de récupération, alors que le modèle reste inchangé, que le service fonctionne correctement et que les contrôles de déploiement réussissent. La raison est que la modification peut envoyer un contexte plus volumineux au modèle, prolonger la génération et accroître l’accumulation des requêtes devant le serveur d’inférence, tandis que le retour arrière du conteneur de l’application ne restaure pas les paramètres de récupération qui ont été modifiés ailleurs.
Ce scénario hypothétique illustre un problème concret de l’exploitation des applications d’IA : qu’est-ce qui a réellement été déployé ? Dans les applications génératives, le comportement du système n’est pas déterminé par la seule version du modèle ; les entrées, le prétraitement, les prompts, l’index, les modèles d’embedding, les contrats des outils et les paramètres du service peuvent chacun changer séparément.
Définir clairement les limites de la version
L’article propose de commencer par une déclaration de version contrôlée qui conserve les références de tous les composants testés ensemble. Elle peut inclure l’identifiant de version, la version de l’application, la version du modèle, la version du prompt, la version de l’index, la version de l’embedding, le pipeline de segmentation et de reranking, les paramètres d’exécution, le jeu d’évaluation, ainsi que la version précédente.
Ces références doivent pointer vers des paramètres ou des artefacts conservés et vérifiables, tandis que les références aux secrets doivent être stockées à la place de leurs valeurs. La version d’exécution devrait couvrir les limites de tokens, le regroupement, les délais d’attente et l’allocation des ressources. Quant aux applications qui appellent des outils, elles doivent inclure les versions des schémas d’outils et des adaptateurs.
Cette déclaration ne garantit pas une reproductibilité exacte : les services externes peuvent changer, la génération peut rester non déterministe et certains fournisseurs ne proposent pas d’instantanés de modèle immuables. Il faut donc consigner ces limites, ainsi qu’un point dans le temps pour la capture des données et les paramètres d’indexation lorsque les données changent continuellement. Mettre à jour successivement plusieurs magasins de configuration ne constitue pas une version atomique.
Tester la tâche complète, et pas seulement l’appel au modèle
La réussite d’une requête HTTP ne signifie pas que l’utilisateur a obtenu une réponse correcte. La passerelle d’évaluation doit mesurer les tâches du produit lui-même, comme citer une source accessible, respecter la bonne version du produit et s’abstenir d’inventer des instructions en l’absence de preuves.
L’article recommande un jeu de données versionné comprenant les questions ordinaires, les échecs antérieurs, les demandes ambiguës, les cas dépourvus de preuves et les tentatives de dépassement des limites d’autorisation, tout en conservant un jeu qui n’a pas été utilisé pour l’ajustement. Des contrôles déterministes peuvent être appliqués à la validité du schéma, aux arguments des outils, aux identifiants de citation et à l’application des autorisations. Les jugements sémantiques nécessitent quant à eux un critère clair et une revue humaine ; le jugement d’un autre modèle peut aider à classer les cas, mais il ne constitue pas une vérité de référence.
La version doit être exécutée sur l’ensemble du parcours, de la récupération à la génération et à la validation des sorties, puis les résultats doivent être examinés par segments importants de la tâche, comme la longueur des entrées, les langues, les versions des produits et les situations où les preuves sont rares. Il faut également définir les critères d’acceptation avant de voir la version candidate, notamment l’absence de toute violation des autorisations, les limites de dégradation de la qualité et les budgets de temps de réponse et de coût.
Mesurer la charge de travail et le coût tels que les perçoit l’utilisateur
Tester le nombre de requêtes par seconde ne suffit pas. Les tests doivent être répartis selon les longueurs des entrées et des sorties, les niveaux de concurrence, les pics d’accès et le comportement de la mémoire chaude et froide. Pour les réponses en flux, il faut distinguer le délai d’apparition du premier token, le débit des tokens suivants et le délai d’achèvement, tout en mesurant le temps d’attente dans la file.
L’article recommande de commencer par des traces complètes de la requête, puis d’examiner la récupération, le reranking, les files d’attente, les phases de préremplissage et de génération, ainsi que les appels ultérieurs. Il ne faut pas additionner des percentiles provenant de différentes étapes pour les considérer comme un percentile global ; chaque mesure peut décrire des requêtes différentes.
La même identité doit également être associée à la version dans les traces et les journaux de requêtes structurés, et il faut suivre la qualité, les distributions des temps de réponse, les erreurs, l’utilisation des tokens et les taux de basculement vers des parcours alternatifs. Un coût inférieur par requête ne signifie pas nécessairement un coût inférieur pour la tâche achevée ; l’article propose donc de calculer le coût de la tâche réussie, en comptabilisant les tentatives échouées et en indiquant clairement lorsque des indicateurs indirects du succès sont utilisés.
Le retour arrière restaure les dépendances, pas seulement les poids du modèle
La version candidate peut être proposée à une proportion limitée du trafic tout en maintenant la version actuelle disponible, mais la réussite du test progressif exige de comparer les signaux de la candidate et du contrôle, et de garantir qu’elle est exposée aux segments de charge importants. Le responsable de la décision, les conditions d’arrêt, la durée minimale d’observation et la procédure de restauration doivent être définis avant le début du déploiement.
Si la version candidate remplace sur place l’index de récupération, il ne suffira pas de rediriger les requêtes vers une ancienne image de l’application. Il faut conserver des versions compatibles des index ou concevoir une migration réversible, en tenant compte des opérations de suppression et de révocation des autorisations en cours. Il faut également définir une politique de drainage ou d’annulation des générations en cours et protéger les effets secondaires des outils, comme l’envoi d’e-mails ou la modification d’enregistrements, au moyen de l’idempotence et de limites d’approbation appropriées.
Pourquoi cette approche est-elle importante ?
La valeur concrète de ces recommandations est qu’elles déplacent la gestion des applications d’IA de la question « Quel modèle utilisons-nous ? » vers une question plus large : est-il possible d’identifier la version complète qui a produit une mauvaise réponse, puis de restaurer une version connue et compatible ? Cela signifie que le minimum utile peut résider dans un dépôt existant et se composer d’une déclaration de version, d’une tâche d’évaluation, d’un test de charge représentatif, de traces associées à la version et d’une formation réelle au retour arrière.
Les limites sont également claires : réussir un ensemble limité de tests ne prouve pas l’absence de failles de sécurité ou d’échecs rares, et les retours de production sont sélectifs et ne reflètent pas toujours l’exactitude de la réponse. La revue humaine et la définition des responsabilités aux points de contact entre l’application, la plateforme et les données restent donc des éléments de l’architecture opérationnelle, et non de simples ajouts pouvant être entièrement automatisés.