Jev vs. LLMs bei der Trace-Analyse für KI-Agenten: Entscheidungen, Kosten und Belege

Was ist Trace-Analyse für KI-Agenten?

Die Trace-Analyse für KI-Agenten prüft aufgezeichnete Modellaufrufe, Werkzeugaktionen und Zustandsänderungen, um Ergebnisse zu erklären. Dieser Leitfaden vergleicht Jevs typisierte Entscheidungen mit LLM-basierter Interpretation. Er zeigt, wie Sie Labels validieren, Kosten steuern und Befunde vor einem Release mit Belegen verknüpfen.

Beginnen Sie mit der Entscheidung, die Sie treffen müssen. Bei einem Agenten für Bestelländerungen könnte die Frage lauten, ob er Freigaben beachtet und den vorgesehenen Datensatz hinterlässt. Für die verantwortliche Fachabteilung ist das nützliche Ergebnis ein überprüfter Vorgang mit betroffener Arbeit, Belegen und einer zuständigen Person. Eine Sammlung interessanter Gesprächsprotokolle beantwortet diese Frage noch nicht.

Ein Trace ist eine instrumentierte Aufzeichnung beobachtbarer Ausführung. Er kann unvollständig sein und legt keine privaten internen Denkprozesse eines Modells offen. OpenTelemetry beschreibt Spans als Vorgänge, die innerhalb von Traces miteinander verbunden werden können.

Die folgende Methode dient der fachlichen Orientierung. Ihre Ereignisfelder, der Klassifikationsentwurf, die Diagramme und Berechnungen sind vorgeschlagene Beispiele. Sie sind keine Spezifikation veröffentlichter Bibha-Funktionen und kein Bericht über einen Kundeneinsatz. Die verlinkten Bibha-Seiten zu Agenten und Monitoring erläutern den Plattformkontext dieser Prüfmethode.

Quellen: Traces | OpenTelemetry (externe Website)

Was ist Jev und welche Ergebnisse liefert es?

Jev ist das System-One-Modell von TypeSafe AI. TypeSafe beschreibt Training mit Reinforcement Learning for Calibrated Decisions (RLCD) und parallele typisierte Ausgaben anstelle erzeugter Prosa. Diese Schnittstelle begrenzt die Antwortform. Sie macht nicht jede semantische Entscheidung korrekt.

Choice-Fragen wählen vorgegebene Optionen, Score-Fragen verwenden definierte Stufen und Noul-Fragen liefern eine Wahrheitswahrscheinlichkeit. Jede Frage bewertet denselben Zustand unabhängig. Choice und Score enthalten Konfidenzwerte, die aus ihren Wahrscheinlichkeitsverteilungen abgeleitet werden. Noul hat kein separates Konfidenzfeld.

Die aktuelle Dokumentation nennt Jev 1.13 mit der Modell-ID jev-1.13.0, ausschließlich Texteingaben, ein Gesamtbudget von 64k Tokens pro Anfrage und eine separate Grenze von 32k für Zustand plus längste Frage. Fixieren Sie die Version und prüfen Sie den tatsächlichen Belegausschnitt. Evaluieren Sie deutsche und andere nicht englische Aufgaben gesondert.

Quellen: TypeSafe AI: introducing System One models and Jev (externe Website)TypeSafe AI: Choice, Score and Noul questions (externe Website)TypeSafe AI: confidence and probability distributions (externe Website)TypeSafe AI: Jev models, versions and limits (externe Website)

Jev vs. LLMs: wählen Sie zuerst die Aufgabe

Prüfen Sie Jev für definierte Entscheidungen, sobald Richtlinie, Belegansicht und Labels feststehen. Prüfen Sie ein LLM für Vorschläge neuer Kategorien, die Interpretation unbekannter Fälle oder die Formulierung einer beleggestützten Erklärung. Diese Rollen sind zu evaluierende Empfehlungen. Sie behaupten nicht, dass ein Modell jede Aufgabe gewinnt.

Auch LLMs können schemabeschränkte strukturierte Werte erzeugen, wie TypeSafes Einführung ausdrücklich anerkennt. Vergleichen Sie den vollständigen Prüfprozess: akzeptierte Ausgaben, Belegqualität, Fehler, Entscheidungsenthaltungen, Latenz und tatsächliche Kosten. Erhalten Sie menschliche Bewertung bei wichtigen Meinungsverschiedenheiten und verbinden Sie Quellereignisverweise durch validierte Anwendungslogik.

Quellen: TypeSafe AI: introducing System One models and Jev (externe Website)TypeSafe AI: Jev models, versions and limits (externe Website)TypeSafe AI: Choice, Score and Noul questions (externe Website)TypeSafe AI: confidence and probability distributions (externe Website)

Ordnen Sie den veröffentlichten Vergleich ein

Applied Compute berichtete am 23. September 2026 über 148 Banking-Traces aus 69 Szenarien. Jev 1.13.0 erreichte beim Schwellenwert 0,20 einen Recall von 85% gegenüber der Vereinigung der Sol-/Claude-Opus-Labels, keiner menschlichen Referenzwahrheit. Die Kostenschätzung betrifft eine Annotation über 10.000 Traces. Dies sind Versuchsergebnisse, keine Bibha-Ergebnisse oder allgemeingültige Rangfolge. Validieren Sie Ihren Arbeitsumfang.

Quellen: Billion-Token Scale Trace Analysis: Jev vs LLMs | Applied Compute (externe Website)

Definieren Sie Arbeitsumfang und Untersuchungszeitraum

