In diesem Beitrag
LangSmith: Trace-Aufbewahrung, Sampling und Evaluationskosten
Header-Illustration: © 2026 Wavect.
Sampling vor der Übertragung, Evaluator-Sampling und Trace-Aufbewahrung sind in LangSmith getrennte Einstellungen. Die erste bestimmt, welche Daten die Plattform erreichen, die zweite, welche davon bewertet werden, und die dritte, wie lange die Nachweise verfügbar bleiben. Ein niedrigerer Evaluationsanteil verringert nicht die Zahl bereits eingegangener Traces.
Diese Unterscheidung hilft, wenn ein Produktionsteam klären muss, warum die Trace-Rechnung gestiegen ist, keine Bewertungen mehr erscheinen oder sich ein Vorfall nicht mehr rekonstruieren lässt. Eine sinnvolle Konfiguration braucht eine festgelegte Aufbewahrungsdauer für Nachweise, eine messbare Bewertungsgrundlage und ein Budget für jeden abrechenbaren Vorgang.
Quellen geprüft am . Dieser Leitfaden führt offizielle Dokumentation und aktuelle öffentliche Preise zusammen. Die Beispiele für Datenvolumen und Rechnungen sind illustrative Berechnungen. Wir haben weder einen kostenpflichtigen LangSmith-Account getestet noch den produktiven Datenverkehr eines Kunden gemessen.
Was zählt in LangSmith als Trace?
Ein Run ist ein einzelner Vorgang, etwa ein Modell- oder Tool-Aufruf. Ein Trace umfasst den Root-Run und seine untergeordneten Runs; ein Thread fasst mehrere Traces einer Unterhaltung zusammen. Die Observability-Grundlagen von LangSmith erklären diese Zusammenhänge. Eine Unterhaltung mit zehn Gesprächsrunden kann zehn Traces enthalten, während eine einzelne Runde viele untergeordnete Runs umfassen kann.
Die Definition der abrechenbaren Nutzung zählt einen Root-Run samt seinen untergeordneten Spans als einen Trace. Nicht jeder Modellaufruf wird als eigene Trace-Einheit berechnet. Maßgeblich ist außerdem der Zeitpunkt des Dateneingangs, der bei verzögerten Uploads vom Ausführungszeitpunkt abweichen kann. Prüfe Mengen in der Nutzungsansicht und tatsächliche Kosten auf der Rechnung.
LangSmith kann Code unabhängig von LangChain instrumentieren. Geht es um die Wahl des Ausführungsframeworks, beginne mit unserem LangChain-Deep-Agents-Review. Hier geht es darum, wie du Tracing und Evaluation betreibst.
Speichert LangSmith Traces 14, 180 oder 400 Tage?
Die aktuellen SaaS-Stufen bieten 14 Tage Basisaufbewahrung und bis zu 180 Tage erweiterte Aufbewahrung. Das Cloud-Changelog datiert die neue Obergrenze von 180 Tagen auf den 14. September 2026. Sie gilt für neue Traces; ältere bleiben davon unberührt. Diese SaaS-Änderung verändert die Aufbewahrung bei selbst gehosteten oder BYOC-Installationen nicht.
Die Voreinstellung gehört zu einem Tracing-Projekt oder zu einer Agentenumgebung, der ein solches Projekt zugrunde liegt. Eine Änderung wirkt auf künftige Traces. Auch das Abschalten der Verlängerung bei einem Evaluator ändert bereits hochgestufte Traces nicht. Lege die Aufbewahrung deshalb fest, bevor ein neuer produktiver Datenstrom startet.
Bestimme einen konkreten Zeitraum für Nachweise: Wie lange nach einem Vorfall könnte jemand die ursprünglichen Tool-Ergebnisse, Prompts und Antworten benötigen? Aggregierte Diagramme aufzubewahren ist eine andere Anforderung, als eine einzelne Ausführung zu rekonstruieren. Wähle die kürzeste für den Workflow ausreichende Dauer und dokumentiere gesonderte Ausnahmen, die eine längere Speicherung benötigen.
Welche LangSmith-Aktionen verlängern die Trace-Aufbewahrung?
Prüfe die Einstellung der jeweiligen Aktion. Ein manuell hinzugefügter Kommentar und eine automatisierte Prüfregel für einen Trace haben nicht zwingend dieselben Folgen für die Speicherung.
| Aktion | Aufbewahrungsverhalten | Was du prüfen solltest |
|---|---|---|
| Feedback oder Notizen in der Oberfläche | Die Stufe bleibt unverändert | Ein menschlicher Kommentar bewahrt den Trace nicht automatisch länger auf. |
| Feedback über API oder SDK | Verlängert bei ausdrücklicher Anforderung | extend_trace_retention=true beziehungsweise extendTraceRetention: true in TypeScript. |
| Manuelles Hinzufügen zu einer Annotation Queue | Standardmäßig keine Hochstufung | Die manuelle Prüfung muss innerhalb der verfügbaren Aufbewahrungsdauer erfolgen. |
| Online-Evaluator | Verlängerung zunächst aktiviert; bei einem Projekt mit Basisvoreinstellung abschaltbar | Advanced → Extend trace retention. |
| Automatisierung für eine Annotation Queue | Verlängerung standardmäßig aktiviert und abschaltbar | Die gespeicherte Aufbewahrungseinstellung der Aktion. |
| Dataset- oder Webhook-Automatisierung | Verlängerung standardmäßig deaktiviert und zuschaltbar | Die gespeicherte Einstellung sowie weitere passende Regeln. |
| Ausdrückliche Aufbewahrungsaktion | Stuft den passenden Trace hoch | Ein Treffer bei einem untergeordneten Run kann den gesamten Trace hochstufen. |
| Thread-Regel mit aktivierter Verlängerung | Stuft jeden Trace im passenden Thread hoch | Zähle betroffene Traces, nicht nur Unterhaltungen. |
Der Leitfaden zu Nutzung und Abrechnung dokumentiert manuelles Feedback, die ausdrückliche Verlängerung per SDK und das Verhalten bestehender Traces. Die aktionsbezogenen Einstellungen im Automatisierungsleitfaden unterscheiden die Voreinstellungen für Queues, Datasets und Webhooks. Die dort beschriebene Thread-Regel erklärt auch, warum eine ausgewählte Unterhaltung mehrere Hochstufungen auslösen kann.
Für Evaluationen ohne längere Aufbewahrung folge Manage evaluator trace retention: Verbinde den Evaluator mit einem Tracing-Projekt oder einer Umgebung mit Basisvoreinstellung, öffne Advanced und deaktiviere Extend trace retention. Das gilt für künftige Bewertungen auf Trace- und Thread-Ebene. Verwendet das Projekt standardmäßig erweiterte Aufbewahrung, ist diese Option gesperrt. Eine andere passende Regel kann denselben Trace weiterhin hochstufen.
Einige Einleitungen in der Dokumentation beschreiben automatische Hochstufungen noch pauschal. Die Tabelle oben folgt den detaillierten Aktionseinstellungen und der ausdrücklich dokumentierten Abschaltmöglichkeit für Evaluatoren. Prüfe beim Rollout die gespeicherte Konfiguration, statt die Voreinstellung einer neuen Regel als dauerhafte Richtlinie zu behandeln.
Trace-Sampling und Evaluator-Sampling: Welcher Anteil wird bewertet?
Die Trace-Sampling-Einstellung des SDK wählt vor dem Upload einen Anteil aus. Bei einer bereits mit dem LangSmith SDK oder LangChain instrumentierten Anwendung fordert diese Umgebungsvariable ein Sampling von 10 % an:
export LANGSMITH_TRACING_SAMPLING_RATE=0.10Sie konfiguriert keine direkten REST-Aufrufe und richtet allein auch keine Tracing-Instrumentierung ein. Sampling arbeitet probabilistisch. Verwende für den Abgleich die tatsächlich erfolgreich eingegangenen Traces, statt in jedem Monat exakt den eingestellten Prozentsatz zu erwarten.
Das Sampling eines Online-Evaluators greift später bei den Runs, die seinen Filter erfüllen. Der Leitfaden zur Evaluator-Konfiguration benennt diese Auswahlgrundlage ausdrücklich. Auch die Auswahl von Root-Runs ist wichtig: Schließt ein Filter mehrere untergeordnete Runs ein, können für einen Trace mehrere Evaluationen entstehen.
| Stufe | Annahme | Anzahl |
|---|---|---|
| Anwendungsausführungen | Alle Ausführungen des definierten Workflows | 1.000.000 |
| Eingegangene Traces | Tatsächlich erreichte Stichprobe von 10 % mit erfolgreichen Uploads | 100.000 |
| Geeignete Root-Runs | Die Hälfte erfüllt den Evaluator-Filter | 50.000 |
| Bewertete Runs | Tatsächliche Stichprobe von 10 % der geeigneten Root-Runs; alle Evaluationen erfolgreich | 5.000 |
| Gezielt länger aufbewahrte Teilmenge | 1.000 eindeutige Traces aus diesen 5.000 Bewertungen ausgewählt | 1.000 |
Der Evaluator hat 0,5 % der Anwendungsausführungen bewertet: 10 % × 50 % × 10 %. Bezogen auf die eingegangenen Traces waren es 5 %. Keine dieser Bezugsgrößen lässt sich einfach durch „10 % bewertet“ ersetzen. Die Prozentsätze beschreiben die tatsächlichen Mengen dieses Beispiels; konfigurierte Sampling-Raten beschreiben dagegen Erwartungswerte.
Eine Aufbewahrungsregel kann einen bereits übertragenen Fehlerfall länger verfügbar halten. Sie kann keine Ausführung zurückholen, die vor dem Upload verworfen wurde. Soll ein bestimmter Workflow lückenlos erfasst werden, lege diese Anforderung vor der Ausführung mit bedingtem Tracing und einem entsprechend konfigurierten Client fest. Behaupte nicht, eine zufällige Stichprobe erfasse jeden künftigen Fehler.
Wir empfehlen, Anwendungsausführungen, angenommene Traces, geeignete Root-Runs, erfolgreiche Bewertungen und fehlgeschlagene Evaluationen getrennt zu zählen. Dokumentiere bei jeder Qualitätskennzahl auch Filter und Evaluator-Version. Für die Aussagekraft eines Judges und die Gestaltung der Bewertungsrubrik nutze unseren bestehenden Leitfaden zu Kosten und ROI von LLM-Evaluationen.
Was kostet diese Aufbewahrungsstrategie in LangSmith?
Die aktuelle Preisseite für Self-Service-Tarife nennt 1 USD je LSU, 0,005 LSU je Basis-Trace und zusätzlich 0,0025 LSU je Hochstufung auf erweiterte Aufbewahrung. Das entspricht 5 USD pro 1.000 Basis-Traces plus 2,50 USD pro 1.000 Hochstufungen. Plus kostet 39 USD pro Nutzerplatz und Monat und umfasst 10.000 Basis-Traces; Developer umfasst 5.000 Basis-Traces und einen kostenlosen Nutzerplatz.
Wende diese Preise auf das Beispiel oben an. Wir nehmen einen Plus-Nutzerplatz an, ordnen seine 10.000 enthaltenen Basis-Traces dieser Anwendung zu und rechnen ohne zusätzliche Guthaben, Rabatte oder ein Freikontingent für Hochstufungen. Das enthaltene Kontingent wird nicht für jedes Projekt erneut bereitgestellt. Vergleiche die längere Aufbewahrung aller 5.000 bewerteten Traces mit der ausgewählten Teilmenge von 1.000. Bei beiden Varianten gehen weiterhin 100.000 Traces ein und entstehen 5.000 Bewertungen.
| Position | Alle bewerteten Traces verlängern | Ausgewählte Teilmenge verlängern |
|---|---|---|
| Ein Plus-Nutzerplatz | 39,00 USD | 39,00 USD |
| 90.000 abrechenbare Basiseinheiten | 90.000 × 0,005 USD = 450,00 USD | 450,00 USD |
| Abrechenbare Hochstufungen | 5.000 × 0,0025 USD = 12,50 USD | 1.000 × 0,0025 USD = 2,50 USD |
| Zwischensumme für Anwendungstraces und Nutzerplatz | 501,50 USD | 491,50 USD |
Die Differenz beträgt 10 USD, keine Senkung der gesamten Rechnung um 80 %. Die gezielte Aufbewahrung reduziert hier die Hochstufungen um 80 %, während die Basisgebühr für eingegangene Traces gleich bleibt. Betrieblich kann wichtiger sein, dass nur jene Nachweise länger gespeichert werden, die das Team gezielt benötigt.
base_units = max(100_000 - 10_000, 0)
seat_cost = 39
for upgrade_units in (5_000, 1_000):
subtotal = seat_cost + base_units * 0.005 + upgrade_units * 0.0025
print(f"USD {subtotal:.2f}")
# USD 501.50
# USD 491.50Diese Berechnung setzt voraus, dass Hochstufungen im selben Abrechnungsmonat erfolgen und weder rückwirkende Verarbeitung noch die Hochstufung zusätzlicher Traces durch Thread-Regeln oder weitere Aufbewahrungsregeln hinzukommen. Der ursprüngliche Eingang und eine spätere Hochstufung können in unterschiedliche Abrechnungszeiträume fallen. Zähle die Vereinigungsmenge hochgestufter Trace-IDs, statt sich überschneidende Regeltreffer zu addieren.
Bei der Tarifumstellung im Oktober gelten Ausnahmen für Accounts mit Verträgen, Guthaben oder individuellen Preisanpassungen. Enterprise- und selbst gehostete Tarife können einen einheitlichen Trace-Preis ohne diesen Aufschlag verwenden. Prüfe vor der Übernahme des Beispiels die Bedingungen deines Accounts. Die Beträge sind Zwischensummen für Anwendungstraces, keine vollständige Plattformrechnung. Zusätzliche Traces aus Evaluator-Ausführungen oder anderen Workloads, Modellaufrufe, LLM-Judge-Nutzung, weitere Evaluator-Dienste, Deployment, Engine, Steuern und Arbeitszeit sind ausgeschlossen. Für den gesamten Geschäftsprozess miss die Kosten pro akzeptiertem Agentenergebnis.
Warum stoppen LangSmith-Evaluationen, während die Anwendung weiterläuft?
Ein Mengenlimit für Tracing und eine Ausgabengrenze für Evaluatoren regeln unterschiedliche Vorgänge. Für eine fehlende Bewertung braucht es eine Erklärung; sie ist keine bestandene Evaluation.
| Einstellung | Was sie begrenzt | Zu erwartende Folge |
|---|---|---|
| Monatliches Limit für alle Traces | Menge eingehender Traces | Weitere Eingänge können abgelehnt werden; prüfe Upload-Fehler und 429-Antworten. |
| Monatliches Limit für erweiterte Traces | Neue Traces mit erweiterter Aufbewahrung | Aktionen, die eine neue Hochstufung erfordern, werden blockiert; Aktionen mit deaktivierter Verlängerung können weiterlaufen. |
| Wöchentliche Ausgabengrenze für Evaluatoren | LLM-Bewertungskosten einer einzelnen Evaluator-Zuordnung | Bewertungen pausieren für dieses Projekt oder Dataset; Anwendung und Trace laufen weiter. |
Ist das Limit für erweiterte Traces erreicht, können Feedback in der Oberfläche und manuelle Queue-Einträge weiterhin funktionieren, weil sie die Aufbewahrung nicht ändern. Dasselbe gilt für Evaluatoren und Regeln mit deaktivierter Verlängerung. Trace-Mengenlimits sind Näherungsgrenzen und deckeln weder jedes LangSmith-Produkt noch die Rechnung deines Modellanbieters.
Die Dokumentation zu Evaluator-Ausgaben nennt eine leicht übersehene Unterscheidung: Die Organisationsvoreinstellung wird je Zuordnung eines Evaluators zu einem Projekt oder Dataset übernommen. Eine Voreinstellung von 20 USD für drei Zuordnungen ist kein gemeinsames Organisationsbudget von 20 USD. Jede Zuordnung hat eine eigene Grenze.
Diese wöchentlichen Grenzen werden montags um 00:00 UTC zurückgesetzt. Bereits laufende Bewertungen können sie leicht überschreiten; die Durchsetzung erfordert ein unterstütztes Modell mit konfiguriertem Preis. Prüfe den Status der Zuordnung und die Evaluator-Logs, bevor du einen Filter änderst, um fehlende Bewertungen zu „reparieren“. Den hinterlegten Modellpreis zu senken, um eine Grenze zu umgehen, würde auch die Ausgabenmessung verfälschen.
Wird ein LangSmith-Dataset-Beispiel gelöscht, wenn sein Trace abläuft?
Nein. Kopierte Dataset-Beispiele haben einen eigenen Lebenszyklus. Die Hinweise zu Abrechnung und Aufbewahrung beschreiben ausdrücklich, wie Eingaben und Ausgaben in einem Dataset gespeichert werden, damit sie nach Ablauf des ursprünglichen Traces verfügbar bleiben. Eine Trace-Richtlinie von 14 Tagen ist daher keine Richtlinie von 14 Tagen für jede Kopie dieser Inhalte.
Auch die Dataset-Historie zählt. Laut LangSmith-Dokumentation zum Löschen erhält Soft Delete historische Versionen. Hard Delete entfernt Eingaben, Ausgaben und Metadaten der ausgewählten Beispiele dagegen aus allen diesen Versionen. Behandle das Löschen als eigenen Prozess mit eigener Überprüfung.
Erfasse für jedes kuratierte Beispiel Zweck, ursprüngliche Trace-ID, Dataset und Version, Verantwortliche sowie eine Prüf- oder Löschfrist. Das Speichern eines Eingabe-Ausgabe-Paars erhält nicht den vollständigen verschachtelten Trace-Baum. Bewahre die für einen Vorfall oder Regressionstest tatsächlich benötigten Nachweise auf und prüfe, was nach jeder Aufbewahrungsgrenze noch zugänglich ist.
Eine praktikable LangSmith-Konfiguration für den Produktivbetrieb
Die folgende Reihenfolge ist ein Vorschlag für den Rollout. Passe sie an die Nachweisanforderungen des Workflows an und überprüfe sie mit synthetischen Datensätzen, bevor du dich darauf verlässt.
- Umgebungen trennen und die künftige Voreinstellung festlegen. Dokumentiere, ob das Produktionsprojekt oder die Agentenumgebung mit Basisaufbewahrung oder erweiterter Aufbewahrung beginnt. Halte die Konfiguration zusammen mit dem Anwendungsrelease fest.
- Festlegen, welche Daten die Anwendung verlassen dürfen. Definiere Ausschlüsse für sensible Daten vor dem Sampling. Die Maskierung von Eingaben und Ausgaben entfernt nicht automatisch jedes Metadatenfeld. Ein Judge kann Inhalte nicht bewerten, die seine Eingabe nicht enthält. Prüfe einen repräsentativen bereinigten Trace und die zugeordneten Variablen des Evaluators.
- Übertragung und Bewertung unabhängig konfigurieren. Dokumentiere SDK-Sampling, Root-Run-Filter, Evaluator-Sampling und die Ausgabengrenze jeder Zuordnung. Führe Zähler für den gesamten Workflow außerhalb der ausgewählten Trace-Stichprobe.
- Aufbewahrung bewusst wählen. Wenn der Workflow es erlaubt, belasse Routinebewertungen in der Basisstufe und verlängere eine definierte Teilmenge für Untersuchungen. Prüfe jede überlappende Regel einschließlich Thread-Aktionen und setze eine Frist für manuelle Prüfungen.
- Erwartete Zustandsänderungen überprüfen. Schicke synthetische Erfolgsfälle, Fehlerfälle und Fälle mit sensiblen Eingaben durch die vorgesehenen Abläufe. Prüfe Dateneingang, Bewertung, Aufbewahrung und Dataset-Kopien getrennt. Gleiche Rechnungsmengen mit angenommenen Traces und eindeutigen Hochstufungen ab.
- Bei fehlenden Nachweisen alarmieren. Überwache Übertragungsfehler, Evaluator-Fehler, pausierte Zuordnungen und die Bewertungsabdeckung. Lege Verantwortliche für ablaufende Traces und das Löschen von Dataset-Beispielen fest.
Details zur Umsetzung außerhalb dieser LangSmith-Einstellungen findest du in unserem Leitfaden zur PII-Redaktion. Teams, die bereits einen bestehenden LiteLLM-Stack untersuchen, können den gesonderten Leitfaden zur Trace-Analyse mit LiteLLM Lens nutzen.
Nach einem erfolgreichen Rollout lassen sich vier konkrete Fragen beantworten: Was haben wir erfasst, was haben wir bewertet, was wird bei Bedarf noch vorhanden sein und was haben diese Entscheidungen gekostet? Wavects KI-Integrationsservice hilft dabei, diese Einstellungen mit der Anwendung und ihrem Prüfprozess zu verbinden.