Beobachtbarkeit von KI-Anwendungen: Qualität, Kosten und Fehler bis zu ihrer Ursache verfolgen

Welches Problem Beobachtbarkeit löst

Eine mangelhafte Antwort identifiziert nicht selbst die fehlerhafte Komponente. Ursache kann eine nicht fundierte Generierung sein, aber ebenso eine Retrieval-Abfrage mit wenig passenden Dokumenten, ein externes Tool mit Fehlerantwort, eine Validierung, die eine falsche Ausgabe akzeptierte, oder ein Wiederholungsversuch, der Verhalten und Kosten verändert hat. Nur den finalen Text und eine Fehlermarkierung zu protokollieren, lässt zu viele Hypothesen offen.

Beobachtbarkeit macht aus einer Interaktion eine rekonstruierbare Folge technischer Tatsachen. Ihr praktischer Zweck besteht darin, für eine konkrete Ausführung und für eine Population von Ausführungen zu beantworten: Welche Version bearbeitete die Anfrage? Welche strukturierten Eingaben erhielt sie? Welche Schritte führte sie aus? Wie lange dauerte jeder davon? Welche Ressourcen verbrauchte sie? Und welches überprüfbare Ergebnis entstand? Diese Evidenz hilft, einen Einzelfall von einer Regression nach einer Änderung zu unterscheiden.

Sie ersetzt weder Bewertungen vor dem Deployment noch garantiert sie die Richtigkeit einer Antwort. Ihre Aufgabe ist, diese Praktiken durch Signale aus der Produktion zu ergänzen. Die bereitgestellten Quellen beschreiben, dass Modell, Prompt, Zeiten je Phase, Wiederholungsversuche, Tokens, Kosten und Qualität verbunden werden müssen, wenn der Anwendungsfall dies erfordert. Dieser Leitfaden überträgt diesen Rahmen in einen minimalen Instrumentierungsvertrag, ohne anzunehmen, dass eine aggregierte Kennzahl allein die Ursache erklärt.

Um von diesem Rahmen zu verwandten Materialien zu gelangen, kann die Inhaltsarchitektur auf [Lernen](route:learn.index), [Vergleichen](route:compare.index) und [Entdecken](route:discover.index) verlinken. Diese Links ersetzen nicht die Evidenz, die im Trace jeder Ausführung erfasst wird.

Die Analyseeinheit: ein Interaktions-Trace

Die kleinste nützliche Einheit ist ein Trace pro Geschäftsinteraktion, nicht pro isoliertem Modellaufruf. Er sollte beginnen, wenn die Anwendung eine identifizierbare Aufgabe annimmt – etwa die Beantwortung einer Anfrage oder die Verarbeitung eines Vorgangs – und enden, wenn sie ein Ergebnis ausliefert, ablehnt oder abbricht. Der Trace besitzt eine stabile Kennung und enthält untergeordnete Spans für seine Teilschritte.

Ein Span repräsentiert eine abgegrenzte Operation: Eingabenormalisierung, Retrieval, Modellaufruf, Tool-Ausführung, Wiederholungsversuch, Validierung, Nachbearbeitung oder Auslieferung. Jeder Span bewahrt seine Elternbeziehung, Start und Ende, seinen Status sowie spezifische Attribute. Damit lässt sich eine hohe Gesamtlatenz zerlegen, ohne die Verzögerung automatisch dem Modellanbieter zuzuschreiben.

Der Trace sollte mit einer pseudonymisierten Anfrage- oder Konversationskennung, einem Kanal, einem Aufgabentyp und einer Deployment-Kohorte verknüpft sein. Diese Attribute sollten nicht verwendet werden, um Freitext oder direkte Personenkennungen zu speichern. Ihr Zweck besteht darin, eine Verschlechterung nach Version, Aufgabe, Umgebung oder Kanal segmentieren zu können, ohne die Person hinter der Nutzung erneut zu identifizieren.

