FAQ

Rankings werden aus Datenpipelines und dokumentierter Methodik erzeugt—nicht aus Marketingaussagen einzelner Anbieter.

Öffentliche, glaubwürdige Rankings erfordern konsistente Snapshots in src/data/db/site.sqlite sowie Dokumentation von Tasks, Gewichten, Daten und Reproduzierbarkeit in der Methodik.

Statisches HTML begünstigt SEO, Time-to-First-Byte und globales CDN-Caching. Rankings können täglich oder wöchentlich per CI-gesteuertem Build aktualisiert werden.

Live-Abfragen können Read-only-Edge-APIs neben statischen Snapshots und Quellenangaben zur Auditierbarkeit nutzen.

Der Pfad außerhalb des Locale-Präfix bleibt erhalten (z. B. /zh/model/ ↔ /en/model/) für paralleles Lesen.

Lange Abschnitte ohne Übersetzung können vorübergehend Englisch oder eine andere Defaultsprache spiegeln—schrittweise Lokalisierung.

Composite fassen Metriken nach Normalisierung und Gewichtung zusammen—hilfreich für Überblick, allein unzureichend für schwache Teilaufgaben. In Produktion sollten pro Task Scores oder Unter-Ränge veröffentlicht werden, wo sinnvoll.

Bei gemischten öffentlichen Benchmarks Versionen und Umgang mit fehlenden Zellen angeben.

Modell- und Agenten-Boards betonen Fähigkeit oder Task-Erfolg; GitHub-Trends OSS-Aktivität—ergänzend.

Viele Stars bedeuten nicht State-of-the-Art; proprietäre oder nicht auf GitHub gehostete Arbeit ist von Trendstatistiken ausgeschlossen.

Typischer Ablauf: Evaluatoren in CI ausführen, Boards/Datasets über die Daten-Pipeline in src/data/db/site.sqlite schreiben, Astro-Build auslösen, statisches Output deployen.

Object-Storage-Snapshots brauchen URLs und Prüfsummen auf der Quellen-Seite.

Externe Links öffnen in neuem Tab mit noopener/noreferrer. Vertrauenswürdigkeit und Datenschutz der Zielseiten liegen beim Besucher.

Es gelten Daten- und Code-Lizenzen vorgelagert; bei Nachveröffentlichung Links zu Methodik und Quellen sowie das Datums angeben.