KI in Produktion ohne Blindflug: LLM-Observability und Evals für den selbst-gehosteten Stack

Ein LLM in die Produktion zu bringen, ist 2026 nicht mehr die eigentliche Herausforderung. Ein Modell per vLLM zu serven und einen RAG-Prototyp zu bauen, gelingt in wenigen Tagen. Die schwierige Frage lautet: Was passiert danach? Sobald echte Nutzer echte Anfragen stellen, wird ein LLM-System zur Blackbox. Antworten wirken plausibel, sind aber gelegentlich falsch. Die Cloud-Rechnung steigt unerklärlich. Ein Agent bricht bei jeder zwanzigsten Anfrage ab – und niemand weiß, warum.

Genau hier setzt LLM-Observability an. Sie ist 2026 von einer Kür zur Pflicht geworden: Wer generative KI produktiv betreibt, braucht Sicht auf jeden Trace, jeden Token und jede Qualitätskennzahl – und belastbare Evaluierung statt Bauchgefühl. Die gute Nachricht für den datenschutzbewussten Mittelstand: Die besten Werkzeuge sind Open Source und lassen sich vollständig on-premise betreiben. Vertrauliche Prompts und Traces verlassen das Haus nie.

Observability vs. Evaluation: zwei Dinge, beide nötig

Bevor wir über Tools sprechen, muss ein Begriffspaar sauber getrennt werden, das in der Praxis ständig verwechselt wird. Observability und Evaluation sind zwei getrennte Disziplinen – und 2026 gelten beide als unverzichtbar, um Agenten und RAG-Systeme zuverlässig zu betreiben.

Observability beantwortet die Frage: Was tut mein System gerade? Sie macht das Innenleben eines LLM-Aufrufs sichtbar – über sogenannte Traces. Ein Trace protokolliert den gesamten Weg einer Anfrage: welche Dokumente das Retrieval geladen hat, welcher Prompt an das Modell ging, wie lange jeder Schritt dauerte und wie viele Tokens er kostete. Observability zeigt Latenz, Durchsatz und Kosten – aber sie sagt nichts darüber aus, ob die Antwort auch richtig war.

Evaluation beantwortet die andere Frage: Wie gut ist das Ergebnis? Sie beurteilt die Qualität und Korrektheit der Ausgaben – etwa, ob eine RAG-Antwort tatsächlich durch die abgerufenen Quellen gedeckt ist (Faithfulness), ob ein JSON-Schema eingehalten wurde oder ob ein Agent das richtige Werkzeug gewählt hat. Evaluation ist die messtechnische Grundlage, um Qualität objektiv nachzuweisen statt sie zu behaupten.

Der 2026er-Standard-Stack im Überblick

Der Markt für LLM-Observability und -Evaluation hat sich konsolidiert. Ein etablierter Kern von Werkzeugen taucht 2026 in praktisch allen führenden Vergleichen auf. Für den Mittelstand ist die entscheidende Trennlinie nicht der Funktionsumfang, sondern die Frage: Kann ich das Tool im eigenen Netz betreiben – oder muss ich meine Prompts an einen US-SaaS-Anbieter senden?

Tool	Open Source / self-hostbar	Schwerpunkt
Langfuse	Ja (MIT, >28.000 Stars)	Tracing, Prompt-Management, Evals
Arize Phoenix	Ja (OTel-nativ, 50+ Evals)	Tracing, eingebaute Eval-Metriken
MLflow	Ja (Apache 2.0)	Experiment-Tracking, GenAI-Evals
Comet Opik	Ja (Apache 2.0)	Tracing, Eval-Pipelines
W&B Weave	OSS-Version vorhanden	Tracing, Experiment-Vergleich
Latitude	OSS-Komponente	Prompt- & Eval-Plattform
LangSmith	Primär kommerziell	Tracing im LangChain-Umfeld
Braintrust	Primär kommerziell	Eval-Workflows, Playground

Zu den self-hostbaren Open-Source-Optionen gehören also unter anderem Langfuse, Arize Phoenix und MLflow – ergänzt um Comet Opik und die OSS-Version von W&B Weave. LangSmith, Braintrust und Latitude sind primär kommerziell (mit Free-Tiers), wobei Latitude eine Open-Source-Komponente mitbringt. Ein Detail zur Einordnung: Latitude ist weniger reines Observability-Tool als eine Prompt- und Eval-Plattform – man sollte es beim Stack-Vergleich entsprechend differenzieren.

Die gemeinsame technische Basis ist wichtiger als die Toolwahl selbst: Fast alle setzen auf OpenTelemetry-kompatible Instrumentierung. Das bedeutet, dass Sie Ihren Code einmal mit Standard-Konventionen versehen und das Backend später austauschen können. Wählen Sie das Tool nach Ihrem Team-Setup, nicht nach dem lautesten Marketing.

Langfuse & Phoenix on-premise betreiben

