Evaluierung, Benchmarking & Red Teaming

Öffentliche Benchmark-Ergebnisse sagen Ihnen fast nichts darüber aus, wie ein KI-System in Ihrer Bereitstellung abschneiden wird. Wir konzipieren Evaluierungs-Harnesses, domänenspezifische Benchmarks und strukturierte Red-Teaming-Programme, die messen, ob KI-Systeme für Ihren Anwendungsfall tatsächlich funktionieren — gemessen an Ihren Daten, Ihren Grenzfällen sowie Ihren Kosten- und Sicherheitsanforderungen.

Warum öffentliche Benchmarks Ihre Bereitstellung verfehlen

Spitzenmodelle liegen durchweg über 88 % beim MMLU. GPT-5.3 Codex erreicht 99 %. Das 2025 LLM Leaderboard von Vellum hat MMLU vollständig gestrichen, weil es Modelle in keiner sinnvollen Weise mehr unterscheidet. MMLU-Pro, das dies beheben sollte, nähert sich für Spitzenmodelle bereits 90 %. Die meistzitierten Benchmarks der Branche sind zu Eitelkeitsmetriken geworden.

Das tiefere Problem ist die Relevanz. Ein Benchmark-Ergebnis sagt die Produktionsleistung nur unter drei Bedingungen voraus:

• Es prüft Aufgaben, die Ihren ähnlich sind.
• Der Testsatz ist frei von Datenkontamination — einige Benchmarks weisen Leckageraten von bis zu 100 % auf.
• Die Ergebnisunterschiede sind statistisch signifikant.

Für die meisten Unternehmensbereitstellungen trifft keine dieser Bedingungen zu. Der Rang kann sich vollständig umkehren, sobald Sie mit Ihren eigenen Daten testen — das drittplatzierte Modell in öffentlichen Ranglisten kann das erstplatzierte bei einer realen Extraktionsaufgabe um 40 % übertreffen. Genau diese Art von Lücke soll ein maßgeschneidertes Evaluierungs-Harness sichtbar machen, weshalb die Beantwortung der Frage „Welches Modell schneidet bei meinen Daten, meinen Grenzfällen und unter meinen Kostenvorgaben am besten ab?“ eine Evaluierungsinfrastruktur erfordert, die für Ihre Bereitstellung konzipiert ist.

Die drei Ebenen eines rigorosen Evaluierungsprogramms

Wir strukturieren die Evaluierung um drei Ebenen, von denen jede eine andere Frage zu Ihrem KI-System beantwortet.

Fähigkeitsevaluierung — Tut es, was wir brauchen?

Wir erstellen aufgabenspezifische Testsuiten aus Ihren Produktionsdaten und realistischen Grenzfällen, nicht aus bequemen Stichproben. Für ein Underwriting-Modell bedeutet das, mit tatsächlich abgelehnten Anträgen, Grenzfällen und den spezifischen Dokumentformaten zu testen, denen Ihre Pipeline begegnet.

Jeder Testfall wird mit Erhebungsmethodik und Metriken zur Annotationsqualität dokumentiert. Wir messen mit statistischer Strenge — mehrere Durchläufe mit verschiedenen Seeds, Bootstrap-Konfidenzintervalle und gepaarte Signifikanztests. Eine Verbesserung von 2 %, die innerhalb des Konfidenzintervalls liegt, ist keine Verbesserung.

Sicherheitsevaluierung — Wo versagt es, und wie schwerwiegend?

Wir testen Verhaltensgrenzen mithilfe strukturierter Sonden: Minimalfunktionstests, Invarianztests (ändert sich die Ausgabe, wenn sie es nicht sollte?) und Tests gerichteter Erwartungen. Die disaggregierte Evaluierung berichtet die Leistung über jedes betrieblich relevante Datensegment, denn ein Modell, das im Durchschnitt funktioniert, aber bei einer kritischen Teilpopulation versagt, ist nicht sicher einzusetzen, wie ausführlich dargelegt in unserer Forschung dazu, warum seltene, aber katastrophale Ausfallraten nicht ignoriert werden dürfen.

Adversariale Evaluierung — Lässt es sich zu Fehlverhalten bewegen?

Diese Ebene fragt, ob jemand das System dazu bringen kann, etwas zu tun, was es nicht sollte. Hier ist das Red Teaming angesiedelt.

Red Teaming als strukturierte Fähigkeitsbewertung

Red Teaming ist kein Penetrationstest unter anderem Namen. Die Sicherheitsbewertung fragt „Kann ein Angreifer dieses System kompromittieren?“ Red Teaming im Evaluierungskontext fragt „Wo liegen die Grenzen des Verhaltens dieses Systems, und wo brechen diese Grenzen?“ Die Methoden überschneiden sich, aber die Fragen, die Berichterstattung und die Zielgruppe sind unterschiedlich.

