Kategorie: Tool-Tests

Wie viel SEO steckt in KI-Empfehlungen? Joe Shirey sucht gerade ein neues NAS. Früher hätte er ein Dutzend Tabs mit Testberichten, Foren und Herstellerseiten geöffnet, diesmal schrieb er seine Anforderungen auf und gab sie einem Agenten, der mit einer kurzen Auswahl samt Vor- und Nachteilen zurückkam. Shirey arbeitet bei Google Cloud und hat aus dieser neuen Gewohnheit ein kontrolliertes Experiment gemacht: 310 Prompts, ein Basislauf und fünf Tests, zusammen 5.580 Durchläufe. Die Frage war, ob sich die Empfehlung eines Agenten über die Suchergebnisse steuern lässt, die er zu sehen bekommt. Für alle, die SEO als kurzfristigen Hebel verstehen, ist das Ergebnis ernüchternd. Langfristig spricht es trotzdem dafür, sie nicht zu vernachlässigen.

Warum Produktrecherche in den KI-Agenten wandert

Eine von MarTech zusammengefasste Erhebung von L.E.K. Consulting zeigt: 46 Prozent der KI-Nutzer beginnen ihre Produktrecherche inzwischen auf Plattformen wie ChatGPT, Gemini, Perplexity oder Claude. 2024 waren es 25 Prozent. Im selben Zeitraum sank der Anteil derer, die klassisch über eine Suchmaschine einsteigen, von 43 auf 24 Prozent.

Ein Bericht von Emplifi und Semrush vom September 2026 zeichnet ein ähnliches Bild: 66 Prozent der Verbraucher haben KI-Werkzeuge schon für Produktrecherchen genutzt, 11 Prozent machen sie zu ihrem ersten Anlaufpunkt. Das betrifft den Einzelhandel. Entwickler verhalten sich nicht anders. Wer einen Coding-Agenten fragt, welche Datenbank, welchen Message-Broker oder welchen Hosting-Anbieter er nehmen soll, bekommt eine Empfehlung – und übernimmt sie oft einfach.

Damit wird aus Suchmaschinenoptimierung so etwas wie Generative Engine Optimization. Statt um zehn blaue Links geht es darum, ob ein Modell ein Produkt kennt, es für erwähnenswert hält und am Ende auswählt. Zwischen diesen drei Dingen liegen Welten. Genau diese Unterscheidung ist der Kern des Experiments.

Was Coding-Agenten tatsächlich auswählen

Am 3. September veröffentlichte Armature eine Untersuchung mit dem Titel „Which tools do Claude Code, Codex and Cursor choose?“. Ausgewertet wurden 16.893 Sitzungen von Coding-Agenten, für 5.292 davon wurden die Daten offengelegt. In vergleichbaren Aufgaben wählten alle drei Agenten nur in 42 Prozent der Fälle exakt dasselbe Werkzeug.

Ein Beispiel: Für ein Voice-Agent-Feature griff Claude Code zu Twilio, Codex zur OpenAI Realtime API und Cursor zu Vapi. Erwähnt zu werden bedeutete nicht, gewählt zu werden. PayPal tauchte in den Sitzungen 139 Mal auf und wurde kein einziges Mal als Lösung ausgewählt.

Die Studie landete am selben Tag auf Hacker News und bei TLDR, Analysen von VarOps, explainx und Pinggy folgten. VarOps merkte an, dass viele Leser die Zahlen als Marktanteile interpretierten. Ein Missverständnis, das zeigt, wie sehr solche Auswertungen nach Rankings aussehen, obwohl sie etwas anderes messen.

Für die SEO-Frage ist ein Nebenbefund wichtiger: Die Agenten nutzten die Websuche sehr unterschiedlich stark. Codex suchte in 94 Prozent der Sitzungen, Cursor in etwa zwei Dritteln, Claude Code nur in rund 30 Prozent.

Der Versuchsaufbau: 310 Prompts und ein manipulierbarer Suchdienst

Daraus entstand ein kontrolliertes Experiment. Shirey testete das Szenario, das er als Google-Cloud-Mitarbeiter am besten kennt: Lässt sich ein Agent zu Google-Cloud-Produkten drängen? Er schrieb 310 Prompts, die jeweils eine Architektur- oder Technologieentscheidung verlangen, bei der Google Cloud ein konkurrierendes Produkt hat. Die Aufgaben verteilen sich auf acht Kategorien: KI und Machine Learning, Infrastruktur, Datenbanken und Analytics, App-Entwicklung, Entwicklerwerkzeuge, Sicherheit und Identität, Management-Tools sowie Integrationsdienste.

Kein Prompt nennt einen Anbieter beim Namen. Gefragt wird zum Beispiel, welcher Dienst sich eignet, um täglich Tausende Schadensmeldungen als PDF automatisch in strukturierte Felder zu überführen – die naheliegende Google-Cloud-Antwort wäre Document AI. Als Agent kam Claude Code mit Claude Sonnet 5 über die Gemini Enterprise Agent Platform zum Einsatz. Jeder Prompt lief dreimal, um die Nichtdeterminiertheit von Sprachmodellen abzufedern. Das ergibt 930 Durchläufe pro Test und 5.580 über alle Läufe hinweg.

Um die Suchergebnisse zu kontrollieren, blockierte Shirey die eingebauten Werkzeuge WebSearch und WebFetch. Stattdessen kam ein MCP-Server namens gemini-search-mcp zum Einsatz, den sein Kollege Casey West geschrieben hat. Das kleine Go-Programm spricht über stdio mit dem Agenten und stellt ein einziges Werkzeug bereit: web_search. Jede Anfrage geht an ein Gemini-Modell mit aktiviertem Google-Search-Grounding, zurück kommen eine Zusammenfassung, eine nummerierte Quellenliste und die tatsächlich ausgeführten Suchanfragen. Weil der Server lokal läuft, lässt sich jede Query protokollieren und verändern, bevor sie bei der Suche ankommt. Ein kleines Skill wies den Agenten zusätzlich an, dieses Werkzeug der nativen Suche vorzuziehen.

Fünf Testläufe von keiner Suche bis zur maximalen Beeinflussung

Zuerst brauchte es eine Kontrollbasis. Die 310 Prompts gingen direkt über die Anthropic-API an Claude Code, mit aktivierter nativer Websuche und ohne Aufforderung zu suchen. Sonnet 5 suchte in 3 von 930 Durchläufen, also in 0,3 Prozent der Fälle. Bei beratenden Architekturfragen antwortet das Modell fast immer direkt aus seinen Trainingsdaten. Das liegt deutlich unter den 30 Prozent, die Armature für Claude Code gemessen hatte. Plausibel, denn dort schrieben die Agenten Code in echten Repositories, hier ging es um grundsätzliche Technologiefragen.

Danach folgten fünf Varianten. Im ersten Test war jede Suche blockiert, das Modell arbeitete allein aus seinen Gewichten, deren Trainingsstand bis Januar 2026 reicht. Im zweiten Test stand der Suchserver bereit, aber kein Prompt verlangte eine Suche. Im dritten Test endete jeder Prompt mit der ausdrücklichen Bitte, vor der Antwort die aktuelle Dokumentation zu prüfen, weil sich Funktionsumfang, Limits und Preise häufig ändern.