Die Rekonstruktion muss unveränderliche Referenzen auf die verwendeten Versionen enthalten: Modell und relevante Parameter, Prompt-Vorlage, Retrieval-Konfiguration, Tool-Definitionen, Validierungsregeln und Flow-Version. Verweist eine Kennung auf veränderlichen Inhalt, kann eine spätere Untersuchung eine andere Konfiguration rekonstruieren als jene, die den Vorfall verursacht hat.

Der minimale Telemetrievertrag

Definieren Sie den Vertrag vor der Instrumentierung. Auf Trace-Ebene erfassen Sie Kennung, Zeit, Umgebung, Aufgabentyp, Kanal, Kohorte, Flow-Version, Endstatus und – sofern vorhanden – ein Geschäftsergebnis. Auf Span-Ebene erfassen Sie Operationstyp, Status, Dauer, Versuchszahl, Abhängigkeiten und Attribute, die den Vergleich von Konfigurationen ermöglichen. Verwenden Sie ein kontrolliertes Vokabular für Zustände wie Erfolg, technischer Fehler, Validierungsfehler, sichere Ablehnung, Abbruch und Zeitüberschreitung.

Für einen Modellaufruf umfassen die Mindestattribute Anbieter oder Modellfamilie, Version oder aufgelösten Alias, sofern verfügbar, Parameter mit wesentlichem Einfluss auf die Ausgabe, Vorlagenkennung, Eingabe- und Ausgabe-Tokens sowie berechnete Kosten oder Daten, die eine Berechnung nach dem geltenden Tarif ermöglichen. Für Retrieval erfassen Sie versionierten Index oder Sammlung, Strategie, Filter, Anzahl der Kandidaten und ausgewählte Dokumente über nicht sensible Kennungen.

Tools benötigen Name und Version, angeforderte Operation, Ergebniscode, Fehlerklasse, Dauer sowie Idempotenz oder einen Korrelationsschlüssel, wenn Aktionen ausgeführt werden. Für Validierungen erfassen Sie Namen und Version der Regel, das Ergebnis und eine Fehlerkategorie. Verwechseln Sie syntaktisch gültiges JSON nicht mit einer geschäftlich akzeptablen Antwort: Das sind unterschiedliche Signale.

Der Vertrag muss dokumentieren, was ausgeschlossen wird. Vermeiden Sie standardmäßig Prompts, Antworten, abgerufene Dokumente, vollständige Tool-Argumente, E-Mail-Adressen, Telefonnummern, Anschriften, Geheimnisse, Zugriffstokens und alle Daten, die für die Diagnose nicht erforderlich sind. Wenn Text für autorisiertes Debugging notwendig ist, wenden Sie Datenminimierung, Maskierung, Zugriffskontrollen und eine getrennte Aufbewahrung an.

Die tatsächlichen Kosten pro Interaktion messen

Die Kosten pro Interaktion entsprechen nicht den durchschnittlichen Kosten eines Hauptaufrufs. Addieren Sie Ein- und Ausgaben des Modells, Wiederholungsversuche, Tool-Aufrufe mit eigener Abrechnung, Retrieval, sofern es zurechenbare Ausgaben verursacht, und fehlgeschlagene Schritte. Halten Sie beobachtete Kosten getrennt von Schätzungen: Erstere stammen aus Nutzungsdaten und angewandten Preisen; Letztere können von Tarifen, Rundungen oder unvollständigen Informationen abhängen.

Ordnen Sie jede Komponente demselben Trace zu und bewahren Sie Währung, Berechnungsdatum sowie die Version der Preistabelle oder der Schätzmethode. Das ist wichtig, weil eine Preis-, Modell- oder Verarbeitungsmodusänderung dazu führen kann, dass zwei Zeiträume nicht direkt vergleichbar sind. Gibt es für eine Komponente keine überprüfbaren Kosten, markieren Sie sie als unbekannt, statt null anzusetzen.

