Benchmark-getriebene Entwicklung: Mehr als TDD für KI-Systeme
Wie Benchmark-getriebene Entwicklung sich von TDD weiterentwickelt hat, um das exponentielle Tempo von KI durch datenbasierte Konfigurationsgenerierung und empirische Optimierung zu bewältigen.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
Ich entdeckte Benchmark-getriebene Entwicklung Anfang 2025, während ich ein Übersetzungssystem entwickelte, an dem ich seit zwei Jahren arbeitete, sowie mehrere Dokumenten-Render-Engines. Das Übersetzungssystem wurde das Labor, in dem diese Methodik kristallisierte. Ich arbeitete seit etwa 2023 mit KI-Systemen und als ich Fortschritte machte, erkannte ich, dass KI-Modelle sich so schnell entwickelten, dass traditionelle Ansätze nicht mithalten konnten.Dies war zur Zeit, als Funktionsaufrufe gerade als Innovation auf dem Markt aufkamen, bevor autonome Agenten wirklich existierten. Ich bewertete verschiedene Sprachpaare, baute komplexe Pipelines und bemerkte, dass ich eine Möglichkeit brauchte, mit der das Projekt selbst die Fähigkeiten bis auf das Wesentliche messen konnte. Das Problem war nicht nur zu prüfen, ob etwas funktionierte—es ging darum herauszufinden, was am besten funktionierte, wenn sich die Landschaft alle paar Wochen veränderte..Von Tests zu Simulationen#
Ich habe immer den Wert von Tests verstanden, besonders beim Aufbau von Unternehmenssystemen für die Regierung, wo strenge Anforderungen und vollständig finanzierte Verträge nach Nachweis verlangten. Aber als TDD bei den Projekten, an denen ich arbeitete, aufgezwungen wurde, erlebte ich etwas Wichtiges: Frameworks funktionieren nur, wenn Teams sie tatsächlich annehmen. Eine vollständige Einführung zu erzwingen, macht selten Sinn. Was ich gelernt habe, ist, dass der beste Ansatz häufig hybrid ist – nur so viel übernehmen, wie nötig ist. Ich richtete mich eher auf das Testen von Kernfunktionen als auf umfassende Unit-Abdeckung aus. Warum tausende verstreute Tests pflegen, wenn ein Simulationsskript unter 1000 Zeilen den gesamten Benutzerfluss validieren könnte? Für eine politische Wahlkampf-Anwendung baute ich eine Simulation, die Mock-Teams erstellte, Wahlkampfmitarbeiter simulierte, die ein- und austreten, realistische Arbeitsbelastungen generierte und das System in großem Maßstab belastete. Dies hat alles offenbart: UI-Verhalten, Diagrammerstellung, Datenintegrität bei Grenzwerten. Ein Skript gab mir mehr Vertrauen als verstreute Unit-Tests je könnten. In meinen 25 Jahren Programmieren habe ich die letzten 10-12 tief bewusst gemacht, wie wertvoll ein großartiges Scorecard sein kann. Ich verwendete Scorecards lange bevor GPT existierte, und sie mit KI in den letzten drei Jahren erneut zu betrachten, war faszinierend. Diese Simulationserfahrungen legten den Grundstein für das, was Benchmark-Driven Development wurde.Der Moment, an dem sich alles veränderte#
Der wahre Durchbruch geschah, als ich realisierte, was alles veränderte: die Benchmarking nur eine Konfiguration ausgeben konnte, die direkt in die Produktion geht. Es ist bereits getestet, genau dort, bereit, mit den Eingabeaufforderungen und allem einzufügen. Das war die große Erkenntnis. Dies entstand aus der Konfrontation mit einem grundlegenden Problem des Übersetzungssystems. KI-Anbieter behaupteten Unterstützung für Dutzende von Sprachen, aber in welchem Umfang und in welcher Qualität? Diese Informationen waren nicht gut dokumentiert, und ich habe durch Erfahrung gelernt, dass ich die Angaben der Anbieter nicht vollständig vertrauen konnte – und ich sollte es nicht. Deshalb habe ich eine Benchmark-Bewertungs-Schleife erstellt, die im Projekt lebt. Ich konnte ihm einen Service und ein Modell geben, und es würde bewerten, welche Sprachen es tatsächlich gut beherrscht – nicht das, was der Anbieter behauptet hat, sondern was empirische Beweise zeigten. Der Prozess ist idempotent: gleiche Eingabe, gleiche Ausgabe, konsequent zwischengespeichert für schnelle Ergebnisse. Beim Ändern von Eingabeaufforderungen führen wir A/B-Tests durch, um die besten zu entdecken. Modelle, die konsequent fehlten, wurden für bestimmte Sprachpaare auf die schwarze Liste gesetzt oder abgewertet, was das Benchmarking produktiver machte. KI zur Erstellung von KI-Integrationen zu nutzen, erwies sich als unglaublich mächtig. Mit Funktionsaufrufen und frühen Frameworks, die sich zu Agenten entwickeln würden, konnte ich Benchmarks mit KI erstellen, komplett mit Scorecards und Bewertungen. Was ich über Modelle und Sprachfähigkeiten entdeckt habe, unterschied sich erheblich von den Angaben der Anbieter. Ich musste näher am Metall, näher am tatsächlichen Beweis sein.graph TB
Problem[Anbieteransprüche]
Loop[Bewertungs-Schleife]
Cache[Idempotenter Cache]
ABTest[A/B-Test-Eingabeaufforderungen]
Demote[Blacklist schlägt fehl]
Discovery[Emit nach Prod]
Problem -->|Erstellen| Loop
Loop -->|Aktivieren| Cache
Cache -->|Schnell| ABTest
Cache -->|Verfolgen| Demote
ABTest -->|Durchbruch| Discovery
Demote -->|Optimieren| Discovery
style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy sourceWas Benchmark-Driven Development eigentlich ist#
Benchmark-Driven Development geht über die Validierung hinaus und wird zu einem generativen Prozess. Wo Tests die Richtigkeit prüfen, vergleichen Benchmarks die Leistung über mehrere Dimensionen hinweg. Wichtiger noch, in BDD geben Benchmarks die Konfiguration aus, die das Produktionssystem antreibt. Was ich wirklich sagen will, ist folgendes: statt nur zu prüfen, ob der Code funktioniert, bewertet das System kontinuierlich, welcher Ansatz am besten funktioniert, und konfiguriert sich anschließend automatisch, um diesen optimalen Ansatz zu verwenden. Nimm das, was funktioniert, und baue etwas, das tatsächlich deinem Kontext dient. Testgetriebene Entwicklung:graph TB
Test[Schreibe Test]
Code[Schreibe Code]
Pass[Test erfolgreich]
Test --> Code
Code --> Pass
style Pass fill:transparent,stroke:#10B981,stroke-width:2pxCopy sourcegraph TB
Bench[Führe Benchmarks aus]
Compare[Vergleiche Ergebnisse]
Config[Erzeuge Konfiguration]
Deploy[Produktion]
Bench --> Compare
Compare --> Config
Config --> Deploy
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
style Config fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy sourceIm Übersetzungssystem#
Im Übersetzungssystem habe ich anstelle eines einzelnen KI-Modells und der Hoffnung, dass es bei allen Sprachpaaren gut abschneidet, ein umfassendes Benchmark-System entwickelt, das mehrere Modelle anhand von drei Hauptmetriken bewertet:- Qualität - Übersetzungsgenauigkeit und Erhaltung kultureller Nuancen
- Geschwindigkeit - Antwortzeit für verschiedene Textlängen
- Kosten - Preis pro Token oder pro Anfrage
graph TB
Input[Testkorpus]
Models[KI-Modelle]
Bench[Benchmark-Suite]
Metrics[Ergebnis: Q/S/C]
Winner[Beste Konfiguration]
ProdConfig[Produktion]
Input --> Bench
Models --> Bench
Bench -->|Qualität| Metrics
Bench -->|Geschwindigkeit| Metrics
Bench -->|Kosten| Metrics
Metrics --> Winner
Winner -->|Auto-Generieren| ProdConfig
style Winner fill:transparent,stroke:#3B82F6,stroke-width:2px
style ProdConfig fill:transparent,stroke:#10B981,stroke-width:2pxCopy sourceDie Bewertung des Bewertenden#
Eine entscheidende Innovation war die Implementierung dessen, was ich „bewerte den Bewertenden zuerst“ nenne. Da ich etwas mit Spanisch vertraut war, konnte ich leicht kulturelle Nuancenverluste erkennen, die einfachere Bewertungskriterien verpassten.. Die Lösung bestand darin, teurere, hochwertigere Modelle speziell zur Bewertung der Scorecard selbst einzusetzen, um sicherzustellen, dass die Benchmarks das gemessen haben, was wirklich zählt.. Eval‑Schleifen zu haben und intelligenter Modelle zur Bewertung der Bewertenden zu verwenden, wurde zu einer mächtigen Technik.. Einen guten Bewertenden für etwas zu bekommen, ist in einem Projekt eine erstaunliche Schöpfung – ein Feat, eine Herausforderung und ein Erfolg zugleich.. Dieser Meta‑Bewertungsprozess verfeinerte die Scorecard iterativ, und ich konnte ein robustes Bewertungsrahmenwerk schaffen, dem man tatsächlich vertrauen konnte, um automatisierte Entscheidungen zu treffen.. Meiner Erfahrung nach ist hier der Ort, an dem die meisten Teams scheitern: sie vertrauen ihren Evaluatoren, ohne sie zuerst zu beurteilen.graph TB
Basic[Grundlegende Metriken]
Human[Menschliche Prüfung]
Premium[Premium-Modell]
Refined[Verfeinerte Scorecard]
Trust[Vertrauenswürdiger Bewertender]
Basic -->|Gefundene Lücken| Human
Human -->|Einblicke| Premium
Premium -->|Bewerten| Basic
Premium --> Refined
Refined -->|Iterieren| 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:2pxCopy sourceWenn Benchmarks Konfiguration werden#
Als ich erkannte, dass Benchmarks Produktionskonfigurationen erzeugen können, klickte alles. Das Benchmark existiert neben dem Code und kann sich auf jede Ebene der Pipeline oder jedes Bauteil im Engine konzentrieren. Es kann Mock-Komponenten erstellen, Variationen testen und wenn die Scores sich verbessern, eine Konfiguration direkt in den Quellcode ausgeben. Diese Konnektivität wurde wesentlich. KI entwickelt sich so schnell, dass es sich lohnt, Benchmarking im Projekt zu haben. Wenn ein neues Modell mit besseren Wirtschaftlichkeits- oder Geschwindigkeitswerten veröffentlicht wird, bleiben die Scorecards gleich und das Benchmarking geht weiter. Die Qualitätsgewinne sind unglaublich. Die erfolgreichen Kombinationen — Modellwahl, Prompt-Engineering, Parameteranpassung — die bereits mit vollständigen Prüfpfaden getestet wurden, werden in die Konfiguration ausgegeben und gehen direkt in die Produktion. Mit dem Übersetzungssystem erhielt ich ein unglaubliches Bewusstsein für die Modellfähigkeiten bei Sprachübersetzungen. Gewinner wurden automatisch zur Produktionskonfiguration, immer mit dem besten Gleichgewicht von Qualität, Preis und Erhaltung kultureller Nuancen. Dies schuf einen Prüfpfad, der genau zeigt, warum jede technische Entscheidung getroffen wurde, unterstützt von empirischen Daten. Wenn jemand fragt: "Warum Modell X für Spanisch-zu-Französisch, aber Modell Y für Chinesisch-zu-Englisch?" die Antwort liegt in den Benchmark-Ergebnissen.Prompt Engineering durch Daten#
Das System hat sich entwickelt, um nicht nur die Modellauswahl, sondern auch das Prompt Engineering selbst zu benchmarken. Ich konnte die Benchmarks erstellen und anschließend sogar verschiedene Teile an KI-Prompts arbeiten lassen, A/B-Tests verschiedener Prompts systematisch durchführen. Klare Gewinner traten auf, basierend auf den etablierten Metriken. Dies entfernte die Schätzarbeit aus dem Prompt Engineering und ersetzte Intuition durch datenbasierte Entscheidungen.Die Wirtschaftlichkeit der kontinuierlichen Entdeckung#
Es gibt einen signifikanten Kosteneinsparungsaspekt bei diesem Ansatz. Die Scorecard ist darauf ausgelegt, die beste Qualität und kulturelle Nuancen mit guter Geschwindigkeit zu fördern, aber auch zu den bestmöglichen Kosten. Darüber hinaus spare ich Kosten, indem ich nichts manuell bewerten muss—ich lasse alles einfach laufen, wenn ein neues Modell oder eine neue Modellversion veröffentlicht wird. Wenn ein Modell behauptet, es sei besonders gut bei bestimmten Sprachpaaren, ist es unglaublich einfach, es einfach zur Konfiguration hinzuzufügen und die Benchmarks laufen zu lassen. Ich weiß, dass alles, was gewinnt, in die Produktion übernommen wird, unterstützt durch harte Beweise. Für mich ist benchmark‑getriebene Entwicklung wie ein kleines Team von Agenten, die im Projekt in einer speziellen Abteilung forschen, entdecken und evaluieren. Es macht ziemlich Spaß, zuzusehen.. Es ist, als hätte man ein kleines F&E-Labor im Projekt, das arbeitet.. Das Übersetzungssystem war eines meiner Lieblingssysteme – ich habe über zwei Jahre damit gebaut, abwechselnd, und es ist endlich an einem Punkt, an dem ich einen Service damit erstellen kann, obwohl ich es derzeit privat verwende..Der tugendhafte Kreislauf#
Benchmark-gesteuerte Entwicklung schafft einen tugendhaften Kreislauf:- Klarheit durch Messung: Abstrakte Qualität wird zu konkreten Kennzahlen
- Lernen durch Vergleich: Jedes Benchmark lehrt etwas Neues über den Problemraum
- Vertrauen durch Daten: Entscheidungen werden durch lokale, überprüfbare Beweise unterstützt
- Evolution durch Automatisierung: Das System verbessert sich kontinuierlich selbst
graph TB
Define[Kennzahlen definieren]
Implement[Benchmarks erstellen]
Cache[Ergebnisse zwischenspeichern]
Evaluate[A/B-Tests durchführen]
Select[Gewinner auswählen]
Generate[Konfiguration ausgeben]
Deploy[In Produktion deployen]
Monitor[Leistung überwachen]
Define --> Implement
Implement --> Cache
Cache --> Evaluate
Evaluate --> Select
Select --> Generate
Generate --> Deploy
Deploy --> Monitor
Monitor -.->|Kontinuierlich| 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:2pxCopy sourceWas aus der Praxis hervorging#
Durch die Umsetzung von Benchmark-Driven Development tauchten diese Muster als kritisch auf:- Klare Messgrößen erwiesen sich als wesentlich: Der Erfolg wurde über mehrere Dimensionen messbar, wenn Leistung, Kosten und Qualität neben der Richtigkeit verfolgt wurden.
- Umfassende Benchmarks offenbarten versteckte Probleme: Das Testen über den gesamten erwarteten Eingangsbereich und Randfälle offenbarte Probleme, die teilweise Tests verpassten.
- Caching ermöglichte schnelle Iteration: Idempotenz und aggressives Caching machten tausende Benchmark-Variationen ohne redundante Berechnungen machbar.
- Automatisierte Konfiguration reduzierte Fehler: Als Benchmark-Ergebnisse direkt die Produktionskonfiguration erzeugten, verschwanden manuelle Transkriptionsfehler.
- Audit-Trails lieferten Klarheit: Jede Konfigurationsentscheidung konnte auf Benchmark-Daten zurückverfolgt werden, wodurch Fehlersuche und Rechenschaftspflicht unkompliziert wurden.
Wo dieser Ansatz gedeiht#
Meine Philosophie in Bezug auf Softwareentwicklung ist, dass der Ansatz sich immer an den Kontext und die Notwendigkeit anpassen sollte.. Benchmark-gesteuerte Entwicklung macht für viele Projekte keinen Sinn, insbesondere für solche, die keine experimentelle Natur haben oder nicht direkt in KI-Systeme eingebunden sind, die einer schnellen Weiterentwicklung ausgesetzt sind.. Für mich entstand die Notwendigkeit durch die Spannung zwischen dem Evolutionsrhythmus im Raum und dem Spektrum der KI-Fähigkeiten – von vollständig deterministischen Ausgaben bei Temperatur Null bis hin zu kreativen Ausgaben bei höheren Temperaturen.. Mit dem Übersetzungssystem machte der benchmark-gesteuerte Ansatz Sinn, weil ich Qualität, Geschwindigkeit und Kosten mit harten Beweisen und einer nachvollziehbaren Spur messen konnte.. BDD hat sich in Szenarien mit:- Mehrere gültige Implementierungsoptionen (verschiedene KI-Modelle, Algorithmen oder Ansätze)
- Schnell wandelnde Technologielandschaften
- Mehrdimensionale Optimierungsanforderungen (Qualität, Geschwindigkeit, Kosten)
- Bedarf an erklärbaren technischen Entscheidungen
- Komplexe Konfigurationsräume
- Systemen, die kontinuierliche Anpassungen an neue Fähigkeiten erfordern