GH GambleHub

Monitorowanie modelu

1) Dlaczego

Celem jest utrzymanie jakości i bezpieczeństwa rozwiązań modelu w sprzedaży, przy jednoczesnym zachowaniu zgodności z SLA/SLO, RG/AML/Legal i budżetów. Monitorowanie powinno wykrywać wczesną degradację (dane, kalibracja, opóźnienie, koszt), minimalizować oczekiwany koszt błędów oraz zapewnić odtwarzalność/audyt.


2) Obszary monitorowania (mapa)

1. Dostępność i wydajność: latency p95/p99, błąd, RPS, autoskale.
2. Jakość prognozy: PR-AUC/KS (na etykietach internetowych), kalibracja (ECE), oczekiwany koszt @ próg.
3. Dryf i stabilność: PSI/KL według funkcji i prędkości, zmiana dystrybucji/kategorii.
4. Zasięg i kompletność: udział pomyślnie obsługiwanych zapytań, udział „pustych” funkcji, pamięci podręcznej.
5. Kawałek/sprawiedliwość: metryki według rynku/dostawcy/urządzenia/wieku konta.
6. Poręcze ochronne (RG/AML): naruszenia polityki, częstotliwości interwencji, fałszywe pozytywy/negatywy.
7. Koszt: koszt/żądanie, koszt/funkcja, GPU/CPU-zegar, małe pliki/IO (dla partii/blisko-RT).
8. Dane/umowy: system funkcji, wersje, równoważność online/offline.


3) SLI/SLO (punkty orientacyjne dla iGaming)

Opóźnienie p95: personalizacja ≤ 150 ms, wpisy RG/AML ≤ 5 z e2e.
Dostępność: ≥ 99. 9%.
Szybkość błędu 5xx: ≤ 0. 5% w oknie 5 min.
Zasięg: ≥ 99% wniosków otrzymało prawidłową prędkość i rozwiązanie.
Świeżość etykiet do oceny online: D + 1 (dziennie), dla szybkich pełnomocników - ≤ 1 godzina.
Drift PSI: Funkcja/szybkość <0. 2 (ostrzeżenie 0. 1).
Kalibracja EKG: ≤ 0. 05.
Expected-cost_live: nie wyższy niż model bazowy + X% (cel X jest wybierany przez firmę).


4) Sygnały i wzory

4. 1 Dryf

PSI: podsumować różnicę w rozkładzie (pociąg vs prod).
Dywergencja KL: wrażliwe na „cienkie” ogony; monitor dla kluczowych funkcji/prędkości.
KS dla stawek (jeśli etykiety są obecne): różnica CDF dla dodatnich/negatywnych.

4. 2 Kalibracja

ECE (przewidywany błąd kalibracji):przewidywany prob − wskaźnik empirycznyna koszach.
Krzywa niezawodności: wykres dokładności vs prawdopodobieństwo.

4. 3 Przewidywany koszt

zminimalizować (C = c_{fp}\cdot FPR + c_{fn}\cdot FNR) na progu roboczym; liczyć online w oknie przesuwnym z opóźnionymi etykietami.


5) Źródła etykiet

Etykiety online (szybkie serwery proxy): 7-dniowe zdarzenie depozytowe, kliknij/konwersja, zakończona sprawa RG.
Opóźnione etykiety: obciążenie zwrotne/oszustwo (45-90 dni), długoterminowe churn/LTV.
Zasady: zachowaj na bieżąco; nie używać zdarzeń „z przyszłości”.


6) Deski rozdzielcze (minimalny skład)

1. Obsługa: RPS, p50/p95/p99 latency, 4xx/5xx, nasycenie, autoskalowanie.
2. Jakość: rozkład punktów, PR-AUC (na etykietach zastępczych), EKG, oczekiwany koszt, KS.
3. Drift: PSI/KL według najlepszych funkcji, kategorie nowości, brakująca szybkość, funkcja pobrania opóźnienia.
4. Kawałek/sprawiedliwość: PR-AUC/ECE/oczekiwany koszt według rynku/dostawcy/urządzenia.
5. Poręcze: naruszenie RG/AML, interwencje/1k żądania, fałszywy stopa.
6. Koszt: koszt/żądanie, czas CPU/GPU, szybkość trafienia w pamięci podręcznej, wyszukiwanie zewnętrzne.


