← Retour aux articlesDécouverteSeptember 23, 202513 min de lectureCopy article

Benchmark-Driven Development: Au-delà de TDD pour les systèmes d'IA

Benchmark-Driven Development est passé de TDD pour gérer le rythme exponentiel de l'IA : les benchmarks génèrent désormais automatiquement des configurations de production avec des pistes d'audit complètes.

Developed by Robert E. Beckner III (Merlin) | rbeckner.com

J'ai découvert Benchmark-Driven Development début 2025 en construisant un système de traduction sur lequel j'avais travaillé pendant deux ans et plusieurs moteurs de rendu de documents. Le système de traduction est devenu le laboratoire où cette méthodologie s'est cristallisée. J'avais travaillé avec des systèmes d'IA depuis environ 2023, et à mesure que j'avançais, je me suis rendu compte que les modèles d'IA évoluaient si rapidement que les approches traditionnelles ne pouvaient pas suivre. C'était vers le moment où l'appel de fonctions venait d'émerger comme une innovation sur le marché, avant que les agents autonomes ne deviennent vraiment une réalité. J'évaluais différentes paires de langues, construisais des pipelines complexes, et je me suis rendu compte que j'avais besoin d'un moyen pour le projet lui-même de mesurer les capacités jusqu'au métal. Le problème n'était pas seulement de tester si quelque chose fonctionnait, mais de découvrir ce qui fonctionnait le mieux lorsque le paysage changeait toutes les quelques semaines.

Des tests aux simulations#

J'ai toujours compris la valeur des tests, surtout lors de la construction de systèmes d'entreprise pour le gouvernement où des exigences strictes et des contrats entièrement financés exigeaient des preuves. Mais lorsque la TDD a été imposée sur les projets sur lesquels je travaillais, j'ai constaté quelque chose d'important : les cadres ne fonctionnent que lorsque les équipes les adoptent réellement. Forcer une adoption complète est rarement judicieux. Ce que j'ai appris, c'est que la meilleure approche est souvent hybride — adopter uniquement ce dont on a besoin. Je me suis orienté vers la testabilité des fonctionnalités de base plutôt que vers une couverture unitaire exhaustive. Pourquoi maintenir des milliers de tests dispersés alors qu'un seul script de simulation de moins de 1000 lignes pourrait valider l'ensemble du flux utilisateur? Pour une application de mobilisation politique, j'ai créé une simulation qui créait des équipes fictives, simulait l'arrivée et le départ de militants, générait des charges réalistes, et mettait le système à l'épreuve à grande échelle. Cela a révélé tout : le comportement de l'interface, le rendu des graphiques, l'intégrité des données aux limites. Un seul script m'a donné plus de confiance que des tests unitaires dispersés ne l'auraient jamais pu. Au cours de mes 25 années de programmation, j'ai passé les 10-12 dernières années pleinement conscient de la valeur d'un excellent tableau de bord. J'utilisais des tableaux de bord bien avant l'existence de GPT, et les revisiter avec l'IA ces trois dernières années a été fascinant. Ces expériences de simulation ont jeté les bases de ce qui est devenu Benchmark-Driven Development.

Le Moment où tout a changé#

Le véritable découvert se produit lorsque j'ai réalisé quelque chose qui a tout changé : le benchmarking pouvait simplement émettre une configuration qui passe directement en production. Il est déjà testé, là, prêt à se brancher avec les invites et tout . C'était la grande intuition . Cela a émergé en confrontant un problème fondamental avec le système de traduction . Les fournisseurs d'IA prétendaient soutenir des dizaines de langues, mais dans quelle mesure et avec quelle qualité ? Ces informations n'étaient pas bien documentées, et j'ai appris par expérience que je ne pouvais pas entièrement faire confiance aux affirmations des vendeurs — et je ne devrais pas . Alors j'ai créé une boucle d'évaluation de benchmark qui vit dans le projet . Je pouvais lui donner un service et un modèle, et il évaluerait les langues dans lesquelles il est réellement compétent — pas ce que le vendeur prétendait, mais ce que les preuves empiriques montraient . Le processus est idempotent : même entrée, même sortie, mis en cache de façon constante pour des résultats rapides . Lorsqu'on change les invites, nous effectuons des tests A/B pour découvrir les meilleures . Les modèles qui échouaient constamment ont été blacklistés ou déclassés pour certaines paires linguistiques, rendant le benchmarking plus productif . L'utilisation de l'IA pour créer des intégrations IA s'est avérée incroyablement puissante . Avec l'appel de fonctions et les premiers cadres qui deviendraient des agents, je pouvais construire des benchmarks avec l'IA, complets de fiches de score et d'évaluations . Ce que j'ai découvert sur les modèles et les capacités linguistiques différait considérablement des affirmations des vendeurs . Je devais être plus proche du métal, plus proche des preuves réelles .

