
Online- vs. Offline-LLM-Evaluierung: Was Sie brauchen (und wann)
Online- vs. Offline-LLM-Evaluierung ist eine Entscheidung, nicht zwei, und unsere promptfoo-Suite hat es letzten Dienstag bewiesen: ein umgeschriebener System-Prompt, 47 Testfälle, Faithfulness von 0,91 auf 0,74 in rund 90 Sekunden CI-Zeit. Der Offline-Check fing diese Regression vor dem Merge ab; das Produktions-Monitoring hätte sie erst später getroffen, getarnt als Support-Ticket. Offline vs. Online, dasselbe Urteil: zwei Spuren, unterschiedliche Aufgaben.
Bei der Offline-LLM-Evaluierung läuft Ihr Modell vor dem Deployment gegen einen festen Datensatz und beweist, dass eine Änderung die gemessene Qualität nicht beschädigt hat. Die Online-Evaluierung bewertet den Live-Traffic nach dem Launch und deckt auf, was der Datensatz nie enthielt. Die meisten Teams brauchen beides, in dieser Reihenfolge: Offline sichert das Deploy ab, Online fängt den Drift.
Die wichtigsten Erkenntnisse
- Die Offline-Evaluierung läuft vor dem Deploy gegen einen festen Datensatz; die Online-Evaluierung bewertet den Live-Traffic nach dem Launch.
- Die meisten Teams brauchen beides: Offline sichert Deploys ab, Online fängt, was der Datensatz verpasst hat.
- Offline erkennt Prompt-Regressionen und Formatbrüche; Online erkennt Drift, Latenz unter Last und Integrations-Eigenheiten.
- Binden Sie Offline-Evals als CI-Merge-Gate ein; streamen Sie Online-Scores aus Produktions-Traces in Ihr Eval-Set.
Worin unterscheiden sich Online- und Offline-Evaluierung tatsächlich? (9 Dimensionen)
Die beiden Modi unterscheiden sich auf neun Achsen, doch die ausschlaggebende ist die Datenquelle: Die Offline-Evaluierung bewertet einen festen, versionierten Datensatz vor dem Deploy, während die Online-Evaluierung den Live-Traffic nach dem Launch bewertet. Jeder andere Unterschied (Kosten, Latenz, Risiko, Governance) folgt aus dieser Trennung.
Das Learning Center von Label Studio rahmt das Paar als komplementäre Modi statt als Rivalen, und wir stimmen zu. Die Tabelle erweitert dieses Framing um LLM-spezifische Metriken, die dessen generische ML-Version nicht abdeckt.
| Dimension | Offline | Online |
|---|---|---|
| Datenquelle | Fester Golden-Datensatz, in Git versioniert | Live-Produktions-Traces, stichprobenartig |
| Zeitpunkt | Vor dem Deploy, bei jedem PR | Nach dem Launch, kontinuierlich |
| Kosten pro Lauf | Judge-Tokens pro Suite-Lauf; nahezu null Grenzkosten | Judge-Tokens auf gesampelten Traffic; skaliert mit dem Volumen |
| Latenz-Beschränkung | Keine; Batch in Ruhe | Sub-Sekunden-Budgets auf kritischen Pfaden |
| Risiko für Nutzer | Null; Fehler erreichen nie Nutzer | Real; schlechte Ausgaben treffen Live-Sitzungen |
| Feedback-Geschwindigkeit | Minuten pro PR | Sekunden bis Minuten auf Streams |
| Metrik-Typen | Faithfulness, Answer Relevancy, Format-Compliance, Benchmark-Scores | Latenz-Perzentile, Fehlerrate, Halluzinationsrate, Nutzer-Feedback |
| Wiederholbarkeit | Deterministisch bei gepinntem Modell und Datensatz | Nicht deterministisch; der Traffic-Mix verschiebt sich täglich |
| Governance und Audit | Versionierte Artefakte, zwischen Releases diffbar | Dashboards und Alerts; schwerer zu reproduzieren |
Unsere Interpretation: Die Offline-Spalte beantwortet „Hat diese Änderung etwas kaputtgemacht?", und die Online-Spalte beantwortet „Driftet die Produktion weg von dem, was wir getestet haben?". In der Zeile der Metrik-Typen divergieren beide am stärksten; unser Leitfaden zu LLM-Evaluierungsmetriken zerlegt jede einzelne.
Was fängt jeder Modus, und was fällt durch beide?
Jeder Modus besitzt eine private Fehlerklasse, die der andere nicht sehen kann. Offline fängt Änderungen, die Sie gemacht haben; Online fängt Änderungen, die die Welt um Sie herum gemacht hat. Die teuren Fehler, die beide Netze überleben, brauchen einen menschlichen Reviewer. Diese Taxonomie ist unsere Synthese dessen, was jeder Modus meldet, kein veröffentlichter Standard.
| Quadrant | Beispiele | Maßnahme |
|---|---|---|
| Nur Offline | Prompt-Regressionen, kaputte Ausgabeformate, Benchmark-Score-Einbrüche, Faithfulness unter Schwellwert | Merge in CI blockieren |
| Nur Online | Verteilungsdrift, Latenz unter Last, Integrations-Eigenheiten, adversarielle Missbrauchsmuster | Alarmieren, Traces sampeln, ins Eval-Set leiten |
| Von beiden erkannt | Anstieg der Halluzinationsrate, Erosion der faktischen Konsistenz | Beide behalten; den Aufwand deduplizieren, nicht die Abdeckung |
| Von keinem erkannt | Neue Edge Cases, subjektive Qualitätsurteile, Brand-Voice-Drift | Menschliche Review-Warteschlange; gelabelte Fälle speisen das Offline-Set |
Der Nur-Offline-Quadrant ist der Ort, an dem CI-Gates ihr Geld wert sind: Ein umgeschriebener Prompt, der die Format-Compliance still von 99 % auf 91 % drückt, ist im Code-Review unsichtbar und in einer 47-Fälle-Suite offensichtlich. Der Nur-Online-Quadrant ist heimtückischer. Echte Nutzer formulieren Dinge, die Ihr Golden-Set nie getan hat, Dritt-APIs time-outen zu Zeiten, die Staging nie trifft, und irgendjemand wird Ihrem Chatbot einen 40.000-Zeichen-Prompt füttern, nur um zu sehen, was passiert. Für diese Seite deckt unser Leitfaden zur Evaluierung von Agenten in Produktion das Scoring von Mehrschritt-Trajektorien ab, nicht nur einzelner Ausgaben.
Die unterste Zeile ist die, die Teams überspringen, und die, die sie verbrennt. Die Fehler, die Sie Nutzer kosten, sind die, die kein Modus allein fängt. Sie brauchen einen Menschen in der Schleife.
Wie bindet man Offline-Evals in ein CI-Gate ein? (Die Config, die niemand zeigt)
Fügen Sie einen Eval-Runner als erforderlichen Status-Check auf jedem Pull Request hinzu, der einen Prompt, ein Modell oder eine Retrieval-Konfiguration berührt. Assert auf einen Schwellwert. Merge darunter blockieren. promptfoo dokumentiert genau dieses CI-Muster, und es ist das, was wir betreiben.
Der GitHub-Actions-Schritt
Eine abgespeckte Version des Gates, das wir heute betreiben:
name: llm-eval-gate
on:
pull_request:
paths: ["prompts/**", "evals/**", "src/rag/**"]
jobs:
faithfulness-gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- name: Run offline evals, fail the PR on regression
run: npx promptfoo@latest eval --config evals/support-agent.yaml
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # LLM-as-judgeDie YAML-Konfiguration deklariert die Testfälle und die Assertions; eval beendet sich mit einem Rückgabewert ungleich null, wenn die Suite unter den Schwellwert fällt, GitHub markiert den erforderlichen Check als fehlgeschlagen, und der Merge-Button wird grau. Der paths-Filter ist wichtig: Ein README-Fix sollte keine Judge-Tokens verbrennen.
Was das Gate tatsächlich fängt
Die Live-Version scoret unsere Support-Agent-RAG-Kette gegen 47 Golden Cases bei jedem PR, der einen Prompt berührt. Ein voller Lauf dauert etwa 90 Sekunden CI-Zeit, und der Merge blockiert automatisch, wenn die Faithfulness unter 0,82 fällt. In drei Monaten hat es zwei Regressionen gefangen, die sonst ausgeliefert worden wären: ein Rewrite des System-Prompts, der die Faithfulness von 0,91 auf 0,74 drückte, und eine Retriever-Änderung, die die Kontextlänge verdoppelte und die Answer Relevancy unter den Schwellwert zog. Beides sah im Review nicht gefährlich aus.
Ein Faithfulness-Gate in CI kostet 90 Sekunden pro PR. Eine Faithfulness-Regression in Produktion kostet Sie ein Support-Ticket und ein Rollback.
Wir haben die Runner, die Sie in dieses Muster einstecken können (promptfoo, DeepEval und die übrigen), in unserem LLM-Evaluierungstools-Roundup verglichen.
Welche Tools betreiben welchen Modus? (Tool-zu-Modus-Matrix)
Kein einzelnes Tool besitzt beide Spuren sauber. promptfoo und DeepEval sind Offline-First-Runner, die exportierte Produktionsdaten nach Zeitplan scoren können; Langfuse und LangSmith sind Online-First-Trace-Stores, die LLM-as-Judge-Scorer an erfasste Traces anbauen. Die Matrix ist unsere Lektüre der Dokumentation jedes Anbieters: Interpretation, kein Evangelium.
| Tool | Offline-Runner | Online-Scorer | Beides nativ? | Was es NICHT kann |
|---|---|---|---|---|
| promptfoo | Ja: YAML-Suites, CI-nativ, Red-Team-Packs | Teilweise: dieselben Configs gegen exportierte Logs | Offline-First; Online braucht einen Export-Schritt | Live-Traces erfassen; als Monitoring-Dashboard dienen |
| DeepEval | Ja: Tests im pytest-Stil, 14+ Metriken | Ja, über die Confident-AI-Plattform | Ja, mit dem gehosteten Add-on | Die Open-Source-Bibliothek allein ist nur Offline |
| Langfuse | Teilweise: Datensatz-Experimente via SDK | Ja: Judge-Evaluatoren auf erfassten Traces | Ja: Datensätze plus Trace-Scorer | Ihr CI-Merge-Gate betreiben; das verdrahten Sie selbst |
| LangSmith | Ja: Datensätze und Offline-Experimente | Ja: Automatisierungen scoren gesampelte Traces | Ja | Reibungslos live außerhalb des LangChain-Stacks laufen |
| OpenAI Evals | Ja: Evals im Registry-Stil | Nein | Nein | Produktions-Trace-Pipelines; Nicht-OpenAI-Modelle |
| Arize Phoenix | Ja: Notebook-First-Experimente | Ja: Spans und Traces mit Inline-Evaluatoren | Ja | Leichtgewichtiges Setup; Observability steht an erster Stelle |
Wählen Sie promptfoo oder DeepEval, wenn Ihr erster Bedarf ein Merge-Gate ist, das schlechte Prompts in CI blockiert. Wählen Sie Langfuse oder LangSmith, wenn Ihr erster Bedarf das Scoring von Live-Traffic ist, und unser Langfuse-vs-LangSmith-Vergleich geht tief in diese Wahl. OpenAI Evals bleibt der Außenseiter: ein Offline-Runner im Registry-Stil ohne Produktionsseite.
promptfoo sichert Ihre PRs ab. Langfuse scoret Ihre Produktions-Traces. Keines ersetzt das andere.
Wie verwandelt die Feedback-Schleife Online-Ausfälle in Offline-Tests?
Sampeln Sie niedrig gescorte Produktions-Traces, labeln Sie sie, und committen Sie sie in das Offline-Eval-Set. Die Regressions-Suite wächst dann mit jeder Überraschung, die die Produktion Ihnen zuwirft, und das nächste Deploy wird gegen das erweiterte Set gegatet. Das Flywheel-Framing ist unseres; es ist der Teil, den die meisten Teams nie bauen.
Der Zyklus, so wie wir ihn betreiben:
- Online-Scorer markieren Traces unter einem Judge-Score von 0,7.
- Wir sampeln 20 bis 30 markierte Traces pro Woche.
- Ein Mensch labelt jeden einzelnen: erwartete Ausgabe plus Fehlerklasse.
- Gelabelte Fälle treten dem Offline-Eval-Set als neue Golden Examples bei.
- Der nächste PR läuft gegen die erweiterte Suite, und die Schleife startet neu.
Das Sampling beginnt auf Ihrer LLM-Observability-Ebene, denn Traces sind das Rohmaterial. Zum Rhythmus: Wöchentlich schlägt monatlich, weil Drift sich aufzinst. Wir labeln 10 bis 15 Fälle pro Woche, und das Set ist „groß genug", wenn neue Label die Bestehensquote nicht mehr bewegen, bei einem schmalen Support-Agenten etwa 150 bis 250 Fälle. Die Grenze zwischen den Modi verschwimmt weiter: Deepchecks berichtet, dass die Ingenieure von Union.ai ihre „Offline"-Evaluierungen alle paar Minuten einplanen, was sie faktisch in nahezu Echtzeit-Checks verwandelt.
Ihr Eval-Set ist kein festes Artefakt. Es wächst jede Woche, in der die Produktion Sie überrascht.
Wann brauchen Sie beides? (Online- vs. Offline-LLM-Evaluierung nach Phase)
Sie brauchen beides ab der Launch-Woche, aber die Balance verschiebt sich je nach Phase: Offline trägt die Pre-Deploy-Arbeit allein, die Launch-Woche fügt Shadow- oder Canary-Scoring hinzu, der Steady State lehnt sich an Online-Monitoring mit periodischen Offline-Re-Runs, und ein Drift-Alarm sollte in einem reproduzierten Offline-Test plus einem größeren Eval-Set enden.
| Phase | Offline | Online | Maßnahme |
|---|---|---|---|
| Pre-Deploy | Regressions-Gate auf jedem PR | Noch keines | Merge unter Schwellwert blockieren |
| Launch-Woche | Volle Suite auf dem Release Candidate | Shadow- oder Canary-Scoring auf 5–10 % des Traffics | Online-Scores mit der Offline-Baseline vergleichen |
| Steady State | Periodische Re-Eval auf einem aufgefrischten Datensatz, wöchentlich oder monatlich | Kontinuierliches Stichproben-Scoring plus Alerts | Drift beobachten; quartalsweise neu baselinen |
| Drift erkannt | Die fehlgeschlagenen Traces offline reproduzieren | Der Alarm, der den Trigger ausgelöst hat | Gelabelte Traces dem Eval-Set hinzufügen; das nächste Deploy neu gaten |
Pre-Deploy ist der billigste Ort, um streng zu sein: Ein blockierter Merge kostet Minuten; ein schlechtes Release kostet Vertrauen. Die Launch-Woche ist der Ort, an dem Teams zu wenig investieren, dabei kostet Shadow-Scoring auf einer kleinen Traffic-Scheibe wenig und deckt auf, ob das Golden-Set gelogen hat. Im Steady State setzt die Selbstzufriedenheit ein, also terminieren Sie die Re-Eval im Kalender.
Was ist mit dem EU AI Act?
Die Hochrisiko-Pflichten des EU AI Act werden bis August 2026 stufenweise eingeführt, wobei der vollständige Fristen-Zeitplan auf EUR-Lex veröffentlicht ist, und das Konformitätsmuster bildet sich sauber auf die beiden Modi ab. Dokumentierte Offline-Nachweise zeigen, dass das System die Qualitätsziele vor dem Release erreicht hat; laufendes Online-Monitoring zeigt, dass es sie danach weiter erreicht. Unsere Lesart ist, dass ein Audit-Trail beide Artefakte braucht, denn Offline-Logs allein beweisen nicht, dass das System konform blieb, und Dashboards allein beweisen nicht, dass es konform gestartet ist. Das ist Interpretation, keine Rechtsberatung; unser LLM-Evaluierungspipeline-Pillar bildet den vollständigen Anforderungskatalog ab.
Die Offline-Evaluierung ist Ihr Nachweis. Die Online-Evaluierung ist Ihr Frühwarnsystem. Regulierer wollen beides.
Über den Autor: Mert Batur ist Co-Founder von Techsy.io, wo das Team KI-Agenten, Automatisierungssysteme und Voice-/SDR-Pipelines für B2B-Kunden ausliefert. Er schreibt über den LLM-Tooling-Stack, den das Techsy-Team tatsächlich in der Produktion einsetzt. Vernetzen Sie sich auf LinkedIn.
Häufig gestellte Fragen
Was ist Offline-LLM-Evaluierung?
Die Offline-LLM-Evaluierung lässt ein Modell oder einen Prompt vor dem Deployment gegen einen festen, versionierten Datensatz laufen. Typische Checks umfassen Faithfulness zum abgerufenen Kontext, Answer Relevancy, Format-Compliance und Benchmark-Scores. Weil sich der Datensatz während des Laufs nie ändert, sind die Ergebnisse wiederholbar und diffbar, genau deshalb funktionieren Offline-Suites als CI-Merge-Gates.
Was ist Online-LLM-Evaluierung?
Die Online-LLM-Evaluierung bewertet den Live-Produktions-Traffic nach dem Launch. Ein LLM-as-Judge-Scorer bewertet gesampelte Traces auf Halluzination, Tonfall oder Tool-Call-Korrektheit, und die Scores fließen in ein Dashboard. Sie nimmt außerdem Signale auf, die Offline-Tests nicht sehen können: Latenz unter Last, Nutzer-Feedback und wie echte Anfragen von Ihrem Golden-Set abweichen.
Wann sollte ich Offline- vs. Online-LLM-Evaluierung einsetzen?
Nutzen Sie die Offline-Evaluierung, um Deploys abzusichern: Jede Prompt-, Modell- oder Retrieval-Änderung sollte die Suite vor dem Merge bestehen. Nutzen Sie die Online-Evaluierung, um das zu überwachen, was ausgeliefert wird. Die meisten Teams reihen beides, statt eines zu wählen: zuerst Offline, ab der Launch-Woche Online, wobei Produktionsausfälle zurück in das Offline-Set fließen.
Was ist ein Beispiel für Online- vs. Offline-LLM-Evaluierung?
Offline-Beispiel: Eine promptfoo-Suite fährt 200 Golden-Support-Fragen bei jedem Pull Request und blockiert den Merge, wenn die Faithfulness unter 0,82 fällt. Online-Beispiel: Langfuse scoret 10 % der Live-Traces mit einem LLM-as-Judge-Halluzinations-Check und alarmiert, wenn der Wochendurchschnitt abrutscht. Dasselbe Rubric, andere Datenquelle.
Wie passt Human-in-the-Loop in die LLM-Evaluierung?
Menschen schließen die Lücke, die kein Modus abdeckt: neue Edge Cases, subjektive Qualitätsurteile und Brand-Voice-Drift. Ein praktischer Rhythmus ist, 10 bis 20 gesampelte Traces mit niedrigem Score pro Woche zu labeln und die gelabelten Fälle in das Offline-Eval-Set zu committen. Die Review-Warteschlange ist ein Pipeline-Input, kein Nebenprojekt.
Wie funktionieren Langfuse-Evaluierungen für das Online-Scoring?
Langfuse erfasst Traces aus Ihrer Anwendung und hängt dann LLM-as-Judge-Evaluatoren an, die jeden Trace gegen ein Rubric scoren: Halluzination, Relevanz, Toxizität oder ein Custom-Prompt. Die Scores landen auf einem Dashboard, das Sessions und Nutzern zugeordnet ist. Teams exportieren dauerhaft niedrig gescorte Traces in einen Offline-Datensatz für Regressionstests. Unser Observability-Plattformen-Roundup vergleicht die Trace-Stores, die dieses Muster speisen.
Wie füge ich Offline-Evals zu einer CI/CD-Pipeline hinzu?
Fügen Sie einen Eval-Runner als erforderlichen Status-Check auf Pull Requests hinzu, die Prompts, Modelle oder Retrieval-Config berühren. promptfoo und DeepEval laufen beide headless und beenden sich bei einer fehlgeschlagenen Assertion mit einem Rückgabewert ungleich null, was den Merge automatisch blockiert. Das YAML-Gate weiter oben in diesem Beitrag ist eine funktionierende Vorlage; starten Sie mit 30 bis 50 Fällen.
Verlangt der EU AI Act Offline- oder Online-Evaluierung?
Faktisch beides. Für Hochrisiko-Systeme erwartet das Gesetz dokumentierte Nachweise, dass die Qualitätsziele vor dem Release erreicht wurden, was Offline-Artefakte bedeutet, plus laufendes Monitoring nach dem Deployment, was Online-Telemetrie bedeutet. Die gestaffelten Fristen laufen laut EUR-Lex bis August 2026. Das ist unsere Lesart des Konformitätsmusters, keine Rechtsberatung.
Kann LLM-as-a-Judge in beiden Modi laufen, Offline und Online?
Ja, und das sollte es auch, denn das Rubric überträgt sich. Offline scoret der Judge jede Ausgabe des Eval-Sets im Batch während CI. Online scoret derselbe Judge-Prompt gesampelte Produktions-Traces in nahezu Echtzeit. Ein Rubric über beide Modi hinweg zu behalten ist das, was Ihre Offline-Baseline mit Ihrem Online-Drift-Signal vergleichbar macht.
Welche Metriken unterscheiden sich zwischen Offline- und Online-Evaluierung?
Offline-Metriken messen die Ausgabequalität gegen Ground Truth: Faithfulness, Answer Relevancy, Format-Compliance, Benchmark-Scores. Online-Metriken fügen Betriebs- und Verhaltenssignale hinzu: p95-Latenz, Fehlerrate, Halluzinationsrate auf Live-Traffic, Drift-Score und Nutzerzufriedenheit. Die Offline-Liste fragt „Ist es gut?", und die Online-Liste fragt „Ist es noch gut?"
Die Kurzversion
- Offline- und Online-Evaluierung sind komplementäre Spuren, kein Entweder-oder: Eine sichert ab, was Sie ausliefern, die andere überwacht, was Sie ausgeliefert haben.
- Starten Sie diese Woche mit dem CI-Gate, fügen Sie zum Launch Online-Trace-Scoring hinzu, und verdrahten Sie die Feedback-Schleife, bevor Ihr Eval-Set veraltet.
- Die Schleife ist das System. Ein statischer Golden-Datensatz verrottet; ein wachsender zinst sich auf.
Wenn Sie ein zweites Augenpaar auf Ihre Eval-Pipeline wollen, holen Sie sich eine kostenlose Beratung.