Claude Opus 4.5: Wie sich eine Verbesserung bei langen Aufgaben dem Modell statt dem Harness zuschreiben lässt

Die Frage lautet nicht, welches Modell gewinnt, sondern was sich verändert hat

Claude Opus 4.5 kann in einem Workflow für Programmierung, Dokumentenrecherche oder operative Problemlösung in mehreren Schritten als klare Verbesserung erscheinen. Das Endergebnis eines Agenten gehört jedoch nicht ausschließlich dem Modell. Es hängt von einer vollständigen Konfiguration ab: der Modellversion und -kennung, dem System-Prompt, dem abgerufenen Kontext, den erlaubten Werkzeugen, der Planungsrichtlinie, dem Aktionslimit, Wiederholungen, dem Reasoning-Budget, dem Abbruchkriterium und dem Verifizierer, der die Antwort akzeptiert oder verwirft.

Daher reicht es nicht aus, in einem Produkt ein Modell auszutauschen und anschließend eine höhere Erfolgsquote zu beobachten, um zu schließen, dass Claude Opus 4.5 die Ursache der Differenz ist. Dies kann mit einem erneuerten Retrieval-Korpus, einem zuverlässigeren Werkzeug, mehr erlaubten Turns, einer Auswahl aus mehreren Samples oder einer Änderung des Evaluators zusammenfallen. Auch das Fallprofil, das das System erreicht, kann sich verändert haben. Attribution verlangt, einen Eindruck von Verbesserung in einen kontrollierten Vergleich zu überführen.

Dieser Beitrag soll weder einen allgemeinen Sieger gegenüber anderen Modellen bestimmen noch veröffentlichte Ergebnisse unbesehen auf eine eigene Anwendung übertragen. Sein Ziel ist enger und operativer: Er soll bestimmen, welche Evidenz die Aussage trägt, dass Claude Opus 4.5 in einer konkreten Aufgabe unter einer deklarierten Konfiguration und mit vertretbaren Risiken eine produktiv einsetzbare Verbesserung liefert.

Die tatsächliche Evaluationseinheit ist eine Konfiguration, kein Modellname

Zu sagen, dass eine Ausführung „Claude Opus 4.5“ nutzt, beschreibt nur einen unzureichenden Teil des Experiments. Die Anthropic-Dokumentation weist für das Modell in der direkten API eine bestimmte Kennung aus. Die Dokumentation von Amazon Bedrock zeigt eine andere Kennung für dasselbe Modell über diesen Kanal, und die Google-Cloud-Dokumentation verwendet ein weiteres Identifikationsformat. Diese Unterschiede belegen für sich genommen keine unterschiedlichen Fähigkeiten, verhindern aber, dass der Handelsname als vollständige technische Spezifikation behandelt wird.

Vor dem Vergleich von Ergebnissen empfiehlt es sich, einen unveränderlichen Ausführungsvertrag zu erstellen. Er sollte Anbieter und Region enthalten, wenn diese den Dienst beeinflussen, außerdem die exakte Kennung, das Testdatum, die verwendete Schnittstelle, aktivierte Modalitäten, Generierungsparameter, gegebenenfalls das Reasoning-Budget, das Ausgabelimit und die Fehlerbehandlungsrichtlinie. Ist der Workflow agentisch, muss der Vertrag zusätzlich System-Prompt, Werkzeugversionen, deren Beschreibungen, Berechtigungen, Schrittlimits, Retrieval-Strategie und Abschlusskriterium erfassen.

Der Zweck ist keine Bürokratie. Ohne diesen Vertrag ist ein Ergebnis weder reproduzierbar noch diagnostizierbar. Sinkt die Leistung eine Woche später, kann das Team weder eine Datenvariation von einer Prompt-Änderung, einem restriktiveren Kontingent, einem degradierten Werkzeug noch einer effektiven Änderung des im gewählten Kanal verfügbaren Modells unterscheiden.

Ebenen, die die Attribution häufig verfälschen

