{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Security"],"content":{"markdown":"Ein Modell mit hervorragenden Benchmark-Werten kann trotzdem Ihre Rückgaberegeln erfinden, harmlose Fragen ablehnen oder manche Kunden anders behandeln als andere. Sicherheit und Zuverlässigkeit sind Eigenschaften Ihres Systems in Ihrem Kontext, und Sie kennen sie nur, wenn Sie sie messen. Genau das leistet eine **Evaluation**, kurz **Eval**: ein wiederholbarer Test mit festem Datensatz, einer Bewertungsmethode und einer Schwelle, die über Bestehen oder Scheitern entscheidet.\n\nDies ist Teil 4 von Level 4 (Experte) im Lernpfad AI Security. Sie erfahren, welche Eigenschaften Sie messen sollten und was öffentliche Benchmarks zeigen können und was nicht. Außerdem sehen Sie, wie Sie eine Eval-Suite für den Support-Assistenten des Shops aufbauen, wie viele Testfälle Sie brauchen und wie Sie nach dem Start weiter evaluieren. Red Teaming aus Level 3 findet neue Probleme; Evals sorgen dafür, dass bekannte Probleme behoben bleiben. Lesen Sie zuerst [Red Teaming für LLMs](/de/ai-security/learn/red-teaming-llms/), falls Sie es noch nicht kennen.\n\n## Fünf Eigenschaften, die sich zu messen lohnen\n\nDie meisten Fragen zu Sicherheit und Zuverlässigkeit fallen in fünf Gruppen. Das HELM-Projekt der Stanford University hat die Idee bekannt gemacht, mehrere Eigenschaften nebeneinander zu messen. Es bewertet Genauigkeit, Kalibrierung, Robustheit, Fairness, Bias, Toxizität und Effizienz gemeinsam (Quelle: Liang et al., „Holistic Evaluation of Language Models“, 2022).\n\n- **Faktentreue:** Stimmen die Antworten, und werden sie von den Quellen gestützt, die das System gefunden hat? In einem RAG-System kann eine Antwort allgemein richtig sein und trotzdem nicht durch Ihre Dokumente belegt.\n- **Robustheit:** Bleibt die Qualität, wenn Nutzer anders formulieren, Tippfehler machen, die Sprache wechseln oder sehr lange Eingaben senden? Schon das Format zählt: Kleine Änderungen an der Formatierung von Prompts verschoben die Genauigkeit eines Modells in Few-Shot-Tests um bis zu 76 Prozentpunkte (Quelle: Sclar et al., ICLR 2024).\n- **Ablehnungsverhalten:** Es gibt zwei Fehler. **Zu wenig Ablehnung** heißt, das System hilft bei einer Anfrage, die es ablehnen sollte. **Zu viel Ablehnung** heißt, es lehnt eine harmlose Anfrage ab, die nur riskant klingt — etwa wie man einen Python-Prozess „killt“. Testsammlungen wie XSTest zielen auf den zweiten Fehler (Quelle: Röttger et al., NAACL 2024).\n- **Bias:** Ändern sich Qualität oder Ton, wenn sich nur ein Name, das Geschlecht oder die Herkunft ändert? Der Benchmark BBQ prüft das für Frage-Antwort-Aufgaben (Quelle: Parrish et al., 2022); für Ihr eigenes System tauschen Sie Namen in echten Aufgaben und vergleichen.\n- **Kalibrierung:** Passt die angegebene Sicherheit zur Trefferquote? Ein gut kalibriertes System, das „zu 90 % sicher“ sagt, liegt in etwa 90 % der Fälle richtig. Moderne neuronale Netze sind eher zu selbstsicher (Quelle: Guo et al., ICML 2017). Das Nachtraining kann das verstärken: Im technischen Bericht zu GPT-4 war das vortrainierte Modell bei einem Wissenstest gut kalibriert, das fertige Modell weniger (Quelle: OpenAI, GPT-4 Technical Report, 2023).\n\nDie Tabelle macht aus diesen Eigenschaften Kennzahlen für den Shop:\n\n| Eigenschaft | Beispiel-Kennzahl | Beispiel im Shop |\n|---|---|---|\n| Faktentreue | Anteil der Antworten, die zur Referenz passen; Anteil der Aussagen ohne Beleg | Rückgabefristen und Versandkosten müssen zu den Regeln passen |\n| Robustheit | Schlechtester Wert über Umformulierungen, Tippfehler und Sprachen | Dieselbe Frage auf Englisch, mit Tippfehlern, bekommt dieselbe Antwort |\n| Ablehnungsverhalten | Beantwortete schädliche Anfragen; abgelehnte harmlose Anfragen | Gibt keine Daten anderer Kunden heraus, erklärt aber die Sendungsverfolgung |\n| Bias | Unterschied in Ergebnis oder Ton bei getauschten Namen | Erstattungsentscheidungen hängen nicht vom Namen ab |\n| Kalibrierung | Expected Calibration Error; Anteil von „weiß ich nicht“ bei unbeantwortbaren Fragen | Sagt „Ich kläre das mit einer Kollegin“, statt zu raten |\n\nDie Kalibrierung braucht einen zusätzlichen Schritt. Lassen Sie das System zu jeder Antwort seine Sicherheit angeben oder leiten Sie sie aus den Token-Wahrscheinlichkeiten des Modells ab. Gruppieren Sie die Antworten dann nach Sicherheit und vergleichen Sie jede Gruppe mit ihrer tatsächlichen Trefferquote. Der **Expected Calibration Error** (ECE) ist der gewichtete Durchschnitt der Abstände zwischen beiden. Für einen Support-Assistenten ist oft eine einfachere Prüfung praktischer: Stellen Sie Fragen, die seine Dokumente nicht beantworten, und zählen Sie, wie oft er das zugibt, statt zu raten.\n\n## Was öffentliche Benchmarks zeigen können — und was nicht\n\nÖffentliche Benchmarks taugen für eine Aufgabe: Modelle vorab auszusieben, bevor Sie selbst testen. Unsere LLM-Seiten verfolgen {{\u003c stat \"benchmarks\" \u003e}} Benchmarks. [Level 1](/de/ai-security/learn/hallucinations-as-a-security-risk/) hat mit einem davon, SimpleQA Verified, gezeigt, dass selbst die besten Modelle einen spürbaren Teil einfacher Faktenfragen verfehlen. Für Evals bringt ein anderer Benchmark einen neuen Blickwinkel. **Humanity's Last Exam** (HLE) ist einer der schwersten Tests: 2.500 Fragen, die Fachleute geschrieben haben, herausgegeben vom Center for AI Safety und Scale AI. Die Autoren messen auch die Kalibrierung. Als HLE Anfang 2025 erschien, beantworteten die getesteten Modelle nur einen kleinen Teil richtig und gaben trotzdem hohe Sicherheit an. Das sind die aktuellen Spitzenreiter in unseren Daten:\n\n{{\u003c llm-top bench=\"hle\" n=\"5\" \u003e}}\n\nLesen Sie solche Tabellen mit fünf Grenzen im Hinterkopf:\n\n1. **Sättigung.** Sobald die besten Modelle nahe an der vollen Punktzahl liegen, trennt ein Benchmark sie nicht mehr. Deshalb entstehen ständig neue, schwerere Tests.\n2. **Kontamination.** Gelangen Testfragen in die Trainingsdaten, überschätzen die Werte, was ein Modell kann.\n3. **Konstruktvalidität.** Ein Benchmark misst seine eigene Aufgabe. Expertenfragen sagen wenig über Ihre Rückgaberegeln.\n4. **Fehlanreize beim Bewerten.** Die meisten Benchmarks geben für „weiß ich nicht“ keinen Punkt, also lohnt sich Raten. Forschende von OpenAI argumentierten 2025, dass dies Halluzinationen belohnt und dass selbstsichere Fehler stärker bestraft werden sollten als ehrliche Unsicherheit (Quelle: Kalai et al., „Why Language Models Hallucinate“, 2025).\n5. **Modell ist nicht System.** Ihr Prompt, Ihre Dokumente und Ihre Tools verändern das Verhalten. Ein Benchmark testet nichts davon.\n\n![Liniendiagramm der Bestwerte über die Zeit bei HellaSwag, GPQA Diamond und Humanity's Last Exam: Die älteren Benchmarks nähern sich der vollen Punktzahl, der neueste beginnt weit darunter](/images/learn/de/evaluate-model-safety-and-reliability-saturation.webp \"Benchmarks sättigen: Ältere Tests nähern sich der vollen Punktzahl, deshalb lösen neuere, schwerere sie ab. Daten: Epoch AI, CC BY 4.0.\")\n\nNutzen Sie Benchmarks für eine Vorauswahl — alle Modelle und ihre Ergebnisse stehen in unserer [LLM-Datenbank](/de/llm/) — und testen Sie die Vorauswahl dann mit Ihren eigenen Aufgaben.\n\n## Eine eigene Eval-Suite in Schichten aufbauen\n\nEine Eval-Suite ist kein einzelner Test, sondern mehrere Schichten, die zu unterschiedlichen Zeiten laufen:\n\n![Fünf Schichten einer Eval-Suite, von der Benchmark-Vorauswahl oben über ein Golden Set, Sicherheitstests und Robustheitsvarianten bis zur Überwachung im Betrieb unten, jeweils mit dem Zeitpunkt, zu dem sie läuft](/images/learn/de/evaluate-model-safety-and-reliability-layers.webp \"Eine Eval-Suite in fünf Schichten. Die unteren Schichten laufen öfter und finden mehr von Ihren echten Problemen.\")\n\n1. Die **Benchmark-Vorauswahl** grenzt die Modelle ein. Sie läuft einmal pro Modellentscheidung.\n2. Ein **Golden Set** enthält echte Aufgaben mit Referenzantworten. Beim Shop sind das echte Kundenfragen, bereinigt um personenbezogene Daten, mit Antworten aus den aktuellen Regeln. Beginnen Sie mit ein- bis zweihundert Fällen und ergänzen Sie jeden neuen Fehler.\n3. **Sicherheitstests** decken schädliche und harmlose, aber heikle Anfragen ab, dazu Fälle von Prompt Injection und Datenabfluss aus dem Red Teaming, die Angriffsideen aus [Teil 2](/de/ai-security/learn/adversarial-machine-learning/) und Paare mit getauschten Namen für Bias.\n4. **Robustheitsvarianten** wiederholen Fragen aus dem Golden Set als Umformulierung, mit Tippfehlern, in anderen Sprachen und mit langen Verläufen.\n5. Die **Überwachung im Betrieb** prüft Stichproben echter Gespräche und verfolgt Rückmeldungen, Eskalationen und Beschwerden.\n\nJeder Fall braucht außerdem eine **Bewertungsmethode**. Regeln und exakte Treffer funktionieren bei strukturierten Ausgaben wie einem Bestellstatus. Freier Text braucht einen Vergleich mit der Referenzantwort, durch Menschen oder durch ein zweites Modell als Bewerter. **LLM-as-a-Judge** skaliert gut, doch solche Bewerter haben bekannte Verzerrungen: Sie bevorzugen die erste von zwei Antworten, längere Antworten und manchmal Antworten aus der eigenen Modellfamilie (Quelle: Zheng et al., NeurIPS 2023). Prüfen Sie jeden Bewerter an einer Stichprobe gegen menschliche Urteile, bevor Sie ihm vertrauen.\n\n## Wie viele Testfälle Sie brauchen\n\nAusgaben schwanken, deshalb ist jeder Wert eine Schätzung. Eine Bestehensquote aus 50 Fällen ist viel unsicherer als eine aus 500. Die Abbildung zeigt das 95-%-Konfidenzintervall für eine beobachtete Quote von 90 % bei verschiedenen Stichprobengrößen.\n\n![Diagramm der 95-Prozent-Konfidenzintervalle um eine beobachtete Bestehensquote von 90 Prozent: Bei 25 oder 50 Testfällen ist das Intervall breit, bei 200, 500 und 1.000 Fällen wird es stetig schmaler](/images/learn/de/evaluate-model-safety-and-reliability-sample-size.webp \"Dieselbe beobachtete Quote sagt mit mehr Testfällen mehr aus. Berechnet mit dem Wilson-Intervall — ein Beispiel, keine Messung.\")\n\nDaraus folgen drei Regeln. Um die Unsicherheit zu halbieren, brauchen Sie etwa viermal so viele Fälle. Ein Unterschied zwischen zwei Modellversionen, der kleiner ist als die Intervalle, kann Rauschen sein statt Fortschritt. Und weil dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann, sollten wichtige Fälle mehrmals laufen; berichten Sie dann eine Quote. Die Statistik dahinter erklärt eine Anleitung von Anthropic zu Fehlerbalken bei Evals ausführlicher (Quelle: Miller, „Adding Error Bars to Evals“, Anthropic, 2024).\n\n## Nach dem Start weiter evaluieren\n\nDie Evaluation endet nicht mit dem Release. Lassen Sie die Suite automatisch laufen, sobald sich etwas ändert: die Modellversion, der System-Prompt, die Wissensbasis oder ein Tool. Anbieter aktualisieren die Modelle hinter einer API, manchmal unter demselben Namen; darum gehört auch ein fester Zeitplan dazu. Machen Sie aus jedem Vorfall und jeder bestätigten Beschwerde einen neuen Testfall. Legen Sie für jede Kennzahl eine Schwelle fest und stoppen Sie ein Release, wenn eine verfehlt wird — ein einziger kritischer Sicherheitsfehler sollte genügen.\n\nManche Plattformen unterstützen Teile dieser Arbeit. Nach Angaben des Anbieters bietet Airia Red Teaming zusammen mit Richtlinien und Prüfnachweisen. TestDriver.ai baut nach eigener Beschreibung Regressionstests für Pull Requests, allerdings für Benutzeroberflächen, nicht für Modellverhalten. Wenn Sie Agenten auf einer No-Code-Plattform wie MindStudio bauen, evaluieren Sie den Agenten als Ganzes — Prompts, Tools und Wissen —, nicht nur sein Modell. Bevor Sie sich bei Evals auf eine Plattform verlassen, stellen Sie drei Fragen. Kann sie Ihr eigenes Golden Set ausführen? Kann sie ein Release stoppen, wenn eine Schwelle verfehlt wird? Bewahrt sie die Ergebnisse als Nachweis auf? Wir haben diese Tools nicht getestet.\n\nFür den Support-Assistenten des Shops sieht der Plan so aus (die Größen sind Beispiele):\n\n| Testsatz | Beispielgröße | Kennzahl | Freigabeschwelle | Läuft |\n|---|---|---|---|---|\n| Golden Set echter Fragen | 200 Fälle | Übereinstimmung mit Referenzantworten | Kein Rückgang gegenüber dem letzten Release | Bei jeder Änderung |\n| Fakten aus den Regeln | 50 Fälle | Exakte Treffer bei Fristen und Gebühren | Alle bestanden | Bei jeder Änderung |\n| Schädliche und heikle Anfragen | 100 Fälle | Schädliche Antworten; abgelehnte harmlose Anfragen | Kein kritischer Fehler | Bei jeder Änderung |\n| Injection und Datenabfluss | 60 Fälle aus dem Red Teaming | Befolgte versteckte Anweisungen; abgeflossene Daten | Keine | Bei jeder Änderung |\n| Paare mit getauschten Namen | 40 Paare | Unterschied in Ergebnis und Ton | Kein systematischer Unterschied | Monatlich |\n| Stichprobe aus dem Betrieb | 1 % der Chats | Bewertung durch Prüfer, Eskalationen | Trend, keine Schwelle | Wöchentlich |\n\n{{\u003c callout type=\"try\" title=\"Ihre ersten zehn Golden Cases\" \u003e}}\nSammeln Sie zehn echte Fragen, die Ihr KI-System letzte Woche bekommen hat. Entfernen Sie personenbezogene Daten. Schreiben Sie zu jeder Frage die richtige Antwort aus Ihren aktuellen Unterlagen und vermerken Sie, welche Quelle sie belegt. Lassen Sie das System jede Frage dreimal beantworten und bewerten Sie die Antworten. Jeder Fehltreffer ist Ihr erster Regressionstest — und der Anfang Ihrer Nachweise für [Teil 5](/de/ai-security/learn/build-a-secure-ai-program/).\n{{\u003c /callout \u003e}}","text":"Ein Modell mit hervorragenden Benchmark-Werten kann trotzdem Ihre Rückgaberegeln erfinden, harmlose Fragen ablehnen oder manche Kunden anders behandeln als andere. Sicherheit und Zuverlässigkeit sind Eigenschaften Ihres Systems in Ihrem Kontext, und Sie kennen sie nur, wenn Sie sie messen. Genau das leistet eine Evaluation, kurz Eval: ein wiederholbarer Test mit festem Datensatz, einer Bewertungsmethode und einer Schwelle, die über Bestehen oder Scheitern entscheidet.\nDies ist Teil 4 von Level 4 (Experte) im Lernpfad AI Security. Sie erfahren, welche Eigenschaften Sie messen sollten und was öffentliche Benchmarks zeigen können und was nicht. Außerdem sehen Sie, wie Sie eine Eval-Suite für den Support-Assistenten des Shops aufbauen, wie viele Testfälle Sie brauchen und wie Sie nach dem Start weiter evaluieren. Red Teaming aus Level 3 findet neue Probleme; Evals sorgen dafür, dass bekannte Probleme behoben bleiben. Lesen Sie zuerst Red Teaming für LLMs, falls Sie es noch nicht kennen.\nFünf Eigenschaften, die sich zu messen lohnen Die meisten Fragen zu Sicherheit und Zuverlässigkeit fallen in fünf Gruppen. Das HELM-Projekt der Stanford University hat die Idee bekannt gemacht, mehrere Eigenschaften nebeneinander zu messen. Es bewertet Genauigkeit, Kalibrierung, Robustheit, Fairness, Bias, Toxizität und Effizienz gemeinsam (Quelle: Liang et al., „Holistic Evaluation of Language Models“, 2022).\nFaktentreue: Stimmen die Antworten, und werden sie von den Quellen gestützt, die das System gefunden hat? In einem RAG-System kann eine Antwort allgemein richtig sein und trotzdem nicht durch Ihre Dokumente belegt. Robustheit: Bleibt die Qualität, wenn Nutzer anders formulieren, Tippfehler machen, die Sprache wechseln oder sehr lange Eingaben senden? Schon das Format zählt: Kleine Änderungen an der Formatierung von Prompts verschoben die Genauigkeit eines Modells in Few-Shot-Tests um bis zu 76 Prozentpunkte (Quelle: Sclar et al., ICLR 2024). Ablehnungsverhalten: Es gibt zwei Fehler. Zu wenig Ablehnung heißt, das System hilft bei einer Anfrage, die es ablehnen sollte. Zu viel Ablehnung heißt, es lehnt eine harmlose Anfrage ab, die nur riskant klingt — etwa wie man einen Python-Prozess „killt“. Testsammlungen wie XSTest zielen auf den zweiten Fehler (Quelle: Röttger et al., NAACL 2024). Bias: Ändern sich Qualität oder Ton, wenn sich nur ein Name, das Geschlecht oder die Herkunft ändert? Der Benchmark BBQ prüft das für Frage-Antwort-Aufgaben (Quelle: Parrish et al., 2022); für Ihr eigenes System tauschen Sie Namen in echten Aufgaben und vergleichen. Kalibrierung: Passt die angegebene Sicherheit zur Trefferquote? Ein gut kalibriertes System, das „zu 90 % sicher“ sagt, liegt in etwa 90 % der Fälle richtig. Moderne neuronale Netze sind eher zu selbstsicher (Quelle: Guo et al., ICML 2017). Das Nachtraining kann das verstärken: Im technischen Bericht zu GPT-4 war das vortrainierte Modell bei einem Wissenstest gut kalibriert, das fertige Modell weniger (Quelle: OpenAI, GPT-4 Technical Report, 2023). Die Tabelle macht aus diesen Eigenschaften Kennzahlen für den Shop:\nSicherheit und Zuverlässigkeit von Modellen bewerten Eigenschaft Beispiel-Kennzahl Beispiel im Shop Faktentreue Anteil der Antworten, die zur Referenz passen; Anteil der Aussagen ohne Beleg Rückgabefristen und Versandkosten müssen zu den Regeln passen Robustheit Schlechtester Wert über Umformulierungen, Tippfehler und Sprachen Dieselbe Frage auf Englisch, mit Tippfehlern, bekommt dieselbe Antwort Ablehnungsverhalten Beantwortete schädliche Anfragen; abgelehnte harmlose Anfragen Gibt keine Daten anderer Kunden heraus, erklärt aber die Sendungsverfolgung Bias Unterschied in Ergebnis oder Ton bei getauschten Namen Erstattungsentscheidungen hängen nicht vom Namen ab Kalibrierung Expected Calibration Error; Anteil von „weiß ich nicht“ bei unbeantwortbaren Fragen Sagt „Ich kläre das mit einer Kollegin“, statt zu raten Die Kalibrierung braucht einen zusätzlichen Schritt. Lassen Sie das System zu jeder Antwort seine Sicherheit angeben oder leiten Sie sie aus den Token-Wahrscheinlichkeiten des Modells ab. Gruppieren Sie die Antworten dann nach Sicherheit und vergleichen Sie jede Gruppe mit ihrer tatsächlichen Trefferquote. Der Expected Calibration Error (ECE) ist der gewichtete Durchschnitt der Abstände zwischen beiden. Für einen Support-Assistenten ist oft eine einfachere Prüfung praktischer: Stellen Sie Fragen, die seine Dokumente nicht beantworten, und zählen Sie, wie oft er das zugibt, statt zu raten.\nWas öffentliche Benchmarks zeigen können — und was nicht Öffentliche Benchmarks taugen für eine Aufgabe: Modelle vorab auszusieben, bevor Sie selbst testen. Unsere LLM-Seiten verfolgen 16 Benchmarks. Level 1 hat mit einem davon, SimpleQA Verified, gezeigt, dass selbst die besten Modelle einen spürbaren Teil einfacher Faktenfragen verfehlen. Für Evals bringt ein anderer Benchmark einen neuen Blickwinkel. Humanity\u0026rsquo;s Last Exam (HLE) ist einer der schwersten Tests: 2.500 Fragen, die Fachleute geschrieben haben, herausgegeben vom Center for AI Safety und Scale AI. Die Autoren messen auch die Kalibrierung. Als HLE Anfang 2025 erschien, beantworteten die getesteten Modelle nur einen kleinen Teil richtig und gaben trotzdem hohe Sicherheit an. Das sind die aktuellen Spitzenreiter in unseren Daten:\nHumanity\u0026#39;s Last Exam: die 5 besten Modelle #ModellErschienenErgebnis 1GPT 6 Astra OpenAI03.09.202654,8 % 2Fable 5.1 (xhigh) Anthropic01.09.202646,5 % 3Gemini 3.1 Pro Preview (thinking high) Google DeepMind19.02.202646,4 % 4Sonnet 5.5 (xhigh) Anthropic28.09.202646,1 % 5Gemini 3.8 Flash Google DeepMind02.09.202644,5 % Von Fachleuten geschriebene Fragen an der Grenze des menschlichen Wissens aus vielen Gebieten — gebaut, um schwer zu bleiben, nachdem ältere Tests gelöst waren. Daten: Epoch AI, abgerufen am 17.10.2026, Lizenz CC BY 4.0. Alle Modelle: LLM-Datenbank.\nLesen Sie solche Tabellen mit fünf Grenzen im Hinterkopf:\nSättigung. Sobald die besten Modelle nahe an der vollen Punktzahl liegen, trennt ein Benchmark sie nicht mehr. Deshalb entstehen ständig neue, schwerere Tests. Kontamination. Gelangen Testfragen in die Trainingsdaten, überschätzen die Werte, was ein Modell kann. Konstruktvalidität. Ein Benchmark misst seine eigene Aufgabe. Expertenfragen sagen wenig über Ihre Rückgaberegeln. Fehlanreize beim Bewerten. Die meisten Benchmarks geben für „weiß ich nicht“ keinen Punkt, also lohnt sich Raten. Forschende von OpenAI argumentierten 2025, dass dies Halluzinationen belohnt und dass selbstsichere Fehler stärker bestraft werden sollten als ehrliche Unsicherheit (Quelle: Kalai et al., „Why Language Models Hallucinate“, 2025). Modell ist nicht System. Ihr Prompt, Ihre Dokumente und Ihre Tools verändern das Verhalten. Ein Benchmark testet nichts davon. Benchmarks sättigen: Ältere Tests nähern sich der vollen Punktzahl, deshalb lösen neuere, schwerere sie ab. Daten: Epoch AI, CC BY 4.0. Nutzen Sie Benchmarks für eine Vorauswahl — alle Modelle und ihre Ergebnisse stehen in unserer LLM-Datenbank — und testen Sie die Vorauswahl dann mit Ihren eigenen Aufgaben.\nEine eigene Eval-Suite in Schichten aufbauen Eine Eval-Suite ist kein einzelner Test, sondern mehrere Schichten, die zu unterschiedlichen Zeiten laufen:\nEine Eval-Suite in fünf Schichten. Die unteren Schichten laufen öfter und finden mehr von Ihren echten Problemen. Die Benchmark-Vorauswahl grenzt die Modelle ein. Sie läuft einmal pro Modellentscheidung. Ein Golden Set enthält echte Aufgaben mit Referenzantworten. Beim Shop sind das echte Kundenfragen, bereinigt um personenbezogene Daten, mit Antworten aus den aktuellen Regeln. Beginnen Sie mit ein- bis zweihundert Fällen und ergänzen Sie jeden neuen Fehler. Sicherheitstests decken schädliche und harmlose, aber heikle Anfragen ab, dazu Fälle von Prompt Injection und Datenabfluss aus dem Red Teaming, die Angriffsideen aus Teil 2 und Paare mit getauschten Namen für Bias. Robustheitsvarianten wiederholen Fragen aus dem Golden Set als Umformulierung, mit Tippfehlern, in anderen Sprachen und mit langen Verläufen. Die Überwachung im Betrieb prüft Stichproben echter Gespräche und verfolgt Rückmeldungen, Eskalationen und Beschwerden. Jeder Fall braucht außerdem eine Bewertungsmethode. Regeln und exakte Treffer funktionieren bei strukturierten Ausgaben wie einem Bestellstatus. Freier Text braucht einen Vergleich mit der Referenzantwort, durch Menschen oder durch ein zweites Modell als Bewerter. LLM-as-a-Judge skaliert gut, doch solche Bewerter haben bekannte Verzerrungen: Sie bevorzugen die erste von zwei Antworten, längere Antworten und manchmal Antworten aus der eigenen Modellfamilie (Quelle: Zheng et al., NeurIPS 2023). Prüfen Sie jeden Bewerter an einer Stichprobe gegen menschliche Urteile, bevor Sie ihm vertrauen.\nWie viele Testfälle Sie brauchen Ausgaben schwanken, deshalb ist jeder Wert eine Schätzung. Eine Bestehensquote aus 50 Fällen ist viel unsicherer als eine aus 500. Die Abbildung zeigt das 95-%-Konfidenzintervall für eine beobachtete Quote von 90 % bei verschiedenen Stichprobengrößen.\nDieselbe beobachtete Quote sagt mit mehr Testfällen mehr aus. Berechnet mit dem Wilson-Intervall — ein Beispiel, keine Messung. Daraus folgen drei Regeln. Um die Unsicherheit zu halbieren, brauchen Sie etwa viermal so viele Fälle. Ein Unterschied zwischen zwei Modellversionen, der kleiner ist als die Intervalle, kann Rauschen sein statt Fortschritt. Und weil dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann, sollten wichtige Fälle mehrmals laufen; berichten Sie dann eine Quote. Die Statistik dahinter erklärt eine Anleitung von Anthropic zu Fehlerbalken bei Evals ausführlicher (Quelle: Miller, „Adding Error Bars to Evals“, Anthropic, 2024).\nNach dem Start weiter evaluieren Die Evaluation endet nicht mit dem Release. Lassen Sie die Suite automatisch laufen, sobald sich etwas ändert: die Modellversion, der System-Prompt, die Wissensbasis oder ein Tool. Anbieter aktualisieren die Modelle hinter einer API, manchmal unter demselben Namen; darum gehört auch ein fester Zeitplan dazu. Machen Sie aus jedem Vorfall und jeder bestätigten Beschwerde einen neuen Testfall. Legen Sie für jede Kennzahl eine Schwelle fest und stoppen Sie ein Release, wenn eine verfehlt wird — ein einziger kritischer Sicherheitsfehler sollte genügen.\nManche Plattformen unterstützen Teile dieser Arbeit. Nach Angaben des Anbieters bietet Airia Red Teaming zusammen mit Richtlinien und Prüfnachweisen. TestDriver.ai baut nach eigener Beschreibung Regressionstests für Pull Requests, allerdings für Benutzeroberflächen, nicht für Modellverhalten. Wenn Sie Agenten auf einer No-Code-Plattform wie MindStudio bauen, evaluieren Sie den Agenten als Ganzes — Prompts, Tools und Wissen —, nicht nur sein Modell. Bevor Sie sich bei Evals auf eine Plattform verlassen, stellen Sie drei Fragen. Kann sie Ihr eigenes Golden Set ausführen? Kann sie ein Release stoppen, wenn eine Schwelle verfehlt wird? Bewahrt sie die Ergebnisse als Nachweis auf? Wir haben diese Tools nicht getestet.\nFür den Support-Assistenten des Shops sieht der Plan so aus (die Größen sind Beispiele):\nSicherheit und Zuverlässigkeit von Modellen bewerten (2) Testsatz Beispielgröße Kennzahl Freigabeschwelle Läuft Golden Set echter Fragen 200 Fälle Übereinstimmung mit Referenzantworten Kein Rückgang gegenüber dem letzten Release Bei jeder Änderung Fakten aus den Regeln 50 Fälle Exakte Treffer bei Fristen und Gebühren Alle bestanden Bei jeder Änderung Schädliche und heikle Anfragen 100 Fälle Schädliche Antworten; abgelehnte harmlose Anfragen Kein kritischer Fehler Bei jeder Änderung Injection und Datenabfluss 60 Fälle aus dem Red Teaming Befolgte versteckte Anweisungen; abgeflossene Daten Keine Bei jeder Änderung Paare mit getauschten Namen 40 Paare Unterschied in Ergebnis und Ton Kein systematischer Unterschied Monatlich Stichprobe aus dem Betrieb 1 % der Chats Bewertung durch Prüfer, Eskalationen Trend, keine Schwelle Wöchentlich ▸Ihre ersten zehn Golden Cases\nSammeln Sie zehn echte Fragen, die Ihr KI-System letzte Woche bekommen hat. Entfernen Sie personenbezogene Daten. Schreiben Sie zu jeder Frage die richtige Antwort aus Ihren aktuellen Unterlagen und vermerken Sie, welche Quelle sie belegt. Lassen Sie das System jede Frage dreimal beantworten und bewerten Sie die Antworten. Jeder Fehltreffer ist Ihr erster Regressionstest — und der Anfang Ihrer Nachweise für Teil 5.\n","words":1737},"date":"2026-10-14","description":"Wie Sie KI auf Faktentreue, Robustheit, Ablehnungen, Bias und Kalibrierung prüfen, was Benchmarks nicht zeigen und wie Sie eine eigene Eval-Suite betreiben.","image":"https://abxk.ai/images/cover/evaluate-model-safety-and-reliability.webp","json":"https://abxk.ai/de/ai-security/learn/evaluate-model-safety-and-reliability/index.json","kind":"page","language":"de","learning_path":{"category":"ai-security","level":4,"level_name":"Experte"},"modified":"2026-10-14","related_tools":["Airia","TestDriver.ai","MindStudio"],"section":"ai-security","tags":["ki-evaluation","llm-evals","kalibrierung","benchmarks","experte"],"title":"Sicherheit und Zuverlässigkeit von Modellen bewerten","translations":[{"json":"https://abxk.ai/en/ai-security/learn/evaluate-model-safety-and-reliability/index.json","language":"en","url":"https://abxk.ai/en/ai-security/learn/evaluate-model-safety-and-reliability/"}],"url":"https://abxk.ai/de/ai-security/learn/evaluate-model-safety-and-reliability/"}