KI in Produktion ohne Blindflug: LLM-Observability und Evals fuer 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 unerklaerlich. Ein Agent bricht bei jeder zwanzigsten Anfrage ab – und niemand weiss, warum.

Genau hier setzt LLM-Observability an. Sie ist 2026 von einer Kuer zur Pflicht geworden: Wer generative KI produktiv betreibt, braucht Sicht auf jeden Trace, jeden Token und jede Qualitaetskennzahl – und belastbare Evaluierung statt Bauchgefuehl. Die gute Nachricht fuer den datenschutzbewussten Mittelstand: Die besten Werkzeuge sind Open Source und lassen sich vollstaendig on-premise betreiben. Vertrauliche Prompts und Traces verlassen das Haus nie.

Observability vs. Evaluation: zwei Dinge, beide noetig

Bevor wir ueber Tools sprechen, muss ein Begriffspaar sauber getrennt werden, das in der Praxis staendig verwechselt wird. Observability und Evaluation sind zwei getrennte Disziplinen – und 2026 gelten beide als unverzichtbar, um Agenten und RAG-Systeme zuverlaessig zu betreiben.

Observability beantwortet die Frage: Was tut mein System gerade? Sie macht das Innenleben eines LLM-Aufrufs sichtbar – ueber 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 darueber aus, ob die Antwort auch richtig war.

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

Der 2026er-Standard-Stack im Ueberblick

Der Markt fuer LLM-Observability und -Evaluation hat sich konsolidiert. Ein etablierter Kern von Werkzeugen taucht 2026 in praktisch allen fuehrenden Vergleichen auf. Fuer 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	Primaer kommerziell	Tracing im LangChain-Umfeld
Braintrust	Primaer kommerziell	Eval-Workflows, Playground

Zu den self-hostbaren Open-Source-Optionen gehoeren also unter anderem Langfuse, Arize Phoenix und MLflow – ergaenzt um Comet Opik und die OSS-Version von W&B Weave. LangSmith, Braintrust und Latitude sind primaer 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 spaeter austauschen koennen. Waehlen Sie das Tool nach Ihrem Team-Setup, nicht nach dem lautesten Marketing.

Langfuse & Phoenix on-premise betreiben

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

Das ist der entscheidende DSGVO-Vorteil gegenueber US-SaaS: Ein Trace ist kein anonymer Metrikpunkt. Er enthaelt den kompletten Klartext dessen, was ein Nutzer gefragt und was das Modell geantwortet hat – inklusive aller Geschaeftsgeheimnisse, die in der Anfrage steckten. Wer diese Traces an einen externen Dienst sendet, exportiert genau die Daten, die er eigentlich schuetzen wollte.

Architektur: leicht starten oder skalieren

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

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

Beide sind OpenTelemetry-basiert, wodurch das Backend austauschbar bleibt: Sie koennen mit Phoenix als Einzelprozess beginnen und spaeter auf ein Langfuse-Cluster umziehen, ohne Ihre Instrumentierung neu zu schreiben. Die Integration in ein vLLM- oder TensorRT-LLM-Serving erfolgt ueber die Standard-SDKs – ein paar Zeilen, um jeden Aufruf zu tracen. So wird Observability zum natuerlichen Teil eines DSGVO-konformen On-Premise-Gesamtstacks statt eines US-SaaS-Fremdkoerpers.

Die neue Best Practice: guenstige Evaluatoren auf 100 % des Traffics

Der groesste konzeptionelle Shift bei Evals hat sich 2026 durchgesetzt – und er raeumt mit einem verbreiteten Missverstaendnis auf. Jahrelang galt LLM-as-a-Judge als Goldstandard: Man laesst ein starkes Modell die Ausgabe eines anderen Modells bewerten. Das funktioniert, ist aber teuer und langsam. Wer jede Produktionsantwort von einem grossen Judge-Modell pruefen laesst, verdoppelt seine Kosten und Latenz – untragbar bei echtem Traffic.