Messen Sie den Umfang in mehreren Einheiten, bevor Sie ein Analysewerkzeug auswählen. Zählen Sie relevante Geschäftsläufe, aufgezeichnete Ereignisse, gespeicherte Bytes, Analyseanfragen und Ein-/Ausgabetokens getrennt. Halten Sie den Zeitraum, die Workflow-Zusammensetzung und Systemversionen neben diesen Kennzahlen fest. Jede beantwortet eine andere Kapazitäts- oder Qualitätsfrage. Ein großer Tokenwert kann nicht alle ersetzen.

Wählen Sie die Einheit passend zur Geschäftsentscheidung. Eine Bestellaufgabe kann mehrere Dienste und Trace-IDs durchlaufen. Ein Gespräch kann wiederum mehrere Bestellungen betreffen. Verbinden Sie technische Traces mit einer nicht sprechenden Aufgaben-ID und definieren Sie, ob Wiederholungsversuche zum selben Lauf oder zu einem neuen Versuch gehören. Trennen Sie Produktionsaufgaben von erzeugten Testläufen und Trainings-Rollouts, sofern ein Vergleich nicht ausdrücklich beides verlangt.

Für diesen Leitfaden gilt ein abgeschlossener oder unterbrochener Bestelländerungsversuch als relevante Einheit. Das Ergebnis wird nur akzeptiert, wenn die erforderliche Freigabe und der maßgebliche Bestellzustand übereinstimmen. Diese Festlegung verhindert, dass eine schnelle Antwort oder eine erfolgreiche HTTP-Anfrage versehentlich zum Erfolgsmaß wird. Andere Workflows benötigen eigene Abnahmekriterien.

Erstellen Sie vor der Analyse eine kurze Beschreibung des Datenumfangs: Zeitraum, Einschlussregeln, ausgeschlossene Läufe, Versionen, Aufbewahrungslücken und verantwortliche Person. Erfassen Sie neben dem Durchschnitt auch die Verteilung der Trace-Längen. Wenige sehr lange Traces können Anfragegrenzen und Prüfaufwand bestimmen. Testen Sie diese Fälle gezielt, statt sie im Mittelwert zu verbergen.

Erfassen Sie genügend Belege für einen Befund

Eine Belegvereinbarung definiert, was aufgezeichnet werden muss, um die Prüffrage zu beantworten. Beginnen Sie mit stabilen Aufgaben-, Lauf- und Ereignis-IDs, kausalen Verbindungen, Vorgang und Ergebnis, Versionen von Workflow, Modell, Werkzeug und Richtlinie sowie einem Verweis auf die Ergebnisprüfung. Ergänzen Sie einen Vollständigkeitsstatus, damit fehlende Belege vor der Klassifikation sichtbar sind.

OpenTelemetry stellt Zeitstempel, Attribute, Ereignisse, Verbindungen und Statusinformationen zu Spans bereit. W3C Trace Context spezifiziert Korrelationsheader. Die aktuellen OpenTelemetry-Konventionen für generative KI sind weiterhin als Development gekennzeichnet. Fixieren Sie die verwendeten Konventions- und Instrumentierungsversionen. Die hier vorgeschlagenen Beschaffungsfelder sind Anwendungsfelder. Sie bedeuten nicht, dass ein universeller Standard bereits jeden geschäftlichen Freigabedatensatz definiert.

Legen Sie die Bedeutung jedes Feldes fest. Ein Freigabeergebnis sollte die betroffene Aktion und Datensatzversion, die Entscheidung und die erteilende Instanz benennen. Das Ergebnis einer Änderung sollte zwischen angenommen, gespeichert, abgelehnt und ungewiss unterscheiden. Bei einer Zeitüberschreitung des Werkzeugs bleibt die Ungewissheit bestehen, bis eine zulässige Zustandsprüfung sie auflöst. Ein fehlender Span beweist nicht, dass der Vorgang nie stattfand.

Testen Sie die Erfassungsvereinbarung mit doppelten Ereignissen, fehlenden übergeordneten Verweisen, verspäteter Übermittlung und unterbrochenen Läufen. Entfernen Sie Duplikate anhand der dokumentierten Ereignisidentität, ohne einen berechtigten zweiten Versuch zu verwerfen. Speichern Sie Erfassungsfehler neben Vollständigkeitsmaßen und vergleichen Sie angenommene Ereignisse mit erwarteten Ereignisgruppen. Für die Instrumentierungsqualität braucht es eine zuständige Person, weil unzuverlässige Erfassung wie unzuverlässiges Agentenverhalten aussehen kann.

Quellen: Traces | OpenTelemetry (externe Website)Trace Context | W3C Recommendation (externe Website)Semantic conventions for generative AI systems | OpenTelemetry (externe Website)

Durchsuchen Sie Metadaten vor geschützten Inhalten

Suchen Sie relevante Läufe in einem kompakten Index und laden Sie danach nur die zulässigen Belege für die Prüfung. Halten Sie IDs, Vorgangstypen, Versionen, Zeitangaben und Vollständigkeit durchsuchbar. Ausführliche Prompts, abgerufene Dokumente und Werkzeugdaten benötigen möglicherweise einen getrennten geschützten Speicher mit eigenen Zugriffs- und Aufbewahrungsregeln. Ihre Erfassung ist eine bewusste Entscheidung und keine allgemeine Voraussetzung.

Die OpenTelemetry-GenAI-Dokumentation behandelt die Erfassung von Ein- und Ausgabeinhalten als sensibel und optional. Als Speicheroption bietet Parquet komprimierte Spaltendaten. DuckDB unterstützt die Weitergabe von Spaltenauswahl und Filtern an Parquet-Scans. Seine Partitionsverarbeitung kann Dateien anhand von Partitionsfiltern überspringen. Diese Fähigkeiten können Sie im vorhandenen Datenbestand prüfen. Sie beschreiben nicht die Implementierung von Bibha.

