Claude automatisiert Evals und Hill-Climbing

Zwei Befehle schließen den Kreislauf aus Bewertung und Verbesserung

Die wichtigste Veränderung ist einfach: Claude verbindet Eval-Design und Anwendungsoptimierung zu einem wiederholbaren Kreislauf. Der offizielle Claude-Beitrag Automating eval design and hillclimbing with Claude beschreibt zwei Befehle: /claude-api build-eval und /claude-api hillclimb.

Der erste erstellt eine Evaluierungs-Suite direkt in der Codebasis. In der Claude-Dokumentation werden exakte Übereinstimmungen, codebasierte Prüfungen und LLM-gestützte Bewertungen genannt, ebenso wie Referenzantworten und Metriken für Genauigkeit und Latenz. Ein Eval ist damit keine separate Tabelle, an die man sich erst vor dem Release erinnert, sondern Teil des aktiven Projekts.

Der zweite Befehl verändert die Anwendung iterativ und bewertet das Ergebnis anhand der bereits erstellten Tests. Laut den Materialien von Claude Platform kann die Suche System-Prompts, Modellauswahl, den Aufwandgrad und weitere API-Parameter umfassen. Dabei werden nicht die Modellgewichte trainiert, sondern Konfigurationen rund um das Modell automatisiert durchsucht.

Ein Detail ist entscheidend: Die Daten werden in Train und Test aufgeteilt, und das Endergebnis wird an einer zurückgehaltenen Stichprobe geprüft. Ohne diese Absicherung könnte Hill-Climbing schnell lernen, bei einem konkreten Beispielsatz zu gewinnen, ohne das Verhalten des Systems insgesamt zu verbessern.

Stand 30. September 2026 verstehe ich diese Veröffentlichung als Erläuterung einer Engineering-Methode und nicht als datiertes Produkt-Release, da die Originalbeschreibung kein Ankündigungsdatum nennt. Die Idee ist jedoch bereits auf Ebene der Prozessarchitektur praktisch nutzbar.

Prompt-Tuning wird zu einem Suchproblem

Die wichtigste Folge: Die Verbesserung einer KI-Anwendung kann sich von einer Reihe subjektiver Änderungen zu einem messbaren Zyklus entwickeln. Besonders gut eignet sich der Ansatz für Aufgaben mit reproduzierbaren Eingaben, überprüfbaren Ergebnissen und einer stabilen Bewertungsfunktion.

Ich würde zuerst drei Punkte prüfen: Leakage von Beispielen zwischen Train und Test, die Instabilität des LLM-Graders und die Frage, ob die Metrik der tatsächlichen Qualität entspricht. Ist die Rubrik schwach, optimiert Hill-Climbing äußerst diszipliniert das Falsche. Auch Kosten, Latenz und Fehler müssen in die Bewertung einfließen, sonst gewinnt eine Konfiguration, die nur bei einer Kennzahl gut ist.

Das ist kein magischer Knopf zur Verbesserung von Claude, sondern ein Weg zu reproduzierbaren Experimenten, die weniger vom Geschmack des Prompt-Autors abhängen. Die schwierigste Komponente bleibt unverändert: Das System ist nur so intelligent, wie sein Eval ehrlich formuliert ist.

Wir haben zuvor erläutert, wie sich die Zuverlässigkeit von LLM-as-a-Judge mit IRT-Metriken messen lässt. Dieses Framework hilft zu prüfen, ob automatisierte Eval-Verbesserungen konstante Qualität statt verrauschter Bewertungen zeigen.