Von Traces zu Testfällen

Vierter Artikel der Reihe über das Testen von KI-Systemen. Im ersten haben wir den Massstab gebaut, im zweiten einem Modell in die Hand gegeben, im dritten ist der Mensch geblieben. Eine Frage fehlt noch, die, von der alles ausgeht: Woher kommen die Fälle?

Der Fall, den niemand reproduzieren konnte

Eine Nutzerin meldet, dass der Assistent eine Frage zu einer internen Richtlinie schlecht beantwortet hat. Das Ticket kommt an, jemand bestätigt das Problem, der Prompt wird korrigiert. Bis hierhin ein gewöhnlicher Tag.

Drei Wochen später, im monatlichen Review, erinnert sich jemand an die Regel, die wir uns gegeben hatten: Jeder Vorfall wird ein dauerhafter Fall. Er öffnet das Ticket, um daraus eine Zeile im Golden Set zu machen — und stellt fest, dass es nicht geht.

Das Dokument, aus dem der Kontext geholt wurde, ist inzwischen aktualisiert worden; jener Absatz sagt heute nicht mehr dasselbe. Das Prompt-Template hat sich zweimal geändert. Niemand weiss, welche Modellversion an jenem Tag lief, weil der Anbieter den Alias inzwischen verschoben hat. Übrig bleiben die Frage der Nutzerin und ein Screenshot der falschen Antwort.

Das heisst: Übrig bleibt eine Anekdote. Und eine Anekdote ist kein Test, denn es gibt keine Möglichkeit, sie erneut auszuführen und zu sehen, ob es heute besser läuft.

Der Fall war nicht verloren gegangen. Er war nie in einer Form erfasst worden, die es erlaubt hätte, ihn noch einmal zu erleben.

Ein Trace ist kein Testfall

Die beiden Objekte ähneln sich genug, um zu vermuten, das eine sei das komprimierte Format des anderen. Sind sie nicht — und der Unterschied ist genau das, was den Übergang schwierig macht.

Die Zeile, auf die es ankommt, ist die erste. Ein Trace hält ein Verhalten fest; ein Testfall erklärt eine Erwartung. Dazwischen steht ein Urteil, und dieses Urteil ist genau das, was das System nicht besitzt — besässe es das, müssten Sie es nicht testen.

Das ist auch der Grund, warum «generieren Sie Ihre Evals automatisch aus den Traces» ein Versprechen ist, das man genau lesen sollte. Die Kandidaten aus den Traces zu erzeugen, geht und ist nützlich. Aber das ist der leichte Schritt — verkauft unter dem Namen des schweren.

Für das Wiederholen instrumentieren ist nicht für das Debuggen instrumentieren

Fast jedes System in Produktion hat bereits Instrumentierung. Das Problem ist, dass sie für andere Fragen geschrieben wurde.

Wer fürs Debugging instrumentiert, will wissen, wo es gebrochen ist und was es gekostet hat: Latenz pro Schritt, Tokens, Fehler, Durchsatz. Nützliches Material — und keines der Felder, die man zum Wiederholen eines Falls braucht, landet dort zufällig.

Hier die Liste, die es braucht, mit dem Grund für jedes Feld.

Der aufgelöste Prompt und das Template, getrennt. Der aufgelöste Prompt allein sagt Ihnen, was das Modell gesehen hat, aber nicht, was sich geändert hat, als sich das Verhalten änderte. Das Template allein ist das Gegenteil: Sie wissen, was Sie geschrieben haben, nicht, was angekommen ist. Es braucht beides, mit der Template-Version daneben. Das ist der Unterschied zwischen «die Antwort ist schlechter geworden» und «die Antwort ist schlechter, seit wir jenen Satz in v7 des Templates ergänzt haben».