Wir arbeiten nach einer strukturierten Methodik, die auf der Taxonomie NIST AI 100-2 E2025 aufbaut, die im März 2025 erheblich erweitert wurde, um Schwachstellen autonomer KI-Agenten und GenAI-spezifische Angriffskategorien abzudecken. Unsere Red-Team-Programme folgen einer definierten Abfolge:

1. Definition des Bedrohungsmodells, zugeschnitten auf Ihren Bereitstellungskontext.
2. Aufzählung der Angriffstaxonomie, die die Kategorien der OWASP LLM Top 10 v2 abdeckt — Prompt Injection, Jailbreaking, Datenvergiftung, indirekte Injection über abgerufene Inhalte, multimodale Angriffe und codierungsbasierte Umgehung.
3. Systematische Angriffsdurchführung mit dokumentierten Verfahren.
4. Nach Schweregrad bewertete Befunde mit Reproduktionsschritten.

Menschliches und automatisiertes Red Teaming

Wir ergänzen menschliches Red Teaming durch automatisierte adversariale Pipelines. Cascade von Haize Labs erzielt Angriffserfolgsraten von 44 % bei Spitzenmodellen, viermal höher als bei Single-Turn-Baselines. Promptfoo führt über 50 Schwachstellentypen in CI/CD über mehr als 300.000 Entwicklerinstallationen aus. Automatisierte Werkzeuge erfassen bekannte Muster in großem Maßstab; menschliche Red Teamer finden neuartige Schwachstellen, die automatisierte Systeme noch nie gesehen haben — was dort am wichtigsten ist, wo die Folgen eines übersehenen Ausfallmodus schwerwiegend sind.

Was jedes Engagement liefert

Jedes Red-Team-Engagement ist darauf ausgelegt, drei Ergebnisse zu produzieren:

• Einen Befundbericht mit Schweregradbewertungen und Reproduktionsverfahren.
• Empfehlungen zur Behebung, abgebildet auf Ihre Architektur.
• Eine automatisierte Regressions-Testsuite, die aus entdeckten Schwachstellen abgeleitet wird und sich in Ihre Bereitstellungspipeline integriert, sodass entdeckte Schwachstellen behoben bleiben.

Wann automatisierte Evaluierung funktioniert — und wann nicht

Die LLM-as-Judge-Evaluierung — bei der ein Spitzenmodell die Ausgaben eines anderen Modells bewertet — ist zum Standard für Teams geworden, die sich menschliche Evaluierung in großem Maßstab nicht leisten können. Sie ist nützlich. Sie ist auch auf bestimmte, dokumentierte Weise unzuverlässig. Die Forschung hat mehr als 12 verschiedene Bias-Typen bei LLM-Bewertern identifiziert:

• Selbstpräferenz-Bias — GPT-4 bewertet Ausgaben mit geringerer Perplexität höher, unabhängig davon, ob es sie selbst erzeugt hat.
• Weitschweifigkeits-Bias — Bewerter bevorzugen durchweg ausführliche, formelle Antworten gegenüber prägnanten, korrekten.
• Positions-Bias — Bewerter begünstigen diejenige Antwort, die zuerst erscheint.

Diese Verzerrungen sind für allgemeine Qualitätsvergleiche mit Entzerrungstechniken wie randomisierter Position und Multi-Bewerter-Panels beherrschbar. Sie sind disqualifizierend, wenn domänenspezifische Korrektheit zählt. Ein LLM-Bewerter kann nicht zuverlässig beurteilen, ob ein klinisches System Arzneimittelwechselwirkungen korrekt erkennt oder ob eine juristische Recherche die Rechtsprechung akkurat zitiert. Wir setzen automatisierte Bewertung dort ein, wo Bias beherrschbar ist, und menschliche Expertenprüfung dort, wo Korrektheit Fachwissen erfordert.

Evaluierung agentischer KI-Systeme

Statisches Modell-Benchmarking funktioniert nicht für Agenten, die planen, Werkzeuge nutzen und mehrstufige Arbeitsabläufe ausführen. Eine einzelne Genauigkeitszahl kann nicht erfassen, ob der Agent das richtige Werkzeug ausgewählt, es mit korrekten Parametern aufgerufen, sich bei einem gescheiterten Schritt elegant erholt oder über 15 verkettete Operationen hinweg ein kohärentes Ergebnis erzeugt hat. Ein Agent kann jeden einzelnen Schritt korrekt ausführen und dennoch ein falsches Ergebnis liefern, weil die Argumentation, die diese Schritte verbindet, fehlerhaft war.

Wir evaluieren agentische Systeme über fünf Dimensionen, die dem CLEAR-Framework entnommen sind:

• Kosten Effizienz der Werkzeug- und Token-Nutzung.
• Latenz über die vollständige Aufgabenerledigung hinweg.
• Wirksamkeit des durchgängigen Aufgabenerfolgs.
• Gewährleistung dass Sicherheitsanforderungen während der gesamten Ausführung eingehalten wurden.
• Zuverlässigkeit über wiederholte Durchläufe hinweg.

