🤖 AI

Optimization before Evaluation: Evaluation with Unoptimised Prompts Can be Misleading

Ce papier soutient que les cadres d'évaluation actuels des LLM reposant sur des invites statiques sont trompeurs car l'optimisation des invites modifie considérablement le classement des modèles, rendant nécessaire une optimisation des invites par modèle pour identifier avec précision le meilleur modèle pour une tâche spécifique.

Auteurs originaux : Nicholas Sadjoli, Tim Siefken, Atin Ghosh, Yifan Mai, Daniel Dahlmeier

Publié 2026-05-01

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Nicholas Sadjoli, Tim Siefken, Atin Ghosh, Yifan Mai, Daniel Dahlmeier

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

L'idée principale : Le piège du « taille unique »

Imaginez que vous êtes un responsable de recrutement cherchant le meilleur chef pour votre restaurant. Vous avez cinq chefs différents (appelons-les Modèle A, B, C, D et E). Pour les tester, vous leur donnez à tous la même carte de recette exacte : « Préparez un ragoût. Utilisez du sel, du poivre et des oignons. »

Vous les observez cuisiner, goûtez le ragoût et les classez. Le Chef B gagne. Vous engagez le Chef B.

Le problème : Le Chef B est excellent pour suivre cette recette spécifique, mais peut-être que le Chef D est en réalité un génie qui a juste besoin que la recette soit écrite légèrement différemment pour briller. Peut-être que le Chef D a besoin que l'instruction dise : « Faites mijoter les oignons d'abord, puis ajoutez le sel » pour donner le meilleur de lui-même.

Ce papier soutient que les méthodes actuelles de test des modèles d'IA (Grands Modèles de Langage) ressemblent à ce responsable de recrutement. Ils donnent à chaque IA exactement la même invite statique (la carte de recette) et les classent en fonction de qui s'en sort le mieux avec cette carte spécifique.

Les auteurs affirment que cela est trompeur. Dans le monde réel, si vous engagez une IA, vous ne lui donneriez pas juste une invite générique ; vous ajusteriez les instructions pour obtenir les meilleures performances de cette IA spécifique. Ce papier appelle ce processus l'Optimisation des Prompts (PO).

L'expérience : Ajustez la recette, changez le gagnant

Les chercheurs ont pris cinq modèles d'IA populaires et les ont testés sur diverses tâches (comme résoudre des problèmes de mathématiques, répondre à des questions d'affaires ou extraire des données).

