LLM-Überwachung: Was über Latenz, Fehler und Token hinaus zu messen ist

LLM Überwachung sollte mit der Modell Anrufsgesundheit beginnen: Latenz, Fehler, Anforderungsvolumen, Token und Ausgabequalität. Das ist die vernünftige Standardfunktion für eine Chat Funktion, eine Abrufleitung oder einen API Wrapper. Sobald die gleiche Anwendung planen kann, Tools anrufen, auf Genehmigung warten, später wieder aufnehmen oder eine Aufgabe abgeschlossen erklären kann, fügen Sie ein zweites Hauptbuch für die Betriebsgesundheit hinzu. Die beiden Hauptbücher beantworten unterschiedliche Fragen. Der erste fragt, ob sich der Modelldienst normal verhalten hat? Der zweite fragt, ob der Agent nützliche Fortschritte erzielt hat und das erwartete Ergebnis erzielt hat. run id ; verwandeln Sie nicht ein grünes Latenzdiagramm in eine Behauptung, die Arbeit sei gesund. Beginnen Sie mit der Standard LLM Überwachungsschicht Ein nützliches erstes Dashboard benötigt keine Dutzende von Platten. Es benötigt ausreichend Beweise, um Versagen von Anbietern, Versagen von Anwendungen, Kostendrift und Qualitätsdrift zu trennen. Signal Frage, die sie beantwortet Praktische erste Warnung Was sie nicht beweisen kann Fehlerquote bei Anfragen Sind Modellanrufe scheitern? Rate über ein Fenster, geteilt nach Anbieter und Modell Ob erfolgreiche Anrufe die Aufgabe vorangetrieben haben P50/p95 Latenz Hat die Reaktionszeit zurückgegangen? Vergleichen Sie ähnliche Operationen und Modelle Ob ein langsamer Lauf schließlich geliefert Ein und Ausgangs Token Ist der Kontext oder die Generation gewachsen? Veränderung von einer spezifischen Aufgabenbasis Ob die zusätzlichen Token nützlich waren Durchsatz Ändert sich die Last? Anfragen pro Minute plus Gleichzeitigkeit Ob ein geplanter Lauf verpasst wurde Qualitätsscore Hat die Probenausgabe eine Rubrik erfüllt? Versionerte Evaluator plus menschliche Kalibrierung Ob eine Datei, ein Ticket oder eine Bereitstellung existiert Spurenbedeckung Kann ein Betreiber die Ausführung rekonstruieren? Fehlende oder unvollständige Spuren nach Laufzeit Ob das beabsichtigte Ergebnis vorhanden ist Diese Ausgangslinie entspricht der aktuellen Suchansicht. Langfuse beschreibt die Überwachung rund um Latenz , Durchsatz und Fehlerraten, mit Spuren für Ausführungswege und Bewertung für die Ausgabequalität. Splunk und Dynatrace erweitern das Set auf Ressourcen, Sicherheit, Kosten, Feedback und Anwendungssignale. Dies sind nützliche Ansichten einer LLM Anwendung; keine sollten nur deshalb entsorgt werden, weil eine Agenschicht vorhanden ist. Die semantischen GenAI Konventionen von OpenTelemetry machen die Trennung in der Instrumentation selbst sichtbar. Die Entwicklungsspezifikation definiert gen ai.client.token.usage und gen ai.client.operation.duration , dann separate Workflow und Agenteninstrumente wie gen ai.invoke agent.duration , Abschluss und Werkzeug Aufrufzahl. Entwicklung Hier ist wichtig: Steck die Version fest, die du implementierst, und erwarte, dass die Namen geändert werden. Die saubere Implementierung ist ein Modell Call Ledger mit run id , operation , provider , model und Timestamp. Aggregieren Sie es für Service Alarme, aber halten Sie einen Weg zurück zum einzelnen Laufen. Ein Token Spike ohne Run Identifikator ist eine Rechnung; ein Token Spike, der an einen Stillstand Run befestigt ist, ist ein Vorfall Hinweis. Fügen Sie ein Aufgaben Gesundheitsbuch hinzu, wenn die Anwendung ein Agent wird Eine von LLM unterstützte Funktion überschreitet die operative Grenze, wenn sie im Laufe der Zeit Arbeit besitzt. Es könnte eine Datenbank anrufen, einen Bericht schreiben, eine Anfrage öffnen, auf eine Person warten oder nach einem Zeitplan aufwachen. Zu diesem Zeitpunkt sind erfolgreiche Modellreaktionen nur zwischengeschaltete Ereignisse. Das OpenAI Agents SDK zeigt, wie reich diese Ereignisse werden können. Seine eingebauten Tracing Aufzeichnungen Generationen, Funktion Tool Anrufe, Handoffs, Guardrails und Agent Runns. Das sind wertvolle Debug Beweise. Die gleiche Dokumentation stellt auch fest, dass Generations und Funktionsspannen empfindliche Eingaben und Ausgänge enthalten können, was ein Grund dafür ist, dass die Erfassung von Inhalten eher eine explizite Wahl als eine Überwachungsvoraussetzung ist. Ein Aufgaben Gesundheitsbuch kann kleiner bleiben als die Spur. Für jeden Lauf: expected outcome : ein Prädikat wie report exists and parses , nicht der Satz beenden Sie die Aufgabe; outcome verified : true , false oder unavailable mit Verifizierungsversion; progress delta : eine auf die Aufgabe spezifische Zählung oder Verdauungsänderung über ein angegebenes Fenster; waiting on : eine benannte Abhängigkeit wie human approval oder null ; last heartbeat at und last progress at , da Aktivität und Fortschritt unterschiedliche Uhren sind; declared complete : das, was die Laufzeit gemeldet hat; collector freshness : wann diese Tatsachen zuletzt beobachtet wurden. Dieses Hauptbuch wiederholt absichtlich nicht jeden Anruf, jeden Abschluss oder jeden Zeitraum. Es speichert die geringsten Beweise, die benötigt werden, um zu entscheiden, ob der Lauf funktioniert, wartet, steckt, unerreichbar oder abgeschlossen ist. Rohspuren bleiben für die Untersuchung verfügbar, wenn die Politik dies erlaubt. Die wichtige Modellwahl ist Tri State Beweise. Wenn ein Sammler das Lieferwert nicht überprüfen kann, registriert er outcome verified: "unavailable" . Verwenden Sie keine fehlenden Beweise in true und nennen Sie einen unbekannten Lauf nicht fehlgeschlagen, nur weil sein Signal fehlt. Wiederholen Sie die Lücke mit sechs Runs Das Begleitgerät enthält sechs synthetische Runden. Die LLM Ledger Alerten, wenn Anforderungsfehler mindestens 20% sind, übersteigt die P95 Latenz 5.000 ms oder die Token Nutzung übersteigt 20.000. Das Aufgaben Gesundheitsbuch überprüft explizite Wartezeit, erklärte Fertigstellung gegenüber einem deterministischen Ergebnis und Fortschrittsfrischheit. Führen Sie die Prüfung mit Node.js 20 oder neuerer Ausführung durch: Das genaue Ergebnis ist: Die Meinungsverschiedenheit ist das Ergebnis, nicht ein Defekt in beiden Hauptbüchern. Die Provider Fehler Runde erfordert eine Modell Service Untersuchung, obwohl der Agent noch Fortschritte macht. Der langsame Lauf ist mit einem bestätigten Ergebnis abgeschlossen, also handelt es sich um ein Leistungsproblem und nicht um einen Fehlvorfall. Die Genehmigungswartung und der falsche Erfolgslauf sehen für den LLM Monitor normal aus, weil ihre Anrufe schnell, billig und erfolgreich waren. Nur der Auftragsvertrag enthüllt, was Aufmerksamkeit braucht. Die Zahlen sind ein Gegenbeispiel, nicht ein Benchmark. Sechs synthetische Aufzeichnungen können keine universellen Warnschwellen festlegen. Ersetzen Sie die Einschränkungen durch Basislinien aus Ihrer Laufzeit, und ersetzen Sie progress delta durch Beweise, die mit dem tatsächlichen Job verbunden sind. Verwandeln Sie den Auftragsvertrag in Warnungen Beginnen Sie mit einem hochwertigen Workflow. Schreiben Sie den Abschlussprädikat, bevor Sie ein weiteres Dashboard hinzufügen. Eine Forschungsarbeit erfordert möglicherweise eine Markdown Datei, mindestens zwei erreichbare Quellen und ein schemafähiges Beweisbuch. Ein Coding Job erfordert möglicherweise einen Clean Patch plus einen benannten Testbefehl. Ein Unterstützungsagent kann ein erstelltes Ticket oder eine aufgezeichnete Eskalation verlangen. Dann beurteilen Sie die Signale in einer Reihenfolge, die die Bedeutung bewahrt: 1. Wenn die Laufzeit oder der Sammler veraltet ist, markieren Sie den Lauf unerreichbar oder unsicher. 2. Wenn waiting on explizit ist, lenken Sie die Abhängigkeit anstatt den Lauf neu zu starten. 3. Wenn die Laufzeit den Abschluss erklärt, bewerten Sie die Ergebnisprädikate. 4. Wenn der Lauf aktiv ist, aber progress delta außerhalb seines Fensters Null bleibt, markieren Sie ihn fest. 5. Wenn keine Anwendung findet und der nützliche Fortschritt frisch ist, lassen Sie ihn funktionieren. Dieser Befehl verhindert drei laute Eingriffe. Eine rechtmäßige Genehmigung ist keine Haltestelle. Ein Befehl, der aus Null herausgegangen ist, ist nicht automatisch eine vollendete Aufgabe. Eine sehr beschäftigte Spur mit wiederholten Werkzeugen ist kein Fortschritt, wenn sich das relevante Artefakt nie ändert. Warnung auf die nächste sichere Aktion, nicht nur das Symptom. Eine Anbieter Fehlerwarnung geht an den Anwendungsbesitzer mit Modell, Betrieb, Fehlerklasse und Spurenverbindung. Eine Genehmigungswartung geht an die Person, die entscheiden kann, mit dem genauen Umfang, der angefordert wird. Ein Missergebnis Alarm verweist auf das fehlgeschlagene Prädikat. Eine erneute Versuchsschleife empfiehlt eine begrenzte Pause oder Untersuchung; sie sollte keine irreversible Behebung zulassen. Halten Sie die Verbindung nützlich, ohne alles zu sammeln Verwenden Sie eine unsichtbare run id über beide Hauptbücher. Stellen Sie nicht Kundentext, Geheimnisse, absolute Wege oder Werkzeugnutzlasten in diesen Identifikator. Ein nützlicher Korrelationsregister kann Folgendes enthalten: Die Regeln für die Speicherung und den Zugang unterscheiden sich, wenn sich die Datenrisiken unterscheiden. Aggregate Latenz und Token Histogramme benötigen möglicherweise eine längere Aufbewahrungsdauer als prompt bearing Spanes. Ergebnisbeweise können oft ein Verdauung, Zählung, Statuscode oder Schema Ergebnis sein, anstatt das Artefakt selbst. Wenn ein Betreiber in eine Spur bohrt, zeigen Sie ihre Frische und die Probenahmegrenze, damit Abwesenheit nicht als Beweis verwechselt wird. Es gibt auch eine Grenze für die automatisierte Bewertung. Deterministische Kontrollen sind für Dateien, HTTP Status, Datenbankzeilen, Tests und strukturierte Felder vorzuziehen. Wenn das beabsichtigte Ergebnis qualitativ ist, kann ein versionierter Evaluier helfen, aber seine Punktzahl ist Beweise mit Unsicherheitnicht Grundwahrheit. Kalibrieren Sie es gegen menschliche Überprüfung und bewahren Sie einen unavailable Zustand. In welchem Sidewisp passt Die Produktrichtung von Sidewisp ist das zweite Hauptbuch: eine Gesundheitsansicht rund um die bestehenden Agentenlaufzeiten, mit Beweisen, Frische, Ausgabepriorität und expliziten Genehmigungsgrenzen. Es soll nicht die Laufzeit, das Modell Gateway oder das Roh Tracing System ersetzen. Das ist eine Richtung, nicht eine Beobachtungsbehauptung. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Das öffentliche Website und Artikelsystem sind live, während die Produktion Agent Gesundheit Sammlung, Laufzeit Adapter und die Wiederherstellung der Ausführung im Allgemeinen nicht ausgeliefert werden. Nehmen Sie die private Vorschau an, wenn diese Modell Anruf Verglichen Ergebnis Grenze mit dem Betriebsproblem übereinstimmt, das Sie lösen müssen. Hauptquellen OpenTelemetry GenAI Metriken semantische Konventionen Entwicklungsstatus Metriknamen für Client , Workflow , Agent und Tool Operationen. OpenAI Agents SDK Tracing Leitfaden Spuren von Ereignisarten, Exportverhalten und Sensitivdatenkontrollen. Langfuse: Was ist die Beobachtbarkeit und Überwachung von LLM? ein gleichbedeutender Benchmark für Latenz, Durchsatz, Fehler, Tracing und Bewertung.