Muster werden geladen…
Eval-getriebene Entwicklung (Agent-CI)(EDD)
Die Disziplin im Entwicklungslebenszyklus, Agenten und Prompts zuerst gegen Evals zu bauen. Sorgfältig kuratierte Golden-Datasets (etwa 50 bis 500 Fälle, gewichtet nach bekannten Fehlermodi) werden zusammen mit den Prompts versioniert, bei jedem Pull Request als Regressionssuite ausgeführt, und Merge oder Promotion sind an Metrik-Schwellenwerte gebunden. Die Pipeline fixiert die Versionen von Modell und Judge, sodass ein stilles modellseitiges Update aufseiten des Anbieters als Regression erkannt statt unbemerkt übernommen wird, und staffelt ihre Prüfungen als Lint, dann Offline-Eval, dann ein Kosten-Gate, bevor eine Änderung gemergt werden kann. Zu unterscheiden von agent-observability-tracing, das Laufzeit-Telemetrie und kein Gate vor dem Merge ist, und von festen öffentlichen Benchmarks, die keine teameigenen Regressionssuiten in der CI sind.
In 30 Sekunden
- Was
- Versionierte Golden Datasets laufen bei jedem PR als Regressionssuiten und machen den Merge von Metrik-Schwellenwerten abhängig, mit fest gepinnten Modell- und Judge-Versionen.
- Wann einsetzen
- Teams, die Agenten ausliefern und dabei stille Modell-Updates erkennen, bekannte Fehlermodi durchgehend abdecken und Prompt-Änderungen messbar validieren müssen.
- Achtung
- Golden Datasets veralten oder passen nicht mehr zu den echten Produktionsfehlern, wenn sie nicht aktiv gepflegt und auf die aktuellen Fehlermodi gewichtet werden.
Fragen Sie den KI-Experten zu diesem Pattern
Öffnet den Assistenten mit vorbereiteter Frage. Sie prüfen sie vor dem Senden.
Eval-getriebene Entwicklung (Agent-CI): Überblick
Die Disziplin im Entwicklungslebenszyklus, Agenten und Prompts zuerst gegen Evals zu bauen. Sorgfältig kuratierte Golden-Datasets (etwa 50 bis 500 Fälle, gewichtet nach bekannten Fehlermodi) werden zusammen mit den Prompts versioniert, bei jedem Pull Request als Regressionssuite ausgeführt, und Merge oder Promotion sind an Metrik-Schwellenwerte gebunden. Die Pipeline fixiert die Versionen von Modell und Judge, sodass ein stilles modellseitiges Update aufseiten des Anbieters als Regression erkannt statt unbemerkt übernommen wird, und staffelt ihre Prüfungen als Lint, dann Offline-Eval, dann ein Kosten-Gate, bevor eine Änderung gemergt werden kann. Zu unterscheiden von agent-observability-tracing, das Laufzeit-Telemetrie und kein Gate vor dem Merge ist, und von festen öffentlichen Benchmarks, die keine teameigenen Regressionssuiten in der CI sind.
- Version-controlled golden datasets (~50-500 cases) weighted toward known failure modes
- Regression suite runs on every pull request; merge gated on metric thresholds
- Pinned model and judge versions so silent provider updates surface as regressions
- Staged CI pipeline: lint, then offline eval, then cost gate before merge
- LLM-as-judge and code-based scorers combined per failure dimension
- Prompt and dataset changes reviewed together as a single diff
Den Agent-Evals-Field-Guide erhalten
Alle 25 Methoden zur Agentenbewertung in einem Leitfaden: welcher Benchmark was misst, wann ein öffentlicher Score in die Irre führt und wie Sie Evals aus Ihren eigenen Fehlern bauen. Der Link kommt mit Ihrer Bestätigung, zusammen mit dem wöchentlichen Agent Architect.
Wöchentliche E-Mail, Abmeldung mit einem Klick. Ihre Adresse wird nur für das Briefing verwendet.
Quellen
Die Veröffentlichungen, Spezifikationen und Repositories, auf denen dieses Muster beruht.
Vom Ingenieur hinter diesem Katalog
Finden Sie heraus, was Ihre Evals übersehen
Einen Agenten zu messen ist schwerer, als ihn auszuliefern, und die meisten Suiten bleiben grün, während die Produktion abdriftet. Lassen Sie Ihr Evaluations-Setup durchgehend prüfen: was Sie heute messen, was Sie noch nicht sehen, und welche Regressionen Ihre Suite derzeit durchlässt.
750 € statt 1.500 €, eine Woche, schriftlicher Bericht und Walkthrough-Call, bis 30. September