Jenseits der Bestenliste: Benchmarking von LLMs an einer echten Sicherheitsaufgabe

Bei den schwierigsten Problemen – abstraktes visuelles Denken wie ARC-AGI-2, Mathematik auf Forschungsniveau wie FrontierMath oder fachübergreifende Expertenfragen wie Humanity's Last Exam – ist die öffentliche Bestenliste ein vernünftiger Anhaltspunkt: Man wählt das bestplatzierte Modell und erhält wahrscheinlich das beste Ergebnis.

Bei einfachen Problemen, wie Textklassifizierung oder Entitätsextraktion, reicht oft das Feintuning eines kleinen Modells mit ein paar Tausend gelabelten Beispielen aus – zu einem Bruchteil der Kosten.

Die interessante Lücke liegt in der Mitte: Aufgaben, die wirklich komplex sind und echtes Fachwissen sowie Urteilsvermögen erfordern – aber nicht so schwierig, dass nur Frontier-Modelle sie bewältigen können. In der Praxis ist es nicht nachhaltig, bei jeder Anfrage im großen Maßstab ein Frontier-Modell laufen zu lassen. Aber es ist nicht offensichtlich, ob kleinere, günstigere Modelle bei solchen Aufgaben mithalten können.

Dieser Artikel beschreibt, wie wir diese Frage bei Red Sift angegangen sind – was wir gemessen haben, wie wir es gemessen haben und was die Ergebnisse über die Modellauswahl für solche Aufgaben aussagen.

Radar Lite führt automatisierte Sicherheitsprüfungen für Domains in drei Bereichen durch: E-Mail-Sicherheit, DNS-Integrität und Web-/TLS-Konfiguration. Die Rohausgabe ist ein strukturierter Datensatz mit Testergebnissen – bestanden, fehlgeschlagen, Warnung, neutral – samt Belegen und Anmerkungen zu jedem Befund.

Die Aufgabe des Summarizers besteht darin, dies in einen lesbaren Markdown-Bericht zu übersetzen: die wichtigsten Fehler herauszustellen, die Auswirkungen auf die Praxis zu erklären und umsetzbare Empfehlungen zu geben.

Dies ist aus mehreren Gründen eine ideale Benchmarking-Aufgabe:

• Sie erfordert echtes Fachwissen. DMARC, SPF, DKIM, MTA-STS, DNSSEC, TLS-Zertifikatsketten – das sind keine Themen, die in generischen Trainingsdaten stark vertreten sind. Ein Modell, das DMARC p=none als bestandenes Ergebnis behandelt oder eine defekte DNSSEC-Kette mit einer geringfügigen Warnung statt einem Ausfallrisiko verwechselt, erzeugt Zusammenfassungen, die Sicherheitsteams aktiv in die Irre führen.
• Sie ist schwierig, aber nicht extrem schwierig. Die Belege liegen vor – das Modell muss nichts entdecken, sondern sie nur korrekt interpretieren und klar formulieren. Die Obergrenze ist strukturiertes, fachlich fundiertes Schreiben, nicht offenes Schlussfolgern oder mathematischer Beweis.
• Die Qualität ist messbar. Genauigkeit, Vollständigkeit, Struktur, Klarheit – es gibt konkrete, bewertbare Dimensionen, was eine konsistente Bewertung ermöglicht.
• Kosten und Latenz sind real relevant. Radar Lite ist ein kostenloses Tool. Frontier-Modelle bei jeder Anfrage laufen zu lassen, ist im großen Maßstab nicht tragfähig, sodass der Kompromiss zwischen Kosten und Qualität direkte Auswirkungen auf den Produktivbetrieb hat.

Bevor Sicherheitsprüfungen durchgeführt werden, analysiert Radar Lite die natürlichsprachliche Anfrage des Nutzers, um zwei Dinge zu erkennen:

• Intent (Absicht) – zu welchem Sicherheitsbereich der Nutzer eine Frage stellt: EMAIL (DMARC, SPF, DKIM, MTA-STS), DNS (DNSSEC, CAA-Einträge), WEB (TLS-Konfiguration, HTTPS, HSTS) oder ANY für eine vollständige Bewertung über alle drei Bereiche
• Scope (Umfang) – wie viele Domains betroffen sind und auf welche Weise: SINGLE für eine Domain, MULTI für mehrere unabhängig bewertete Domains oder COMPARE für einen direkten Vergleich

