KI-Funktionen wandern derzeit reihenweise aus Prototypen in produktive Webanwendungen: Suchassistenten, Textgeneratoren, Agenten, die Formulare vorausfüllen oder Tickets vorsortieren. Sobald diese Funktionen echte Nutzerinnen und Nutzer erreichen, stellt sich eine Frage, die im Prototyp noch ignoriert werden konnte: Was genau ist passiert, als das System eine falsche Antwort gegeben hat?

Genau an dieser Stelle setzt die Version 1.0.0 von OpenObserve an. Die Plattform bringt eine eigene Observability-Umgebung für Anwendungen mit großen Sprachmodellen mit. Dazu kommen erweiterte Alarme, Unterstützung für Service Level Objectives und schnellere Abfragen mit PromQL.

Observability ist mehr als Monitoring

Monitoring beantwortet die Frage, ob ein System läuft: Ist der Dienst erreichbar, wie hoch ist die Antwortzeit, wie voll ist die Festplatte. Observability – zu Deutsch etwa Beobachtbarkeit – zielt auf die Frage, warum sich ein System so verhält, wie es sich verhält. Dafür werden Messwerte, Protokolldaten und Ablaufspuren einzelner Anfragen zusammengeführt, sodass sich ein konkreter Vorfall im Nachhinein rekonstruieren lässt.

Bei klassischen Webanwendungen ist dieser Unterschied unangenehm, aber beherrschbar. Bei KI-Anwendungen wird er zum Kernproblem. Ein Sprachmodell liefert für dieselbe Eingabe nicht zwangsläufig dieselbe Ausgabe. Es gibt keinen Stacktrace, der erklärt, warum eine Antwort inhaltlich daneben liegt. Und zwischen der Nutzereingabe und der ausgegebenen Antwort liegen oft mehrere Zwischenschritte: eine Suche in einer Wissensdatenbank, ein Werkzeugaufruf, ein zweiter Modellaufruf, der das Zwischenergebnis zusammenfasst.

Wo Agenten typischerweise scheitern

Fällt eine Antwort falsch aus, ist das Modell selbst nur eine von mehreren möglichen Ursachen. In der Praxis verteilen sich die Fehlerquellen über die gesamte Kette:

  • Kontext: Die Wissensabfrage hat die falschen oder veraltete Textabschnitte geliefert. Das Modell hat sauber gearbeitet – mit schlechtem Material.
  • Prompt: Eine Änderung an der Anweisung hat Nebenwirkungen an Stellen, an die beim Testen niemand gedacht hat.
  • Werkzeugaufrufe: Ein angebundener Dienst antwortet langsam, mit einem Fehler oder in einem unerwarteten Format.
  • Abbruch und Wiederholung: Zeitüberschreitungen führen zu Wiederholungsversuchen, die Kosten und Latenz vervielfachen, ohne dass es im Frontend sichtbar wird.
  • Modellwechsel: Ein Anbieter aktualisiert ein Modell, und das Verhalten verschiebt sich, obwohl am eigenen Code nichts geändert wurde.

Ohne durchgängige Nachvollziehbarkeit dieser Schritte bleibt die Fehlersuche Raterei. Genau deshalb ist eine Umgebung, die speziell auf LLM-Anwendungen zugeschnitten ist, mehr als ein Komfortmerkmal: Sie entscheidet darüber, ob ein KI-Feature betrieben oder nur gehofft wird.

SLOs bringen Verbindlichkeit in die Diskussion

Der zweite relevante Baustein der neuen Version sind Service Level Objectives. Ein SLO ist ein messbares Qualitätsziel für einen Dienst, etwa bezogen auf Verfügbarkeit oder Antwortzeit über einen definierten Zeitraum. Der Wert dieser Technik liegt weniger in der Zahl selbst als in der Diskussion, die sie erzwingt: Welche Qualität schuldet ein Feature seinen Nutzern eigentlich, und wie viel Abweichung ist tolerierbar, bevor das Team reagieren muss?

Für KI-Funktionen ist das besonders nützlich, weil sie sich schlecht binär bewerten lassen. Ein Assistent ist selten einfach „defekt“. Er wird langsamer, teurer oder ungenauer. SLOs machen aus diesem Graubereich eine überprüfbare Größe – und geben Teams eine Grundlage, um zu entscheiden, wann eine Verschlechterung ein Fall für den Bereitschaftsdienst ist und wann für das nächste Sprint-Planning.

Erweiterte Alarme ergänzen das. Entscheidend ist dabei nicht die Menge der Benachrichtigungen, sondern ihre Trefferquote: Wer zu viele Alarme erhält, ignoriert sie. Wer zu wenige definiert, erfährt von Problemen durch Kundenanrufe.

Abfragegeschwindigkeit ist keine Nebensache

Dass OpenObserve PromQL-Abfragen beschleunigt hat, klingt nach einem technischen Detail. PromQL ist die Abfragesprache, mit der sich Zeitreihen – also über die Zeit aufgezeichnete Messwerte – auswerten lassen. Sie ist in der Betriebspraxis weit verbreitet.

Die Geschwindigkeit dieser Abfragen bestimmt, wie eine Störungsanalyse abläuft. Braucht eine Auswertung spürbar lange, formulieren Teams weniger Hypothesen und geben früher auf. Antwortet das System schnell, entsteht ein iterativer Prozess: Vermutung, Abfrage, Eingrenzung, nächste Vermutung. Gerade bei KI-Anwendungen mit ihren vielen Zwischenschritten ist diese Form der Annäherung oft der einzige gangbare Weg zur Ursache.

Was Verantwortliche daraus mitnehmen sollten

Der praktische Nutzen solcher Werkzeuge hängt davon ab, ob Observability früh eingeplant wird. Einige Punkte lohnen die Aufmerksamkeit bereits in der Konzeptionsphase:

  1. Nachvollziehbarkeit als Anforderung formulieren. Jeder Schritt einer KI-Interaktion sollte mit Eingabe, Ausgabe, Dauer und verwendetem Modell erfasst werden – nicht erst, wenn Beschwerden eintreffen.
  2. Datenschutz mitdenken. Bei Eingaben und Antworten handelt es sich potenziell um personenbezogene Daten. Aufbewahrungsfristen, Zugriffsrechte und Anonymisierung gehören ins Konzept, nicht in ein späteres Nachrüstprojekt.
  3. Qualitätsziele definieren. Ohne vereinbarte Schwellenwerte bleibt jede Diskussion über die Güte eines Assistenten eine Frage des Bauchgefühls.
  4. Kosten mitprotokollieren. Token-Verbrauch und Wiederholungsversuche sind Betriebskennzahlen, die sich am besten dort auswerten lassen, wo auch Latenz und Fehlerquote liegen.
  5. Betriebsverantwortung klären. Wer schaut auf die Dashboards, wer reagiert auf Alarme, wer entscheidet über einen Rollback des Prompts?

Für Web- und Softwareprojekte bedeutet das: KI-Features sind ab dem Moment, in dem sie live gehen, gewöhnliche Betriebsgegenstände mit ungewöhnlichem Fehlerverhalten. Wer sie ohne durchgängige Beobachtbarkeit ausliefert, verlagert die Fehlersuche auf die Nutzerinnen und Nutzer. Es lohnt sich deshalb, Observability, Qualitätsziele und Alarmierung im selben Zug zu planen wie das Feature selbst – der Aufwand dafür ist überschaubar, der Preis für ein Nachrüsten unter Druck deutlich höher.

Quellen