Die neue Best Practice trennt sauber nach Kosten. Guenstige, 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 Pruefungen auf dieser Ebene:

• Faithfulness: Ist die RAG-Antwort tatsaechlich durch die abgerufenen Quellen gedeckt, oder halluziniert das Modell?
• Schema-Validierung: Haelt die Ausgabe das erwartete JSON-Format ein? Diese Pruefung ist rein deterministisch und praktisch kostenlos.
• Banned-Phrase-Detection: Enthaelt die Antwort verbotene Formulierungen, Konkurrenznennungen oder Compliance-Verstoesse?

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

Die Kernaussage fuer 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 ueberwachen

Observability wird erst dann wertvoll, wenn sie die richtigen Dinge misst. Fuer die beiden haeufigsten Produktionsfaelle – RAG und autonome Agenten – gibt es jeweils spezifische Metriken, die ueber generische Latenzwerte weit hinausgehen.

RAG-spezifische Metriken

Bei Retrieval-Augmented-Generation sind zwei Kennzahlen zentral. Faithfulness misst, ob die generierte Antwort ausschliesslich auf den abgerufenen Kontext gestuetzt ist – der wichtigste Schutz gegen Halluzinationen. Kontext-Relevanz prueft die andere Seite: Waren die abgerufenen Dokumente ueberhaupt relevant fuer 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 muessen Tool-Use-Fehler und fehlgeschlagene Aufrufe getract werden: Hat der Agent das richtige Werkzeug gewaehlt? Waren die Parameter gueltig? Ist der API-Aufruf durchgelaufen? Besonders tueckisch 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 ueberhaupt sichtbar.

Der Closed Loop: aus Fehlern werden Testfaelle

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

Das Prinzip: Wenn ein guenstiger Evaluator eine Produktionsantwort als problematisch markiert – etwa eine RAG-Antwort mit niedriger Faithfulness – triggert dieser markierte Trace automatisch einen Review-Workflow. Ein Mensch prueft den Fall, und die Antwort wird zu einem neuen Testfall im Regression-Dataset. So waechst Ihr Test-Datensatz mit jedem realen Fehler, statt kuenstlich am Schreibtisch erdacht zu werden. Man spricht treffend vom Produktionsverkehr als staendig wachsendem Test-Dataset.

• Produktionsfehler zu Testfaellen: Von Evaluatoren markierte Traces werden automatisch zu neuen Eval-Faellen – kein Fehler geht verloren.
• Human-Review speist Kriterien: Die menschliche Bewertung problematischer Faelle verfeinert die Eval-Rubriken und die Prompt-Iterationen.
• Kontinuierlich statt ad-hoc: Statt punktueller Feuerwehreinsaetze entsteht ein systematischer, dauerhafter Verbesserungsprozess.
• Regressionen fruehzeitig erkennen: Nach jedem Modell-Update laeuft das gewachsene Regression-Dataset – Qualitaetsverluste fallen vor dem Release auf, nicht danach.

Gerade der letzte Punkt ist 2026 gold wert: Modell-Updates kommen haeufig, und ein neues Modell, das im Durchschnitt besser ist, kann in Ihrem spezifischen Anwendungsfall trotzdem schlechter abschneiden. Ohne ein gewachsenes Eval-Set aus echten Produktionsfaellen 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.

Haeufig 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-Konformitaet. 2026 braucht man beides, um Agenten und RAG zuverlaessig zu betreiben.

Kann ich Observability DSGVO-konform betreiben?

Ja. Langfuse, Arize Phoenix und MLflow sind Open Source und laufen vollstaendig on-premise. Damit bleiben Traces mit vertraulichen Prompts im eigenen Netz – im Gegensatz zu US-SaaS-Loesungen, an die Sie Ihre Daten senden muessten.

Reicht LLM-as-Judge noch aus?

Allein nicht mehr. Die 2026er-Best-Practice laesst guenstige, 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.