Beide bestimmen, welche Prüfungen durchgeführt werden, und – entscheidend – was der Summarizer liefern soll: Eine COMPARE-Zusammenfassung muss Gegensätze herausarbeiten und einen Gewinner benennen; eine MULTI-Zusammenfassung braucht einen eigenen Abschnitt pro Domain. Das macht das Sampling für den Benchmark nicht trivial: Die Aufgabe ändert ihre Form je nachdem, was der Nutzer angefragt hat.

Wir haben ungefähr 3.000 reale Produktionsanfragen aus dem Speicher gezogen und diese auf einen Benchmark-Datensatz mit 100 Einträgen heruntergesampelt. Zufälliges Sampling hätte den häufigsten Anfragetyp – Einzeldomain, beliebiger Intent – überrepräsentiert, daher haben wir geschichtetes Sampling verwendet, um sicherzustellen, dass die gesamte Bandbreite des Verhaltens des Summarizers abgedeckt wird:

Der Datensatz hat vier zentrale Eigenschaften:

• Repräsentativ – die Aufteilung des Scopes spiegelt die Produktionsanteile wider, wobei MULTI und COMPARE bewusst übergewichtet werden, da sie strukturell schwieriger sind und Modellschwächen eher aufdecken
• Vielfältig – die Intent-Aufteilung stellt sicher, dass alle drei Sicherheitsbereiche abgedeckt sind, statt sich auf den häufigsten Anfragetyp zu beschränken
• Unverzerrt – die Einschränkung auf eindeutige Domains bedeutet, dass jeder Eintrag eine tatsächlich unabhängige Beobachtung ist; keine einzelne Organisation-Infrastruktur beeinflusst die Ergebnisse unverhältnismäßig
• Statistisch aussagekräftig – bei 100 Einträgen sind Punktzahlunterschiede von etwa 3–5 Punkten auf der normierten Skala von 0–1 zuverlässig erkennbar, sodass sich echte Modellunterschiede von Rauschen unterscheiden lassen

Standard-Automatikmetriken wie BLEU oder ROUGE funktionieren hier nicht. Eine gute Zusammenfassung ist nicht diejenige, die einer Referenzzeichenfolge entspricht – sondern eine, die genau, gut strukturiert und umsetzbar ist. Wir haben einen LLM-as-a-Judge-Ansatz verwendet, wobei es einige Varianten zu berücksichtigen gilt.

• Paarweiser Vergleich – ein Richtermodell auffordern, die bessere von zwei Ausgaben auszuwählen – ist beliebt, aber bei einer großen Anzahl von Modellkonfigurationen mit je 100 Einträgen bräuchte man Tausende von Vergleichen, nur um sie zu ranken. Und selbst dann wüsste man, welches Modell gewonnen hat, ohne zu wissen warum.
• Direkte Bewertung vermeidet das Skalierungsproblem, aber der Richter erfindet dabei effektiv jedes Mal seine eigene Bewertungsrichtlinie, was zu inkonsistenten Ergebnissen über verschiedene Durchläufe hinweg führt.
• Eine strukturierte Bewertungsrichtlinie löst beide Probleme: Die Kriterien werden vorab festgelegt, sodass der Richter keinen Spielraum zum Abweichen hat, und die Punktzahlen pro Kriterium zeigen genau, wo jedes Modell zurückbleibt. Wir haben 0–2 statt einer binären Bewertung verwendet, da einige Kriterien einen echten Mittelzustand haben – teilweise korrekt unterscheidet sich sinnvoll von richtig oder falsch.

Wir kamen so auf eine Bewertungsrichtlinie mit 13 Kriterien, die auf den Ausgabeanforderungen von Radar Lite basiert:

• Sachliche Genauigkeit – keine halluzinierten Probleme, alle Fehler gemeldet
• Sprache und Tonfall – kein durchgesickerter interner Fachjargon, korrekte Formatierung, professioneller Sprachstil
• Schweregrad und Struktur – korrekte Emoji-Verwendung, Überschriftenebenen, Gruppierung von Problemen
• Tiefe – Spezifität der Ursachenanalyse, umsetzbare Empfehlungen
• Fachliche Korrektheit – MX-Null-Unterdrückungsregeln (z. B. kein Melden von fehlendem MTA-STS bei einer Domain ohne E-Mail-Verkehr), Scope-spezifische Formatierung bei Multi-Domain-Anfragen

