Stochastische KI-Systeme messen: Warum ein einzelner Testlauf nichts beweist und wie Mehrfachläufe funktionieren

Stand November 2026 · CODLAB Team

Kurzantwort: Weil Sprachmodelle Wahrscheinlichkeitsverteilungen abtasten, beweist eine gelungene Einzelvorführung keine Betriebssicherheit. Belastbare KI-Bewertung erfordert wiederholte Testläufe je Prüffrage (mindestens drei unabhängige Durchläufe zur Varianzschätzung), strikt getrennte Metriken für Dokumentensuche, Quellentreue und Antwortverweigerung sowie automatisierte Regressionsprüfungen vor jedem Modell-, Prompt- oder Indexwechsel.

Das Grundproblem: Deterministische Erwartung trifft auf stochastische Modelle

In der klassischen Unternehmenssoftware gilt eine einfache Prüfregel: Wenn eine Buchungsfunktion für einen definierten Eingabedatensatz den erwarteten Kontostand berechnet, liefert derselbe Aufruf auch beim tausendsten Mal exakt denselben Wert. Ein einziger grüner Integrationstest belegt für diesen konkreten Pfad das Verhalten des Codes.

Große Sprachmodelle (LLMs) und darauf aufbauende Assistenten brechen mit dieser Annahme. Ein generatives Modell berechnet bei jedem Schritt eine Wahrscheinlichkeitsverteilung über das nächste Token. Selbst bei niedriger Sampling-Temperatur (etwa temperature = 0.2 wie im Referenz-Assistenten ragbot im Code von codlab.de — öffentliche Chat-Demo seit Oktober 2026 abgeschaltet — oder sogar nominell 0.0) können minimale Änderungen im Prompt, abweichende Reihenfolgen abgerufener Textblöcke oder Gleitkomma-Rundungseffekte auf GPUs bei parallelem Batching dazu führen, dass eine Antwort im ersten Lauf präzise eine Einschränkung nennt und sie im nächsten Lauf unterschlägt.

In unserer angewandten Forschungs- und Entwicklungsarbeit bei CODLAB für souveräne KI-Systeme trennen wir deshalb strikt zwischen Vorführung und belastbarer Prüfung: Ein System kann in einer Live-Präsentation überzeugend wirken und dennoch bei Randfällen durchfallen. Sowohl das Bundesamt für Sicherheit in der Informationstechnik (BSI, Generative KI-Modelle, Version 2.0, 2025) als auch das Generative-AI-Profil des NIST (NIST AI 600-1, 2024) betonen, dass punktuelle Stichproben keine systematische Messung ersetzen. Wie sieht ein technisch ehrliches Messverfahren für den Mittelstand konkret aus?

1. Glossar und Statistik der Mehrfachläufe: pass@k vs. pass^k

Ein einzelner Durchlauf zieht bei einem probabilistischen System lediglich eine Stichprobe der Größe eins. In der Fachliteratur müssen dabei zwei völlig verschiedene Kennzahlen strikt auseinandergehalten werden: pass@k (eingeführt u. a. für Code-Synthese mit automatischen Unit-Tests, Chen et al., 2021, arXiv:2107.03374) misst die Wahrscheinlichkeit, dass unter k Versuchen mindestens einer gelingt (any) — nützlich nur dann, wenn ein deterministischer Prüfer falsche Kandidaten vor der Anzeige verwirft. Im direkten Nutzerdialog erhält die anfragende Person jedoch genau eine Antwort ohne nachgeschalteten Compiler; maßgeblich ist hier die strikte Durchgängigkeit pass^k (Yao et al., τ-bench, 2024, arXiv:2406.12045), also dass alle k unabhängigen Durchläufe die Prüfkriterien erfüllen (all).

