🤖 machine learning

TraCeS: Learning Per-Timestep Constraint-Violation Credit from Sparse Trajectory-Level Labels

TraCeS ist eine Reinforcement-Learning-Methode, die zeitschrittweise Sicherheitsverletungskredite aus spärlichen Trajektorien-basierten Labels lernt, ohne dass eine bekannte Kostenfunktion oder ein Schwellenwert erforderlich ist, wodurch die Einhaltung von Nebenbedingungen und die Effizienz des Feedbacks in kontinuierlichen Steuerungsaufgaben verbessert werden.

Ursprüngliche Autoren: Siow Meng Low, Ze Gong, Akshat Kumar

Veröffentlicht 2026-07-01

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Siow Meng Low, Ze Gong, Akshat Kumar

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Das große Problem: Die „Black Box“-Sicherheitsregel

Stellen Sie sich vor, Sie bringen einem Roboter das Autofahren bei. In einer perfekten Welt würden Sie dem Roboter genau sagen, wie viel „Gefahr“ jede Aktion erzeugt (z. B. „Links abbiegen mit 80 km/h kostet 5 Gefahrspunkte“). Sie würden ihm auch ein hartes Limit vorgeben, wie etwa: „Du darfst insgesamt nicht mehr als 100 Gefahrspunkte erreichen.“

Doch in der realen Welt ist Sicherheit oft eine Black Box.

Sie kennen nicht die exakte Mathematik dahinter, was eine Situation gefährlich macht.
Sie kennen das exakte „Gefahrslimit“ nicht.
Sie können die Sicherheit des Roboters nicht jede einzelne Sekunde überprüfen (das wäre zu teuer und zu langsam).

Stattdessen erhalten Sie nur ein grobmaschiges Feedback am Ende einer Fahrt. Sie bekommen ein einfaches „Bestanden“ oder „Nicht bestanden“ (Pass/Fail).

Ist das Auto verunglückt? Nicht bestanden.
Ist es sicher am Ziel angekommen? Bestanden.

Das Problem ist: Wenn das Auto am Ende einer 10-minütigen Fahrt verunglückt, wissen Sie nicht, welche spezifische Sekunde den Absturz verursacht hat. War es die Kurve in Minute 2? Die Geschwindigkeit in Minute 8? Oder war es einfach nur Pech? Dies nennt man das Credit-Assignment-Problem (Problem der Zuordnung von Ursache und Wirkung).

Die Lösung: TraCeS (Das „Detektiv“-System)

Die Autoren schlagen TraCeS vor (Trajectory-based Constraint Estimation for Safety). Betrachten Sie TraCeS als einen Detektiv, der versucht herauszufinden, wo das Unheil begann, basierend auf allein dem abschließenden „Bestanden/Nicht bestanden“-Urteil.

So funktioniert es, Schritt für Schritt:

1. Das „Überlebenswahrscheinlichkeits“-Spiel

Anstatt zu versuchen, die exakten „Gefahrspunkte“ für jede Bewegung zu erraten, stellt TraCeS eine andere Frage: „Wie hoch ist die Wahrscheinlichkeit, dass dieses Auto jetzt gerade noch sicher ist?“

Zu Beginn der Fahrt liegt die Wahrscheinlichkeit, sicher zu sein, bei 100 %.
Während das Auto fährt, beobachtet TraCeS jede Bewegung.
Macht das Auto eine sichere Bewegung, bleibt die Wahrscheinlichkeit hoch.
Macht das Auto eine riskante Bewegung, sinkt die Wahrscheinlichkeit leicht.
Macht das Auto eine katastrophale Bewegung, stürzt die Wahrscheinlichkeit gegen Null.

2. Der „Domino-Effekt“ (Faktorisierung)

Das Paper nutzt einen cleveren mathematischen Trick. Es behandelt die Gesamtsicherheit einer Fahrt wie eine Kette von Dominosteinen.