Jedes Kriterium wird mit 0–2 bewertet, für maximal 26 Rohpunkte, normiert auf 0–1.

Bevor wir den Richter im großen Maßstab einsetzten, haben wir ihn validiert. Drei Kandidatenmodelle als Richter wurden jeweils 5 unabhängige Male auf denselben Einträgen ausgeführt, und wir haben die Konsistenz pro Kriterium gemessen – wie oft dasselbe Modell für dieselbe Eingabe über unabhängige Durchläufe hinweg dieselbe Punktzahl vergab. GPT-5.4 mit geringem Reasoning-Aufwand schnitt am besten ab: 11 von 13 Kriterien lieferten über alle 5 Durchläufe identische Punktzahlen, und die Durchschnittswerte pro Kriterium über die Durchläufe hinweg lagen zwischen 0,81 und 0,88 – eine enge Spanne, die auf eine stabile Kalibrierung hindeutet. Es wurde als Richter für den vollständigen Benchmark-Durchlauf ausgewählt.

Wir haben Modelle sowohl von kommerziellen Anbietern als auch aus Open-Source-Veröffentlichungen bewertet:

• OpenAI: GPT-5, GPT-5 mini, GPT-5 nano
• Anthropic: Claude Sonnet 4.6, Claude Haiku 4.5
• Google: Gemini 3.1 Pro, Gemini 3 Flash, Gemini 3.1 Flash Lite, Gemma 4 26B (über Vertex AI)
• Selbst gehostetes Open Source: Qwen3.5 122B, Qwen3.6 35B, Gemma 4 26B

Gemma 4 erscheint in beiden Listen – es wurde sowohl auf unserer eigenen Infrastruktur als auch über Vertex AI ausgeführt, um zu überprüfen, dass unser Setup vergleichbare Ergebnisse wie der Managed-Anbieter liefert. Mehrere Modelle wurden sowohl mit als auch ohne erweitertes Reasoning getestet, um zu verstehen, ob die zusätzliche Latenz und die Token-Kosten spürbar bessere Zusammenfassungen erzeugen.

Wir haben jede Konfiguration gegen den vollständigen Datensatz mit 100 Einträgen laufen lassen, mit GPT-5 als Richter. Hier sind die Ergebnisse.

Gemini 3.1 Pro und Claude Sonnet 4.6 liegen mit 0,93 und 0,92 an der Spitze. Aber sie spielen keineswegs in einer anderen Liga als die Modelle darunter. Mehrere Mittelklasse-Modelle – die meisten mit einer Form von aktiviertem Reasoning – gruppieren sich zwischen 0,88 und 0,90, alle innerhalb von 0,05 zum besten Ergebnis: GPT-5 mit geringem Reasoning, Gemma 4 26B mit erweitertem Reasoning und Gemini 3 Flash mit geringem Reasoning.

Gemini 3 Flash lieferte in unseren Ergebnissen die beste Gesamtbalance: 0,88 Punkte, 7 Sekunden Latenz, 0,76 $ für 100 Anfragen – mehr als 5-mal günstiger und mehr als doppelt so schnell wie Gemini 3.1 Pro. Das einzige schnellere Modell ist GPT-5 nano ohne Reasoning, das mit 0,58 deutlich niedriger abschneidet.

Gemma 4 auf Vertex AI ist mit 0,17 $ insgesamt die kosteneffizienteste tragfähige Option, mit einer Punktzahl von 0,86 und 13 Sekunden Latenz. Es liegt qualitativ knapp unter Gemini 3 Flash, aber zu weniger als einem Viertel der Kosten. Bei Anwendungen mit hohem Volumen summiert sich dieser Unterschied schnell.

GPT-5 mini mit geringem Reasoning ist ebenfalls bemerkenswert: 0,87 bei 0,46 $, was der Punktzahl des vollständigen GPT-5-Modells ohne Reasoning (1,70 $) entspricht – gleiche Qualität, ein Viertel der Kosten.