Ebenso wichtig ist die statistische Grenze kleiner Stichproben: Übergibt eine Pipeline eine kritische Sicherheitsbedingung nur mit Einzelwahrscheinlichkeit p = 2/3, bestehen drei unabhängige Läufe dennoch mit einer Wahrscheinlichkeit von (2/3)³ ≈ 29,6 % vollständig fehlerfrei. Drei Läufe je Testfall sind bei CODLAB daher eine pragmatische Entwicklungsuntergrenze, um grobe Instabilitäten früh zu sehen — keine statistische Garantie. Vor produktiven Freigaben sind größere Laufzahlen mit ausgewiesener Unsicherheit erforderlich, wobei wir zwei Versuchsarten sauber trennen:

• Identische Wiederholungen bei festem Kontext (Sampling-Varianz): Exakt dieselbe Anfrage gegen denselben eingefrorenen Retrieval-Stand prüft, ob zwingende Bedingungen (Fristen, Grenzwerte, Zuständigkeiten) und Quellenverweise über alle k Läufe erhalten bleiben.
• Kontrollierte Paraphrasen-Experimente (Eingabe-Sensitivität): Getrennt von der reinen Wiederholung variieren wir gezielt die Formulierung derselben Fachfrage (Umgangssprache, Abkürzung, Tippfehler), um die Empfindlichkeit von Retrieval und Antwort getrennt auszuweisen.

# Methodisches Muster (check_domain_criteria steht stellvertretend für projektspezifische Prüfer):
# Strikte Trennung zwischen mindestens einem Treffer (pass@k) und allen Läufen korrekt (pass^k)
def evaluate_case_stability(pipeline_fn, test_case, k=3):
    outcomes = []
    for run_idx in range(k):
        result = pipeline_fn(test_case.query)
        outcomes.append({
            "run": run_idx + 1,
            "retrieved_urls": [s["url"] for s in result["sources"]],
            "grounded": result["grounded"],
            "passes_rubric": check_domain_criteria(result["answer"], test_case.criteria),
        })
    flags = [item["passes_rubric"] for item in outcomes]
    return {
        "any_passed_at_k": any(flags),   # pass@k-Logik: mindestens 1 Erfolg
        "all_passed_hat_k": all(flags),  # pass^k-Logik: alle k Läufe fehlerfrei
        "pass_rate": sum(flags) / k,
        "runs": outcomes,
    }

2. Vier getrennte Diagnoseebenen statt einer einzigen Gesamtnote

Eine pauschale Prozentzahl wie „der Bot ist zu X Prozent genau" ist technisch wertlos, weil sie unterschiedliche Fehlerursachen vermischt. Aufbauend auf Evaluationsrahmen wie RAGAS (Es et al., 2023/2024, arXiv:2309.15217), selbstkritischen Abrufarchitekturen (Asai et al., Self-RAG, arXiv:2310.11511) und unserer Notiz RAG bewerten: Retrieval und Antworten getrennt zerlegen wir die Diagnose in vier getrennte Ebenen (die im Betrieb kausal zusammenhängen, aber getrennt gemessen werden müssen):

1. Retrieval-Vollständigkeit (Recall@k): Befindet sich die fachlich erforderliche Referenzpassage überhaupt unter den k abgerufenen Textblöcken? Fehlt sie hier, müssen Chunking, Metadatenfilter oder hybride Suche korrigiert werden — nicht der Systemprompt.
2. Kontext-Präzision (Context Precision / Signal-Rausch-Verhältnis): Wie hoch ist der Anteil tatsächlich relevanter Absätze im übergebenen Kontext? Zu viele irrelevante Nachbarabschnitte erhöhen die Gefahr von Verwechslungen zwischen ähnlichen Produkten oder Richtlinien.
3. Quellentreue (Faithfulness / Grounding): Stützt sich jede einzelne Behauptung der generierten Antwort ausschließlich auf den übergebenen Kontext, ohne externe Annahmen hinzuzudichten oder dokumentierte Ausnahmen wegzulassen?
4. Enthaltungs- und Abgrenzungsgenauigkeit (Refusal Accuracy): Erkennt das System unbeantwortbare Fragen, gesperrte Wissensbereiche und mehrdeutige Revisionsstände zuverlässig und verweigert die Spekulation?

