Benchmarks messen bei KI jetzt auch Zweifel, nicht nur Antworten
Am 5. Oktober veröffentlichte GitHub ReviewBench, einen offenen Benchmark für Code-Reviews. Er beruht auf einer Analyse von 103.900.000 Pull Requests und enthält 219 Fälle. Im September beschrieben Forscher der UC Riverside einen Weg, die Zuversicht eines Modells von seiner Korrektheit zu trennen.

Zwei Arbeiten gehen dasselbe Problem von entgegengesetzten Seiten an. Sie erschienen nicht am selben Tag. GitHub veröffentlichte ReviewBench, einen offenen Benchmark für KI-Code-Reviews, der aus einer Analyse von 103.900.000 Pull Requests auf der Plattform hervorging. Unabhängig davon beschrieben Informatiker der UC Riverside ein Verfahren, mit dem sich die internen Merkmale finden lassen, die ein Sprachmodell zuversichtlich klingen lassen, obwohl es falsch liegt.
Keine der beiden Arbeiten ist eine Produkteinführung. Beide versuchen eine Frage zu beantworten, die Käufer und Nutzer immer wieder stellen: Wenn ein Modell etwas sagt, woran soll man erkennen, ob man ihm glauben kann?
Was GitHub gebaut hat
ReviewBench, vorgestellt im GitHub Blog, enthält 219 öffentliche Pull Requests aus 187 Open-Source-Repositories in 19 Sprachen. Laut GitHub entspricht die Mischung aus Sprachen und Repository-Größen weitgehend der eigenen Gesamtverteilung. Erfahrene Entwickler haben die echten Treffer vor der Veröffentlichung von Hand gekennzeichnet. Der Datensatz ist öffentlich.
Der Benchmark bewertet vier Kennzahlen und ordnet jeden Fund nach Schweregrad und Kategorie ein. Teams können die Ergebnisse nach der Art des Reviews filtern, die sie interessiert. Laut GitHub hilft das dabei, Prüfer zu vergleichen, die viele Probleme melden, mit solchen, die still bleiben, und hohe Trefferquoten mit kleinen Hinweisen.
Die wichtige Zahl ist 103.900.000. So viele Pull Requests hat GitHub ausgewertet, um reale Review-Arbeitslasten zu erfassen, und die 219 Fälle folgen dieser Verteilung. Eine Anpassung hat GitHub bewusst vorgenommen. Die Größe der Pull Requests ist stärker auf die mittlere und obere Mitte der Verteilung gewichtet, was die Überrepräsentation sehr großer Änderungen verringert. Das Unternehmen schreibt außerdem, seine Offline-Bewertung von Copilot Code Review sage die Richtung von Produktionsexperimenten inzwischen verlässlicher voraus.
Unbekannt bleibt, wie ein Wettbewerber abschneidet. GitHub lädt andere Code-Review-Systeme ein, sich anzumelden und Ergebnisse einzureichen. Der Beitrag nennt keine Rangliste und keine Zahlen eines Basismodells.
Warum Zuversicht keine Korrektheit ist
Die Studie der UC Riverside unter Leitung des Doktoranden Het Patel blickte in zwei Modelle mit offenen Gewichten: Llama-3.1-8B von Meta mit 8.000.000.000 Parametern und Gemma-2-9B von Google mit 9.000.000.000 Parametern. Das Team stellte Multiple-Choice-Fragen und sortierte die Antworten in vier Gruppen, richtig oder falsch kombiniert mit zuversichtlich oder unsicher.
Mit Sparse Autoencodern fanden die Forscher drei Arten interner Merkmale: einige hingen vor allem mit Unsicherheit zusammen, einige vor allem mit falschen Antworten, einige mit beidem. Unterdrückten sie die Merkmale, die rein an Unsicherheit hängen, sank die Genauigkeit deutlich. Das deutet darauf hin, dass diese Merkmale echte Arbeit leisten, wenn gute Antworten entstehen. In der Mitteilung der Universität heißt es, die Veränderung einiger Merkmale habe das Verhalten des Modells geändert, ohne das ganze Modell neu zu trainieren.
„Die Hauptannahme in dem Feld ist, dass ein Modell wahrscheinlich richtig liegt, wenn es zuversichtlich ist, und eher falsch, wenn es unsicher ist“, sagte Patel. „Aber wir sehen oft die Gegenbeispiele, die gut dokumentiert sind.“
Daran sollte man sich halten. Ein Zuversichtswert ist kein Verlässlichkeitswert, und ein Modell, das sich absichert, kann trotzdem recht haben. Manche Teams bauen Leitplanken ein, die Antworten unter einer Zuversichtsschwelle blockieren. Die Studie legt nahe, dass diese Schwelle das falsche Signal misst.
Kleinere Modelle, belegte Angaben
Leisere Beispiele derselben Disziplin tauchten anderswo auf. Ein GitHub-Projekt namens Jeff-Code kombiniert ein Entscheidungsmodell mit 800.000.000 Parametern mit Qwen 3.8-27B mit 27.000.000.000 Parametern in einem Coding-Agenten. Es meldet Aufgaben, die bei gleicher Erfolgsquote 47 Prozent schneller fertig sind (32 Prozent weniger Zeit). Die Zahlen sind ungewöhnlich genau: 62,4 Prozent gegenüber 62,8 Prozent Erfolgsquote, eine gepaarte Differenz von minus 0,2 Punkten mit einem 95-Prozent-Intervall von minus 2,6 bis plus 2,1, über 1.242 gepaarte Aufgaben.
Das Projekt nennt auch, wo es scheitert. Auf Terminal-Bench 2.0 (0,96x) und SkillsBench (0,91x) gab es keine klare Beschleunigung. Das Denken in jedem Schritt abzuschalten war schneller, kostete aber 7,6 Punkte. Eine weniger vorsichtige Schwelle von 0,7 kostete 4,5 Punkte.
Reflection stellte unterdessen Beam vor, ein Modell mit offenen Gewichten und 501.000.000.000 Parametern, von denen 23.000.000.000 aktiv sind, und veröffentlichte dazu eine breite Benchmark-Tabelle. Beam erreicht 80,9 auf SWE-bench Verified und 97,8 auf AIME 2.026. Das Unternehmen sagt, es komme mit 3 bis 4 Mal weniger Inferenzrechenleistung auf Ergebnisse, die mit GLM-5.2 vergleichbar sind. Das Modell durchläuft noch das abschließende Red-Teaming; Gewichte, ein technischer Bericht und eine Modellkarte sind für später in diesem Monat angekündigt.
Die Benchmark-Tabelle eines Anbieters ist kein neutraler Beleg, und die Einschränkungen von Reflection sind wichtig. Der AA Omniscience Index ist nur mit dem öffentlichen Split und den eigenen Ergebnissen des Unternehmens ausgewiesen. Die Aussage zur Effizienz lässt sich prüfen, sobald die Gewichte erscheinen.
Wo die Zahlen übernommen werden
Vertraute Benchmark-Namen verbreiten sich schnell, und nicht immer unversehrt. Das Entscheidungsmodell d1 von Liquid AI wird in sechs Anwendungen mit GPT-6.1 Sol und Claude Opus 5.5 verglichen. Das Unternehmen behauptet, es erreiche oder übertreffe GPT-6.1 Sol in vier Fällen und koste 19- bis 200-mal weniger. In einer Demo zur Sichtprüfung meldet es 85 bis 97 Prozent Genauigkeit beim Sortieren guter und defekter Teile. Es merkt an, dass das Modell für diese Aufgabe nie trainiert wurde.
Interfaze veröffentlichte eine Benchmark-Tabelle für sein Modell Interfaze 1.1 Lite. Die Tabelle reicht von GPQA Diamond (85,9 gegenüber 92,4 für Interfaze) bis zur Worterkennungsrate von VoxPopuli. Es ist ein Anbietervergleich, keine Prüfung durch Dritte.
Außerhalb der Modellanbieter veröffentlichte Veris einen Voice-Agent-Benchmark, der wegen seiner Messgrößen interessanter ist. Auf VAmoS Pro Bench senkte ein hinter dem Anrufer laufender Fernseher die zusammengefasste Aufgabenlösung von 38,7 Prozent auf 8,6 Prozent. Neun von vierzehn Voice-Stacks lösten weniger als 5 Prozent der TV-Anrufe. Der beste Stack, Phonic, erreichte 57,5 Prozent Aufgabenlösung bei 1,42 Sekunden Latenz; der schlechteste, eine Pipecat-Kaskade, erreichte 17,3 Prozent.
Veris ist offen über die Grenzen. Das Board ist eine Prüfung, gebaut auf den Richtlinien eines einzigen Versorgers, mit simulierten Anrufern. Das ist eine engere Aussage als eine allgemeine Rangliste der Fähigkeiten, und Veris formuliert sie so.
Das ältere Argument darunter
Nichts davon beantwortet die tiefere Frage. David Chalmers' Aufsatz darüber, ob ein großes Sprachmodell Bewusstsein haben könnte, überarbeitet im August 2.024, argumentiert, dass heutigen Modellen rekurrente Verarbeitung, ein globaler Arbeitsbereich und eine einheitliche Handlungsfähigkeit fehlen. Er kommt zu dem Schluss, es sei etwas unwahrscheinlich, dass heutige Modelle bewusst sind, ihre Nachfolger aber könnten es sein.
Das ist Hintergrund, keine Nachricht, und es berührt nicht direkt die Frage, ob ein Code-Reviewer einen Fehler findet. Es erklärt aber, warum das Problem der Zuversicht schwer ist. Ein Modell, das flüssigen, sicheren Text erzeugt, hat keine eigene Instanz, die weiß, dass es falsch liegt. Die Arbeit der UCR legt nahe, dass sich ein solches Signal finden und anpassen lässt. Die Arbeit von GitHub legt nahe, dass es sich bewerten lässt.
Was beides nicht liefert, ist eine einzige Zahl, die ein Käufer in ein Beschaffungsdokument schreiben kann. ReviewBench hat noch keine veröffentlichten Ergebnisse von Wettbewerbern. Das Verfahren der UCR wurde an zwei Modellen mit offenen Gewichten gezeigt, nicht an den geschlossenen Systemen, die die meisten Unternehmen nutzen. Die Gewichte von Beam sind noch nicht draußen. Bis diese Lücken sich schließen, bleibt die ehrliche Antwort auf die Frage, ob ein Modell verlässlich ist, eine Reihe enger Messungen, jede mit einem genannten Geltungsbereich.
Quellen
9- 01ReviewBench: An open benchmark for AI code reviewEN
- 02Making AI more trustworthyEN
- 03Jeff-CodeEN
- 04Introducing Beam: Reflection's 501B open-weight modelEN
- 05Introducing d1: The most capable decision model, now with visionEN
- 06Interfaze-1-liteEN
- 07VAmoS Pro BenchEN
- 08Could a Large Language Model be Conscious?EN
- 09ReikaEN
Alle Zahlen und Zitate in diesem Text stammen aus den unten genannten Quellen.
Die Materialien wurden vom Redaktionsteam mit Unterstützung von KI erstellt.
Kommentare
0- Noch keine Kommentare — seien Sie der Erste.