Messen Sie Verteilungen, nicht nur Mittelwerte. Ein stabiler Durchschnitt kann einen Ausläufer von Interaktionen mit zahlreichen Wiederholungsversuchen oder übergroßem Kontext verdecken. Segmentieren Sie nach Aufgabe, Kanal, Version und Endergebnis. Kosten einer Ausführung, die mit einem Fehler endet, sind weiterhin Betriebskosten und müssen sowohl im Gesamtwert als auch in der Verschwendungsanalyse erscheinen.

Wenn menschliche Prüfung beteiligt ist, sollte sie als separater operativer Kosten- oder Aufwandswert mit expliziter Schätzmethode erfasst werden. Eine Vermischung mit Inferenzkosten kann verschleiern, dass eine Latenzoptimierung Arbeit auf Menschen verlagert hat.

Quellen der Latenz trennen

Die Ende-zu-Ende-Latenz ist die Zeit, die Nutzende wahrnehmen, zeigt aber nicht, welche Komponente korrigiert werden muss. Erfassen Sie Spans für Warteschlange oder Annahme, Kontextvorbereitung, Retrieval, Modellaufrufe, Netzwerk – sofern beobachtbar –, Tools, Wiederholungsversuche, Validierung und Ausgabeserialisierung. Die Summe stimmt bei parallelen Operationen möglicherweise nicht exakt mit der Gesamtdauer überein; deshalb muss auch die zeitliche Beziehung zwischen Spans gespeichert werden.

Vergleichen Sie Dauerperzentile je Phase, nicht nur den durchschnittlichen Gesamtwert. Ein Anstieg im hohen Tool-Latenzperzentil bei stabiler Modelllatenz lenkt die Untersuchung auf eine externe Abhängigkeit. Eine Zunahme der Retrieval-Dauer kann von Index, Filter oder einer größeren Kandidatenmenge herrühren. Bei langsamen Antworten durch Wiederholungsversuche müssen sowohl die auslösende Bedingung als auch die Begrenzungsrichtlinie geprüft werden.

Vermeiden Sie vereinfachende Zuschreibungen. Dass ein Trace einen Modellaufruf enthält, beweist nicht, dass das Modell der Engpass war. Angemessene Evidenz ist eine zeitliche Verteilung, segmentiert nach derselben Version, demselben Aufgabentyp und vergleichbaren Bedingungen. Änderungen im Traffic, Inhalt oder Nutzermix sind Störfaktoren, die dokumentiert werden müssen.

Qualitätssignale in der Produktion und ihre Grenzen

Qualität darf nicht auf einen einzigen Score reduziert werden. Nutzerfeedback spiegelt die wahrgenommene Erfahrung wider, kann aber selten sein, zu Extremfällen verzerrt sein oder Kontext vermissen lassen. Menschliche Prüfung erlaubt die Anwendung definierter Kriterien und das Erkennen subtiler Fehler, verursacht jedoch Kosten und deckt nur einen begrenzten Anteil ab. Deterministische Regeln sind für überprüfbare Anforderungen wie ein Schema oder eine Autorisierung reproduzierbar, erfassen aber nicht allein Nützlichkeit, faktische Richtigkeit oder kontextuelle Angemessenheit.

Automatische Evaluatoren können helfen, Stichproben zu priorisieren und Trends zu verfolgen, wenn sie versioniert, gegen menschliche Prüfung kalibriert und mit expliziten Grenzen eingesetzt werden. Sie sind kein unabhängiger Wahrheitsbeweis, insbesondere bei mehrdeutigen Aufgaben oder wenn sie Verzerrungen mit dem bewerteten System teilen. Erfassen Sie ihre Version, verfügbare Eingabe, Kriterium, Ergebnis und Konfidenzniveau, falls die Methode eines erzeugt.

Verknüpfen Sie alle Signale mit dem Trace und unterscheiden Sie ihre Herkunft klar. Ein Rückgang positiver Bewertungen ist nicht gleichbedeutend mit einer verletzten Geschäftsregel; eine Ausgabe mit gültigem JSON beweist nicht, dass ihre Werte korrekt sind. Das Dashboard sollte jedes Signal getrennt anzeigen und danach Übereinstimmungen oder Abweichungen untersuchbar machen.

