Der Prototyp läuft, die Demo begeistert – und dann kommt die Frage, an der die meisten KI-Projekte scheitern: Woher wissen wir eigentlich, dass das Ding richtig antwortet? Wer darauf keine messbare Antwort hat, verhandelt am Ende über Geschmack statt über Qualität.
Dieser Artikel ist ein vertiefender Fachbeitrag aus unserem Content-Cluster. Entdecken Sie die vollständige Übersicht auf unserer Hauptseite:KI-Automatisierung für Unternehmen →
- Der Prototyp beweist nichts: Eine überzeugende Demo zeigt, dass ein KI-System antworten kann – nicht, dass es zuverlässig richtig antwortet. Zwischen beidem liegt die gesamte Qualitätssicherung, und genau dort scheitern die meisten Projekte auf dem Weg in den Betrieb.
- Getrennt messen statt pauschal bewerten: Bei RAG-Systemen sind Retrieval und Generierung zwei verschiedene Fehlerquellen. Wer nur die Endantwort bewertet, weiß im Fehlerfall nicht, ob die Quelle nicht gefunden oder die gefundene Quelle falsch verarbeitet wurde – und repariert an der falschen Stelle.
- Ein Score macht den Festpreis erst sauber: Abnahme über einen definierten Schwellenwert auf einem vorab gemeinsam festgelegten Testset ersetzt die endlose Diskussion über Geschmack. Beide Seiten wissen vorher, wann das Projekt fertig ist.
Die Frage nach der Demo
Sprachmodelle sind 2026 kein Machbarkeitsthema mehr. Der Engpass hat sich verschoben: Nicht das Bauen ist schwer, sondern der Nachweis, dass das Gebaute im Alltag trägt. Evals sind das Werkzeug, das diesen Nachweis liefert – und die Grundlage jeder belastbaren Abnahme.
1. Die Frage, die nach dem Prototyp kommt
Es gibt einen Moment in jedem KI-Projekt, der sich zuverlässig wiederholt. Der Prototyp läuft. Die Demo im Meeting funktioniert. Jemand stellt drei Fragen, das System antwortet flüssig und plausibel, im Raum wird genickt. Und dann sagt jemand aus der Fachabteilung den einen Satz, der die Stimmung kippen lässt: „Und woher wissen wir, dass das immer stimmt?"
Diese Frage ist vollkommen berechtigt, und sie ist der eigentliche Beginn des Projekts. Denn eine Demo beweist Machbarkeit, nicht Zuverlässigkeit. Sie zeigt, dass das System auf drei ausgewählte Fragen eine gute Antwort produziert hat. Über die vierhundertsten Frage eines Sachbearbeiters an einem Dienstagnachmittag sagt sie nichts.
Der Unterschied ist fundamental, und er hat einen technischen Grund. Klassische Software ist deterministisch: Gleiche Eingabe, gleiche Ausgabe, jedes Mal. Ein Sprachmodell ist das nicht. Es produziert Wahrscheinlichkeiten, keine Gewissheiten. Dieselbe Frage kann zwei Formulierungen hervorbringen, von denen eine korrekt ist und die andere subtil daneben liegt. Damit lässt sich arbeiten – aber nicht mit Methoden, die für deterministische Systeme gebaut wurden.
Wer diese Lücke nicht schließt, bezahlt sie später. Meist auf drei Arten:
Vertrauensverlust im Betrieb
Ein einziger sichtbar falscher Output in einer Fachabteilung reicht, damit ein System intern als unzuverlässig gilt. Danach nutzt es niemand mehr freiwillig – unabhängig davon, wie gut die Trefferquote objektiv ist. Ohne Messwerte lässt sich dieser Eindruck auch nicht widerlegen.
Änderungen als Blindflug
Jede Prompt-Anpassung, jeder Modellwechsel, jede neue Datenquelle verändert das Verhalten – auch dort, wo vorher alles funktionierte. Ohne Testset merkt das niemand. Der Fehler fällt Wochen später auf, und dann weiß niemand mehr, welche der zwölf Änderungen ihn verursacht hat.
Die Abnahme wird zur Verhandlung
Ohne vereinbartes Qualitätsmaß entscheidet der subjektive Eindruck darüber, ob geliefert wurde. Das ist für beide Seiten schlecht: Der Auftraggeber hat keine Handhabe, der Dienstleister kein Ende. Nachbesserungsschleifen ohne Zielmarke sind der häufigste Grund, warum KI-Festpreisprojekte defizitär enden.
Die gute Nachricht: Das Problem ist gelöst, die Werkzeuge existieren, und sie sind nicht besonders exotisch. Sie heißen Evals.
2. Was ein Eval ist – und was es von einem Unit-Test unterscheidet
Ein Eval ist ein reproduzierbarer Testlauf, der die Ausgabe eines KI-Systems gegen ein festes Set aus Eingaben und geprüften Referenzantworten bewertet. Sie geben dem System hundert oder tausend echte Anfragen, vergleichen die Antworten mit dem, was richtig gewesen wäre, und erhalten am Ende eine Zahl.
Diese Zahl ist der entscheidende Punkt. Ein Eval sagt nicht „korrekt" oder „falsch". Es sagt: in 94 von 100 Fällen ausreichend, in 4 Fällen unvollständig, in 2 Fällen sachlich falsch. Damit lässt sich arbeiten – man kann sie mit dem Wert von letzter Woche vergleichen, einen Schwellenwert festlegen und über Verbesserungen reden, ohne über Eindrücke zu reden.
Unit-Test vs. Eval
- Ergebnis: Binär – bestanden oder nicht bestanden.
- Erwartung: Exakt definiert. Eine Abweichung um ein Zeichen ist ein Fehler.
- Reproduzierbarkeit: Vollständig. Derselbe Input liefert immer denselben Output.
- Ein Fehlschlag heißt: Der Code ist kaputt, repariere ihn.
- Aussagekraft: Ein einzelner Fall genügt als Beweis.
- Ergebnis: Ein Score über viele Fälle, meist als Anteil oder Durchschnitt.
- Erwartung: Ein Korridor. Mehrere Formulierungen können gleichermaßen richtig sein.
- Reproduzierbarkeit: Eingeschränkt. Auch bei Temperature 0 schwanken Ergebnisse zwischen Modellversionen.
- Ein Abfall heißt: Das Verhalten hat sich verschoben, untersuche die Ursache.
- Aussagekraft: Erst die Menge trägt. Einzelne Fälle sind Anekdoten.
Aus diesem Unterschied folgt die wichtigste organisatorische Konsequenz: Ein Eval braucht eine Datengrundlage, die jemand mit Fachwissen erstellt hat. Diese Grundlage heißt Golden Dataset – ein kuratiertes, versioniertes Set aus realen Anfragen und fachlich freigegebenen Referenzantworten.
Hier liegt in der Praxis die eigentliche Arbeit. Nicht das Schreiben des Eval-Codes ist aufwendig – das sind überschaubare Skripte. Aufwendig ist, fünfzig bis zweihundert echte Fälle zu sammeln und von jemandem prüfen zu lassen, der das Fachgebiet beherrscht. Diesen Aufwand sollte man nicht verstecken, sondern offen als Projektposition ausweisen. Er ist die Investition, die alles Folgende überhaupt erst messbar macht.
Experten-Tipp: Fangen Sie mit dreißig Fällen an
Ein perfektes Testset mit tausend Einträgen wird nie fertig, weil der Aufwand vor dem Nutzen liegt. Dreißig sorgfältig ausgewählte Fälle – zehn typische, zehn schwierige, zehn Grenzfälle, an denen das System scheitern soll – liefern bereits ein belastbares Signal und lassen sich an einem Vormittag zusammenstellen. Das Set wächst danach mit jedem echten Fehler, der im Betrieb auftritt: Jede Beschwerde wird zu einem neuen Testfall.
3. RAG-Evaluation: Retrieval und Generierung getrennt messen
Die meisten produktiven KI-Systeme im Unternehmenskontext sind keine reinen Sprachmodelle, sondern RAG-Systeme: Sie suchen zuerst passende Dokumente aus einer Wissensbasis und lassen das Modell die Antwort anschließend aus diesen Dokumenten formulieren. Wie so ein System aufgebaut wird, haben wir im Detail in unserem Leitfaden zum lokalen Enterprise RAG mit pgvector beschrieben.
Für die Qualitätssicherung ist entscheidend, dass ein RAG-System zwei unabhängige Fehlerquellen hat. Und wer nur die Endantwort bewertet, kann sie nicht auseinanderhalten.
Ein RAG-System kann bei perfekter Generierung trotzdem falsch antworten – weil das Retrieval danebengegriffen hat. Und es kann die richtige Quelle finden und daraus trotzdem Unsinn machen. Wer nur das Ende misst, repariert die falsche Hälfte.
Deshalb braucht die Bewertung zwei getrennte Messpunkte:
Retrieval-Qualität – findet das System die richtige Stelle? Gemessen wird, ob unter den zurückgelieferten Dokumenten das tatsächlich relevante enthalten ist. Die gängige Kennzahl ist Recall@k: der Anteil der Testfragen, bei denen das richtige Dokument unter den ersten k Treffern auftaucht. Ergänzend zeigt Precision, wie viel Ballast das System mitliefert – jedes irrelevante Dokument im Kontext ist eine zusätzliche Gelegenheit für das Modell, sich zu verlaufen.
Generierungs-Qualität – macht das System daraus die richtige Antwort? Hier wird bewertet, ob die formulierte Antwort die Frage tatsächlich beantwortet und ob sie durch den gelieferten Kontext gedeckt ist. Diese zweite Prüfung ist die eigentliche Halluzinations-Kontrolle und bekommt im nächsten Kapitel ein eigenes Maß.
Diese Trennung hat einen sehr praktischen Nutzen: Sie sagt Ihnen, wo Sie ansetzen müssen. Ein niedriger Recall ist ein Datenproblem – die Chunking-Strategie passt nicht, die Dokumente sind schlecht strukturiert, oder es fehlt ein Reranking-Schritt, der die Vorauswahl sortiert. Am Prompt zu drehen hilft in diesem Fall überhaupt nicht. Umgekehrt ist eine schlechte Antwort bei perfekt gefundenem Dokument ein Prompt- oder Modellproblem, und die Wissensbasis umzubauen wäre verschwendete Zeit.
Die typischen Metriken im Überblick:
Recall@k
Anteil der Testfragen, bei denen das relevante Dokument unter den ersten k Treffern liegt. Die wichtigste Retrieval-Kennzahl: Was nicht gefunden wird, kann auch nicht korrekt beantwortet werden. Übliche Messpunkte sind k=3 und k=10.
Precision
Anteil tatsächlich relevanter Dokumente unter allen gelieferten. Ein hoher Recall bei niedriger Precision bedeutet: Das System findet die Antwort, vergräbt sie aber unter Beifang – teuer in Tokens und riskant für die Genauigkeit.
Groundedness / Faithfulness
Ist jede Aussage der Antwort im gelieferten Kontext gedeckt? Diese Metrik fängt genau die Fälle, in denen das Modell Trainingswissen einstreut, statt sich an die Quelle zu halten – der häufigste Halluzinationstyp im RAG-Betrieb.
Answer Relevancy
Beantwortet die Ausgabe die gestellte Frage – oder eine benachbarte? Ein Modell kann eine sachlich einwandfreie, vollständig belegte Antwort auf eine Frage geben, die niemand gestellt hat. Ohne dieses Maß bleibt das unsichtbar.
Vollständigkeit
Enthält die Antwort alle wesentlichen Punkte der Referenzantwort? Besonders relevant bei mehrteiligen Fragen: Eine Antwort, die nur die erste Hälfte behandelt, ist nicht falsch, aber unbrauchbar – und fällt in einer reinen Korrektheitsprüfung nicht auf.
Verweigerungsrate
Wie oft sagt das System korrekt „das weiß ich nicht"? Ein oft übersehenes Maß: Ein System, das nie verweigert, halluziniert bei jeder Frage außerhalb seiner Wissensbasis. Grenzfälle im Testset, die eine Verweigerung erwarten, machen das messbar.
4. Halluzinations-Kontrolle: Groundedness, Guardrails, Human-in-the-Loop
Der Begriff Halluzination wird meist zu unscharf verwendet. Für die Qualitätssicherung ist eine präzisere Unterscheidung nötig, denn die verschiedenen Fehlertypen verlangen unterschiedliche Gegenmaßnahmen.
Die praktisch wichtigste Trennlinie verläuft zwischen sachlich falsch und nicht gedeckt. Eine Antwort kann sachlich vollkommen korrekt sein und trotzdem ein Problem darstellen – nämlich dann, wenn das Modell die Information aus seinem Trainingswissen ergänzt hat, statt sie aus den bereitgestellten Firmendokumenten zu ziehen. Im Zweifel steht dann allgemeines Internetwissen in einer Antwort, die aussieht, als käme sie aus dem Qualitätshandbuch des Unternehmens.
Genau das misst Groundedness: Für jede einzelne Aussage der Antwort wird geprüft, ob sie im gelieferten Kontext belegt ist. Das Verfahren dahinter ist mechanisch – die Antwort wird in Einzelaussagen zerlegt, jede Aussage gegen den Kontext gehalten, das Ergebnis aggregiert.
Die Bewertung von Groundedness lässt sich nicht sinnvoll mit Stringvergleichen machen – dafür ist Sprache zu variabel. Der gängige Weg ist LLM-as-a-Judge: Ein zweites Modell bekommt Kontext, Antwort und eine präzise Kriterienliste und benotet.
Dieses Verfahren skaliert hervorragend und hat eine Schwäche, über die man reden muss: Der Judge ist selbst ein Sprachmodell. Er kann dieselben systematischen Fehler machen wie das geprüfte System, neigt zu Milde bei ausführlich formulierten Antworten und bevorzugt messbar Texte, die stilistisch zu seinem eigenen Ausgabestil passen. Ein unkalibrierter Judge produziert Zahlen, die vertrauenswürdig aussehen und es nicht sind.
Experten-Tipp: Den Judge gegen Menschen eichen
Bevor Sie einem LLM-Judge Ihre Abnahme anvertrauen, lassen Sie ihn und einen Fachmenschen dieselben dreißig bis fünfzig Fälle unabhängig bewerten. Vergleichen Sie die Übereinstimmung. Weichen die Urteile systematisch ab, schärfen Sie die Kriterienliste nach – meist fehlen konkrete Beispiele für „gut" und „unzureichend" im Judge-Prompt. Diese Eichung wiederholen Sie bei jedem Modellwechsel des Judges. Ohne sie messen Sie die Meinung eines Modells, nicht die Qualität Ihres Systems.
Neben der Messung braucht produktiver Betrieb zwei weitere Ebenen. Guardrails greifen zur Laufzeit: Sie prüfen die Antwort, bevor der Nutzer sie sieht, und blockieren oder eskalieren bei zu niedriger Groundedness, bei fehlenden Quellenangaben oder bei Themen außerhalb des zugelassenen Bereichs. Und Human-in-the-Loop bleibt überall dort Pflicht, wo eine falsche Antwort echten Schaden anrichtet – bei rechtlichen Auskünften, medizinischen Angaben oder verbindlichen Preiszusagen. Dass Verifikation der eigentliche Engpass autonomer Systeme ist, gilt für Wissensagenten genauso wie für die Coding-Agenten in der Softwareentwicklung.
5. Regressionstests für Prompts: Golden Dataset und CI
Prompts sind Quellcode. Sie steuern Verhalten, sie haben Versionen, sie brechen bei Änderungen. Behandelt werden sie in der Praxis aber häufig wie Notizzettel: irgendwo im Code eingebettet, ohne Historie, geändert per Zuruf im Chat.
Das ist deshalb gefährlich, weil Prompt-Änderungen nichtlokale Wirkung haben. Sie fügen einen Satz hinzu, um ein bestimmtes Verhalten zu korrigieren – und verändern damit die Antworten auf sämtliche anderen Anfragen mit. In klassischem Code hat eine Änderung einen abgegrenzten Wirkungsbereich, den man lesen kann. Bei einem Prompt gibt es diesen Bereich nicht.
Dasselbe gilt für Modellwechsel. Ein Upgrade auf eine neuere Modellversion ist keine reine Verbesserung, sondern eine Verhaltensänderung: Einige Fälle werden besser, einige schlechter, und ohne Messung wissen Sie nicht, welche. Genau dafür existiert der Regressionstest.
Der Aufbau ist unspektakulär und in wenigen Tagen erledigt:
-
Prompts aus dem Code herauslösen
Jeder Prompt bekommt eine eigene, versionierte Datei mit klarer Kennung. Damit wird jede Änderung im Diff sichtbar, und Sie können im Fehlerfall nachvollziehen, welche Fassung wann produktiv war. Das ist die Voraussetzung für alles Weitere – ohne sie lässt sich ein Verhaltensbruch nicht zuordnen.
-
Golden Dataset anlegen und versionieren
Das Testset liegt als strukturierte Datei im Repository neben dem Code, nicht in einer Tabelle auf einem Netzlaufwerk. Jeder Eintrag enthält die Anfrage, die erwartete Antwort, das erwartete Quelldokument und die Angabe, welche Kriterien für diesen Fall gelten. Grenzfälle, bei denen eine Verweigerung die richtige Antwort ist, gehören ausdrücklich dazu.
-
Eval-Lauf als Skript automatisieren
Ein Kommando spielt das gesamte Testset gegen das System, berechnet die Metriken aus Kapitel 3 und schreibt das Ergebnis als maschinenlesbaren Bericht. Wichtig ist, den Lauf reproduzierbar zu halten: feste Modellversion, feste Parameter, protokollierte Konfiguration. Sonst vergleichen Sie später Zahlen, die nicht vergleichbar sind.
-
Schwellenwerte definieren und in CI verankern
Der Eval-Lauf läuft bei jeder Änderung an Prompt, Modell oder Wissensbasis automatisch mit. Unterschreitet ein Score die vereinbarte Schwelle, wird die Änderung nicht übernommen. Damit ist Qualität keine Frage der Disziplin mehr, sondern eine technische Bedingung – dieselbe Verschiebung, die Unit-Tests vor zwanzig Jahren für klassische Software gebracht haben.
-
Betriebsfehler zurück ins Testset führen
Jede berechtigte Beschwerde aus dem Betrieb wird zu einem neuen Fall im Golden Dataset – mit der korrekten Antwort daneben. So wächst die Messlatte mit dem System, und derselbe Fehler kann nicht zweimal unbemerkt auftreten. Dieser Rückkanal ist der Unterschied zwischen einem Testset, das altert, und einem, das besser wird.
Ein Hinweis zu den Kosten, weil er in Angeboten regelmäßig fehlt: Ein Eval-Lauf über zweihundert Fälle mit LLM-as-a-Judge verursacht echte API-Kosten, und zwar bei jedem Durchlauf. Das ist bei den heutigen Preisen kein Ausschlusskriterium, aber es gehört kalkuliert – gerade wenn der Lauf bei jedem Commit ausgelöst wird. Eine übliche Aufteilung ist ein kleines, schnelles Set bei jeder Änderung und der vollständige Lauf einmal täglich oder vor jedem Release. Wie sich solche laufenden Posten in eine ehrliche Wirtschaftlichkeitsrechnung einfügen, behandelt unser Beitrag zum messbaren ROI von KI-Projekten.
6. Vom Eval zum Abnahmekriterium im Festpreis-Angebot
Jetzt zum kaufmännischen Teil, der aus alldem erst einen Vorteil macht. Ein Festpreis funktioniert nur, wenn beide Seiten vorher wissen, wann die Leistung erbracht ist. Bei klassischer Software ist das unstrittig: Die Funktion existiert oder nicht. Bei einem KI-System, dessen Qualität graduell ist, fehlt dieser Punkt – es sei denn, man schafft ihn.
Genau das leisten Evals. Sie verwandeln eine Geschmacksfrage in eine Zahl, und Zahlen lassen sich in einen Vertrag schreiben. Aus „die Antworten sollen gut sein" wird ein prüfbares Abnahmekriterium.
Nicht der Eval-Score schützt den Festpreis, sondern die Tatsache, dass beide Seiten ihn vor Projektbeginn gemeinsam festgelegt haben. Ein Testset, das erst bei der Abnahme entsteht, ist eine Waffe – eines, das am Anfang steht, ist ein Vertrag.
Praktisch heißt das: Das Golden Dataset wird zur ersten Projektphase, nicht zur letzten. Auftraggeber und Dienstleister setzen sich zusammen, sammeln reale Anfragen, formulieren die erwarteten Antworten und einigen sich auf die Schwellenwerte. Das dauert einen Tag bis eine Woche, je nach Fachgebiet – und es ist der wertvollste Termin im gesamten Projekt. Denn dabei stellt sich regelmäßig heraus, dass die Fachabteilung selbst uneinig ist, was die richtige Antwort wäre. Diese Erkenntnis vor dem Bauen zu haben, ist Gold wert.
Vier Punkte, die in eine belastbare Abnahmeklausel gehören:
Das Testset ist benannt und eingefroren
Umfang, Herkunft und Version des Golden Datasets stehen im Angebot. Es wird vor Umsetzungsbeginn gemeinsam freigegeben und danach nicht mehr einseitig erweitert. Spätere Ergänzungen sind möglich – aber als beauftragte Änderung, nicht als stillschweigende Verschärfung der Messlatte.
Die Schwellenwerte sind pro Metrik beziffert
Nicht ein Gesamtwert, sondern getrennte Schwellen für Retrieval und Generierung – sonst kann eine schwache Hälfte von einer starken verdeckt werden. Welche Höhe angemessen ist, hängt vom Anwendungsfall ab und wird bei der Testset-Erstellung festgelegt, nicht aus einer Tabelle abgeschrieben.
Das Messverfahren ist beschrieben
Wer misst, womit, mit welchem Judge-Modell und welcher Kriterienliste? Läuft die Messung beim Auftragnehmer oder beim Auftraggeber? Ohne diese Festlegung streitet man bei der Abnahme nicht über die Qualität, sondern über die Messung – ein deutlich unangenehmerer Streit.
Der Umgang mit Nichterreichung ist geregelt
Was passiert, wenn die Schwelle knapp verfehlt wird – Nachbesserung mit Frist, Teilabnahme, Minderung? Und was gilt, wenn die Ursache in gelieferten Daten liegt, deren Qualität der Auftragnehmer nicht verantwortet? Diese Fälle vorher zu klären kostet einen Absatz und spart im Ernstfall Wochen.
Der letzte Punkt verdient Nachdruck, weil er die häufigste Konfliktquelle ist. Die Qualität eines RAG-Systems hängt unmittelbar an der Qualität der zugelieferten Dokumente. Sind diese widersprüchlich, veraltet oder unstrukturiert, sinkt der Score – ohne dass der Dienstleister etwas falsch gemacht hätte. Eine saubere Klausel trennt deshalb die Verantwortungsbereiche und macht die Datengrundlage zur Mitwirkungspflicht des Auftraggebers.
Quick-Check: Ist Ihr KI-Projekt abnahmefähig?
Fazit
Die Frage nach dem Prototyp – woher wissen wir, dass das stimmt? – ist kein Misstrauensvotum, sondern der Übergang vom Experiment zum Produkt. Wer sie mit einer weiteren Demo beantwortet, verschiebt das Problem nur. Wer sie mit einem Score auf einem gemeinsam definierten Testset beantwortet, hat das Projekt auf ein Fundament gestellt, das Änderungen, Modellwechsel und Betriebsjahre überlebt.
Der Aufwand dafür ist überschaubar und liegt fast vollständig in der fachlichen Vorarbeit: reale Fälle sammeln, richtige Antworten festlegen, Schwellen vereinbaren. Der Eval-Code selbst ist ein Nachmittag. Was diese Vorarbeit aber verändert, ist die Natur des Projekts. Aus einem offenen Auftrag mit unklarem Ende wird eine Werkleistung mit definierter Abnahme – und genau das ist die Voraussetzung dafür, dass ein Festpreis für beide Seiten fair ist.
Ein KI-System ohne Evals ist kein fertiges Produkt. Es ist eine Demo, die im Betrieb steht.
Unsere Expertise vor Ort
Wir sind Ihr digitaler Partner – regional verankert und überregional erfolgreich.
Haben Sie eine Vision?
Lassen Sie uns gemeinsam prüfen, wie wir Ihre Idee zum Fliegen bringen.
Jetzt kostenloses Strategiegespräch buchenErweitertes Fachglossar
Eval
Ein reproduzierbarer Testlauf, der die Ausgabe eines KI-Systems gegen ein festes Set aus Eingaben und geprüften Referenzantworten bewertet. Anders als ein Unit-Test liefert ein Eval keine Ja/Nein-Antwort, sondern einen Score über viele Fälle hinweg – die Aussage lautet also nicht 'korrekt', sondern 'in 94 von 100 Fällen ausreichend'.
Golden Dataset
Ein kuratiertes, versioniertes Testset aus realen Anfragen und fachlich freigegebenen Referenzantworten. Es ist die Messlatte jedes Evals: Ohne Golden Dataset gibt es keinen Vergleichswert, gegen den sich Verbesserung oder Regression überhaupt feststellen ließe.
Groundedness
Das Maß dafür, ob jede Aussage einer KI-Antwort tatsächlich durch die mitgelieferten Quelldokumente gedeckt ist. Eine Antwort kann sachlich richtig und trotzdem nicht grounded sein – nämlich dann, wenn das Modell die Information aus seinem Trainingswissen ergänzt statt aus dem bereitgestellten Kontext.
LLM-as-a-Judge
Ein Bewertungsverfahren, bei dem ein zweites Sprachmodell die Antwort des Produktivmodells anhand einer festen Kriterienliste benotet. Es skaliert die Bewertung auf tausende Fälle, muss aber selbst gegen menschliche Urteile kalibriert werden, weil der Judge dieselben systematischen Fehler machen kann wie das geprüfte Modell.
Regressionstest
Ein wiederholter Testlauf, der prüft, ob eine Änderung bereits funktionierende Fälle beschädigt hat. Bei KI-Systemen betrifft das vor allem Prompt-Anpassungen und Modellwechsel: Beides kann Verhalten verändern, das nirgends im Code steht und deshalb ohne festes Testset unbemerkt kippt.
Abnahmekriterien
Vorab schriftlich vereinbarte, überprüfbare Bedingungen, bei deren Erfüllung eine Werkleistung als vertragsgemäß erbracht gilt. Bei KI-Projekten treten Eval-Schwellenwerte auf einem gemeinsam definierten Testset an die Stelle subjektiver Bewertungen wie 'die Antworten fühlen sich gut an'.