Round 1 (L'ancienne méthode) : Ils ont donné à chaque modèle la même invite de « base ». Ils les ont classés.
Round 2 (La nouvelle méthode) : Ils ont utilisé un outil automatisé pour « régler » l'invite pour chaque modèle individuellement. Ils ont demandé à l'IA : « Comment pouvons-nous réécrire les instructions pour que vous les compreniez le mieux ? » puis ont relancé les tests.

Le résultat : Le classement a complètement changé.

Dans certains cas, le modèle arrivé dernier au Round 1 a bondi à la première place au Round 2.
Le modèle qui était « le meilleur » dans l'ancien test n'était pas nécessairement le meilleur lorsqu'on lui donnait des instructions adaptées à son cerveau spécifique.

L'analogie : C'est comme tester des coureurs sur une piste.

Ancienne méthode : Vous faites courir tout le monde avec de lourdes bottes. Le Coureur A gagne car il est habitué aux lourdes bottes.
Nouvelle méthode : Vous donnez au Coureur A des baskets légères et au Coureur B des semelles orthopédiques sur mesure. Soudain, le Coureur B gagne.
Conclusion : Si vous ne les aviez testés qu'avec des bottes lourdes, vous auriez engagé le mauvais coureur pour un marathon.

Points clés de l'étude

1. Le modèle « meilleur » dépend de l'invite
Le papier a découvert que le « gagnant » d'une compétition change selon la façon dont les instructions sont rédigées. Si vous voulez choisir la meilleure IA pour un travail spécifique, vous devez d'abord optimiser les instructions pour cette IA spécifique. Si vous ne le faites pas, vous risquez de choisir un modèle qui est en réalité médiocre pour vos besoins.

2. Différents modèles réagissent différemment
Tout comme les humains, différentes IA ont des « personnalités » ou des sensibilités différentes.

Certains modèles (comme le Modèle B dans l'étude) étaient très sensibles aux changements d'invite. Un petit ajustement les faisait performer beaucoup mieux.
D'autres modèles étaient déjà si bons à une tâche spécifique (comme le routage simple) que l'ajustement de l'invite ne les aidait pas beaucoup, ou parfois même les confondait.

3. Le « Critique » peut se tromper
Les chercheurs ont utilisé une IA « critique » (GPT-4o) pour aider à réécrire les invites pour les autres modèles. Habituellement, cela fonctionnait très bien. Cependant, parfois le critique devenait trop malin ou les instructions devenaient trop complexes, ce qui faisait échouer le modèle.

Exemple : Dans un cas, l'invite optimisée demandait à l'IA de « réfléchir étape par étape » à tel point qu'elle a commencé à répondre aux questions d'exemple dans l'invite au lieu de la question de test réelle. C'était comme un élève qui lit les réponses du test pratique à voix haute au lieu de passer l'examen.

Ce que cela signifie pour vous (le praticien)

Si vous êtes une entreprise essayant de choisir une IA pour faire un travail (comme répondre aux e-mails clients ou analyser des documents), ne vous contentez pas de lancer un benchmark standard.

Le papier conclut que pour trouver le vrai meilleur modèle pour votre tâche spécifique, vous devez :

Prendre votre tâche.
Essayer différents modèles.
Optimiser l'invite pour chaque modèle individuellement pour voir ce dont ils sont réellement capables.
Ensuite, choisir le gagnant.

Si vous sautez l'étape 3 et utilisez simplement une invite générique, vous prenez probablement une mauvaise décision d'embauche basée sur un test trompeur.

Résumé

Le papier est un avertissement : Ne jugez pas un poisson par sa capacité à grimper à un arbre, et ne jugez pas une IA par sa capacité à suivre une invite générique. Pour savoir qui est vraiment le meilleur, vous devez parler leur langue. Si vous n'optimisez pas l'invite pour chaque modèle, vos résultats d'évaluation sont probablement faux, et vous pourriez vous retrouver avec le mauvais outil pour le travail.

1. Énoncé du problème

Les cadres d'évaluation actuels des grands modèles de langage (LLM) (par exemple, BigBench, LM Eval Harness, HELM) reposent principalement sur des modèles de prompts statiques. Dans ces cadres, un seul prompt non optimisé est appliqué uniformément à tous les modèles évalués.

Les auteurs soutiennent que cette approche est fondamentalement erronée pour le développement centré sur l'application car :

La qualité du prompt est une variable : La qualité et le style du prompt impactent considérablement les capacités d'un modèle à suivre les instructions et ses performances globales.
Des classements trompeurs : En traitant le prompt comme une constante fixe, les benchmarks échouent à capturer la performance maximale potentielle d'un modèle lorsqu'il est associé à un prompt optimisé.
Décalage avec l'industrie : Alors que les benchmarks académiques utilisent des prompts statiques, les praticiens de l'industrie utilisent régulièrement des techniques d'Optimisation de Prompt (PO) pour ajuster les prompts à des modèles et des tâches spécifiques afin de maximiser les performances.

L'hypothèse centrale est que l'évaluation des modèles avec des prompts non optimisés conduit à des classements de modèles incorrects et à une sélection de modèles sous-optimale pour des tâches réelles.

2. Méthodologie

Les auteurs ont mené des expériences comparant les évaluations standard avec des prompts statiques à des évaluations où les prompts étaient optimisés pour chaque modèle spécifique.

Configuration expérimentale

Modèles : Cinq LLM de premier plan (trois multimodaux à source fermée, deux textuels uniquement à poids ouverts) ont été évalués. Les noms des modèles ont été anonymisés (Modèle A–E).
Ensembles de données : Un mélange de benchmarks académiques publics et d'ensembles de données internes de l'industrie :
- Open-source : GSM8K (Mathématiques), OpenbookQA, MMLU (Multitâche).
- Interne : Digital Assistant Routing, Copilot Help Docs, Copilot Consultancy, Text-to-SQL, EDDE (Extraction de documents).
Techniques d'optimisation : Deux types d'Optimisation de Prompt (PO) ont été mis en œuvre en utilisant GPT-4o comme « critique » ou optimiseur :
1. Optimisation uniquement des instructions : Utilisation du framework TextGrad pour optimiser les instructions système et de tâche ( $I$ ).
2. Optimisation des instructions avec exemples : Utilisation du framework MIPRO (via DSPy) pour optimiser à la fois les instructions et les exemples few-shot ( $I + E$ ).
Métrique d'évaluation : Le Tau de Kendall ( $\tau$ ) a été utilisé pour mesurer la corrélation entre les classements de modèles dérivés des prompts statiques et ceux des prompts optimisés.

3. Contributions clés

Preuve empirique de l'instabilité des classements : L'article fournit la première preuve à grande échelle montrant que l'Optimisation de Prompt modifie radicalement les classements de modèles. Les modèles qui apparaissent « meilleurs » sous des prompts statiques chutent souvent dans le classement lorsque des prompts optimisés sont utilisés, et vice versa.
Quantification de la sensibilité : L'étude démontre que différents modèles présentent des niveaux de sensibilité variables à l'optimisation de prompt en fonction de la complexité de la tâche.
Recommandation méthodologique : Les auteurs proposent que l'Optimisation de Prompt devrait être une étape standard et obligatoire dans les pipelines d'évaluation de modèles centrés sur l'application, plutôt qu'une étape de post-traitement optionnelle.

4. Résultats clés

A. Changements de classement significatifs

Corrélation faible : La corrélation entre les classements utilisant des prompts statiques et des prompts optimisés est très faible.
- PO uniquement des instructions : Tau de Kendall moyen $\approx 0,23$ .
- PO des instructions avec exemples : Tau de Kendall moyen $\approx 0,36$ .
- Une valeur de $\tau$ proche de 0 indique que les classements sont presque non corrélés, ce qui signifie que le « meilleur » modèle change fréquemment.
Exemples spécifiques :
- Sur GSM8K, les prompts statiques suggéraient que le Modèle B était le meilleur, mais après optimisation uniquement des instructions, le Modèle D est devenu le meilleur performer.
- Sur MMLU, le Modèle B était en tête avec des prompts statiques, mais le Modèle D a pris la tête après optimisation.

B. Améliorations des performances

Gain général : La PO a généralement amélioré les scores de performance absolus des modèles sur tous les ensembles de données.
Performance maximale : Pour les objectifs centrés sur l'application, la PO permet aux praticiens de découvrir le vrai plafond de performance maximale d'une combinaison modèle-prompt. Par exemple, le Modèle A sur l'ensemble de données « Copilot Help Docs » a enregistré une augmentation de 6,9 % du score maximum après optimisation uniquement des instructions.

C. Sensibilité aux tâches

Tâches complexes vs simples : La PO a apporté les bénéfices les plus significatifs pour des tâches complexes et ouvertes (par exemple, GSM8K, Copilot Consultancy).
Rendements décroissants : Pour des tâches où les modèles performent déjà de manière quasi parfaite (par exemple, OpenbookQA, Digital Assistant Routing), la PO a fourni des gains minimes ou, dans certains cas, a dégradé les performances en raison d'une sur-optimisation ou d'instructions redondantes.

D. Cas négatifs (Modes de défaillance)

L'article met également en évidence des cas où la PO a diminué les performances :

Confusion de format : Dans OpenbookQA, l'optimisation a ajouté des instructions de raisonnement verbeuses qui ont confondu l'analyseur de métriques, entraînant le marquage d'une réponse correcte comme incorrecte.
Mauvaise interprétation des exemples : Dans MMLU, un prompt optimisé a amené un modèle à traiter les exemples few-shot comme de véritables questions de test, entraînant une cascade d'erreurs. Cela suggère la nécessité de vérifications de compatibilité entre l'optimiseur (« critique ») et le modèle cible.

5. Importance et conclusion

L'article remet fondamentalement en question le statu quo du benchmarking des LLM. Il soutient que les prompts statiques sont insuffisants pour sélectionner le meilleur modèle pour une application spécifique.

Pour les praticiens : S'en remettre aux classements publics avec des prompts statiques peut conduire à sélectionner un modèle sous-optimal. Pour garantir le meilleur retour sur investissement et les meilleures performances, les organisations doivent effectuer une optimisation de prompt par modèle avant l'évaluation finale.
Pour les chercheurs : Les futurs cadres de benchmarking doivent intégrer la PO automatisée comme composante centrale du pipeline d'évaluation afin de refléter avec précision les scénarios d'application réels.

Conclusion : Les auteurs concluent que « Optimisation avant Évaluation » n'est pas seulement une bonne pratique, mais une nécessité. Ignorer l'optimisation de prompt conduit à des benchmarks trompeurs et potentiellement à des erreurs coûteuses dans la sélection de modèles pour les systèmes de production.