Contexte et objectifs
GitHub utilise un modèle de langage pour analyser les dépôts et identifier les chaînes qui ressemblent à des secrets (tokens, clés). Le problème principal n’est pas la capacité du modèle à classer correctement chaque chaîne, mais la capacité du système global à diminuer les alertes inutiles tout en conservant un taux de rappel suffisant pour ne pas laisser passer de véritables credentials. Cette double exigence impose de séparer les métriques de précision (réduction des faux positifs) des contraintes de sécurité (rappel minimal).
Méthodologie d’évaluation
Les équipes ont structuré l’évaluation en trois niveaux : résultat principal (précision et réduction des faux positifs), contrainte de sécurité (rappel) et garde‑fous opérationnels (latence, coût, fiabilité, compatibilité production). Chaque expérience doit répondre à la question : « Le nouveau paramètre améliore‑t‑il le résultat principal sans violer les contraintes ? ». Pour garantir la traçabilité, chaque run enregistre le prompt, le modèle, la version du jeu de données et la configuration du pipeline. Les changements sont appliqués un à un : d’abord le prompt, ensuite le modèle, puis la construction du contexte. Cette approche empêche l’attribution erronée d’une amélioration à un facteur non testé.
Gestion des métriques et garde‑fous
La précision est maximisée tant que le rappel reste dans une fourchette prédéfinie (par exemple, une baisse de moins de 2 % par rapport au seuil de sécurité). Les métriques opérationnelles sont quantifiées : la latence cible est de l’ordre de quelques centaines de millisecondes, le coût par appel doit rester sous un centime, et le taux d’erreur du pipeline ne doit pas dépasser 0,1 %. Si une modification améliore la précision mais augmente la latence au point de dépasser le seuil, elle est rejetée. De même, une amélioration du coût qui entraîne une perte de rappel critique est également écartée.
Intégration continue et suivi des changements
Le processus d’évaluation est intégré au pipeline CI/CD comme un test d’intégration de bout en bout. À chaque modification du code, du prompt ou du modèle, le test est relancé et les résultats sont comparés à un baseline stocké. Le tableau de suivi (hypothétique dans l’article) montre les valeurs de précision, rappel, latence et coût pour chaque version, permettant d’isoler rapidement les régressions. Les prompts et les configurations sont versionnés dans un dépôt Git, ce qui rend possible le rollback instantané en cas de dégradation. Enfin, les équipes planifient des tests réguliers de mise à jour de modèle afin de détecter les variations de comportement liées aux nouvelles itérations du LLM, même lorsque les performances offline semblent stables.
