Methodik für das Intelligenz-Benchmarking von Artificial Analysis

Artificial Analysis Intelligence Index v4.3.2

Artificial Analysis Intelligence Index

Artificial Analysis Intelligence Index kombiniert eine umfassende Suite von Bewertungsdatensätzen, um die Fähigkeiten von Sprachmodellen in den Bereichen Argumentation, Wissen, Mathematik und Programmierung zu bewerten.

Es ist eine hilfreiche Synthese der gesamten Intelligenz von Sprachmodellen und kann zum Vergleich von Sprachmodellen verwendet werden. Wie alle Bewertungsmetriken unterliegt sie Einschränkungen und ist möglicherweise nicht direkt auf jeden Anwendungsfall anwendbar. Wir sind jedoch zuversichtlich, dass es sich um einen nützlicheren Synthesevergleich zwischen Sprachmodellen handelt als jede andere heute existierende Metrik.

Artificial Analysis Intelligence Index v4.3.2 umfasst 10 Auswertungen: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, AA-LCR v1.1, AA-Omniscience, Humanity's Last Exam, GDP.pdf, CritPt. Unsere Methodik legt Wert auf Fairness und praktische Anwendbarkeit.

Wir schätzen ein 95 %-Konfidenzintervall für den Artificial Analysis Intelligence Index von weniger als ±1 % – basierend auf Experimenten mit >10 Wiederholungen bei bestimmten Modellen für alle im Artificial Analysis Intelligence Index v4.3.2 enthaltenen Bewertungsdatensätze. Einzelne Bewertungsergebnisse können breitere Konfidenzintervalle als ±1 % aufweisen. Wir freuen uns darauf, in Zukunft weitere Einzelheiten aus unserer statistischen Analyse bekannt zu geben.

Artificial Analysis Intelligence Index ist eine hauptsächlich textbasierte, englischsprachige Bewertungssuite. Wir vergleichen Modelle für Bildeingaben, Spracheingaben und mehrsprachige Leistung separat mit der Evaluierungssuite Intelligence Index.

Intelligence Index-Auswertungssuite

Der Intelligence Index wird als gewichteter Durchschnitt über vier Kategorien berechnet: Agenten (30 %), Kodierung (20 %), wissenschaftliches Denken (20 %) und Allgemein (30 %). Die Gewichtung betont die Agentenaufgaben. Die Kategoriezugehörigkeit und die Gewichtungen pro Bewertung werden unten angezeigt.