Ziehen Sie auch Fälle ohne Feedback in die Stichprobe ein, zusätzlich zu negativen Fällen. Sonst lernt das Team nur über Menschen, die Probleme melden, nicht über stille Fehler. Das Stichprobendesign muss dokumentiert werden: Population, Zeitraum, Schichten, Umfang und Prüfungskriterium.

Diagnose von vier häufigen Vorfällen

Eine erfundene Antwort sollte vom Ergebnis rückwärts untersucht werden. Prüfen Sie, ob die Aufgabe Fundierung verlangte, ob Kontext abgerufen wurde, welche Dokumente ausgewählt wurden, welche Anweisungen zur Quellennutzung galten und ob eine Regel oder Prüfung unbelegte Behauptungen erkannte. Wurden Retrieval-Konfiguration oder Prompt-Version nicht erfasst, kann die Ursache unbestimmt bleiben; schreiben Sie den Fehler nicht durch Ausschluss dem Modell zu.

Bei irrelevantem Kontext vergleichen Sie normalisierte Anfrage, Filter, versionierte Sammlung, Strategie, Kandidatenzahl und endgültige Auswahl. Das Problem kann bei Indizierung, Filtern, Metadaten, Änderungen im Korpus oder der Ranking-Strategie liegen. Geringe Relevanz kann auch entstehen, weil die Anfrage vor dem Informationsabruf der falschen Aufgabe zugeordnet wurde.

Bei ungültigem JSON trennen Sie Syntax- von Semantikebene. Prüfen Sie das verlangte Schema, die Methode für strukturierte Ausgabe, die Parser-Version, Wiederholungsversuche und das Validierungsergebnis. Ein erfolgreicher Wiederholungsversuch kann eine steigende Rate zunächst ungültiger Antworten verdecken und Kosten sowie Latenz erhöhen.

Bei einer fehlgeschlagenen Tool-Aktion klären Sie, ob das Tool aufgerufen wurde, zulässige Argumente erhielt, die Abhängigkeit antwortete, eine Zeitüberschreitung auftrat und Teilwirkungen entstanden sind. Aktionen mit Folgen benötigen Idempotenzschlüssel, Bestätigungszustände und Wiederholungsgrenzen. Eine zufriedenstellende finale Antwort beweist nicht, dass die Aktion ausgeführt wurde.

Warnungen, Schwellenwerte und Entscheidungen zum Stoppen

Eine brauchbare Warnung spezifiziert Kennzahl, Zeitfenster, Segment, Schwellenwert, verantwortliche Person, erforderliche Evidenz und erste Maßnahme. „Die Qualität sinkt“ erfüllt dieses Kriterium nicht. Eine operative Formulierung könnte den Anstieg von Validierungsfehlern einer bestimmten Version in einem definierten Zeitfenster überwachen, Beispiel-Traces verlangen und die Prüfung der für den Flow verantwortlichen Person zuordnen.

Nutzen Sie Schwellenwerte als Aufmerksamkeitsregeln, nicht als Beweis für Kausalität. Sie müssen auf einer Basislinie des eigenen Dienstes beruhen und überprüft werden, wenn sich Volumen, Aufgabenmix oder Produkt ändern. Kombinieren Sie Warnungen zu Verfügbarkeit und Sicherheit mit Prüfung von Qualität und Kosten: Die Optimierung einer isolierten Kennzahl kann eine andere verschlechtern.

Stoppen, rollen Sie zurück oder begrenzen Sie eine Änderung, wenn sie eine Sicherheitsbedingung, eine kritische Geschäftsregel oder ein vereinbartes Kostenlimit verletzt oder wenn die Evidenz eine relevante Verschlechterung gegenüber einer vergleichbaren Kohorte zeigt. In anderen Fällen reduzieren Sie die Exposition durch schrittweise Deployments und erhöhen die Stichprobengröße, bevor Sie zu einem Schluss kommen.

