Ilustración editorial para Claude Sonnet 4.5 en ciencias de la vida: qué demuestran sus resultados y cómo revalidarlos
Imagen generada con gpt-image-2.5-sunburst para InferamaQuelle ↗
01

Was bedeutet es, eine menschliche Referenz in einem begrenzten Test zu übertreffen?

Ein Benchmark-Ergebnis beantwortet eine klar umrissene Frage: Wie hat ein Modell bei einem bestimmten Datensatz, einer bestimmten Aufgabe, bestimmten Anweisungen und unter bestimmten Bedingungen abgeschnitten? Daraus folgt nicht automatisch eine wesentlich weiter reichende Antwort auf die Frage, ob das Modell die Protokolle eines Labors korrekt lesen, dessen Daten interpretieren und wissenschaftliche Schlussfolgerungen zuverlässig unterstützen kann. Wer beurteilen möchte, ob Claude Sonnet 4.5 in einem realen Arbeitsablauf hilfreich sein könnte, muss diese beiden Aussagen auseinanderhalten.

Anthropics Systemkarte zu Claude Sonnet 4.5 weist Ergebnisse für mehrere LAB-Bench-Aufgaben aus, darunter Protocol QA, FigQA, SeqQA und Cloning, und führt außerdem eine menschliche Referenz auf. In der angegebenen Grafik zu Protocol QA erzielt Sonnet 4.5 bei k=10 einen Wert von 0,833; für Sonnet 4 wird 0,741 ausgewiesen. Das sind Ergebnisse, die Anthropic für eine veröffentlichte Evaluierung angibt. Sie sind keine unabhängige Validierung der Leistung in beliebigen Dokumenten oder Laboren.

Dass ein Modell in einer bestimmten Evaluierung eine menschliche Referenz übertrifft, bedeutet daher weder, dass es Forschenden insgesamt überlegen ist, noch dass es jede Frage richtig beantwortet oder dass seine Antworten sicher als Versuchsanweisungen verwendet werden können. Die Interpretation hängt davon ab, welche Fragen gestellt, wie sie bewertet und wer in die menschliche Vergleichsgruppe aufgenommen wurde. Die verfügbaren Quellen reichen nicht aus, um das Ergebnis auf andere Dokumente, Teams oder Entscheidungen zu übertragen.

02

Das evaluierte Modell genau bestimmen

„Claude Sonnet 4.5“ bezeichnet eine Modellfamilie beziehungsweise eine kommerzielle Modellversion. Für eine reproduzierbare Evaluierung muss jedoch festgehalten werden, welche Modellkennung tatsächlich die Anfrage erhalten hat. Anthropics Dokumentation unterscheidet zwischen datierten Kennungen und Aliasnamen und nennt für Sonnet 4.5 den Snapshot claude-sonnet-4-5-20250929. Wer diese Kennung zusammen mit Datum und Testkonfiguration dokumentiert, verringert Unklarheiten beim Vergleich von Ergebnissen.

Diese Vorsicht gilt auch für den Vergleich mit späteren Modellen. Die bereitgestellte offizielle Quelle zu Sonnet 5 kündigt dieses Modell an, belegt jedoch nicht, dass es bei denselben LAB-Bench- oder BixBench-Aufgaben mit demselben Protokoll und Datensatz wie Sonnet 4.5 evaluiert wurde. Auch lässt sich anhand der vorliegenden Dokumentation keine gleichwertige Vergleichsmessung für Sonnet 4.6 behaupten. Dass eine spätere Version erscheint, ist für sich genommen kein Beleg für eine Verbesserung bei diesen Aufgaben.

Ein sinnvoller Vergleich muss Aufgabe und Bedingungen festlegen, statt lediglich Modellnamen gegenüberzustellen. Wenn sich der Fragenkatalog, die Zahl der Beispiele im Prompt, die verfügbaren Werkzeuge oder das Bewertungsverfahren ändern, können solche Unterschiede das Ergebnis beeinflussen – zusätzlich zu möglichen Unterschieden zwischen Modellversionen.

