Menjalankan model Reinforcement Learning (RL) berbasis arsitektur ringkas seperti single-layer transformer (Decision Transformer ringan atau policy network berbasis attention satu layer) di production membutuhkan pendekatan deployment yang ketat. Karakteristik model RL sangat rentan terhadap distribution shift dan instabilitas aksi secara real-time. Artikel ini membahas implementasi canary release, pemantauan latensi komputasi, serta otomatisasi rollback saat metrik performa atau reward mengalami degradasi.

Arsitektur Inferensi dan Verifikasi Metrik

Model policy RL satu layer biasanya dipilih untuk sistem berlatensi rendah seperti real-time bidding, recommender ranking dinamis, atau kontrol jaringan. Karena arsitekturnya ringkas, inferensi umumnya dibatasi dengan SLA di bawah 10ms.

Sebelum membuka lalu lintas pengguna, jalankan verifikasi lokal pada instance inferensi untuk memastikan determinisme output numerik dan kestabilan dimensi tensor:

import torch
import numpy as np

def verify_policy_shape_and_latency(model, input_dim, seq_len=1):
    model.eval()
    dummy_state = torch.randn(1, seq_len, input_dim)
    
    with torch.no_grad():
        # Dry run untuk GPU/CPU warmup
        for _ in range(10):
            _ = model(dummy_state)
            
        # Validasi output tensor
        action_dist = model(dummy_state)
        assert not torch.isnan(action_dist).any(), "Error: Terdeteksi nilai NaN pada output action"
        assert action_dist.shape[-1] > 0, "Error: Output layer tidak valid"
        
    return True

Konfigurasi Canary Release via Traffic Shifting

Terapkan pembagian trafik bertahap menggunakan API Gateway atau Service Mesh (seperti Envoy atau Istio). Jangan mengalihkan 100% trafik langsung ke model baru. Mulai dengan alokasi 5% pada fase canary, pantau metrik esensial, lalu naikkan secara linear.

Contoh konfigurasi VirtualService Envoy/Istio untuk membagi beban kerja antara model stable dan canary:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: rl-policy-routing
spec:
  hosts:
  - rl-infer.internal
  http:
  - route:
    - destination:
        host: rl-infer-service
        subset: stable
      weight: 95
    - destination:
        host: rl-infer-service
        subset: canary
      weight: 5

Observability: Latensi CPU/GPU dan Deteksi Anomali

Model RL rentan mengalami bottleneck komputasi jika batched inputs tidak ditangani dengan efisien. Metrik yang wajib dipantau:

  • Latensi P99: Batas ambang harus berada pada rentang toleransi aplikasi (contoh: < 15ms). Peningkatan tajam menandakan adanya degradasi batch processing.
  • GPU/CPU Engine Saturation: Penggunaan context switching yang terlalu tinggi pada model ringkas sering kali menunjukkan thread contention.
  • Action Distribution Entropy: Entropy yang jatuh drastis mendekati nol menandakan model mengalami policy collapse (selalu memilih aksi yang sama).

Automated Rollback Berbasis Reward Drop

Pada model RL, stabilitas sistem tidak hanya diukur dari HTTP 5xx atau latensi, melainkan business reward (misalnya: Click-Through Rate, conversion rate, atau task completion). Jika nilai moving average reward pada subset canary turun drastis dibanding versi stable, sistem orkestrasi harus mengeksekusi rollback otomatis.

Contoh skrip Prometheus alerting evaluation loop untuk eksekusi rollback otomatis via Kubernetes patch:

import os
import subprocess
import requests

PROMETHEUS_URL = "http://prometheus.monitoring:9090/api/v1/query"
REWARD_DROP_QUERY = '(rate(rl_reward_canary_sum[5m]) / rate(rl_reward_canary_count[5m])) < 0.8 * (rate(rl_reward_stable_sum[5m]) / rate(rl_reward_stable_count[5m]))'

def evaluate_and_rollback():
    response = requests.get(PROMETHEUS_URL, params={'query': REWARD_DROP_QUERY}).json()
    results = response.get('data', {}).get('result', [])
    
    if results:
        print("Peringatan: Reward drop terdeteksi melebihi ambang batas 20%. Memicu rollback...")
        # Reset traffic weight canary menjadi 0
        patch_cmd = [
            "kubectl", "patch", "virtualservice", "rl-policy-routing",
            "--type", "json",
            "-p", '[{"op": "replace", "path": "/spec/http/0/route/1/weight", "value": 0}, {"op": "replace", "path": "/spec/http/0/route/0/weight", "value": 100}]'
        ]
        subprocess.run(patch_cmd, check=True)
        print("Rollback selesai. Trafik 100% dialihkan kembali ke stable.")

if __name__ == "__main__":
    evaluate_and_rollback()

Mitigasi Kegagalan dan Postmortem Checklist

Ketika model canary gagal memenuhi ekspektasi operasional dan rollback selesai dilakukan, tim teknik harus menjalankan audit terstruktur. Jangan langsung melakukan re-training tanpa menganalisis akar masalah.

Langkah Mitigasi Cepat (Safe Fallback)

Sediakan modul fallback heuristik berbasis aturan lokal (rule-based fallback) langsung di layer aplikasi. Jika servis RL mengalami timeout (> 50ms) atau mengembalikan output invalid, servis langsung menggunakan aksi default statis tanpa melempar exception ke end-user.

Postmortem Checklist

  • Data Distribution Shift: Apakah fitur input pada traffic live menyimpang dari dataset training offline?
  • Exploration Noise Leakage: Apakah aksi model baru menyertakan noise eksplorasi acak yang belum dinonaktifkan (training artifact)?
  • Tensor Shape Mismatch: Apakah sequence padding menyebabkan perbedaan representasi pada input transformer layer?
  • Hardware Bottleneck: Apakah ada pembatasan memori GPU atau thermal throttling CPU selama evaluasi canary?