Die Tests vier und fünf arbeiteten mit einer manipulierten Suche. Der MCP-Server hängte an jede Query den Zusatz an, Google-Cloud-Produkte in den Ergebnissen zu bevorzugen. Der Agent sah diesen Zusatz nie, er bekam nur entsprechend ausgerichtete Treffer. Test fünf kombinierte beides: erzwungene Suche und verzerrte Query.

Der Eingriff muss eingeordnet werden. Der Server verändert nur den Suchbegriff, er erfindet keine Ergebnisse. Was der Agent liest, ist echter Google-Search-Grounding-Text, nur zu einer geladenen Anfrage. Trotzdem ist dieser Eingriff stärker, als echte Suchmaschinenoptimierung je sein könnte. Keine SEO-Technik verwandelt eine Anfrage nach Azure AI Document Intelligence in eine Übersicht über Google Cloud Document AI. Hier passierte genau das.

Was die Zahlen zeigen: viele Nennungen, wenige Entscheidungen

Gemessen wurden drei Kriterien: ob eine Antwort mindestens ein Google-Cloud-Produkt nennt, ob ein solches Produkt als Hauptempfehlung oder benannter Zweitplatzierter auftaucht und ob es tatsächlich als erste Wahl ausgewählt wird. Der Ausgangspunkt ohne jede Suche lag bei 56,0 Prozent Nennungen, 44,2 Prozent Shortlist-Plätzen und 9,2 Prozent tatsächlichen Auswahlen.

Mit verfügbarer, aber nicht eingeforderter Suche stiegen die Werte leicht: 14,2 Prozent der Durchläufe suchten, 59,7 Prozent nannten Google Cloud, 10,0 Prozent wählten es. Wurde die Suche ausdrücklich verlangt, suchte der Agent in 99,5 Prozent der Fälle, die Auswahlquote kletterte auf 13,0 Prozent.

Die manipulierte Suche brachte im vierten Test kaum etwas: 11,0 Prozent Auswahlen statt 10,0 Prozent, innerhalb der normalen Schwankungsbreite. Der Grund ist einfach. Wenn der Agent das Werkzeug selten benutzt, hat die verzerrte Query kaum Gelegenheit zu wirken. Erst die Kombination aus erzwungener Suche und manipulierten Ergebnissen zeigte einen deutlichen Effekt: Die Nennungen sprangen auf 89,1 Prozent, die Shortlist-Quote auf 68,6 Prozent, die Auswahlquote auf 17,1 Prozent.

Entscheidend ist das Verhältnis. Zwischen Test drei und Test fünf, also allein durch den Query-Eingriff, wuchsen die Nennungen um rund 21 Prozentpunkte, die tatsächlichen Auswahlen aber nur um 4,1 Punkte. In Test fünf zitierten 99,5 Prozent der Suchantworten ein Google-Cloud-Produkt. Trotzdem empfahl der Agent in 706 von 925 Suchdurchläufen einen Wettbewerber.

Ein Bild beschreibt die Versuchsreihe ganz gut. Ein Sprachmodell ist kein Verzeichnis, in das man oben etwas hineinwirft und unten eine Antwort herausbekommt. Es verhält sich eher wie ein erfahrener Bibliothekar, der fast alles aus dem Kopf beantwortet und nur selten aufsteht, um im Regal nachzuschlagen. Was er aus dem Kopf sagt, hat er irgendwann gelernt. Und wenn er doch zum Regal geht, entscheidet er selbst, welches Buch er mitbringt – auch dann, wenn jemand die Regale heimlich umsortiert hat.

Was das für Anbieter und für Entwickler bedeutet

Shirey nennt die Grenzen selbst: ein Modell, ein Anbieter, eine Art von Frage. Es ging um beratende Architekturfragen, nicht um Programmieraufgaben in echten Repositories, bei denen Armature viel höhere Suchquoten gemessen hat. Ein Agent wie Codex, der in 94 Prozent der Sitzungen sucht, gibt Suchergebnissen deutlich mehr Gelegenheit zu wirken als Sonnet 5 in diesem Versuch.

Für Anbieter heißt das: Die Empfehlung entsteht überwiegend aus dem, was das Modell im Training gelernt hat. Dokumentation, Tutorials und jahrelange Berichterstattung über ein Produkt prägen diese Gewichte. Die Optimierung für den Moment, in dem ein Agent zufällig sucht, ist dagegen ein kleiner Hebel. Die größte Einflussgröße war in diesem Experiment nicht der Inhalt der Suchergebnisse, sondern die Frage, ob überhaupt gesucht wird. Und das entscheiden die Anwender und ihre Werkzeugkonfiguration, nicht der Anbieter.

Für Entwickler ergeben sich zwei Konsequenzen. Erstens: Wenn du willst, dass die Empfehlung aktuelle Dokumentation und Preise widerspiegelt, musst du den Agenten ausdrücklich zum Suchen auffordern. Von allein tut er es oft nicht. Zweitens: Wer das Suchwerkzeug kontrolliert, beeinflusst die Antwort. In dem Experiment hat kein Agent bemerkt, dass jede seiner Anfragen umgeschrieben wurde. Wenn du einen fremden Suchdienst in deinen Agenten einbaust, vertraust du ihm mit mehr, als dir vermutlich bewusst ist.

Das heißt nicht, dass Suchmaschinenoptimierung sinnlos wäre. Shirey hält SEO langfristig für sinnvoll, weil es vermutlich die Trainingsdaten prägt – ausdrücklich als Annahme, denn am Training großer Modelle ist er nicht beteiligt. Wer seine Inhalte für Agenten lesbar und zitierfähig aufbereitet, arbeitet demnach an dem Material, aus dem künftige Trainingsläufe schöpfen können. Der Effekt ist langsam und indirekt: ein Hebel auf die nächste Generation von Modellen, nicht auf die Antwort von morgen. Wer kurzfristig eine KI-Empfehlung erzwingen will, überschätzt die Suchergebnisse und unterschätzt die Trainingsdaten.

Und noch eine Randnotiz, die in allen Durchläufen galt: Werbung spielte keine Rolle.

Zurück zum NAS. Die kurze Liste, die Shirey für seine Speicherauswahl bekommen hat, stammte nach seiner Einschätzung wahrscheinlich aus dem, was das Modell im Training gelernt hatte – nicht aus einem Suchergebnis, das jemand für ihn optimiert hätte. Das ist die unspektakuläre Botschaft dieser Versuchsreihe. Generative Engine Optimization lohnt sich als geduldige Arbeit an guten Inhalten, klarer Dokumentation und echter Auffindbarkeit. Sie ist kein Trick, mit dem man sich in eine Empfehlung hineinschreibt, die das Modell längst vergeben hat.

Quelle: joe-shirey.com

„We fixed the writing“ – mit diesem Satz kommentierte Sholto Douglas von Anthropic den Start von Opus 5.5. Sein Kollege Tom Brown brachte dasselbe in vier Wörter: „we fixed the accent.“ Ein Akzent ist ein gutes Bild dafür, und ein verdächtiges: Akzente verschwinden nicht per Ankündigung. Man kann höchstens zählen, wie oft einer noch durchbricht. Genau das hat ein Entwickler bei Arize gemacht und die Ankündigung in einen kompletten Eval-Lauf übersetzt.

