LLM-Evaluierung für eine Unternehmensplattform: Regressionstests der Antworten, bevor Sie das Modell wechseln

LLM-Evaluierung vor einem Modellwechsel: was eine Plattform braucht

LLM-Evaluierung auf einer Unternehmensplattform heißt, jede Änderung gegen einen festen Regressionssatz laufen zu lassen, bevor sie die Nutzer erreicht, und sie nur freizugeben, wenn sie vorab schriftlich festgelegte Freigabekriterien (Release-Gates) besteht. Eine Plattform für 500 bis 2.000 Beschäftigte ändert sich mehrmals im Jahr: eine neue Modellversion, der Wechsel von FP8 auf 4-Bit-Gewichte, ein Upgrade der Serving-Engine, ein neuer System-Prompt, eine andere Regel für das Chunking oder ein anderes Embedding-Modell. Jede dieser Änderungen kann Antworten verändern, die im Vormonat richtig waren.

Der Regressionssatz ist der Evaluationssatz aus dem Piloten, aufbewahrt und erweitert. Wie man ihn aus den Fragen der Nutzer aufbaut, mit akzeptierten Antworten und Quellabschnitten, behandelt unser Leitfaden zu RAG auf Unternehmensdaten, die Qualitäts- und Lastmessungen des Piloten unser Beitrag dazu, was ein privater KI-Pilot messen sollte. Dieser Artikel behandelt die Tests nach dem Go-live, von Metriken und Judges bis zu einer gestuften Freigabe.

Welche Änderungen an der Plattform welche Tests brauchen

Ein neues Embedding-Modell verändert die Suche und erfordert eine vollständige Neuindexierung, während ein neuer System-Prompt die Suche unberührt lässt; nicht jede Änderung braucht also das volle Verfahren.

Unser Planungsbeispiel; Metriknamen aus der Dokumentation von Ragas und promptfoo, gelesen am 10. Oktober 2026.

Die letzte Zeile betrifft das Evaluierungswerkzeug selbst. Ein Score ist eine Eigenschaft von Plattform und Judge zusammen, deshalb setzt ein neues Judge-Modell oder ein neues Release der Evaluierungsbibliothek die Baseline zurück. Die Dokumentation von Ragas markiert ihre ältere Metriken-API für die Abkündigung in Version 0.4 und die Entfernung in 1.0, Grund genug, die Version des Evaluators in der Testumgebung festzuschreiben.

Metriken für die RAG-Evaluierung: Faithfulness, Relevanz, Precision, Recall

Ragas, eine Open-Source-Bibliothek zur Evaluierung unter der Lizenz Apache 2.0, definiert vier Metriken für die Antwort und die Suche einer RAG-Pipeline. Faithfulness „misst, wie faktisch konsistent eine Antwort mit dem abgerufenen Kontext ist“: Ein LLM zerlegt die Antwort in Aussagen und prüft jede gegen die gefundenen Abschnitte, und der Score ist der Anteil der gestützten Aussagen. Response Relevancy (in der Überschrift der Seite Answer Relevancy) erzeugt aus der Antwort standardmäßig drei Fragen und mittelt deren Kosinus-Ähnlichkeit zur Frage des Nutzers. Laut Dokumentation arbeitet sie „ohne die faktische Richtigkeit zu bewerten“, eine flüssig formulierte falsche Antwort kann bei ihr also gut abschneiden.

Context Precision prüft „die Fähigkeit des Retrievers, relevante Chunks höher einzustufen als irrelevante“, und braucht eine Referenzantwort; ihre Variante ContextUtilization vergleicht die Abschnitte stattdessen mit der erzeugten Antwort. Context Recall braucht in jeder Variante eine Referenz: In der LLM-basierten wird die Referenzantwort in Aussagen zerlegt, und der Score ist der Anteil, den der gefundene Kontext stützt; andere Varianten vergleichen Referenzabschnitte oder Dokument-IDs. Factual Correctness vergleicht die Aussagen der Antwort mit denen der Referenz und meldet Precision, Recall oder F1, mit F1 als Voreinstellung.

Metrikseiten von Ragas, Assertion-Referenz von promptfoo und README von lm-evaluation-harness, gelesen am 10. Oktober 2026.

