Benchmarks und bekannte Grenzen

Layas Ergebnisse hängen vom Checkpoint, der Aufgabe, der Frageformulierung, der Optionsanzahl und der Hardware ab. Nutze die vollständigen Benchmark-Tabellen, um einen vergleichbaren Lauf zu finden, bevor du einen Checkpoint oder einen Konfidenz-Schwellenwert wählst. Das Forschungsverzeichnis enthält die Skripte und Ergebnisdateien hinter den Haupttabellen.

Die relevante Messung finden

Die veröffentlichten Jev-Zahlen neben den ursprünglichen Laya-Suiten stammen aus Drittstudien mit anderen Prompts und Stichprobengrößen. Sie sind nützlicher Kontext, aber kein kontrollierter Direktvergleich. Siehe die Vergleichsnotizen in research/README.md.

Lies die Genauigkeit zusammen mit der Baseline und dem Daten-Split. Zum Beispiel meldet der Typed-Decisions- Benchmark 0.766 Genauigkeit für den feinabgestimmten Checkpoint, während beide Basis-Checkpoints unter seiner Majority-Class-Baseline von 0.461 liegen. Dieses Ergebnis stützt Fine-Tuning für eine ähnliche Aufgabe; es belegt keine 0.766 Genauigkeit für einen untrainierten Checkpoint oder eine neue Domäne.

Lies die Konfidenz getrennt von der Genauigkeit. Der Expected Calibration Error (ECE) misst, wie gut gemeldete Wahrscheinlichkeiten mit der beobachteten Korrektheit übereinstimmen; niedriger ist besser. Die ursprünglichen ECE- und Mean-Confidence-Spalten des 51-Sprachen-Sweeps stammen aus der Zeit vor dem Temperatur-Clamp in #42. Seine Genauigkeits- spalten gelten weiterhin, aber nutze den geclampten Neulauf in research/results/, wenn du aktuelle Konfidenzwerte vergleichst. Selbst ein niedrigerer ECE auf einer Suite legt keinen sicheren Schwellenwert für eine andere Aufgabe oder Optionsanzahl fest.

Grenzen, die du an deinen eigenen Daten prüfen solltest

• Sprach-Routing: Der englische Checkpoint kann auf Text selbstsicher sein, den er außerhalb des Englischen schlecht verarbeitet. Nutze Router für gemischtsprachige Eingaben und prüfe Routing-Entscheidungen für die Sprachen, die du bedienst. Der mehrsprachige Checkpoint schneidet auch auf den englischen MASSIVE- und XNLI-Slices schlechter ab als der englische Checkpoint.
• Viele Optionen: Choice-Beschreibungen teilen sich ein festes Token-Budget. Der 77-Label-Banking77-Lauf schneidet mit dem Standardbudget schlecht ab. Halte eine einzelne choice-Frage bei etwa 20 Optionen, oder evaluiere eine Shortlist und ein größeres Head-Budget an deinen eigenen Labels.
• Kalibrierung: Beide Basis-Checkpoints sind auf den veröffentlichten Suiten im Auslieferungszustand überkonfident, während eine separate Routing-Aufgabe unterkonfident war. Fitte und evaluiere Temperaturen an separaten, zurückgehaltenen Beispielen aus deinem Workflow, bevor du ein Konfidenz-Gate nutzt.
• Aufgabenübertrag: Zurückgehaltene Moderation ist im Anwendungs-Benchmark schwach, und ordinales score ist das schwächste Primitiv in den berichteten englischen Suiten. Der mehrsprachige Checkpoint hat zudem eine gemessene Verzerrung gegen die erste score-Stufe. Teste den tatsächlichen Fragetyp und die Datenverteilung, die du bedienen willst.
• Formulierung und Reihenfolge: Die Optionsreihenfolge kann eine choice-Antwort ändern. Boolesche choice-Labels und verneinte Anfragen sind in dokumentierten Beispielen ebenfalls fehlgeschlagen; noul kann seinen Options- labels statt dem Zustand folgen. Prüfe alternative Optionsreihenfolgen und Formulierungen, besonders wenn eine falsche Entscheidung teuer ist.
• Lange Dokumente: Der mehrsprachige Encoder kann bis zu 8.192 Token lesen, wenn er für dieses Limit konfiguriert ist, aber der Long-Context-Benchmark meldet weniger zuverlässige Antworten jenseits von etwa 4.000 Token vorangehenden Textes. Miss die Genauigkeit bei den Längen, die du im Einsatz erwartest.
• Latenz: Die T4-Zahlen sagen weder CPU- noch Kaltladezeit voraus. Miss warme und kalte Aufrufe mit deinem eigenen Checkpoint, Gerät, deinen Eingabelängen und deiner Fragenanzahl.

Der Abschnitt „Honest limits“ im README enthält Beispiele und aktuelle Workarounds. Die Benchmark-Tabellen geben den Datensatz und die Hardware hinter jeder der obigen Grenzen an.

Ein Ergebnis reproduzieren oder erweitern

Beginne mit der Skript- und Ergebnisübersicht und dem Lauf-Index oben in BENCHMARKS.md. research/scripts/bench_local.py führt den 51-Sprachen-CPU-Sweep aus, bench_apps.py deckt Anwendungs-Workflows ab, und bench_latency.py misst Routing- und Inferenzgeschwindigkeit. Das T4-Notebook wird aus research/scripts/build_benchmark_nb.py erzeugt; ändere den Generator, wenn du diesen Benchmark änderst.

Für ein neues Deployment halte einen zurückgehaltenen Satz mit denselben Zuständen, Fragen und erwarteten Antworten für jeden Checkpoint bereit, den du vergleichst. Notiere die Checkpoint-Revision, Laya- und Bibliotheksversionen, Gerät, Fragenanzahl, Optionsanzahl und Token-Budget bei jedem Lauf. Nimm eine einfache Baseline für die Genauigkeit auf und berichte die Latenz nach dem Warm-up sowie die Erstladezeit. So wird dein Ergebnis mit den veröffentlichten Läufen vergleichbar, und du kannst es nach einem Upgrade erneut prüfen.