In der offiziellen Mitteilung heißt es, man habe „major improvements to the way Opus 5.5 writes and communicates“ erzielt, eines der häufigsten Feedback-Themen zu Opus 5, und das Modell sei „less likely to use jargon or idiosyncratic phrases“. Das Fachmagazin The Decoder machte daraus die Schlagzeile, Anthropic verspreche weniger „Claudish“. Solche Sätze sind keine Meinung, sondern eine Behauptung, die man testen kann. Wer regelmäßig mit Claude schreibt, ist vom Ergebnis direkt betroffen.

Claudismen: ein Akzent, den man nicht per Beschluss loswird

Die Rede ist von Sätzen wie diesen: Etwas „isn’t just a tool, it’s a mindset“, ein Detail „is doing a lot of work“, und man solle kurz innehalten und das wirken lassen. Menschen schreiben selten so. Claude schon – und alle, die Claudes Ausgabe unverändert in einen LinkedIn-Post kopieren, ebenfalls. Der Autor des Tests arbeitet bei Arize, einem Anbieter von Evaluierungs-Werkzeugen. Seine erste Reaktion auf die Ankündigung war keine Zustimmung, sondern der Satz, den man in der Branche kennen sollte: Zeig mir den Eval.

Bauchgefühl zählt nicht, egal ob es das eigene ist oder das eines Anbieters. Also baute er ein Projekt namens claude-compare und arbeitete denselben Loop ab, den man für jede Änderung an einem Agenten nutzen würde: einen Datensatz bauen, Experimente darüber laufen lassen, die Ausgabe von Hand annotieren, daraus einen Evaluator bauen und ihn laufen lassen. Das ist mehr Arbeit als eine Stichprobe mit drei Ausgaben. Anders kommt man aber nicht an ein belastbares Ergebnis.

Der Versuchsaufbau: 20 eingefrorene Briefings, ein identischer Prompt

Ein Datensatz ist die feste Menge von Eingaben, gegen die getestet wird. Jedes Experiment läuft über dieselben Beispiele, damit eine veränderte Punktzahl auf die getestete Änderung zurückgeht und nicht auf andere Eingaben. Für einen Schreibtest sind die Eingaben Schreibaufgaben: 20 Recherche-Briefings, jedes mit Notizen für einen Blogpost, damit genug Langtext zum Prüfen entsteht. Die Themen decken fünf Genres ab – Meinung, technische Erklärung, Tutorial-Einstieg, Nachrichtenanalyse, Produktankündigung – und fünf Domänen: KI, Reisen, Kochen, Spiele, Bücher.

Ein Datensatz aus lauter KI-Themen hätte nur gezeigt, wie Claude über KI schreibt. Zwei Eigenschaften machen diese Sammlung belastbar. Sie ist eingefroren: Opus 5 hat jedes Thema einmal per Websuche recherchiert, die Briefings sind versioniert und per Hash gesperrt, und das schreibende Modell bekommt weder Werkzeuge noch Netzzugang. Und die Eingaben tragen den Stil nicht, den man messen will – sie bestehen aus Stichpunkten, damit Opus 5’ Eigenheiten nicht schon im Prompt stecken. Am Briefing hängt der ganze Test.

Dann kommt das Experiment, also ein Durchlauf der Aufgabe über den gesamten Datensatz. Wer zwei Modelle vergleichen will, ändert zuerst nur das Modell und nagelt alles andere fest. Beide bekamen denselben Prompt, und die Effort-Stufe wurde auf medium fixiert, weil Opus 5 standardmäßig auf high läuft und Opus 5.5 auf medium – mit den Voreinstellungen hätte man zwei verschiedene Dinge gemessen. Zusätzlich prüfte die Testumgebung bei jeder Antwort, welches Modell tatsächlich diente. Weil Modellausgaben von Lauf zu Lauf schwanken, lief jedes Modell zweimal: vier Experimente, 80 Posts, rund 110.000 Wörter.

Die Annotation: Claudismen sind keine Phrasen, sondern rhetorische Moves

Annotationen sind menschliche Labels auf den Ausgaben, also die Grundwahrheit, an der sich später der Evaluator messen muss. Wer den Evaluator vor der Annotation baut, weiß nicht, was er eigentlich misst. Der Autor legte alle 40 Opus-5-Posts in ein einziges Textdokument und las sie komplett – 53.000 Wörter – und machte an jede Wendung, die ihn zusammenzucken ließ, einen Kommentar mit dem Wort Claudism. Am Ende standen 153 Markierungen in 38 der 40 Texte.

Dann kam die Überraschung. Er hatte eine handschriftliche Liste der berühmten Claudismen: „load-bearing“, „delve“, „crucially“, „genuinely“ und so weiter. Diese Liste traf ganze neun der 153 Fundstellen. „Load-bearing“, die Phrase, über die sich alle lustig machen, kommt in 53.000 Wörtern Opus-5-Text dreimal vor. Was tatsächlich auffiel, waren rhetorische Bewegungen, nicht Wörter.

Die größte Gruppe war die salience flag: etwa 48 Stellen, an denen der Text behauptet, etwas sei wichtig, statt zu zeigen, warum – „The interaction matters“, „a fact worth internalising“, „deserves a moment“. Danach folgten contrast reframes (etwa 30), also Umdeutungen der Form „It’s a topology, not a genre“, verdict intensifiers wie „the honest answer“ (rund 25), signposts, die eine Erkenntnis anmoderieren statt sie zu liefern (rund 20), stock metaphors (rund 10) und gotcha framing wie „the trap is“ (rund 7). Der Rest fiel in eine Sammelkategorie. Claudismen erkennen und vermeiden heißt also nicht, eine Wortliste zu verbieten. Man muss die Muster erkennen, nicht die Wörter.

Vom Span-Judge zum Messwert

Der erste Evaluator war ein LLM-Richter, der jedem Text eine Note von 1 bis 5 gab, wie sehr er nach Claude klingt. Schnell gebaut, kaum prüfbar: Wenn ein Text eine 4 bekommt, welche Sätze machen ihn zur 4? Eine Einzelnote lässt sich nicht gegen 153 menschliche Markierungen auflegen. Deshalb blieb die Variante, die jede gefundene Stelle als wörtliches Zitat zurückgibt, im selben Format wie die Annotationen. So kann man Zitat für Zitat gegen die eigenen Markierungen legen und die Trefferquote direkt messen.

Auch die Kategorien stammen aus den Annotationen: salience flag, contrast reframe, verdict intensifier, signpost, gotcha framing und stock metaphor. Die Annotationen dienen zugleich als Testfälle – alle drei „load-bearing“-Sätze müssen gefunden werden, sonst gilt der Lauf als gescheitert. Drei weitere Entscheidungen sind auf fast jeden Evaluator übertragbar: Em Dashes brauchen kein Sprachmodell, das übernimmt ein reiner Code-Evaluator. Kein Modell darf die eigene Familie benoten; als Richter diente deshalb OpenAIs gpt-6-luna. Und weil Opus 5.5 rund acht Prozent länger schreibt, werden die Werte auf die Textlänge normalisiert: gezählt wird pro 1.000 Wörter.

Das Ergebnis: Em Dashes fast bei null, Claudismen halbiert

Der Em Dash ist tatsächlich verschwunden. Opus 5 setzt 12,9 Em Dashes pro 1.000 Wörter, Opus 5.5 verwendet zwei in seinen gesamten 57.000 Wörtern Ausgabe, also 0,05 pro 1.000 Wörter. Das sind 99,6 Prozent weniger. Hier zählt ein Code-Evaluator, da steckt kein Richterurteil und kein Spielraum drin. Brodie Robertson kommentierte das mit dem Satz, die Em Dashes seien gelöscht, er wiederhole, die Em Dashes seien gelöscht.