KategorieEvaluierungFragenWiederholungenAntworttypBewertungGewichtung im
Intelligence Index		Werkzeug
nutzung		Privat
Agenten (30%)AA-Briefcase v1.191 Aufgaben in 4 Szenarien1Aufgabenerledigung durch Agenten mit Dateien als ErgebnisKombinierter Elo-Wert aus paarweisen Vergleichen von Aufgabenerfolg nach Bewertungsraster, analytischer Qualität und Präsentationsqualität15%✓
GDPval-AA v2.1220 Aufgaben1Aufgabenerledigung durch Agenten mit Dateien als ErgebnisPaarweiser Vergleich (Elo) durch ein Jurorenpanel, verankert bei DeepSeek V4.1 Flash (max) mit 1600, eingefroren und skaliert10%✓✗
AutomationBench-AA657 Aufgaben1SaaS-Workflow-Automatisierung mit REST API-ToolsZielerreichung; Aufgaben mit einem Verstoß gegen Schutzvorgaben erhalten null Punkte5%✓
Programmieren (20%)Terminal-Bench 4.0663Terminalbasierte AufgabenausführungTestsuite mit pass/fail, pass@110%✗
SciCode288 Teilprobleme (Testdatensatz)3Python-Code (muss alle Unit-Tests bestehen)Codeausführung, pass@1; Bewertung auf Teilproblemebene mit von Wissenschaftlern annotierten Hintergrundinformationen im Prompt10%✗✗
Allgemein (30%)AA-Omniscience6,0001FreitextantwortGenauigkeit (10 %) und 1 – Halluzinationsrate (5 %) als separate Komponenten15%✗
GDP.pdf100 Aufgaben in 10 Bereichen5Freiform-Antwort basierend auf einem langen PDFAll-pass als Hauptkennzahl und Mean Pass mit gleicher Gewichtung je Aufgabe10%✗✗
AA-LCR v1.11003FreitextantwortLLM zur Prüfung der Antwortäquivalenz, pass@15%✗✗
Wissenschaftliches Schlussfolgern (20%)HLE (Humanity's Last Exam)2,1581FreitextantwortLLM zur Prüfung der Antwortäquivalenz, pass@110%✗✗
CritPt705Python Funktionen, symbolische Ausdrücke, numerische AntwortenOffizieller Bewertungsserver, pass@110%✗

Zusätzliche Evaluationen

Über die Intelligence Index-Suite hinaus führen wir eine Reihe zusätzlicher Auswertungen durch, die mehrsprachige, visuelle, mathematische und andere Fähigkeiten abdecken. Diese werden separat gemeldet und sind nicht im Intelligence Index-Score enthalten.

Artificial Analysis Multilingual Index: Stellt die Mehrsprachigkeit von Modellen dar. Dies basiert auf der Global-MMLU-Lite-Bewertung für alle unterstützten Sprachen. Wir unterstützen die folgenden Sprachen:

  • 🇬🇧 English
  • 🇨🇳 Chinese
  • 🇮🇳 Hindi
  • 🇪🇸 Spanish
  • 🇫🇷 French
  • 🇸🇦 Arabic
  • 🇧🇩 Bangla
  • 🇵🇹 Portuguese
  • 🇮🇩 Indonesian
  • 🇯🇵 Japanese
  • 🇰🇪 Swahili
  • 🇩🇪 German
  • 🇰🇷 Korean
  • 🇮🇹 Italian
  • 🇳🇬 Yoruba
  • 🇲🇲 Burmese
KategorieEvaluierungFragenWiederholungenAntworttypBewertungWerkzeug
nutzung		Privat
Agenten𝜏³-Banking975Dual-Control-Agent-Benutzer-Simulation mit WissensabrufAuswertung des Backend-Datenbankstatus, pass@1✓✗
Harvey LAB-AA120 Aufgaben1Erstellung juristischer Arbeitsergebnisse durch Agenten mit DateiausgabeBewertung der Rasterkriterien durch einen einzelnen LLM-Juror, pass@1✓✓
APEX-Agents-AA452 Aufgaben3Erledigung von Aufgaben professioneller Dienstleistungen durch AgentenRubrikbasierte lokale Dateibewertung, pass@1✓✗
AA-AnalystAgent80 in 14 Bereichen5Python-Codeausführung durch Agenten mit frei formulierter EndantwortBinäre Korrektheitsbewertung durch einen LLM-Juror, gegebenenfalls durch numerische Vorprüfung überschrieben, pass^5✓✓
ITBench-AA59 Szenarien (öffentlich + privat)3Strukturierte JSON-Ursachendiagnose aus dem Offline-Vorfall-Snapshot KubernetesDurch LLM normalisierter Entitätsabgleich, durchschnittliche Präzision bei vollständigem Recall✓
EnterpriseOps-Gym-AA1.117 Aufgaben im Oracle-Modus (8 Bereiche)3Mehrfache MCP-Werkzeugaufrufe auf zurücksetzbaren Servern einer Unternehmens-TestumgebungErgebnisbasierte SQL-Statusprüfer, strenge pass@1-Erfolgsquote✓✗
Terminal-Bench-Science 0.170 (5 Bereiche)3Terminalbasierte AufgabenausführungTestsuite mit pass/fail, pass@1✗
AllgemeinIFBench2945FreitextantwortExtraktion und regelgesteuerte Bewertung, pass@1✗✗
MLCR-AA60 Fragen (Experten- und zusammengesetzte Stufen)3FreitextantwortPrüfung der Kürze und LLM-Jurorenpanel (Mehrheitsvotum von 3 Juroren über Vollständigkeit und Genauigkeit), pass@1✗
SonstigeGlobal-MMLU-Lite~ 6.000 (~ 400 pro Sprache)1Multiple Choice (4 Optionen)Regex-Extraktion, pass@1✗✗
MMMU Pro1,7301Multiple Choice (10 Optionen)Regex-Extraktion, pass@1✗✗

Grundsätze der Intelligenzevaluation

Unser Bewertungsansatz orientiert sich an vier Grundprinzipien:

  • Standardisiert: Alle Modelle werden unter identischen Bedingungen mit einheitlichen Aufforderungsstrategien, Temperatureinstellungen und Bewertungskriterien bewertet.
  • Unvoreingenommen: Wir verwenden Bewertungstechniken, die eine ungerechtfertigte Bestrafung von Modellen für Antworten vermeiden, die den Anweisungen in unseren Eingabeaufforderungen korrekt folgen. Dazu gehört die Verwendung klarer Eingabeaufforderungen, robuster Methoden zur Antwortextraktion und einer flexiblen Antwortvalidierung, um gültige Variationen in den Modellausgaben zu berücksichtigen.
  • Zero-Shot-Instruktionen: Wir evaluieren mit klaren Anweisungen ohne Beispiele oder Demonstrationen und prüfen damit, ob Modelle Anweisungen ohne Few-Shot-Lernen befolgen können. Dieser Ansatz passt zu modernen instruktionsoptimierten und dialogorientierten Modellen.
  • Transparent: Wir legen unsere Methodik offen, einschließlich Eingabeaufforderungsvorlagen, Bewertungskriterien und Einschränkungen.

Allgemeine Testparameter

Wir testen alle Auswertungen mit den folgenden Einstellungen:

  • Temperatur: 0 für nicht-begründende Modelle, 0,6 für begründende Modelle (es sei denn, das Modelllabor empfiehlt eine andere Temperatur)
  • Maximale Ausgabe-Tokens:
    • Nicht-begründende Modelle: 16.384 Token (nach unten angepasst, wenn Modelle ein kleineres Kontextfenster oder eine niedrigere maximale Ausgabe-Token-Obergrenze haben)
    • Reasoning-Modelle: Maximal zulässige Ausgabetokens, wie von den Modellerstellern angegeben (benutzerdefinierte Einstellung für jedes Reasoning-Modell)
  • Fehlerbehandlung:
    • Automatischer Wiederholungsversuch bei API-Fehlern (bis zu 30 Versuche)
    • Alle Fragen, bei denen alle 30 Wiederholungsversuche fehlgeschlagen sind, werden manuell überprüft. Ergebnisse, bei denen anhaltende API-Fehler Probleme verursacht haben, werden nicht veröffentlicht. Fehler, bei denen alle verfügbaren API für proprietäre Modelle eine bestimmte Frage blockieren, können zu niedrigeren Bewertungen führen (dieser Effekt ist nicht wesentlich).
  • Bewertungsmethodik: Wir verwenden im Allgemeinen die Bewertung pass@1 für unsere Auswertungen, wobei ein Modell beim ersten Versuch die richtige Antwort liefern muss. Bei Auswertungen mit mehreren Wiederholungen wird pass@1 durch die Aggregation der Ergebnisse über alle Wiederholungen hinweg berechnet. Dies wird wie folgt berechnet:
    Dabei ist pi = 1, wenn Versuch i korrekt ist, andernfalls 0, und k ist die Gesamtzahl der Testinstanzen über alle Wiederholungen hinweg.

Wir bewahren interne Kopien aller Bewertungsdatensätze auf. Die Quellen unserer ausgewählten Datensätze sind unten aufgeführt.

Für die Auswertungen des Artificial Analysis Intelligence Index verwenden wir die vom API-Anbieter jedes Modells gemeldeten Token-Zählungen, sofern verfügbar, um die Kosten für die Ausführung des Intelligence Index genau anzugeben. In den seltenen Fällen, in denen die Anzahl der Anbieter-Tokens nicht verfügbar ist, verwenden wir einen Canonical-Tokenizer-Fallback. Dies steht im Gegensatz zum Ansatz beim Leistungsbenchmarking, bei dem wir clientseitige Token-Zählungen vom o200k_base-Tokenizer verwenden, um die Token-Zählungen für denselben Text modellübergreifend zu standardisieren. Bei der Meldung von Cache-Trefferraten und -Kosten kombinieren wir diese Token-Zählungen mit Live-Messungen der typischen Cache-Trefferrate des Modells, anstatt uns auf die einmalige Messung bei der Ausführung der Bewertung zu verlassen.

Wir verwenden e2b als unseren primären Sandbox-Anbieter für Agenten-Benchmarks.

Evaluationen des Artificial Analysis Intelligence Index

Auswertungen, aus denen sich der aktuelle Artificial Analysis Intelligence Index zusammensetzt, gruppiert nach Fähigkeit.

Agenten

AA-Briefcase v1.1

  • Status: Im Artificial Analysis Intelligence Index v4.3.2 mit einer Gewichtung von 15 % enthalten.
  • Beschreibung: AA-Briefcase ist ein neuer Benchmark für das Testen von Modellen zu realistischen Wissensarbeitsaufgaben in komplexen Projekten, die von Branchenexperten erstellt wurden. Modelle werden in mehrwöchigen Wissensarbeitsprojekten evaluiert, jedes mit vielen verknüpften Aufgaben und Tausenden von Eingabequelldateien. AA-Briefcase kombiniert Rubriken- und paarweise Bewertung, um den überprüfbaren Aufgabenerfolg, die analytische Qualität und die Präsentationsqualität zu bewerten und so einen ganzheitlichen Überblick über die gesamte Agentenfähigkeit bei der Wissensarbeit zu geben.
  • Änderungen gegenüber AA-Briefcase v1: v1.1 ändert nur die Anpassung der Elo-Werte. Wir passen die Werte mit einem Crowd-BT-Modell an. Für einen Vergleich der Einreichungen und mit den angepassten Stärkeparametern und sowie der Annotatorenqualität gilt:
    Wir definieren und geben Folgendes:
    Dabei wird je Bewertungsbereich anhand früherer AA-Briefcase-Urteile angepasst. Die Rasterbewertung wird durch einen deterministischen Vergleich statt durch einen Juror entschieden; deshalb gilt für diesen Bereich . Die Elo-Werte verschieben sich, die Rangfolge bleibt jedoch weitgehend erhalten.
  • Beispieldatensatz: https://huggingface.co/datasets/ArtificialAnalysis/AA-Briefcase-Lite
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Implementierung:
    • Jedes AA-Briefcase-Szenario ist ein realistisches mehrwöchiges Geschäftsproblem, organisiert als mehrwöchiger Workflow, den der Agent nacheinander abarbeitet, mit 2–5 Aufgaben pro Woche. Obwohl Aufgaben innerhalb eines Szenarios über Wochen hinweg Dateien und Kontext gemeinsam nutzen, erledigen Modelle derzeit jede Aufgabe in einem unabhängigen Lauf, ohne ihre eigenen vorherigen Einreichungen zu übertragen. Der Agent erhält die Aufgabenbeschreibung und zugängliche Quelldateien und erstellt dann die endgültigen zu liefernden Dateien ohne Live-Interaktion oder iteratives Feedback während der Ausführung.
    • Szenario-Quellpools umfassen gemeinsam genutzte Dateien und wochenspezifische Dateien, wobei reale, erweiterte und synthetische Materialien gemischt werden. Quelldateien sind so konzipiert, dass sie realistische professionelle Artefakte wie Slack-Exporte, Tabellenkalkulationen, PDFs, Interviewtranskripte, Marktforschung, Standarddokumente, App-Store-Seiten, Board-Materialien, E-Mails und andere Geschäftsunterlagen enthalten. Spätere Aufgaben innerhalb einer Woche erhalten möglicherweise standardisierte Basisfalldateien (die gleichen Referenzarbeitsprodukte für jedes Modell), sodass jede Aufgabe unabhängig ausführbar bleibt und gleichzeitig die Kontinuität über die Woche hinweg gewahrt bleibt.
    • Modellübermittlungen werden mit Stirrup in einer einwöchigen E2B-Sandbox ausgeführt.
      • Runden: Agenten laufen bis zu 500 Runden pro Aufgabe.
      • Werkzeuge: Der Agent erhält ein einzelnes Code-Ausführungstool, das Shell-Befehle und Code in der Sandbox ausführt, sowie die unten aufgeführten Finishing-Tools (und ein Bildanzeigetool, wenn das Modell Vision unterstützt). Die Sandbox verfügt über keinen Internetzugang, sodass der Agent nur die bereitgestellten Quelldateien verwenden kann.
      • Sandbox: Jede Szenario-/Wochen-Sandbox wird aus den Quelldateien dieser Woche erstellt, wobei standardmäßige Python-Pakete und Systemtools für die Dokumentenverarbeitung und wissenschaftliche Berechnungen vorinstalliert sind.
      • Abschlusswerkzeuge: Ein finish-Werkzeug, mit dem der Agent eine Zusammenfassung und die absoluten Pfade seiner Ergebnisse einreicht (es wird geprüft, ob es sich um tatsächliche Dateien handelt, nicht um Verzeichnisse oder fehlende Pfade), sowie ein abandon_task_finish-Werkzeug zum Aufgeben, das er nur dann mit einer Begründung aufruft, wenn er die Aufgabe für tatsächlich unlösbar hält.
    • Prompts: Die Eingabeaufforderungen, die bei der Generierung und Benotung verwendet werden:
      • Systemprompt des Agenten:
        You are an AI agent working on a specific task within a multi-week simulated workplace scenario. Each task is part of a longer workflow; your job is to complete the current task using the tools provided in up to 500 steps, then submit your deliverables.

When you are done you must call the `finish` tool as your final step, passing a brief summary of what you accomplished and a list of absolute paths for every deliverable file.

If you have genuinely concluded that the task cannot be completed — for example because required inputs are missing, a hard dependency is unavailable, or the request itself is incoherent — call the `abandon_task_finish` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Record any clarifying assumptions you made in your finish summary.
      • Aufgabenprompt des Agenten:
        <execution_context>
## Sandbox

You operate inside an isolated Linux container through the `code_exec` tool, which runs shell commands and lets you read, create, and edit files. Commands run as the unprivileged user `user` (UID 1000), starting from `/home/user`. Passwordless `sudo` exists but is rarely needed, since your home directory is fully writable.

Every command runs independently: no working directory, environment variable, or other shell state carries over from one call to the next. Prefer absolute paths for both files and commands, and do not navigate with `cd` across calls — a `cd` in one command is gone by the next, so relying on it leaves you silently operating in the wrong place. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user/work && python build.py`).

## No network

The container has no outbound connectivity, and there is no proxy, allowlist, or flag that can turn it on — treat the environment as permanently offline. Anything that reaches for the internet will fail, including package installs (`pip`, `npm`, `apt`), remote `git` operations, and any HTTP/HTTPS client request from any language.

Identify a network block by its error signature rather than by guessing: failed name resolution (`Could not resolve host`, `Temporary failure in name resolution`), an unreachable route (`Network is unreachable`, a refused or timed-out connection to a public host), or a stalled TLS handshake. When you see these, the failure is structural — do not retry the same call and do not hunt for a workaround (mirrors, alternate hosts, cached copies). Re-plan using only what is already installed and what ships inside your workspace.

## Filesystem

- Writable: everything under `/home/user/` plus `/tmp`. Use these for deliverables, intermediate files, and caches.
- Read-only inputs:
- `/home/user/shared/` — reference material shared across the whole scenario
- `/home/user/week/` — documents specific to this week's tasks
Copy these into a working folder before transforming them rather than editing them in place.

## Runtime

A broad scientific-computing and document-processing stack is already installed, so confirm what is present before assuming a gap:
- Python 3.13 with the usual data stack (numpy, pandas, polars, scipy), plotting (matplotlib, plotly), the scikit-learn ML family, and document tooling (python-docx, python-pptx, openpyxl, PyMuPDF, pdfplumber, reportlab, weasyprint, Pillow, opencv), plus Playwright.
- System tools include LibreOffice, Pandoc, Tesseract, FFmpeg, ImageMagick, Ghostscript, TeX Live, OpenJDK, Chromium, jq, and git.
- Check availability with `pip show <pkg>` or `which <tool>` instead of installing — installs fail offline, but almost anything you would reach for is already here.
- matplotlib runs headless (`MPLBACKEND=Agg`): write figures to files; never call `plt.show()`.
- Commands are terminated after 20 minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Submitting your work

Finish by calling the `finish` tool — anything not submitted through it is not graded. Your call must include:
1. A short summary of what you accomplished.
2. Absolute paths to every deliverable (files only, not folders).

Save each deliverable directly in `/home/user` under the exact filename the task asks for — not in a subdirectory.

Save deliverables as ordinary, visible files. Do not leave the only copy of your work in a dot-prefixed file or directory (e.g. `.submission.txt`, `.outputs/report.md`), including inside an archive; a `.zip` is fine when the task explicitly asks for one. Assume your files will be opened and edited by others after submission, so write them to last.

If the task genuinely cannot be completed, call the `abandon_task_finish` tool with a brief reason instead. Use it only when you have concluded the work is impossible — not to escape a difficult task.
</execution_context>

<scenario_overview>
{scenario_overview}
</scenario_overview>

<week_overview>
{week_overview}
</week_overview>

<task_description>
{task}
</task_description>

<deliverables>
Submit these files, by exact name, saved directly in `/home/user`:
{expected_output_filenames}
</deliverables>

Please begin working on the task now.
      • Eingabeaufforderung zur Bewertung der binären Rubrik:
        You are grading a submitted deliverable against one binary rubric check.

The user message contains:
- the task instructions,
- the rubric item,
- the submitted artifact content.

Submitted artifacts may appear as text blocks, image blocks, or parser notes for unsupported content.

Use only evidence from the submitted artifact content. Do not infer facts from filenames, task instructions, or rubric text unless the submitted artifact content supports them.

Beyond the task instructions and rubric in the user message, you only ever receive the submitted artifact itself, never the external source files it cites. Do not fail an item merely because you cannot open or cross-check a cited source — judge citations on whether they are present, specific, and well-formed in the submission, not on whether the source's contents can be independently confirmed.

Return a strict binary judgment:
- passed=true only if the pass criteria are satisfied.
- passed=false if any required element is missing, materially wrong, unsupported, or not evidenced.

Write concise reasoning that cites submitted artifact evidence or the absence of evidence.
Do not award partial credit.
    • Jede Aufgabe wird anhand zweier Prüfarten bewertet. Rubrikprüfungen sind binäre Pass/Fail-Kriterien, die für eine einzelne Einreichung bewertet werden. Paarweise Prüfungen vergleichen zwei Einsendungen für dieselbe Aufgabe und geben eine bevorzugte Einsendung oder einen Gleichstand zurück. Es gibt zwei Arten: Analytische Qualität (deren Ausgabe eine tiefere, besser strukturierte Analyse bietet) und Präsentation (deren Ausgabe professioneller präsentiert wird).
    • Die Rasterbewertung sowie die paarweisen Vergleiche von analytischer Qualität und Präsentation verwenden jeweils ein Gremium aus drei Juroren statt eines einzelnen Jurors. Das reduziert die Bevorzugung von Einreichungen desselben Modells oder derselben Modellfamilie. Die Rasterbewertung nutzt Claude Opus 4.8 mit maximalem Effort, GPT-5.5 mit hohem Reasoning und Gemini 3.1 Pro Preview mit hohem Reasoning. Die paarweisen Vergleiche nutzen Claude Opus 5 mit hohem Effort, GPT-5.6 Sol mit mittlerem Reasoning und Gemini 3.8 Flash mit hohem Reasoning. Jedes Rasterurteil und jeder LLM-bewertete Paarvergleich wird von einem aus dem jeweiligen Gremium ausgewählten Juror entschieden. Die Auswahl ist über Prüfungen und Vergleiche hinweg ausgewogen. Für vergleichbare Ergebnisse bewertet stets derselbe Juror eine bestimmte Rasterprüfung. AA-Briefcase Elo ist die Hauptmetrik dieser Evaluierung: Sie kombiniert den Elo-Wert für analytische Qualität, den Elo-Wert für Präsentation und die Rasterbestehensquote. Die Rasterleistung wird über synthetische direkte Vergleiche mit einer Maximum-Likelihood-Elo-Aggregation in Elo umgerechnet. Jeder Bewertungsbereich wird mit einem Crowd-BT-Modell angepasst.
    • Integration in den Intelligence Index: Für die Aufnahme in den Intelligence Index wird der kombinierte Elo-Wert von AA-Briefcase v1.1 zum Zeitpunkt der Aufnahme eines Modells eingefroren und mit clamp((Elo - 500) / 2000) normalisiert. Dies ist dieselbe Abbildung wie bei GDPval-AA v2.1. Die Elo-Skala ist bei GPT-5.5 (medium) mit 1000 verankert, während der feste Normalisierungsbereich die Beiträge zum Intelligence Index über die Zeit stabil hält. Artificial Analysis kann die Referenzparameter mit zunehmender Modellleistung bei dieser Evaluierung aktualisieren, um eine aussagekräftige Differenzierung im Intelligence Index zu erhalten.

GDPval-AA v2.1

  • Beschreibung: GDPval-AA v2.1 ist das Bewertungsframework der Artificial Analysis für den GDPval-Datensatz von OpenAI. Es bewertet die Fähigkeiten von Sprachmodellen bei wirtschaftlich wertvollen Aufgaben und deckt 44 Berufe in Schlüsselsektoren ab, die zum BIP in den Vereinigten Staaten beitragen.
  • Änderungen gegenüber GDPval-AA v2: v2.1 ändert nur die Festlegung der Elo-Skala:
    • Wir verankern die Skala, indem wir DeepSeek V4.1 Flash (max) auf 1600 festlegen.
    • Wir passen die Werte mit einem Crowd-BT-Modell an. Für einen Vergleich der Einreichungen und mit den angepassten Stärkeparametern und sowie der Annotatorenqualität gilt:
      Wir definieren und geben Folgendes:
      Dabei wird anhand früherer GDPval-AA-Urteile angepasst.
    • Während sich die Elo-Wertungen verschieben, bleibt die Rangfolge weitgehend erhalten.
  • Paper: https://arxiv.org/abs/2510.04374
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Datensatz:
    • Wir stützen unsere Bewertung auf den öffentlichen Golddatensatz OpenAI GDPval von https://huggingface.co/datasets/openai/gdpval
    • Bei einigen Microsoft Office-Dateien im Datensatz fehlten Metadatenteile oder fehlerhafte Beziehungseinträge, die LibreOffice daran hinderten, sie zu öffnen. Wir haben die minimal fehlenden Metadaten hinzugefügt und die fehlerhaften Einträge korrigiert, um die Kompatibilität sicherzustellen. Dokumenttext, Folieninhalt und Layout wurden nicht geändert.
  • Implementierung: Diese Evaluierung umfasst zwei Phasen:
    • Aufgabenübermittlung – Modelle erhalten eine Aufgabe und müssen eine oder mehrere Dateien erstellen.
    • Paarweise Bewertung – Ein Juror, der aus einer Gruppe von drei Juroren der Grenzregion LLM besteht, bewertet blind zwei Einreichungen für dieselbe Aufgabe, die jeweils von einem anderen Modell erstellt wurden.
    • Elo-Berechnung: Nachdem wir paarweise Rankings gesammelt haben, passen wir sie über die Maximum-Likelihood-Schätzung an ein Crowd-BT-Modell an und berechnen mithilfe des Sandwich-Schätzers Konfidenzintervalle, um unsere endgültige Elo-Metrik zu ermitteln. Wir verankern die Elo-Skala, indem wir DeepSeek V4.1 Flash (max) auf 1600 festlegen. Jede andere Bewertung wird relativ zu diesem Anker angepasst.
    • Integration in den Intelligence Index: Für die Aufnahme in den Intelligence Index wird der Elo-Wert von GDPval-AA v2.1 zum Zeitpunkt der Aufnahme eines Modells eingefroren und mit clamp((Elo - 500) / 2000) normalisiert. Die Elo-Skala ist bei DeepSeek V4.1 Flash (max) mit 1600 verankert, während der feste Normalisierungsbereich die Beiträge zum Intelligence Index über die Zeit stabil hält. Artificial Analysis kann die Referenzparameter mit zunehmender Modellleistung bei dieser Evaluierung aktualisieren, um eine aussagekräftige Differenzierung im Intelligence Index zu erhalten.
  • Details zur Aufgabenübermittlung:
    • Alle Modelle werden mit unserem Open-Source-Agenten-Harness Stirrup ausgeführt. Innerhalb des Harness erhalten Modelle eine Codeausführungsumgebung (E2B Sandbox) und die folgenden sechs Tools, die sie nach eigenem Ermessen aufrufen können:
      • Web Fetch – Ruft den Hauptinhalt einer Webseite ab und extrahiert ihn als markdown.
      • Websuche – Durchsucht das Web mithilfe der Brave Search API; gibt die Top-5-Ergebnisse mit Titel, URL und Beschreibung zurück.
      • Bild anzeigen – Liest Bilddateien (.png,.jpg,.jpeg) aus der Sandbox und zeigt sie als native Bild-Tokens für die LLM-Nutzung an. Dieses Tool ist nur für Modelle mit Sehunterstützung verfügbar. Bilder werden auf maximal 1 Megapixel herunterskaliert, bevor sie an das Modell gesendet werden.
      • Code Exec – Führt Bash-Befehle in der Sandbox über das Tool code_exec aus; gibt Exit-Code, stdout und stderr zurück.
      • Fertig stellen – Signalisiert den Abschluss der Aufgabe und gibt an, welche Dateien übermittelt werden sollen.
      • Aufgabe abbrechen – Signalisiert mit einem kurzen Grund, dass das Modell nicht glaubt, dass es die Aufgabe abschließen kann, anstatt Dateien einzureichen.
    • Für jede Aufgabe wird eine neue E2B-Sandbox mit den mit der jeweiligen Aufgabe verknüpften Referenzdateien initialisiert und mit einer Reihe relevanter Pakete für den Aufgabensatz vorinstalliert. Wir basierten die Paketsammlung auf der offengelegten Umgebung aus dem ursprünglichen GDPval-Papier, erweitert in Version 2 um zusätzliche Abhängigkeiten (einschließlich einer vollständigen TeX Live LaTeX-Toolchain und Build-Tools).

      Systempakete sind die vollständig versionsfixierte transitive Abhängigkeiten, die innerhalb des Debian trixie-Basisimages aufgelöst wird, daher sind die meisten Einträge Abhängigkeiten der Pakete, die wir direkt installieren

    • Wir fordern den Agenten mit einer Anweisung auf, die die relevante Aufgabenaufforderung, Referenzdateien und Details zum Finish-Tool interpoliert.
  • Ausführungslimits:
    • Der LLM hat 250 Runden Zeit, um die Aufgabe abzuschließen. Eine einzelne Runde wird als Assistentennachricht und deren Werkzeugaufrufe (sofern vorhanden) definiert. Wenn sich das Modell dem Limit nähert, wird ihm das verbleibende Turnbudget mitgeteilt.
    • Das Modell kann den Lauf über das Tool „Aufgabe abbrechen“ vorzeitig beenden, wenn es glaubt, die Aufgabe nicht abschließen zu können, und einen kurzen Grund angeben, anstatt Dateien einzureichen.
    • Wenn das Modell nach Abschluss einer bestimmten Runde 70 % seines Kontextfensters überschreitet, fordert der Agent es auf, den Aufgabenstatus, die abgeschlossene Arbeit, die aktuellen Dateien, die verbleibenden Schritte und den wichtigen Kontext zusammenzufassen.

Eingabeaufforderung des Aufgabenübermittlungssystems:

You are an AI agent completing a standalone professional task. Your job is to use the provided tools to produce the requested deliverables within 250 steps, then submit your work.

When you are done, call the `finish` tool as your final step with:
1. A brief summary of what you accomplished.
2. Absolute paths to every deliverable file.

If you have genuinely concluded that the task cannot be completed because required inputs are missing, a hard dependency is unavailable, or the request is incoherent, call the `abandon_task_finish` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Make reasonable assumptions when needed and record them in your finish summary.

Eingabeaufforderung zur Aufgabenübermittlung:

## Runtime

You are running in an isolated Linux sandbox. Use the `code_exec` tool to read, create, and modify files. Commands run as the non-root user `user` (UID 1000). Default working directory is `/home/user`.

Every command runs independently: no working directory, environment variable, or other shell state carries over from one call to the next. Prefer absolute paths for both files and commands, and do not navigate with `cd` across calls — a `cd` in one command is gone by the next, so relying on it leaves you silently operating in the wrong place. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user/work && python build.py`).