Was vor einem Versionsvergleich festzuhalten ist

Diese Tabelle ist eine Checkliste für eine interne Prüfung. Sie schreibt den Veröffentlichungen keine methodischen Angaben zu, die in den verfügbaren Quellen nicht genannt werden.

ElementMindestens zu dokumentierenWarum es wichtig ist
ModellExakte Modellkennung und AbrufdatumUnterscheidet Snapshots von Aliasnamen.
Aufgabe und KorpusVersion, Aufteilung und AusschlusskriterienVerhindert den Vergleich unterschiedlicher Fragen oder Daten.
KonfigurationPrompt, Beispiele, Werkzeuge und verwendete ParameterErmöglicht einzuordnen, unter welchen Bedingungen die Antwort zustande kam.
EvaluierungBewertungsraster, Referenzantworten und PrüfendeMacht transparent, wie die Korrektheit einer Antwort bestimmt wurde.
03

Drei Benchmarks, drei Arten von Evidenz

LAB-Bench ist eine Sammlung von Aufgaben zur Messung sprachmodellbezogener Fähigkeiten, die für die biologische Forschung relevant sind. Der Originalartikel beschreibt Multiple-Choice-Fragen und einen Vergleich mit erfahrenen Forschenden. Der Aussagebereich ist auf die im Benchmark enthaltenen Aufgaben beschränkt. LAB-Bench ist weder eine unmittelbare Beobachtung der Laborarbeit noch eine Bewertung sämtlicher Phasen eines Forschungsprojekts.

Protocol QA ist eine Teilaufgabe von LAB-Bench und konzentriert sich auf Fragen zu Protokollen. Das veröffentlichte Ergebnis für Sonnet 4.5 liefert Evidenz zu seiner Leistung bei dieser Aufgabe unter den berichteten Evaluierungsbedingungen. Es belegt nicht, dass das Modell ein Protokoll praktisch ausführen, sämtliche Unklarheiten darin erkennen oder eine Anweisung korrekt an lokale Reagenzien, Geräte und Arbeitsabläufe anpassen kann. Eine Dokumentenfrage zu verstehen und einen experimentellen Arbeitsschritt auszuführen sind unterschiedliche Fähigkeiten.

LAB-Bench umfasst außerdem Aufgaben zu Figuren, Sequenzen und Klonierung. Die Ergebnisse der Systemkarte für diese Kategorien erweitern zwar das Spektrum der untersuchten Fähigkeiten, machen die jeweiligen Punktzahlen jedoch nicht austauschbar: Jede Aufgabe prüft andere Fähigkeiten und Formate. Ein gutes Ergebnis bei Protokollfragen lässt sich nicht automatisch auf die Interpretation einer Abbildung übertragen.

BixBench untersucht die computergestützte Biologie anhand offener Fragen, die mehrstufige Analyseverläufe erfordern. Im Originalartikel werden erste Evaluierungen mit GPT-4o und Claude 3.5 Sonnet beschrieben, nicht mit Claude Sonnet 4.5. BixBench ist daher hilfreich, um eine Art der Evaluierung computergestützter Analysen zu veranschaulichen. Die berichteten ersten Ergebnisse sind jedoch keine Resultate von Sonnet 4.5 und sollten auch nicht als solche dargestellt werden.

Das BixBench-Repository beschreibt ein Harness und eine Konfiguration für Evaluierungen, zu denen Notebook- und Codeanalysen gehören. Damit lässt sich eine kontrollierte Reproduktion des Benchmarks planen; dennoch muss geprüft werden, welche Modellversion, Werkzeuge und Bedingungen in jedem einzelnen Experiment verwendet wurden. Für LAB-Bench dokumentiert das Repository der Urheber Ein- und Ausgabeformate sowie Evaluierungsskripte. Es weist zugleich darauf hin, dass der vollständige Datensatz nicht öffentlich verfügbar ist. Diese Einschränkung ist relevant, wenn ein veröffentlichtes Ergebnis exakt rekonstruiert werden soll.

