L'intégration de grands modèles de langage (LLM) dans les applications de production introduit un défi unique : le modèle est non déterministe. Contrairement au logiciel traditionnel, où un test passe ou échoue en fonction d'une logique stricte, les sorties des LLM peuvent varier légèrement à chaque exécution tout en restant « correctes », ou se dégrader subtilement en qualité en raison de petits ajustements du prompt. Sans tests rigoureux, ces changements subtils — souvent appelés dérive des prompts — peuvent entraîner des pannes silencieuses, une diminution de la confiance des utilisateurs et une augmentation des coûts opérationnels.
Cet article explore comment mettre en œuvre un flux de travail de tests de régression robuste pour les prompts LLM à l'aide de Braintrust, une plateforme conçue spécifiquement pour l'observabilité et l'évaluation des LLM. Nous démontrerons comment intégrer ce processus directement dans votre pipeline CI/CD pour vous assurer que chaque modification de prompt est validée par rapport à un référentiel standardisé avant le déploiement.
Pourquoi les tests unitaires traditionnels échouent pour les LLM
Les tests unitaires traditionnels reposent sur des correspondances exactes. Pour un LLM, vérifier si la sortie est égale à "The weather is sunny." est fragile. Une légère reformulation en "It’s a sunny day." devrait passer, mais un test traditionnel la marquerait comme échouée. De plus, les LLM sont sensibles au contexte, aux paramètres de température et même à la version spécifique du modèle sous-jacent. Si vous mettez à jour votre modèle de base de GPT-4 à une version plus récente, ou si vous ajustez votre prompt système pour plus de clarté, vous risquez de casser des cas limites que les tests précédents ne couvraient pas.
Les tests de régression dans le contexte des LLM nécessitent des tests basés sur l'évaluation. Au lieu de vérifier des chaînes de caractères exactes, nous utilisons des fonctions de notation qui évaluent la justesse sémantique, la sécurité et le format de la réponse. Braintrust vous permet de définir ces évaluateurs une fois et de les réexécuter sur l'ensemble de votre jeu de données chaque fois que le prompt change.
Mise en place du flux d'évaluation Braintrust
D'abord, vous devez définir votre logique d'évaluation. Braintrust fournit un SDK Python qui rend cela simple. Le concept central consiste à créer une Task qui associe les prompts d'entrée aux réponses du modèle et applique une fonction de notation.
Ci-dessous, un exemple pratique d'un script d'évaluation, evals.py, qui teste un prompt de résumés. Il vérifie deux métriques : Précision (contient-il des faits clés ?) et Ton (est-il professionnel ?).
import braintrust
from braintrust import Task, Eval
from my_app.llm import generate_summary
# Définir la fonction de notation
def score(output, input, metadata):
# Utiliser un LLM juge ou une heuristique pour noter la sortie
accuracy = check_factuality(output, input['expected_facts'])
tone = check_tone(output)
return {
"accuracy": accuracy,
"tone": tone,
"pass": accuracy > 0.8 and tone > 0.7
}
# Initialiser le projet Braintrust
project = braintrust.Project("summarizer-eval")
# Créer la tâche avec la version actuelle du prompt
task = Task(
name="v2.1_prompt_update",
evals=[
Eval(
name="summarization_test",
data=[
{"input": "Long text here...", "expected_facts": ["fact1", "fact2"]},
# ... charger le jeu de données complet depuis CSV/JSON
],
query=generate_summary,
score=score
)
]
)
# Exécuter l'évaluation
result = project.create(task=task)
print(f"Evaluation ID: {result.id}")
Intégration avec CI/CD : L'étape de contrôle
Le véritable pouvoir de ce flux de travail réside dans le contrôle automatisé. Dans votre configuration GitHub Actions ou GitLab CI, vous pouvez exécuter ce script d'évaluation à chaque demande d'extraction (pull request) qui modifie le répertoire prompts/ ou le code d'appel du LLM.
Si le score moyen passe en dessous d'un seuil défini (par exemple, un taux de réussite de 90 %), le travail CI échoue, empêchant la fusion. Cela agit comme un gardien, garantissant qu'aucune régression de prompt n'atteigne la production.
# .github/workflows/llm-regression.yml
name: LLM Regression Tests
on: [pull_request]
jobs:
llm-eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: '3.10'
- name: Install dependencies
run: |
pip install -r requirements.txt
pip install braintrust
- name: Set Braintrust Token
run: |
echo "BRAINTRUST_TOKEN=${{ secrets.BRAINTRUST_TOKEN }}" >> $GITHUB_ENV
- name: Run Evaluation
run: |
python evals.py
- name: Check Pass Rate
run: |
# Script to fetch results from Braintrust API and fail if < 90% pass
python check_threshold.py --min-pass-rate 0.90
Suivi des performances en production
Bien que le CI/CD empêche les régressions avant le déploiement, la dérive des prompts peut également se produire en production en raison des changements dans la distribution des données des utilisateurs. Les fonctionnalités d'observabilité de Braintrust vous permettent de journaliser les traces de production aux côtés de vos données d'évaluation. En comparant les scores de vos évaluations hors ligne avec les scores du trafic de production en direct, vous pouvez détecter lorsque le modèle commence à avoir des difficultés avec de nouveaux types d'entrées qui n'étaient pas dans votre jeu de données de test.
Cette approche en boucle fermée garantit que vos jeux de données de test restent pertinents. Lorsque les scores de production baissent, vous pouvez identifier ces cas d'échec spécifiques, les ajouter à votre suite de tests de régression et réexécuter le pipeline CI pour vous assurer que la prochaine mise à jour du modèle ou du prompt les gère correctement.
Conclusion
L'automatisation des tests de régression pour les prompts LLM n'est plus optionnelle — c'est un composant essentiel de l'ingénierie IA fiable. En utilisant des outils comme Braintrust, les développeurs peuvent passer des tests de correspondance de chaînes fragiles à des évaluations sémantiques robustes. L'intégration de ce processus dans votre pipeline CI/CD crée un filet de sécurité qui détecte la dérive des prompts tôt, réduit le temps de débogage et offre ultimement une expérience utilisateur plus constante et digne de confiance. À mesure que les applications LLM se développent, la construction de cette infrastructure d'observabilité et de test dès le premier jour fera la différence entre un produit stable et une expérience de déploiement chaotique.