Maschinelle Übersetzung, nicht von einem Muttersprachler geprüft. Englisch ist die maßgebliche Fassung.

Empfängervertrauen und SeefahrtAuf GitHub bearbeitenQuelle: docs/BENCH.md

kshana-bench

Ein offener Satz von Aufgaben, Aufteilungen und Metriken für die Erkennung von GNSS-Störungen und für timing-holdover. Die Spezifikation ist bench/SPEC.md (Version 2.0.0; Lizenz von Text und Manifesten: CC-BY-4.0 / CC0 vorgeschlagen, Entscheidung des Eigentümers steht aus). Die Prüfung der Datensatzlizenzen ist bench/LICENCES.md. Die Zielwerte der Basislinien wurden vor dem ersten bewerteten Lauf in xval/bench/PREREGISTRATION.md und, für 2.0.0, in PREREGISTRATION-v2.md festgelegt, und ihre Ergebnisse stehen in xval/bench/RESULTS-v2.md.

Urteile, wie dort festgehalten: Die Zielwerte des Bewerters, C1 bis C3 und D2 sind erreicht; A2 ist NOT MET (agc_k_sigma AUC 0,766 gegenüber mindestens 0,80 auf der Testaufteilung), D1 ist NOT MET (größte Lücke 0,0301) und Aufgabe (b) R1 ist NOT MET (übernommen, nicht neu ausgeführt). Kein Zielwert wird gelockert.

Was es ist: eine Möglichkeit, Methoden auf denselben Daten mit demselben Metrikcode zu vergleichen. Was es nicht ist: eine Rangliste von Produkten, eine Zulassung oder ein Beleg dafür, dass eine Methode im Feld funktioniert. Jede Bewertung ist MODELLED, und eine Bewertung beschreibt ein Protokoll oder einen Korpus, nie ein Produkt. Kshana-Ergebnisse sind beratend.

Die eingebauten Basislinien der Aufgabe D von kshana-bench (die Optimismuslücke) auf der Testaufteilung, aus einem echten Lauf der Engine v0.40.0 (`kshana bench baseline`). Jedes Balkenpaar ist die Fläche unter der ROC-Kurve für die Fälle innerhalb der Verteilung und für die verschobenen Fälle; die Lücke dazwischen ist die Optimismuslücke, gemessen an einer Toleranz von 0,05. fused-max-z: 0,998 und 0,983 (Lücke 0,015); sqm-imbalance: 0,882 und 0,882 (Lücke 0,001); agc-excess: 0,848 und 0,819 (Lücke 0,030); raim-parity: 0,682 und 0,672 (Lücke 0,010); energy-cn0-drop: 0,595 und 0,565 (Lücke 0,030). Die Labels sind Labels eines generativen Modells eines synthetischen Korpus, nie Felddaten: MODELLED. Beratend: modelliert oder gegen genannte Referenzen gemessen, keine Zulassung, keine Zertifizierung und keine Konformitätserklärung. Eine Bewertung beschreibt ein Protokoll oder einen Korpus, nie ein Produkt.Die eingebauten Basislinien der Aufgabe D von kshana-bench (die Optimismuslücke) auf der Testaufteilung, aus einem echten Lauf der Engine v0.40.0 (`kshana bench baseline`). Jedes Balkenpaar ist die Fläche unter der ROC-Kurve für die Fälle innerhalb der Verteilung und für die verschobenen Fälle; die Lücke dazwischen ist die Optimismuslücke, gemessen an einer Toleranz von 0,05. fused-max-z: 0,998 und 0,983 (Lücke 0,015); sqm-imbalance: 0,882 und 0,882 (Lücke 0,001); agc-excess: 0,848 und 0,819 (Lücke 0,030); raim-parity: 0,682 und 0,672 (Lücke 0,010); energy-cn0-drop: 0,595 und 0,565 (Lücke 0,030). Die Labels sind Labels eines generativen Modells eines synthetischen Korpus, nie Felddaten: MODELLED. Beratend: modelliert oder gegen genannte Referenzen gemessen, keine Zulassung, keine Zertifizierung und keine Konformitätserklärung. Eine Bewertung beschreibt ein Protokoll oder einen Korpus, nie ein Produkt.