Beginnen Sie mit den Speicher- und Abfragewerkzeugen, die Ihr Team bereits betreibt. Partitionieren Sie nach einem geeigneten Zeit- oder Arbeitsbereich nur dann, wenn repräsentative Abfragen davon profitieren. Verwenden Sie keine unverarbeiteten Personen- oder Mandantenkennungen in Dateipfaden. Eine Partition dient der Leistung. Organisationsgrenzen müssen Sie durch tatsächliche Zugriffskontrollen durchsetzen und unabhängig testen.

Messen Sie Abfragelatenz, Scanvolumen, Erfassungsverzögerung und autorisierten Inhaltsabruf über einen realistischen Zeitraum. Berücksichtigen Sie Löschung und Ablauf: Ein Quellinhalt kann nicht mehr verfügbar sein, obwohl eine Annotation bestehen bleibt. Erhalten Sie die zulässigen Belegverweise des Befunds und dokumentieren Sie die Änderung der Verfügbarkeit. Stellen Sie ein Label nicht stillschweigend als vollständig reproduzierbar dar, nachdem sein entscheidender Quellbeleg abgelaufen ist.

Quellen: Semantic conventions for generative client AI spans | OpenTelemetry (externe Website)Reading and Writing Parquet Files | DuckDB (externe Website)Hive Partitioning | DuckDB (externe Website)

Beispiel: eine Lieferantenänderung vor der Freigabe

Der fiktive Lauf PO-DEMO-042 zeigt eine beobachtbare Umgehung einer Freigabe. Richtlinie P-7 verlangt eine aktuelle Freigabe, bevor der Lieferant einer Bestellung geändert wird. Ereignis e03 dokumentiert die Verweigerung für genau diese Aktion. e04 dokumentiert die gespeicherte Änderung. e05 bestätigt unabhängig die geänderte Bestellung. Freigabe und Änderung beziehen sich auf denselben Vorschlag. Ihre Beziehung stützt deshalb den Befund.

Die Ereignistabelle ist bewusst klein. Alle IDs, Richtlinien, Datensatzversionen und Ergebnisse sind erfunden. Prüfen Sie in einer echten Untersuchung die Anwendbarkeit der Richtlinie, die Gültigkeit der Freigabe, die Aktionsidentität und die kausale Reihenfolge, bevor Sie denselben Schluss ziehen. Uhrzeiten unterschiedlicher Maschinen können ungenau sein. Übergeordnete Verbindungen und aufgezeichnete Abläufe können helfen festzustellen, was dem Schreibvorgang vorausging.

Ereignis e06 zeigt ein weiteres Problem: Die abschließende Antwort bezeichnet die Änderung als freigegeben, obwohl die aufgezeichnete Freigabe verweigert wurde. Das belegt den Widerspruch zwischen der Antwort und dem Freigabedatensatz. Es erklärt nicht, warum das System handelte. Eine veraltete Richtlinie, ein Orchestrierungsfehler oder eine Lücke bei Werkzeugberechtigungen könnten Ursachen sein. Jede bleibt jedoch eine Hypothese, bis die relevante Komponente geprüft wurde.

Fehlte e03, würden die Belege eine bestätigte Änderung stützen, aber keine gewährte oder verweigerte Freigabe nachweisen. Würde e04 eine Zeitüberschreitung melden und e05 fehlen, bliebe das Schreibergebnis ungewiss. Diese Varianten benötigen unterschiedliche Befunde. Die prüfende Person sollte keine dieser Lücken durch die selbstsichere Formulierung der abschließenden Antwort ersetzen.

Nutzen Sie eine Beleg-Pipeline mit Prüfstufen

Eine nützliche Analyse-Pipeline trennt Erfassung, Prüfung, Interpretation und Freigabebefugnis. Das Diagramm führt das fiktive Bestellbeispiel durch eine vorgeschlagene Folge: Untersuchungszeitraum auswählen, Vollständigkeit prüfen, zulässige Belege aufbereiten, definierte Prüfungen anwenden, unklare Befunde entscheiden und eine vorgeschlagene Änderung bewerten. Jede Stufe liefert ein überprüfbares Ergebnis statt einer unterstellten Garantie.

Bei der Vollständigkeitsprüfung behält PO-DEMO-042 seine Verweise auf Freigabe, Änderung und Zustandsprüfung. Bei der fachlichen Prüfung erhält die prüfende Person approval_bypass als vorgeschlagenes Label mit e03 und e04. Bei der abschließenden Bewertung bestätigt sie, dass die Richtlinie auf diese Aktion zutrifft. Eine Freigabestufe wird erst erreicht, nachdem eine verantwortete Änderung an separaten Aufgaben unter vereinbarten Abnahmekriterien getestet wurde.

Halten Sie den Pfad für fehlende Belege sichtbar. Ein Lauf ohne entscheidenden Freigabedatensatz kann in eine Warteschlange für Belegreparatur oder menschliche Prüfung gehen, statt zwangsweise als Erfolg oder Fehler zu gelten. Ein Lauf mit bekanntem Transportfehler kann eine deterministische Prüfung durchlaufen und dennoch eine Ergebnisprüfung benötigen. Die Verzweigungen zeigen diese Entscheidungen. Ihre Größe und Position stellen keine Datensatzanteile dar.