Die Argumente des Tool Calls. Hier berühren sich die beiden Enden der Reihe. Die Assertions aus dem Artikel, aus dem die Reihe entstanden ist — prüfen, ob das Modell die richtigen Retrieval-Filter erzeugt hat, ohne die Abfrage je auszuführen — sind genau das, was ein gut instrumentierter Trace bereits enthält. Wenn Sie die Argumente erfassen, schreibt sich jener Test aus der Produktion heraus von selbst, statt von Hand aus einer Laborvorstellung. Es ist das einzelne Feld mit dem höchsten Ertrag der ganzen Liste.

Die Bezeichner und die Version der abgerufenen Chunks, nicht der Text. Den Text zu speichern wirkt wie die vorsichtige Wahl und ist die schlechteste der drei verfügbaren: Es bläht die Spans auf, holt personenbezogene Daten herein, die Sie nicht brauchen, und ist vor allem eine Kopie. Bei einer Kopie merken Sie nie, dass sich das Dokument darunter geändert hat: Der Fall läuft weiter gegen einen eingefrorenen Kontext, den es nirgends mehr gibt. Mit Bezeichner plus Version sehen Sie es sofort.

Die Modellversion und die Sampling-Parameter. Temperature, Top-p und der Seed, falls Sie einen verwenden. Ohne diese vergleicht der Abgleich mit der Baseline zwei verschiedene Dinge, und Sie wissen es nicht. Achtung bei den Aliassen der Anbieter: gpt-irgendwas-latest ist ein Feld, das seine Bedeutung unter Ihnen ändert, ohne dass eine einzige Ihrer Dateien angefasst wird.

Das Feedback-Signal, am Trace verankert. Nicht in einem separaten Ticket, nicht in einer Nebentabelle mit einem Zeitstempel, über den man dann zurückzufinden hofft. Es ist der Unterschied zwischen «wir sammeln Feedback» und «das Feedback ist nutzbar»: im zweiten Fall führt ein Daumen nach unten mit einem Klick zum Input, zum Kontext und zu den Argumenten, die ihn erzeugt haben.

Eine Asymmetrie ist dabei im Blick zu behalten, dieselbe wie bei Logs: Was Sie im Moment nicht erfassen, holen Sie später nicht zurück. Niemand hat je einen fehlenden Trace rekonstruiert. Das macht die Wahl der Felder zu einer schwereren Entscheidung, als sie aussieht, denn der Preis für einen Fehler wird Monate später fällig, wenn ein Fall gebraucht wird und nicht da ist.

Was versioniert sein muss

Ein Fall ist nur dann reproduzierbar, wenn alles, wovon er abhängt, identifiziert ist. In LLM-Systemen bewegen sich unter einem Test fünf Dinge: der Dokumentenkorpus, der Index, das Tool-Schema, das Prompt-Template, das Modell.

Bewegt sich eines davon, ohne dass Sie es wissen, läuft der Test weiter und liefert weiter eine Zahl. Er schlägt nicht fehl: Er misst etwas anderes. Das ist die schlimmste Art stillen Versagens, denn es erzeugt keinen Fehler zum Anschauen, sondern eine falsche Kennzahl mit ernstem Gesicht.

Im ersten Artikel stand eine Regel: Eine Veränderung der Zahlen muss entweder dem System oder dem Datensatz zurechenbar sein, nie beidem zugleich. Hier gehört die Regel erweitert: nie dreien zugleich. Fällt der Score und Sie haben in derselben Woche die Wissensbasis aktualisiert, dauert das Gespräch darüber, was passiert ist, Tage und endet fast immer mit einer Vermutung.

Auch der unbequeme Teil gehört gesagt: vollständiges Pinning ist oft nicht praktikabel. Sie frieren den Produktionskorpus nicht ein, um Tests laufen zu lassen, und in vielen Fällen kontrollieren Sie nicht einmal die Modellversionen, die Ihr Anbieter ausliefert. Die pragmatische Antwort ist nicht Verzicht, sondern die Version auch dann zu erfassen, wenn Sie sie nicht einfrieren können. Das gibt Ihnen keine Reproduzierbarkeit, es gibt Ihnen Zurechenbarkeit — und die sind 90% des Werts und kosten ein Feld.

Welche Traces zu Fällen werden