Um die gesamte Fahrt zu überstehen, muss man Schritt 1 überstehen, UND Schritt 2, UND Schritt 3 ... bis zum Ende.
TraCeS bricht das große „Bestanden/Nicht bestanden“-Label in winzige „Überlebens-Scores“ für jede einzelne Sekunde herunter.
Wenn eine bestimmte Kurve dazu führte, dass die Überlebenswahrscheinlichkeit drastisch sank, gibt TraCeS dieser Kurve ein hohes „Verletzungsguthaben“ (einen Penalty/Abzug). Wenn eine Bewegung die Chancen kaum verändert hat, erhält sie ein niedriges Guthaben.

3. Aus Fehlern lernen (Die Feedback-Schleife)

TraCeS läuft in einer Schleife ab:

Fahren: Der Roboter absolviert einige Fahrten.
Bewerten: Ein Mensch oder ein Monitor gibt für die gesamte Fahrt ein „Bestanden“ oder „Nicht bestanden“ aus.
Detektieren: TraCeS analysiert die „Nicht bestanden“-Fahrten und fragt: „In welchen spezifischen Sekunden ist die Überlebenswahrscheinlichkeit am stärksten gesunken?“ Es weist diesen Momenten Strafen zu.
Lehren: Der Roboter lernt, diese spezifischen Momente in Zukunft zu vermeiden.
Wiederholen: Der Robot fährt erneut, erhält neue Bewertungen und der Detektiv wird klüger.

Warum ist das besonders?

Die meisten Sicherheitssysteme benötigen ein vorab geschriebenes Regelwerk (z. B. „Fahre niemals schneller als 20 mph“). TraCeS braucht das nicht. Es lernt die Regeln implizit, indem es einfach beobachtet, was abgelehnt wird.

Es ist effizient: Es benötigt keinen Menschen, der jede einzelne Sekunde jeder Fahrt bewertet. Ein einziges „Nicht bestanden“-Label am Ende reicht aus, damit der Detektiv den Übeltäter finden kann.
Es ist intelligent im Umgang mit Unsicherheit: Wenn der Detektiv verwirrt ist, welche Bewegung den Absturz verursacht hat, fordert er mehr Daten zu ähnlichen Fahrten an. Wenn er sich sicher ist, hört er auf zu fragen. Das spart Zeit und Geld.
Es geht mit Rauschen um: Selbst wenn der menschliche Bewerter manchmal Fehler macht (z. B. „Bestanden“ sagt, obwohl es eigentlich „Nicht bestanden“ war), ist TraCeS robust genug, um dennoch das richtige Verhalten zu lernen.

Die Ergebnisse

Die Autoren testeten dies in spielähnlichen Umgebungen (Roboter beim Gehen, Autos beim Fahren).

Null Wissen: TraCeS startete ohne jegliches Wissen über die Regeln oder die Gefahrenlimits.
Erfolg: Es lernte, in fast allen Szenarien sicher zu fahren, und nutzte dabei oft weniger gelabelte Beispiele als andere Methoden, die versuchten, die Regeln blind zu erraten.
Präzision: Als sie sich die von TraCeS gelernten „Verletzungsguthaben“ ansah, stimmten diese perfekt mit den tatsächlichen Momenten überein, in denen der Roboter kurz vor dem Crash stand. Es konnte die „schlechten Äpfel“ in der Kette der Ereignisse erfolgreich identifizieren.

Zusammenfassende Analogie

Stellen Sie sich vor, Sie sind ein Trainer, der einen Basketballspieler unterrichtet.

Der alte Weg: Sie sagen dem Spieler: „Spring nicht höher als 1 Meter und renne nicht schneller als 10 km/h.“ (Dies setzt voraus, dass man die exakten Regeln kennt).
Der TraCeS-Weg: Sie schauen dem Spieler beim Spiel zu. Am Ende sagen Sie: „Du hast verloren.“ Sie sagen ihm nicht warum. Aber TraCeS fungiert wie ein superintelligenter Assistent, der das Video analysiert, sieht, dass der Spieler in Minute 10 zu hoch gesprungen ist, und sagt: „Nächstes Mal spring nicht so hoch in Minute 10.“ Der Spieler lernt die Regel, ohne dass Sie sie jemals explizit ausgesprochen haben.