Welche Schlussfolgerungen die Ergebnisse tragen – und welche nicht

Diese Unterscheidung verhindert, dass eine einzelne Referenzaufgabe als allgemeiner Nachweis wissenschaftlicher Kompetenz missverstanden wird.

EvaluierungWelche Evidenz sie liefertWas sie für sich genommen nicht belegt
Protocol QALeistung bei Fragen zu Protokollen im jeweils evaluierten Datensatz und unter der jeweiligen Konfiguration.Korrekte Ausführung, Anpassung an lokale Abläufe oder experimentelle Sicherheit.
FigQA und andere LAB-Bench-AufgabenLeistung bei bestimmten, in LAB-Bench enthaltenen Aufgaben der biologischen Forschung.Eine einheitliche Fähigkeit, beliebige Figuren, Sequenzen oder biologische Probleme zu analysieren.
BixBenchEvaluierung offener Aufgaben der computergestützten Biologie mit mehrstufigen Analysen.Ein Ergebnis für Sonnet 4.5, wenn sich die zitierte Evaluierung auf andere Modelle bezieht.
04

Warum Protocol-QA-Werte nicht ohne Prüfung zusammengeführt werden sollten

Die bereitgestellte Evidenz umfasst ein Protocol-QA-Ergebnis aus der Systemkarte von Sonnet 4.5: 0,833 für Sonnet 4.5 bei k=10 und 0,741 für Sonnet 4. Die redaktionelle Vorlage weist darauf hin, dass manche Veröffentlichungen von Anthropic für Aufgaben mit der Bezeichnung Protocol QA andere Punktzahlen nennen. Die vorliegenden Quellen dokumentieren jedoch nicht ausreichend, ob diese Werte auf demselben Datensatz, unterschiedlichen Teilmengen, verschiedenen Prompts oder anderen methodischen Änderungen beruhen.

Ein gleicher Aufgabenname garantiert nicht, dass zwei Messungen gleichwertig sind. Bevor man sie als Entwicklung oder Widerspruch darstellt, sollte man die genaue Modellversion, den evaluierten Datensatz, das Frageformat, die im Prompt enthaltenen Beispiele, den Zugang zu Werkzeugen, die Bewertungsregel und den Umgang mit Teilantworten prüfen. Wer den Parameter k präzise interpretieren möchte, muss außerdem klären, was k=10 in der Grafik bedeutet und wie die Antworten aggregiert wurden.

Auch die menschliche Vergleichsreferenz muss ähnlich sorgfältig geprüft werden. Die Systemkarte weist eine menschliche Referenz aus. Die hier beschriebenen Materialien reichen aber nicht aus, um die Teilnehmenden, ihre Zahl, ihre Erfahrung oder die erhaltenen Anweisungen sicher zu charakterisieren. Ohne diese Angaben wäre es nicht sachgerecht, die Referenz als universellen Maßstab für Expertenleistung darzustellen.

Die angemessene Schlussfolgerung lautet weder, dass die Ergebnisse unvereinbar sind, noch, dass einer der Werte falsch ist. Vielmehr lässt sich ihre Vergleichbarkeit anhand der verfügbaren Informationen nicht klären. Eine sorgfältige Darstellung nennt jeden Wert in seinem jeweiligen Kontext und macht die Unsicherheit ausdrücklich kenntlich, statt eine Entwicklung zu berechnen oder Punktzahlen zusammenzuführen.

05

Vom Benchmark ins Labor: die noch fehlende Übertragung

Ein Benchmark kann prüfen, ob eine Antwort mit einer Lösungsvorlage übereinstimmt. Ein Labor muss jedoch wissen, ob die Antwort für seine aktuelle Dokumentation und den konkreten Fragekontext korrekt ist. Protokolle können lokale Varianten, interne Bezeichnungen, Revisionshinweise oder relevante Bedingungen enthalten, die im Referenzmaterial eines öffentlichen Tests fehlen. Die Fähigkeit, allgemeine Fragen zu beantworten, belegt nicht, dass das Modell die maßgebliche Dokumentversion gefunden und angewendet hat.

