Quelle est la chose la plus frustrante lorsque vous développez une application IA aujourd'hui ? Il y a de fortes chances que ce soit ce scénario : vous avez modifié votre invite pour la 17e fois, quelques cas de test semblent fonctionner, mais une fois en production, un cas limite auquel vous n'aviez jamais pensé fait tout s'effondrer. C'est précisément ce problème que l'article de la Cookbook d'OpenAI, publié en octobre 2025 et intitulé "Building resilient prompts using an evaluation flywheel" (Construire des invites résilientes grâce à une boucle d'évaluation), cherche à résoudre.
Dans cet article, l'ingénieur d'OpenAI Neel Kapse et l'éducateur renommé en ML Hamel Husain introduisent le concept central de boucle d'évaluation (Evaluation Flywheel). En s'appuyant sur une méthodologie éprouvée issue de la recherche qualitative en sociologie, ils font passer le développement d'applications IA du stade du « prompt-and-pray » (modifier et prier) à celui d'une véritable discipline d'ingénierie. Cet article décrypte pour vous ce cadre de travail d'OpenAI afin de vous aider à l'appliquer à vos propres projets IA.
🎯 Guide rapide : La Cookbook utilise l'exemple concret d'un « assistant de location d'appartements » pour illustrer l'intégralité du flux de travail, de l'analyse des échecs à l'évaluateur automatique (grader) et à l'intégration CI. Les outils Evals API et Prompt Optimizer mentionnés font partie des capacités avancées de la plateforme OpenAI, accessibles via des passerelles comme APIYI (apiyi.com). Les développeurs peuvent ainsi reproduire le flux de la Cookbook sans difficulté.
Étude de cas : L'assistant de location d'appartements, une IA mise à mal par les cas limites
L'exemple choisi dans la Cookbook est très parlant : un assistant IA qui répond aux questions des locataires sur les dimensions des appartements, les visites et les équipements. Bien qu'il semble être un simple chatbot de service client, son déploiement en environnement réel a révélé des comportements inattendus.
Les types d'échecs recensés sont très représentatifs et parleront à tous les développeurs :
| Type d'échec | Description | Conséquence |
|---|---|---|
| Erreur de planification | Suggère des créneaux de visite inexistants | Déplacement inutile du client, hausse des plaintes |
| Confusion d'état | Ne supprime pas l'ancien rendez-vous lors d'une modification | Double réservation, désorganisation commerciale |
| Mise en page illisible | Liste des équipements condensée en un bloc de texte | Expérience utilisateur médiocre, information illisible |
| Lien rompu | Lien vers le plan de l'appartement en erreur 404 | Perte de l'utilisateur au profit de la concurrence |
| Dérive des données | Horaires d'ouverture erronés par rapport à la réalité | Désinformation de l'utilisateur, risque juridique |
Si vous avez déjà développé une application IA, vous savez que ces erreurs ne sont pas dues à une négligence lors de la rédaction de l'invite, mais au fait qu'elles sont imprévisibles. L'équipe de Fractional, dans son étude de cas sur l'inspection des reçus, résume bien le phénomène : tester uniquement les « happy paths » ne permettra jamais de détecter les bugs de la « longue traîne » en production. Il est indispensable de mettre en place une boucle vertueuse : « collecte des échecs → identification des modèles → mesure automatique ».
C'est précisément ce cycle que la boucle d'évaluation vise à instaurer.
Définition du cycle d'évaluation d'OpenAI : une discipline d'ingénierie pour remplacer le "prompt-and-pray"
Le cookbook définit le cycle d'évaluation (ou "flywheel") de manière concise : un processus d'itération continue qui remplace les suppositions par une discipline d'ingénierie structurée. Il se compose de trois étapes et, tel un véritable volant d'inertie, il tourne en continu, renforçant la résilience du système à chaque tour.
Les responsabilités des trois étapes sont très claires, chacune résolvant un problème spécifique :
| Étape | Problème central | Activités principales | Livrables |
|---|---|---|---|
| Analyze (Analyse) | "Pourquoi est-ce un échec ?" | Lecture manuelle des échantillons, induction des modèles d'échec | Liste de classification des échecs + proportions |
| Measure (Mesure) | "Quelle est la gravité ?" | Création d'un évaluateur, exécution sur le dataset | Indicateurs quantitatifs + baseline |
| Improve (Amélioration) | "Comment corriger ?" | Modification de l'invite, réévaluation | Nouvelle version + comparaison des indicateurs |
De nombreuses équipes sautent l'étape d'analyse pour passer directement à l'évaluation automatique, ce qui est la cause la plus fréquente d'échec du cycle d'évaluation. Une mesure automatique sans analyse qualitative est un château de cartes, car vous ne savez tout simplement pas ce que vous mesurez. C'est l'insight le plus important de ce cookbook, et ce qui le distingue des tutoriels classiques sur les évaluations.
💡 Analogie : Le cycle d'évaluation ressemble au cycle PDCA bien connu des chefs de produit, mais appliqué à l'ingénierie des invites avec une méthodologie concrète. "Analyze" correspond à "identifier le problème", "Measure" à "quantifier le problème", et "Improve" à "résoudre le problème". Les trois sont indispensables. Nous recommandons, lors de l'invocation du modèle via l'API OpenAI sur apiyi.com, de bien consolider l'étape d'analyse avant de lancer la mesure.
Étape 1 du cycle d'évaluation OpenAI : La méthode de marquage en deux étapes pour l'analyse
L'étape d'analyse est la plus négligée, mais pourtant la plus cruciale. Le cookbook propose ici une méthode très professionnelle : Open Coding (Codage ouvert) → Axial Coding (Codage axial). Issue de la recherche qualitative en sociologie, cette méthode est l'un des paradigmes les plus éprouvés pour analyser des données textuelles non structurées.
La première étape, l'Open Coding, est simple : lisez 50 échantillons d'échecs, sans préjugés de classification, et attribuez directement une étiquette descriptive à chaque échec. Par exemple :
- "A recommandé un créneau de visite inexistant"
- "La liste des équipements est un bloc de texte illisible"
- "La modification du rendez-vous n'a pas annulé l'ancien"
- "A répondu avec les dimensions d'un autre appartement"
- "Le lien vers le plan de l'appartement ne fonctionne pas"
Notez qu'à cette étape, on ne cherche pas délibérément à classer proprement. Vous devez simplement décrire honnêtement ce que vous voyez. L'Open Coding ressemble à la prise de notes de lecture : laissez vos idées circuler sans contrainte, car une catégorisation prématurée vous ferait perdre la perception des modèles marginaux.
La deuxième étape, l'Axial Coding, permet de structurer le tout : vous regroupez les étiquettes éparses de la première étape en catégories de haut niveau significatives. Les exemples de catégories donnés par le cookbook sont :
- Problèmes de planification de visite (regroupant : erreur d'horaire, non-annulation, double réservation) → 35 % des échecs
- Erreurs de formatage (regroupant : mise en page cassée, lien invalide) → 10 % des échecs
- Exactitude des données (regroupant : erreur d'horaires d'ouverture, erreur de dimensions) → X % des échecs
L'Axial Coding ressemble à l'organisation d'une table des matières, vous permettant de voir la "carte topographique" des échecs. Le chiffre de 35 % vous indique immédiatement quelle catégorie corriger en priorité, car c'est là que le retour sur investissement (ROI) est le plus élevé.
| Méthode de marquage | Objectif | État d'esprit | Sortie |
|---|---|---|---|
| Open Coding | Découverte | Libre, sans classification prédéfinie | 50+ étiquettes descriptives |
| Axial Coding | Structuration | Induction, construction de catégories | 5-8 catégories d'échecs de haut niveau |
🔧 Conseil pratique : Pour les développeurs, lors de l'étape d'analyse, vous pouvez connecter vos logs de production via l'API proxy (comme apiyi.com) directement à l'interface de marquage des datasets de l'API Evals, sans avoir à développer votre propre backend. Utilisez le type de marquage "Feedback" pour l'Open Coding et le type "Label" pour l'Axial Coding, en suivant exactement le flux du cookbook.
Phase 2 du cycle d'évaluation OpenAI : Sélection des deux types de "grader" pour la mesure (Measure)
Lors de la phase d'analyse, vous avez identifié "à quoi ressemble un échec". La phase de mesure consiste désormais à transformer ces échecs en code de détection automatique. Le cookbook propose un guide de sélection pour deux types de graders, un point qui prête souvent à confusion pour les ingénieurs.
| Type de Grader | Cas d'utilisation | Avantages | Inconvénients |
|---|---|---|---|
| Python Grader | Règles déterministes (chaînes, regex, vérification API) | Résultats stables, zéro hallucination, coût nul | Incapable d'évaluer des dimensions subjectives |
| LLM Grader | Jugements subjectifs (esthétique, alignement sémantique, qualité du raisonnement) | Flexible, évalue des dimensions difficiles à coder | Nécessite un alignement avec un expert métier (SME), coût en tokens |
Prenons l'exemple d'un assistant de location immobilière, où les deux types de graders trouvent leur utilité :
- "L'heure recommandée est-elle dans un créneau réellement disponible ?" → Python Grader (interrogation de base de données ou API)
- "La liste des équipements est-elle présentée de manière esthétique ?" → LLM Grader (notation de 0 à 10)
- "Le lien vers le plan de l'appartement est-il accessible ?" → Python Grader (requête HEAD)
- "Le ton de la réponse correspond-il à l'image de marque ?" → LLM Grader (notation basée sur une grille d'évaluation)
Le cookbook souligne une pratique d'ingénierie cruciale : le LLM Grader doit faire l'objet d'un alignement avec un expert métier (SME – Subject Matter Expert) ; ne faites pas aveuglément confiance aux scores de GPT-4o. La méthode consiste à diviser les données en ensembles d'entraînement/validation/test et à vérifier deux indicateurs :
- High TPR (Taux de vrais positifs) : Capacité à détecter les vrais échecs.
- High TNR (Taux de vrais négatifs) : Capacité à ne pas pénaliser à tort les échantillons corrects.
Se fier uniquement à la précision globale peut être trompeur à cause d'une ligne de base élevée. Il est impératif d'aligner ces deux indicateurs. C'est ce qui sépare une approche "qui a l'air de fonctionner" d'une solution robuste.
📊 Processus de validation : Un expert métier annote 100 échantillons comme "vérité terrain" → Le LLM Grader note ces mêmes échantillons → Calcul du TPR / TNR → Ajustement du prompt du grader jusqu'à ce que les deux indicateurs soient atteints. Ce processus est nativement pris en charge par la plateforme Evals sur apiyi.com, car l'API Evals est entièrement compatible avec le protocole officiel d'OpenAI.
Phase 3 du cycle d'évaluation OpenAI : Expérimentation à double voie pour l'amélioration (Improve)
Lors de cette troisième phase, vous pouvez enfin modifier vos invites. Le cookbook propose deux chemins d'amélioration parallèles qui ne sont pas exclusifs, mais complémentaires.
Chemin 1 : Optimisation automatique (Prompt Optimizer)
La plateforme OpenAI intègre un outil d'optimisation d'invites. Vous lui fournissez un ensemble d'échantillons d'échec et l'invite originale ; il testera automatiquement diverses stratégies de réécriture (ajout de few-shot, chaîne de pensée, ajustement de l'ordre des instructions, etc.) et évaluera l'efficacité de l'amélioration via vos graders. Cette voie est pratique et idéale pour une exploration initiale.
Chemin 2 : Amélioration manuelle basée sur les modes d'échec
En vous basant sur les modes d'échec identifiés lors de la phase d'analyse, vous modifiez manuellement l'invite de manière ciblée. Par exemple :
- Erreur de planification de visite → Ajout d'une étape obligatoire dans l'invite pour "vérifier le calendrier des disponibilités".
- Mise en page défectueuse → Utilisation de balises XML pour spécifier explicitement le format de sortie.
- Annulation non prise en compte → Ajout d'une logique d'état : "annuler avant de prendre un nouveau rendez-vous".
L'avantage de l'approche manuelle est la précision : vous savez exactement quelle modification traite quel mode d'échec, ce qui facilite grandement le débogage.
Une fois les deux chemins parcourus, vous disposerez de N versions candidates d'invites. L'étape cruciale de la phase d'amélioration est la suivante : utilisez le même ensemble de graders sur le même jeu de données pour tester toutes les versions et sélectionnez celle qui obtient les meilleurs indicateurs. Ne sautez pas cette étape, car nous avons tendance à être biaisés par un sentiment de satisfaction personnelle envers nos propres modifications. Seuls les chiffres permettent de corriger ce biais.
Après avoir testé toutes les versions, le cycle est bouclé. Vous découvrirez probablement de nouveaux modes d'échec (car le système s'étant amélioré, il expose des cas limites plus profonds), et vous retournerez à la phase d'analyse pour un nouveau tour. C'est l'essence même du "cycle" : il ne s'arrête jamais, il tourne de plus en plus vite et devient de plus en plus robuste.
Différence fondamentale entre une invite résiliente (Resilient Prompt) et une invite fragile
Le terme resilient prompt (invite résiliente) mentionné dans le titre est un concept crucial. La définition donnée par le cookbook est la suivante : une invite capable de fournir des réponses de haute qualité sur toutes les entrées possibles. Cela semble simple, mais il s'agit en réalité d'une norme d'ingénierie très élevée.
Les différences entre résilience et fragilité se manifestent principalement selon cinq dimensions :
| Dimension de comparaison | Invite fragile | Invite résiliente |
|---|---|---|
| Robustesse de l'entrée | S'effondre au moindre changement | Stable malgré les reformulations |
| Cas limites | Sorties étranges ou hallucinations | Dégradation élégante ou transfert humain |
| Observabilité | Boîte noire, devinettes en cas d'erreur | Grader complet pour localiser l'erreur |
| Admissibilité en production | Performance démo ≠ performance prod | Validation via une boucle d'évaluation |
| Évolutivité | Corriger A casse B | Protection par régression automatique |
L'intuition de l'ingénieur pousse à croire qu'une invite "suffisamment bonne" fera l'affaire, mais en environnement de production, des problèmes surviennent avec une probabilité de 0,1 %. Cela semble négligeable, mais à l'échelle d'un million d'appels, cela représente 1 000 incidents. La valeur technique d'une invite résiliente ne réside pas dans le passage de 80 % à 90 %, mais dans celui de 99 % à 99,9 %.
🚀 Conseil d'intégration : Pour pousser une invite vers une résilience de 99,9 %, vous devez automatiser la boucle d'évaluation, ce qui nécessite une invocation stable de l'API OpenAI Evals et des outils d'optimisation d'invites. Nous recommandons d'utiliser une plateforme de service proxy API comme apiyi.com, dont les interfaces sont parfaitement synchronisées avec l'officiel, et dont les nœuds IDC locaux garantissent que les tâches d'évaluation ne sont pas interrompues.
Intégration CI/CD et surveillance de production pour la boucle d'évaluation OpenAI
La dernière étape soulignée par le cookbook est : transformer la boucle d'évaluation en une discipline d'ingénierie quotidienne. La mise en œuvre se divise en deux parties :
Première partie : Intégration CI/CD
Connectez la suite de graders au pipeline CI, afin que chaque modification d'invite déclenche automatiquement une évaluation. Si les indicateurs régressent au-delà d'un certain seuil, la fusion de la PR est automatiquement bloquée. Cette étape transforme l'évaluation d'une simple activité de recherche en une pratique de développement quotidienne, marquant le véritable passage à l'ingénierie des invites.
| Type de seuil CI | Paramètre recommandé | Explication |
|---|---|---|
| Précision globale | Régression ≤ 1 % | Empêche la régression globale |
| Grader critique | Régression ≤ 0,5 % | Contrôle strict des modes d'échec prioritaires |
| Détection nouveau mode | Avertissement, pas de blocage | Encourage la découverte de nouveaux problèmes |
| Latence P95 | Croissance ≤ 10 % | Contrôle des coûts et de l'expérience |
Deuxième partie : Surveillance de production
Au-delà de la CI, il est nécessaire d'échantillonner en continu l'environnement de production pour découvrir des "modes d'échec sauvages" absents des jeux de tests CI. Ces nouveaux modes sont réintégrés dans l'ensemble d'évaluation, faisant tourner la boucle.
La méthode consiste à échantillonner les journaux de production à un taux fixe (par exemple 1 %), à exécuter la même suite de graders, et à isoler les anomalies pour une analyse humaine. Les nouveaux modes d'échec identifiés sont traités via Open Coding et Axial Coding avant d'être ajoutés au jeu de tests. Ce cycle permet à votre système d'invites de devenir toujours plus résilient, plutôt que de stagner après le déploiement. C'est la discipline d'ingénierie fondamentale que le cookbook lègue à tous les ingénieurs IA.
5 leçons pratiques de la boucle d'évaluation d'OpenAI pour les développeurs locaux
Après avoir lu le cookbook, j'ai extrait 5 enseignements qui offrent des conseils directs aux développeurs utilisant des modèles en Chine :
Leçon 1 : Commencez par l'analyse, pas par la mesure
Beaucoup d'équipes commencent directement par configurer des évaluateurs (graders) et suivre des indicateurs, en sautant l'étape de l'analyse humaine. Résultat : l'évaluateur ne mesure pas les véritables modes de défaillance, les chiffres sont beaux, mais les utilisateurs continuent de se plaindre. Ne lancez pas d'évaluation automatique sans avoir effectué 50 analyses manuelles (Open Coding).
Leçon 2 : Ne laissez pas GPT faire l'Open Coding
L'Open Coding doit être réalisé par des humains, car GPT, en mode induction, risque de polluer vos étiquettes avec les biais de ses données d'entraînement. Le moment idéal pour faire intervenir le LLM est après l'Axial Coding, lors de l'implémentation de l'évaluateur. La phase de "découverte" de l'analyse est réservée aux humains.
Leçon 3 : Privilégiez les évaluateurs Python aux évaluateurs LLM
Si une règle déterministe peut couvrir le cas, n'utilisez pas d'évaluateur LLM. Pour trois raisons : c'est plus stable, moins cher et cela ne nécessite pas d'alignement avec des experts métiers (SME). Réservez l'évaluateur LLM aux dimensions réellement subjectives que les règles ne peuvent pas couvrir.
Leçon 4 : Liez les indicateurs à l'impact métier
35 % de problèmes de planification, 10 % de problèmes de formatage — ces pourcentages n'ont de valeur décisionnelle que s'ils sont convertis en "taux de désabonnement" ou "taux de réclamation". L'indicateur en soi n'a pas de sens, ce sont ses conséquences métier qui comptent.
Leçon 5 : Automatisez la boucle, ne la traitez pas comme un projet ponctuel
Le retour sur investissement (ROI) d'un seul tour de boucle n'est pas forcément énorme, mais les intérêts composés sur le long terme sont considérables. Transformez vos évaluateurs en tâches CI, automatisez l'échantillonnage en production et configurez des alertes automatiques pour les nouveaux modes de défaillance. Laissez la boucle tourner 24h/24.
Structure de code Python pour reproduire la boucle d'évaluation d'OpenAI
Bien que le cookbook présente principalement le flux de travail via l'interface utilisateur de la plateforme OpenAI, l'invocation programmatique via l'API Evals est tout aussi efficace. Voici une structure de code Python montrant comment appeler l'API Evals pour créer un évaluateur et lancer une évaluation, idéale pour les développeurs qui préfèrent un flux de travail basé sur le code :
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url="https://vip.apiyi.com/v1", # Basculer vers la passerelle de service proxy API d'OpenAI
api_key="Votre clé API APIYI"
)
# 1. Créer une tâche d'évaluation (définir l'ensemble des évaluateurs)
eval_cfg = await client.evals.create(
name="leasing_assistant_v1",
data_source_config={
"type": "stored_completions",
"metadata": {"version": "v1"}
},
testing_criteria=[
{ # Exemple d'évaluateur Python
"type": "string_check",
"name": "tour_time_valid",
"input": "{{sample.output}}",
"operation": "eq",
"reference": "{{item.expected_time}}"
},
{ # Exemple d'évaluateur LLM
"type": "score_model",
"name": "format_quality",
"model": "gpt-4o",
"input": "{{sample.output}}",
"instructions": "Attribuer une note de 0 à 10 sur la clarté du formatage de la sortie"
}
]
)
# 2. Lancer l'évaluation
run = await client.evals.runs.create(
eval_id=eval_cfg.id,
name="baseline_run",
data_source={"type": "completions"}
)
# 3. Récupérer les résultats de l'évaluation
result = await client.evals.runs.retrieve(eval_id=eval_cfg.id, run_id=run.id)
print(f"Taux de réussite : {result.report_url}")
Ce code comporte trois points clés. Le premier est le changement de base_url, cette ligne détermine si vous pouvez exécuter des tâches d'évaluation de manière stable en Chine. Le second est le tableau testing_criteria, qui vous permet de configurer tous les évaluateurs et de les exécuter en une seule fois. Le troisième est que l'API Evals est asynchrone ; sur de grands jeux de données, l'évaluation peut prendre de quelques minutes à plusieurs dizaines de minutes, il est donc nécessaire de prévoir des mécanismes d'attente et de nouvelle tentative dans votre programme.
FAQ sur la boucle d'évaluation OpenAI
Q1 : Quelle est la différence entre la boucle d'évaluation et des plateformes comme LangSmith ou Weights & Biases ?
Le positionnement est différent. LangSmith se concentre sur "l'outillage de l'évaluation", tandis que la boucle d'évaluation se concentre sur la "méthodologie d'évaluation". Le premier vous indique comment implémenter, le second vous apprend à réfléchir. Les deux peuvent être utilisés conjointement : utilisez l'outil pour porter la méthodologie.
Q2 : 50 échantillons d'échec, est-ce suffisant ? N'est-ce pas trop peu ?
Pour la phase de codage ouvert (Open Coding), 50 échantillons suffisent, car l'objectif est de découvrir des modèles plutôt que d'atteindre une exhaustivité statistique. Le nombre d'échantillons requis pour la phase de mesure dépend du taux d'échec : si le taux est de 5 %, il faut 1 000 échantillons pour obtenir un intervalle de confiance stable ; si le taux est de 30 %, 200 suffisent.
Q3 : L'optimiseur d'invites (Prompt Optimizer) peut-il remplacer totalement les modifications manuelles ?
Non. Les outils automatiques excellent dans l'optimisation locale sur des évaluateurs connus, mais ils ne sont pas doués pour comprendre les contraintes métier (comme une règle implicite du type "le client exige que chaque réponse ne dépasse pas 80 caractères"). La combinaison de modifications manuelles et d'optimisation automatique est la meilleure pratique.
Q4 : L'invocation de l'API Evals est-elle stable depuis la Chine ?
Une connexion directe à OpenAI pour des tâches de longue durée (l'évaluation prend souvent de quelques minutes à quelques heures) entraîne fréquemment des réinitialisations de connexion. Nous recommandons d'utiliser un service proxy API comme apiyi.com. Les nœuds IDC nationaux sont spécifiquement optimisés pour les connexions longues, ce qui réduit considérablement le taux d'interruption des tâches d'évaluation.
Q5 : À quelle taille d'équipe la boucle d'évaluation est-elle adaptée ?
Elle convient aussi bien aux projets solo qu'aux équipes de 100 personnes. La seule différence réside dans la fréquence de rotation de la boucle. Un projet solo peut faire un tour toutes les deux semaines, tandis qu'une grande équipe peut itérer quotidiennement, voire toutes les heures. L'essentiel est d'établir une discipline, pas une question d'échelle.
Q6 : Qui est Hamel Husain et pourquoi ce livre de recettes (cookbook) suscite-t-il autant d'intérêt ?
Hamel est un éducateur très influent dans la communauté du machine learning, qui promeut depuis longtemps les meilleures pratiques d'ingénierie pour les applications de grands modèles de langage. Ce livre de recettes est la première fois qu'OpenAI introduit systématiquement des méthodologies de recherche qualitative (comme le codage ouvert) dans l'ingénierie des invites, ce qui explique le vif intérêt de l'industrie.
Conclusion
La véritable valeur de la boucle d'évaluation OpenAI est d'apporter à la communauté des ingénieurs IA une réponse standard à la question : "Comment faire de l'ingénierie d'invites de manière professionnelle ?". Il ne s'agit pas d'un outil spécifique, mais d'une discipline d'ingénierie qui transforme le développement d'invites, passant d'un "artisanat basé sur le ressenti" à une "pratique d'ingénierie traçable".
En intégrant les trois phases — Analyser, Mesurer, Améliorer — dans votre flux de développement, votre application IA passe du stade de "démo qui semble fonctionner" à celui de "produit prêt pour la production et conforme aux SLA". Derrière cette montée en gamme se trouve une boucle complète où les échecs sont systématiquement collectés, les modèles structurés et les améliorations validées par des mesures automatiques.
Si vous développez une application IA basée sur des invites, nous vous recommandons vivement de mettre en place cette boucle. Nous suggérons d'utiliser une plateforme d'API comme apiyi.com pour invoquer directement l'API Evals et l'optimiseur d'invites. Un simple changement de base_url suffit pour exécuter l'ensemble du processus du livre de recettes, sans vous soucier des problèmes de stabilité réseau.
En gravant cette "boucle" dans votre mémoire musculaire, vos invites commenceront dès aujourd'hui à gagner en résilience.
📌 Auteur : APIYI Team — Suivi à long terme des pratiques d'ingénierie des API multimodales d'OpenAI, Anthropic et Google. Pour plus d'analyses pratiques et de guides d'accès à l'API Evals, consultez le centre de documentation sur apiyi.com.