Der erste häufige Störfaktor ist der Kontext. Ein Retrieval-System kann die Zahl der bereitgestellten Dokumente, die Qualität der Ausschnitte, die Suchanfrage, das Embedding-Modell oder die Reihenfolge der Quellen ändern. Erhält Claude Opus 4.5 vollständigere Evidenz als die Baseline, misst die Evaluation eine kombinierte Intervention. Bei Dokumentenrecherche sollte daher nicht nur die endgültige Antwort, sondern auch die Menge der abgerufenen Dokumente aufbewahrt werden.

Der zweite Faktor ist der Werkzeug-Harness. Ein Agent, der Code abfragen, Tests ausführen, Incidents durchsuchen oder reversible Änderungen anwenden kann, verhält sich nicht wie ein Modell in einer isolierten Unterhaltung. Eine neue Werkzeugbeschreibung, ein zusätzlich erlaubter Aufruf oder eine tolerantere Wiederholungsrichtlinie kann einen größeren Effekt haben als der Austausch des Modells. Die Erfolgsquote sollte nach Aktionen, Werkzeugfehlern, Wiederholungen und ohne Eingriff gelösten Fällen aufgeschlüsselt werden.

Der dritte Faktor ist die Auswahl. Die beste Antwort aus mehreren Antworten auszuwählen, Samples abstimmen zu lassen oder ein anderes Modell die Ausgabe prüfen zu lassen, kann die aggregierte Qualität steigern. Diese Techniken können angemessen sein, müssen aber als Teil der evaluierten Lösung ausgewiesen werden. Sie dürfen nicht als pass@1-Fähigkeit des Modells dargestellt werden. Dieselbe Vorsicht gilt für einen Verifizierer, der teilweise korrekte Antworten akzeptiert oder Verzerrungen mit dem Generator teilt.

Schließlich ist der Rechenaufwand Teil der Erklärung. Eine Verbesserung durch mehr Schritte, mehr Reasoning-Tokens, mehr Werkzeugaufrufe oder mehr Kandidaten entspricht nicht notwendigerweise einer effizienten Verbesserung. Sie kann eine valide Entscheidung sein, wenn sie menschliche Prüfung oder operatives Risiko wesentlich reduziert. Dafür müssen jedoch die Kosten je korrekt gelöstem Fall gemessen werden, nicht nur die durchschnittlichen Kosten je Anfrage.

Was offizielle Evaluationen anzeigen können – und was sie nicht belegen

Die Ankündigung von Anthropic zu Claude Opus 4.5 nennt methodische Details zu den kommunizierten Evaluationen, darunter Thinking-Budgets, Kontext, Aufwandsstufen, Sampling-Parameter, unabhängige Wiederholungen und testabhängige Ausnahmen. Diese Information ist relevant, weil sie ein veröffentlichtes Ergebnis als Produkt eines Protokolls interpretierbar macht, nicht als kontextlose Eigenschaft des Modells.

Die System Card des Anbieters liefert zusätzliche Informationen über Fähigkeits- und Sicherheitsevaluationen sowie über den Deployment-Ansatz. Diese Quellen helfen dabei, den vom Entwickler des Modells erklärten Umfang zu verstehen und Testhypothesen zu formulieren. Sie ersetzen keine Validierung im Repository, Korpus, mit den Werkzeugen und unter den Risikokriterien jeder einzelnen Organisation.

Beim Lesen eines Benchmarks sollte das Team fragen, ob eine einzelne Antwort oder eine Auswahl unter mehreren gemessen wurde, ob Werkzeuge eingesetzt wurden, welcher Kontext bereitgestellt wurde, wie eine Enthaltung bewertet wird und ob das Ausführungsbudget vergleichbar war. Eine Punktzahl kann aufschlussreich sein, ohne übertragbar zu sein. Insbesondere kann eine geschlossene Aufgabe mit automatischem Verifizierer eine offene Operation nicht abbilden, bei der Nachvollziehbarkeit der Evidenz, Berechtigungen und Reversibilität von Aktionen wichtig sind.

Attributionsprotokoll für lange Workflows

Das Protokoll beginnt mit der Definition der zu treffenden Entscheidung. Zum Beispiel: dem Agenten erlauben, Codekorrekturen zur menschlichen Prüfung vorzuschlagen, Vorgänge mit verpflichtender Enthaltung zu klassifizieren oder die Zahl der Fälle auszuweiten, die er ohne Eskalation untersuchen kann. Die primäre Kennzahl muss dieser Entscheidung entsprechen und nicht einer leicht messbaren, aber entkoppelten Größe wie der Antwortlänge.