TraCeS verwandelt ein vages „Du hast versagt“ in ein spezifisches „Mach das zu dieser Zeit nicht“, wodurch Roboter in der Lage sind, Sicherheit aus spärlichem, hochgradig abstraktem Feedback zu lernen.

Technisches Resümee: TraCeS

Problemstellung

Die Gewährleistung sicheren Verhaltens in Reinforcement Learning (RL) ist eine Herausforderung, wenn Sicherheitsbeschränkungen implizit, ungemessen oder während des Trainings nicht verfügbar sind. In vielen sicherheitskritischen Domänen (z. B. Robotik, autonomes Fahren) sind hartcodierte Beschränkungen und handgestaltete Kostenfunktionen oft spröde und versagen bei der Generalisierung über kontextabhängige Szenarien hinweg. Darüber hinaus ist eine dichte Supervision pro Zeitschritt häufig nicht verfügbar; stattdessen beschränkt sich die Supervision auf grobe, spärliche binäre Labels, die angeben, ob eine gesamte Trajektorie (oder ein Präfix davon) innerhalb eines unbekannten Sicherheitsschwellenwerts geblieben ist.

Die Kernschwierigkeit liegt im Credit-Assignment-Problem: Ein Label auf Trajektorienebene (z. B. „abgelehnt“) zeigt an, dass eine Verletzung aufgetreten ist, spezifiziert jedoch nicht, wann oder welche spezifischen Verhaltensweisen sie verursacht haben. Standardmäßige Constrained Markov Decision Process (CMDP)-Methoden setzen den Zugriff auf eine bekannte Kostenfunktion pro Zeitschritt und einen Schwellenwert voraus, was hier nicht der Fall ist. Die Arbeit befasst sich mit dem Szenario, in dem der Agent eine sichere Policy aus spärlichen, trajektorienbasierten Akzeptanz-/Ablehnungs-Labels lernen muss, ohne Kenntnis über die zugrunde liegende Kostenfunktion $C$ oder den Beschränkungsschwellenwert $b$ .

Methodik: TraCeS

Die Autoren schlagen TraCeS (Trajectory-based Constraint Estimation for Safety) vor, ein Framework, das pro Zeitschritt lernbare Verletzungskredite aus spärlichen Trajektorien-Labels ableitet. Die Methode operiert durch eine iterative Schleife, die drei Hauptkomponenten umfasst:

1. Sequentieller Verletzungsschätzer (Sequential Violation Estimator)

TraCeS trainiert einen sequentiellen Schätzer, um spärliches binäres Feedback in dichte, pro Zeitschritt berechnete Verletungskredite zu zerlegen.

Monotone Verletkungsabstraktion: Die Methode setzt eine monotone Verletkungsstruktur voraus (Annahme 3.1): Sobald eine Trajektorie eine Beschränkung verletzt, bleibt sie danach verletzt. Dies impliziert, dass die Wahrscheinlichkeit für „noch nicht verletzt“ über die Zeit nicht zunimmt.
Faktorisierung: Der Schätzer sagt die Wahrscheinlichkeit voraus, mit der ein Trajektorien-Präfix $\tau_{0:t}$ die Beschränkung noch nicht verletzt hat, bezeichnet als $\hat{P}(\psi_{0:t}=1 | \tau_{0:t})$ . Diese Wahrscheinlichkeit wird in per-Schritt multiplikative Kredite faktorisiert:
$\hat{P}(\psi_{0:T-1}=1 | \tau_{0:T-1}) = \prod_{t=0}^{T-1} \hat{P}^\Delta_t$
Hierbei repräsentiert $\hat{P}^\Delta_t$ die Änderung der Nicht-Verletzungswahrscheinlichkeit beim Erweitern des Präfixes um einen Schritt. Ein Wert signifikant kleiner als 1 deutet auf einen Schritt hin, der einen scharfen Abfall der Sicherheitswahrscheinlichkeit induziert, was die Lokalisierung des Verletzungskredits effektiv ermöglicht.
Architektur: Der Schätzer verwendet einen gemeinsamen Encoder $f_w$ , um einen Zusammenfassungsvektor $h_t$ des Präfixes aufrechtzuerhalten, und einen Decoder $g_w$ , um Parameter für eine Log-Normalverteilung auszugeben. Der extrahierte Log-Kredit wird auf nicht-positiv beschränkt ( $\log \hat{P}^\Delta_t \le 0$ ), um sicherzustellen, dass die kumulative Wahrscheinlichkeit nicht steigt.
Training: Der Schätzer wird unter Verwendung des Binary Cross-Entropy-Loss auf den spärlichen binären Labels (akzeptiert/abgelehnt) von Trajektorien oder Präfixen trainiert, wobei das Problem als Maximum-Likelihood-Schätzung der unbekannten Labeling-Regel $\Psi(\cdot)$ behandelt wird.