Für Unternehmen, die vertrauliche Dokumente, Konstruktionsdaten oder personenbezogene Informationen verarbeiten, ist der Eigenbetrieb kein Nice-to-have, sondern Voraussetzung. Langfuse und Arize Phoenix laufen vollständig im eigenen Netz – und damit verlassen auch die Traces, die vollständige Prompts und Modellantworten enthalten, niemals das Haus.

Das ist der entscheidende DSGVO-Vorteil gegenüber US-SaaS: Ein Trace ist kein anonymer Metrikpunkt. Er enthält den kompletten Klartext dessen, was ein Nutzer gefragt und was das Modell geantwortet hat – inklusive aller Geschäftsgeheimnisse, die in der Anfrage steckten. Wer diese Traces an einen externen Dienst sendet, exportiert genau die Daten, die er eigentlich schützen wollte.

Architektur: leicht starten oder skalieren

Bei der Wahl zwischen den beiden führenden Open-Source-Optionen hilft ein Blick auf den Betriebsaufwand:

• Arize Phoenix startet leicht als Einzelprozess – ideal für erste Experimente und kleinere Teams. Es ist OpenTelemetry-nativ (auf Basis der OpenInference-Konventionen) und bringt über 50 eingebaute Eval-Metriken mit, ohne dass Sie Event-Obergrenzen fürchten müssen.
• Langfuse ist der schwerere, aber mächtigere Self-Host-Stack. Der Produktivbetrieb setzt mehrere Komponenten voraus – Postgres, ClickHouse, Redis und einen S3-kompatiblen Objektspeicher. Dafür erhalten Sie ausgereiftes Prompt-Management, Team-Funktionen und stabile Skalierung bei hohem Trace-Volumen.

Beide sind OpenTelemetry-basiert, wodurch das Backend austauschbar bleibt: Sie können mit Phoenix als Einzelprozess beginnen und später auf ein Langfuse-Cluster umziehen, ohne Ihre Instrumentierung neu zu schreiben. Die Integration in ein vLLM- oder TensorRT-LLM-Serving erfolgt über die Standard-SDKs – ein paar Zeilen, um jeden Aufruf zu tracen. So wird Observability zum natürlichen Teil eines DSGVO-konformen On-Premise-Gesamtstacks statt eines US-SaaS-Fremdkörpers.

Die neue Best Practice: günstige Evaluatoren auf 100 % des Traffics

Der größte konzeptionelle Shift bei Evals hat sich 2026 durchgesetzt – und er räumt mit einem verbreiteten Missverständnis auf. Jahrelang galt LLM-as-a-Judge als Goldstandard: Man lässt ein starkes Modell die Ausgabe eines anderen Modells bewerten. Das funktioniert, ist aber teuer und langsam. Wer jede Produktionsantwort von einem großen Judge-Modell prüfen lässt, verdoppelt seine Kosten und Latenz – untragbar bei echtem Traffic.

Die neue Best Practice trennt sauber nach Kosten. Günstige, distillierte Evaluatoren laufen auf 100 % des Traffics. Das sind spezialisierte, kleine Modelle – etwa DeBERTa-basierte Faithfulness-Klassifikatoren oder distillierte Modelle wie Luna-2 – die billig genug sind, um jede einzelne Anfrage in Echtzeit zu bewerten. Typische Prüfungen auf dieser Ebene:

• Faithfulness: Ist die RAG-Antwort tatsächlich durch die abgerufenen Quellen gedeckt, oder halluziniert das Modell?
• Schema-Validierung: Hält die Ausgabe das erwartete JSON-Format ein? Diese Prüfung ist rein deterministisch und praktisch kostenlos.
• Banned-Phrase-Detection: Enthält die Antwort verbotene Formulierungen, Konkurrenznennungen oder Compliance-Verstöße?

Der teure Agent-as-Judge – ein aufwendiges, mehrschrittiges Bewertungsverfahren mit einem starken Modell – wird dagegen nur noch selektiv eingesetzt: auf Anomalien, die von den günstigen Evaluatoren markiert wurden, auf gesampelte Stichproben-Audits und auf tiefe Pre-Production-Evaluierungen vor jedem Release. So bekommen Sie die Gründlichkeit des Judge-Verfahrens, ohne dessen Kosten auf jede Anfrage zu legen.

Die Kernaussage für 2026 lautet also: LLM-as-Judge allein reicht nicht mehr aus. Es bleibt ein wertvolles Werkzeug – aber als selektive dritte Schicht, nicht als Dauerlast auf jeder Anfrage.

RAG und Agenten gezielt überwachen

Observability wird erst dann wertvoll, wenn sie die richtigen Dinge misst. Für die beiden häufigsten Produktionsfälle – RAG und autonome Agenten – gibt es jeweils spezifische Metriken, die über generische Latenzwerte weit hinausgehen.

RAG-spezifische Metriken