Hier ist eine Entscheidung zu treffen, und die Standardwahl ist die falsche.

Zufälliges Sampling ist fast immer die schlechteste Verschwendung, aus demselben Grund, der im dritten Artikel schon beim Stichproben-Review zu sehen war: Liegt die Fehlerrate bei 2%, finden Sie unter hundert zufällig gezogenen Fällen zwei — und haben menschliche Aufmerksamkeit auf achtundneunzig Fälle verwendet, die in Ordnung waren. Es braucht eine geschichtete Auswahl, gebaut auf verschiedenen Signalen, die verschiedene Fragen beantworten.

Explizites Scheitern. Daumen nach unten, Tickets, Eskalationen, menschliche Korrekturen. Die beste Quelle und die knappste: Nutzende melden einen kleinen Bruchteil dessen, was schiefgeht, und sie melden es, wenn es gravierend ist. Jedes Element dieser Kategorie verdient es, angeschaut zu werden.

Implizites Scheitern. Die Nutzerin formuliert dieselbe Frage anders, wiederholt, bricht auf halbem Weg ab. Ein verrauschtes Signal — manchmal hat sie es sich schlicht anders überlegt — aber so reichlich, wie das andere knapp ist, und fast niemand sammelt es. Eine Umformulierung wenige Sekunden nach der Antwort ist in den meisten dialogorientierten Systemen der günstigste Weg zu wissen, dass die Antwort nichts genützt hat.

Uneinigkeit. Die Fälle, in denen der automatische Judge und der Mensch zum selben Output unterschiedliche Urteile fällen. Sie zählen doppelt, weil sie nicht nur das System infrage stellen, sondern die Rubrik. Der dritte Artikel schilderte ein Projekt, in dem zwei unabhängige Prüfende in 68% der Fälle übereinstimmten, und die Schlussfolgerung war, dass nicht das Modell das Problem war, sondern die Definition. Diese Fälle sind der Weg, solche Situationen zu finden, bevor daraus ein Monat sinnloses Prompt Engineering wird.

Neuheit. Inputs, die weit von allem entfernt sind, was das Golden Set bereits enthält. Es ist das Signal, das die Lücke angeht, die der erste Artikel zugestanden hat nicht schliessen zu können — zweihundert Beispiele beschreiben nicht den Long Tail dessen, was Nutzende tatsächlich fragen. Schliessen werden Sie sie ohnehin nicht, aber Sie können immerhin bemerken, wenn eine Zone von Traffic auftaucht, für die Sie keine Messung haben.

Kosten- und Latenz-Ausreisser. Sie sind keine Qualitätsfehler und gehören von den anderen getrennt, aber sie sind echte Regressionen. Der Artikel, aus dem die Reihe entstanden ist, hatte bereits festgehalten, dass in diesen Systemen die Kosten Teil des Gesprächs über Qualität sind und nicht Teil eines anderen Gesprächs.

Die Falle

Wenn Sie nur auf Fehlern auswählen, bauen Sie ein Set, das die Bugs von gestern beschreibt.

Der Mechanismus ist heimtückisch, weil er sich verbessernde Zahlen erzeugt: Das Set enthält die Fälle, die kaputt waren, Sie reparieren sie, der Score steigt. Derweil ist der normale Traffic — der, der funktionierte und den nie jemand gemeldet hat — nirgends abgebildet, und wenn er schlechter wird, merkt es niemand, bis die Nutzenden es sagen.

Es braucht eine feste Quote gewöhnlichen Traffics, der besteht. Es ist dieselbe Logik wie beim Holdout des ersten Artikels, angewandt auf die Zusammensetzung des Sets statt auf seine Verwendung: eine strukturelle Verteidigung gegen eine Drift, die niemand mit Absicht begeht.

Promotion ist ein menschlicher Akt

Es gibt eine Abkürzung, die irgendwann allen einfällt: den Produktions-Output nehmen und zum erwarteten Output befördern. Das ist der schnellste Weg, ein Golden Set zu füllen, und es kostet fünf Minuten für tausend Fälle.

