Pipeline SCRL ma cztery etapy. Etap 1: Reward model setup — dla każdej z trzech domen trenowany jest osobny Transformer-based reward model na task-specific danych (visual quality, audio sync, effect alignment, instruction alignment, representation alignment). Etap 2: Threshold calibration — dla każdego constraint reward R_c oblicza się μ_c^base i σ_c^base na SFT baseline distribution, ustala τ_c = μ_c + k_c × σ_c z module-specific k_c (1,1 dla VGAs, 0,8 dla IM, 0,3 dla GRM). Etap 3: Constrained reward construction — composite reward R(y_i) = R_feedback(y_i) − Σ_c λ_c(t) × ReLU(τ_c − R_c(y_i)) z PID-controlled λ_c(t). Etap 4: GDPO optimization — per-reward standardization + group-relative batch normalization + PPO-style policy update z importance sampling clipping i KL regularization.
Naiwne łączenie heterogenicznych nagród w multi-reward RL (np. quality + alignment + feedback) cierpi z trzech praktycznych problemów: (1) skala mismatch — różne nagrody mają różne rzędy wielkości i jedna dominuje pozostałe; (2) nie wszystkie nagrody są równorzędne — niektóre to twarde cele biznesowe, inne to ograniczenia jakości/zgodności; (3) hand-tuned magic numbers (wagi, progi) są kruche i niemożliwe do generalizacji między modułami. SCRL rozwiązuje to przez constrained formulation (user feedback jako primary, alignment i quality jako constraints), PID-controlled Lagrangians i kalibrację thresholds względem SFT baseline distribution.
Składowa nagrody mierząca jakość generowanego wideo z trzech aspektów: R_visual (estetyka, spójność spatio-temporal), R_audio (synchronizacja TTS, spójność BGM), R_effect (jakość subtitles, highlights, action bars). Wszystkie aspekty mają dedykowane Transformer-based reward models trenowane na task-specific danych.
Oficjalna
Składowa nagrody mierząca zgodność wygenerowanej treści z D-SIDs intencji użytkownika z GRM: R_instr-align (semantyczna zgodność D-SIDs ↔ wygenerowane instrukcje IM), R_rep-align (semantyczne podobieństwo D-SIDs ↔ finalnie wygenerowane wideo). Kotwiczy personalizację na strukturyzowanej intencji użytkownika.
Oficjalna
Składowa nagrody mierząca rzeczywistą reakcję użytkownika: R_real (sparse, ale wysoko-fidelity rzeczywiste interakcje — click, like, collect, purchase), R_pred (gęste predykcje engagement z deployed ranking models, łapiące preference strength poza explicit interactions). Łączenie sparse + dense rozwiązuje problem reward sparsity.
Time-varying λ_c(t) ≥ 0 dla każdego constraint reward, aktualizowane PID-controlled rule (proportional + integral + derivative na constraint violations) zamiast naive primal-dual update. Eliminuje typowe oscylacje i overshoot w constrained policy optimization (Stooke et al. 2020).
Oficjalna
Thresholds τ_c = μ_c^base + k_c × σ_c^base kalibrowane względem SFT baseline distribution na held-out validation set, z module-specific strictness factor k_c: VGAs (1,1 dla τ_a i τ_q — najsurowsze), IM (0,8 dla τ_a), GRM (0,3 dla τ_a, τ_q pominięte). Eliminuje hand-tuned magic numbers.
Standardowe primal-dual updates λ_c po naruszeniu constraints mają tendencję do nadkorekcji (overshoot) i oscylacji — λ_c rośnie zbyt agresywnie, potem spada zbyt mocno, destabilizując trening.
Statyczne, ręcznie dobrane τ_c są kruche — nie generalizują się między modułami (VGAs vs IM vs GRM) i wymagają ponownego strojenia przy każdej zmianie modelu. Brak relacji do baseline distribution oznacza brak intuicji co do trudności constraint.
Real user feedback (R_real) jest sparse i opóźniony — clicks/conversions zdarzają się rzadko per sample. Naive użycie tylko R_real prowadzi do niestabilnego, słabego signal treningowego.
Traktowanie wszystkich nagród jako równorzędnych (naive sum lub weighted sum) ignoruje fakt, że niektóre to twarde KPI biznesowe (feedback), a inne to gwarancje jakości — co prowadzi do suboptymalnych trade-offs gdy nagrody są w konflikcie.
Schulman et al. wprowadzają Proximal Policy Optimization — fundament wszystkich późniejszych on-policy RL methods.
Stooke et al. publikują 'Responsive Safety in Reinforcement Learning by PID Lagrangian Methods' — bezpośredni technologiczny fundament constrained policy optimization w SCRL.
OpenAI publikuje InstructGPT — standardowy pipeline RLHF z reward model + PPO. Inspiracja dla multi-aspect reward models w SCRL.
DeepSeek wprowadza Group Relative Policy Optimization — value-free policy optimization przez group-relative normalization.
Liu et al. (NVIDIA) wprowadzają GDPO z per-reward decoupled normalization — bezpośredni budulec optymalizacji w SCRL.
Kuaishou Technology + Beihang University łączą GDPO + PID Lagrangians + multi-domain reward models w SCRL — framework zamykający pętlę end-to-end w paradigmie Recommendation-as-Generation. Wdrożenie produkcyjne na 400M+ DAU.
Współczynnik definiujący jak restrykcyjny jest constraint threshold względem baseline std. Większy k_c = trudniej spełnić constraint = wyższy presja na alignment/quality.
Jak rozłożyć ogólny cel optymalizacji na primary objective vs constraints. RaG wybiera: user feedback = primary, alignment + quality = constraints.
Proportional, Integral, Derivative współczynniki kontrolera PID dla aktualizacji λ_c(t). Wpływają na szybkość reakcji na naruszenia constraints i stabilność.
Liczba i specjalizacja reward models w każdej domenie. RaG używa 7+ niezależnych Transformer-based reward models trenowanych na task-specific danych.
Stage-dependent w dwóch wymiarach: (1) reward routing per moduł RaG, (2) λ_c(t) zmienia się dynamicznie w trakcie treningu.
Każdy moduł w RaG (GRM, IM, VGAs) trenowany jest osobno z innym podzbiorem nagród i innym strictness k_c. VGAs widzą wszystkie nagrody (quality + alignment + feedback), IM widzi alignment + feedback (bez quality), GRM widzi tylko alignment + feedback z najbardziej zrelaksowanym k_a.
Obliczenia reward models są niezależne i mogą być zrównoleglone (jeden reward model na device). Per-reward standardization i sumowanie są lekkie. Bottleneck pozostaje rollout phase i sam policy update — nie konstrukcja composite reward.
Wszystkie komponenty SCRL (reward models, GDPO optimizer, policy update) to standardowe Transformer/MLP workloads na tensor cores. Kuaishou wdroży produkcyjnie na klastrach NVIDIA GPU.
Sam framework jest hardware-agnostic — wymaga tylko sprzętu wspierającego standardowe operacje policy optimization i Transformer reward models. Można wdrożyć na TPU, AMD MI300 itp.
