Vorlagen werden geladen …
visibility Lesemodus: Konfigurationen, Prompt-Bausteine und Formate lassen sich ansehen und hier im Browser ausprobieren, gespeichert wird nichts, weder in diesem Browser noch auf dem Controller. Laufen lassen sich die gespeicherten Konfigurationen in der Test-Suite.
tune Auswahl & Export expand_more
account_tree Agenten-Pipeline
Verfügbare Bausteine · in die Pipeline ziehen oder zum Hinzufügen klicken
Pipeline
rule Vorprüfungen
edit_note Prompt Bausteine
An: Läufe der Test-Suite mit dieser Konfiguration erzwingen das gewählte JSON-Schema per Guided Decoding. Aus: Das Modell antwortet frei, es gelten nur die Formatvorgaben des Prompts (z. B. ein Ausgabe-Baustein).
tune Benchmark-Einrichtung
1. Testdatensatz
Akzeptierte Datensatzformate
JSON: ein Array (oder {"items": [...]})
aus Objekten mit text und optionalem label.
Hassrede ist die positive Klasse. Akzeptierte Label-Werte:
true/false, 1/0, wahr/falsch, ja/nein,
hate/none, hateful, offensive, toxic,
off/not. Zeilen mit anderen Werten gelten als ohne Label und werden gemeldet.
[
{ "text": "Du bist so ein Idiot!", "label": true },
{ "text": "Danke fuer deine Hilfe.", "label": false }
]
CSV: Kopfzeile mit einer Spalte text
und optionaler Spalte label.
text,label "Du bist so ein Idiot!",1 "Danke fuer deine Hilfe.",0
Optional: Thread-Felder.
Zusätzlich zu text und label darf jeder Eintrag
ts (Zeitstempel), author (wer geschrieben hat) und
thread (zu welcher Unterhaltung der Beitrag gehört) führen; in einer CSV
sind das gleichnamige Spalten. Alle drei sind freiwillig, ein Datensatz ohne sie
läuft unverändert. Gelesen werden sie vom Shitstorm-Barometer: der
Zeitstempel ist die Uhr für die Aktualisierung in Zeitintervallen, der Autor zählt,
wie viele verschiedene Personen die Eskalation tragen. Ohne Zeitstempel läuft nur
die Kurve „bei jedem neuen Kommentar“, und der Testbericht sagt das auch.
Erlaubte Schreibweisen der Zeit: ISO (2026-03-14T18:02:00),
14.03.2026 18:02 oder eine Unix-Zeit. Der Knopf
„Beispiel-Thread verwenden“ lädt genau so einen Datensatz.
[
{ "text": "Diskutiert gern sachlich.", "label": false,
"ts": "2026-03-14T18:02:00", "author": "moderator", "thread": "t-1042" },
{ "text": "Halt einfach die Klappe, du Wichtigtuerin.", "label": true,
"ts": "2026-03-14T19:16:00", "author": "bergwind", "thread": "t-1042" }
]
text,label,ts,author,thread "Diskutiert gern sachlich.",0,2026-03-14T18:02:00,moderator,t-1042 "Halt einfach die Klappe, du Wichtigtuerin.",1,2026-03-14T19:16:00,bergwind,t-1042
Angaben zum Datensatz
Sie gehen in den Export „Datenschema 1.0“ im Ergebnis-Dashboard, eine Datei nach dem Datenschema des Wissenspools. Nichts davon wird gesendet. Beim Laden eines Datensatzes schlägt die Seite Werte aus dem Dateinamen vor; die Community ist für jeden Lauf nötig, die Kennung für eine Grid-Suche.
2. Zu vergleichende Läufe
Jede Karte ist eine gespeicherte Konfiguration. Prompt, Vorprüfungen, Urteilsfindung, Modell und Sampling kommen aus ihr (Name anklicken, um Agenten-Pipeline, Kontextstufe und zusammengesetzten Prompt dahinter zu sehen); ihr ausführender Baustein entscheidet, ob die Anfrage an Standard-Provider oder an einen Job auf NHR@FAU Alex (SSH) geht (beides eingerichtet unter Infrastruktur). Jede Konfiguration höchstens einmal: Varianten einer Konfiguration vergleicht die Grid-Suche.
Automatisiertes Testen: eine oder mehrere gespeicherte Konfigurationen wählen und dazu, was gegen sie variiert wird. Jede Kombination wird ein Lauf und läuft nacheinander ab. Was keine Dimension variiert, kommt aus der Konfiguration selbst: ihr ausführender Baustein bestimmt Backend, Modell und Sampling, ihr zusammengesetzter Prompt, ihre Vorprüfungen und ihre Urteilsfindung gelten wie in einem manuellen Lauf.
Namen anklicken, um Prompt und Pipeline dahinter zu sehen. Eine Konfiguration, deren ausführender Baustein auf Alex läuft, fragt den Cluster erst ab, wenn sie hier angehakt wird.
Eine Dimension, die aus ist, nimmt den Wert der Konfiguration. Eine Dimension, die an ist, zählt ihre angehakten Werte durch.
3. Ausführung
monitoring Ergebnis-Dashboard
Hardware
Die Hardware der Alex-Jobs, auf denen dieser Benchmark lief, beim Start vom Knoten des Jobs erfasst. Läufe über Standard-Provider liefern keine Hardware-Daten.
Lauf-Setup
Womit jeder Lauf gestartet wurde: Konfiguration, Ziel, Denkmodus, Strukturierte Ausgabe und Sampling-Parameter.
| Lauf | Konfiguration | Backend | Job | Modell | Denkmodus | Strukturierte Ausgabe | Urteilsfindung | Shitstorm-Barometer | Few-Shot | temp | top_p | seed |
|---|
Latenz pro Antwort
Durchschnittliche Millisekunden pro Eintrag; der Strich markiert das 95. Perzentil.
Generierungsgeschwindigkeit
Completion-Token pro Sekunde, über alle Einträge aggregiert.
GPU-Auslastung während des Benchmarks
Auslastung eingefärbt nach dem aktiven Lauf; die graue Linie ist der Speicher in Prozent. Daten vom Knoten des Alex-Jobs, alle paar Sekunden abgetastet; Läufe über Standard-Provider liefern keine GPU-Daten.
Shitstorm-Barometer
Der Barometerwert über den Thread: eine Kurve je Aktualisierungsregel (bei jedem Kommentar, in festen Zeitintervallen) und je Wertquelle (rechnerisch aus den Einzelurteilen, LLM-Einschätzung des Fensters). Beide laufen über dieselbe X-Achse, den Eintrag im Datensatz, und sind damit direkt vergleichbar. Die gestrichelte Linie ist die Warnschwelle.
S-Score
Mittelwert aus normalisiertem F2 und MCC (0 bis 1, höher ist besser).
Geschwindigkeit & Hardware-Auslastung pro Lauf
Reaktionsgeschwindigkeit des Dienstes pro Lauf (Latenz-Perzentile über alle Antworten) und wie stark die GPUs während des Laufs gearbeitet haben. GPU-Werte gibt es nur für Läufe auf NHR@FAU Alex (SSH); die übrigen zeigen „–“.
| Lauf | Latenz Ø | Median | p95 | max | Gen.-Tempo | Antworten/s | GPU-Last Ø | Last max | GPU-Speicher Ø | Speicher max |
|---|
Qualitätsmetriken
| Lauf | n | Accuracy | Precision | Recall | F1 | F2 | MCC | S-Score | Fehler |
|---|
Konfusionsmatrizen
Pro Lauf: TP/FN obere Zeile (tatsächlich Hassrede), FP/TN untere Zeile (tatsächlich keine). Spalten: vorhergesagt Hassrede / keine.
Ergebnisse pro Eintrag (erste 100)
receipt_long Laufprotokoll
Jeder Eintrag von , Schritt für Schritt: welche Vorprüfungs-Regeln zutrafen, ob die Nachricht überhaupt ans Modell ging oder davor blockiert wurde, was zurückkam und wie lange jeder Schritt dauerte. Die Schritte werden geschrieben, während sie passieren; nichts wird nachträglich rekonstruiert, und Einstellungen, die die Test-Suite nur speichert, sind als solche benannt.
Womit dieser Lauf gestartet wurde
Shitstorm-Barometer
Was das Barometer in diesem Lauf wirklich gemessen hat: je Aktualisierungsregel und je Wertquelle eine Kurve, jeder Messpunkt mit seinem Fenster, seinen drei Frühindikatoren und seiner Stufe.
Anfragen
Eine Zeile pro infer/batch-Anfrage: wie viele Einträge
sie trug, wie viele davon bereits eine Regel entschieden hatte und wie lange der
Round-Trip dauerte.
Einträge
history Testverlauf
Jeder abgeschlossene Benchmark landet hier (neueste zuerst, die letzten 20, in diesem Browser gespeichert). Einträge sind eine reine Ansicht dessen, was getestet wurde; Konfiguration laden macht das ganze Setup eines Eintrags, also Läufe, Parameter und (bei kleinen Datensätzen) den Datensatz selbst, wieder zu den aktuellen Einstellungen der Test-Suite.