7) Ostrzeganie (przykładowe zasady)

HighP95Latency: p95> 150 ms (5 min) → strona SRE/MLOp.
ErrorBurst: 5xx> 0. 5% (5 min) → skrypt rollback jest dostępny.
PSI_Drift: PSI (amount_base)> 0. 2 (15 min) → rozgrzewka.
ECE_Bad: EKG> 0. 07 (30 min) → przebudowa kalibracji/progów.
ExpectedCost_Up: + X% do punktu odniesienia (1 dzień) → rozważyć rollback/przeciążenie.
Slice_Failure: PR-AUC na rynku R spadł> Y% (1 dzień) → właściciel domeny biletowej.
Guardrails_Breach: udział agresywnych ofert> cap → natychmiastowy kill-switch.


8) Rejestrowanie i śledzenie

Dzienniki zapytań (minimum): 'request _ id',' trace _ id', 'model _ id/version', 'feature _ version', 'feature _ stats' (brak%, skrajności),' score ',' decision ',' threshold ',' policy _ id', 'guard _ mask', 'latency _ ms', 'cost' _ estimate ', (opcjonalne) wyjaśnienia (SHAP top-k).
OTel-треса: стана 'feature _ fetch' → 'preprocess' → 'score' → 'postprocess' → 'guardrail'.
PII: wyłącznie aliasy/żetony; Maskowanie polityki, kluczowa rezydencja.


9) Ocena jakości online

Okna przesuwne dla PR-AUC/KS za pomocą szybkich etykiet (godzina/dzień).
Przechowywane etykiety: D + 7/D + 30/D + 90 raportów retrospektywnych, korekty kosztowe.
Kalibracja: Ponowna ocena izotoniczna/Platt na D + 1, artefakt automatycznie odświeżający.


10) Próg decyzji i polityka

Utrzymujemy próg jako konfig w rejestrze; online rozważamy przewidywany koszt i dostosować się w dopuszczalnym zakresie (stawka ograniczona).
Czapki bezpieczeństwa: górne/dolne granice działań; ręczna regulacja zgodności.
Progi Backtesting: nocna symulacja wczorajszych danych.


11) Plasterki i uczciwość

Segmenty: rynek/jurysdykcja, dostawca, urządzenie/ASN, wiek konta, moc depozytu.
Wskaźniki: PR-AUC, ECE, oczekiwany koszt, różnice FPR/TPR (wyrównane szanse), rozbieżny wpływ.
Działania: kalibracja/próg dla plasterków, przekwalifikowanie skalą, przegląd funkcji.


12) Równoważność online/offline

Funkcja testu równości: MAE/MAPE na próbce kontrolnej; alert przy rozbieżności> próg.
Wersioning: 'feature _ spec _ version', 'logic _ version'; Archiwum WORM.
Umowy obwodowe: bez podwójnego wpisu (v1/v2) nie dopuszcza się zmiany obwodu.


13) Szyny ochronne (RG/AML)

Działania przed-/post-filtr, limity częstotliwości, cooldown, listy zakazów.
Лова „policy _ id/propensity/mask/decision”; zgłaszać naruszenia.
Czas do wywiadu i fałszywe wskaźniki interwencji.


14) Incydenty i książka startowa

Scenariusze i etapy:

1. Opóźnienie/5xx na stronie: sprawdź zewnętrznych dostawców funkcji → włącz pamięć podręczną/timeouts → skala → rollback w razie potrzeby.

2. PSI/ECE/Przewidywany koszt uległ pogorszeniu: zamrożenie ruchu (kanaryjskie), włączenie progów awaryjnych/modelu, przekwalifikowanie biegu.

3. Awaria kawałka: tymczasowy próg specyficzny dla kawałków, bilet do właściciela domeny.

4. Naruszenie barier: przełącznik zabójstw, audyt przypadków, po morzu.


15) Koszt i wydajność

Profilowanie: Ułamek czasu w feature-fetch vs score vs IO.
Strategie pamięci podręcznej: TTL/eksmisja, gorące funkcje w pamięci RAM, zimne - leniwe.
Kwantyzacja/optymalizacja modelu: FP16/INT8 przy zachowaniu jakości.
Obciążenie zwrotne: koszt/żądanie, koszt/funkcja według zespołu/rynku.