Protokollieren Sie die Analyseversion und jede Prüfentscheidung. Ändert eine spätere Richtlinien- oder Taxonomieversion die Interpretation, erhalten Sie den früheren Prüfdatensatz und erstellen ausdrücklich einen neuen. Die Pipeline ermöglicht damit nachvollziehbare Entscheidungen über eine Sammlung hinweg. Sie ist ein empfohlenes Vorgehen für den Betrieb. Ein Diagramm allein schafft kein automatisiertes oder vollständiges Kontrollsystem.

Reduzieren Sie Eingaben ohne entscheidende Belege zu verlieren

Die Vorverarbeitung sollte relevante Belege leichter prüfbar machen und dabei die Grundlage des Befunds erhalten. Erstellen Sie eine kompakte Betriebsansicht aus stabilen Ereignisverweisen, zulässigen Auszügen, Aktionsidentität, Voraussetzungsergebnissen und Änderungszuständen. Bewahren Sie den Quelldatensatz innerhalb seiner autorisierten Aufbewahrungsgrenzen auf. Kennzeichnen Sie jede Schwärzung, Auslassung und Kürzung, damit die lesende Person die Grenzen der Ansicht beurteilen kann.

Bei PO-DEMO-042 muss die kompakte Ansicht die verweigerte Freigabe aus e03 und die gespeicherte Änderung aus e04 erhalten. Eine wiederholte Katalogantwort zu entfernen, kann für diese Frage unproblematisch sein. Die Freigabe als vermeintlich routinemäßige Metadaten zu entfernen, verändert dagegen die Frage selbst. Eine Zusammenfassung, die nur eine aktualisierte Bestellung meldet, würde die nötigen Belege zur Unterscheidung zwischen freigegebener Änderung und Umgehung beseitigen.

Lost in the Middle zeigte bei den untersuchten Such- und Fragebeantwortungsaufgaben einen Einfluss der Informationsposition. LongLLMLingua untersucht Prompt-Kompression für bestimmte Aufgaben mit langen Kontexten. Diese Arbeiten begründen Tests dazu, wie die Belegauswahl Ihren Klassifikator beeinflusst. Sie belegen nicht, dass ein bestimmtes aktuelles Modell ein Ereignis übersehen wird oder Kompression jedes relevante Detail bewahrt.

Erstellen Sie einen Prüfsatz mit langen Traces, spät auftretenden Voraussetzungen, wiederholten Werkzeugausgaben und widersprüchlichen Nachrichten. Vergleichen Sie Labels und Belegverweise vor und nach der Reduktion. Untersuchen Sie Abweichungen und halten Sie fest, ob die entfernten Belege relevant waren. Versionieren Sie das Reduktionsverfahren gemeinsam mit dem Bewertungsraster. Eine niedrigere Tokenrechnung hilft nur, wenn die resultierende Ansicht weiterhin die beabsichtigten Entscheidungen stützt.

Quellen: Lost in the Middle: How Language Models Use Long Contexts (externe Website)LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression (externe Website)

Definieren Sie Fehlerlabels mit Grenzen und Zuständigkeiten

Eine Fehlertaxonomie ist ein versioniertes Vokabular für beobachtete Muster. Prüfen Sie zunächst unterschiedliche Läufe gemeinsam mit den Workflow-Verantwortlichen. Entwerfen Sie anschließend wenige Labels, die betriebliche Fragen beantworten. Geben Sie jedem Label Einschlussbelege, Ausschlussregeln, Schweregrad und eine zuständige Person. Erfassen Sie Beobachtungen, vermutete Ursachen und geschäftliche Folgen in getrennten Feldern.

Die interaktive Taxonomie verwendet ein eigenständiges Beschaffungsbeispiel mit sechs Labels. Die Auswahl eines Labels sollte seine Bedeutung und die erforderlichen Belege anzeigen. Die Tabelle enthält dieselben Definitionen als lesbaren Text. Diese Kategorien sind Lehrbeispiele, kein Standard, kein Kundenergebnis und kein veröffentlichter Bibha-Klassifikator. Ein Lauf kann mehrere Labels tragen. unknown bedeutet, dass die aktuellen Definitionen seine Einordnung nicht klären können.

Verlangen Sie für approval_bypass einen Beleg dafür, dass die anwendbare Freigabe beim Speichern der konkreten Änderung verweigert oder anderweitig unerfüllt war. Ein allein fehlendes Freigabeereignis ist ausgeschlossen, weil die Sammlung unvollständig sein könnte. evidence_missing erfasst diese Einschränkung. Diese Grenze verhindert, dass ein Erfassungsfehler automatisch als Richtlinienverstoß erscheint. Die Instrumentierungsverantwortlichen erhalten damit einen gesonderten Vorgang zur Klärung.

Nutzen Sie explorative Prüfungen, um Definitionen vor einer Release-Messung zu verbessern. Dokumentieren Sie Richtlinien- und Taxonomieversionen, bewahren Sie schwierige Beispiele auf und fixieren Sie das Vokabular für jedes Vergleichsfenster. Wird eine Kategorie später aufgeteilt, dokumentieren Sie die Zuordnung und bewerten bei Bedarf einen gemeinsamen Vergleichssatz erneut. Neue Labels können nützlich sein. Ihr Auftreten darf jedoch nicht mit einer Verschlechterung des Agenten verwechselt werden.

Wählen Sie die Prüfung passend zu den Belegen

Verwenden Sie deterministische Prüfungen, wenn die relevante Bedingung ausdrücklich in strukturierten Daten vorliegt. Nutzen Sie semantische Klassifikation, wenn die Interpretation Richtlinientext oder mehrere verbundene Ereignisse erfordert. Setzen Sie menschliche Bewertung für strittige, neue oder folgenreiche Fälle ein. Die Methoden können zusammenarbeiten. Keine sollte allein deshalb Ausführungsbefugnisse erhalten, weil sie ein Label erzeugt.