Es ist auch der Weg, das aktuelle Verhalten einzufrieren und es Wahrheit zu nennen. Der erste Artikel hat das Vokabular dafür schon: Was Sie bekommen, ist ein Silver Dataset mit dem Etikett golden, und die Gefahr besteht darin, «das Modell ist mit sich selbst konsistent» mit «das Modell hat recht» zu verwechseln. Von da an liest sich jede Regression gegenüber dem heutigen Verhalten als Fehler, Korrekturen eingeschlossen.

Die Arbeitsteilung sieht so aus. Der Trace liefert Input, Kontext, den tatsächlichen Output und die Metadaten: den ganzen umfangreichen, langweiligen Teil, gratis. Ein Mensch ergänzt drei Dinge, die im Trace nirgends stehen — die Akzeptanzkriterien, die Kategorie und das Urteil, dass dieser Fall es wert ist, für immer behalten zu werden.

Das sind zwei bis drei Minuten pro Fall. Genau deshalb bleibt das Golden Set klein, und das ist gut so: Ein Set aus zweihundert Fällen, über die jemand einzeln nachgedacht hat, ist mehr wert als eines aus zehntausend, das ein Skript erzeugt hat.

Bemerkenswert ist, dass dies eine der Human-in-the-Loop-Tätigkeiten in der Bewertungsphase ist, die der dritte Artikel beschreibt — und dass es deren Probleme erbt: Schreiben zwei Personen unterschiedliche Kriterien zum selben Fall, wandert die Uneinigkeit ins Golden Set und von dort in jede Messung, die Sie darauf bauen. Das Kappa zwischen denen, die Fälle befördern, ist eine unromantische und sehr aufschlussreiche Kennzahl.

Womit man das heute macht

Die praktische Frage ist, ob man diesen Ablauf kauft oder schreibt. Die Antwort: Man kauft die langweilige Hälfte und schreibt die, auf die es ankommt — und es sind genau die zwei Hälften, die dieser Text bisher getrennt hat.

Der Schritt vom Trace zum Fall ist bereits ein Knopf. Bei Langfuse heisst er + Add to dataset und steht auf jeder Observation eines Produktions-Trace zur Verfügung; es gibt ihn auch als Massenoperation, indem man Zeilen aus der Observation-Tabelle auswählt und die Felder zuordnet. Das Element, das dabei entsteht, behält die source_trace_id — die Herkunft, die Regel acht verlangt, schreiben Sie also nicht von Hand: Sie ist ein Feld des Produkts. Bei LangSmith heisst der Knopf Add to Dataset und geht von einer gefilterten Auswahl von Runs aus. Es sind dieselben Werkzeuge, die Ihnen weiter unten unter den OTLP-Exportern begegnen: Der Trace, den Sie einmal schreiben, dient sowohl dem Hinschauen als auch dem Befördern.

Auch die menschliche Prüfung hat einen Ort, an dem sie stattfindet. Die Annotation Queues von Langfuse sind die Warteschlange aus dem vorigen Absatz, zum Produkt geworden: Man legt sie an, indem man die Bewertungsdimensionen wählt, Traces gelangen einzeln oder als Menge hinein, und wer prüft, sieht eine Aufgabe nach der anderen mit Scores und Kommentaren, per Tastatur bedienbar. Das ist kein kosmetisches Detail. Zwei Minuten pro Fall mal zwanzig Fälle im Monat sind der Unterschied zwischen einer Praxis, die überlebt, und einer, die in der ersten vollen Woche zusammenbricht.

Was keines dieser Produkte entscheidet, ist das Urteil. Die Akzeptanzkriterien, die Kategorie und ob dieser Fall es wert ist, für immer behalten zu werden, stehen in keinem Feld des Trace, und es gibt keinen Knopf, der sie erzeugt. Die oben beschriebene Arbeitsteilung ändert sich nicht dadurch, dass Sie ein Werkzeug gekauft haben: Es ändert sich nur, dass der umfangreiche Teil Sie keine Zeit mehr kostet.