16) Przykłady (fragmenty)

Próg przewidywanych kosztów (pseudokoda):
python thr_grid = np.linspace(0.01, 0.99, 99)
costs = [expected_cost(y_true, y_prob >= t, c_fp, c_fn) for t in thr_grid]
thr_best = thr_grid[np.argmin(costs)]
Prometeusz (pomysły metryczne):
text model_inference_latency_ms_bucket feature_fetch_latency_ms_bucket model_request_total{code}
model_score_distribution_bucket psi_feature_amount_base ece_calibration expected_cost_live slice_pr_auc{slice="EEA_mobile"}
Alert (idea):
text
ALERT DriftDetected
IF psi_feature_amount_base > 0.2 FOR 15m

17) Procesy i RACI

R (odpowiedzialny): MLOp (obserwowalność/wpisy/rejestr), Data Science (wskaźniki jakości/kalibracja/próg), Data Eng (cechy/umowy/równoważność).
A (Odpowiedzialność): szef danych/CDO.
C (skonsultowano się): Zgodność/DPO (PII/RG/AML/DSAR), Bezpieczeństwo (KMS/Audit), SRE (SLO/Incydenty), Finanse (Koszt).
I (Poinformowany): Produkt/Marketing/Operacje/Wsparcie.


18) Plan działania

MVP (2-4 tygodnie):

1. Podstawowy SLI/SLO (latency/5xx/coverage) + deska rozdzielcza.

2. PSI dla 10 najlepszych funkcji i dystrybucji punktów; EKG i przewidywane koszty na etykietach zastępczych.

3. dzienniki decyzji + szlaki OTel; test równoważności online/offline.

4. Alerts HighP95Latency/PSI_Drift/ECE_Bad + runbook'i.

Faza 2 (4-8 tygodni):
  • Panele kawałków/rzetelności, nocne mierniki zasypki na opóźnionych etykietach.
  • Automatyczna rekalibracja i symulator progowy.
  • Deska rozdzielcza i kwoty/limity na funkcje/powtórki.
Faza 3 (8-12 tygodni):
  • Dryf automatycznego uwalniania/przekładania z kontrolą kanaryjską.
  • Archiwa WORM raportów jakości i artefaktów.
  • Testy monitorowania chaosu i ćwiczenia DR.

19) Lista kontrolna dostawy

  • SLI/SLO uzgodnione i monitorowane w cieniu/kanarku ≥ 24 godziny.
  • PSI/KL, ECE, przewidywane koszty i PR-AUC są rozpatrywane online; określono progi i wpisy.
  • Panele cięcia/uczciwości są włączone; przypisuje się właścicieli segmentów.
  • Kompletne kłody/trasy (decyzje, progi, maski), maskowanie PII i miejsce zamieszkania spełnione.
  • Test równoważności online/offline green; wykresy funkcji w ramach umowy.
  • Uruchomiona książka startowa "i testowany rollback z jednym kliknięciem; kill-switch дла guardrails.
  • Koszty wpisują się w budżety; cache/kwoty/limity są aktywne.
  • Przechowywane jest archiwum metryki/artefaktów i raportów jakościowych WORM.

20) Przeciwdziałanie modelom i ryzyku

Brak etykiet online i retrospektywna ocena.
Monitorowanie ROC-AUC tylko bez przewidywanych kosztów i kalibracji.
Ignoruj kawałek/uczciwość → ukryte awarie w regionach/urządzeniach.
Nie ma równoważności funkcji online/offline → „podwójna rzeczywistość”.
Zero barier: Toksyczne oferty, naruszenia RG/AML.
Brak planów wstecznych/DR, brak archiwum WORM.


21) Najważniejsze

Monitorowanie modelu to system wczesnego ostrzegania i zarządzania ryzykiem/kosztami, zamiast "patrzeć raz w tygodniu. "Wprowadź SLO, zmierz dryf/kalibrację/oczekiwany koszt, plasterki toru i barierki, przytrzymaj przyciski rollback/kill-switch, automatyzuj raporty i przekierowania. Tak więc modele pozostaną użyteczne, etyczne i zgodne z wszelkimi turbulencjami danych i ruchu.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.