Eine deterministische Regel kann die Entscheidung aus e03 mit dem gespeicherten Zustand aus e04 vergleichen, sofern Aktions-IDs und Richtlinienbereich zuverlässig sind. Ein LLM-basierter semantischer Klassifikator kann vorschlagen, dass e06 der aufgezeichneten Freigabe widerspricht, und die Beleg-IDs mit einer kurzen Erklärung zurückgeben. Eine fachlich prüfende Person kann eine mögliche Freigabeausnahme klären. Verlangen Sie von allen drei Verfahren dieselbe Belegdisziplin.

Modellbasierte Bewerter benötigen eigene Prüfungen. Die MT-Bench-Studie zu solchen Bewertern identifiziert Positions-, Ausführlichkeits- und Selbstbevorzugungsverzerrungen in den untersuchten Situationen. Testen Sie für diesen Workflow, ob eine andere Reihenfolge gleichwertiger Belege, eine veränderte Antwortlänge oder die Modellbezeichnung Labels beeinflusst. Diese Experimente zeigen Grenzen des ausgewählten Bewerters und Rasters, statt die berichtete Übereinstimmung eines anderen Benchmarks zu übernehmen.

Begrenzen Sie Ein- und Ausgaben des Klassifikators. Stellen Sie zulässige Belege, anwendbare Richtlinien und aktuelle Definitionen bereit. Validieren Sie zurückgegebene Label-IDs und Ereignisverweise. Eine Erklärung ohne gültigen Verweis ist ein Prüfhinweis und kein gesicherter Befund. Fehlen Belege oder widersprechen sich Interpretationen, sollte die Prüfung sich einer Entscheidung enthalten und den Fall in die passende Warteschlange leiten.

Quellen: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (externe Website)

Erstellen Sie geprüfte Beispiele vor der Klassifikatormessung

Erstellen Sie einen Referenzsatz für die Entscheidungen, die der Klassifikator treffen soll. Nehmen Sie akzeptierte Läufe, relevante Fehler, unvollständige Belege und berechtigte Ausnahmen auf. Lassen Sie Fachprüfende die Belege nach Möglichkeit unabhängig labeln und klären Sie anschließend Meinungsverschiedenheiten. Die aufgelösten Entscheidungen bilden die Referenz für diesen Datensatz. Dokumentieren Sie ihre Grenzen, statt sie als unfehlbare Wahrheit darzustellen.

Trennen Sie Label-Entdeckung, Entwicklung, Schwellenwertabstimmung und Abschlusstest. Halten Sie zusammenhängende Versuche, doppelte Aufgaben und Ereignisse desselben Laufs im selben Teilbestand. Wenn die Übertragbarkeit eines Releases wichtig ist, reservieren Sie einen späteren Zeitraum oder eine von der Entwicklung unberührte Aufgabenfamilie. Die Aufteilung sollte die spätere Entscheidung abbilden und nicht nur die Tabellenbearbeitung vereinfachen.

Nehmen Sie für die Beschaffung gewährte, verweigerte und abgelaufene Freigaben, eine zulässige Ausnahme, einen Schreibvorgang mit Zeitüberschreitung und bestätigtem Zustand sowie einen Schreibvorgang mit ungeklärtem Zustand auf. Ergänzen Sie eine doppelte Anfrage, deren Idempotenzschlüssel eine zweite Änderung verhindert. Diese Fälle prüfen, ob die Definitionen oberflächlich ähnliche Ereignisse mit unterschiedlichen betrieblichen Bedeutungen unterscheiden.

Verbergen Sie Referenzdiagnosen und erwartete Labels vor den Eingaben des Klassifikators. Dokumentieren Sie die Beispielauswahl und Fälle ohne geklärte Referenz. Ändert das Team nach Sichtung der Abschlusstestfehler eine Label-Definition, ist dieser Satz zu Entwicklungsmaterial geworden. Reservieren Sie neue Evaluationsbelege, bevor Sie behaupten, das überarbeitete System lasse sich auf neue Fälle übertragen.

Berichten Sie Präzision, Recall und Kalibrierung getrennt

Messen Sie jedes wichtige Label einschließlich seiner Fallzahl und seines Prüfaufwands. Präzision fragt, wie viele vorgeschlagene positive Fälle korrekt sind. Recall fragt, wie viele positive Referenzfälle gefunden wurden. Bei einem ausdrücklich fiktiven Ergebnis mit 80 richtig positiven, 20 falsch positiven und 40 falsch negativen Fällen beträgt die Präzision 80% und der Recall ungefähr 66,7%. Das sind Rechenbeispiele, keine gemessenen Klassifikatorergebnisse. Wenden Sie diese Prüfungen auf Jev-Entscheidungen und LLM-generierte Labels an.

Geben Sie neben diesen Quoten die Verwechslungszahlen, den Datensatzzeitraum und die Fallzahl je Label an. Eine seltene Freigabeumgehung kann in der Gesamtgenauigkeit verschwinden, wenn die meisten Läufe akzeptabel sind. Auch die Bewertung mehrerer Labels benötigt eine erklärte Zähleinheit. Gibt es keine relevanten positiven Fälle oder Vorhersagen, weisen Sie Werte gegebenenfalls als undefiniert aus und erläutern die verfügbaren Belege, statt einen perfekten Wert zu erfinden.