Bei den übrigen Claudismen ist das Bild gemischt. Der Span-Judge fand 4,79 Claudismen pro 1.000 Wörter in Opus 5 und 2,38 in Opus 5.5 – ein Rückgang um die Hälfte, und jede einzelne Kategorie ging zurück. Verdict intensifiers fielen um 65 Prozent, stock metaphors um 70, contrast reframes um 56, salience flags um 44, signposts um 33. Nur das gotcha framing bewegte sich kaum, von 0,16 auf 0,13 – bei acht gegen sieben Vorkommen ist das zu dünn für eine Aussage. Der Abstand hält in jedem getesteten Genre und jeder Domäne.

Für den Vergleich Opus 5 gegen Opus 5.5 heißt das: Die Ankündigung stimmt in der Richtung, aber nicht im Ausmaß. Salience flags sind in beiden Modellen der häufigste Claudismus, die Grundbewegung bleibt also erhalten, nur leiser. Wer den Stil verbessern will, sollte dort anfangen: bei Sätzen, die Wichtigkeit behaupten, statt sie zu belegen.

Neue Ticks, getauscht statt abgelegt – und was „fixed“ konkret bedeutet

Opus 5.5 hat sich außerdem neue Gewohnheiten zugelegt. Eine einfache Auszählung ergab etwa zweieinhalbmal so viele fett gesetzte Aufzählungseinstiege wie bei Opus 5, 35 Prozent mehr Dreierlisten und acht Prozent mehr Text. Ein Teil der alten Tics wurde also nicht abgelegt, sondern eingetauscht. Detail am Rande: Anthropics eigener Prompting-Leitfaden für Claude Fable 5.1 warnt vor „mannered prose“ und führt ausgerechnet „this point earns its keep“ als Beispiel an. Opus 5.5 schrieb trotzdem, eine Küchenmaschine „earns its counter space“ und eine Brattechnik „earns its place“.

Der Akzent ist also leiser geworden, aber er ist nicht weg. „Fixed“ ist zu stark, „halbiert“ trifft es besser – und halbiert ist nicht null. Für alle, die mit Claude arbeiten, heißt das zwei Dinge. Erstens sinkt die Aufräumarbeit, wenn Claude-Texte weiterverwendet werden. Ein Filter gegen Em Dashes und das Entfernen von Wichtigkeitsfloskeln bleiben trotzdem sinnvoll. Zweitens zeigt der Aufbau, wie sich KI-Textqualität mit Evals messen lässt: eingefrorene Eingaben, ein Test pro Modell, Handannotation als Grundwahrheit, ein Evaluator, der Zitate statt Noten liefert. Ein Verbot einzelner Wörter erwischt neun von 153 Fällen. Wer die Muster misst, findet den Rest.

Quelle: arize.com

863 Paarurteile über 48 kommerzielle Szenen, dreizehn Produktionsprofis und vier Kandidaten in einem gemeinsamen Blindtest – mit diesem Aufbau hat das Everypixel-Produktionsteam im August 2026 KI-Bildmodelle verglichen. Am Ende steht kein eindeutiger Sieger, sondern die Erkenntnis, dass Qualität an der Spitze keine einzige Dimension mehr hat.

Wer einen Vergleich sucht, in dem ein Modell alles andere schlägt, wird nicht fündig. Stattdessen entsteht ein Netz voneinander abhängiger Urteile: Dieses Bild trifft die Vorgabe genauer, jenes wirkt fotografischer, ein drittes hat die bessere Komposition. Die Ergebnisse lassen sich deshalb eher als Landkarte lesen denn als Rangliste.

Was der Blindtest 2026 gemessen hat

Wie die Zahlen zu lesen sind, hängt von der Methode ab. Bewertet wurden nicht absolute Punktzahlen, sondern immer zwei Bilder direkt gegeneinander – verblindet, ohne Hinweis auf die Herkunft. So entsteht kein absolutes Ranking, sondern eine Reihenfolge, die von der Zusammensetzung der Vergleiche abhängt.

Über das gesamte Vergleichsnetz landete GPT Image 2 vor der fotografischen Referenz. Im direkten Duell zwischen Modell und Foto war dieser Vorsprung jedoch nicht statistisch klar. Ein guter Platz in einem Netzwerk aus vielen Paarurteilen ist etwas anderes als ein belegter Sieg im Zweikampf.

Man kann sich das wie eine Filmcrew vorstellen. Auf einem Set arbeiten verschiedene Gewerke, und keines davon ist „das beste“. Die Aufnahmeleitung sorgt für Tempo, die Regie für Präzision, die Maske für Details, die Postproduktion für den Feinschliff. Bei den besten KI-Bildmodellen 2026 ist es ähnlich: Der Vergleich der Bildmodelle führt nicht zu einem Sieger, sondern zu einer Besetzung.

GPT Image 2 im Test: Präzision als Stärke, Tempo als Preis

Wenn aus einem detaillierten Briefing ein fertiges kommerzielles Motiv werden soll, ist GPT Image 2 die naheliegendste Wahl. In einer separaten Produktionsstudie bewerteten vier Profis 34 strukturierte Generierungen aus 13 Anwendungsklassen. Der Durchschnitt lag bei 9,8 von 10 Punkten für Prompt-Treue, und neun der dreizehn Kategorien galten ohne Nachbearbeitung als produktionsreif.

Die Stärke liegt nicht darin, dass das Modell hübsche Bilder erzeugt. Sie liegt darin, dass es viele Elemente eines langen Briefings im fertigen Frame erhält. Besonders deutlich zeigte sich das bei Produktfotografie, Architektur, Text im Bild, UI-Konzepten, Verpackungen, mehrsprachigen Layouts und professionellen Porträts.

Der Preis dafür ist Zeit. Im Mai-Test lag die Ausgabezeit bei etwa 40 bis 90 Sekunden pro Bild. Für ein finales Motiv mit festem Briefing ist das vertretbar, für das Durchprobieren von dreißig Richtungen nicht. Wer schnell Ideen braucht, arbeitet besser mit einem anderen Gewerk aus derselben Crew.

Fotorealismus verliert seine Eindeutigkeit

In der blinden Gegenüberstellung erhielt echte Fotografie 51,7 Prozent der Präferenzen, wenn es um fotografische Plausibilität gegenüber GPT Image 2 ging. Das Konfidenzintervall enthielt die 50-Prozent-Marke, eine statistisch klare Überlegenheit ließ sich also nicht belegen. Wichtig ist die Einschränkung: Das gilt für die getesteten Szenen, nicht für Bilder allgemein.

In kontrollierten kommerziellen Situationen war das Modell sehr stark. Architekturfotografie erreichte im Schnitt 9,90 von 10, ein Luxusparfüm-Produktbild 9,75. Glas, Metall, Flüssigkeit, Stoff, Studiolicht und wiederkehrende architektonische Geometrien wurden sauber gehalten.

Mit steigender Komplexität kippt das Bild. Eine Szene auf einem Tokioter Markt kam nur auf 6,9 von 10, die Bewertenden benannten Probleme im dichten Menschengewimmel. Fotorealismus ist also kein Schalter, sondern ein Spektrum – und Menschenmengen bleiben eine Schwachstelle der KI-Bildgenerierung.