A broad scientific-computing and document-processing stack is already installed, so confirm what is present before assuming a gap:
- Python 3.13 with the usual data stack (numpy, pandas, polars, scipy), plotting (matplotlib, plotly), the scikit-learn ML family, and document tooling (python-docx, python-pptx, openpyxl, PyMuPDF, pdfplumber, reportlab, weasyprint, Pillow, opencv), plus Playwright.
- System tools include LibreOffice, Pandoc, Tesseract, FFmpeg, ImageMagick, Ghostscript, TeX Live, OpenJDK, Chromium, jq, and git.
- Commands are terminated after 10 minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Reference Files Location

(This section appears only when the task includes reference files.)

The reference files for the task are available in your environment's file system.

Here are their paths:

- [absolute path to each reference file]

## Completing Your Work

In order to complete the task you must use the `finish` tool to submit your work. If you do not use the `finish` tool you will fail this task!

As a last resort if you really cannot make any meaningful progress, use `abandon_task_finish` with a brief reason instead of submitting files.

**Required in your finish call:**
1. A brief summary of what you accomplished
2. A list of **ABSOLUTE file paths** for the required output files (Do not submit folders).

## Task

Here is the task you need to complete:

[task description]

Please begin working on the task now.
  • Kontextüberlauf: Wenn der nächste Modellaufruf (oder die Zusammenfassungsanforderung selbst) das Kontextfenster überschreitet, wickelt der Agent frühere Runden ab, bis die Zusammenfassung erfolgreich ist.
  • Aufgabenabschluss: Um die Aufgabe abzuschließen, muss der LLM das Finish-Tool aufrufen und eine Zusammenfassung der geleisteten Arbeit sowie die Pfade der Dateien bereitstellen, die übermittelt werden sollen. Dieses Werkzeug kann jederzeit verwendet werden.
  • Bewertung: Wir prüfen paarweise Übereinstimmungen zwischen Modelleinsendungen in zwei Phasen:
    • Ausgewogene Stichprobe: Wir beproben zunächst jedes Modell unterschiedlich und gleichen die Sichtbarkeit auf Aufgaben, Juroren und Gegner aus, um erste Bewertungen zu ermitteln.
    • Aktives Sampling: Nach der Anfangsphase wechseln wir zum Elo-informierten Sampling, das Paarungen zwischen Modellen mit ähnlichen Bewertungen priorisiert, um die meisten Informationen pro Vergleich abzuleiten. Wir sorgen während des gesamten Prozesses für eine ausgewogene Darstellung der Aufgaben innerhalb jedes Modells.
    • Einreichungen werden nach dem Zufallsprinzip als Einreichung A und B anonymisiert, um etwaige Modell- oder Positionsverzerrungen durch das Bewertermodell abzumildern.
    • Die Übereinstimmungen werden von einem Gremium aus drei Grenz-LLM-Juroren führender Labore bewertet, die jeweils mit ihren Standard-Begründungseinstellungen durchgeführt werden: GPT-5.6 Sol (medium reasoning), Gemini 3.8 Flash (high reasoning) und Claude Opus 5 (high effort). Für jeden Vergleich nehmen wir Stichproben zwischen den Juroren vor. Die ursprüngliche Aufgabe, alle Referenzdateien und alle Einreichungsdateien werden analysiert und dem Richter als Kontext bereitgestellt.
    • Dokumentbasierte Dateien (.pdf,.docx,.pptx,.xlsx usw.) werden sowohl als Text als auch als Bilder analysiert. Wir extrahieren ZIP-Dateien und analysieren jede einzelne Datei separat. Bei Aufgaben, die Audio- oder Videodateien enthalten, wird der Vergleich an Gemini 3.8 Flash weitergeleitet, das diese Modalitäten nativ verarbeitet. Dieser Kontext ist in eine Bewertungsaufforderung eingebettet, die den Juror auffordert, zu bestimmen, welcher der Beiträge A und B besser auf die Aufgabe reagiert.
    • Endgültige Bewertung: Unsere endgültige Elo-Bewertung ist eine Bradley-Terry-Bewertung, die mithilfe der Maximum-Likelihood-Schätzung aus allen paarweisen Vergleichen (Unentschieden werden als halbe Siege für jede Seite gezählt) berechnet wird und auf DeepSeek V4.1 Flash (max) bei 1600 basiert. Die 95 %-Konfidenzintervalle werden mithilfe des Sandwich-Schätzers berechnet, um die Bewertungsunsicherheit zu quantifizieren.

AutomationBench-AA

  • Beschreibung: AutomationBench-AA ist die Ausführung von Artificial Analysis von Zapiers AutomationBench. Es testet, ob Modelle realistische SaaS-Workflows ausführen können, die mehrere simulierte Geschäftsanwendungen umfassen, wobei REST APIs als Tool-Schnittstelle verwendet werden.
  • Paper: https://arxiv.org/abs/2604.18934
  • Bestenliste: https://zapier.com/benchmarks
  • Repository: https://github.com/zapier/AutomationBench
  • Datensatz:
    • Wir werten eine zurückgehaltene private Aufteilung mit 657 Aufgaben aus dem AutomationBench-Datensatz Version 1.0.6 aus
    • Die Aufgaben umfassen sechs Geschäftsbereiche: Finanzen, HR, Marketing, Betrieb, Vertrieb und Support
    • Sie laufen in simulierten App-Umgebungen, die Produkte wie Gmail, Google Sheets, Slack, Salesforce, Zendesk, Jira und HubSpot umfassen
  • Implementierung:
    • Wir führen jede Aufgabe einmal in der AutomationBench-Multiturn-Umgebung aus, mit einer Obergrenze von 50 Turns. Modelle verwenden das API-Toolset und ermitteln und rufen die benötigten REST-Endpunkte über strukturierte Toolaufrufe auf
    • Wir klassifizieren jede AutomationBench-Behauptung entweder als Ziel, das vom Agenten wahr gemacht werden muss, oder als Leitplanke, die zunächst bestanden wird und vom Agenten nicht durchbrochen werden darf
    • Ziele und Leitplanken werden mithilfe programmatischer Überprüfungen des endgültigen Umgebungszustands bewertet. AutomationBench-AA verwendet keinen separaten LLM-Richter für die Bewertung
    • Für den Headline-Score erhält eine Aufgabe 0, wenn das Modell gegen eine Leitplanke verstößt. Wenn keine Leitplanken verletzt werden, erhält die Aufgabe den Prozentsatz der Ziele, die das Modell erreicht hat. Fehlerhafte Aufgaben werden ebenfalls mit 0 bewertet
    • Jede Aufgabe gehört zu einer Geschäftsdomäne, daher sind Domänenaufschlüsselungen sich gegenseitig ausschließende Teilmengen des Aufgabensatzes. App-Aufschlüsselungen schließen sich nicht gegenseitig aus: Eine Aufgabe kann mehrere Apps umfassen, daher können ihre Ziel- und Leitplankenzusicherungen zu mehr als einer App beitragen

Programmierung

Terminal-Bench 4.0

  • Beschreibung: Die 4.0-Version von Terminal-Bench, entwickelt von Forschern der Stanford University, dem Laude Institute und der Open-Source-Community. Umfasst Softwareentwicklung, Systemadministration, Datenverarbeitung, Modellschulung und Sicherheit, wobei jede Aufgabe durch eine eigene Verifizierungssuite bewertet wird.
  • Bestenliste: https://www.tbench.ai/?version=4
  • Datensatz: https://github.com/harbor-framework/terminal-bench
  • Implementierung:
    • Wir werten den gesamten Terminal-Bench 4.0-Datensatz (66 Aufgaben) mit dem mini-swe-agent-Harness aus, wobei die pass@1-Bewertung über 3 Wiederholungen pro Aufgabe gemittelt wird
    • Für jede Aufgabe gibt es einen eigenen Testsatz. Wir folgen der Terminal-Bench-Methodik: Eine Aufgabe wird nur dann bestanden, wenn alle Tests bestanden werden. Die Bewertung wird im eigenen Prüfcontainer jeder Aufgabe ausgeführt, der von der Umgebung des Agenten isoliert ist, und ein Prüfer, der sein Zeitlimit überschreitet, gilt als Fehler
    • Wir wenden die folgenden Einschränkungen auf Bewertungen für den Agenten an:
      • Die maximale Anzahl an Agentenschritten ist auf 500 begrenzt
      • Task-Timeouts und Sandbox-Ressourcen folgen den Upstream-Taskdefinitionen
    • Die gesamte andere Agentenkonfiguration folgt den Standardeinstellungen für mini-swe-agent, einschließlich der interaktiven Minikonfiguration und Eingabeaufforderungen, des nativen Bash-Tools und ohne Kontextkomprimierung oder -zusammenfassung: Der Agent sieht immer sein vollständiges Transkript

SciCode

  • Beschreibung: Python-Programmierung zur Lösung wissenschaftlicher Rechenaufgaben.
  • Paper: https://arxiv.org/abs/2407.13168
  • Datensatz: https://scicode-bench.github.io/
  • Implementierung:
    • Wir testen mit von Wissenschaftlern kommentierten Hintergrundinformationen, die in der Eingabeaufforderung enthalten sind
    • Wir berichten über die Bewertung auf Unterproblemebene
    • Pass@1-Bewertungskriterien
    • SciCode-Schrittskripts werden auf isolierten Executoren mit einem Ausführungszeitlimit von 300 Sekunden bewertet (Datensatz v1.0.1).

Allgemein

AA-Omniscience

  • Beschreibung: AA-Omniscience ist ein Wissens- und Halluzinations-Benchmark, der die sachliche Zuverlässigkeit misst, präzises Wissen belohnt und falsche Vermutungen oder Halluzinationen bestraft. Es bietet eine detaillierte Bewertung der Fähigkeit eines Modells, Bekanntes von Unbekanntem in verschiedenen Wissensbereichen zu unterscheiden.
  • Paper: https://arxiv.org/abs/2511.13029
  • Datensatz: https://huggingface.co/datasets/ArtificialAnalysis/AA-Omniscience-Public
  • Implementierung:
    • Der Benchmark besteht aus 6.000 Fragen zu 42 Themen, darunter Wirtschaft, Geistes- und Sozialwissenschaften, Gesundheit, Recht, Softwaretechnik und Naturwissenschaften, Ingenieurwesen und Mathematik.
    • Modelle werden anhand des AA-Omniscience Index bewertet, der Punkte für richtige Antworten vergibt, Punkte für halluzinierte Antworten abzieht und Enthaltungen neutral hält und Enthaltungen gegenüber falschen Vermutungen belohnt
    • Jede Antwort wird basierend auf der Bewertung entweder als CORRECT, INCORRECT, PARTIAL_ANSWER oder NOT_ATTEMPTED bewertet Modellantwort und die Ground-Truth-Antwort. Als Bewertungsmodell wird GPT-5.6 Luna (medium) verwendet
    • Integration in den Intelligence Index: AA-Omniscience trägt zwei Komponenten zum Intelligence Index bei: (1) Genauigkeit – der Anteil richtiger Antworten, gewichtet mit 10 % des Gesamtindex, und (2) Nicht-Halluzinationsrate – berechnet als 1 minus der Halluzinationsrate, gewichtet mit 5 % des Gesamtindex (AA-Omnisciences 15 %-Anteil).

GDP.pdf

  • Beschreibung: Die Implementierung von GDP.pdf von Surge AI durch Artificial Analysis. Der Benchmark prüft, ob Modelle über lange, reale berufliche Dokumente schlussfolgern und aufgabenspezifische Kriterien erfüllen können.
  • Paper: https://arxiv.org/abs/2607.11192
  • Datensatz: surgeai/GDP.pdf
  • Evaluierungsdatensatz: 100 Aufgaben in zehn Berufsbereichen, basierend auf 4.592 PDF-Seiten und anhand von 1.275 Kriterien bewertet. Wir versuchen jede Aufgabe fünfmal, sodass jedes Modell einen festen Nenner von 500 Versuchen hat.
  • Dokumentenvorbereitung und -lieferung: Wir bereiten jedes Quell-PDF mit LiteParse 2.5.0 vor, mit aktivierter englischer OCR. Jedes Modell erhält den kompletten extrahierten Text jeder Seite. Wenn der Endpunkt dies unterstützt, senden wir zuerst Seitenbilder in der Reihenfolge der Seiten, gefolgt von der Aufgabe und dem vollständigen extrahierten Text in einer einzigen Benutzernachricht. Modelle ohne Bildeingabe erhalten nur Text. Wir rendern Seitenbilder mit 150 DPI und reduzieren sie auf mindestens 72 DPI, wenn der Modellkontext oder die Nutzlastbeschränkungen des Anbieters dies erfordern. Wir können auch undurchsichtige Seiten von PNG in JPEG konvertieren. Wenn ein Endpunkt begrenzt, wie viele Bilder eine Anfrage übertragen darf, kombinieren wir Seiten zu zusammengesetzten Bildern, zwei Seiten pro Bild zuerst und bis zu vier, wenn die Obergrenze enger ist, wobei jede Zelle mit ihrer Seitenzahl beschriftet ist. Über vier Seiten pro Bild hinaus decken die Bilder nur die ersten Seiten ab; Die restlichen Seiten verbleiben im extrahierten Text. Wenn beides zutrifft, teilt die Eingabeaufforderung dem Modell mit, dass es sich bei den Seitenbildern um zusammengesetzte Bilder handelt, und gibt die Seitenzahl an, bei der die Bildabdeckung endet. Wenn die Bilder nach der Anpassung nicht in den Kontext oder die Größenbeschränkungen der Anfrage passen, senden wir nur den gesamten extrahierten Text. Wir kürzen oder fassen den extrahierten Text nicht zusammen. Modelle antworten in einer einzigen Runde, ohne Browsing oder Werkzeuge.

    Im Gegensatz zur Surge AI-Implementierung verwenden wir keine API-Dokumenteingabefunktionen. Diese sind für den Benutzer undurchsichtig und befinden sich über der Modellebene, sodass sie Variationen von API-Produktentscheidungen und Hosts einführen können, anstatt Modelle einzeln zu vergleichen.

  • Bewertung: GPT-5.6 Luna Medium beurteilt jedes Kriterium unabhängig. Jeder Anruf erhält die Aufgabenaufforderung, die Antwort des Teilnehmers und ein Kriterium, jedoch nicht das Quell-PDF oder die Identität des Teilnehmers. Wir akzeptieren eine Aufgabenbewertung nur, wenn für jedes Kriterium ein Urteil vorliegt. Wir bewerten Fehler, fehlende Versuche und fehlerhafte Terminaleingaben mit Null.
  • Gemeldete Messwerte:
    • All-pass ist die Hauptmetrik: der Anteil aller 500 Versuche, bei denen jedes Kriterium bestanden wurde.
    • Mean Pass ist die sekundäre Metrik: Wir berechnen die Kriteriums-Erfolgsquote jedes Versuchs und mitteln sie dann mit gleicher Gewichtung über Aufgaben und Wiederholungen.
    • Bei Domänenschnitten wird die gleiche Task-Makro-Berechnung Mean Pass verwendet. Wir melden keine Domäne All-pass.
  • Kosten- und Geschwindigkeitsbereich: Die veröffentlichten Kosten decken nur Anrufe von Teilnehmermodellen ab und schließen Richteranrufe, PDF-Vorbereitung und OCR aus. Wir schätzen die Zeit pro Aufgabe anhand der Ausgabe-Token-Nutzung und der Modellausgabegeschwindigkeit. Es schließt Richteranrufe, PDF-Vorbereitung und OCR aus, es handelt sich also nicht um einen durchgängigen Bewertungszeitplan.

Unterschiede zur Surge AI-Implementierung

Artificial AnalysisSurge AI
DokumenteneingabeMit LiteParse und OCR extrahierter Text sowie Seitenbilder für bildfähige ModelleRohes PDF, das an den Dokumenteingang des Anbieters gesendet wird
BewertungsmodellGPT-5.6 Luna MediumGemini 3.5 Flash

Der Aufgabensatz ist geteilt, aber die Dokumenteingabe und die Beurteilung unterscheiden sich, sodass die Artificial Analysis- und Surge-Scores nicht direkt vergleichbar sind.

