Versionnement rapide et tests de régression

Les invites contiennent de la logique : des instructions, des contraintes, des exemples et des formats de sortie qui déterminent ce que fait une application. Les traiter comme des chaînes de texte informelles conduit à des modifications non suivies et à des surprises en production. Les traiter comme du code signifie contrôler les versions, les réviser, les tests automatisés et les versions contrôlées. Ce qui nécessite une gestion des versions, c'est plus que la formulation de l'invite. La sortie dépend de la configuration complète : l'invite du système, le modèle et ses variables, quelques exemples, les schémas d'outils ou de fonctions, l'identifiant du modèle, les paramètres d'échantillonnage tels que la température et les jetons maximum, et les paramètres de récupération si des documents sont injectés. Changer l'un d'eux peut changer le comportement, donc les équipes les versionnent ensemble, souvent identifiées par un hachage de contenu, et les stockent dans git ou dans un registre d'invite. Les tests de régression nécessitent un ensemble de données d'évaluation, souvent appelé un ensemble d'or : des entrées réelles représentatives, des cas extrêmes connus et des échecs de production passés transformés en cas de test. Les évaluateurs vont du strict au flou : correspondance exacte, validation du schéma JSON, expressions régulières, vérifications basées sur le code, notation d'un juge LLM par rapport à une rubrique et examen humain périodique des échantillons. La suite s'exécute automatiquement à chaque modification et compare les résultats à la dernière référence acceptée. Les modifications de modèle sont aussi risquées que les modifications rapides. Les alias de fournisseur tels qu'un nom de modèle générique le plus récent peuvent pointer vers de nouvelles versions au fil du temps, et les anciens instantanés deviennent obsolètes. Épingler un instantané daté et réexécuter la suite avant de changer transforme la dérive silencieuse en une décision délibérée. Plusieurs idées fausses causent des problèmes. Quelques contrôles ponctuels manuels manquent de rares échecs. La température 0 réduit le caractère aléatoire mais ne garantit pas des sorties identiques d'une exécution à l'autre. Un score de juge LLM plus élevé n'est pas automatiquement meilleur, car les juges ont des préjugés tels que la préférence pour des réponses plus longues. Étant donné que les résultats varient, les bonnes suites utilisent des seuils et des échantillons répétés plutôt que d'exiger une égalité exacte des chaînes. Des outils open source tels que promptfoo, ainsi que des plateformes d'évaluation commerciales, prennent en charge ces flux de travail, mais un simple script en CI peut également fonctionner.