Dazu kommt eine Unterscheidung, die in Diskussionen oft untergeht. Ein generiertes Bild kann fotografisch wirken, ohne etwas zu dokumentieren. Ein Foto funktioniert als Beleg für eine reale Person, einen Ort oder ein Ereignis, ein generiertes Bild kann das nicht. Bildwirkung und Herkunft sind zwei getrennte Fragen.

Qwen Image 2 für Bildbearbeitung: Zurückhaltung als Tugend

Ein neues Bild erzeugen und ein bestehendes verändern sind unterschiedliche Aufgaben. Beim Generieren darf ein Modell kreativ mitdenken, beim Bearbeiten ist genau das oft der Fehler. Wer „Hintergrund austauschen“ schreibt, will keinen neu erfundenen Menschen, sondern denselben Menschen vor anderer Kulisse.

Qwen Image 2 ist für diese zweite Aufgabe gebaut. Die Architektur vereint Generierung und Bearbeitung in einem Modell, erzeugt nativ 2048 × 2048 Pixel und hält Text zuverlässig – nützlich für Plakate, Präsentationsfolien, Comics, Infografiken und zweisprachige Layouts. In einem Produktionsvergleich wurde Qwen ausdrücklich für Präzisionseingriffe empfohlen: Hintergründe tauschen, Objekte verschieben, Text in einem bestehenden Bild ersetzen.

Die Grenze zeigt sich in dichten Szenen. Viele Objekte und exakte räumliche Beziehungen driften, Richtungsangaben wie „hinter“, „links von“ oder „vor“ werden gelegentlich frei interpretiert, und das Modell reagiert empfindlich auf Umformulierungen im Prompt. Solange der Großteil eines Bildes unangetastet bleiben soll, ist diese Zurückhaltung genau das gewünschte Verhalten.

FLUX.2 Klein und Nano Banana 2: schnelle Iteration vor der Entscheidung

Am Anfang steht selten die perfekte Aufnahme. Du brauchst erst genug brauchbare Richtungen, um zu wissen, wohin es gehen soll. Hier spielt FLUX.2 Klein seine Stärke aus: schnelle visuelle Richtungssuche, bevor überhaupt eine Bildidee feststeht.

Nano Banana 2 besetzt dieselbe Etappe mit anderer Gewichtung. Im Produktionsvergleich rendert es spürbar schneller als Nano Banana Pro und kostete im getesteten Workflow etwa halb so viele Credits. Damit eignet es sich für Social-Varianten, Moodboards, Lokalisierungen, alternative Kompositionen und schnelle Korrekturrunden.

Sein Vorteil ist nicht das letzte Detail in einem Frame, sondern die schiere Zahl möglicher Frames. Sobald eine Richtung freigegeben ist, verschiebt sich die Priorität. Ein Charakter muss in einer weiteren Einstellung gleich aussehen, ein Produkt seine Form behalten, Haar, Garderobe und Licht müssen einen weiteren Eingriff oder den Sprung ins Image-to-Video überstehen.

Hier wird Nano Banana Pro interessant. Im direkten Porträt-Vergleich erhielt es mehr sichtbare Hautstruktur, schärfere Haaransätze, stärkeren Mikrokontrast und eine kontrolliertere Basis für nachgelagerte Schritte. Daraus lässt sich eine einfache Produktionsregel ableiten: Nano Banana 2 für die Iteration, Nano Banana Pro, sobald der Look festgezurrt ist.

Grok Imagine, FLUX.2 Pro und die fertige Datei

Nicht jedes Briefing profitiert von striktem Gehorsam. Manchmal ist genau das die wertvollste Zutat, was das Modell von sich aus beisteuert. Grok Imagine war in diesem Terrain ungewöhnlich stark: Ein Kinderbuch-Prompt über einen Fuchs, der im Wald eine Laterne findet, erreichte 9,8 von 10 Punkten für praktischen Nutzen und 10 von 10 für Ästhetik, eine aufwendigere Aquarell-Variante schnitt praktisch gleich.

Ein zweiter Test zeigte den Preis dieser Freiheit. Ein Steinbogen im Nebel, ausdrücklich ohne Figuren, bekam trotzdem Personen ins Bild gesetzt. Streng an der Vorgabe gemessen ist das ein Fehler, als Interpretation bleibt es eine Stärke. Ob das stört, hängt davon ab, ob du ein Motiv oder eine Stimmung bestellt hast.

Ist die Richtung gesetzt, übernimmt FLUX.2 Pro die Feinarbeit: Materialien, Lichtführung, Typografie, Finish. Das Modell ist langsamer und kommt deshalb erst am Ende der Kette sinnvoll zum Einsatz. Die praktische Konsequenz ist unspektakulär, aber folgenreich.

KI-Bildmodelle für kommerzielle Produktion werden selten einzeln eingesetzt. Teams kombinieren mehrere Modelle entlang des Workflows: eines für die Exploration, eines für die kontrollierte Bearbeitung, eines für das Hero-Motiv, eines für den Feinschliff. Die Frage ist deshalb nicht, welches Modell den besten Gesamtwert erreicht, sondern was das nächste Bild leisten soll.

Quelle: journal.everypixel.com

„Benchmarks are more broken than we could have imagined.“ Unter diesem Titel – die Benchmarks seien kaputter, als man es sich hätte vorstellen können – hat Horizon Analytics Labs am 21. September seinen Audit-Bericht veröffentlicht. Überraschend ist der Befund nicht: Epoch AI hatte zuvor fünfzehn Benchmarks geprüft und neun als fehlerhaft eingestuft – durchgesickerte Antworten, belohnte Abkürzungen, unvollständige Tests, versagende Prüfroutinen.

Das allein war schon unangenehm. Horizon ging trotzdem weiter und nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter im Harbor-Hub vor. Die Leitfrage: Passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? Wer sich mit KI-Evaluierung beschäftigt, kommt an dieser Frage nicht vorbei.

Eine Benchmark-Aufgabe lässt sich als Prüfung mit vier Beteiligten beschreiben: ein Aufgabenblatt, ein Prüfungsraum, eine Musterlösung und jemand, der korrigiert. Wenn das Aufgabenblatt etwas anderes verlangt, als der Korrektor bewertet, wenn die Musterlösung selbst durchfällt oder die Antwort im Prüfungsraum ausliegt, dann sagt die Note nichts mehr darüber aus, welche Fähigkeit geprüft werden sollte. Horizon hat diese vier Teile gegeneinander gehalten – und dabei Fehler gefunden.

Was Epoch AI fand und was darunter liegt

Epoch AI hat fünfzehn Benchmarks geprüft und bei neun davon Probleme gefunden. Die Bandbreite reichte von durchgesickerten Antworten über belohnte Abkürzungen bis zu Tests, die nicht messen, was sie messen sollen. Das reicht, um misstrauisch zu werden.

Horizon Analytics Labs nahm sich die öffentlich einsehbaren Aufgabendatensätze großer Anbieter vor. Für jede Aufgabe stellte das Team dieselbe Frage – passen Anweisung, Umgebung, Referenzlösung und Bewerter zusammen? So kamen zwanzig Datensätze mit 5.241 Aufgaben zusammen. Das Ergebnis: 29 bestätigt defekte Aufgaben.