Die bereitgestellten Quellen empfehlen, Leistung, Kosten und Qualität zu verknüpfen und Versionen oder Umgebungen zu vergleichen. Eine konkrete Wahl von Schwellenwerten ist in diesen Quellen nicht universell festgelegt; sie muss aus Risiken, Basislinie und Servicezusagen abgeleitet werden.

Aufbewahrung, Minimierung und Zugriff

Ein detaillierter Trace kann zu einem sensiblen Repository werden, wenn er ohne Grenzen gestaltet wird. Beginnen Sie mit der Diagnosefrage und erfassen Sie nur Attribute, die zu ihrer Beantwortung erforderlich sind. Pseudonymisierte Kennungen, angemessen verwaltete Hashes und Fehlerkategorien liefern häufig mehr operativen Wert als das unterschiedslose Speichern vollständiger Prompts, Antworten oder Dokumente.

Trennen Sie operative Daten von Daten für außergewöhnliches Debugging. Erstere können Dauern, Versionen, Zähler, Zustände und technische Referenzen enthalten; Letztere benötigen, sofern begründet, beschränkten Zugriff, Maskierung, Zugriffsprotokollierung und eine definierte kurze Aufbewahrungsdauer. Prüfen Sie außerdem, welche Daten Instrumentierungsbibliotheken an Dritte senden, bevor Sie sie aktivieren.

Definieren Sie, wer Traces einsehen darf, wer Zugriff auf außergewöhnliche Inhalte erhält und wer Regeln für Schwärzung oder Aufbewahrung ändern kann. Löschanfragen, regulatorische Anforderungen und interne Richtlinien können je nach Rechtsraum und Anwendungsfall variieren. Dieser Leitfaden legt keine rechtlichen Pflichten fest; sie erfordern eine auf den organisatorischen Kontext anwendbare Prüfung.

Die bereitgestellte New-Relic-Dokumentation erwähnt Filter, die sensible Daten vor der Übertragung ausschließen. Diese Tatsache stützt die technische Machbarkeit von Filtern, beweist aber nicht, dass eine konkrete Konfiguration für alle Datenkategorien oder alle regulatorischen Rahmen ausreichend ist.

Abschließende Vorlage für Release und minimales Dashboard

Prüfen Sie vor der Freigabe einer Version, dass jede Ausführung mit einer unveränderlichen Version von Flow, Prompt, Modell, Retrieval, Tools und Validierungen verbunden werden kann. Stellen Sie sicher, dass Wiederholungsversuche als unterscheidbare Spans oder Attribute erscheinen, dass Tokens und Kosten allen Versuchen zugerechnet werden und dass Geschäftsergebnisse nicht mit technischen Fehlern verwechselt werden.

Das minimale Dashboard sollte Trace-Volumen, Rate der Endzustände, Gesamtlatenz und Latenz je Phase, Tokens und Kosten pro Interaktion, Wiederholungsversuche, Validierungsergebnisse, Tool-Fehler und nach Herkunft getrennte Qualitätssignale vereinen. Alle Diagramme müssen Filter nach Zeitraum, Umgebung, Version, Aufgabe, Kanal und Kohorte zulassen, damit keine heterogenen Populationen verglichen werden.

Wählen Sie für das Release eine Kontrollkohorte oder frühere Basislinie und definieren Sie im Voraus die Bedingungen für Ausweitung, Pause und Rollback. Bewahren Sie repräsentative Trace-Stichproben auf, einschließlich erfolgreicher, fehlgeschlagener und kostenintensiver Ausführungen. Dokumentieren Sie Änderungen bei Traffic, Korpus, Preisen oder Richtlinien, die die Interpretation verändern könnten.

Das erwartete Ergebnis ist keine automatische Erklärung für jeden Vorfall. Es ist ein System, das die Abhängigkeit von Erinnerungen, Screenshots und vereinzelten Eindrücken verringert und ausdrücklich zeigt, wann die Evidenz eine Schlussfolgerung zulässt und wann sie noch nicht ausreicht.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.