Zusammen gelesen zeigen Faithfulness und Context Recall, wo ein Fehler beginnt. Ein niedriger Recall bedeutet, dass die Suche nicht zurückgebracht hat, was die Antwort brauchte, und die Korrektur liegt in Chunking, Metadaten oder Embedding-Modell. Hoher Recall bei niedriger Faithfulness bedeutet, dass das Modell eigene Aussagen hinzugefügt hat, was auf das Modell, den Prompt oder die Präzision verweist.

Exact Match und deterministische Prüfungen für Extraktion und Format

Viele Fälle auf einer Unternehmensplattform haben genau eine richtige Antwort: eine Rechnungsnummer, ein Vertragsdatum, eine Kostenstelle, ein JSON-Objekt für das nächste System. Für sie gibt die Ragas-Metrik Exact Match laut Dokumentation 1 zurück, wenn die Antwort exakt mit der Referenz übereinstimmt, und andernfalls 0, und String Presence gibt 1 zurück, wenn die Antwort die Referenz enthält. Promptfoo bietet dieselben Prüfungen als Assertions (equals, contains, regex, is-json), und jede Assertion lässt sich mit dem Präfix not- negieren, sodass not-contains eine verbotene Formulierung abfängt.

Deterministische Prüfungen brauchen keinen Judge und lassen die Freigabe schon an einem einzigen defekten Fall scheitern. Wir schlagen eine daraus gebildete Teilmenge von Pflichtfällen vor: Extraktionsfelder, gültiges JSON, eine Quellenangabe in jeder RAG-Antwort und Ablehnungen bei Fragen, die der anfragende Nutzer nicht beantwortet bekommen darf. Ein Modellwechsel, der einen dieser Fälle bricht, geht nicht weiter, was immer seine Durchschnittswerte zeigen.

LLM-as-a-Judge und seine publizierten Verzerrungen

Faithfulness, Relevanz und Rubrik-Scores brauchen ein Modell, das die Antwort liest und bewertet. Das Paper „Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena“, vorgestellt auf der NeurIPS 2023, berichtet, dass starke Judges wie GPT-4 „über 80 % Übereinstimmung“ mit menschlichen Präferenzen erreichen, „dasselbe Maß an Übereinstimmung wie zwischen Menschen“. Diese Zahl zählt nur Stimmen ohne Unentschieden; mit Unentschieden nennt Tabelle 5 des Papers 66 Prozent für GPT-4 gegenüber Expertenstimmen auf MT-Bench und 63 bis 67 Prozent zwischen Experten. Das Paper nennt Positions-, Ausführlichkeits- und Selbstbevorzugungsverzerrung (position, verbosity und self-enhancement bias) sowie eine begrenzte Fähigkeit zum logischen Schließen. Die Ausführlichkeitsverzerrung ist definiert als die Neigung eines Judges zu „längeren, ausführlichen Antworten, auch wenn sie nicht so klar sind“. Zur Selbstbevorzugung, bei der Judges „die von ihnen selbst erzeugten Antworten“ bevorzugen, schreiben die Autoren, dass sie wegen begrenzter Daten nicht feststellen konnten, ob die Modelle sie zeigen.

Bei Vergleichen zweier Antworten rufen Sie den Judge zweimal auf, mit vertauschter Reihenfolge der beiden Antworten, und werten einen Sieg nur, wenn beide Aufrufe übereinstimmen. Für Fragen mit bekannter Antwort nehmen Sie einen referenzgestützten Judge, der eine Referenzantwort in seinem Prompt sieht; in einem Regressionssatz ist das die akzeptierte Antwort. Als Vorsichtsmaßnahme gegen Selbstbevorzugung wählen Sie, wo möglich, einen Judge aus einer anderen Modellfamilie als der des Kandidaten.

Auf einer privaten Plattform sieht der Judge dieselben Dokumente wie das Modell, das er bewertet, also läuft auch er on-premise. Die Dokumentation von promptfoo hält fest: „Standardmäßig verwenden modellbewertete Assertions den integrierten Grading-Provider von promptfoo“, ausgewählt anhand der Zugangsdaten in der Umgebung. Legen Sie den Judge explizit mit --grader oder defaultTest.options.provider fest; die Dokumentation nennt selbst gehostete, OpenAI-kompatible Judges wie vLLM. Auch Ragas braucht für seine LLM-basierten Metriken ein Judge-Modell, und die Version des Judges wird festgeschrieben wie die des Evaluators.