Und es gibt eine Abkürzung, die man Ihnen inzwischen selbst anbietet. LangSmith gibt an, die eigene Engine könne automatisch Ground-Truth-Beispiele aus Produktions-Traces erzeugen. Es lohnt sich, den Absatz über die Promotion mit diesem Satz vor Augen noch einmal zu lesen: Die Kandidaten aus den Traces zu erzeugen ist nützlich und ist der leichte Schritt; den Produktions-Output zum erwarteten Output zu befördern ist der Weg, das aktuelle Verhalten einzufrieren und es Wahrheit zu nennen. Der Knopf unterscheidet die beiden nicht. Sie müssen es tun, und in der Unterscheidung liegt der ganze Wert.

Wenn Sie kein Produkt wollen, brauchen Sie keines. Die fünf Felder dieses Artikels lassen sich mit jeder Tracing-Bibliothek erfassen, die geschichtete Auswahl ist eine Abfrage auf Ihrem Store, und die Promotion ist eine Textdatei in Git mit einem Review darüber. Das ist der Weg, den ich allen mit einem einzigen System empfehle: Die Plattform kaufen Sie, wenn Sie drei Systeme haben und keine Lust, davon drei Fassungen zu pflegen.

Der Ertrag: messen, wie weit das Set von der Realität abgekommen ist

Bis hierhin ging es darum, wie man das Golden Set speist. Der Teil, der diese Arbeit zu mehr als einer Bequemlichkeit macht, ist ein anderer, und er betrifft die Pflege.

Im ersten Artikel wurde das Pflegeproblem eingeräumt und die Lösung hiess Disziplin: ein fester Anteil jedes Monatsreviews dafür, das Set wieder mit dem echten Traffic in Deckung zu bringen. Im selben Artikel stand wenige Zeilen später auch der ehrliche Satz: Die Pflege ist das Erste, was fällt, wenn ein Termin drückt.

Mit der Kategorienverteilung des Traffics auf der einen Seite und der des Golden Set auf der anderen wird aus dieser Disziplin eine Sache von zwei Zahlen.

Die Abdeckungslücke. Kategorien, die im Traffic Gewicht haben und im Set unterrepräsentiert sind. Es ist der Alarm, der ohne diese Messung in Gestalt unzufriedener Nutzender sechs Monate später eintrifft — bei ausgezeichnetem Score auf dem Dashboard, weil das Set etwas gut gemessen hat, das niemand mehr gefragt hat.

Die toten Fälle. Das Gegenteil: Fälle im Set, denen nichts mehr entspricht, was jemand fragt. Der erste Artikel hatte eine Regel Nummer sieben, «Datieren und ausdünnen», die eine Intuition war: Wenn ein Fall seit zwei Jahren drin ist und immer besteht, misst er vielleicht nichts mehr. Mit der Traffic-Verteilung hört das auf, eine Intuition zu sein, und wird zu einer Entscheidung, die man in einer Sitzung vertreten kann.

Der Unterschied zwischen den beiden Fassungen ist nicht technisch, er ist organisatorisch. Eine Kennzahl überlebt einen Termin; guter Wille nicht. Es ist derselbe Grund, aus dem im ersten Artikel das CI-Gate erst überlebte, als es aufhörte, eine hinzunehmende Blockade zu sein, und zu etwas wurde, mit dem man diskutieren konnte.

Datenschutz, konkret

Im ersten Artikel war die DSGVO eine Zeile: Beispiele gehören anonymisiert, bevor sie in einem Repository landen, das das ganze Team liest. Wenn die Quelle der echte Traffic wird, hört die Frage auf, eine Zeile zu sein.

Der Inhalt von Prompts und Completions ist in dem Moment personenbezogenes Datum, in dem die Nutzerin etwas hineinschreibt, und das ist keine Schulbuchannahme: Es ist der Normalfall. Menschen fügen E-Mails ein, Vorgangsnummern, Kundennamen, und in medizinischen oder juristischen Kontexten weit Heikleres. In dem Moment, in dem dieser Inhalt in eine Span gelangt, ist er im Observability-System — und das hat typischerweise eine deutlich breitere Zugriffsfläche als die Produktionsdatenbank.