Kalibrierung ist eine gesonderte Eigenschaft. Sie vergleicht vorhergesagte Wahrscheinlichkeiten mit beobachteten Label-Häufigkeiten. Ein vom Modell formulierter Konfidenzwert ist nicht automatisch eine Wahrscheinlichkeit. Passen Sie die Kalibrierung anhand geeigneter separater Daten an oder prüfen Sie sie dort. Stimmen Sie Aktionsschwellen unabhängig vom unberührten Abschlusstest ab. Die scikit-learn-Dokumentation unterscheidet Wahrscheinlichkeitsschätzung, Kalibrierung und Schwellenwertwahl.

Wählen Sie Schwellenwerte entsprechend der Aktion. Eine Untersuchungswarteschlange kann mehr Fehlalarme akzeptieren, um zusätzliche Fälle zu finden. Eine folgenreiche Betriebsentscheidung verlangt dagegen strengere Belege und Prüfung. Zeigen Sie für jeden Schwellenwert übersehene Fälle und nötige Prüfkapazität. Messen Sie erneut, wenn sich Modell, Raster, Richtlinie, Vorverarbeitung oder Arbeitsumfang ändern. Die frühere Messung beschreibt ihre dokumentierte Konfiguration.

Quellen: Precision, recall, F-score and support | scikit-learn (externe Website)Probability calibration | scikit-learn (externe Website)Tuning the decision threshold for class prediction | scikit-learn (externe Website)

Sichern Sie Abdeckung und machen Sie Ungewissheit sichtbar

Trennen Sie Stichproben zur Aufbewahrung von Untersuchungsstichproben und Populationsmessung. OpenTelemetry beschreibt Head-Sampling als frühe Entscheidung und Tail-Sampling als Entscheidung anhand späterer Trace-Belege. Die Tail-Sampler-Implementierung hat Grenzen bei Routing, Speicher und spät eintreffenden Spans. Eine konfigurierte Fehlerregel belegt nicht, dass jeder fehlerhafte Lauf erhalten wurde, insbesondere wenn vorgelagerte Stufen bereits Belege verworfen haben.

Erhalten Sie nach Möglichkeit eine probabilistische Basisstichprobe neben gezielten Gruppen für seltene Ereignisse, neue Versionen, langsame Läufe und unvollständige Erfassung. Halten Sie den Auswahlgrund und die effektive Einschlusswahrscheinlichkeit fest, sofern diese belastbar ist. Die OpenTelemetry-Anleitung definiert angepasste Zählwerte unter angegebenen Annahmen. Gezielte Auswahlen ohne bekannte Wahrscheinlichkeiten erhalten nicht allein deshalb gültige Gewichte, weil sie zur Fehlersuche nützlich sind.

Eine gezielt mit Freigabefehlern angereicherte Sammlung eignet sich zur Untersuchung dieser Fehler. Ihr roher Label-Anteil ist nicht die Produktionsfehlerquote. Populationsschätzungen benötigen den richtigen Nenner, gültige Auswahlgewichte, Duplikatbehandlung und die Berücksichtigung von Klassifikationsfehlern. Benennen Sie die Zielpopulation und die Unsicherheit der Schätzung, statt ohne vertretbares Studiendesign eine präzise Zahl zu präsentieren.

Halten Sie unknown und evidence_missing im Bericht sichtbar. Erfassen Sie ihre Warteschlangen, Wartezeiten und Auflösungen getrennt von bestätigten Fehlern und akzeptierten Ergebnissen. Zählen Sie Entscheidungsenthaltung nicht stillschweigend als Erfolg. Bei mehreren Labels können die Labelzahlen die Laufzahlen überschreiten. Zeigen Sie deshalb beides. Mehr ungeklärte Fälle können einen neuen Workflow, eine schwache Definition oder geänderte Erfassung anzeigen. Prüfen Sie Beispiele vor der Wahl der Abhilfe.

Quellen: Sampling | OpenTelemetry (externe Website)Tail Sampling Processor | OpenTelemetry Collector Contrib (externe Website)TraceState: Probability Sampling | OpenTelemetry (externe Website)

Berechnen Sie Tokenkosten und den begleitenden Aufwand

Schätzen Sie Kosten anhand des tatsächlichen Analyseplans einschließlich Auswahl und wiederholter Durchläufe. N bezeichnet relevante gespeicherte Traces, s den Auswahlanteil und k die Durchläufe pro ausgewähltem Trace. Multiplizieren Sie N × s × k mit den durchschnittlichen Ein- und Ausgabetokens je Durchlauf. Bepreisen Sie überschneidungsfreie Abrechnungskategorien in derselben Währung und für denselben Analysezeitraum.

Ein vollständig fiktives Beispiel: 100.000 Traces × 0,25 Auswahlanteil × 2 Durchläufe ergeben 50.000 Durchläufe. Bei jeweils 1.500 Eingabe- und 100 Ausgabetokens sind das 75 Millionen Eingabetokens und 5 Millionen Ausgabetokens. Angenommen werden 1 Kosteneinheit je Million Eingabetokens und 4 je Million Ausgabetokens. Die Klassifikation kostet dann 75 × 1 + 5 × 4 = 95 Einheiten.

Mengen und Preise sind Annahmen, keine Jev-Preise, Anbietertarife, Bibha-Ergebnisse oder Angebote. Das Beispiel berücksichtigt Wiederholungsversuche, Caching, Anfragerundung und unterschiedliche Trace-Längen erst, wenn diese Terme ergänzt werden. Google veröffentlicht getrennte Abrechnungskategorien für seine Modelle und Modi. Nutzen Sie für Ihre Schätzung den tatsächlichen Anbietervertrag. Addieren Sie Zähler für gecachte Eingaben oder Detailwerte für Denktokens nicht erneut, wenn diese schon in den abgerechneten Gesamtwerten enthalten sind.