Diagram source

graph TB
    Problem[Reclamations des fournisseurs]
    Loop[Boucle d'évaluation]
    Cache[Cache idempotent]
    ABTest[Prompts d'essai A/B]
    Demote[Échec de la liste noire]
    Discovery[Émettre vers Prod]

    Problem -->|Créer| Loop
    Loop -->|Activer| Cache
    Cache -->|Rapide| ABTest
    Cache -->|Suivre| Demote
    ABTest -->|Percée| Discovery
    Demote -->|Optimiser| Discovery

    style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
    style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2px

Copy sourceCe n'était pas théorique. Cela a émergé de la douleur pratique de ne pas pouvoir faire confiance aux affirmations du vendeur et de devoir constamment mettre à jour les systèmes de production à mesure que de nouveaux modèles apparaissaient. Les références ont évolué des outils de mesure en générateurs de configuration.

Ce qu'est réellement le Développement Basé sur les Benchmarks#

Le Développement Basé sur les Benchmarks va au-delà de la validation pour devenir un processus génératif. Tandis que les tests vérifient la justesse, les benchmarks comparent les performances sur plusieurs dimensions. Plus important encore, en DBD, les benchmarks émettent la configuration qui pilote le système de production. Ce que je veux vraiment dire, c'est ceci : au lieu de simplement vérifier si le code fonctionne, le système évalue continuellement quelle approche fonctionne le mieux, puis se configure automatiquement pour utiliser cette approche optimale. Prenez ce qui fonctionne et construisez quelque chose qui serve réellement votre contexte. Développement Basé sur les Tests:

Diagram source

graph TB
    Test[Écrire un test]
    Code[Écrire du code]
    Pass[Test réussi]
    Test --> Code
    Code --> Pass

    style Pass fill:transparent,stroke:#10B981,stroke-width:2px

Copy sourceDéveloppement Basé sur les Benchmarks:

Diagram source

graph TB
    Bench[Exécuter les benchmarks]
    Compare[Comparer les résultats]
    Config[Générer la configuration]
    Deploy[Production]
    Bench --> Compare
    Compare --> Config
    Config --> Deploy

    style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
    style Config fill:transparent,stroke:#3B82F6,stroke-width:2px

Copy source

À l'intérieur du système de traduction#

Dans le système de traduction, plutôt que de choisir un seul modèle IA et d'espérer qu'il fonctionne bien sur toutes les paires de langues, j'ai créé un système de référence complet qui a évalué plusieurs modèles sur trois métriques clés :

Qualité - Précision de la traduction et préservation des nuances culturelles
Vitesse - Temps de réponse pour différentes longueurs de texte
Coût - Tarification par token ou par requête

Les benchmarks ont parlé d'eux-mêmes et ont révélé des insights surprenants qui ont fondamentalement changé ma façon de penser aux capacités linguistiques de l'IA. Le moment de clarté est survenu grâce à un projet de traduction de manuscrit chinois pour un client. Sa femme avait écrit un manuscrit chinois de 175+ pages, et j'aidais à le numériser et le traduire. J'ai capturé les pages en utilisant la fonction overlay de Google Translate, puis j'ai divisé le contenu en morceaux de 10-15 pages pour une évaluation systématique. En utilisant Claude Opus—le modèle le plus avancé disponible à l'époque—j'ai effectué des évaluations complètes sur chaque morceau. L'IA ne se contentait pas de traduire ; elle analysait la qualité des sorties de traduction automatique de Google Translate. Les résultats étaient frappants : une perte de 30% en nuance culturelle, avec des exemples précis indiquant exactement où le sens s'est brisé. L'IA expliquerait : "Cette phrase signifie X en anglais selon la traduction automatique, mais le chinois exprime en réalité Y — le contexte culturel est Z, et cette méprise change fondamentalement le sens." Il ne s'agissait pas de différences subtiles. Ce furent des pertes significatives du message voulu par l'auteur. Ce qui rendait cette découverte plus troublante, c'est de tester des modèles qui prétendaient soutenir 50-80+ langues. Ayant une certaine familiarité avec l'espagnol, j'ai pu repérer des pertes similaires de nuance culturelle que des métriques plus simples auraient complètement manquées< Cela a soulevé la question de ce que signifie réellement une « langue supportée » lorsqu'il y a une perte de 30% en nuance culturelle par rapport à des alternatives plus coûteuses. Le couple a été profondément touché par le rapport détaillé – ils ne s'attendaient pas à une telle précision pour identifier où la traduction a échoué et pourquoi. Pour moi, c'était le moment de cristallisation : j'avais besoin de benchmarks qui mesuraient ce qui comptait réellement, pas seulement ce que les fournisseurs prétendaient. Cette expérience a directement inspiré l'approche axée sur les benchmarks qui deviendra centrale dans la façon dont je construis des systèmes.

Diagram source

graph TB
    Input[Corpus de Test]
    Models[Modèles d'IA]
    Bench[Suite d'évaluation]
    Metrics[Score: Q/S/C]
    Winner[Meilleure configuration]
    ProdConfig[Production]

    Input --> Bench
    Models --> Bench
    Bench -->|Qualité| Metrics
    Bench -->|Vitesse| Metrics
    Bench -->|Coût| Metrics
    Metrics --> Winner
    Winner -->|Auto-générer| ProdConfig

    style Winner fill:transparent,stroke:#3B82F6,stroke-width:2px
    style ProdConfig fill:transparent,stroke:#10B981,stroke-width:2px

Copy source

Évaluer l'évaluateur#

Une innovation cruciale consistait à mettre en œuvre ce que j'appelle "évaluer l'évaluateur en premier". Étant quelque peu familier avec l'espagnol, j'ai pu facilement repérer les pertes de nuance culturelle que de simples métriques d'évaluation ont manquées . La solution était d'employer des modèles plus coûteux et de meilleure qualité spécifiquement pour évaluer la fiche de score elle-même, garantissant que les références mesurent ce qui compte vraiment . Avoir des boucles d'évaluation et utiliser des modèles plus intelligents pour évaluer les évaluateurs est devenu une technique puissante . Obtenir un bon évaluateur pour une chose est une création incroyable dans un projet – un exploit, un défi et une réussite à la fois . Ce processus de méta-évaluation a raffiné la fiche de score itérativement, et j'ai pu créer un cadre d'évaluation robuste qui pouvait réellement être fiable pour prendre des décisions automatisées . D'après mon expérience, c'est là que la plupart des équipes échouent : elles font confiance à leurs évaluateurs sans les évaluer d'abord .

Diagram source

graph TB
    Basic[Métriques de base]
    Human[Revue humaine]
    Premium[Modèle premium]
    Refined[Fiche de score raffinée]
    Trust[Évaluateur de confiance]

    Basic -->|Écarts trouvés| Human
    Human -->|Perspectives| Premium
    Premium -->|Évaluer| Basic
    Premium --> Refined
    Refined -->|Itérer| Trust

    style Human fill:transparent,stroke:#333333,stroke-width:2px
    style Premium fill:transparent,stroke:#3B82F6,stroke-width:2px
    style Trust fill:transparent,stroke:#10B981,stroke-width:2px

Copy source

Quand les Benchmarks deviennent une Configuration#

Une fois que j'ai réalisé que les benchmarks pouvaient générer des configurations de production, tout a fait sens. Le benchmark vit à côté du code et peut se concentrer sur n'importe quelle couche du pipeline ou du composant du moteur. Il peut créer des composants fictifs, tester des variations, et lorsque les scores s'améliorent, émettre une configuration directement dans le code source. Cette connectivité est devenue essentielle. L'IA évolue si rapidement qu'il est judicieux d'avoir le benchmarking vivant dans le projet. Lorsqu'un nouveau modèle est publié avec de meilleures économies ou une meilleure vitesse, les tableaux de bord restent les mêmes et le benchmarking continue. Les gains de qualité sont incroyables. Les combinaisons gagnantes—sélection de modèle, ingénierie des invites, ajustement des paramètres—déjà testées avec des pistes d'audit complètes, sont émises dans la configuration et passent directement en production. Avec le système de traduction, cela m'a donné une conscience incroyable des capacités du modèle pour les traductions linguistiques. Les gagnants sont automatiquement devenus la configuration de production, utilisant toujours le meilleur équilibre qualité, prix et préservation de la nuance culturelle. Cela a créé une trace d'audit montrant exactement pourquoi chaque décision technique a été prise, soutenue par des données empiriques. Quand quelqu'un demande "Pourquoi le Modèle X pour l'espagnol-vers-français mais le Modèle Y pour le chinois-vers-anglais ?" la réponse existe dans les résultats du benchmark.

Ingénierie des prompts à travers les données#

Le système a évolué pour servir de référence non seulement pour la sélection de modèles mais également pour l'ingénierie des prompts. J'ai pu établir les références, puis faire en sorte que différentes parties travaillent même sur les invites IA, en testant systématiquement différents prompts par A/B. Des gagnants clairs ont émergé en fonction des métriques établies. Cela a supprimé le jeu d'astuces de l'ingénierie des prompts, remplaçant l'intuition par des décisions basées sur les données.

L'économie de la découverte continue#

Il y a un aspect significatif d'économies de coûts à cette approche. Le tableau de bord est conçu pour promouvoir la meilleure qualité et nuance culturelle avec une bonne rapidité, mais aussi au meilleur coût. Au-delà, il y a le coût que je réalise en n'ayant pas à évaluer quoi que ce soit manuellement — laissez simplement tout se dérouler lorsqu'un nouveau modèle ou une nouvelle version de modèle est publié. Lorsqu'un modèle affirme être vraiment bon sur certains paires linguistiques, il est incroyablement facile de simplement l'ajouter à la configuration et de voir les benchmarks s'exécuter. Je sais que ce qui gagne sera mis en production, soutenu par des preuves concrètes. Pour moi, le développement basé sur les benchmarks est comme avoir une petite équipe d'agents travaillant sur le projet, dans une section spéciale, recherchant, découvrant et évaluant. C'est assez amusant à regarder. C'est comme avoir une petite boutique R&D dans le projet qui fait du travail. Le système de traduction était l'un de mes systèmes préférés — j'ai passé plus de deux ans à le construire de façon intermittente, et il en est enfin à un point où je peux créer un service avec, bien que je l'utilise actuellement en privé.

Le Cycle Vertueux#

Le développement basé sur les benchmarks crée un cycle vertueux :

Clarté par la mesure : La qualité abstraite devient des métriques concrètes
Apprentissage par la comparaison : Chaque benchmark enseigne quelque chose de nouveau sur l'espace problématique
Confiance par les données : Les décisions sont soutenues par des preuves locales vérifiables
Évolution par l'automatisation : Le système s'améliore continuellement

Cette méthode s'est avérée extrêmement efficace pour construire vers l'innovation. Elle est devenue mon approche préférée pour construire des systèmes, surtout dans le domaine de l'IA où le terrain change constamment sous nos pieds. Je ne suis pas non plus un puriste à ce sujet. Le contexte de chaque projet révèle quelle approche fonctionne le mieux.

Diagram source

graph TB
    Define[Définir les métriques]
    Implement[Construire les benchmarks]
    Cache[Mettre en cache les résultats]
    Evaluate[Exécuter les tests A/B]
    Select[Sélectionner le gagnant]
    Generate[Émettre la configuration]
    Deploy[Déployer en production]
    Monitor[Surveiller la performance]

    Define --> Implement
    Implement --> Cache
    Cache --> Evaluate
    Evaluate --> Select
    Select --> Generate
    Generate --> Deploy
    Deploy --> Monitor
    Monitor -.->|Continu| Evaluate

    style Cache fill:transparent,stroke:#333333,stroke-width:2px
    style Select fill:transparent,stroke:#3B82F6,stroke-width:2px
    style Deploy fill:transparent,stroke:#10B981,stroke-width:2px

Copy source

Ce qui est apparu de la pratique#

En mettant en œuvre le développement dirigé par les benchmarks, ces modèles ont émergé comme critiques :

Des métriques claires se sont avérées essentielles: le succès est devenu mesurable à travers plusieurs dimensions lorsque la performance, le coût et la qualité étaient suivis en même temps que la conformité.
Des benchmarks complets ont révélé des problèmes cachés: tester sur toute la gamme d'entrées attendues et de cas limites a révélé des problèmes que les tests partiels ont manqués.
La mise en cache a permis une itération rapide: l'idempotence et la mise en cache agressive ont rendu des milliers de variations de benchmarks possibles sans calculs redondants.
La configuration automatisée a réduit les erreurs: lorsque les résultats des benchmarks générèrent directement la configuration de production, les erreurs de transcription manuelle ont disparu.
Les traces d'audit ont apporté de la clarté: chaque décision de configuration était traçable jusqu'aux données des benchmarks, ce qui rend le débogage et la responsabilité simples.

Où cette approche prospère#

Ma philosophie en matière de développement logiciel est que l'approche devrait toujours évoluer selon le contexte et la nécessité. Le développement guidé par les benchmarks n'aurait aucun sens pour de nombreux projets, en particulier ceux qui n'ont pas de nature expérimentale ou qui ne sont pas directement intégrés avec des systèmes d'IA confrontés à une évolution rapide. Pour moi, la tension du taux d'évolution dans l'espace combinée à la gamme de capacités de l'IA — des sorties complètement déterministes à température zéro aux sorties créatives à températures plus élevées — a créé la nécessité. Avec le système de traduction, l'approche guidée par les benchmarks avait du sens car je pouvais mesurer la qualité, la vitesse et le coût avec des preuves tangibles et une traçabilité documentée. BDD s'est avéré le plus efficace dans les scénarios suivants:

Plusieurs options de mise en œuvre valides (différents modèles d'IA, algorithmes ou approches)
Paysages technologiques en évolution rapide
Exigences d'optimisation multidimensionnelles (qualité, vitesse, coût)
Besoin de décisions techniques explicables
Espaces de configuration complexes
Systèmes nécessitant une adaptation continue aux nouvelles capacités

C'est particulièrement puissant pour les systèmes d'IA, les moteurs de rendu, les problèmes d'optimisation et tout domaine où le "meilleur" dépend du contexte et des compromis. Le contexte de chaque projet révèle quelle approche fonctionne le mieux.

La voie à suivre#

À mesure que l'IA devient de plus en plus intégrée à nos systèmes, les tests statiques deviennent insuffisants. Les preuves suggèrent que les méthodologies qui s'adaptent aussi rapidement que la technologie sous-jacente évolue produisent de meilleurs résultats. Le développement axé sur les benchmarks offre une voie à suivre où nos systèmes s'optimisent continuellement en fonction des preuves empiriques. Le passage du TDD au BDD a été une évolution vers quelque chose de plus puissant, conservant les tests tout en les dépassant. Dans un monde où la meilleure solution change quotidiennement, nos méthodologies de développement doivent être également dynamiques.

Conclusion#

Benchmark-Driven Development représente une évolution dans la façon dont nous construisons et optimisons les systèmes. En rendant les benchmarks génératifs plutôt que simplement évaluatifs, nous créons des systèmes auto-optimants avec des traces d'audit intégrées. Le point clé : au lieu de simplement tester si quelque chose fonctionne, mesurer continuellement ce qui fonctionne le mieux, puis configurer automatiquement le système pour utiliser cette solution optimale. À une époque de changement technologique exponentiel, cette adaptabilité et cette transparence deviennent essentielles pour construire des systèmes innovants. C'est extrêmement gratifiant car j'apprends moi-même de cela. J'ai plus de clarté, et la prise de décision est soutenue par des données locales réelles. Regarder les benchmarks fonctionner est assez amusant — comme avoir un petit laboratoire R&D dans le projet découvrant ce qui fonctionne pendant que je me concentre sur la construction. Pour toute personne construisant des systèmes dans des domaines en évolution rapide, cela offre une approche pragmatique pour atteindre l'excellence grâce à l'optimisation empirique. Adoptez uniquement ce qui sert les objectifs réels. Questionnez tout pour révéler ce qui compte réellement. Lorsque les équipes comprennent pourquoi elles font ce qu'elles font, les résultats parlent d'eux-mêmes. Pour une analyse systématique du cadre et des modèles de mise en œuvre, j'ai documenté les composants clés dans Benchmark-Driven Development: A Framework. C'est le premier article que je partage sur mon site web, et j'espère que vous avez trouvé de la valeur dans le parcours de découverte de cette méthodologie. Prenez soin de vous et bonne chance.#IA#benchmarking#architecture logicielle#tests#innovation#TypeScript#méthodologie de développement#expérientiel#perspectives—Robert E. Beckner III (Merlin)Continuer la lectureSuivantBenchmark-Driven Development: Un cadre pour la configuration des systèmes d'IA Un débat de l'après-midi avec Grok : Le but du savoirDialogueOctober 18, 20258 min de lecture Le Dernier CLI: Reconstruire la Base 51 sur laquelle mes outils ont été construitsDécouverteAugust 19, 202613 min de lecture Qwen 3.8-27B sur un M1 Ultra : De 12.1 à 20.3 tok/s en Mesurant ToutDécouverteAugust 14, 202610 min de lectureProjets connexes175-Page manuscrit chinoisInnovation IA Sphinx CapitalFinTech