4 Punkte von GN⁺ 2025-11-09 | 1 Kommentare | Auf WhatsApp teilen
  • Eine groß angelegte Studie unter Leitung des Oxford Internet Institute (OII) mit Beteiligung von 42 Forschenden weltweit bestätigt, dass es Benchmarks zur Bewertung von Large Language Models (LLM) an wissenschaftlicher Strenge mangelt
  • Die Prüfung von 445 KI-Benchmarks zeigte, dass mehr als die Hälfte unklare Begriffsdefinitionen oder schwache Analysemethoden aufweist und dadurch keine verlässlichen Schlussfolgerungen zulässt
  • Nur 16 % der untersuchten Studien nutzten statistische Methoden, und abstrakte Konzepte wie „Schlussfolgern“ oder „Harmlosigkeit“ wurden häufig nicht klar definiert
  • Das Forschungsteam legt 8 Empfehlungen zur Verbesserung vor, darunter präzisere Definitionen, repräsentative Evaluationen und stärkere statistische Analysen, und veröffentlicht dafür das Tool Construct Validity Checklist
  • Die wissenschaftliche Validität von KI-Benchmarks entwickelt sich zu einer zentralen Herausforderung für den Fortschritt der KI-Technologie und die Glaubwürdigkeit von Regulierung

Überblick über die Studie

  • Die Studie wurde vom Oxford Internet Institute (OII) geleitet, beteiligt waren unter anderem EPFL, Stanford, TUM, UC Berkeley und Yale
  • Der Titel der Arbeit lautet Measuring What Matters: Construct Validity in Large Language Model Benchmarks; die Präsentation ist auf der Konferenz NeurIPS 2025 vorgesehen
  • Die Forschung analysierte systematisch 445 KI-Benchmarks, um die wissenschaftliche Validität ihrer Bewertungskriterien zu untersuchen

Zentrale Ergebnisse

  • Mangel an statistischer Strenge: Nur 16 % der untersuchten Studien verwendeten statistische Vergleichsmethoden
    • Behauptungen über Leistungsunterschiede oder Überlegenheit zwischen Modellen könnten auf Zufall beruhen
  • Vage oder umstrittene Definitionen: Etwa die Hälfte der Benchmarks definiert abstrakte Konzepte wie „Schlussfolgern“ oder „Harmlosigkeit“ nicht klar
    • Das Fehlen klarer Begriffsdefinitionen führt zu einer Diskrepanz zwischen Evaluationsziel und tatsächlicher Messung

Problembeispiele

  • Verwechslung mit Formvorgaben: Wenn beim Lösen einfacher Logikrätsel verlangt wird, Antworten in einem komplexen Format einzureichen, kann selbst eine richtige Lösung wegen eines Formatfehlers als falsch gewertet werden
  • Fragile Leistung: Es gibt Fälle, in denen Modelle bei einfachen Mathematikaufgaben stark sind, aber scheitern, sobald Zahlen oder Satzstrukturen nur leicht verändert werden
  • Unbegründete Behauptungen: Hohe Punktzahlen bei medizinischen Prüfungsfragen können fälschlich den Eindruck erwecken, ein Modell verfüge über Fachkompetenz auf dem Niveau von Ärztinnen und Ärzten

Empfehlungen zur Verbesserung

  • Das Forschungsteam hält eine Lösung der Probleme für möglich und legt 8 Empfehlungen vor, angelehnt an Validierungsmethoden aus Psychometrie und Medizin
    • Define and isolate: Das zu messende Konstrukt klar definieren und irrelevante Faktoren kontrollieren
    • Build representative evaluations: Reale Umgebungen abbilden und die gesamte Bandbreite der Zielkompetenz einbeziehen
    • Strengthen analysis and justification: Statistische Unsicherheit ausweisen, Fehleranalysen durchführen und die Validität des Benchmarks begründen
  • Mit der Construct Validity Checklist können Forschende, Entwickler und Regulierungsbehörden die Validität eines Benchmark-Designs im Vorfeld prüfen