Ergänzen Sie explorative Arbeit, Datenaufbereitung, Speicherung, Scans, deterministische Berechnungen, Orchestrierung und menschliche Prüfung getrennt. Prüfen Sie die Empfindlichkeit gegenüber längeren Belegen, mehr Durchläufen und höherem Auswahlanteil. Fragen Sie anschließend, ob das reduzierte Budget wichtige Fehler und unklare Fälle weiterhin abdeckt. Ein günstiger Klassifikator, der Prüfende überlastet oder entscheidende Belege auslässt, kann den gesamten Betriebsprozess verteuern.

C_classification = N * s * k * ((t_in / 1000000) * p_in + (t_out / 1000000) * p_out)
C_total = C_classification + C_discovery + C_data_and_storage + C_deterministic_compute + C_orchestration + C_human_review

Quellen: Gemini Developer API pricing | Google AI for Developers (externe Website)

Behandeln Sie Trace-Inhalte als nicht vertrauenswürdige Eingaben

Schützen Sie das Analysesystem ebenso sorgfältig wie den geprüften Agenten. Trace-Inhalte können Kundentext, abgerufene Dokumente und Werkzeugantworten enthalten, die eine angreifende Person beeinflusst. AgentDojo untersucht Prompt-Injection-Versuche über nicht vertrauenswürdige Werkzeuginhalte. Das begründet separate Tests der Vertrauensgrenze des Bewerters neben normalen Aufgabenqualitätstests. Es belegt keine unangreifbare Abwehr.

Geben Sie dem Bewerter für die vorgeschlagene Beschaffungsprüfung nur Lesezugriff auf die zulässige Belegansicht und keine Befugnis zur Bestelländerung. Behandeln Sie eingebettete Aufforderungen, Richtlinien zu ignorieren oder Daten offenzulegen, als zu analysierenden Inhalt. Trennen Sie Bewertungsanweisungen, Richtlinien und Quellbelege klar. Validieren Sie die Ausgabe gegen zulässige Labels und prüfen Sie, ob zitierte Ereignisse zum autorisierten Lauf gehören.

Minimieren Sie die Inhaltserfassung und vereinbaren Sie Zugriff, Verarbeitungsort, Aufbewahrung und Löschung mit den Systemverantwortlichen. Schwärzen Sie Geheimnisse und personenbezogene Details erforderlichenfalls vor dem Export. Kennzeichnen Sie die Schwärzung in der Belegansicht. W3C Trace Context verbietet personenbezogene oder sensible Informationen in Korrelationsheadern. Trace-IDs sollen Aufzeichnungen verbinden. Sie dürfen nicht als Berechtigung für deren Abruf dienen.

Testen Sie erfundene Ereignisverweise, manipulierte abgerufene Texte, organisationsfremde IDs und Versuche, Bewertungswerkzeuge auszulösen. Beziehen Sie unvollständige und geschwärzte Traces ein. Dokumentieren Sie Nutzen und Grenzverletzungen unabhängig, damit eine scheinbar hilfreiche Diagnose keinen Zugriffsverstoß verdeckt. Halten Sie unnötige Quellinhalte aus Protokollen heraus und ermöglichen Sie autorisierten Prüfenden einen kontrollierten Zugriff auf die zugrunde liegenden Belege.

Quellen: AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents (externe Website)Trace Context | W3C Recommendation (externe Website)

Überführen Sie einen geprüften Befund in ein kontrolliertes Release

Nutzen Sie Trace-Befunde zur Begründung einer verantworteten Änderung und einer wiederholbaren Abnahmeprüfung. Bei PO-DEMO-042 muss zunächst geklärt werden, wo die Freigabeanforderung durchgesetzt werden soll. Testen Sie anschließend die kleinste relevante Änderung. Ein vorgeschlagenes Label autorisiert keine Produktionsänderung. Die Workflow-Verantwortlichen und die Freigabeinstanz bleiben für die Entscheidung zuständig.

Bewerten Sie die vollständige Aufgabe einschließlich Endzustand. tau-bench zeigt die Prüfung eines Datenbankzustands nach einer Interaktion gegen ein annotiertes Ziel sowie die Bewertung wiederholten Erfolgs. Übertragen Sie diese Idee sorgfältig auf Ihre Abnahmekriterien: Eine verweigerte Freigabe soll den Lieferanten unverändert lassen, eine gewährte Änderung den vorgesehenen Zustand erreichen und ein Wiederholungsversuch keine doppelte Zustandsänderung erzeugen.

Vergleichen Sie Ausgangssystem und Kandidaten auf einem festen Satz, einem zurückgehaltenen Satz und den erforderlichen adversariellen Fällen. Halten Sie Aufgabenmix, Richtlinie, Taxonomie und Bewerterversionen dort konstant, wo der Vergleich dies verlangt. Berichten Sie Qualität, Latenz, Ressourcenverbrauch und ungeklärte Fälle gemeinsam. Ändert sich das Messverfahren, trennen Sie diese Änderung von der Systemverbesserung, die Sie nachweisen möchten.

Benennen Sie vor dem Release die freigebende Person, den Einführungsumfang, die Alarmzuständigkeit und den Rücksetzungsauslöser. Prüfen Sie die Wiederherstellung bei einer teilweisen Einführung oder ausgefallenen Abhängigkeit. Untersuchen Sie danach neue Läufe, die Basisstichprobe und ungeklärte Warteschlangen unter denselben erklärten Kriterien. Dokumentieren Sie Änderungen, ihre Belege und verbleibende Ungewissheit. Ein kontrolliertes Release schließt einen Prüfzyklus und erhält zugleich die Möglichkeit, das nächste Problem zu erkennen.