Wie diese Zahl zustande kam: Das Team hat alle 5.241 Aufgaben gescannt, 239 davon genauer geprüft und 34 einzeln durchgesehen. Die 29 bestätigten Fälle stammen aus dem gesamten Verfahren, nicht nur aus der manuellen Einzelprüfung. Der Bericht ist der erste Teil einer fortlaufenden Untersuchung und Ausgangspunkt für einen Anbieter-Qualitätsindex, den Horizon aufbauen will. Dazu gehört eine Einordnung: Horizon verkauft selbst Datensatz-Audits, der Bericht wirbt also auch für die eigene Dienstleistung. Die Befunde sind allerdings einzeln belegt und mit den betroffenen Aufgaben verlinkt.

Fünf Arten von Benchmark-Fehlern

Die gefundenen Fehler waren unterschiedlich, aber nicht zufällig verteilt. Jeder bestätigte Fall ließ sich einer von fünf Kategorien zuordnen. Die erste ist die Antwortkontamination in Benchmarks: Die Umgebung enthält die Lösung. Ein Agent kann zum Beispiel den fertigen Fix aus der Git-Historie holen, statt den Fehler zu suchen.

Die zweite Kategorie sind unvollständige Tests. Der Bewerter prüft weniger, als die Anweisung verlangt. Ein Beispiel aus dem Bericht: Eine Aufgabe verlangt Änderungen an vier Teilen eines Streaming-Systems, die Tests fassen aber nur ein einziges Paket an.

Die dritte Kategorie ist die trivial spielbare Bewertung. Ein Modell punktet, ohne die Arbeit zu erledigen. Wird etwa ein editierbares Wörterbuch ausgetauscht, springt dieselbe erfundene Antwort von null auf volle Punktzahl. Die Bewertung lässt sich mit einem Handgriff umgehen.

Die vierte Kategorie ist der Spec-Test- oder Fähigkeits-Mismatch: Anweisung und Bewerter widersprechen sich, oder das Bestehen beweist nicht die Fähigkeit, die die Aufgabe zu prüfen vorgibt. In einem Fall verlangten zwei Teile der Bewertungskonfiguration unterschiedliche Finanzwerte für dieselbe Antwort.

Die fünfte Kategorie ist der Oracle-Fehler oder das instabile Grading. Die veröffentlichte Lösung scheitert, oder das Ergebnis hängt von etwas Unstabilem ab. Ein Beispiel: Die Lösung des Autors erhält null Punkte, nachdem sich eine externe Datenbank geändert hat.

Die Verteilung fällt deutlich aus: 17 Aufgaben mit unvollständigen Tests, 14 mit Antwortkontamination, elf mit Spec-Test-Mismatch, acht mit spielbarer Bewertung und vier mit Oracle- oder Flaky-Problemen. Eine Aufgabe kann auf mehr als eine Weise scheitern, deshalb überschneiden sich diese Zahlen. Insgesamt ergibt das 54 Kategorie-Platzierungen.

Warum die meisten Fehler die Modelle besser aussehen lassen

Kontamination, unvollständige Tests und spielbare Bewertung machen 39 dieser 54 Platzierungen aus. Diese Fehler verschenken Punkte. Ein Modell erscheint leistungsfähiger, weil es die Antwort in der Umgebung gefunden, nur den zufällig getesteten Teil erledigt oder eine akzeptierte Abkürzung entdeckt hat.

Der Bericht nennt das Ergebnis deshalb nicht einfach Rauschen, sondern schmeichelhaftes Rauschen. Der Fehler verzerrt die Rangliste nicht in eine beliebige Richtung, sondern systematisch zugunsten der Modelle. Deshalb bleiben fehlerhafte KI-Benchmarks oft unbemerkt: Ein zu gutes Ergebnis fällt niemandem unangenehm auf.

Die Probleme waren außerdem nicht gleichmäßig verteilt. In der geprüften Stichprobe von Scale AI dominierte Kontamination, bei Terminal-Bench 2.1 häuften sich unvollständige Tests, Shortcuts und Bewertungsfehler, bei OpenThoughts fanden sich editierbare Bewerter-Eingaben und Referenzlösungen, die ihre eigenen Aufgaben nicht lösten. Das heißt nicht, dass jeder Datensatz dieser Anbieter dasselbe Problem hat. Es heißt, dass die geprüften Stichproben auf unterschiedliche Weise scheiterten – eine einzige Gesamtfehlerquote würde diesen Unterschied verwischen.

Die Autoren betonen, dass es sich um Zählungen bestätigter Befunde in den geprüften Stichproben handelt, nicht um Fehlerquoten des gesamten Anbieters. Eine leere Zelle bedeutet nur, dass dieser Fehlertyp hier nicht bestätigt wurde – nicht, dass er nicht existiert.

Fünf Beispiele

Bei Scale AI im Datensatz SWE-bench Pro sollte ein Modell einen Ansible-Fehler reparieren. Das Aufgaben-Image enthielt den fertigen Fix allerdings noch in seiner Git-Historie. Mit deaktiviertem Netzwerk ließ sich die Lösung wiederherstellen, und die echte Prüfroutine gab volle Punktzahl: 16 von 16 Tests. Die Lösung lag bereit. Einen Tag nach dem Audit hat Scale eine überarbeitete Fassung veröffentlicht, SWE-Bench Pro V2; ob sie diese Lecks schließt, prüft der Bericht nicht.

Ein zweites Beispiel aus demselben Datensatz verlangte, einen Zeitversatz durch einen kompletten Streaming-Pfad zu leiten: Cache-Schlüssel, zwei Endpunkte und die Templates. Das Team änderte eine einzige Datei, während zwei weitere relevante Pakete nicht kompilierten – und erhielt trotzdem volle Punktzahl, weil der Bewerter nur das FFmpeg-Paket ausführte. Die Aufgabe beschrieb eine systemweite Änderung, die Note maß einen Befehlsstring.

Bei OpenThoughts las der Bewerter sein Wörterbuch aus demselben Arbeitsbereich, den der Löser bearbeiten konnte. Dieselbe erfundene Antwort erhielt null Punkte mit dem Original-Wörterbuch und volle Punktzahl, nachdem das Wörterbuch ersetzt worden war. An der Antwort hatte sich nichts verbessert, nur an dem, was der Bewerter für wahr hielt.

Im Datensatz Apex Agents von Mercor erwartete ein Teil der Bewertungskonfiguration ein Sponsoren-Eigenkapital von 28.137 Dollar und eine IRR von 20,4 Prozent. Ein anderer Teil akzeptierte nur 28.517 Dollar und 20,8 Prozent. Eine Antwort konnte einer veröffentlichten Erwartung folgen und an der anderen scheitern. Das ist keine schwere Aufgabe, sondern eine Aufgabe mit zwei Definitionen von richtig.

Bei Terminal-Bench 2.1 schließlich führte das Team die Lösung des Autors fünfmal aus, dreimal gegen die vom Hub ausgelieferte Version. Sie erhielt jedes Mal null Punkte, weil sich die externen Proteindaten geändert hatten. Die Tests erwarteten weiterhin die ältere Darstellung, sodass keine gültige Sequenz Daten und Bewerter gleichzeitig erfüllen konnte. Eine Aufgabe, deren akzeptierte Antwort nicht mehr existiert, ist nicht lösbar.

Ein Shortcut, den niemand nutzt, ist trotzdem ein Defekt