AA-LCR v1.1

  • Beschreibung: Bewerten Sie die Leistung langer Kontexte, indem Sie Argumentationsfunktionen in mehreren langen Dokumenten testen (~100.000 Token, gemessen mit dem cl100k_base-Tokenizer).
  • Änderungen gegenüber AA-LCR: Fügt eine Systemaufforderung zur Verdeutlichung der Bewertungsanweisungen hinzu, korrigiert 16 Antwortschlüssel und benotet mit GPT-5.6 Luna (medium). Die Ergebnisse sind nicht direkt mit v1.0 vergleichbar.
  • Datensatz: https://huggingface.co/datasets/ArtificialAnalysis/AA-LCR
  • Implementierung:
    • 100 harte, textbasierte Fragen aus 7 Dokumentenkategorien (Unternehmensberichte, Branchenberichte, Regierungskonsultationen, Wissenschaft, Recht, Marketingmaterialien und Umfrageberichte)
    • Etwa 100.000 Token (gemessen mit dem cl100k_base-Tokenizer) an Eingaben pro Frage, sodass Modelle ein Kontextfenster von mindestens 128.000 unterstützen müssen, um bei diesem Benchmark zu punkten. Insgesamt ca. 3 Millionen eindeutige Eingabe-Tokens, die sich über ca. 230 Dokumente erstrecken, um den Benchmark auszuführen (Ausgabe-Tokens variieren normalerweise je nach Modell).
    • Modellantworten werden mit GPT-5.6 Luna (medium) als Gleichheitsprüfer mit der Bewertung pass@1 ausgewertet

Wissenschaftliches Schlussfolgern