2. Optimierung der beschränkten Policy (Constrained Policy Optimization)

Sobald der Schätzer die per-Schritt Kredite gelernt hat, integriert TraCeS diese in einen Standard-CMDP-Solver.

Surrogat-Kosten: Der geschätzte Log-Kredit wird in eine Surrogat-Kostenfunktion transformiert: $\tilde{C}_t = -\log \hat{P}^\Delta_t \ge 0$ .
Umformulierung der Beschränkung: Die ursprüngliche Chance-Constraint (die erfordert, dass die Wahrscheinlichkeit einer akzeptablen Trajektorie mindestens $d$ beträgt) wird approximiert. Unter Verwendung der Jensenschen Ungleichung leiten die Autoren eine handhabbare untere Schranke ab, die die multiplikative Beschränkung in eine additive Form umwandelt:
$\mathbb{E}_{\tau \sim \pi_\theta} \left[ \sum_{t} \tilde{C}_t \right] \le -\log d$
Diese Umformulierung ermöglicht die Verwendung von Standard-Algorithmen für beschränktes RL (z. B. PPO-Lagrangian) mit den gelernten Surrogat-Kosten, obwohl die wahre Kostenfunktion unbekannt ist.
Theoretische Garantie: Das Paper liefert eine Schranke für die Approximationslücke, die durch die Jensensche Ungleichung eingeführt wird, und zeigt, dass die Lücke schrumpft, wenn der Schätzer stabiler wird und die Varianz der vorhergesagten Nicht-Verletzungswahrscheinlichkeiten abnimmt.

3. Aktive Trajektorienselektion (Active Trajectory Selection)

Um die Annotationslast zu reduzieren, setzt TraCeS eine unsicherheitsbasierte Strategie ein, um zu entscheiden, welche Trajektorien gelabelt werden sollen.

Variationskoeffizient (CV): Die Methode berechnet den CV der Trajektorien-basierten Surrogat-Kosten unter dem Sampling-Rauschen des Schätzers. Trajektorien mit hohem CV (was auf eine hohe Dispersion oder Unsicherheit in der Vorhersage des Schätzers hindeutet) werden für die Labeling priorisiert. Dies konzentriert menschliche oder automatisierte Annotationsbemühungen auf Rollouts, bei denen der Schätzer am unsichersten ist, was die Dateneffizienz verbessert.

Zentrale Beiträge

Problemformulierung: Das Paper formalisiert das Problem des sicheren Policy-Learnings aus spärlichen Trajektorien-basierten Labels unter einer monotonen Verletkungsabstraktion und adressiert die Lücke, in der weder die Kostenfunktion noch der Schwellenwert bekannt sind.
Methode (TraCeS): Ein neuartiger sequentieller Schätzer, der die Trajektorien-basierte Akzeptanz in per-Zeitschritt-Verletzungskredite faktorisiert. Dies ermöglicht die Transformation von grobem binärem Feedback in ein dichtes Surrogat-Kostensignal, das mit Standard-CMDP-Solvern kompatibel ist.
Theorie und Evaluierung:
- Theoretische Analyse der Approximationslücke, die durch die untere Schranke der Jensenschen Ungleichung eingeführt wird.
- Empirische Validierung über 12 kontinuierliche Kontrollaufgaben (Safety Gymnasium, MuJoCo, Bullet Safety Gym).
- Demonstration der Robustheit in Low-Data-Regimes, unter verrauschten Labels und in Settings mit menschlichem Feedback.