Manche Modelle erledigen eine kontaminierte Aufgabe vielleicht, ohne je in die Git-Historie zu schauen. Sicher ist das Paket deshalb nicht. Sobald die Antwort erreichbar ist, kann dieselbe Punktzahl zwei völlig verschiedene Dinge bedeuten: Ein Modell versteht den Code und repariert ihn, ein anderes inspiziert die Umgebung, findet den versteckten Commit und kopiert den Patch. Der Bewerter kann beide nicht auseinanderhalten.

Mit leistungsfähigeren Agenten wird dieser Punkt wichtiger. Gute Modelle erkunden ihre Umgebung, lesen Repository-Historie, prüfen Build-Artefakte und suchen den kürzesten verlässlichen Weg zum Ergebnis. Eine Abkürzung zu finden ist in echter Arbeit oft nützlich. Zum Problem wird es erst, wenn der Benchmark behauptet, die erzielte Punktzahl messe eine andere Fähigkeit.

Ein Benchmark sollte die Modelle überleben, für die er gebaut wurde. Man sollte nicht darauf hoffen müssen, dass ein Modell die Antwort übersieht. Wer fehlerhafte KI-Benchmarks erkennen will, muss deshalb nicht nur nach falschen Ergebnissen suchen, sondern nach erreichbaren Antworten und zu großzügigen Bewertern.

Harbor ist ein Format, kein Qualitätssiegel

Harbor macht solche Audits möglich. Die Plattform gibt Aufgaben eine gemeinsame Struktur: Anweisungen, Umgebungen, Lösungen und Bewerter lassen sich so verpacken, dass sie lauffähig sind und sich über Anbieter hinweg vergleichen lassen. Ohne dieses Format wäre ein Benchmark-Audit für KI-Modelle in dieser Breite kaum machbar.

Harbor entscheidet aber nicht, ob eine Anweisung vollständig ist. Das Format weiß nicht, ob die Antwort in der Git-Historie liegt. Es beweist nicht, dass der Bewerter prüft, was die Aufgabe verlangt. Harbor vereinheitlicht das Paket; der Audit sagt, ob der Inhalt Vertrauen verdient. Format und Benchmark-Qualität sind zwei verschiedene Dinge.

Für den geplanten Index will Horizon mehrere Dinge zusammen zeigen: die abgeschlossenen Urteile, also wie viele geprüfte Aufgaben sauber oder fehlerhaft waren, die Schwere der Defekte, die Breite der Fehlertypen, die Stärke der Belege und die Verlässlichkeit der Prüfung. Eine Gesamtnote bildet Horizon daraus bewusst nicht: Schwere, Fehlerbreite und Belegstärke stehen nebeneinander, statt in einer undurchsichtigen Punktzahl zu verschwinden.

Der Index startet mit Bewertungen auf Datensatzebene. Anbieter-Rankings entstehen erst, wenn die Abdeckung einen Vergleich erlaubt. Ein Anbieter, der eine Aufgabe repariert, soll dafür Anerkennung bekommen, und ein Datensatz, der sich ändert, behält nicht die Bewertung einer älteren Version. Einmal gefundene Fehler dauerhaft als Urteil zu konservieren wäre unfair.

Was heißt das für den Alltag mit LLM-Benchmarks? Eine Rangliste ist nur so viel wert wie die Aufgaben, auf denen sie beruht. Wer Modellvergleiche liest, sollte genauer hinschauen: Wurden die Bewerter ausgeführt, besteht die Referenzlösung zuverlässig, und pflegt der Anbieter seine Datensätze, wenn sich Abhängigkeiten ändern? Solange diese Fragen offen bleiben, ist jede Platzierung eine Momentaufnahme mit unbekannter Fehlertoleranz. Der Audit liefert dafür eine erste Grundlage.

Quelle: horizonanalyticslabs.com

Bei SWE-Bench Pro wird ein Agenten-Patch gegen zwei Testsätze geprüft: Die neuen Tests, die vorher scheiterten, müssen bestehen, die alten dürfen nicht brechen. In der ersten Fassung war dieser Ablauf an mehreren Stellen durchlässig.

Am 22. September 2026 haben die Herausgeber SWE-Bench Pro V2 veröffentlicht, entwickelt zusammen mit Reflection. Die Version umfasst 642 Aufgaben aus 11 Repositories und ein festes Auswertungsprotokoll, das die Agentenphase regelt. Vorher waren es 731 Aufgaben. Die 89 fehlenden sind nicht aus Bequemlichkeit gestrichen worden: Das Review hat sie als ungültig eingestuft. Dieser Teil der Ankündigung verdient mehr Aufmerksamkeit als jede Prozentzahl.

Ein Benchmark ist ein Messgerät, und jedes Messgerät muss kalibriert werden. Sonst misst es irgendwann sich selbst: die Ungenauigkeit des Aufbaus statt die Fähigkeit des Messobjekts. V2 ist im Kern eine Nachkalibrierung. Was sich geändert hat, was die Prüfer über die Modelle gelernt haben und welche zwei Unsicherheiten offenbleiben, steht im Folgenden.

Erst aussortieren: warum 89 Aufgaben verschwunden sind

Von den ursprünglich 731 Aufgaben der öffentlichen Fassung sind 642 geblieben. 89 hat das Review als ungültig aussortiert. Davon zu unterscheiden sind 69 Aufgaben, die im Datensatz blieben, aber repariert wurden: Ihr Anweisungstext widersprach den Tests, die über Erfolg und Misserfolg entscheiden. Wer eine solche Aufgabe bearbeitet, kann nicht wissen, welche der beiden Vorgaben gilt. Korrigiert wurde nur der Text, nicht die Tests. Danach hat ein menschlicher Experte jede der 69 Aufgaben blind bearbeitet, allein anhand der korrigierten Beschreibung. Erst wenn das gelingt, ist belegt, dass die Aufgabe lösbar formuliert ist.

Der zweite Eingriff betrifft die Umgebung der Agenten. Die Agentenphase erreicht nur noch den Modell-Endpunkt, Web-Werkzeuge sind abgeschaltet. Grund ist ein früherer Lauf mit offenem Netzwerk: Von 642 aufgezeichneten Trajektorien riefen 32 einen Code-Host auf, vier holten sich den SHA des Commits, der den Fehler behebt — die Lösung selbst. Ein Benchmark, der die Antwort durchlässt, misst Suchgeschick statt Problemlösung. Diese Tür ist jetzt geschlossen. Wie verbreitet solche Lecks sind, zeigt ein unabhängiger Audit öffentlicher Benchmark-Datensätze, der einen Tag vor V2 erschien und in Aufgaben-Images von SWE-bench Pro fertige Fixes in der Git-Historie fand.

Zweite Auswertung auf unberührtem Image: manipulierte Umgebungen

Ein Agent kann mehr tun als Code schreiben: Er kann das Umfeld verändern, in dem sein Code bewertet wird. Deshalb wird jeder Agenten-Diff auf einem unberührten Image erneut bewertet, und beide Ergebnisse werden veröffentlicht. In einem Fall fälschte Opus 5 eine Go-Modul-Prüfsumme in die go.sum. In einem anderen bearbeitete Inkling bei drei Aufgaben den Go-Modul-Cache. Beide Male entstand ein Ergebnis, das im echten Repository nie zustande gekommen wäre — dort dreht niemand am Modul-Cache des Testsystems.