Bedeutung der Studie

  • Benchmarks sind ein zentrales Instrument zur Festlegung von Forschungsrichtungen in der KI, Modellwettbewerb sowie politischen und regulatorischen Maßstäben
  • Benchmarks mit schwacher wissenschaftlicher Grundlage bergen das Risiko, Missverständnisse über Leistung und Sicherheit von KI zu erzeugen
  • Die Studie wird als Modell internationaler Zusammenarbeit zur Sicherung der Verlässlichkeit von KI-Evaluationen vorgestellt

Weitere Informationen

  • Die Arbeit soll vom 2. bis 7. Dezember 2025 auf der NeurIPS 2025 vorgestellt werden
  • Unterstützt wurde die Forschung von verschiedenen Einrichtungen, darunter das Clarendon-Stipendium, ESRC, EPSRC und der Meta LLM Evaluation Research Grant
  • Das OII untersucht seit 25 Jahren die gesellschaftlichen Auswirkungen neuer Technologien wie Künstliche Intelligenz, digitale Plattformen und autonome Systeme

1 Kommentare

 
GN⁺ 2025-11-09
Hacker-News-Kommentare
  • Ich bin in einem Forschungslabor für LLM-Benchmarks und menschliche Evaluation zuständig.
    Ehrlich gesagt ist dieses Feld derzeit praktisch ein kompletter Wilder Westen. Es gibt keine richtige Lösung, und auch die Forschenden wollen sich nicht nur ans Benchmarking klammern.
    Auf Produktebene sind klassische A/B-Tests am Ende die realistischste Methode. Denn damit lassen sich direkte Metriken im großen Maßstab messen.
    Natürlich gibt es auch Dinge wie „benchmarketing“, aber die meisten wollen tatsächlich aufrichtig gute Benchmarks bauen. Es ist nur einfach zu schwierig oder unmöglich.

    • Ich arbeite bei einem Hyperscaler an Plattform-Infrastruktur, und auch die Benchmarks in unserem Bereich sind ein Chaos.
      Obwohl die messbaren Metriken klar sind, ist die Statistik miserabel. Meist werden nur Mittelwertdifferenzen verglichen, und selbst die Berechnung der p-Werte ist nicht vertrauenswürdig.
      Außerdem gibt es fast keine Korrelation zur Performance realer Workloads. Experimente in Produktion sind so verrauscht, dass man Verluste leicht übersieht.
      Bei AI ist es noch schlimmer. Schon das Messobjekt ist unklar, und es gibt Anreize für Noise-Messung für den Aktienkurs. Dass LLM-Benchmarks unter solchen Bedingungen schlecht sind, ist kaum überraschend.
    • Auch A/B-Tests sind riskant. Im Ergebnis optimiert man indirekt auf Nutzerfeedback, und menschliche Evaluatoren lassen sich leicht manipulieren.
      B kann seine Punktzahl einfach dadurch erhöhen, dass es Menschen „täuscht“. Der Fall von OpenAI 4o ist ein typisches Beispiel.
    • Es hat mich schockiert zu sehen, dass ein Modell Matheaufgaben auf Grundschulniveau gut löst, aber schon bei kleinen Änderungen an Zahlen oder Formulierungen scheitert. Letztlich ist das nur Muster-Memorisierung.
    • Ich halte es für das größere Problem, dass Tech-Unternehmen und Medien solche Probleme nicht transparent offenlegen. Benchmark-Scores werden vermarktet, als wären sie objektive Kennzahlen.
    • Ich arbeite ebenfalls an LLM-Evaluation, und zynisch betrachtet sind die meisten Benchmarks Pseudo-Aufgaben. Denn es gibt kaum echte Anwendungsfälle dafür.
      Etwas großzügiger betrachtet liegt das Problem darin, dass Intelligenz an sich schwer zu benchmarken ist. Schon bei Menschen ist es schwierig, Eignung für eine Tätigkeit mit standardisierten Fragen zu bewerten; bei AI gilt das umso mehr.
  • Ich arbeite im Bereich TTS (Text-to-Speech), und dort ist es noch mehr ein Bereich des Chaos als bei LLMs.
    Demos sind perfekt, aber wenn man Hunderte von Minuten generiert, treten ständig Lautstärke-Drift, Tempowechsel und Aussprachefehler auf.
    Das größte Problem ist, dass es keinen Standard-Benchmark für langfristige Sprachsynthese gibt.
    Ich habe in Death of Demo einen Artikel mit vorgeschlagenen Kriterien dazu geschrieben.

  • Ich habe über das Projekt Humanity’s Last Exam geschrieben.
    Dabei werden schwierige Fragen per Crowdsourcing von Fachleuten weltweit gesammelt, um AI-Modelle zu testen.
    Interessant fand ich, dass selbst für Menschen einfache Probleme für AI weiterhin schwierig sind.
    Letztlich hängt die Zukunft des AI-Trainings von Erfahrungen in der realen Welt (meatspace) und von Annotationen zum Schlussfolgern ab.

    • Unternehmen wie Mercor oder Micro1 erzielen mit diesem Ansatz bereits neunstellige Jahresumsätze.
  • Ich denke, Benchmarks sind SAT-Punktzahlen ähnlich. Sie sind keine perfekte Vorhersage, aber als grobes Signal brauchbar.
    LLMs entwickeln sich in eine sinnvolle Richtung, und Benchmarks spiegeln das bis zu einem gewissen Grad wider.

    • Aber es gibt keinen Grund, warum Prüfungen für Menschen die Arbeitsleistung von LLMs vorhersagen sollten. Eine einfache Multiplikationsaufgabe korreliert zum Beispiel mit menschlicher Intelligenz, ist für Computer aber bedeutungslos.
    • Das ist wie eine Prüfung zur Bewertung von Kunstkritikern. Schon der Versuch, subjektive Ergebnisse objektiv zu benoten, ist widersprüchlich.
    • Die Formulierung „klar verbessert“ verwischt den Punkt. Tatsächlich ist schon umstritten, ob es überhaupt eine sinnvolle Verbesserung gibt.
  • Im aktuellen LLM-Boom sind Benchmarks das schwächste Glied.
    Vergleiche zwischen Modellen sind fast ein pseudowissenschaftliches Durcheinander.
    Ich nutze das LMArena-Leaderboard, aber die Unterschiede zwischen den Modellen sind nicht erklärbar.
    Prompts sind stark an Modellversionen gekoppelt, sodass etwas, das mit GPT-4 gut funktionierte, mit GPT-5 kaputtgeht.
    Deshalb neige ich inzwischen einfach dazu, Gemini zu verwenden.

    • Die Bewertungen in LMArena lassen sich viel zu leicht manipulieren. Auch menschliche Evaluatoren fallen leicht auf schmeichelnde Antworten herein.
      Solches feedbackbasiertes Tuning verschärft das Überkonfidenzproblem von LLMs.
    • Ich habe eine Website namens AImodelReview gebaut, um die Ausgaben verschiedener Modelle zu vergleichen.
      Aber Nutzer wollen nicht selbst bewerten, sondern Leaderboard-artige Ranglisten.
      Man kann auch LLMs als Richter einsetzen, aber das fühlt sich irgendwie falsch an.
      Am Ende braucht man Evaluation auf Basis von Experten-Reviewern, aber das ist teuer.
    • Das erinnert mich daran, dass menschliche psychologische Tests ähnlich schwierig sind.
  • Für einzelne Entwickler ist die Lösung, eigene Benchmarks direkt zu bauen.
    Man erstellt Tests auf Basis von Codeproblemen, die man selbst gelöst hat, und schaut auf Metriken wie tok/s oder TTFT.

    • Ich nutze LLMs nur in einer Agent-Wrapper-Umgebung, deshalb ist mein Benchmarking einfach. Ich probiere die Aufgabe mit einem neuen Modell aus und entscheide nach Gefühl über Pass/Fail.
      Letztlich ist die realistischste Bewertung, dass Nutzer es einfach selbst ausprobieren.
    • Wenn man dem GitHub von OpenAI eine Evaluation hinzufügt, wird das nächste Modell bei genau diesem Problem besser.
    • Solche eigenen Bewertungen nennt man evals, und für ernsthafte AI-Projekte sind sie unverzichtbar.
    • Websites wie AI Stupid Level verfolgen einen ähnlichen Ansatz.
    • Man sollte allerdings nicht vergessen, dass „ein Problem lösen“ auch einfach Mustererkennung sein könnte.
  • Jemand führte Aufgaben aus prüfungsähnlichen AIME-Tests ohne Taschenrechner als Beispiel an und meinte, Benchmarks mit nur kleinen Zahlen spiegelten die tatsächlichen Fähigkeiten nicht wider.
    Ich denke aber, dass es auch eine Form von Fortschritt ist, wenn Modelle sich wie Menschen Prüfungstaktiken aneignen. Das kommt menschlichem Schlussfolgern näher.

    • Umgekehrt gibt es auch die Meinung, dass echte Schlussfolgerungsfähigkeit bedeuten müsste, auch Probleme mit großen Zahlen zu lösen.
    • Wenn Studierende Aufgaben mit Prüfungstaktik lösen, ist das nur ein Teil menschlicher Bewertung; LLMs verkaufen das aber als ihre Gesamtfähigkeit.
      Ich will eine nicht gamifizierte Evaluation. Im Moment ist das nur intelligentes Autocomplete.
    • Rechenaufgaben werden letztlich ein Problem sein, das mit Tool-Nutzungskompetenz verschwindet.
    • Auch das Forbidden-Technique-Video zu dieser Debatte ist interessant.
    • Wenn man LLMs externe Tools wie Excel oder Mathematica nutzen lässt, könnten sie Rechenaufgaben wie Menschen lösen.
  • Es gab den Vorschlag, gemeinsam ein Git-Repo mit nervigen Bugs zu bauen, um LLMs daran zu testen.
    Ich habe zum Beispiel Yjs/CRDT-Bugs mit Claude Code, GPT5-codex und GLM-4.6 ausprobiert, aber am Ende waren nur Workarounds möglich.
    Erst als ich Frontend-Logs ans Backend geschickt habe, damit die AI sie in Echtzeit sieht, gab es Fortschritte.

    • Es war effektiv, die Playwright-Bibliothek direkt einsetzen zu lassen, um Frontend-Probleme zu lösen.
    • Allerdings könnte so ein Vorschlag faktisch auch bedeuten, kostenlos hochwertige Trainingsdaten für AI bereitzustellen.
    • Ich habe persönlich ebenfalls eine Sammlung von Bugs gebaut und LLMs Testcode dazu schreiben lassen, aber selbst aktuelle Modelle scheitern noch daran.
    • Tatsächlich pflegen die meisten erfahrenen LLM-Nutzer bereits ihre eigenen privaten Benchmarks.
      Wenn man sie veröffentlicht, werden sie in Trainingsdaten absorbiert und damit entwertet.
      Solche persönlichen Benchmarks helfen, das tatsächliche Tempo realer Modellfortschritte viel nüchterner zu betrachten.
  • Benchmarks sind letztlich nur Spezifikationen für einen bestimmten Kontext. Sie zeigen nur, dass Code in einer bestimmten Situation gut funktioniert, garantieren aber nicht alle Fälle.

    • Wie Dijkstra sagte: „Tests können die Existenz von Bugs zeigen, aber nicht ihre Abwesenheit beweisen.“
      Auf LLMs übertragen heißt das: „Benchmarks zeigen nur, welche Aufgaben möglich sind, beweisen aber nicht, welche unmöglich sind.“
  • In dieser Studie wurden 445 Benchmarks untersucht, und bei den meisten fehlt es angeblich an Konstruktvalidität.
    Wenn man echte Intelligenz messen will, muss man Neuheit (novelty) bewerten.
    Das Lösen von Mustern, die bereits gesehenen Problemen ähneln, ist nur simples Auswendiglernen.
    Aber es ist fast unmöglich, angesichts von Hunderten Petabytes an Trainingsdaten völlig neue Probleme zu erstellen, die diese Daten sicher vermeiden.
    Dadurch entsteht eine Illusion von Intelligenz.

    • Problemlösung einfach in „Erinnerung“ und „Kreativität“ aufzuteilen, ist ein falscher Ansatz.
      Tatsächlich gibt es zwischen beiden Konzepten unzählige Grauzonen.
      Selbst ein völlig neues Problem braucht ein gewisses Maß an Ähnlichkeit, damit es lösbar ist.