Erst diese Vierteilung macht Optimierungen ingenieurmäßig steuerbar: Wenn der Wechsel auf ein anderes Embedding-Modell den Recall@5 verbessert, aber gleichzeitig ähnlich klingende Altversionen in den Kontext zieht und dadurch die Quellentreue senkt, wird dieser Zielkonflikt sofort in den Zahlen sichtbar.

3. Chancen und Grenzen von „LLM-as-a-Judge"

Weil eine rein manuelle Prüfung Hunderter Antworten nach jeder Konfigurationsänderung im Projektalltag kaum durchzuhalten ist, setzen viele Teams ein zweites Sprachmodell als automatischen Bewerter ein („LLM-as-a-Judge"). Lianmin Zheng et al. haben dieses Verfahren systematisch untersucht und neben seiner Skalierbarkeit auch seine charakteristischen Verzerrungen dokumentiert (Zheng et al., NeurIPS 2023, arXiv:2306.05685):

• Verbosity Bias (Längenverzerrung): Automatische Bewerter bevorzugen häufig ausführlichere, wohlklingend gegliederte Antworten — selbst dann, wenn eine knappe Antwort fachlich präziser ist oder die längere Fassung unbelegte Details ergänzt.
• Position Bias (Reihenfolgeverzerrung): Bei paarweisen Vergleichen zwischen Variante A und Variante B hängt das Urteil spürbar davon ab, welche Antwort zuerst im Prompt steht.
• Self-Enhancement Bias (Modellverwandtschaft): Modelle bewerten Ausgaben aus derselben Modellfamilie oft wohlwollender als fremde Formulierungen.

In unserer Methodik bei CODLAB gelten für automatisierte Bewerter deshalb strenge Leitplanken: Erstens ersetzen wir überall dort, wo es möglich ist, offene Modellurteile durch deterministische Vorprüfungen (Vorhandensein erwarteter Quell-URLs, Einhaltung des Enthaltungspfads, Ausschluss verbotener Zusagen oder Preisangaben). Zweitens prüfen Richter-Prompts keine vagen Noten von 1 bis 10, sondern binäre Einzelkriterien („Enthält die Antwort den Hinweis auf die schriftliche Freigabepflicht: Ja/Nein?"). Drittens wird jedes automatisierte Bewertungsraster vorab an einer von Fachpersonen geprüften Stichprobe kalibriert; bei Paarvergleichen wird die Reihenfolge systematisch gedreht.

4. Deterministische Gates und statistische Gates gemeinsam denken

Ein produktives KI-System besteht nie nur aus dem Sprachmodell. Rund um den Modellaufruf liegen Web-Oberflächen, Formulare, API-Ratenbegrenzungen, Mandantenfilter und Zitationsanzeigen. In unseren Engineering Notes zeigen wir am Beispiel von Playwright und axe: ein Test, der rot werden kann ein zentrales Qualitätsprinzip von CODLAB: Ein Test hat nur dann Wert, wenn er bei einem echten Fehler nachweislich rot wird.

Dieses Prinzip übertragen wir auf hybride Prüfpipelines aus deterministischen und statistischen Schranken:

• Deterministische Schranken (0 % Fehlertoleranz): Zugriffsschutz zwischen Mandanten, Same-Origin-Prüfung am API-Endpunkt, Einhaltung der Distanzschwelle bei leerer Quellenlage, gültige Strukturdaten, Tastaturbedienbarkeit und Kontrastwerte auf Mobil- und Desktop-Ansichten. Ein einziger Fehlschlag blockiert die Auslieferung sofort.
• Statistische Schranken (definierte Mindestschwellen über Mehrfachläufe): Für einen kuratierten Katalog aus Fachfragen, Randfällen und Gegenbeispielen wird bei jedem Wechsel von Prompt, Chunking-Logik oder Modellversion gemessen, ob Recall@k, Enthaltungsquote und Kriterientreue über mindestens drei Läufe hinweg stabil bleiben. Verschlechtert eine Änderung eine Fehlerklasse (z. B. fehlende Warnhinweise), wird das Update gestoppt und die betroffene Frage dauerhaft in den Regressionskatalog aufgenommen.

5. Synthetisches Praxisbeispiel: Versionswechsel ohne Blindflug

Hinweis zur Einordnung: Das folgende Beispiel ist vollständig synthetisch und dient ausschließlich der Veranschaulichung der Prüfmethodik. Es beschreibt kein konkretes Kundenprojekt und keine erhobenen Kundenkennzahlen.

Betrachten wir ein fiktives mittelständisches Prüflabor, das einen internen Assistenten zur Recherche in Qualitätsmanagement-Verfahrensanweisungen nutzt. Nach sechs Monaten Betrieb soll das bisherige Sprachmodell durch ein neueres, kompakteres Open-Weights-Modell abgelöst werden, um die Antwortzeit auf dem eigenen Server zu verkürzen. Ohne strukturiertes Messprotokoll würde das Team zehn spontane Testfragen eingeben, schnellere Antworten beobachten und umstellen.

Mit einem reproduzierbaren Evaluationslauf sieht die Entscheidung anders aus:

1. Der bestehende Prüfkatalog umfasst 60 dokumentierte Fachfragen: 35 Standardfragen mit eindeutiger Fundstelle, 10 Fragen zu Dokumenten mit jüngst geänderter Ausnahmeregelung und 15 Fragen außerhalb der freigegebenen Verfahrensanweisungen.
2. Beide Modellvarianten durchlaufen denselben eingefrorenen Retrieval-Index in jeweils drei unabhängigen Durchläufen pro Frage (180 Auswertungen je Modell).
3. Die Auswertung zeigt im fiktiven Szenario: Das kompaktere Modell antwortet zwar schneller und besteht die Standardfragen im ersten Lauf, ignoriert aber in den Wiederholungsläufen bei widersprüchlichen Entwurfs- und Freigabevermerken häufiger den Gültigkeitsstatus.
4. Statt das Risiko in den Fachbereich zu verlagern, erkennt das Team die Ursache vor der Freigabe: Entweder werden ungültige Entwürfe bereits im Datenbankfilter strikt ausgeschlossen oder das größere Modell bleibt im Einsatz.

Genau diese laufende Kontrolle nach Updates, Dokumentänderungen und Modellwechseln ist Bestandteil eines verantwortungsvollen KI-Betriebs, wie wir ihn unter Betrieb & Wartung für KI-Systeme beschreiben. Wenn Sie prüfen möchten, wie sich ein geplanter oder bestehender KI-Assistent in Ihrem Unternehmen objektiv messen lässt, sprechen Sie uns gerne über Kontakt & Erstgespräch an.

Weiterführend in dieser Forschungsreihe: Wie die vorgelagerte Suchpipeline die gemessenen Retrieval-Kennzahlen bestimmt, erläutert unser Auftaktbeitrag zu Hybrid Retrieval, Chunking und Cross-Encoder-Reranking; wie dieselben Mehrfachlauf-Metriken wie pass^k auf mehrstufige Werkzeugaufrufe angewendet werden, zeigt die Analyse zu kontrollierten KI-Agenten und deterministischen Leitplanken.

Verifizierte Primärquellen

• Chen, M., Tworek, J., Jun, H. et al. (2021): Evaluating Large Language Models Trained on Code (arXiv:2107.03374).
• Yao, S., Shinn, N., Razavi, P. & Narasimhan, K. (2024): τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045).
• Es, S., James, J., Espinosa-Anke, L. & Schockaert, S. (2023/2024): RAGAS: Automated Evaluation of Retrieval Augmented Generation (EACL 2024, arXiv:2309.15217).
• Zheng, L. et al. (2023): Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023, arXiv:2306.05685).
• Asai, A. et al. (2023/2024): Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (ICLR 2024, arXiv:2310.11511).
• National Institute of Standards and Technology (2024): Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1).
• Bundesamt für Sicherheit in der Informationstechnik (2025): Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden, Version 2.0 vom 17.01.2025.

Ergänzender Praxisleitfaden im Blog: KI im Unternehmen einführen: Vom Arbeitsauftrag zur überprüfbaren Freigabe.