• Ein praktischer Release-Datensatz. Dokumentieren Sie Untersuchungszeitraum und Versionen, freigegebenen Belegzugriff, entschiedene Befunde, Änderungsverantwortung, Abnahmeergebnisse, verbleibende Grenzen, Freigabebefugnis und Rücksetzungsplan. Fügen Sie zulässige Belegverweise an, damit die nächste prüfende Person die Entscheidung beurteilen kann.

Quellen: tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (externe Website)

Verbinden Sie die Belege mit Ihrem betriebenen Workflow

Bibha unterstützt Teams dabei, Aufgaben-Traces und Betriebskennzahlen mit Evaluation, überprüftem Feedback und kontrollierten Verbesserungsreleases zu verbinden. Das Angebot für Monitoring, Evaluation und Governance umfasst vereinbarte Geschäftsergebnisse, aufgabenspezifische Tests, menschliche Prüfung, versionierte Ergebnisse sowie definierte Zugriffs- und Freigabeverantwortung. Die öffentlichen Plattformseiten erläutern diesen Umfang. Implementierungsdetails hängen vom System und der Zusammenarbeit ab.

Belegvereinbarung, Speicheroptionen, Taxonomie und Klassifikations-Pipeline dieses Leitfadens sind fachliche Empfehlungen. Prüfen Sie diese anhand Ihres Workflows, Ihrer Belegberechtigungen und Betriebsgrenzen, bevor daraus ein Entwurf wird. Für Bibha werden hier weder Durchsatzwerte, Klassifikatorergebnisse oder Einsparungen noch automatische Lernresultate im Produktionsbetrieb behauptet. Monitoring-Belege unterstützen überprüfte Änderungen durch Menschen. Sie bedeuten nicht, dass jede Interaktion das laufende Modell verändert.

Erstellen Sie eine Workflow-Beschreibung mit der zu verbessernden Entscheidung, den beteiligten Systemen, dem maßgeblichen Ergebnis und der Freigabeverantwortung. Ergänzen Sie zulässig aufzubewahrende Belege, Prüfvolumen und Betriebsbudget. Diese Angaben ermöglichen eine konkrete Diskussion darüber, wo Plattformkonfiguration, Integrationsarbeit und fortlaufende Prüfung ineinandergreifen.

Wenn Sie einen Agentenworkflow planen, bringen Sie diese Beschreibung in ein Gespräch mit Bibha ein. Beginnen Sie mit einer folgenreichen Frage, etwa ob eine Änderung ohne aktuelle Freigabe möglich ist, und vereinbaren Sie die Belegprüfung. Ein nützliches erstes Ergebnis ist ein abgegrenzter Prüf- und Release-Plan mit benannten Zuständigkeiten und Abnahmekriterien.

Fragen und Antworten

Quellen

1. Billion-Token Scale Trace Analysis: Jev vs LLMs | Applied Compute https://www.appliedcompute.com/platform/billion-token-scale-trace-analysis (externe Website)
2. Traces | OpenTelemetry https://opentelemetry.io/docs/concepts/signals/traces/ (externe Website)
3. Trace Context | W3C Recommendation https://www.w3.org/TR/trace-context/ (externe Website)
4. Semantic conventions for generative AI systems | OpenTelemetry https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/README.md (externe Website)
5. Semantic conventions for generative client AI spans | OpenTelemetry https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md (externe Website)
6. Sampling | OpenTelemetry https://opentelemetry.io/docs/concepts/sampling/ (externe Website)
7. Tail Sampling Processor | OpenTelemetry Collector Contrib https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md (externe Website)
8. TraceState: Probability Sampling | OpenTelemetry https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/ (externe Website)
9. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena https://arxiv.org/abs/2306.05685 (externe Website)
10. Precision, recall, F-score and support | scikit-learn https://scikit-learn.org/stable/modules/generated/sklearn.metrics.precision_recall_fscore_support.html (externe Website)
11. Probability calibration | scikit-learn https://scikit-learn.org/stable/modules/calibration.html (externe Website)
12. Tuning the decision threshold for class prediction | scikit-learn https://scikit-learn.org/stable/modules/classification_threshold.html (externe Website)
13. Lost in the Middle: How Language Models Use Long Contexts https://arxiv.org/abs/2307.03172 (externe Website)
14. LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression https://arxiv.org/abs/2310.06839 (externe Website)
15. tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains https://arxiv.org/abs/2406.12045 (externe Website)
16. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents https://arxiv.org/abs/2406.13352 (externe Website)
17. Reading and Writing Parquet Files | DuckDB https://duckdb.org/docs/current/data/parquet/overview (externe Website)
18. Hive Partitioning | DuckDB https://duckdb.org/docs/current/data/partitioning/hive_partitioning (externe Website)
19. Gemini Developer API pricing | Google AI for Developers https://ai.google.dev/gemini-api/docs/pricing (externe Website)
20. TypeSafe AI: introducing System One models and Jev https://typesafe.ai/blog/introducing-system-one-models-and-jev (externe Website)
21. TypeSafe AI: Jev models, versions and limits https://docs.typesafe.ai/models (externe Website)
22. TypeSafe AI: Choice, Score and Noul questions https://docs.typesafe.ai/primitives (externe Website)
23. TypeSafe AI: confidence and probability distributions https://docs.typesafe.ai/confidence (externe Website)