Anschließend wird eine reproduzierbare Baseline aufgebaut. Sie kann das derzeit eingesetzte Modell oder eine frühere Konfiguration von Claude Opus 4.5 sein, muss aber mit derselben eingefrorenen Fallmenge ausgeführt werden. Bei Eingaben, die sich im Zeitverlauf ändern, etwa Websuchen, Repository-Zustände oder transaktionale Werkzeuge, sollten Snapshots, Simulatoren oder reproduzierbare Protokolle verwendet werden. Andernfalls führt die Umgebung nicht zurechenbares Rauschen ein.

Die erste Intervention darf nur eine Variable ändern: die Modellkennung. Der übrige Vertrag bleibt erhalten. Erfordert das neue Modell ein anderes Aufrufformat, muss diese Anpassung minimal sein, geprüft werden und als Abweichung dokumentiert sein. Nach der Messung dieser isolierten Änderung kann das Team realistischere vollständige Konfigurationen bewerten, etwa einen optimierten Prompt oder ein höheres Budget. Diese müssen jedoch als Kombinationen und nicht als reiner Modelleffekt gekennzeichnet werden.

Wiederholungen sind notwendig, da Ausgaben und Werkzeugpfade variieren können. Die Zahl der Durchläufe und die gewählte Aggregation müssen vor der Einsicht in die Ergebnisse deklariert werden. Neben Durchschnittswerten sollten Verteilungen, materielle Fehler und Unterschiede nach Schwierigkeitsgrad gespeichert werden. Eine aggregierte Verbesserung, die in mehrdeutigen Fällen verschwindet, kann für einen Hochrisiko-Workflow unzureichend sein.

Kennzahlen, die nicht zu einem einzigen Score verdichtet werden sollten

Die zentrale Kennzahl ist meist der vollständige Fallerfolg: Antwort oder Aktion erfüllt alle anwendbaren Kriterien und führt keinen materiellen Fehler ein. Er muss von teilweiser Korrektheit unterschieden werden. Bei einer technischen Diagnose ist die Identifikation einer plausiblen Ursache nicht gleichbedeutend mit dem Vorschlag einer Korrektur, die Tests besteht und die Einschränkungen des Repositorys respektiert. Bei einer Recherche ist das Zusammenfassen von Dokumenten nicht gleichbedeutend damit, eine Schlussfolgerung mit relevanter und im System korrekt zugeordneter Evidenz zu stützen.

Die korrekte Enthaltung verdient eine eigene Messgröße. Ein Agent, der einen Fall außerhalb seines Geltungsbereichs oder mit unzureichender Evidenz ablehnt, kann sicherer sein als einer, der eine überzeugende, aber unbegründete Antwort erzeugt. Ebenso muss die Rate korrekter Aktionen gemessen werden, einschließlich erlaubter Aufrufe, gültiger Parameter und erwarteter Wirkungen. Diese Trennung verhindert, dass eine hohe Abschlussrate oder intensive Werkzeugnutzung unangemessene Aktionen verdeckt.

Für wirtschaftliche und operative Tragfähigkeit sollten Kosten je korrekt gelöstem Fall, die Latenzverteilung einschließlich des oberen Bereichs, Schrittzahl, Tokens, Werkzeugaufrufe und Minuten menschlicher Prüfung erfasst werden. Vermiedene Prüfung darf nur dann gezählt werden, wenn das Ergebnis ein unabhängiges Kriterium erfüllt und der Prozess diese Prüfung tatsächlich auslassen oder reduzieren kann. Das ist eine geschäftliche Schlussfolgerung, keine Eigenschaft, die das Modell selbst liefert.

Drei repräsentative Tests für ein instrumentiertes Team