Darüber hinaus ist eine Frage zu einem Protokoll nicht gleichbedeutend mit seiner praktischen Durchführung. Diese hängt von Personen, Geräten, Proben, Materialien und Kontrollen ab, die durch einen Frage-Antwort-Test nicht abgedeckt werden. Ebenso beweist eine plausible Interpretation einer Abbildung weder, dass sie gültig ist, noch, dass die wissenschaftliche Schlussfolgerung angesichts der vollständigen Daten Bestand hat.

Auch verfügbare Werkzeuge verändern die Bewertung. Bei einer rechnergestützten Analyse kann die Fähigkeit, Code zu erstellen oder auszuführen, das Ergebnis beeinflussen. Bei einer Dokumentenaufgabe antwortet das Modell möglicherweise ausschließlich auf Grundlage des Prompts. Um Unterschiede einer Modellversion zuzuschreiben, müssen die Werkzeuge konstant gehalten und ihre Verwendung dokumentiert werden. Die verfügbaren Quellen beschreiben zwar Bestandteile der Benchmark-Evaluierungen, reichen aber nicht aus, um sämtliche Bedingungen jedes veröffentlichten Werts zu rekonstruieren.

Ein positives Ergebnis ist daher ein Anlass, einen eng begrenzten Anwendungsfall zu prüfen – etwa eine mögliche Antwort in der Dokumentation zu finden und einen Entwurf zur Überprüfung vorzubereiten. Es ist keine Erlaubnis, die Prüfung durch Fachleute zu ersetzen, und kein Nachweis wissenschaftlicher Gültigkeit.

06

Eine aussagekräftige retrospektive Validierung gestalten

Eine interne Prüfung muss weder Experimente automatisieren noch sensible Informationen offenlegen, um das Verständnis von Dokumenten zu bewerten. Sie kann auf einem freigegebenen, eingefrorenen Korpus beruhen: Dokumenten, die das Team verwenden darf, mit eindeutig identifizierbaren Dateiversionen und einer Aufzeichnung darüber, welches Material beim Beantworten verfügbar war. Ein eingefrorener Korpus verhindert, dass spätere Dokumentänderungen die Interpretation der Ergebnisse beeinflussen.

Fachleute, die mit den Dokumenten vertraut sind, sollten repräsentative Fragen und geprüfte Referenzantworten formulieren. Sinnvoll sind Fragen, deren Antwort ausdrücklich im Text steht, Fragen, für die Informationen aus mehreren Stellen zusammengeführt werden müssen, und Fragen, die sich anhand des verfügbaren Materials nicht beantworten lassen. Diese letzte Kategorie zeigt, ob das System die Grenzen der Evidenz erkennt, statt Lücken mit einer plausiblen Antwort zu füllen.

Bevor Modelle verglichen werden, sollte jede Antwort anhand eines Bewertungsrasters geprüft werden. Dieses kann die inhaltliche Richtigkeit, die Belegung durch die Quelle, das Erkennen der maßgeblichen Version, wichtige Auslassungen und unbelegte Behauptungen getrennt erfassen. Die Antworten sollten von Personen beurteilt werden, deren Bewertung nicht von Modellmarke oder -version abhängt. Abweichungen zwischen den Prüfenden sollten dokumentiert und anhand zuvor vereinbarter Kriterien geklärt werden.

Für den Vergleich von Sonnet 4.5 mit späteren Versionen sollten dieselben Fragen, Dokumente, Anweisungen, Werkzeuge und Bewertungsregeln verwendet werden. Die genaue Kennung jedes Modells ist festzuhalten. Wenn eine Plattform keine feste Version oder keinen bestimmten Parameter zulässt, gehört diese Einschränkung zum Ergebnis und darf nicht verschwiegen werden. Wiederholungen helfen zudem, die Stabilität der Antworten einzuschätzen. Ihre Zahl richtet sich nach Aufwand und Risiko des vorgesehenen Einsatzes, nicht nach den öffentlichen Benchmark-Quellen.