Aufgaben#

Aufgabe Einheit Daten Primäre Metrik
(a) Erkennung auf Empfängerprotokollen eine Epoche eines JammerTest-2024-Protokolls abgerufen durch scripts/fetch_jammertest2024.sh (GPL-3.0+, nie eingebunden) AUC
(b) Erkennung auf IQ ein bewertetes Fenster einer Szene synthetisches Kshana-Szenenrezept; TEXBAT nur als Referenz AUC je Alarmart
(c) Vorhersage von timing-holdover (Satellit, Ursprung) IGS-Uhren bei 300 s (eingecheckter Auszug, festgelegter Hash) RMSE bei 3600 s
(d) Optimismuslücke außerhalb der Verteilung ein synthetischer Fall Korpus impairment-eval, innerhalb und außerhalb der Verteilung AUC außerhalb und die Lücke

Befehle#

kshana bench spec
kshana bench cases --task d --split test --scale 0.5 --out cases/        # cases.json + truth.json
kshana bench cases --task c --split test --out cases/
kshana bench truth --task a --data <extracted JammerTest 2024> --split test --out truth.json
kshana bench score --truth truth.json --predictions my-scores.json --out my.result.json
kshana bench baseline --task d --split test --out results/               # the built-in baselines
kshana bench validate results/*.result.json
kshana bench leaderboard results/ --out bench/site/index.html
kshana bench seal --task d --seed-file secret.txt --new                  # owner: make a seed, print only its hash
kshana bench reveal-check --task d --seed-file secret.txt --commitment <hex>
kshana bench manifest --task a --data <extracted dir> --out manifest.json
kshana bench verify-manifest manifest.json --root <dir>

Eine Einreichung ist eine Datei (kshana-bench-predictions/1): scores (eine Zahl je Fall-ID; höher heißt wahrscheinlicher beeinträchtigt) für die Aufgaben a, b und d oder predictions (die Phasenänderung in ns bei jedem Horizont) für Aufgabe c. Eine Ergebnisdatei (kshana-bench-result/1) nennt die Spezifikationsversion, die Aufteilung, den SHA-256 der Wahrheit und der Vorhersagen sowie die Metriken. Ergebnisse verschiedener Hauptversionen der Spezifikation kommen nie in eine Tabelle.

Ehrliche Grenzen#

  • Die zurückgehaltenen Datensätze mit echten Daten (a und c) sind öffentlich, weil jeder die Daten herunterladen kann. Sie schützen davor, eine Aufteilung nach Kenntnis der Bewertungen zu wählen, nicht davor, auf diesen Ordnern abzustimmen. Der versiegelte zurückgehaltene Datensatz der Aufgabe (d) ist ein Commit-and-Reveal-Verfahren: Der Eigentümer legt nur den Hash in bench/holdout/COMMITMENTS.json fest und behält den Startwert (bisher ist keiner versiegelt).
  • Die Wahrheit der Aufgabe (a) sind die geplanten Angriffsfenster der Ereignisprotokolle in Minutenauflösung, daher ist eine Erkennungswahrscheinlichkeit eine untere Schranke; die Metriken auf Ereignisebene (Latenz, verpasste Alarme, Fehlalarme) kommen mit dem Jammertest-Bewerter von kshana jammertest score.
  • Die IQ-Basislinie der Aufgabe (b) wird aus docs/design/DETECTION-ROC.md übernommen und für v1 nicht neu ausgeführt.
  • Der Korpus der Aufgabe (d) ist eine Trennbarkeits- und Pipeline-Prüfung; eine AUC darauf ist eine AUC über modellabgeleitete Labels.