Itérez sur la requête avant de mettre à niveau le modèle
Lorsqu'un modèle obtient un score inférieur à votre seuil de précision minimal, examinez ses échecs et corrigez la requête avant de payer pour un modèle plus grand. Puis relancez les mêmes cas. Cela fait passer le moins cher des trois modèles Claude testés par Meridian de 84 % à 100 %.
La démonstration de cette vidéo a été enregistrée en août 2026. Elle a été exécutée sur Claude Haiku 4.5, Claude Sonnet 5 et Claude Opus 5. Les résultats seront différents sur des modèles plus récents. La démonstration de chaque leçon correspond à une exécution d'évaluation distincte, de sorte que ses scores et ses coûts ne correspondront pas à ceux des autres leçons.
Un score d'évaluation faible indique qu'un modèle a commis trop d'erreurs sur les cas traités, mais ne précise pas si le modèle ou votre requête en est responsable.
Vérifiez d'abord la requête, car un modèle plus grand augmente le prix de chaque requête que vous envoyez après le changement. Modifier la requête ne prend que quelques minutes, et vous pouvez tester la modification immédiatement.
Meridian, un cabinet de conseil en ingénierie fictif, dispose d'une requête qui extrait trois champs de chaque rapport de projet mensuel : l'identifiant du projet, le statut du calendrier et le principal risque. Son évaluation est un test de 50 cas, chacun étant un rapport associé à sa réponse attendue.
Claude Sonnet 5 et Claude Opus 5 ont obtenu les 50 bonnes réponses. Claude Haiku 4.5 coûte le moins cher des trois, mais il n'a obtenu que 84 %, en deçà du seuil de précision minimal, soit les 90 % que Meridian exige avant d'utiliser un modèle.
Avant que Meridian ne dépense davantage pour un modèle plus grand, elle suit cinq étapes :
- Lire les cas en échec et identifier ce qu'ils ont en commun.
- Choisir des corrections pour les réponses non étayées.
- Intégrer les modifications dans la requête.
- Relancer les 50 cas sur les trois modèles.
- Vérifier chaque colonne, puis décider d'une mise à niveau.
Lire les cas en échec et identifier ce qu'ils ont en commun
Triez les cas en échec selon le type de rapport de chacun et le champ sur lequel il a échoué. Un score comptabilise les échecs, mais ne peut pas les expliquer. Lire ce qui a échoué vous montre ce qui s'est mal passé et pourquoi(s’ouvre dans un nouvel onglet), et c'est ainsi que vous apprenez s'il faut blâmer le modèle ou la requête.
Les 50 cas de Meridian se composent de 30 rapports typiques, de 10 rapports couvrant plusieurs projets et de 10 cas sans risque, où le rapport ne comporte pas de section risque. Le tableau montre les résultats de Haiku 4.5 avec l'ancienne requête, celle avec laquelle Meridian a commencé.
| Type de rapport | Cas | Échecs | Champ en échec |
|---|---|---|---|
| Typique | 30 | 3 | schedule_status |
| Multi-projets | 10 | 0 | |
| Risque manquant | 10 | 5 | top_risk |
Haiku 4.5, avec l'ancienne requête, a échoué sur 8 des 50 cas.
Cinq des huit échecs sont des cas de risque manquant, tous sur top_risk. Chacun aurait dû renvoyer null, mais le modèle a systématiquement rédigé une phrase nommant un risque. Le cas r045 en fait partie.
| Cas r045 | |
|---|---|
| Ce que le rapport dit du permis | « l'équipe ne prévoit aucun problème concernant le renouvellement. » |
| Réponse attendue | null |
| La réponse obtenue | « La fenêtre de renouvellement du permis du comté s'ouvre au prochain trimestre et pourrait avoir une incidence sur la continuité du projet si elle n'est pas effectuée à temps. » |
Le permis ne fait l'objet que d'une simple remarque de routine, et le rapport lui-même indique qu'aucun problème n'est à prévoir, pourtant le modèle l'a désigné comme le principal risque.
La ligne top_risk de l'ancienne requête se terminait par « ou null », ce qui autorisait null sans jamais indiquer au modèle quand l'utiliser. Lorsque les échecs se concentrent sur un seul type de rapport et un seul champ, ils partagent généralement une même cause, et ici, la requête omettait quelque chose.
Choisir des corrections pour les réponses non étayées
Choisissez vos corrections parmi cinq méthodes standard permettant de réduire la fréquence des réponses non étayées. Une réponse non étayée, c'est-à-dire une réponse que le document ne corrobore pas, est aussi appelée une hallucination. Les trois premières méthodes ci-dessous sont des étapes de base qui réduisent la fréquence des hallucinations(s’ouvre dans un nouvel onglet).
- Autorisez-le à dire « je ne sais pas ». Indiquez au modèle ce qu'il doit renvoyer lorsque le document ne contient pas la réponse, ce qui, pour Meridian, est
null. - Citer avant de répondre. Demandez au modèle d'extraire d'abord la phrase qui étaye sa réponse, puis de répondre à partir de cette phrase.
- Renvoyer une citation au document. Une fois que le modèle a répondu, demandez-lui de trouver une citation qui étaye chaque affirmation et de retirer toute affirmation qu'il ne peut pas étayer. Une personne peut ensuite vérifier chaque affirmation restante.
- Ajoutez une passe de vérification. Envoyez une deuxième requête dont le rôle est de vérifier la réponse donnée par la première requête(s’ouvre dans un nouvel onglet).
- Restreignez les connaissances externes. Demandez au modèle de répondre uniquement à partir du document et d'omettre ce qu'il a appris pendant l'entraînement.
Meridian utilise les deux premières, car la première comble exactement la lacune identifiée à l'étape 1. La seconde fait en sorte que chaque réponse corresponde à une phrase du rapport. Les deux ne nécessitent que l'ajout d'une ou deux lignes à la requête dont dispose déjà Meridian.
Intégrer les modifications dans la requête
Indiquez dans la requête dans quels cas null est la bonne réponse, et demandez la citation avant la réponse. L'encadré ci-dessous contient la nouvelle requête, qui correspond à la requête de Meridian avec les deux modifications apportées. Repérez la ligne qui remplit chaque fonction, et une note indique ce qui a changé.
Reprenons le cas r045. Le modèle doit désormais pointer vers une phrase qui révèle un risque, et les propos mêmes du rapport n'en révèlent aucun : « l'équipe ne prévoit aucun problème concernant le renouvellement. » Lorsqu'un rapport ne contient aucune phrase de ce type, la nouvelle requête indique quoi renvoyer : <source>none</source>, puis null.
Votre code a lui aussi une nouvelle tâche à accomplir. Comme la citation figure désormais en premier dans la réponse, l'intégralité du texte n'est plus un JSON valide, et json.loads échoue sur celui-ci. Analysez uniquement ce qui suit la balise de fermeture </source>.
answer = json.loads(text.split("</source>")[-1])Relancer les 50 cas sur les trois modèles
Relancez l'évaluation avec la nouvelle requête, en conservant les mêmes 50 cas et les mêmes trois modèles.
| Typique | Multi-projets | Risque manquant | Global | |
|---|---|---|---|---|
| Ancienne requête | 90 % | 100 % | 50 % | 84 % |
| Nouvelle requête | 100 % | 100 % | 100 % | 100 % |
La part des cas correctement traités par Haiku 4.5, avec l'ancienne requête et avec la nouvelle requête.
Aucune des cinq réponses non étayées n'est réapparue, et Haiku 4.5 obtient désormais un score supérieur au seuil de précision minimal.
Dans le tableau suivant, le coût d'exécution correspond au prix du passage d'un modèle sur l'ensemble des 50 cas, et le coût par tâche accomplie divise ce montant par le nombre de réponses correctes.
| Modèle | Typique | Multi-projets | Risque manquant | Global | Coût d'exécution | Coût par tâche accomplie |
|---|---|---|---|---|---|---|
| Haiku 4.5 | 100 % | 100 % | 100 % | 100 % | 0,0468 $ | 0,0009 $ |
| Sonnet 5 | 100 % | 100 % | 100 % | 100 % | 0,1250 $ | 0,0025 $ |
| Opus 5 | 100 % | 100 % | 100 % | 100 % | 0,3040 $ | 0,0061 $ |
Les trois modèles avec la nouvelle requête sur 50 cas, par rapport à un seuil de précision minimal de 90 %, aux tarifs standard d'août 2026. Consultez les tarifs actuels(s’ouvre dans un nouvel onglet).
Tous les modèles dépassent désormais le seuil, vous choisissez donc en fonction du coût par tâche accomplie, et celui de Haiku 4.5 est le plus bas.
Vérifier chaque colonne, puis décider d'une mise à niveau
Examinez chaque colonne des deux exécutions, et pas uniquement celle que vous cherchiez à corriger. Une modification qui profite à un type de cas peut en détériorer un autre, donc vérifiez cela après chaque modification(s’ouvre dans un nouvel onglet).
Comptez les réponses non étayées ainsi que toute réponse correcte devenue erronée. Meridian n'a perdu aucune de ses réponses correctes.
Les trois cas typiques qui avaient échoué sur schedule_status ont réussi cette fois-ci, bien qu'aucune modification n'ait touché la ligne de ce champ. Un modèle peut répondre différemment au même cas d'une exécution à l'autre, donc exécutez chaque configuration au moins deux fois avant de faire confiance à un score(s’ouvre dans un nouvel onglet).
Continuez à modifier la requête et à relancer tant que le score évolue. Lorsqu'il cesse d'évoluer en deçà de votre seuil de précision minimal, c'est que le modèle manque d'une capacité, et c'est le moment de procéder à une mise à niveau(s’ouvre dans un nouvel onglet).
En résumé
- Commencez par lire les cas en échec, regroupés selon le type de rapport de chacun et le champ sur lequel il a échoué.
- Corrigez ce que la requête omet en indiquant quoi renvoyer lorsque le document ne contient pas de réponse et en demandant la citation en premier.
- Relancez les mêmes cas au moins deux fois, et vérifiez que les réponses non étayées diminuent sans qu'aucune réponse correcte ne devienne erronée.
- Ne passez à un modèle plus grand qu'une fois que les modifications de la requête cessent de faire évoluer le score.