Bei Retrieval-Augmented-Generation sind zwei Kennzahlen zentral. Faithfulness misst, ob die generierte Antwort ausschließlich auf den abgerufenen Kontext gestützt ist – der wichtigste Schutz gegen Halluzinationen. Kontext-Relevanz prüft die andere Seite: Waren die abgerufenen Dokumente überhaupt relevant für die Frage? Ein schlechtes Retrieval kann selbst das beste Modell nicht kompensieren. Beide Metriken zusammen zeigen, ob ein RAG-Problem im Retrieval oder in der Generierung liegt.

Agenten-spezifische Metriken

Bei Agenten verlagert sich der Fokus auf Handlungen. Hier müssen Tool-Use-Fehler und fehlgeschlagene Aufrufe getract werden: Hat der Agent das richtige Werkzeug gewählt? Waren die Parameter gültig? Ist der API-Aufruf durchgelaufen? Besonders tückisch sind kaskadierende Agentenfehler – ein kleiner Fehltritt im ersten Schritt pflanzt sich durch die gesamte Kette fort. Nur mehrstufige Traces, die jeden Span verschachtelt darstellen, machen solche Kaskaden überhaupt sichtbar.

Der Closed Loop: aus Fehlern werden Testfälle

Die eigentliche Reifestufe erreicht ein Betrieb dann, wenn Observability und Evaluation nicht nur beobachten, sondern das System aktiv verbessern. Diese Rückkopplung nennt man den Closed Loop – und sie ist der Unterschied zwischen ad-hoc-Feuerwehr und kontinuierlicher Qualitätssteigerung.

Das Prinzip: Wenn ein günstiger Evaluator eine Produktionsantwort als problematisch markiert – etwa eine RAG-Antwort mit niedriger Faithfulness – triggert dieser markierte Trace automatisch einen Review-Workflow. Ein Mensch prüft den Fall, und die Antwort wird zu einem neuen Testfall im Regression-Dataset. So wächst Ihr Test-Datensatz mit jedem realen Fehler, statt künstlich am Schreibtisch erdacht zu werden. Man spricht treffend vom Produktionsverkehr als ständig wachsendem Test-Dataset.

• Produktionsfehler zu Testfällen: Von Evaluatoren markierte Traces werden automatisch zu neuen Eval-Fällen – kein Fehler geht verloren.
• Human-Review speist Kriterien: Die menschliche Bewertung problematischer Fälle verfeinert die Eval-Rubriken und die Prompt-Iterationen.
• Kontinuierlich statt ad-hoc: Statt punktueller Feuerwehreinsätze entsteht ein systematischer, dauerhafter Verbesserungsprozess.
• Regressionen frühzeitig erkennen: Nach jedem Modell-Update läuft das gewachsene Regression-Dataset – Qualitätsverluste fallen vor dem Release auf, nicht danach.

Gerade der letzte Punkt ist 2026 gold wert: Modell-Updates kommen häufig, und ein neues Modell, das im Durchschnitt besser ist, kann in Ihrem spezifischen Anwendungsfall trotzdem schlechter abschneiden. Ohne ein gewachsenes Eval-Set aus echten Produktionsfällen merken Sie das erst, wenn sich Nutzer beschweren. Der Closed Loop macht diese Regression sichtbar, bevor sie in Produktion geht. Zusammen mit sauberen Guardrails entsteht so ein Betrieb, dem man auch autonome Agentic-AI-Workflows anvertrauen kann.

Häufig gestellte Fragen zu LLM-Observability

Was ist der Unterschied zwischen Observability und Evaluation?

Observability macht sichtbar, was Ihr System tut – Traces, Latenz und Kosten. Evaluation beurteilt, wie gut die Ausgaben sind – etwa Faithfulness oder Schema-Konformität. 2026 braucht man beides, um Agenten und RAG zuverlässig zu betreiben.

Kann ich Observability DSGVO-konform betreiben?

Ja. Langfuse, Arize Phoenix und MLflow sind Open Source und laufen vollständig on-premise. Damit bleiben Traces mit vertraulichen Prompts im eigenen Netz – im Gegensatz zu US-SaaS-Lösungen, an die Sie Ihre Daten senden müssten.

Reicht LLM-as-Judge noch aus?

Allein nicht mehr. Die 2026er-Best-Practice lässt günstige, distillierte Evaluatoren auf 100 % des Traffics laufen (Faithfulness, Schema, Banned-Phrase) und setzt teure Agent-as-Judge-Bewertungen nur selektiv auf Anomalien an.

Warum sind versteckte Reasoning-Tokens ein Kostenrisiko?

Reasoning-Modelle erzeugen Thinking-Tokens, die nie in der Antwort erscheinen, aber voll abgerechnet werden. Ohne Observability, die Kosten pro Anfrage ausweist, entdecken Sie diese Kostentreiber erst auf der Rechnung.