Vier praktische Konsequenzen.

Die Erfassung von Inhalten gehört als Opt-in behandelt, nicht als Standard. Das ist auch die Entscheidung, die OpenTelemetry getroffen hat: Standardmässig erfassen die GenAI-Konventionen weder Prompt-Inhalte noch Tool-Argumente, gerade weil diese sensible Daten enthalten können, und es braucht ein explizites Flag, um sie einzuschalten.

Die Redaktion gehört in den Collector, nicht in die Anwendung. Machen Sie es in der Anwendung, muss jeder Dienst daran denken, und früher oder später vergisst es einer — meist der schnell geschriebene. Im Collector ist es eine einzige, prüfbare Stelle, die für alles gilt, was durchläuft.

Die Retention der Traces und die des Golden Set sind zwei verschiedene Politiken. Erstere laufen nach Tagen oder Wochen ab, Letzteres ist append-only und lebt Jahre. Der Übergang vom einen zum anderen ist der Punkt, an dem die Anonymisierung bereits geschehen sein muss, denn danach rettet Sie kein Ablaufdatum mehr.

Das Golden Set bleibt privat. Im ersten Artikel ging es um die Kontamination von Benchmarks: Ein öffentliches Set ist ein verbranntes Set. Wenn die Fälle aus dem echten Traffic stammen, kommt dieser Grund zu dem des Datenschutzes hinzu, und beide zusammen lassen nicht viel Spielraum.

Was OpenTelemetry gibt und was nicht

Es lohnt sich, hier genau zu sein, denn es ist ein Feld, in dem das Marketing der Substanz vorausläuft.

Was es gibt. Ein Trace- und Span-Modell, das gut zu Agentengraphen passt: eine Span pro Knoten, die Eltern-Kind-Beziehung, die den Weg rekonstruiert, der Kontext, der sich über die Aufrufe fortpflanzt. Ein neutrales Exportformat, was bedeutet, dass der Ort, an dem Sie Ihre Traces anschauen, eine umkehrbare Entscheidung ist. Und die Tatsache, dass die spezialisierten Werkzeuge dieses Felds — Langfuse, LangSmith und die anderen — OTLP-Exporter sind: Sie können sie als Implementierung nutzen, ohne ihr Begriffsmodell und ihr Vokabular zu übernehmen.

Was es nicht gibt. Die Entscheidung darüber, was korrekt ist. Keine semantische Konvention wird Ihnen je sagen, ob jene Antwort gut war. Alles unterhalb des Trace — die Auswahl, die Kriterien, das Urteil — bleibt Ihre Arbeit, und es ist die Arbeit, auf die es ankommt.

Und der Teil, den man wissen sollte, bevor man sich darauf stützt. Die semantischen Konventionen für GenAI sind weiterhin im Status Development: Mitte 2026 ist keine GenAI-spezifische Span, Metrik oder Attribut als stabil markiert. 2026 wurden sie in ein eigenes Repository verschoben, das derzeit weder Releases noch Tags hat — es gibt also keine Version, auf die man sich festlegen könnte. Und Umbenennungen hat es gegeben, keine kleinen: 1.37.0 hat die Ereignisse pro Nachricht durch die Attribute gen_ai.input.messages, gen_ai.output.messages und gen_ai.system_instructions ersetzt und gen_ai.system in gen_ai.provider.name umbenannt; 1.27.0 hatte bereits die Token-Benennung geändert. Praktisch heisst das, dass im selben System Frameworks koexistieren, die verschiedene Generationen der Konvention emittieren, und dass Abfragen das berücksichtigen müssen.

Das ist kein Argument dagegen, sie zu nutzen: Es ist ein Argument dagegen, die Architektur des eigenen Denkens darauf zu bauen. Die Frage dieses Artikels — was im Datensatz stehen muss, damit er wiederverwendbar ist — bleibt auch nach der nächsten Umbenennung gültig. Die Attributnamen nicht.