Menschliche Stichprobe und NIST AI 600-1

Die Scores des Judges werden an Menschen überprüft. Für jedes Release prüfen Fachexperten eine Stichprobe von Antworten, ausgewählt aus den Fällen, in denen sich alte und neue Version am stärksten unterscheiden, ohne zu wissen, welche Version welche Antwort geschrieben hat. Wo Prüfer und Judge in vielen Fällen uneins sind, muss am Judge-Prompt oder am Judge-Modell gearbeitet werden, bevor seine Scores über eine Freigabe entscheiden.

Das Generative AI Profile des NIST (NIST AI 600-1, Juli 2024) beschreibt diese Kombination. Seine vorgeschlagene Maßnahme MP-2.3-001 beginnt mit „Genauigkeit, Qualität, Zuverlässigkeit und Authentizität der GAI-Ausgaben bewerten“ und führt den Vergleich mit bekannter Ground Truth, menschliche Aufsicht und automatisierte Evaluierung unter den Methoden auf. MS-2.5-003, „Quellen und Zitate in den Ausgaben von GAI-Systemen prüfen und verifizieren“, gilt vor dem Deployment und während der laufenden Überwachung. Für einen RAG-Assistenten heißt das, dass Prüfer den zitierten Abschnitt öffnen, nicht nur die Antwort.

Unser Service Private AI/ML beginnt mit einem Pilotprojekt auf einem Prozess mit klaren Metriken und misst das Ergebnis an Checkpoints. Nennen Sie uns die Modellwechsel, die auf Ihrer Plattform geplant sind, und wie Antworten heute geprüft werden.

Werkzeuge: Ragas, promptfoo und lm-evaluation-harness

Die drei Werkzeuge überschneiden sich teilweise. Ragas bewertet RAG-Pipelines und Agenten anhand von Datensätzen aus Frage, gefundenen Abschnitten, Antwort und Referenz, mit LLM-basierten Metriken und klassischen wie Exact Match, BLEU und ROUGE. Promptfoo führt die Prompts, Provider und Testfälle aus, die in seiner Konfigurationsdatei promptfooconfig.yaml definiert sind, und kombiniert deterministische und modellbewertete Assertions, mit einem Gewicht je Assertion und einer optionalen Bestehensschwelle je Testfall. Seine CI/CD-Dokumentation zeigt Quality Gates, die eine Pipeline scheitern lassen, wenn Tests fehlschlagen oder die Bestehensquote unter einen festgelegten Wert fällt; damit wird der Regressionssatz zu einem Schritt der Release-Pipeline.

EleutherAIs lm-evaluation-harness, unter der MIT-Lizenz, beschreibt sich als „ein Framework für die Few-Shot-Evaluierung von Sprachmodellen“ mit über 60 akademischen Standard-Benchmarks. Das Werkzeug läuft direkt gegen vLLM oder gegen einen OpenAI-kompatiblen Server mit den Modelltypen local-completions und local-chat-completions, und --log_samples bewahrt jede Antwort für die spätere Analyse auf. Das Harness zeigt, ob ein quantisiertes oder aktualisiertes Modell seine allgemeinen Fähigkeiten bei öffentlichen Aufgaben behalten hat; öffentliche Benchmarks enthalten nicht die Fragen Ihres Unternehmens, deshalb entscheidet weiterhin der Regressionssatz über die Freigabe. Ob die Lizenz eines neuen offenen Modells Ihre Nutzung erlaubt, ist eine eigene Prüfung, behandelt in unserem Beitrag zu Lizenzen offener LLMs für den Unternehmenseinsatz.

Freigabekriterien für einen Modellwechsel: ein Beispiel

Freigabekriterien werden geschrieben, bevor der Kandidat läuft, damit das Ergebnis sie nicht formen kann. Messen Sie zuerst das Rauschen: Lassen Sie den Regressionssatz zweimal gegen die Produktion laufen, denn die Generierung ist nicht vollständig reproduzierbar, und die Streuung zwischen beiden Läufen ist der kleinste Unterschied, den ein Kriterium erkennen kann. Unser Beispiel für eine Plattform mit einem Satz von 300 Fällen, von denen 60 die Pflichtfälle bilden, mit Werten zum Anpassen:

1. Pflichtfälle: Kein Fall, der in der Produktion besteht, darf scheitern.
2. Faithfulness und Factual Correctness: Der Mittelwert darf nicht um mehr als die gemessene Streuung zwischen zwei Läufen unter die Baseline der Produktion fallen.
3. Context Precision und Recall: nur gefordert, wenn sich die Suche geändert hat, nach derselben Regel gegenüber der Baseline.
4. Fallprüfung: Jeder Fall, dessen Score gesunken ist, wird aufgelistet und gelesen.
5. Menschliche Stichprobe: Die Prüfer ziehen die neue Antwort vor oder bewerten beide als gleichwertig, in mindestens so vielen Fällen, wie sie die alte vorziehen.
6. Shadow-Traffic: Der Kandidat beantwortet einen Teil der Live-Anfragen, ohne Anstieg der an der Längengrenze abgeschnittenen Antworten und ohne neuen Fehlertyp.
7. Canary: Ein kleiner Teil der Nutzer erhält das neue Modell, mit einem vereinbarten Rollback-Auslöser im Monitoring.

Die Dokumentation von Istio beschreibt Mirroring als das Senden „einer Kopie des Live-Traffics an einen gespiegelten Dienst“, außerhalb des primären Anfragepfads, wobei die gespiegelten Antworten verworfen werden. Um sie zu bewerten, protokolliert der Shadow-Dienst seine Antworten unter denselben Zugriffsregeln wie das Query-Log, und seine Suche wendet denselben Berechtigungsfilter an wie die Produktion. Metriken, die keine Referenzantwort brauchen, etwa Faithfulness und Response Relevancy, funktionieren auf diesem Traffic, da Live-Fragen keine akzeptierte Antwort haben. Anfragen, die Aktionen auslösen, etwa Tool-Aufrufe von Agenten, bleiben aus dem Mirroring heraus oder erreichen nur Testsysteme, weil der Shadow-Dienst sie ein zweites Mal ausführen würde.

Der Canary-Rollout von KServe erlaubt es „einer neuen Version eines InferenceService, einen Prozentsatz des Traffics zu erhalten“, eingestellt mit canaryTrafficPercent, und lässt sich so konfigurieren, dass der gesamte Traffic zur vorherigen Revision zurückgeleitet wird, wenn ein Rollout-Schritt scheitert. Laut Dokumentation wird die Canary-Strategie „nur im Serverless-Deployment-Modus unterstützt“; im Raw-Deployment-Modus braucht die Aufteilung gewichtete Routen in einem Service Mesh oder Gateway. Während des Canary zeigt LLM-Monitoring mit vLLM-Metriken Warteschlange, Latenz und Abschlussgründe für beide Versionen.

Unser Engineering-Partner Vixen.UNO baut die Plattform auf Kubernetes mit KServe und Kubeflow, mit Protokollierung von Anfragen und Antworten. Beschreiben Sie Ihren Serving-Stack und die nächste Änderung im Formular unten.

Was mit Fehlern nach einem Release geschieht

Jeder Fehler, den Nutzer nach einem Release melden, wird zu einem neuen Fall im Regressionssatz, mit akzeptierter Antwort und Quelle. Scheitern Antworten an Stil, Format oder Aufgabenverhalten statt an Fakten, kann ein Fine-Tuning der nächste Schritt sein, und unser Vergleich von Fine-Tuning und RAG zeigt, welches Problem jedes der beiden löst. Ein feinabgestimmtes Modell durchläuft dieselben Freigabekriterien wie jeder andere Modellwechsel.

Was wir tun

Private AI/ML ist unser Service für private LLMs, RAG-Assistenten und MLOps auf Kubernetes, mit Engineering von unserem Engineering-Partner Vixen.UNO. Er beginnt mit einem Pilotprojekt auf einem Prozess mit klaren Metriken, misst das Ergebnis an Checkpoints und skaliert nur, was seinen Wert bewiesen hat. Die Plattform protokolliert Anfragen und Antworten, sodass Security und Legal sehen, wer worauf zugreift, und Ihr Team wird geschult, sie zu betreiben und weiterzuentwickeln. Änderungen laufen in vereinbarten Wartungsfenstern mit Rollback-Plan, mit Support unter einem vereinbarten SLA.

FAQ