Experimentelle Ergebnisse

Die Autoren evaluieren TraCeS gegen mehrere Baselines:

Oracle-Methoden: PPO-Lagrangian und CPPO-PID (setzen bekannte Kosten und Schwellenwert voraus).
Partielles Wissen: RLSF (lernt Kosten, setzt aber bekannten Schwellenwert voraus).
Zero-Knowledge-Baselines: Eine Cost-Threshold (C-T) Baseline, die versucht, sowohl Kosten als auch Schwellenwert von Grund auf zu lernen.

Wichtigste Erkenntnisse:

Einhaltung von Beschränkungen: TraCeS lernt zuverlässig Policies, die die Sicherheitsbeschränkungen (Kosten $\le$ Schwellenwert) in den meisten Aufgaben erfüllen, trotz des Null-Wissens über die Kosten oder den Schwellenwert.
Label-Effizienz: TraCEs ist wesentlich effizienter beim Labeling als die Zero-Knowledge C-T Baseline und benötigt signifikant weniger gelabelte Trajektorien, um zu sicheren Policies zu konvergieren.
Performance: TraCeS erreicht kompetitive Reward-Safety-Tradeoffs im Vergleich zu Methoden mit partiellem Wissen (RLSF) und nähert sich auf mehreren Aufgaben der Performance von Oracle-Methoden an.
Lokalisierung: Eine qualitative Analyse zeigt, dass die gelernten per-Schritt Kredite die Verletzungsereignisse präzise lokalisieren, indem sie nahe dem Zeitschritt peaken, an dem der kumulative Oracle-Kosten den Schwellenwert überschreitet, anstatt die Kosten gleichmäßig zu verteilen.
Robustheit: Die Methode bleibt effektiv unter moderatem Label-Rauschen (bis zu 10-20 %) und in Low-Data-Regimes (z. B. 1000 gelabelte Trajektorien). Sie funktioniert auch gut mit menschlichem Feedback in einer kleinteiligen Studie zu HalfCheetah.

Bedeutung und Ansprüche

Das Paper behauptet, dass TraCeS einen praktischen Weg zur Ausrichtung von RL-Agenten an impliziten und kontextabhängigen Beschränkungen bietet, wenn formale Spezifikationen nicht verfügbar sind. Durch die Transformation von grober Akzeptanz-/Ablehnungs-Supervision in per-Zeitschritt-Verletzungskredite ermöglicht TraCeS die Nutzung standardmäßiger beschränkter Optimierungsmechanismen, ohne dass handgestaltete Kostenfunktionen oder bekannte Schwellenwerte erforderlich sind.

Die Autoren betonen, dass die gelernten Kredite als kontrollrelevante Sicherheits-Surrogate dienen und nicht darauf abzielen, verborgene Ground-Truth-Kosten identifizierbar wiederherzustellen. Die Methode ist besonders signifikant für Szenarien, in denen Sicherheit durch komplexe, dynamische Faktoren definiert ist (z. B. das Vermeiden eines Schlaglochs könnte eine temporäre Fahrbahnabweichung erfordern), die schwer als feste Kostenfunktionen zu kodieren sind, aber von einem Menschen oder Monitor als „akzeptabel“ oder „inakzeptabel“ für eine Trajektorie beurteilt werden können.

Die Arbeit legt nahe, dass spärliches Trajektorien-Feedback, verarbeitet durch einen sequentiellen Schätzer mit aktiver Selektion, die Lücke zwischen High-Level-Sicherheitsurteilen und Low-Level-Policy-Optimierung effektiv schließen kann.