HLE (Humanity's Last Exam)

  • Beschreibung: Aktueller bahnbrechender akademischer Benchmark des Centre for AI Safety (unter der Leitung von Dan Hendrycks).
  • Paper: https://arxiv.org/abs/2501.14249v2
  • Datensatz: https://huggingface.co/datasets/cais/hle
  • Implementierung:
    • 2,158 Nur-Text-Fragen in den Bereichen Mathematik, Geisteswissenschaften und Naturwissenschaften (aus der Überarbeitung vom Mai 2025, die insgesamt 2.500 Fragen enthält – wir verwenden die Nur-Text-Teilmenge für maximale Vergleichbarkeit zwischen den Modellen)
    • Wir stellen fest, dass die HLE-Autoren offenlegen, dass ihr Datensatz-Kuratierungsprozess eine kontroverse Auswahl von Fragen basierend auf Tests mit GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet, o1, o1-mini und o1-preview (letztere beiden nur für reine Textfragen). Wir raten daher vom direkten Vergleich dieser Modelle mit Modellen ab, die nicht im HLE-Kurationsprozess verwendet wurden, da der Datensatz möglicherweise gegenüber den im Kurationsprozess verwendeten Modellen verzerrt ist.
    • Bewertet mit einer Gleichheitsprüfer-LLM-Eingabeaufforderung, die an das ursprüngliche HLE-Papier angepasst wurde, unter Verwendung von GPT-5.6 Luna (medium) und mit einer pass@1-Bewertung (Eingabeaufforderung finden Sie unten).

CritPt

  • Beschreibung: Benchmark für physikalisches Denken auf Forschungsniveau mit unveröffentlichten Grenzproblemen der Physik, die ein breites Spektrum von Teilgebieten abdecken.
  • Paper: https://arxiv.org/abs/2509.26574
  • Website: https://critpt.com/
  • Repository: https://github.com/CritPt-Benchmark/CritPt
  • Datensatz: https://huggingface.co/datasets/CritPt-Benchmark/CritPt
  • Implementierung:
    • In Zusammenarbeit mit dem CritPt-Team implementieren wir die Komponenten auf „Challenge“-Ebene für alle 70 Testsatz-Challenges (die Beispiel-Challenge ist ausgenommen).
    • Wir führen 5 Wiederholungen für jede Frage mit der Bewertung pass@1 durch
    • Die Modelle werden mit einem zweistufigen Parsing-Ansatz aufgerufen, bei dem im ersten Schritt das Modell aufgefordert wird, die Herausforderung mit Begründung abzuschließen, und im zweiten Schritt die Antwort in das erwartete Codeformat zur Bewertung formatiert wird (siehe Beispielaufforderung für das Parsing auf der Bewertungsseite CritPt).
    • Token-Nutzung und Kostenschätzungen spiegeln beide Schritte wider (Begründung und Antwortanalyse).
    • Zu den Antwortformaten gehören numerische Werte, symbolische Ausdrücke in SymPy und Python-Funktionen (ausgewertet mit Testfällen).
    • Der offizielle CritPt-Bewertungsserver wird verwendet, um alle Herausforderungsantworten auf ihre Richtigkeit hin zu bewerten. Der Grading-API-Zugriff wird von Fall zu Fall zugelassenen Laboren und Forschern gewährt. Senden Sie eine E-Mail an critpt@artificialanalysis.ai, um ihn anzufordern, und sehen Sie sich die Artificial Analysis API-Dokumentation an

Details zu zusätzlichen Evaluationen

Agenten

Harvey LAB-AA

  • Beschreibung: Harvey LAB-AA ist die Implementierung des Legal Agent Benchmark (LAB) von Harvey durch Artificial Analysis. Sie nutzt Harveys Datensatz mit 120 privaten Aufgaben aus 24 juristischen Praxisbereichen. Für jede Aufgabe liest der Agent die Fallunterlagen in einer Sandbox und erstellt juristische Arbeitsergebnisse: Memoranden, Offenlegungspläne, Zusammenfassungen von Zeugenaussagen, Dokumente mit markierten Änderungen und ähnliche Unterlagen. Ein einzelner LLM-Juror bewertet die Ergebnisse Kriterium für Kriterium anhand eines aufgabenspezifischen Rasters mit einzelnen binären Bestehens- oder Nichtbestehenskriterien. Das vermittelt ein Gesamtbild der agentischen Fähigkeit bei realer juristischer Arbeit.
  • Beispieldatensatz: Die fünf im Explorer angezeigten öffentlichen Beispielaufgaben stammen aus Harveys öffentlichen Beispielen unter https://github.com/harveyai/harvey-labs. Die Schlagzeilen basieren auf Harveys privatem Datensatz mit 120 Aufgaben, der nicht öffentlich veröffentlicht wird.
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Implementierung:
    • Bei jeder Aufgabe handelt es sich um einen eigenständigen juristischen Arbeitsauftrag in einem von 24 Rechtsgebieten. Der Agent erhält die Aufgabenanweisungen, einen Satz schreibgeschützter Eingabedokumente und die genauen Dateinamen der zu erstellenden Ergebnisse und arbeitet dann die Aufgabe in einem einzigen Durchgang ab, ohne Live-Interaktion oder iteratives Feedback während der Ausführung.
    • Eingabedokumente sind die Fallmaterialien der Aufgabe – Verträge, Vereinbarungen, Memos, Transkripte und andere Rechtsunterlagen – die schreibgeschützt in der Sandbox bereitgestellt werden. Der Agent kopiert sie in einen Arbeitsordner, liest sie mit den in der Sandbox verfügbaren Dokumentenverarbeitungstools und schreibt seine Ergebnisse (normalerweise.docx,.xlsx oder.md) direkt in sein Home-Verzeichnis unter den genauen Dateinamen, die die Aufgabe angibt.
    • Alle Modelle werden mit unserem Open-Source-Agenten-Harness Stirrup ausgeführt.
      • Runden: Agenten laufen bis zu 200 Runden pro Aufgabe.
      • Werkzeuge: Innerhalb des Harness erhalten Modelle eine Sandbox-Codeausführungsumgebung, und visionsfähige Modelle erhalten zusätzlich ein Bildbetrachter-Tool, das Bilddateien aus der Sandbox als native Bildtokens für das Modell liest. Da die Sandbox keinen Internetzugang hat, kann der Agent nur die bereitgestellten Eingabedokumente und die im Image vorinstallierte Software nutzen.
      • Sandbox: Jede Aufgabe läuft in einer isolierten Linux-Sandbox auf Basis eines gemeinsamen agent-evals-Basisimages (Debian + Python 3.13). Werkzeuge zur Dokumentverarbeitung wie Pandoc, poppler/pdftotext, LibreOffice, python-docx, python-pptx, openpyxl, pdfplumber, PyMuPDF und markitdown sind vorinstalliert. Die Eingabedokumente der Aufgabe werden zur Laufzeit schreibgeschützt bereitgestellt; einzelne Shell-Befehle werden nach 20 Minuten beendet.
      • Abschlusswerkzeuge: Ein finish-Werkzeug, mit dem der Agent eine Zusammenfassung und die absoluten Pfade seiner Ergebnisse einreicht (es wird geprüft, ob es sich um tatsächliche Dateien handelt, nicht um Verzeichnisse oder fehlende Pfade), sowie ein abandon_task_finish-Werkzeug zum Aufgeben, das er nur dann mit einer Begründung aufruft, wenn er die Aufgabe für tatsächlich unlösbar hält.
    • Unterschiede zum Harvey-Benchmark: Harvey LAB-AA ist die unabhängige Neuimplementierung von Artificial Analysis, daher sind unsere Zahlen nicht direkt mit Harveys eigenen veröffentlichten Ergebnissen vergleichbar. Die Hauptunterschiede:
      • Die Übermittlungen müssen genau mit dem Dateinamen übereinstimmen, der in den Aufgabenanweisungen angegeben ist. Ein Beinahe-Unfall-Dateiname gilt als nicht erzeugt, was strenger ist als Harveys Best-Effort-Matching und unsere Punktzahlen im Vergleich zu ihren senken kann.
      • Ein Kriterium scheitert völlig, ohne dass es dem Richter angezeigt wird, und zwar nur dann, wenn keine seiner Ergebnisse vorgelegt wurde. Eine teilweise Einreichung – bei der einige der für das Kriterium deklarierten Dateien vorhanden sind – wird dennoch beurteilt, wobei alle fehlenden Dateien als „abwesend“ markiert werden.
      • Als Bewertungsmodell kommt Gemini 3.1 Pro zum Einsatz.
      • Wir laufen auf den nativen Shell-Tools von Stirrup in einer E2B-Sandbox mit von Artificial Analysis erstellten Agenten- und Beurteilungsaufforderungen und nicht auf Harveys Sandbox und benutzerdefinierten Tools.
      • Die ursprüngliche Implementierung von Harvey stattet den Agenten mit benutzerdefinierten Tools und Fähigkeitsskripten zur Dokumentgenerierung aus (z. B. zum Erstellen von .docx-, .xlsx- und .pptx-Dateien). Wir stellen diese nicht zur Verfügung, daher erzeugen die Agenten die Dateien mit den allgemeinen Werkzeugen in der Sandbox.
    • Jede Aufgabe verfügt über eine Rubrik gleichgewichteter, atomarer, binärer Pass/Fail-Kriterien. Jedes Kriterium wird anhand des Textes bewertet, der aus den deklarierten zu liefernden Dateien des Kriteriums extrahiert wurde. Die Bewertung erfolgt rein textuell: Der Juror sieht den extrahierten Text der zu erbringenden Leistungen, die Aufgabenbeschreibung und die Übereinstimmungskriterien des Kriteriums und gibt ein striktes „Bestanden“ oder „Nicht bestanden“ ohne teilweise Anrechnung zurück.
    • Es werden zwei Hauptmetriken gemeldet: Erfolgsquote des Kriteriums, der Anteil der atomaren Bestehens-/Nichtbestehenskriterien, die die Ergebnisse erfüllen (Mittelwert über den Kriterien), und Erfolgsquote aller Kriterien, der Anteil der Aufgaben, bei denen jedes Kriterium ohne teilweise Punkte bestanden wird. Die Erfolgsquote des Kriteriums ist die Standardmetrik, die auf der gesamten Website angezeigt wird.
    • Prompts: Die Eingabeaufforderungen, die bei der Generierung und Benotung verwendet werden:
      • Systemprompt des Agenten:
        You are an AI agent completing a professional legal-work task. Use the tools provided to read the input documents, produce the requested deliverable files, and submit them within {max_turns} steps.

When you are done you must call the `{finish_tool_name}` tool as your final step, passing a brief summary of what you accomplished and a list of absolute paths for every deliverable file.

If you have genuinely concluded that the task cannot be completed - for example because required inputs are missing or a hard dependency is unavailable - call the `{abandon_task_finish}` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Make reasonable assumptions when needed and record them in your finish summary.
      • Aufgabenprompt des Agenten:
        <execution_context>
## Sandbox

You operate inside an isolated Linux sandbox through the `code_exec` tool, which runs shell commands and lets you read, create, and edit files. Commands run as the unprivileged user `user` (UID 1000).

Files you write persist on disk across calls, but **shell state does not**: each command runs in a fresh shell, so no working directory, environment variable, or other shell state carries from one call to the next. Always use absolute paths for files, and do not navigate with `cd` across calls - a `cd` in one command is gone by the next. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user && python build.py`).

## No network

The sandbox has no outbound connectivity, and there is no proxy, allowlist, or flag that turns it on - treat it as permanently offline. Anything that reaches the internet will fail: package installs (`pip`, `npm`, `apt`), remote `git`, and any HTTP/HTTPS request.

Recognise a network block by its error signature - failed name resolution (`Could not resolve host`, `Temporary failure in name resolution`), an unreachable route (`Network is unreachable`), or a stalled connection - rather than guessing. When you see these the failure is structural: do not retry the same call or hunt for a workaround (mirrors, alternate hosts, cached copies). Re-plan using only what is already installed and the files in your workspace.

## Filesystem

- Writable: everything under `/home/user/` plus `/tmp`. Use these for deliverables, intermediate files, and caches.
- Read-only inputs: `/home/user/documents` - the task's input documents. Copy these into a working folder before transforming them rather than editing them in place.

## Runtime

A document-processing stack is already installed - check what is present before assuming a gap:

- **Reading inputs**: `pandoc` or `python3 -c "import docx; ..."` for Word; `pdftotext` or `python3 -c "import pdfplumber; ..."` for PDFs; `python3 -c "import openpyxl; ..."` for Excel; `markitdown <path>` as a general-purpose extractor for .docx, .xlsx, .pptx, and .pdf. `libreoffice` (the `soffice` binary) is also installed - use `soffice --headless --convert-to pdf <path>` to convert any Office format (.docx/.xlsx/.pptx, including legacy .doc/.xls) when the python parsers fall short.
- **Producing deliverables**:
  - `.docx`: `python3 -c "from docx import Document; ..."` or `pandoc -o out.docx`.
  - `.xlsx`: `python3 -c "import openpyxl; ..."`.
  - `.md` and other plain text: write directly with `cat`/`tee`/your script.
- Check availability with `pip show <pkg>` or `which <tool>` rather than installing - installs fail offline, but the document stack above is already present.
- Commands are terminated after {command_timeout_minutes} minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Submitting your work

Finish by calling the `{finish_tool_name}` tool - anything not submitted through it is not graded. Your call must include:
1. A short summary of what you accomplished.
2. Absolute paths to every deliverable (files only, not folders).

Save each deliverable directly in `/home/user` under the exact filename the task asks for - not in a subdirectory. Save deliverables as ordinary, visible files - do not leave the only copy of your work in a dot-prefixed file or directory (e.g. `.report.docx`, `.output/report.docx`). Assume your files will be opened and edited by others after submission.

If the task genuinely cannot be completed, call the `{abandon_task_finish}` tool with a brief reason instead. Use it only when you have concluded the work is impossible - not to escape a difficult task.
</execution_context>

<task>
### {title}

{instructions}
</task>

<deliverables>
Submit these files, by exact name, saved directly in `/home/user`:
{expected_deliverables}
</deliverables>

Please begin working on the task now.
      • Eingabeaufforderung des Beurteilungssystems (Aufgabenkontext und Arbeitsprodukt):
        You are evaluating a legal AI agent's work product against one binary quality criterion.

<task_context_for_work_product>
The work product below was produced for this legal task. Use the task only as context for what the deliverables were meant to address - judge the work product, not the task.

{task_title}

{task_instructions}
</task_context_for_work_product>

<work_product>
{agent_output}
</work_product>
      • Aufforderung zum Beurteilungskriterium:
        <criterion>
<title>
{criterion_title}
</title>
<match_criteria>
{match_criteria}
</match_criteria>
</criterion>

Return `pass` only if the work product satisfies the criterion as described; otherwise `fail`.

APEX-Agents-AA

  • Beschreibung: APEX-Agents-AA ist die unabhängige Implementierung des APEX-Agents-Benchmarks von Mercor durch Artificial Analysis. Er bewertet langfristige, anwendungsübergreifende Agentenarbeit in professionellen Dienstleistungsumgebungen aus Investmentbanking, Unternehmensberatung und Recht.
  • Paper: https://arxiv.org/abs/2601.14242
  • Datensatz:
    • Wir stützen unsere Bewertung auf den öffentlichen APEX-Agents-Datensatz von https://huggingface.co/datasets/mercor/apex-agents
    • Wir bewerten 452 Aufgaben aus der öffentlichen 480-Aufgaben-Version (mit Ausnahme der Investment Banking-Welten 244 und 246, die externe Laufzeitabhängigkeiten aufweisen).
  • Implementierung:
    • Jede Aufgabe wird mit 3 Wiederholungen ausgeführt und mit pass@1 bewertet – eine Wiederholung besteht nur dann, wenn alle Punkte der Rubrik erfüllt sind, und die Ranglistenpunktzahl ist die durchschnittliche Erfolgsquote aller Wiederholungen
    • Alle Modelle werden mit unserem Open-Source-Agenten-Harness Stirrup mit einer Obergrenze von 200 Runden pro Aufgabe ausgeführt
    • Agenten agieren innerhalb der Archipelago-Umgebung und greifen über MCP-Server, die über das Gateway bereitgestellt werden, auf Arbeitsplatz-Tools zu
    • Der Agent beginnt mit einem kleinen Meta-Tool-Toolbelt und muss von MCP unterstützte Tools explizit verwalten, indem er Folgendes verwendet:
      • Tools auflisten – Zeigt an, welche Tools derzeit verfügbar sind
      • Werkzeug prüfen – Prüft ein Werkzeug, bevor es hinzugefügt wird
      • Tool hinzufügen – Stellt dem Agenten ein von MCP unterstütztes Tool zur Verfügung
      • Werkzeug entfernen – Entfernt Werkzeuge, die nicht mehr benötigt werden
    • Der Agent erhält außerdem:
      • Todo Write – Erstellt oder aktualisiert die Todo-Liste des Agenten. Es kann entweder die vollständige Liste ersetzen oder Aktualisierungen nach Todo-ID zusammenführen, und alle Todos müssen abgeschlossen oder abgebrochen werden, bevor die endgültige Übermittlung akzeptiert wird
      • Fertig stellen – Sendet die endgültige Antwort des Agenten zusammen mit einem Abschlussstatus. Dies ist die einzige Möglichkeit, eine endgültige Antwort einzureichen, und nur eine vollständig abgeschlossene Einreichung gelangt in die Bewertung
    • MCP-Toolaufrufe haben eine Zeitüberschreitung von 60 Sekunden. Die Tool-Ausgaben werden bei Bedarf auf ein 24.000-Token-Budget gekürzt, wobei ein Kopfauszug mit 20.000 Zeichen und ein Endauszug mit 5.000 Zeichen verwendet werden. Bildeingaben werden auf etwa 1 MP komprimiert, bevor sie an das Modell zurückgegeben werden
    • Die Bewertung erfolgt lokal mit dem lokalen Datei-Grader Archipelago. Jede Wiederholung wird anhand der Aufgabenrubrik bewertet, wobei sowohl die über „Fertig stellen“ übermittelte endgültige Antwort als auch der Dateisystemunterschied zwischen anfänglichen und endgültigen Weltschnappschüssen berücksichtigt werden. Eine Wiederholung besteht nur dann, wenn jedes Rubrikelement erfüllt ist. Gemini 3 Flash mit „niedriger“ Argumentation wird als LLM-Richter verwendet

AA-AnalystAgent

  • Beschreibung: AA-AnalystAgent ist der End-to-End-Datenanalyse-Benchmark von Artificial Analysis. Ein Agent beantwortet quantitative Fragen aus geschäftlichen und wissenschaftlichen Bereichen, arbeitet mit den bereitgestellten Quelltabellen und -dokumenten als primären Eingaben und führt Python in einer Sandbox-Codeausführungsumgebung aus. AA-AnalystAgent wird als eigenständige Bestenliste gemeldet und ist kein Bestandteil des Artificial Analysis Intelligence Index.
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Datensatz:
    • AA-AnalystAgent ist eine privat geführte Benchmark; Der Fragensatz, die Referenzantworten und die Quelldateien werden nicht öffentlich veröffentlicht, um das Kontaminationsrisiko zu begrenzen
    • 80 quantitative Fragen aus 14 Geschäfts- und Wissenschaftsbereichen, darunter Umweltberichterstattung, Handels- und Rohstoffstatistiken, Gesundheitsausgabenberichte, Hydrologie- und Wetterdaten, staatliche Mittel, Energiekostenmodelle, Finanzmodelle und Projektpläne
    • Die Fragen umfassen fünf funktionale Workflow-Archetypen, die die Bandbreite der echten Analystenarbeit abdecken: Quellensuche und -diagnose, Filter und Summe, Kennzahlen, Trends und Sensitivitäten, GuV-Modellierung sowie Cash-, Bilanz- und Bewertungsmodellierung
    • Jede Frage ist mit einem Ordner mit Referenztabellen und Dokumenten (xlsx, docx) verknüpft, der in den Arbeitsbereich des Agenten hochgeladen wird. Eine von Menschen verfasste Referenzantwort wird dem Agenten ausgehändigt und vom Bewerter bei der Bewertung verwendet
    • Referenzantworten werden durch Artificial Analysis unabhängig validiert
  • Implementierung:
    • Jede Frage wird mit 5 unabhängigen Wiederholungen durchgeführt. Die Bestenlistenpunktzahl beträgt pass^5 – der Anteil der Fragen, die bei jedem der 5 Versuche richtig beantwortet wurden:
      Dabei ist pji = 1, wenn Versuch i bei Frage j korrekt ist, andernfalls 0 und n die Anzahl der Fragen ist. Dies unterscheidet sich von der pass@1-Bewertung, die wir in unseren anderen Bewertungen verwenden: Ein Analystenagent ist nur dann nützlich, wenn seine Antworten ohne erneute Überprüfung bestehen bleiben, daher belohnt die Schlagzeilenmetrik die Wiedergabe einer richtigen Antwort gegenüber dem gelegentlichen Erreichen
    • Neben pass^5 berechnen wir pass@1 (die mittlere Erfolgsquote pro Versuch, aggregiert über alle Wiederholungen) und pass@5 (der Anteil der bei mindestens einem Versuch gelösten Fragen), die die Zuverlässigkeit eines Modells von seiner Obergrenze trennen
    • Alle Modelle werden als Agenten mit unserem Open-Source-Agentensystem Stirrup ausgeführt, mit einer Obergrenze von 100 Runden pro Aufgabe
    • Dem Agenten wird ein kleines Toolset zur Verfügung gestellt, das die Codeausführung in einer isolierten Linux-Sandbox (Python 3.12 mit vorinstallierten Referenzdateien der Frage und einem angehefteten Satz standardmäßiger Python-Datenanalysebibliotheken), das Abrufen von URLs, die Bildanzeige für visionsfähige Modelle und die Übermittlung der endgültigen Antwort umfasst. Modelle werden angewiesen, nur den Antwortwert (z. B. nur die Zahl oder die Bezeichnung) ohne Erklärung einzureichen
    • Jede Antwort wird anhand der vorgehaltenen Referenzantwort als binär richtig oder falsch bewertet. Jede Zelle wird an einen LLM-Richter gesendet, sodass die Bewertung der Artefakte und die Abrechnung der Richterkosten einheitlich bleiben. Eine deterministische Vorprüfung der numerischen Äquivalenz hat dann in eindeutigen Fällen Vorrang vor dem Richter: Eine Antwort, die dem Referenzwert entspricht, in derselben Einheitenkonvention und mit der Genauigkeit, die die Frage erfordert, ist ein garantierter Erfolg. Die Vorprüfung ist einseitig – sie lässt nie eine Antwort aus – und alles, was sie nicht klären kann, behält das Urteil des Richters bei. Wenn der Richter eine fehlerhafte Antwort auf eine Zelle zurückgibt, kann die Vorprüfung abgeschlossen werden, die Vorprüfung erfasst dennoch ein Bestehen. Gemini 3 Flash (Reasoning) wird als LLM-Richter verwendet

Agent-Eingabeaufforderung: Der Agent wird mit der folgenden Vorlage aufgefordert, die die Referenzdateien der Frage, die Aufgabe und den Namen des Abschlusstools interpoliert:

You are tasked with answering a data analysis question.

## Environment

The `code_exec` tool provides access to a Linux-based execution environment with a full file system where you can create, read, and modify files.

Python 3.12 is the default runtime. Use `python script.py` to run scripts.
The following Python packages are preinstalled (pinned versions):

- numpy 2.4.4, numpy-financial 1.0.0, pandas 3.0.2, scipy 1.17.1, polars 1.40.0
- matplotlib 3.10.8, seaborn 0.13.2
- scikit-learn 1.7.2, statsmodels 0.14.4
- openpyxl 3.1.5, xlrd 2.0.2, python-docx 1.2.0, formulas 1.3.4
- PyMuPDF 1.27.2.2, pdfplumber 0.11.9
- Pillow 12.2.0, requests 2.33.1, beautifulsoup4 4.13.4
- tqdm 4.67.3, tabulate 0.10.0, sympy 1.14.0

## Reference Files

The following reference files are available in your workspace:

<reference_files>
{reference_files}
</reference_files>

## Task

<task>
{task}
</task>

## Submitting Your Answer

When you have determined the answer, use the `{finish_tool_name}` tool to submit it.
Your answer should be a concise, direct response to the question.
If the question asks for a number, provide just the number.
If the question asks for a name or label, provide just that.
Do NOT include explanations in your answer — only the final answer value.

Bewertungsaufforderung: Jede Antwort (Modell, Frage) wird mit der folgenden Eingabeaufforderung an einen LLM-Richter gesendet, wobei die ursprüngliche Frage, die zurückgehaltene Referenzantwort und die vom Agenten eingereichte Antwort interpoliert werden. Die numerische Vorprüfung kann dieses Urteil dann wie oben beschrieben außer Kraft setzen:

You are an expert evaluator grading a data analyst's response to a question.

Decide whether the response is correct or incorrect, judged against the reference answer and the standard a professional data analyst working in this question's domain would be held to. Focus on the substance of the answer, not prose style. Be objective and consistent, and give a brief explanation for your verdict.

First identify exactly what the reference requires — the specific value(s), item(s), or label(s) — and what the response actually commits to, then compare them directly before deciding.

Apply these conventions:

- Format directives are binding. If the question specifies a form or precision — a number of decimal places, "as a percentage", "to the nearest cent", a cell reference, particular units — the response must satisfy it. A right value in the wrong requested form is incorrect.
- Equivalent representations of the same value are correct. Thousands separators, currency symbols, surrounding whitespace, and trailing zeros are immaterial; a percentage and its decimal fraction (e.g. 12.84% and 0.1284) are the same value; adding or omitting a "%" sign never changes correctness when the digits already match the value the reference states; a quantity stated in the dataset's native units (e.g. thousands) matches the same amount written in full.
- Judge precision by value, to a sensible number of significant figures. When the question states a precision, require exactly that. When it does not, accept any answer that is a correct rounding of the reference value — reference answers often carry more decimal places than are meaningful (e.g. a dollar figure written as 64792.44714), and a competent analyst rounds sensibly, so do NOT reject an answer merely for having fewer decimals than the reference. Reject an answer only when its value genuinely differs from the reference (a wrong figure, not a coarser rounding of the same value) or when it discards so much precision that it misstates the quantity.
- Match every required item. If the question asks for more than one item (e.g. "which two tasks"), the response is correct only if it identifies exactly the reference's items. Judge the single set the response commits to and ignore hedged alternatives phrased as "(or ...)"; a response naming different items than the reference — however plausible — is incorrect.
- Honor explicit acceptance and rejection clauses in the reference answer. If the reference names specific values as acceptable or as not acceptable, follow it exactly.

## Question

{question_prompt}

## Reference Answer

{reference_answer}

## Response to Evaluate

{model_response}

EnterpriseOps-Gym-AA

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2)
  • Beschreibung: EnterpriseOps-Gym-AA ist die unabhängige Implementierung des EnterpriseOps-Gym-Benchmarks von ServiceNow durch Artificial Analysis. Er bewertet KI-Agenten bei zustandsbehafteter, mehrstufiger Planung und Werkzeugnutzung in realistischen Unternehmensabläufen. Agenten bedienen laufende Unternehmenssysteme über Werkzeuge und werden anhand des Endzustands der zugrunde liegenden Datenbanken bewertet, nicht anhand ihrer genauen Aktionsfolge.
  • Paper: https://arxiv.org/abs/2603.13594
  • Datensatz: https://huggingface.co/datasets/ServiceNow-AI/EnterpriseOps-Gym
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Domänen: Wir bewerten die Oracle-Modus-Aufgaben des Benchmarks in allen acht Unternehmensdomänen: Kundendienstmanagement (CSM), Personalwesen (HR), IT-Servicemanagement (ITSM), E-Mail, Kalender, Teams und Laufwerk sowie Hybridaufgaben, die die Orchestrierung von Aktionen über mehrere dieser Systeme hinweg erfordern einzelner Arbeitsablauf.
  • Implementierung:
    • Jede Aufgabe wird in einer isolierten, zurücksetzbaren Sandbox ausgeführt: Die relevanten Unternehmenssysteme werden als eigenständige Server der Evaluierungsumgebung bereitgestellt, wobei jedes seine Tools über einen Live-Model Context Protocol (MCP)-Server zur Verfügung stellt und durch eine aufgabenspezifische SQLite-Datenbank mit synthetischen Daten gestützt wird. Jede Aufgabe klont ihre eigene Datenbank, sodass Ausführungen isoliert und reproduzierbar sind.
    • Wir führen den Benchmark nur im Oracle-Tool-Modus aus: Der Agent erhält die für die Aufgabe erforderlichen Tools, wodurch Planung und Ausführung vom Tool-Abruf isoliert werden. Die Distraktor-Tool-Modi des Quelldatensatzes werden nicht ausgeführt.
    • Alle Modelle werden mit unserem Open-Source-Agentensystem Stirrup in einer standardmäßigen Reason-and-Act-Tool-Use-Schleife mit einer Obergrenze von 100 Runden pro Aufgabe ausgeführt. Jede Aufgabe wird mit 3 Wiederholungen ausgeführt und die Gesamtpunktzahl ist der Mittelwert aller Wiederholungen.
    • Die Benotung erfolgt ergebnisorientiert. Nachdem der Agent fertig ist, wird der endgültige Status der Datenbank jeder Aufgabe erstellt und mit den SQL-Verifizierern des Benchmarks überprüft, die die Zielerfüllung, Status- und Integritätsbeschränkungen, Berechtigungs- und Prozesskonformität sowie das Fehlen unbeabsichtigter Nebenwirkungen testen.
    • Es werden zwei Kennzahlen gemeldet. Die Schlagzeile Erfolgsquote ist strikt pass@1: Eine Aufgabe gilt nur dann als Erfolg, wenn sie jeden ihrer Prüfer besteht. Wir berichten auch über die Bestandsquote der Verifizierer, den Anteil der einzelnen bestandenen Verifiziererprüfungen, als detailliertere sekundäre Kennzahl.
    • Unterschiede zum Benchmark von ServiceNow: EnterpriseOps-Gym-AA ist unsere unabhängige Implementierung, die auf unserem eigenen Stirrup-System und unseren Agenten-Eingabeaufforderungen ausgeführt wird. Daher sind unsere Zahlen nicht direkt mit den im Dokument angegebenen Ergebnissen vergleichbar.

Terminal-Bench-Science 0.1

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2)
  • Beschreibung: Terminal-Bench-Science ist eine offene akademische Zusammenarbeit, die von Forschern der Stanford University mit dem Terminal-Bench- und Harbor-Team entwickelt wurde und Beiträge von Wissenschaftlern aus Institutionen auf der ganzen Welt umfasst. Die Aufgaben des Forschungsworkflows basieren auf der realen wissenschaftlichen Praxis und werden von Experten kuratiert und überprüft. Für jede Aufgabe gibt es eigene Tests, die der Agent bestehen muss, wenn er in einem Terminal arbeitet. Die Version 0.1.0 deckt die Lebens-, Physik-, Mathematik-, Ingenieur- und Geowissenschaften ab.
  • Zitat: https://doi.org/10.5281/zenodo.22110254
  • Bestenliste: https://terminal-bench-science.ai/
  • Datensatz: https://github.com/harbor-framework/terminal-bench-science
  • Implementierung:
    • Wir evaluieren die vollständige Version von Terminal-Bench-Science 0.1.0 (70 Aufgaben: 19 Biowissenschaften, 17 physikalische Wissenschaften, 17 mathematische Wissenschaften, 9 technische Wissenschaften, 8 geowissenschaftliche Wissenschaften) mithilfe des mini-swe-agent-Ausführungsumgebung mit pass@1 Die Bewertung erfolgte im Durchschnitt über 3 Wiederholungen pro Aufgabe
    • Für jede Aufgabe gibt es einen eigenen Testsatz. Eine Aufgabe besteht nur, wenn jeder Test erfolgreich ist, und die Bewertung wird im eigenen Prüfcontainer jeder Aufgabe ausgeführt, der von der Umgebung des Agenten isoliert ist
    • Wir wenden die folgenden Einschränkungen auf Bewertungen für den Agenten an:
      • Wir begrenzen den Agenten auf 1.000 Schritte
      • Task-Timeouts und Sandbox-Ressourcen folgen den Upstream-Taskdefinitionen
    • Alle anderen Agentenkonfigurationen folgen den Standardeinstellungen für mini-swe-agent

ITBench-AA

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2)
  • Beschreibung: ITBench-AA ist die unabhängige Implementierung von Artificial Analysis des ITBench-Benchmarks von IBM zur Bewertung von KI-Agenten im Bereich Site Reliability Engineering (SRE): Kubernetes-Vorfall-Ursachenanalyse.
  • Paper: https://arxiv.org/abs/2502.05352
  • Repository: https://huggingface.co/datasets/ArtificialAnalysis/ITBench-AA
  • Agentenframework: https://github.com/ArtificialAnalysis/Stirrup
  • Datensatz:
    • Wir werten 59 Kubernetes-Vorfallsaufgaben aus: 40 aus der öffentlichen ITBench SRE-Version von IBM und 19 private Aufgaben, die uns vom ITBench-Team zur Verfügung gestellt wurden. Der Schlagzeilen-Score wird über beide Splits gemittelt
    • Bei jeder Aufgabe handelt es sich um einen Offline-Kubernetes-Vorfall-Snapshot mit Warnungen, Ereignissen, Ablaufverfolgungen, Metriken, Protokollen und Anwendungstopologie, der in eine szenariospezifische Sandbox eingebettet und unter /home/user bereitgestellt wird
  • Implementierung:
    • Jede Aufgabe wird mit 3 Wiederholungen ausgeführt. Die Hauptmetrik ist die Präzision bei vollständigem Recall: Eine Wiederholung erhält 0.0, wenn sie eine Ursachenentität aus den Referenzdaten auslässt. Andernfalls wird die Präzision über die eingereichten Entitäten berechnet.
    • Alle Modelle werden mit unserem Open-Source-Agenten-Harness Stirrup mit einer 100-Umdrehungs-Kappe pro Aufgabe ausgeführt. Die Agentenschleife informiert das Sprachmodell darüber, dass sich sein Rundenlimit während der letzten 20 Runden nähert.
    • Der Agent erhält ein einzelnes run_shell-Tool zum Überprüfen des Snapshots sowie ein finish-Tool zum Übermitteln seiner endgültigen Antwort. Es muss eine strukturierte JSON-Diagnose in /home/user/agent_output.json geschrieben werden, die den minimalen Satz unabhängiger Kubernetes-Entitäten mit der Grundursache enthält, die für den Vorfall verantwortlich sind, mit Begründung und Beweisen für jede, unter Ausschluss nachgelagerter Symptome
    • Bei der Bewertung wird ein LLM-Richter nur verwendet, um übermittelte contributing_factors auf die kanonischen Ground-Truth-Entitäten und Aliasgruppen zu normalisieren.
    • Nach der Normalisierung werden Ground-Truth-Aliasgruppen zu Bewertungsgruppen zusammengeführt, sodass äquivalente Entitäten wie ein Pod und die entsprechende Bereitstellung/der entsprechende Dienst als dieselbe Vorhersage gelten. Wenn ein Mitglied einer Aliasgruppe als Grundursache markiert ist, wird die zusammengeführte Gruppe als Grundursachenziel gewertet; Die Vorhersage mehrerer Entitäten in derselben Aliasgruppe zählt nur einmal.
    • Die Präzision bei vollständigem Abruf wird als 0.0 berechnet, wenn eine Grundursachen-Bewertungsgruppe fehlt. Wenn keine Grundursachengruppen übersehen werden, handelt es sich um true_positives / (true_positives + false_positives), wobei nicht übereinstimmende Vorhersagen und Vorhersagen, die Nicht-Grundursachengruppen zugeordnet sind, als falsch positive Ergebnisse gelten.
    • GPT-5.5 mit mittlerem Argumentationsaufwand wird als Bewertungsmodell zum Vergleich der Modellausgabe mit der Grundwahrheit für jede Aufgabe verwendet
  • Generierungsaufforderung:
    **Task**:

You are an expert SRE (Site Reliability Engineer) and Kubernetes SRE Support Agent investigating a production incident from OFFLINE snapshot data.

====================================================================
# INCIDENT SNAPSHOT DATA LOCATION
====================================================================
Your incident data and working directory is located in
- /home/user

The final output must be written to /home/user/agent_output.json

Available Python packages:
- `drain3==0.9.11`
- `numpy==2.4.5`
- `pandas==3.0.3`

Both `python` and `python3` are available and use the same environment.

Your objective is to generate a **JSON diagnosis** identifying the root causes of the incident — the minimal set of independent Kubernetes entities whose failures directly explain the incident.

Requirements:
- Provide reasoning and evidence for every listed entity.
- When the JSON file is ready, call the provided finish tool and submit `/home/user/agent_output.json`.

All entities MUST use the format: `namespace/Kind/name`

Examples:
- `otel-demo/Deployment/ad` (Deployment named "ad" in namespace "otel-demo")
- `otel-demo/Service/frontend` (Service named "frontend")
- `cluster/Node/worker-node-1` (cluster-scoped resource)

DO NOT include UIDs in the entity name.

====================================================================
## Output Format
====================================================================
Output must consist solely of the final diagnosis in the specified JSON format below — do **not** include any additional text, markdown, or comments:

```json
{
"contributing_factors": [
  {
    "name": "namespace/Kind/name",
    "reasoning": "A short, clear, human-readable explanation for why this entity is a root cause. Reference evidence where possible.",
    "evidence": "Concise summary of supporting facts — relevant alerts, events, logs, traces, or metrics. Plain string."
  }
]
}
```

====================================================================
# RULES FOR INCLUSION
====================================================================

**Only include an entity if both of the following are true:**

1. **There is qualifying evidence** — it appears in at least one of: a firing alert, a Kubernetes event, an error/warning log line, a metric anomaly, or trace evidence directly tied to the incident window. A passing mention in an unrelated log is not sufficient.

2. **It passes the irreducibility test** — you cannot fully explain its failure by pointing to another entity already in the list. Ask: *"If I remove this entity, does my explanation of the incident become incomplete?"* If yes, include it. If another entity already accounts for it, leave it out.

**Do not include** downstream effects, symptoms, or intermediates — only the independent upstream causes.

**Example (exhausted ResourceQuota blocking pod scheduling):**

Causal chain: ResourceQuota exhausted → ReplicaSet cannot schedule pods → Deployment degraded

- ✅ `otel-demo/ResourceQuota/otel-demo-mem-quota` — memory limit exhausted; directly blocks pod creation. Include.
- ❌ `otel-demo/ReplicaSet/ad-7f9d4b` — failed only because the quota above was exhausted. Exclude.
- ❌ `otel-demo/Deployment/ad` — degraded as a downstream consequence. Exclude.

**Multiple entries are allowed only if they are truly independent** — two separate upstream causes that do not explain each other.

When in doubt, prefer the most specific Kubernetes object that independently introduced the failure.

====================================================================
# INVESTIGATION WORKFLOW
====================================================================

### Phase 1 — Context Discovery
List available files (alerts, logs, events, topology).

### Phase 2 — Symptom Analysis
Read all alert files. Compute:
- Start time, End time, Duration, Frequency

### Phase 3 — Hypothesis Generation
- Create initial hypotheses (e.g. "checkout pods OOMKilled", "redis latency spike").
- Create a validation plan for each hypothesis.

### Phase 4 — Evidence Collection Loop
- Use tools (and generated python code) to gather log, event, metrics, trace evidence.
- Validate or refute each hypothesis using real data.
- Explain firing alerts as soon as you find supporting evidence.

### Phase 5 — Causal Chain Construction
Build a causal chain like
`[Config Error] → [CrashLoop] → [Service Down] → [Frontend 5xx]`

### Phase 6 — Conclusion
Ensure:
- All alerts are explained in the reasoning/evidence for the root causes, but do not add downstream entities only to account for alerts
- All included entities pass the irreducibility test
- JSON is written to `/home/user/agent_output.json`
- Call the finish tool and submit the file
  • Benotungsaufforderung:
    You are an expert AI evaluator specializing in Root Cause Analysis (RCA) for complex software systems.

You will be provided with:

1. A **Ground Truth (GT)** JSON object containing entity definitions.
2. A **Generated Response** JSON object containing predicted entities.

Your job is only to normalize generated entities to ground-truth entities.

Ground Truth fields such as `groups`, `aliases`, `filter`, and `kind` may appear either at the top level of `GT` or under `GT.spec`. Treat `GT.spec` as the ground-truth payload when present.

-----

### Normalization Rules

Before any downstream scoring can occur, you must accurately normalize entities from the `Generated Response` to the `Ground Truth`.

This process must be based on **explicit evidence** from the entity's metadata.
You must not infer or guess mappings based on an entity's position in a causal chain.

Only normalize entities from `Generated Response.contributing_factors`.

An entity from the `Generated Response` can only be mapped to a `Ground Truth` entity if a **Confident Match** can be established.

**Definition of a Confident Match:**
A generated entity is a confident match to a ground-truth entity only if its `name` field, or other explicit identifying metadata, clearly corresponds to the `filter` and `kind` of a ground-truth entity.

**Alias Handling:**
The `GT.aliases` field contains arrays of equivalent entity IDs.
If a generated entity clearly matches an entity in an alias group, you may normalize it to the matching GT entity ID from that alias group.

**Workload Kind Equivalence:**
Treat `Deployment` and `Pod` as equivalent for normalization when the namespace and workload name correspond. For example, `otel-demo/Deployment/checkout` is a confident match for a GT `Pod` entity whose filter matches checkout pods in the `otel-demo` namespace.

**Entity Name Format:**
Generated entities use the format `namespace/Kind/name`.

Examples:
- `otel-demo/Deployment/flagd`
- `otel-demo/Service/frontend`
- `otel-demo/Pod/checkout-8546fdc74d-d68cn`

Confident match examples:
- A generated entity with `name: "otel-demo/Service/adservice"` is a confident match for the GT entity with `id: "ad-service-1"` and `filter: [".*adservice\\\\b"]`.
- A generated entity with `name: "otel-demo/Service/adservice"` can match `ad-pod-1` only if the GT alias set makes that link explicit, for example `["ad-pod-1", "ad-service-1"]`.
- If `GT.aliases` contains `["load-generator-pod-1", "load-generator-service-1"]`, then normalizing a generated `load-generator-service-1` match to that alias group is valid.
- A generated `chaos-mesh/Schedule/...` entity whose name matches a GT filter is a confident match for the spawned chaos resource of any kind, provided name and namespace correspond.
- A generated entity with `name: "67cbd7fe98a0776a"` and no other identifying evidence is not a confident match.

If a generated entity does not have a confident match, leave it unmatched and set its normalized GT entity ID to `null`.

Preserve the original order of the generated `contributing_factors`.

-----

### Output Format

Return only a single JSON object with this shape:

```json
{
"contributing_factor_entities": [
  {
    "submitted_entity_name": "namespace/Kind/name",
    "normalized_gt_entity_id": "ground-truth-entity-id-or-null",
    "reasoning": "brief explanation of why this is a confident match or why it is unmatched"
  }
]
}
```

Rules:
- Include one item for every generated entity in `contributing_factors`.
- Preserve input order.
- Use `normalized_gt_entity_id: null` when there is no confident match.
- Return only valid JSON.

Given the following Ground Truth (GT) and Generated Response, normalize the generated contributing-factor entities to the Ground Truth.

## Ground Truth (GT):
```json
{ground_truth}
```

## Generated Response:
```json
{generated_response}
```

## Task:
1. Look only at `Generated Response.contributing_factors`.
2. For each such entity, determine whether there is a confident match in the Ground Truth.
3. If there is a confident match, return the matched ground-truth entity ID.
4. If there is not a confident match, return `normalized_gt_entity_id: null`.
5. Do not score anything. Return only the normalization result JSON.

Allgemein

IFBench

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2). IFBench wurde in Version 4.1 aus dem Intelligence Index entfernt, wir führen es jedoch weiterhin auf neuen Modellversionen aus.
  • Beschreibung: Ein Benchmark, der die Fähigkeit eines Modells bewertet, präzisen Anweisungen in einer einzigen Runde zu folgen. Es testet ein breites Spektrum an Fähigkeiten, einschließlich Zählen, Formatieren und Satzmanipulation.
  • Paper: https://arxiv.org/abs/2507.02833
  • Datensatz: https://huggingface.co/datasets/allenai/IFBench_test
  • Implementierung:
    • Verwendet den Single-Turn-Datensatz IFBench, der 294 Fragen enthält
    • Wir führen 5 Wiederholungen für jede Frage mit der Bewertung pass@1 durch
    • Wir werten die Antworten anhand des offiziellen Quellcodes von allenai/IFBench aus
    • Wir verwenden den losen Bewertungsmodus, um die Befolgung von Anweisungen zuverlässig zu bewerten. Dabei werden überflüssiger Text oder Formatierungen berücksichtigt, indem mehrere Variationen der Modellausgabe überprüft werden (z. B. mit und ohne die ersten und letzten Zeilen und ohne Sternchen).
    • Unsere Punktzahl stellt die Genauigkeit der Eingabeaufforderung dar (Durchschnitt aller Fragen und Wiederholungen).
    • Wir verwenden nicht die Multiturn-Version von IFBench, die einen anderen Datensatz verwendet

MLCR-AA (Medical Long Context Reasoning)

  • Status: Eigenständige Evaluierung (kein Bestandteil des Artificial Analysis Intelligence Index v4.3.2); ein Bestandteil des Artificial Analysis Healthcare & Medical Index
  • Beschreibung: MLCR-AA ist die Evaluierung von MLCR (Medical Long Context Reasoning) durch Artificial Analysis. Dieser offene Benchmark von Wisedocs misst, wie gut Modelle über lange, fragmentierte Krankenakten schlussfolgern. Er prüft die dokumentübergreifende Synthese, die Fachkräfte der Leistungsprüfung bei Versicherungs- und Gesundheitsfällen leisten, etwa die Rekonstruktion von Chronologie, Kausalität, Behandlungsmustern und Anspruchsrelevanz.
  • Code: Wisedocs-AI/medical-long-context-reasoning
  • Öffentlicher Datensatz: Wisedocs/mlcr-dataset
  • Wichtige Details:
    • Realistische, synthetische medizinische Fälle von etwa 25.000–64.000 Token
    • Die Fragen werden in sechs Schwierigkeitsstufen eingestuft, von der Suche nach einer einzelnen Tatsache über die klinische Synthese auf Expertenniveau bis hin zu zusammengesetzten, mehrteiligen Überlegungen
    • Antworten, die das Prägnanz-Gate bestehen und eine Antwort enthalten, werden von einer Jury aus drei LLM-Richtern bewertet; Richtigkeit und Vollständigkeit werden jeweils durch Mehrheitsbeschluss entschieden
    • Eine Antwort, die länger als das Fünffache der Referenzantwort ist, besteht ein Prägnanz-Gate nicht und wird ohne Wertung mit null bewertet; Bei der Gesamterfolgsquote wird eine Antwort nur dann gutgeschrieben, wenn sie dieses Tor passiert und als vollständig und korrekt beurteilt wird
    • Artificial Analysis bewertet einen privaten, vorgehaltenen Satz der beiden schwierigsten Fragetypen (klinische Synthese auf Expertenebene und zusammengesetztes, mehrteiliges Denken): 60 Fragen, jeder Durchgang mit 3 Wiederholungen. Dieser private Satz ist vom öffentlich veröffentlichten Datensatz getrennt
    • Artificial Analysis gibt die Gesamterfolgsquote (wird nur angerechnet, wenn eine Antwort prägnant ist und als vollständig und genau beurteilt wurde) als Primärpunktzahl an. Die Genauigkeit und Vollständigkeit der Beurteilung sind bedingte Werte unter den bewerteten Antworten. Prägnanz deckt alle Antworten ab. Diese Aufschlüsselungen werden neben der Primärpunktzahl angezeigt; pass@1

Sonstige

Global-MMLU-Lite

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2); ist die Grundlage für den Artificial Analysis Multilingual Index
  • Beschreibung: Eine schlanke, mehrsprachige Version von MMLU zur Bewertung von Wissen und Denkfähigkeiten in einer Vielzahl von Sprachen und kulturellen Kontexten.
  • Datensatz: CohereLabs/Global-MMLU-Lite
  • Wichtige Details:
    • ~6.000 Fragen (~400 pro unterstützter Sprache)
    • Multiple Choice (4 Optionen)
    • Regex-Extraktion, pass@1

MMMU Pro

  • Status: Eigenständige Auswertung (nicht Teil des Artificial Analysis Intelligence Index v4.3.2); ein Benchmark für multimodales (visuelles) Denken
  • Beschreibung: Ein verbesserter MMMU-Benchmark, der Abkürzungen und Ratestrategien eliminiert, um multimodale Modelle in 30 akademischen Disziplinen gründlicher zu testen.
  • Datensatz: MMMU/MMMU_Pro
  • Wichtige Details:
    • 1.730 Fragen
    • Multiple Choice (10 Optionen)
    • Regex-Extraktion, pass@1

Frühere Evaluationen

Bewertungen, die wir zurückgezogen oder ersetzt haben. Wir behalten ihre Methodik hier als Referenz und zur historischen Vergleichbarkeit; Sie sind nicht mehr Teil des Artificial Analysis Intelligence Index oder unserer aktiven Berichterstattung.

GPQA Diamond (Graduate-Level Google-Proof Q&A Benchmark)

  • Status: In Version 4.2 aus dem Artificial Analysis Intelligence Index entfernt, da er bis einschließlich Version 4.1.1 Bestandteil war. Wir führen es immer noch bei neuen Modellversionen aus und melden es als eigenständige Bewertung.
  • Beschreibung: Benchmark für wissenschaftliches Wissen und logisches Denken.
  • Teilmenge: Diamant-Teilmenge (198 Fragen), ausgewählt für maximale Genauigkeit und Unterscheidungskraft
  • Paper: https://arxiv.org/abs/2311.12022
  • Datensatz: https://github.com/openai/simple-evals/blob/main/gpqa_eval.py
  • Wichtige Details:
    • 198 Fragen zu Biologie, Physik und Chemie – wir testen die GPQA Diamond-Teilmenge des vollständigen GPQA-Datensatzes (insgesamt 448 Fragen), die von den ursprünglichen Autoren als die hochwertigste Teilmenge definiert wurde, bei der beide Experten richtig antworten und die Mehrheit der Nicht-Experten falsch antwortet
    • Multiple-Choice-Format mit 4 Optionen
    • Regex-basierte Antwortextraktion mit pass@1-Bewertung (Eingabeaufforderung und Regex unten)

𝜏³-Banking

  • Status: In Version 4.3 aus dem Artificial Analysis Intelligence Index entfernt, da er bis einschließlich Version 4.2 Bestandteil war. Wir führen es immer noch bei neuen Modellversionen aus und melden es als eigenständige Bewertung.
  • Beschreibung: Fintech-Kundensupport-Domäne des 𝜏-Knowledge-Frameworks, das von Sierra entwickelt wurde und Agenten bewertet, die den Abruf aus einer großen unstrukturierten Wissensdatenbank mit mehrstufigen, durch Tools vermittelten Kontoänderungen koordinieren müssen.
  • Paper: https://arxiv.org/abs/2603.04370
  • Blog: sierra.ai/blog/bench-advancing-agent-benchmarking-to-knowledge-and-voice
  • Datensatz: https://github.com/sierra-research/tau2-bench
  • Implementierung:
    • Agenten verarbeiten ca. 700 miteinander verbundene Richtliniendokumente (ca. 195.000 Token, 21 Produktkategorien) und müssen die relevante Richtlinie finden, darüber nachdenken und eine mehrstufige Abfolge von Tool-Aufrufen ausführen – einschließlich Tools, auf die nur in der Dokumentation verwiesen und nicht explizit aufgeführt wird
    • Wir werten die vollständige 𝜏³-Banking-Aufgabensuite (97 Aufgaben) mit 5 Wiederholungen pro Aufgabe aus und melden pass@1 im Durchschnitt über die Wiederholungen, wobei wir den vorgelagerten Datensatz und Grader tau2-bench v1.0.1 ausführen
    • Die Ergebnisse werden anhand des tatsächlichen Zustands der Backend-Datenbank bewertet – zum Beispiel, ob eine Streitigkeit eröffnet oder eine vorläufige Gutschrift ausgestellt wurde – und nicht anhand der Konversationsqualität
    • Wir verwenden GPT-5.4 Mini (medium reasoning) sowohl für den Benutzersimulator als auch für den Assertion Judge in natürlicher Sprache
    • Für den Wissensabruf über den Bankkorpus aktivieren wir die lexikalische Suche BM25 und den Modus grep (bm25_grep) im ursprünglichen 𝜏-Bench-Harness
    • Wir begrenzen die Ausführung auf maximal 200 Schritte pro Aufgabenwiederholung, den Referenzstandard von 𝜏-Knowledge für Textläufe. Ein „Schritt“ bezeichnet hier gemäß der 𝜏-Bench-Ausführungsumgebung jede innerhalb der Simulation übergebene Nachricht, einschließlich der Runden des Benutzersimulators, und nicht nur die Runden des evaluierten Modells.

Terminal-Bench 2.1

  • Status: Ersetzt durch Terminal-Bench 4.0 in Intelligence Index v4.3, war Bestandteil bis einschließlich v4.2. Es bleibt Teil des Coding Index.
  • Beschreibung: Eine verifizierte Aktualisierung von Terminal-Bench, entwickelt von Forschern der Stanford University, dem Laude Institute und der Open-Source-Community. Behält die gleichen 89 kuratierten Aufgaben in den Bereichen Softwareentwicklung, Systemadministration, Datenverarbeitung, Modellschulung und Sicherheit bei, mit Umgebungs- und Befehlskorrekturen, die dafür sorgen, dass die Bewertungen die Fähigkeiten der Agenten widerspiegeln und nicht Umgebungslücken.
  • Paper: https://arxiv.org/abs/2601.11868
  • Bestenliste: tbench.ai/leaderboard/terminal-bench/2.1
  • Implementierung:
    • Wir werten den gesamten Terminal-Bench 2.1-Datensatz (89 Aufgaben) mithilfe des Terminus 2-Agenten-Harness in einer E2B-Sandbox-Umgebung aus, mit einer pass@1-Bewertung im Durchschnitt über 3 Wiederholungen pro Aufgabe
    • Jede Aufgabe wird mit einer Verifizierungssuite geliefert, die der Agent durch die Interaktion mit dem Terminal erfüllen muss – Aufgaben gelten nur dann als erfolgreich, wenn jeder Test bestanden wird
    • Wir wenden die folgenden Einschränkungen auf Bewertungen für den Agenten an:
      • Die maximale Anzahl an „Episoden“ (in denen das Modell den aktuellen Status überprüft und eine Reihe nächster Aktionen am Terminal plant) ist auf 250 begrenzt
      • Das Zeitlimit für den Agenten pro Aufgabe ist auf zwei Stunden (7.200 Sekunden) oder auf das von der Aufgabe selbst festgelegte Zeitlimit eingestellt, wenn dieses länger ist und deutlich über der typischen Aufgabendauer liegt
    • Bei unseren Tests begrenzen diese Einschränkungen überwiegend Fälle, in denen Modelle in einer erfolglosen Schleife stecken bleiben, und wir sehen aufgrund dieser Einschränkungen keine konsistenten Leistungsunterschiede

Terminal-Bench Hard

  • Hinweis: Ersetzt durch Terminal-Bench 2.1, das wir künftig verwenden. Terminal-Bench Hard war vor Version 4.1 Bestandteil des Artificial Analysis Intelligence Index
  • Beschreibung: Ein 2025 veröffentlichter Agenten-Benchmark, entwickelt von Forschenden der Stanford University, dem Laude Institute und der Open-Source-Community. Terminal-Bench bewertet die Fähigkeit von Agenten und Modellen, über eine Terminalschnittstelle verschiedenste Aufgaben zu lösen, darunter Softwareentwicklung, Systemadministration und Spielszenarien.
  • Seite: https://www.tbench.ai/
  • Datensatzregistrierung: https://www.tbench.ai/registry
  • Implementierung:
    • Wir implementieren die „harte“ Teilmenge des Terminal-Bench-Core-Datensatzes mit der neuesten Datensatzversion vom 14. August 2025 (Commit 74221fb); Wir werten 44 Aufgaben aus dieser Teilmenge aus (eine kleine Anzahl von Aufgaben wird aufgrund externer Abhängigkeitsprobleme im Originaldatensatz ausgeschlossen).
    • Wir evaluieren diese „harte“ Teilmenge mithilfe der Agentenumgebung Terminus 2, um die Konsistenz zwischen den Modellen zu gewährleisten, und bewerten Modelle auf der Grundlage der pass@1-Bewertung mit dem Gesamtdurchschnitt über 3 Wiederholungen für jede Aufgabe
    • Im Terminal-Bench-Framework wird auf jede Aufgabe eine bestimmte Reihe von Tests angewendet und sie gelten als erfolgreich, wenn alle Tests bestanden wurden, andernfalls als nicht erfolgreich
    • Wir wenden die folgenden Einschränkungen auf Bewertungen für den Agenten an:
      • Die maximale Anzahl an „Episoden“ (in denen das Modell den aktuellen Status überprüft und eine Reihe nächster Aktionen am Terminal plant) ist auf 100 begrenzt
      • Wir legen ein globales Zeitlimit pro Aufgabe von zwei Stunden (7.200 Sekunden) fest. In der Praxis ist die 100-Folgen-Grenze die verbindliche Vorgabe
      • Modelle sind auf maximal 1 Million kumulative Eingabetoken pro Wiederholung jeder Aufgabe beschränkt
    • Bei unseren Tests begrenzen diese Einschränkungen überwiegend Fälle, in denen Modelle in einer erfolglosen Schleife stecken bleiben, und wir sehen aufgrund dieser Einschränkungen keine konsistenten Leistungsunterschiede

𝜏²-Bench Telecom

  • Hinweis: Ersetzt durch 𝜏³-Banking, das wir künftig verwenden. 𝜏²-Bench Telecom war vor Version 4.1 Bestandteil des Artificial Analysis Intelligence Index
  • Beschreibung: Von Sierra entwickelter Benchmark für Konversations-KI-Agenten in „Doppelkontroll“-Szenarien mit Sprachmodellen, die sowohl Agenten- als auch Benutzerrollen simulieren, um Planung, Werkzeugnutzung und Führung/Kommunikation zu testen.
  • Paper: https://arxiv.org/abs/2506.07982
  • Blog: sierra.ai/resources/research/tau-squared-bench
  • Datensatz: https://github.com/sierra-research/tau2-bench
  • Implementierung:
    • Die in 𝜏²-Bench eingeführte „Telekommunikation“-Domäne enthält 114 Aufgaben (unterabgetastet aus insgesamt 2.285 programmgesteuert generierten Aufgaben), wobei unterschiedliche „Absichten“ beschreiben, ob die Aufgabe mit Dienst-, mobilen Daten- oder MMS-Problemen zusammenhängt. Wir bewerten den Telekommunikationsbereich vollständig mit 3 Wiederholungen pro Aufgabe und geben die Punktzahl unter Verwendung der pass@1-Bewertung als Durchschnitt der 3 Versuche an
    • In diesem Benchmark entscheidet das Ergebnis „Weltzustand“ darüber, ob der Agent erfolgreich war – beispielsweise ob die Handydaten des Benutzers funktionieren, nachdem der Agent die Aufgabe abgeschlossen hat
    • Die vollständige 𝜏²-Bench-Suite umfasst drei Ausführungsmodi mit unterschiedlichen Planungs- und Kommunikationsebenen in Ablationsstudien; Wir implementieren den „Standard“-Dual-Control-Modus mit vollständig simulierten und separaten Benutzer- und Assistentenagenten
    • Wir verwenden Qwen3 235B A22B 2507 (Non-reasoning) für den User-Agent-Simulator, um eine konsistente Checkpoint-Verfügbarkeit und vollständige Kontrolle über die Inferenzeinstellungen neben starker Basisintelligenz sicherzustellen
    • Wir wenden eine Einschränkung auf die Ausführung an, um die Anzahl der Schritte pro Aufgabenwiederholung auf maximal 100 zu beschränken

MATH-500

  • Hinweis: Aus dem Artificial Analysis Intelligence Index und unserer aktiven Berichterstattung entfernt.
  • Beschreibung: Eine 500 Aufgaben umfassende Teilmenge des MATH-Benchmarks, die Mathematik für High-School-Wettbewerbe in einer Reihe von Fächern und Schwierigkeitsgraden umfasst.
  • Datensatz: huggingface.co/datasets/HuggingFaceH4/MATH-500

AIME 2025 (American Invitational Mathematics Examination)

  • Hinweis: Aus unserer aktiven Berichterstattung ausgeschieden; nicht mehr Teil des Artificial Analysis Intelligence Index v4.3.2.
  • Beschreibung: Erweiterter Datensatz zur mathematischen Problemlösung aus der American Invitational Mathematics Examination 2025.
  • Datensatz: 2025 AIME I & 2025 AIME II
  • Wichtige Details:
    • Strenges numerisches Antwortformat (Ganzzahl 1–999)
    • Pass@1-Wertung mit 10 Wiederholungen pro Frage
    • Skriptbasierte Bewertung mit SymPy-Normalisierung + Gleichheitsprüfer LLM als Backup

MMLU-Pro (Multi-Task Language Understanding Benchmark, Pro version)

  • Hinweis: Wurde in Version 4.0 aus dem Intelligence Index entfernt. Aus unserer aktiven Berichterstattung ausgeschieden.
  • Beschreibung: Umfassende Bewertung fortgeschrittenen Wissens über Domänen hinweg, angepasst an die ursprüngliche MMLU.
  • Paper: https://arxiv.org/abs/2406.01574
  • Datensatz: https://huggingface.co/datasets/TIGER-Lab/MMLU-Pro
  • Wichtige Details:
    • Multiple-Choice-Format mit 10 Optionen
    • Regex-basierte Antwortextraktion mit pass@1-Bewertung (Eingabeaufforderung und Regex unten)

LiveCodeBench

Prompt-Vorlagen, Antwortextraktion und Evaluation

Multiple-Choice-Fragen (GPQA, MMLU-Pro)

Wir fordern Multi-Choice-Bewertungen mit der folgenden Anweisungsaufforderung an. Diese Eingabeaufforderung wurde unabhängig von Artificial Analysis entwickelt und anhand verschiedener Ablationsstudien sorgfältig validiert. Wir kommen zu dem Schluss, dass diese Eingabeaufforderung ein klarerer und daher gerechterer Ansatz ist als herkömmliche Multi-Choice-Bewertungsmethoden im Vervollständigungsstil oder andere von uns getestete Anweisungen.

GPQA verwendet vier Optionen (A–D). MMLU-Pro verwendet zehn Optionen (A–J); Wir verwenden dieselbe Struktur mit zusätzlichen Auswahlmöglichkeiten.

Answer the following multiple choice question. The last line of your response should be in the following format: 'Answer: A/B/C/D' (e.g. 'Answer: A').

{Question}

A) {A}
B) {B}
C) {C}
D) {D}
Answer the following multiple choice question. The last line of your response should be in the following format: 'Answer: A/B/C/D/E/F/G/H/I/J' (e.g. 'Answer: A').

{Question}

A) {A}
B) {B}
C) {C}
D) {D}
E) {E}
F) {F}
G) {G}
H) {H}
I) {I}
J) {J}

Regex zur Extraktion von Multiple-Choice-Antworten

Wir extrahieren Multiple-Choice-Antworten in mehreren Stufen, um unterschiedliche Antwortformate abzudecken. Bei Antworten mit einem einzelnen Buchstaben verwenden wir diesen direkt. Ansonsten suchen wir zuerst mit unserem primären Muster nach dem formalen Format "Answer: X", wobei optionale Markdown-Formatierung berücksichtigt wird:

Primäres Muster:

(?i)[\*\_]{0,2}Answer[\*\_]{0,2}\s*:[\s\*\_]{0,2}\s*([A-Z])(?![a-zA-Z0-9])

Wenn das primäre Muster fehlschlägt, versuchen wir nacheinander die folgenden Fallback-Muster, um verschiedene Antwortformate abzufangen:

  • LaTeX-Box-Notation (z. B. \boxed{A} oder \boxed{The answer is A})
    \boxed\{[^}]*([A-Z])[^}]*\}
  • Natürliche Sprache (z. B. "answer is B")
    answer is ([a-zA-Z])
  • Mit Klammern (z. B. "answer is (C")
    answer is \\(([a-zA-Z])
  • Auswahlformat (z. B. "D) some answer text")
    ([A-Z])\)\s*[^A-Z]*
  • Explizite Aussage (z. B. "E is the correct answer")
    ([A-Z])\s+is\s+the\s+correct\s+answer
  • Eigenständiger Brief am Ende der Antwort
    ([A-Z])\s*$
  • Buchstabe gefolgt von einem Punkt (z. B. "F.")
    ([A-Z])\s*\.
  • Buchstabe, gefolgt von einem Nicht-Wort-Zeichen
    ([A-Z])\s*[^\w]

Zur Selbstkorrektur der Antworten berücksichtigen wir immer die zuletzt gefundene Übereinstimmung.

LLM zur Gleichheitsprüfung

Für Auswertungen mit offenen Antworten (HLE, AA-LCR) verwenden wir einen Gleichheitsprüfer LLM, um festzustellen, ob die Antwort eines Modells semantisch äquivalent zur richtigen Antwort ist. Dieser Ansatz verwendet ein Sprachmodell, um zu beurteilen, ob zwei Antworten dieselbe Bedeutung haben, auch wenn sie unterschiedlich formuliert sind. Der Gleichheitsprüfer bewertet die semantische Äquivalenz, anstatt exakte Zeichenfolgenübereinstimmungen zu erfordern, was besonders wichtig für Fragen ist, bei denen mehrere gültige Formulierungen vorhanden sind.

HLE und AA-LCR teilen sich einen einzigen Gleichheitsprüfer, GPT-5.6 Luna (medium), der auf der Grundlage einer Validierung anhand menschlicher Beurteilung ausgewählt wird. Spezifische Eingabeaufforderungen für die Gleichheitsprüfung für jede Bewertung werden in den folgenden Abschnitten detailliert beschrieben.

HLE (Humanity's Last Exam)

Wir fordern HLE mit dem folgenden Text als Systemeingabeaufforderung auf, mit einem Unterschied zwischen Fragen mit exakter Antwort und Multiple-Choice-Fragen – diese Eingabeaufforderungen werden ohne Änderungen gegenüber der ursprünglichen Implementierung von Hendrycks et al. verwendet. Bei Modellen, die keine Systemaufforderung unterstützen, stellen wir die Systemaufforderung der Benutzeraufforderung voran.

System Prompt for Exact Answer Questions:

"Your response should be in the following format:
Explanation: {your explanation for your final answer}
Exact Answer: {your succinct, final answer}
Confidence: {your confidence score between 0% and 100% for your answer}"

System Prompt for Multiple Choice Questions:

"Your response should be in the following format:
Explanation: {your explanation for your answer choice}
Answer: {your chosen answer}
Confidence: {your confidence score between 0% and 100% for your answer}"

Prompt zur HLE-Gleichheitsprüfung

Wir verwenden die folgende Eingabeaufforderung auf GPT-5.6 Luna (medium), um zu überprüfen, ob die Antwort korrekt ist. Diese Eingabeaufforderung wird erneut ohne Änderungen gegenüber der ursprünglichen Implementierung von Hendrycks et al. verwendet.

Judge whether the following [response] to [question] is correct or not based on the precise and unambiguous [correct_answer] below.

[question]: {question}

[response]: {response}

Your judgement must be in the format and criteria specified below:

extracted_final_answer: The final exact answer extracted from the [response]. Put the extracted answer as 'None' if there is no exact, final answer to extract from the response.

[correct_answer]: {correct_answer}

reasoning: Explain why the extracted_final_answer is correct or incorrect based on [correct_answer], focusing only on if there are meaningful differences between [correct_answer] and the extracted_final_answer. Do not comment on any background to the problem, do not attempt to solve the problem, do not argue for any answer different than [correct_answer], focus only on whether the answers match.

correct: Answer 'yes' if extracted_final_answer matches the [correct_answer] given above, or is within a small margin of error for numerical problems. Answer 'no' otherwise, i.e. if there if there is any inconsistency, ambiguity, non-equivalency, or if the extracted answer is incorrect.


confidence: The extracted confidence score between 0|\%| and 100|\%| from [response]. Put 100 if there is no confidence score available.

Prompt zur LCR-Gleichheitsprüfung 

Assess whether the following CANDIDATE ANSWER is CORRECT or INCORRECT.
For the CANDIDATE ANSWER to be correct, it must be consistent with the OFFICIAL ANSWER.

The question, for reference only: {question}
The OFFICIAL ANSWER: {official_answer}
CANDIDATE ANSWER TO ASSESS: {candidate_answer}

Reply only with CORRECT or INCORRECT.

Mathematische Fragen (AIME 2025)

Wir fordern AIME mit der folgenden Anweisungsaufforderung auf:

Solve the following math problem step by step. Put your answer inside \\boxed{{}}.

{Question}

Remember to put your answer inside \\boxed{{}}.

Prompt zur mathematischen Gleichheitsprüfung

Wie oben beschrieben ergänzen wir unsere skriptbasierte Benotung durch einen Sprachmodell-Gleichheitsprüfer. Wir verwenden die folgende Eingabeaufforderung mit Llama 3.3 70B, um zu überprüfen, ob zwei Antworten gleichwertig sind. Diese Eingabeaufforderung wurde von OpenAI entwickelt und in deren Simple-Evals-Repository veröffentlicht.

Look at the following two expressions (answers to a math problem) and judge whether they are equivalent. Only perform trivial simplifications

Examples:

  Expression 1: $2x+3$
  Expression 2: $3+2x$

Yes

  Expression 1: 3/2
  Expression 2: 1.5

Yes

  Expression 1: $x^2+2x+1$
  Expression 2: $y^2+2y+1$

No

  Expression 1: $x^2+2x+1$
  Expression 2: $(x+1)^2$

Yes

  Expression 1: 3245/5
  Expression 2: 649

No
(these are actually equal, don't mark them equivalent if you need to do nontrivial simplifications)

  Expression 1: 2/(-3)
  Expression 2: -2/3

Yes
(trivial simplifications are allowed)

  Expression 1: 72 degrees
  Expression 2: 72

Yes
(give benefit of the doubt to units)

  Expression 1: 64
  Expression 2: 64 square feet

Yes
(give benefit of the doubt to units)

---

YOUR TASK


Respond with only "Yes" or "No" (without quotes). Do not include a rationale.

  Expression 1: %(expression1)s
  Expression 2: %(expression2)s

Aufgaben zur Codegenerierung

SciCode

Wir rufen SciCode mit der folgenden Eingabeaufforderung auf, die ohne Änderungen gegenüber der ursprünglichen Implementierung der „Science Annotated Background“-Eingabeaufforderung von Tian et al. verwendet wird.

PROBLEM DESCRIPTION:
You will be provided with problem steps along with background knowledge necessary for solving the problem. Your task will be to develop a Python solution focused on the next step of the problem-solving process.

PROBLEM STEPS AND FUNCTION CODE:
Here, you'll find the Python code for the initial steps of the problem-solving process. This code is integral to building the solution.

{problem_steps_str}

NEXT STEP - PROBLEM STEP AND FUNCTION HEADER:
This part will describe the next step in the problem-solving process. A function header will be provided, and your task is to develop the Python code for this next step based on the provided description and function header.

{next_step_str}

DEPENDENCIES:
Use only the following dependencies in your solution. Do not include these dependencies at the beginning of your code.

{dependencies}

RESPONSE GUIDELINES:
Now, based on the instructions and information provided above, write the complete and executable Python program for the next step in a single block.
Your response should focus exclusively on implementing the solution for the next step, adhering closely to the specified function header and the context provided by the initial steps.
Your response should NOT include the dependencies and functions of all previous steps. If your next step function calls functions from previous steps, please make sure it uses the headers provided without modification.
DO NOT generate EXAMPLE USAGE OR TEST CODE in your response. Please make sure your response python code in format of ```python```.

LiveCodeBench

Wir rufen LiveCodeBench mit der folgenden Eingabeaufforderung auf, die ohne Änderungen gegenüber der ursprünglichen Implementierung der LiveCodeBench-Eingabeaufforderung durch das ursprüngliche Team verwendet wird. Wir weisen jedoch darauf hin, dass wir nicht die benutzerdefinierten Systemaufforderungen anwenden, die das LiveCodeBench-Team verwendet – wir verwenden weder deren generische Systemaufforderung noch ihre benutzerdefinierten Systemaufforderungen für bestimmte Modelle.

Questions with starter code:

### Question:
{question.question_content}

### Format: You will use the following starter code to write the solution to the problem and enclose your code within delimiters.
```python
{question.starter_code}
```

### Answer: (use the provided format with backticks)


Questions without starter code:

### Question:
{question.question_content}

### Format: Read the inputs from stdin solve the problem and write the answer to stdout (do not directly test on the sample inputs). Enclose your code within delimiters as follows. Ensure that when the python program runs, it reads the inputs, runs the algorithm and writes output to STDOUT.
```python
# YOUR CODE HERE
```

### Answer: (use the provided format with backticks

Regex zur Codeextraktion

Wir extrahieren den Code aus der Antwort mit dem folgenden regulären Ausdruck:

(?<=```python\n)((?:\n|.)+?)(?=\n```)

Versionsverlauf

Version 4.3.2

September 2026 bis heute

  • GDPval-AA v2.1: Die Elo-Skala ist nun bei DeepSeek V4.1 Flash (max) mit 1600 verankert, und die Werte werden mit einem Crowd-BT-Modell angepasst.
  • AA-Briefcase v1.1: Der Anker bleibt GPT-5.5 (medium) bei 1000, aber jeder Bereich für paarweise Vergleiche wird nun mit einem Crowd-BT-Modell angepasst.

Version 4.3.1

September 2026

  • Die paarweise Jury wurde auf aktuelle Modellversionen aktualisiert: AA-Briefcase und GDPval-AA v2. Paarweise Vergleiche werden jetzt mit Claude Opus 5, GPT-5.6 Sol und Gemini 3.8 Flash. Die Bewertungstafeln für die Rubriken bleiben unverändert.

Version 4.3

September 2026

  • 𝜏³-Banking durch AutomationBench-AA (5 %) in der Kategorie „Agenten“ ersetzt
  • Terminal-Bench 2.1 durch Terminal-Bench 4.0 ersetzt (66 Aufgaben, mini-swe-agent-Ausführungsumgebung)
  • Aktualisierung der GDP.pdf-Bildverarbeitung: Verbesserte Verarbeitung von Bildern, die die API-Einschränkungen überschreiten, wobei die Größenänderung jetzt auf einen breiteren Bereich von Fällen angewendet wird, um sicherzustellen, dass Bilder an das Modell übergeben werden können
  • Gewichtungen: GDPval-AA v2 (10 %), AA-Briefcase (15 %), AutomationBench-AA (5 %), Terminal-Bench 4.0 (10 %), SciCode (10 %), AA-LCR (5 %), AA-Omniscience Genauigkeit (10 %) und Nicht-Halluzination (5 %), HLE (10 %), GDP.pdf (10 %), CritPt (10 %)

Version 4.2

September 2026

  • AA-Briefcase (15 %) zur Agentenkategorie hinzugefügt
  • GDP.pdf (10 %) zur Kategorie „Allgemein“ hinzugefügt
  • GPQA Diamond wurde aus dem Intelligence Index entfernt
  • AA-LCR auf v1.1 aktualisiert
  • SciCode-Bewertungszeitlimit von 60 auf 300 Sekunden erhöht und Skriptausführung isoliert, damit langsamer, aber korrekter Code nicht mehr als fehlgeschlagen bewertet wird; als v1.0.1 neu bewertet.
  • Neu ausbalancierte Gewichtungen: GDPval-AA v2 (10 %), 𝜏³-Banking (5 %), AA-Briefcase (15 %), Terminal-Bench 2.1 (10 %), SciCode (10 %), AA-LCR (5 %), AA-Omniscience Genauigkeit (10 %) und Nicht-Halluzination (5 %), HLE (10 %), GDP.pdf (10 %), CritPt (10 %)

Version 4.1.1

August 2026 – September 2026

  • 𝜏³-Banking wurde in den Upstream-Datensatz und Grader tau2-bench v1.0.1 verschoben
  • Bewertungsmodell für HLE, AA-LCR und AA-Omniscience auf GPT-5.6 Luna (medium) aktualisiert; ersetzt jeweils GPT-4o (Aug '24), Qwen3 235B A22B 2507 Non-Reasoning und Gemini 3 Flash Preview (Reasoning)

Version 4.1

Juni 2026 – August 2026

  • GDPval-AA auf GDPval-AA v2 aktualisiert: Sandbox mit neuen und erweiterten Abhängigkeiten, Elo-Werte neu auf die Leistung menschlicher Fachleute bei 1000 kalibriert, ein Panel aus drei führenden LLM-Juroren und ein auf 250 Runden erhöhtes Limit mit der Möglichkeit, vorzeitig abzubrechen
  • Terminal-Bench Hard durch Terminal-Bench 2.1 ersetzt (höhere Zuglimits, keine Token-Limits)
  • 𝜏²-Bench Telecom durch 𝜏³-Banking ersetzt
  • IFBench wurde aus dem Intelligence Index entfernt (wir führen es weiterhin bei neuen Modellversionen aus)
  • Die Gewichtung der Kategorien wurde angepasst, um Agentenaufgaben stärker hervorzuheben: Agenten (34 %), Codierung (24 %), Wissenschaftliches Denken (24 %), Allgemein (18 %), mit AA-Omniscience, aufgeteilt in die Komponenten Genauigkeit (8 %) und Nicht-Halluzination (4 %).
  • Verbesserte Token- und Kostenmetriken, um die tatsächlichen Kosten besser widerzuspiegeln, einschließlich Cache-Trefferraten und Cache-Token-Preisen

Version 4.0.4

März 2026 – Juni 2026

  • Das Grader-Modell für GDPval-AA wurde auf Gemini 3.1 Pro Preview aktualisiert, nachdem das vorherige Grader-Modell Gemini 3 Pro Preview nicht mehr unterstützt wurde

Version 4.0.3

Februar 2026 – März 2026

  • Das Grader-Modell für Omniscience wurde auf Gemini 3 Flash Preview (Reasoning) aktualisiert, nachdem das vorherige Grader-Modell Gemini 2.5 Flash (09-2025) (Reasoning) veraltet war

Version 4.0.2

Januar 2026 – Februar 2026

  • Neu verankerte GDPval-AA Elo-Werte im Intelligence Index nach einer Überarbeitung, um die Robustheit gegenüber seltenen Code-Sandbox-Fehlern zu verbessern

Version 4.0.1

Januar 2026

  • Die harte Terminal-Bench-Bewertung wurde auf 44 Aufgaben verfeinert, wobei eine kleine Anzahl von Aufgaben aufgrund externer Abhängigkeitsprobleme im Originaldatensatz beim angehefteten Commit entfernt wurde

Version 4.0

Januar 2026

  • GDPval-AA hinzugefügt (praxisbezogene Wissensarbeit)
  • AA-Omniscience (Wissen und Halluzination) hinzugefügt
  • CritPt (physikalische Argumentation) hinzugefügt
  • MMLU-Pro, LiveCodeBench, AIME 2025 aus Intelligence Index entfernt
  • Neue kategoriebasierte Gewichtungsstruktur: Agenten (25 %), Kodierung (25 %), Allgemeines (25 %), Wissenschaftliches Denken (25 %).

Version 3.0

2. September 2025 – Dezember 2025

  • Terminal-Bench Hard (Agenten-Workflows) hinzugefügt
  • 𝜏²-Bench Telecom hinzugefügt (Agenten-Workflows)
  • MMLU-Pro und LiveCodeBench im Intelligence Index enthalten
  • Aktualisierte Gewichtungen

Version 2.2

6. August 2025 – 1. September 2025

  • Hinzugefügt: Artificial Analysis Long Context Reasoning
  • Aktualisierte Gewichtungen

Version 2.1

5. August 2025 – 6. August 2025

  • IFBench hinzugefügt
  • AIME 2025 hinzugefügt
  • MATH-500 entfernt
  • AIME 2024 entfernt
  • Aktualisierte Gewichtungen

Version 2.0

11. Februar 2025 – 4. August 2025

Version 1.0—1.3

Januar 2024 – 10. Februar 2025