Pexon Consulting | 10 Min. Lesezeit | 13.06.2026
TL;DR
AI Evaluation Engineering ist 2026 die unterschätzte Pflicht-Lieferung in jedem AI-Projekt: Ohne automatisierte Eval-Gates in CI/CD fliegen Quality-Regressionen erst beim Nutzer auf. Ragas, LangSmith, TruLens und Arize Phoenix decken den Stack ab — Pexon-Default ist Phoenix für Tracing plus Ragas für RAG-Metriken plus eine eigene Test-Suite für Domain-spezifische Akzeptanz. Pattern und CI-Setup.
Warum AI Evaluation Engineering die unterschätzte Pflicht ist
Klassische Software hat Unit-Tests, Integration-Tests, E2E-Tests. Jeder Code-Change läuft durch die Pipeline, ein roter Build stoppt das Deployment. Bei AI-Systemen ist diese Disziplin 2026 noch nicht etabliert — und das ist der häufigste Grund, warum Pilotprojekte in Produktion Probleme bekommen, die niemand vorhergesehen hat.
Konkret aus drei Pexon-Audits bei mittelständischen Banken und Versicherern 2025/2026: Keines der drei AI-Systeme hatte automatisierte Quality-Gates. Jedes der drei hatte mindestens eine Produktiv-Regression in den letzten 6 Monaten, die mit einer Eval-Suite in der CI hätte abgefangen werden können. Schaden pro Vorfall: zwischen 15.000 und 80.000 EUR — Aufwand für nachträglichen Aufbau und Akzeptanz-Recovery beim Nutzer.
Die regulatorische Dimension verschärft das. DORA Artikel 6 verlangt „Wirksamkeitsprüfung“ der eingesetzten IKT-Systeme. EU AI Act Artikel 15 verlangt für High-Risk-Systeme „angemessene Genauigkeits-, Robustheits- und Cybersicherheits-Niveaus“. Beides ohne strukturierte Evaluation nicht nachweisbar. Wer 2026 AI ohne Evaluation Engineering ausrollt, baut sich ein Audit-Findings-Risiko, das spätestens 2027 schlagend wird.
Das Eval-Stack-Drei-Säulen-Modell
Ein produktiver AI-Evaluation-Stack besteht aus drei Säulen, die unterschiedliche Fragen beantworten:
+-------------------+ +-------------------+ +-------------------+
| Säule 1: | | Säule 2: | | Säule 3: |
| Komponenten-Evals | | End-to-End-Akzep- | | Production- |
| (Retrieval, | | tanz-Tests | | Monitoring |
| LLM-Antwort, | | (Domain-Cases) | | (Drift, Anomalie) |
| Tool-Calls) | | | | |
+-------------------+ +-------------------+ +-------------------+
Ragas, TruLens Custom + LangSmith Arize Phoenix,
in CI/CD in Pre-Prod-Gate OpenTelemetrySäule 1 — Komponenten-Evals. Pro Modell-Aufruf metrische Bewertung. Bei RAG sind das die klassischen Ragas-Metriken (faithfulness, answer relevancy, context precision, context recall). Bei Agents sind das Tool-Call-Korrektheit, Reasoning-Quality, Halluzinations-Rate. Diese Säule läuft in jeder Pull-Request-CI gegen ein fixes Test-Set von 50-300 Cases.
Säule 2 — End-to-End-Akzeptanz-Tests. Domänen-spezifische Cases, die nicht eine Metrik, sondern die Akzeptanz eines fachlich Verantwortlichen prüfen. „Hätte Sachbearbeiter X diese Antwort akzeptiert?“ Antwort: ja/nein/eingeschränkt. Wird typisch quartalsweise auf 200-1.000 Cases gemessen, oft mit menschlicher Review-Schicht plus LLM-as-judge-Vorfilter.
Säule 3 — Production-Monitoring. Live-Tracing, Drift Detection, Anomalie-Alerts. Sieht, was im realen Betrieb passiert, und gibt früh ein Signal, wenn Antwort-Quality sinkt — bevor User-Beschwerden kommen.
Wer alle drei Säulen sauber bedient, hat 2026 in jedem AI-Projekt einen klaren Vorsprung. Wer nur die erste oder nur die dritte hat, fliegt blind durch die Produktiv-Phase.
Ragas — die RAG-Spezialisten-Metriken
Ragas (Retrieval-Augmented Generation Assessment) ist das etablierte Open-Source-Framework für RAG-Evaluation. Sechs Metriken sind Standard:
- Faithfulness — wie gut ist die Antwort durch den retrievten Kontext gestützt?
- Answer Relevancy — beantwortet die Antwort wirklich die Frage?
- Context Precision — sind die retrievten Chunks für die Frage relevant?
- Context Recall — fehlt im retrievten Kontext relevante Information aus dem Quelldatenstamm?
- Answer Semantic Similarity — wie ähnlich ist die Antwort einer goldenen Referenz-Antwort?
- Answer Correctness — ist die Antwort faktisch korrekt?
Was Ragas gut macht: Es ist genau auf RAG fokussiert, integriert in LangChain und LlamaIndex, läuft mit beliebigen LLMs als Judge. Was es weniger gut macht: Für Multi-Agent-Workflows oder Tool-Use-Agents reichen die Metriken nicht. Wer dort genaue Bewertungen braucht, kombiniert Ragas mit eigenen Metriken.
Pexon nutzt Ragas als Default für die Säule 1 in allen RAG-Projekten. Setup ist 1-2 PT, integriert direkt in pytest, lauffähig in jeder GitHub-Actions- oder GitLab-CI-Pipeline.
LangSmith — Commercial-Tracing mit Evals
LangSmith ist das kommerzielle Angebot von LangChain. Stärke: tiefe Integration mit dem LangChain- und LangGraph-Ökosystem, eingebaute Datasets, Annotation-UI, Eval-Runs als Service. Wer LangChain produktiv nutzt, bekommt mit LangSmith Tracing, Dataset-Versionierung und Eval-Orchestrierung in einem Stück.
Drei Schwächen, die in unseren Projekten regelmäßig auftauchen:
- Cloud-only in der Standard-Variante. Self-hosted gibt es nur in Enterprise-Plänen, die Lizenz-Kosten beginnen vierstellig pro Monat.
- Vendor-Lock-in auf LangChain-Ökosystem. Wer mit OpenAI Agents SDK, Pydantic AI oder custom orchestration arbeitet, profitiert weniger.
- Datenschutz-Komplexität. Für DSGVO-/DORA-konforme Setups ist LangSmith im Standard-Plan nicht ohne weiteres geeignet — Daten landen in der US-Cloud.
Für Teams mit klarer LangChain-Strategie und ohne harte EU-Daten-Anforderungen ist LangSmith eine valide Wahl. Für regulierte Branchen oder Vendor-neutrale Stacks empfehlen wir die Open-Source-Alternativen Phoenix oder TruLens.
TruLens — die Open-Source-RAG-Triad
TruLens (von TruEra, jetzt Snowflake) ist eines der ersten Open-Source-Tools für RAG-Eval und nach wie vor solide. Kern-Konzept: die „RAG Triad“ aus Context Relevance, Groundedness und Answer Relevance, plus beliebige Custom-Metriken.
Stärken aus zwei Pexon-Setups:
- Komplett self-hostable mit lokalem SQLite oder Postgres
- Custom-Metriken pragmatisch hinzufügbar in Python, ohne Framework-Cargo
- LLM-as-judge mit beliebigem Modell — auch self-hosted Qwen oder Llama
- Dashboards eingebaut über Streamlit, ohne extra Tooling
Schwächen: Die Community ist kleiner als bei Ragas, Releases kommen unregelmäßiger, die Integration mit LangChain und LlamaIndex ist weniger reif. Für rein Open-Source-orientierte Setups in regulierten Umfeldern ist TruLens trotzdem eine gute Wahl.
Arize Phoenix — Observability-First
Arize Phoenix ist 2026 unser Default für Säule 3 (Production-Monitoring) und zunehmend auch für Säule 1 (Komponenten-Evals). Phoenix verfolgt ein Observability-First-Konzept: erst ist Tracing da, dann werden auf den Traces Evals laufengelassen, dann werden Datasets aus Production-Traces aufgebaut.
Drei Eigenschaften, die Phoenix von den anderen abheben:
- OpenTelemetry-native. Phoenix konsumiert OpenInference-Traces, ist also kompatibel mit jeder OpenTelemetry-Pipeline. Damit funktioniert es mit LangChain, LlamaIndex, OpenAI SDK, Anthropic SDK, custom orchestrations — alles in einem Tool.
- Self-hosted + SaaS. Open-Source-Variante self-hostable, SaaS-Variante (Arize AX) für Teams, die das nicht selbst betreiben wollen.
- Datasets aus Traces. Production-Traces können direkt zu Eval-Datasets werden. Das schließt den Loop zwischen Säule 3 (Monitoring) und Säule 1 (Pre-Deploy-Evals).
Schwäche: Die spezialisierten RAG-Metriken sind weniger ausgereift als bei Ragas. Wer reine RAG-Qualitäts-Metriken braucht, kombiniert Phoenix-Tracing mit Ragas-Eval.
Pexon-Default-Stack — Phoenix + Ragas + Custom-Suite
Aus drei laufenden Pexon-Projekten in 2025/2026 hat sich folgender Default herauskristallisiert:
Warum diese Kombination? Phoenix gibt uns die Observability-Backbone, Ragas die spezialisierten Metriken, die eigene pytest-Suite die Domain-Anpassung. Alle drei sind Open-Source, self-hostable, EU-Region-tauglich. Investment für das initiale Setup: 10-18 PT, etwa 13.000-23.000 EUR. Laufende Kosten: Hosting für Phoenix ca. 200-500 EUR pro Monat, sonst keine Lizenz-Kosten.
Was wir aktuell nicht empfehlen: Den ganzen Stack auf LangSmith zu setzen, auch wenn das Marketing es nahelegt. Lock-in plus laufende Kosten plus Datenschutz-Komplexität rechnen sich für die meisten deutschen Mittelstands-Setups schlechter als der Open-Source-Stack.
Quality-Gates in CI/CD — die produktive Pipeline
Der entscheidende Schritt ist die Integration in CI/CD. Ohne Pipeline-Integration bleibt jedes Eval-Setup ein Reporting-Tool, kein Quality-Gate.
# .github/workflows/ai-eval-gate.yml (vereinfacht)
jobs:
ai-eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with: { python-version: '3.13' }
- name: Install deps
run: pip install -r requirements.txt
- name: Run Ragas Eval Suite
run: pytest tests/eval/ --ragas --strict
- name: Quality Gate
run: |
python scripts/check_eval_thresholds.py
--faithfulness-min 0.85
--answer-relevancy-min 0.80
--context-precision-min 0.75Drei Detail-Entscheidungen, die wir in jedem Setup gleich treffen:
- Schwellenwerte pro Metrik konfigurierbar im Repo. Nicht hartkodiert, sondern in einer
eval_thresholds.yaml. Damit kann das AI-Team die Schwellen anpassen, ohne den Build-Code zu berühren. - Eval-Set versioniert wie Code. Das Test-Set liegt im Repo, mit Git-Versionierung. Neue Cases werden via Pull-Request hinzugefügt, alte Cases werden ggf. archiviert — aber nie heimlich gelöscht.
- Eval-Kosten budgetiert. Pro CI-Lauf fallen 1-5 USD LLM-Kosten an (Judge-Modell). Bei 80-200 Pull-Requests pro Monat sind das 100-500 USD pro Monat — explizit budgetiert, nicht versteckt.
Was du loggen musst — und was nicht
Production-Monitoring ist nur so gut wie die Telemetrie. Aus drei Pexon-Setups die Pflicht-Felder:
Wichtig: Bei regulierten Branchen den vollen Prompt nicht im Hauptlog speichern. Hash im Tracing, Volltext im separaten, restriktiv zugänglichen Cold-Storage mit kurzer Retention.
Anti-Patterns
Drei wiederkehrende Fallen aus unseren Audits:
1. Manual-Review-Only. „Wir prüfen Antworten manuell“ ist kein Eval-Setup. Es skaliert nicht, ist nicht reproduzierbar, hat keinen Audit-Trail. Manual Review ist Säule 2 als Ergänzung, nicht als Ersatz für Säule 1 und 3.
2. Eval-Set, das nie wächst. Wer mit 50 Test-Cases startet und 12 Monate später immer noch 50 Cases hat, hat die Disziplin verloren. Pflicht: Jeder Bug-Report wird zum neuen Test-Case. Eval-Set wächst typisch um 5-15 Cases pro Monat.
3. LLM-as-Judge ohne Validierung. Wer das Eval-LLM nicht gegen menschliche Bewertungen validiert, vertraut blind. Pflicht: Quartalsweise 50-100 Cases mit menschlicher Bewertung plus LLM-Judge, Korrelations-Check. Bei Drift Judge-LLM oder Prompt nachtunen.
Konfidenz für alle drei: hoch.
Häufig gestellte Fragen
Welches Tool sollte ich zuerst einführen, wenn ich noch gar keine Evals habe?
Phoenix als Tracing-Backbone. Damit gewinnst du sofort Sichtbarkeit auf Production-Verhalten, ohne dass du Test-Cases schreiben musst. Auf Basis der Trace-Daten kannst du dann iterativ Eval-Datasets aufbauen und Ragas oder eigene Metriken obendrauf legen.
Wie viele Test-Cases brauche ich für eine sinnvolle Eval-Suite?
Aus unserer Praxis: 50-100 Cases als Minimum für sinnvolle Aussagekraft. 200-500 Cases als gutes Mittelfeld für Mittelstands-Workloads. Über 1.000 Cases nur bei sehr breit aufgestellten Stacks. Wichtiger als Menge ist Coverage: ein paar Cases pro Use-Case-Klasse, statt 500 Variationen eines einzigen Cases.
Kann ich AI Evaluation Engineering ohne dediziertes AI-Team aufsetzen?
Eingeschränkt ja. Das initiale Setup (Phoenix + Ragas in CI) braucht zwar AI/ML-Erfahrung, läuft danach aber wie eine normale Test-Suite. Wir liefern Mittelständlern den initialen Setup-Schub im 6-Wochen-Pilot und übergeben dann an das interne Team. Pflicht: mindestens eine Person, die die Eval-Schwellen versteht und Cases pflegt.
Wie wirken sich Evals auf die LLM-Kosten aus?
Ragas-Eval läuft mit Judge-LLM. Pro 100 Cases typisch 1-5 USD bei Frontier-LLM, 0,10-0,50 USD bei Mid-Tier. Bei 80-200 CI-Runs pro Monat sind das 100-1.000 USD zusätzliche LLM-Kosten — explizit, aber gerechtfertigt durch vermiedene Produktiv-Probleme.
Ist LangSmith trotz Cloud-Lock eine valide Option?
Für Teams mit klarer LangChain-Strategie und ohne harte EU-Daten-Anforderungen ja. Die Integration ist tiefer und die Tooling-Reife höher als bei den Alternativen. Für regulierte Branchen und Vendor-neutrale Stacks würden wir aktuell Phoenix + Ragas vorziehen.
Wie verbindet sich AI Evaluation Engineering mit Multi-Model Routing?
Sehr eng. Wer Multi-Model Routing einsetzt, braucht zwingend Evals pro Modell-Tier. Sonst kann die Routing-Logik nicht überprüft werden — und Cost-Optimierung verkommt zu Qualitäts-Regression. Phoenix-Tracing zeigt direkt, welcher Tier gerade welche Konfidenz liefert.
Nächster Schritt
Wenn Sie ein produktives AI-System ohne strukturierte Evaluation betreiben oder vor dem nächsten DORA- oder AI-Act-Audit den Quality-Gate-Aufbau planen: Wir machen das im 6-Wochen-Pilotprojekt für Generative AI konkret — Phoenix-Setup, Ragas-Integration in CI, erste Eval-Suite mit 100-200 Cases als Referenz.
Verwandte Themen
→Agentic Loops Production: Welches Framework hält 100 User?
→GraphRAG Knowledge Graph: Neo4j, Microsoft, RDF im Vergleich