Der erste Test kann eine Dokumentenanalyse aus mehreren Quellen abdecken. Die Menge sollte Vorgänge mit übereinstimmender, widersprüchlicher und unzureichender Evidenz enthalten. Die Evaluation sollte sich nicht darauf beschränken, ob die Schlussfolgerung einem Label entspricht: Sie muss prüfen, ob das System relevantes abgerufenes Material nutzt, Unsicherheit erklärt, wenn dies erforderlich ist, und keine Tatsachen behauptet, die in der Akte fehlen. Fälle ohne eindeutige Antwort sind besonders nützlich, um Enthaltung zu messen.

Der zweite Test kann eine mehrstufige technische Diagnose in einem eingefrorenen Repository sein. Jeder Fall sollte Symptom, Einschränkungen und verfügbare Tests definieren. Der Agent darf Dateien inspizieren und Werkzeuge in einer isolierten Umgebung ausführen, doch Repository-Versionen, erlaubte Befehle und Iterationslimit müssen identisch sein. Die Evaluation sollte Problemlokalisierung, vorgeschlagene Korrektur, Testergebnis und unerwünschte Änderungen getrennt bewerten.

Der dritte Test kann eine Aktion mit reversiblem Werkzeug simulieren, etwa das Erstellen eines Entwurfs, die Vorbereitung einer genehmigungspflichtigen Änderung oder die Aktualisierung eines Teststatus. Solche Fälle zeigen, ob das Modell die Schnittstelle korrekt verwendet, bei fehlenden Daten um Klarstellung bittet und Berechtigungen respektiert. Gutes Verhalten in einer Simulation sollte nicht ohne spezifische Validierung von Kontrollen, Autorisierung und Fehlerwiederherstellung auf irreversible Autonomie übertragen werden.

Gemischte Ergebnisse interpretieren und ein Deployment entscheiden

Gemischte Ergebnisse sind kein Scheitern der Evaluation; oft sind sie die nützlichste Schlussfolgerung. Claude Opus 4.5 kann die Analysequalität in komplexen Fällen erhöhen und zugleich seine Kosten oder Latenz bei Routineanfragen nicht ausgleichen. Es kann Diagnosefehler reduzieren, aber mehr unnötige Aktionen ausführen. Es kann einen anderen Prompt oder ein anderes Werkzeug benötigen, um sein bestes Ergebnis zu erreichen. In jedem dieser Fälle besteht die richtige Entscheidung darin, die Nutzung zu segmentieren, statt einen Durchschnitt in eine universelle Richtlinie zu verwandeln.

Ein schrittweises Deployment sollte zunächst Umfang, Berechtigungen und Fallpopulation begrenzen. Ein Canary ermöglicht, Ergebnisse unter realen Bedingungen zu vergleichen und zugleich einen Rücknahmepfad zu erhalten. Vorab sollte festgelegt werden, welche Kennzahlen eine Pause erzwingen: mehr nicht autorisierte Aktionen, ein Rückgang gültiger Evidenz, schlechtere Enthaltung, mit dem Dienst unvereinbare Latenz, Mehrkosten je gelöstem Fall oder mehr menschliche Prüfung. Die konkreten Schwellenwerte hängen von der Domäne ab und müssen von den Risikoträgern genehmigt werden.

Es sollte ausreichend Evidenz zur Auditierung der Entscheidung aufbewahrt werden: Vertragsversion, Evaluationsmenge, geschützte Aktionstraces mit sensiblen Daten, Ergebnisse je Fall, Regeln des Verifizierers, Ausschlusskriterien und Begründung der Änderungen. Diese Evidenz ist wertvoller als eine allgemeine Verbesserungsbehauptung, da sie die Reproduktion der Entscheidung, die Erkennung von Regressionen und die Prüfung ermöglicht, ob die Leistung bei Änderungen von Daten, Werkzeugen oder Betriebsbeschränkungen erhalten bleibt.

Die wichtigste Unsicherheit ist unvermeidbar: Keine endliche Testmenge deckt alle zukünftigen Fälle ab. Zudem können sich die von Anbietern und Kanälen dokumentierten Bedingungen weiterentwickeln. Die angemessene Antwort ist weder, Stabilität anzunehmen, noch jede Einführung abzulehnen, sondern die Konfiguration zu versionieren, Evaluationen bei relevanten Änderungen zu wiederholen und eine Aufsicht beizubehalten, die der Reversibilität und Wirkung der Aktionen angemessen ist.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.