Die Prüfung sollte retrospektiv bleiben und sich auf das Verständnis von überprüfbarer Dokumentation beschränken. Um herauszufinden, ob das Modell Informationen auffindet, den Text richtig wiedergibt oder erkennt, dass eine Frage unbeantwortet bleibt, muss man es nicht bitten, Experimente zu entwerfen, zu ändern oder auszuführen. Werden Abbildungen oder Analyseergebnisse bewertet, braucht das Team geprüfte Referenzen und sollte diese Bewertung von Ergebnissen zu Protokollfragen getrennt halten.

Protokoll für eine Dokumentenevaluierung

Ein Vorschlag zur Gestaltung einer begrenzten Prüfung, die nicht mit praktischer Versuchsdurchführung verwechselt wird.

  1. 01Den zulässigen Anwendungsfall vereinbaren, freigegebene Dokumente auswählen, Versionen erfassen und den Korpus einfrieren.
  2. 02Mit Fachleuten Fragen formulieren und jede Referenzantwort anhand des Dokuments überprüfen.
  3. 03Beantwortbare Fragen, Fragen zur Zusammenführung mehrerer Informationen und Fälle ohne ausreichende Antwortmöglichkeit einbeziehen.
  4. 04Prompts, Werkzeuge, Modelle, Bewertungsregeln und Zahl der Wiederholungen vor der Durchführung festlegen.
  5. 05Antworten möglichst ohne Kenntnis der Modellversion prüfen, Meinungsverschiedenheiten dokumentieren und Fehler mit einem gemeinsamen Bewertungsraster klassifizieren.
  6. 06Ergebnisse nach Kategorien vergleichen und Grenzen, schwerwiegende Fehler sowie Einsatzbedingungen dokumentieren.
07

Fehler nach ihrer Bedeutung klassifizieren

Eine einzige Gesamtquote richtiger Antworten kann Fehler unterschiedlicher Schwere verbergen. Beim Lesen von Protokollen kann eine Auslassung eine wichtige Bedingung unterschlagen; eine Vertauschung der Schritte kann eine Anweisung verändern; eine Verwechslung von Einheiten kann eine Antwort präzise erscheinen lassen, obwohl sie es nicht ist. Das Team sollte solche Fälle getrennt erfassen und nicht davon ausgehen, dass jede falsche Antwort dasselbe Risiko birgt.

Bei Fragen zu Abbildungen sollte unterschieden werden, ob eine sichtbare Eigenschaft beschrieben, ein nicht dargestellter Zusammenhang behauptet oder eine kausale Erklärung vorgeschlagen wird. Bei computergestützten Aufgaben sollte zwischen einer reproduzierbaren Analyse und einer Schlussfolgerung unterschieden werden, die sich nicht aus den Daten ergibt. Ebenfalls zu markieren sind Quellenangaben, die eine Antwort nicht belegen, Verweise auf die falschen Abschnitte und unbegründete Sicherheit bei fehlenden Informationen.

Die Sicherheitsprüfung im redaktionellen Sinn sollte auf Dokumentenverständnis beschränkt bleiben: Gibt das Modell den Inhalt freigegebener Unterlagen korrekt wieder, und weist es auf Unsicherheit hin? Dazu müssen keine sensiblen Versuchsanweisungen aufgenommen oder Handlungen verlangt werden, die über das Lesen hinausgehen. Ziel ist festzustellen, ob das System als überprüfbare Unterstützung taugt – nicht, einen internen Benchmark in eine Validierung experimenteller Verfahren umzudeuten.

Minimale Fehlerklassifikation

Die Einteilung hilft zu erkennen, ob eine aggregierte Trefferquote eine für den vorgesehenen Einsatz unzulässige Fehlerkategorie verdeckt.