Wir betreiben Gemma 4 sowohl auf unserer eigenen Infrastruktur als auch über Vertex AI. Die Ergebnisse sind in beiden Reasoning-Modi im Wesentlichen identisch – 0,85 (selbst gehostet) vs. 0,86 (Vertex AI) ohne Reasoning und 0,90 vs. 0,89 mit aktiviertem Reasoning. Die Gesamtzahl der Ausgabe-Tokens über 100 Anfragen ohne Reasoning stimmt ebenfalls eng überein: 51.223 (selbst gehostet) vs. 52.405 (Vertex AI). Für Teams, die Open-Modelle im Produktivbetrieb einsetzen, ist diese Art von Gegenprüfung wichtig: Wenn die selbst gehostete Ausgabe sowohl bei Qualität als auch bei Ausführlichkeit mit der Managed API übereinstimmt, kann man sicher sein, dass die eigene Bereitstellung korrekt konfiguriert ist und dass sich Benchmark-Ergebnisse zwischen Umgebungen übertragen lassen.

Bei Modellen, bei denen beide Modi getestet wurden, fügt erweitertes oder geringes Reasoning der Punktzahl typischerweise 0,02–0,03 hinzu:

• GPT-5: 0,89 (gering) vs. 0,87 (keins)
• Claude Haiku 4.5: 0,86 (erweitert) vs. 0,83 (keins)
• Qwen3.5 122B: 0,85 (erweitert) vs. 0,83 (keins)

Ob diese Verbesserung die Latenz und die Kosten rechtfertigt, hängt von der jeweiligen Situation ab. Bei einer Sicherheitszusammenfassung – bei der es sich um strukturiertes Schreiben auf Basis vorliegender Belege handelt und nicht um mehrstufiges Schlussfolgern – sind die Gewinne real, aber nicht transformativ.

Die klare Ausnahme ist GPT-5 nano: Ohne Reasoning erzielt es 0,58, den niedrigsten Wert im gesamten Benchmark, und ist das einzige Modell, das regelmäßig unvollständige oder schlecht strukturierte Zusammenfassungen erzeugte. Mit geringem Reasoning-Aufwand springt es auf 0,72. Bei kleineren Modellen mit geringerer inhärenter Fähigkeit übernimmt Reasoning möglicherweise einen größeren Teil der Arbeit.

Die Durchführung dieser Evaluierung hat verändert, wie wir über die Modellauswahl für Produktionsaufgaben im Bereich "anspruchsvoll, aber nicht Frontier-schwierig" denken:

1. Allgemeine Bestenlisten testen Breite, nicht Tiefe. Die Platzierung eines Modells auf allgemeinen Benchmarks sagt nicht voraus, wie es sich bei einer spezifischen Fachaufgabe verhält. Der einzige Weg, das herauszufinden, ist ein Benchmark mit der tatsächlichen Arbeitslast und den tatsächlichen Daten.
2. Reasoning ist ein Kompromiss, kein kostenloses Upgrade. Bei den meisten Modellen fügt es der Punktzahl 0,02–0,03 hinzu, auf Kosten erheblicher Latenz. Ob sich das lohnt, hängt von der jeweiligen Aufgabe ab – bei strukturiertem Schreiben auf Basis vorliegender Belege sind die Gewinne real, aber bescheiden.
3. Benchmark mit Produktionsdaten, nicht mit synthetischen Stichproben. Geschichtetes Sampling aus echten Anfragen deckte die gesamte Bandbreite von Aufgabentypen auf, die ein Benchmark mit synthetischen Daten übersehen hätte. Das gewählte Modell kann sich am Rand der eigenen Verteilung sehr unterschiedlich verhalten.
4. Selbst-Hosting ist tragfähig, wenn man es validiert. Open-Source-Modelle, die auf der eigenen Infrastruktur laufen, können die Qualität der Managed API erreichen – aber nur, wenn man dies überprüft. Punktzahl, Ausgabelänge und Reasoning-Verhalten sollten übereinstimmen, bevor man es im Produktivbetrieb einsetzt.

Wenn Sie sehen möchten, welche Art von Zusammenfassungen diese Modelle erzeugen: Radar Lite ist kostenlos nutzbar – geben Sie einfach eine Domain ein und stellen Sie eine Frage.