(Stand geprüft im September 2026. Wenn Sie das viel später lesen, prüfen Sie nach: Genau diese Art Information altert lautlos.)

Acht praktische Regeln

1. Erfassen Sie Template und aufgelösten Prompt, getrennt und versioniert. Eines von beiden allein nützt nichts.
2. Erfassen Sie die Bezeichner des Kontexts, nicht den Text. Der Text ist eine Kopie, und eine Kopie verbirgt die Änderungen darunter.
3. Verankern Sie Feedback am Trace, nicht an einem Ticket. Feedback ohne die Ausführung, die es erzeugt hat, ist eine Meinung, kein Datum.
4. Machen Sie die Redaktion im Collector. Weil die Anwendung es früher oder später vergessen wird.
5. Kein Produktions-Output wird zum erwarteten Output, ohne dass ein Mensch es entscheidet. Die Abkürzung kostet mehr, als sie spart.
6. Wählen Sie über fünf Signale aus, nicht nur über Fehler. Mit einer festen Quote bestehenden Traffics, sonst beschreiben Sie die Bugs von gestern.
7. Messen Sie die Abweichung zwischen der Verteilung des Sets und der des Traffics. Es ist die einzige Form von Pflege, die einen Termin überlebt.
8. Jeder Fall trägt seine Herkunft mit sich. Trace-Bezeichner, Datum, das Signal, das ihn ausgewählt hat. Der erste Artikel hat es schon verlangt; jetzt gibt es den Weg, es einzuhalten.

Wo sich die Reihe schliesst

Bis hierhin war diese Reihe eine Leiter. Verschieben Sie die Assertions dorthin, wo sie wenig kosten, bauen Sie den Massstab, entscheiden Sie, wer ihn hält, halten Sie einen Menschen an der Stelle, an der der Fehler teuer ist. Vier Stufen, jede langsamer und teurer als die darunter.

Mit diesem Text wird daraus ein Kreis. Die Produktion erzeugt die Traces, die Traces speisen die Fälle, die Fälle messen die Produktion. Und der Punkt, an dem sich der Kreis schliesst, ist kein Werkzeug: Es ist ein Mensch, der einen echten Fall anschaut und entscheidet, was korrekt gewesen wäre — also der dritte Artikel, der sich an dieser Stelle anders liest.

Eine Anmerkung zur Reihenfolge. Dieser Artikel hätte der erste sein müssen: Ohne Traces haben Sie keine echten Fehler, von denen aus Sie starten könnten, und «starten Sie bei den echten Fehlern» war die erste Regel des ersten Texts. Er kommt zuletzt — genau in der Reihenfolge, in der es in echten Projekten passiert: Observability kommt hinein, wenn man sie braucht, also wenn es schon spät ist.

Es bleibt der praktische Rat, und der ist weniger ehrgeizig, als das Wort Observability nahelegt: Es braucht keine Plattform. Es braucht fünf gut erfasste Felder, einen Ort, an dem sich Feedback an die Ausführung heftet, die es erzeugt hat, und jemanden, der einmal im Monat zwanzig Fälle anschaut und drei davon befördert.

Quellen

• OpenTelemetry, Inside the LLM Call: GenAI Observability with OpenTelemetry — https://opentelemetry.io/blog/2026/genai-observability/
• OpenTelemetry, eigenes Repository für die semantischen GenAI-Konventionen — https://github.com/open-telemetry/semantic-conventions-genai
• John Hodge, The state of the OpenTelemetry GenAI semantic conventions (Juli 2026) — https://john-hodge.com/blog/opentelemetry-genai-semantic-conventions/
• A Practical Guide for Evaluating LLMs and LLM-Reliant Systems — https://arxiv.org/abs/2506.13023
• Hamel Husain, Your AI Product Needs Evals — https://hamelhusain.substack.com/p/evals
• Langfuse, Datasets und Annotation Queues — https://langfuse.com/docs/datasets/overview
• LangSmith, Manage datasets — https://docs.langchain.com/langsmith/manage-datasets