KategorieWas zu prüfen istBeispiel für ein Warnsignal
Auslassung oder UmkehrungOb relevante Angaben fehlen oder die beschriebene Reihenfolge verändert wurde.Die Antwort lässt eine Bedingung aus oder vertauscht zwei Textschritte.
Einheiten und BedingungenOb Einheiten, Grenzwerte und Dokumentkontext erhalten bleiben.Ein Zahlenwert wird ohne Einheit oder unter einer anderen Bedingung angegeben.
Interpretation von AbbildungenOb sichtbare Beobachtung und Interpretation auseinandergehalten werden.Eine Erklärung wird so dargestellt, als wäre sie in der Abbildung beschriftet.
Beleg durch DokumenteOb die Antwort durch den angegebenen Abschnitt gestützt wird.Die zitierte Stelle enthält die zugeschriebene Aussage nicht.
UnsicherheitOb das Modell erkennt, wenn sich eine Frage mit dem Korpus nicht beantworten lässt.Das Modell antwortet kategorisch, obwohl die Antwort nicht belegt ist.
08

Begrenzter Einsatz und Schlussfolgerung

Bestätigt eine positive interne Evaluierung, dass Sonnet 4.5 Informationen findet und mit überprüfbaren Belegen wiedergibt, könnte das Team einen Einsatz als Leseassistenz oder zur Erstellung von Entwürfen prüfen, die anschließend kontrolliert werden. Die endgültige Antwort bliebe an den vom Labor vereinbarten Prüfprozess gebunden. Die öffentliche Punktzahl allein rechtfertigt weder die Nutzung einer Modellausgabe als Versuchsanweisung noch ihre Verwendung als Grundlage einer wissenschaftlichen Interpretation.

Ein Vergleich mit Nachfolgemodellen sollte als neue, kontrollierte Prüfung angelegt werden. Die bereitgestellte Dokumentation ermöglicht die Identifizierung von Sonnet 4.5 und verweist auf eine offizielle Ankündigung von Sonnet 5. Sie liefert aber keine gleichwertigen Ergebnisse für Sonnet 5 auf Protocol QA, LAB-Bench oder BixBench. Auch einen kontrollierten Vergleich mit Sonnet 4.6 kann sie nicht begründen. Aus diesen Quellen lässt sich deshalb nicht ableiten, welches spätere Modell bei denselben Aufgaben besser abschneidet.

Die überprüfbare Schlussfolgerung ist enger gefasst, aber dennoch nützlich: Anthropic veröffentlicht für Sonnet 4.5 positive Ergebnisse bei konkreten LAB-Bench-Aufgaben, darunter Protocol QA. BixBench prüft eine andere Art von Arbeit; die hier zitierten ersten Ergebnisse beziehen sich nicht auf Sonnet 4.5. Diese Daten begründen eine Hypothese über möglichen Nutzen beim Lesen und Analysieren, nicht die Behauptung, das Modell sei in einem realen Labor zuverlässig. Die fehlende Evidenz muss mit freigegebenen Dokumenten, von Fachleuten geprüften Fragen, nachvollziehbaren Referenzantworten und Vergleichen unter gleichwertigen Bedingungen erhoben werden.

Offene Fragen

  • Die geprüften Quellen klären nicht, ob die unterschiedlichen veröffentlichten Protocol-QA-Werte denselben Datensatz, dasselbe Frageformat, Prompting, dieselben Werkzeuge und dasselbe Bewertungsverfahren verwenden.
  • Die vorliegenden Informationen erlauben keine präzise Beschreibung der Teilnehmenden, ihrer Zahl oder der Anweisungen, die der menschlichen Referenz in der Grafik zugrunde liegen.
  • Es liegen keine Belege für eine Evaluierung von Sonnet 4.6 oder Sonnet 5 bei denselben Aufgaben und unter mit Sonnet 4.5 vergleichbaren Bedingungen vor.
  • Das LAB-Bench-Repository weist darauf hin, dass der vollständige Datensatz nicht öffentlich verfügbar ist. Das schränkt die exakte Reproduzierbarkeit der veröffentlichten Ergebnisse ein.
09

Weiter entdecken

09

Verwendete Quellen

03

Korrekturen und Transparenz

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

Korrektur vorschlagen