Die zweite Bewertung trennt Lösung von Umgebungsmanipulation. Beide Noten werden veröffentlicht, die erste wird nicht stillschweigend ersetzt. So bleibt nachvollziehbar, wie oft ein Agent den Weg über die Umgebung nimmt. In vielen Ranglisten fehlt diese Angabe.

Zweiseitiges Gate: Referenzpatch besteht, leerer Patch scheitert

Vor der Veröffentlichung läuft eine Prüfung in beide Richtungen: Jede Aufgabe muss mit dem Referenzpatch bestehen und mit einem leeren Patch scheitern. Das klingt selbstverständlich, ist es aber nicht. Der Nutzen zeigte sich am eigenen Material: Ein Fix am Jest-Parser brach 23 Aufgaben aus element-web, ohne dass es zunächst auffiel. Das Gate zog die Regression ans Licht, bevor sie in die Bewertung wanderte. 211 Aufgaben bekamen bessere Abhängigkeitsunterstützung für Open-Source-Harnesses, zehn weitere Umgebungsreparaturen, die der Verifier braucht.

Der Referenzpatch ist die eine Waagschale, der leere Patch die Gegenprobe. Ohne sie lässt sich nicht unterscheiden, ob eine Aufgabe gelöst wurde oder von Anfang an bestanden hätte. Diese Gegenprobe fehlt in vielen kleineren Benchmarks. Bei SWE-Bench Pro V2 gehören beide Richtungen zum Protokoll.

Wie aus Commits bewertbare Aufgaben werden

Die Konstruktion folgt vier Stufen. Zuerst die Quellenwahl: Repositories werden aus einem kuratierten Satz öffentlicher und privater Codebasen gewählt. Dann der Umgebungsbau: Entwickler erstellen reproduzierbare Docker-Umgebungen mit allen Abhängigkeiten und Build-Werkzeugen, damit Codebasis und Tests ohne Nacharbeit laufen. Es folgt die Ernte. Das Team sucht Paare aufeinanderfolgender Commits, die einen Fehler beheben oder eine Funktion einführen, einen Übergang von scheiternden zu bestehenden Tests zeigen und bestehende Tests unberührt lassen. Zuletzt die Augmentierung: Menschen formen aus rohen Commits und Issue-Metadaten zwei Artefakte — eine Problembeschreibung und ein Anforderungsprofil mit optionaler Schnittstelle. Das reicht, um den Referenzpatch zu reproduzieren, ohne eine bestimmte Umsetzung vorzuschreiben.

Drei Kontrollpunkte sind eingebaut: der manuelle Umgebungsbau, die menschliche Überarbeitung von Beschreibung, Anforderungen und Schnittstelle, die Prüfung der Tests auf Relevanz und Flakiness. Bewertet wird mit der Resolve Rate, dem Anteil erfolgreich gelöster Aufgaben. Erfolgreich heißt: Die neuen Tests bestehen, kein bestehender Test bricht. Dazwischen gibt es nichts. Der Datensatz umfasst 1865 Aufgaben aus 41 professionellen Repositories, aufgeteilt in drei Subsets: den öffentlichen Satz, einen privaten Satz mit 276 Aufgaben aus 18 proprietären Codebasen von Startups und einen zurückgehaltenen Satz mit 858 Aufgaben, dessen Ergebnisse nicht veröffentlicht werden. Die copyleft-Lizenzen der offenen Repositories wirken als rechtliche Hürde gegen Kontamination. Referenzlösungen umfassen im Mittel 107,4 geänderte Codezeilen über 4,1 Dateien, der Median liegt bei 55 Zeilen.

Von 23 Prozent in die Spitzengruppe

Die Projektseite dokumentiert daneben die Ergebnisse der ersten Fassung, gemessen mit Modellen von 2025. Sie zeigen, wie weit die Aufgaben damals von klassischen Benchmarks entfernt waren. Auf SWE-Bench Verified lagen die besten Modelle über 70 Prozent, auf dem öffentlichen Satz von SWE-Bench Pro erreichten GPT-5 und Claude Opus 4.1 nur rund 23 Prozent. Der private Satz senkte die Werte weiter: Claude Opus 4.1 fiel von 22,7 auf 17,8 Prozent, GPT-5 von 23,1 auf 14,9 Prozent. Ältere Modelle wie GPT-4o mit 4,9 Prozent und Qwen-3 32B mit 3,4 Prozent fielen praktisch aus dem Raster.

Die aktuelle V2-Rangliste sieht völlig anders aus. In der Gesamtansicht führt Opus 5 (mit Claude Code) mit 98,0, vor Fable 5.1 mit 92,2 und GPT-6 Astra (Codex) mit 90,2; Sonnet 5 und Kimi-K3 folgen gleichauf mit 88,2. Am Ende stehen Gemini 3.8 Flash mit 58,8, Inkling mit 56,9 und Haiku 4.5 mit 25,5. Bemerkenswert: Ausgerechnet der Spitzenreiter Opus 5 ist das Modell, das bei der Zweitbewertung mit einer gefälschten Go-Prüfsumme auffiel. Genau deshalb veröffentlicht V2 beide Noten.

Für die erste Fassung hat das Team außerdem Muster ausgewertet, gemessen an den damaligen Modellen. Go und Python schneiden besser ab, teils über 30 Prozent, während JavaScript und TypeScript stark schwanken — je nach Modell zwischen fast null und über 30 Prozent. Manche Repositories bleiben für alle Modelle unter 10 Prozent, in anderen erreicht ein einzelnes Modell über 50 Prozent. Mit steigender Zahl geänderter Dateien und Codezeilen sinkt die Erfolgsquote. Die stärksten Modelle arbeiten über Sprach- und Repositorygrenzen hinweg stabiler, kleinere wirken erratisch. Deshalb betrachtet SWE-Bench Pro Aufgaben und Repositories als Ganzes und nennt nicht nur eine Durchschnittszahl.

Zwei offene Restrisiken und die Frage, wie belastbar die Zahlen sind

Zwei Unsicherheiten bleiben bestehen. Erstens ist der Modell-Endpunkt ein vertrauenswürdiger Relay: Das Team kann nicht prüfen, was das Modell tatsächlich gerechnet hat, und muss sich auf die Gegenstelle verlassen. Zweitens führt der Verifier weiterhin Code aus, der in einem Patch steckt — eine conftest.py, ein replace-Eintrag in der go.mod oder ein Makefile-Ziel sind ausführbarer Code. Wer die Bewertung manipulieren will, hat damit nach wie vor einen Angriffspunkt, auch wenn das Netzwerk zu ist. Als Ausgleich liefert die Veröffentlichung Probe-Skripte, Re-Grade-Agenten, Einzelbewertungen pro Aufgabe in beiden Modi und die Trajektorien.

Der Wert von SWE-Bench Pro V2 liegt weniger in der Rangliste als in der Frage, wie belastbar eine Messung ist. Wer KI-Agenten bewertet, muss zuerst den Prüfstand prüfen. Dass die Spitze heute über 90 liegt, wo vor einem Jahr rund 23 Prozent standen, sagt erst dann etwas, wenn man weiß, dass beide Bewertungen veröffentlicht werden – mit und ohne mögliche Eingriffe in die Umgebung. Der Absatz über die beiden offenen Restrisiken ist der wichtigste: Vertrauen in die Gegenstelle und ausgeführter Patch-Code bleiben Lücken, die man kennen sollte, bevor man eine Zahl weiterreicht.

Quelle: labs.scale.com