Für werkzeugnutzende Agenten testen wir außerdem die Genauigkeit der Werkzeugauswahl, die Korrektheit der Parameter (Agenten erfinden Parameternamen in nennenswertem Umfang), die Einhaltung des Geltungsbereichs und die Fehlerbehebung. Für Multi-Agenten-Systeme testen wir die Treue der Kommunikation zwischen Agenten, die Ausbreitung kaskadierender Ausfälle und ob Aufsichtskontrollen tatsächlich eingreifen, wenn untergeordnete Agenten abweichen.

Die Benchmarks holen auf — SWE-bench testet reale Softwareentwicklungsaufgaben, Terminal-Bench bewertet Kommandozeilen-Agenten-Arbeitsabläufe und UpBench nutzt echte Upwork-Stellenausschreibungen, die kontinuierlich aktualisiert werden. Aber vorgefertigte agentische Benchmarks passen selten zu Ihrer spezifischen Agentenarchitektur, Ihrem Werkzeugsatz und Ihrer Domäne, weshalb wir maßgeschneiderte agentische Evaluierungs-Harnesses erstellen — denn die Ausfallmodi Ihres Agenten sind spezifisch für sein Design.

Evaluierung für das EU-KI-Gesetz und die Einhaltung von Vorschriften

Die des EU-KI-Gesetzes Hochrisiko-Bestimmungen treten vollständig in Kraft am 2. August 2026. Artikel 9 verlangt ein Risikomanagementsystem mit dokumentierter Evaluierungsmethodik, Tests unter Bedingungen der bestimmungsgemäßen Verwendung und der vernünftigerweise vorhersehbaren Fehlanwendung sowie eine fortlaufende Marktbeobachtung nach dem Inverkehrbringen. Die Konformitätsbewertung muss abgeschlossen sein, bevor ein Hochrisikosystem auf dem EU-Markt in Verkehr gebracht wird. Verstöße ziehen Geldbußen von bis zu 7 % des weltweiten Jahresumsatzes oder 35 Millionen EUR nach sich.

NIST AI 100-2 E2025 liefert die maßgebliche Taxonomie für die adversariale Evaluierung, die nun Schwachstellen autonomer Agenten abdeckt, die in der Ausgabe von 2023 fehlten. Diese Rahmenwerke tauchen in Beschaffungsanforderungen und in Risikoprüfungen auf Vorstandsebene auf.

Die praktische Herausforderung: Noch definiert kein harmonisierter Standard, was „angemessene Evaluierung“ für die Einhaltung des EU-KI-Gesetzes bedeutet. CEN/CENELEC JTC 21 hat seine Frist im August 2025 verpasst und peilt nun das vierte Quartal 2026 an. Wir konzipieren Evaluierungsprogramme, die schon jetzt belastbare Nachweise erbringen und zugleich anpassungsfähig für Standards bleiben, die noch finalisiert werden — ein Ansatz, den wir darlegen in unserem Whitepaper über architektonische Integrität und regulatorische Rechenschaftspflicht in der generativen KI für Unternehmen.

Kontinuierliche Evaluierung im Produktivbetrieb

Eine Evaluierung vor der Bereitstellung sagt Ihnen, dass das System an einem bestimmten Datum gegen einen bestimmten Testsatz funktioniert hat. Sie sagt Ihnen nichts über den nächsten Monat. Produktionsmodelle driften, Eingabeverteilungen verschieben sich, abgerufene Inhalte ändern sich und Werkzeug-APIs werden aktualisiert. Ein LLMOps-Bericht von 2025 stellte fest, dass bei Modellen, die sechs Monate lang unverändert blieben, die Fehlerraten bei neuen Daten um 35 % anstiegen. Gartner schätzt, dass Stand 2025 nur 18 % der Softwareentwicklungsteams KI-Evaluierungs- und Observability-Plattformen eingeführt hatten, prognostiziert jedoch eine Verbreitung von 60 % bis 2028.

Wir bauen Evaluierungspipelines, die kontinuierlich laufen:

• Die Produktionsüberwachung bewertet den Live-Datenverkehr mit denselben Evaluatoren aus der Entwicklung.
• Fehlgeschlagene Evaluierungen werden zu CI/CD-Regressionstests.
• Die Drift-Erkennung schlägt Alarm, wenn Eingabeverteilungen von den Baselines abweichen.
• Adversariale Suiten laufen nächtlich gegen Produktions-Endpunkte.

Dies ist eine betriebliche Infrastruktur, die die Evaluierung aktuell hält, während sich Ihr System weiterentwickelt.

Die Landschaft der Evaluierungswerkzeuge

Der Markt ist fragmentiert, und jedes Werkzeug hat blinde Flecken. Wir setzen jedes dort ein, wo es passt, und bauen maßgeschneiderte Harnesses dort, wo keines von ihnen hinreicht.