Évaluer la décision
Mesurer la qualité et le coût.
Évaluer la décision est une leçon AI Prompt Engineering gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AI Prompt Engineering, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AI Prompt Engineering comprend 4 leçons au total.
Impossible de décider ce que l’on ne peut pas mesurer
Le choix entre l’invite, l’ajustement et l’hybride n’est valable qu’à la hauteur de l’évaluation qui le sous-tend. Sans jeu d’évaluation figé ni modèle de coûts, toute comparaison reste une anecdote.
- La qualité et le coût sont deux axes : ne les réduisez jamais prématurément à un seul nombre
- Le jeu d’évaluation doit être mis de côté et rester stable pour toutes les approches comparées
- L’approche gagnante est celle qui occupe le meilleur point de la frontière qualité-coût compte tenu de vos contraintes
Construire d’abord le jeu d’évaluation figé
Avant toute comparaison, construisez un jeu d’évaluation indépendant sur lequel aucune approche ne s’entraîne. Il doit couvrir la distribution réelle : cas courants, cas limites connus et entrées adversariales dans des proportions proches de celles de la production.
Figez-le. Chaque approche — par invite seule, ajustée ou hybride — est évaluée sur le même jeu. Si le jeu d’évaluation change d’une comparaison à l’autre, les chiffres ne sont pas comparables et la décision n’est pas valide.
def split_eval(labeled, holdout_ratio=0.2, seed=42):
import random
rng = random.Random(seed) # fixed seed = reproducible split
data = labeled[:]
rng.shuffle(data)
cut = int(len(data) * (1 - holdout_ratio))
train, frozen_eval = data[:cut], data[cut:]
return train, frozen_eval # eval never enters any training runChoisir des métriques adaptées à la tâche
Une précision générique masque les échecs propres à la tâche. Choisissez des métriques qui mesurent réellement les éléments importants :
- Correspondance exacte avec le schéma pour les sorties structurées
- Évaluation par un LLM selon une grille pour la qualité des réponses ouvertes, avec un échantillon vérifié par un humain
- Métriques de queue — pire cas et p95, pas seulement la moyenne (mean)
- Taux de sécurité et de refus comme critères bloquants, évalués séparément de la qualité
Un score moyen (mean) qui masque une queue catastrophique vous conduira à la mauvaise décision.
Évaluer chaque candidat de manière identique
Lancez (run) les approches par invite seule, ajustée et hybride avec le même évaluateur sur le même jeu figé. Notez la qualité ainsi que le vecteur complet des coûts pour chacune, afin d’obtenir une comparaison réellement homogène.
def evaluate(candidate, frozen_eval, scorer):
results = []
for ex in frozen_eval:
out = candidate.run(ex['input'])
results.append(scorer(out, ex['label']))
mean = sum(results) / len(results)
p95 = sorted(results)[int(0.95 * len(results)) - 1]
return {'mean': mean, 'p95_worst': p95}
# Identical frozen_eval + scorer for prompt / tuned / hybridModéliser le vecteur complet des coûts
Le coût ne se résume pas à un seul nombre. Mesurez chaque composante afin que la comparaison reflète la réalité à votre volume :
- Inférence par appel : jetons d’entrée + jetons de sortie multipliés par le tarif (les invites longues coûtent davantage par appel)
- Entraînement amorti : coût de l’ajustement réparti sur le volume de requêtes prévu
- Maintenance : pipeline de données, exécutions d’évaluation et réajustement lors des changements fréquents du modèle de base
- Latence : tarifée séparément lorsqu’elle affecte la conversion ou l’expérience utilisateur
def monthly_cost(calls, in_tok, out_tok, price_in, price_out,
train_cost=0.0, months_amortized=12):
inference = calls * ((in_tok/1000)*price_in + (out_tok/1000)*price_out)
amortized_train = train_cost / months_amortized
return inference + amortized_train
# Long prompt-only: high in_tok, train_cost=0
# Tuned: low in_tok, train_cost>0 amortized over volumeTracer la frontière qualité-coût
Une fois la qualité et le coût mensuel établis pour chaque candidat, placez-les sur une frontière. Un candidat est dominé si un autre présente à la fois une qualité supérieure et un coût inférieur ; éliminez les candidats dominés.
Parmi l’ensemble non dominé, le bon choix dépend de votre contrainte : choisissez l’option la moins chère qui dépasse le seuil de qualité, ou celle offrant la meilleure qualité sous le plafond de coût. La décision devient explicite et défendable, plutôt qu’une simple question de préférence.
def non_dominated(candidates):
# candidate: {'name','quality','cost'} -- higher quality, lower cost better
keep = []
for c in candidates:
dominated = any(o['quality'] >= c['quality'] and o['cost'] <= c['cost']
and o != c for o in candidates)
if not dominated:
keep.append(c)
return keepSignificativité statistique, pas du bruit
Un gain de deux points sur une évaluation de 200 exemples peut être dû au bruit. Avant de désigner un gagnant, vérifiez que l’écart de qualité est significatif sur le plan statistique compte tenu de la taille de votre évaluation.
Utilisez une comparaison appariée (les mêmes exemples avec les deux candidats) ainsi qu’un intervalle de confiance sur la différence. Si l’intervalle contient zéro, vous ne disposez pas d’une amélioration réelle et le coût supplémentaire de l’ajustement n’est pas justifié.
def paired_diff_ci(scores_a, scores_b):
import statistics
diffs = [a - b for a, b in zip(scores_a, scores_b)]
mean = statistics.mean(diffs)
sd = statistics.pstdev(diffs)
se = sd / (len(diffs) ** 0.5)
return (mean - 1.96*se, mean + 1.96*se) # if it spans 0 -> not significantSe prémunir contre la fuite dans l’évaluation
Le moyen le plus rapide de faire paraître l’ajustement artificiellement performant est la fuite : des exemples d’entraînement qui recoupent le jeu d’évaluation. Une évaluation contaminée par une fuite récompense la mémorisation et gonfle le score du candidat ajusté.
Supprimez les doublons entre les jeux d’entraînement et d’évaluation, recherchez les quasi-doublons et privilégiez une évaluation séparée dans le temps (mise de côté selon la date), afin que le modèle ajusté n’ait pas pu la voir. La fuite est la cause la plus fréquente d’une décision d’ajustement qui échoue en production.
Surveiller après le déploiement
La décision n’est pas définitive au lancement. La distribution de production évolue, et un modèle ajusté peut se dégrader silencieusement lorsque les entrées s’éloignent de sa distribution d’entraînement.
- Échantillonner le trafic en direct et l’évaluer avec la même grille
- Déclencher une alerte en cas de baisse de qualité ou de hausse progressive du coût par appel
- Relancer l’évaluation figée chaque fois que la version du modèle de base change
Traitez l’approche choisie comme une hypothèse à vérifier en continu, et non comme une décision définitive.
Consigner la décision
Consignez la comparaison dans un document de décision : le jeu d’évaluation figé, le vecteur de qualité et de coûts de chaque candidat, le résultat de l’analyse de significativité, le volume supposé ainsi que le point choisi sur la frontière et sa justification.
Votre choix devient ainsi vérifiable et réévaluable. Lorsque le volume ou le modèle de base change, vous rouvrez le document et relancez l’analyse au lieu de reprendre le débat de mémoire.
Fonction de décision de bout en bout
Assemblez le tout : évaluez chaque candidat sur le jeu figé, associez-lui son coût, éliminez les options dominées, exigez une différence significative par rapport à la référence la moins chère, puis choisissez selon votre contrainte déterminante.
def decide(candidates, quality_bar, cost_ceiling):
frontier = non_dominated(candidates)
feasible = [c for c in frontier
if c['quality'] >= quality_bar and c['cost'] <= cost_ceiling]
if not feasible:
return 'NO_CANDIDATE_MEETS_CONSTRAINTS'
# cheapest option that clears the quality bar
return min(feasible, key=lambda c: c['cost'])['name']
# Prefer prompt-only on ties: lower maintenance TCOVérification rapide
Un modèle ajusté obtient un score supérieur de 2 points à celui de l’approche par invite sur une évaluation de 150 exemples, mais un intervalle de confiance apparié sur la différence contient zéro. Il coûte également plus cher par mois. Quelle est la bonne décision ?
Récapitulatif
Décidez à partir d’une évaluation figée et d’un vecteur de coûts honnête, pas de votre intuition. La qualité et le coût sont deux axes ; la réponse est un point de la frontière qualité-coût choisi selon votre contrainte déterminante.
- Figer un seul jeu d’évaluation et y évaluer chaque candidat de manière identique
- Choisir des métriques adaptées à la tâche et surveiller la queue, pas seulement la moyenne (mean)
- Modéliser le vecteur complet des coûts et amortir l’entraînement sur le volume réel
- Exiger une significativité statistique ; un intervalle de confiance contenant zéro n’indique aucune amélioration
- Se prémunir contre les fuites dans l’évaluation — principale cause des faux succès de l’ajustement
- Surveiller après le lancement et consigner la décision afin de pouvoir la réévaluer
Questions Fréquemment Posées
La leçon « Évaluer la décision » est-elle gratuite ?
Oui — le texte complet de « Évaluer la décision » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AI Prompt Engineering, passe à CoddyKit PRO. Le cours AI Prompt Engineering comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Évaluer la décision » ?
Mesurer la qualité et le coût. Tu pratiques AI Prompt Engineering avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer AI Prompt Engineering ?
Aucune expérience préalable n'est requise. AI Prompt Engineering sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Évaluer la décision » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon AI Prompt Engineering ?
Oui. Chaque leçon AI Prompt Engineering inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Quand le prompting suffit
- Quand affiner un modèle
- Hybride : prompt et réglage léger
- Évaluer la décision