Розмітка даних і якість моделей

1) Призначення та принципи

Мета: отримувати відтворювані лейбли і вимірювану якість моделей без лейкеджу і з урахуванням комплаєнсу.

• Schema-first: формалізовані онтології, словники класів і критерії.
• Point-in-time: лейбли будуються з інформації, доступної на момент рішення.
• Quality-as-code: інструкції, тести, чек-листи і вибірки - в репозиторії.
• Privacy-by-design: мінімізація PII, DSAR/RTBF, резидентність.
• Cost-aware: рахуємо вартість розмітки і помилкових рішень (expected cost).

2) Онтологія і схема лейблів

• Об'єкт: транзакція/сесія.
• Класи: `legit`, `fraud_suspected`, `fraud_confirmed`, `unknown`.
• Винятки: chargeback без доказів →'unknown'.
• Джерела: кейс-менеджмент, chargeback-реєстри, провайдери/банк.

yaml task: aml_classification object: "payment_transaction"
labels:
- legit
- fraud_suspected
- fraud_confirmed
- unknown guidelines_version: "1. 3. 0"
positive_class: "fraud_confirmed"
exclusions:
- "dispute opened but no evidence -> unknown"
sources_of_truth:
- "case_system. resolution"
- "issuer. chargeback_code"

3) Інструкції анотації (guidelines)

1. Опис завдання та бізнес-контексту.

2. Визначення класів з позитивними/негативними прикладами та прикордонними кейсами.

3. Правила пріоритету джерел (істина> евристика> думка).

4. Критерії «unknown» і ескалації.

5. Політики приватності (маскування, токени замість ID).

6. FAQ і чек-лист розмітника.

• `fraud_confirmed`: доведений chargeback/закритий кейс з тегом FRAUD.
• `fraud_suspected`: ≥3 депозиту
• `legit`: немає прапорів і підтверджених кейсів у вікні 60 днів.
• `unknown`: конфліктуючі ознаки або недостатньо даних.

4) Джерела лейблів і point-in-time правила

Авто-лейбли: правила/кейси, chargeback, самовиключення (RG), outcome ставки.
Граунд-трут: результат розслідування/регуляторних результатів.
Point-in-time: заборонено використовувати події після моменту рішення (t0).
Затримки: наприклад, chargeback проявляється через 45-90 днів → лейбл «зріє».

sql
SELECT e. id, e. event_time AS asof,
CASE WHEN EXISTS (
SELECT 1 FROM cases c
WHERE c. tx_id = e. id
AND c. decision_time <= e. event_time + INTERVAL '90' DAY
AND c. result = 'FRAUD_CONFIRMED'
) THEN 'fraud_confirmed'
ELSE 'legit'
END AS label
FROM silver. payments e;

5) Вибірки: стратифікація та баланс

Рідкісні події: use stratified sampling по ринках/провайдерам/датам; oversampling рідкісних класів або focal loss.
Шари валідації: тримайте holdout по тижнях/ринках/тенантах.
Санкції/PII: виключайте поля з прямими ідентифікаторами з наборів навчання.

sql
-- Verification of class shares by market
SELECT market, label, COUNT() FROM dataset GROUP BY market, label;

6) Узгодженість розмітників (IRR)

Міряйте міжанотаторну згоду: Cohen's κ (2 анотатора )/Krippendorff's α (N анотаторів, різний тип шкали).

• κ < 0. 4 - слабка узгодженість → переглянути інструкції/приклади.

0. 4–0. 6 - прийнятно для складних завдань;> 0. 6 - добре;> 0. 8 - відмінно.

• Покриття (скільки розмічено), κ/ α за класами і слайсами, частка'unknown', середній час, топ-помилки.

7) QA-контур і золоті еталони

Golden set: 1-5% розміченого - еталон з подвійною перевіркою.
Honey-pot завдання: приховані відомі кейси в потоці завдань.
Другий погляд: ескалації/арбітраж на спірних прикладах.
Регресійні тести розмітки: повторна валідація після оновлення гайдів.

8) Активне, слабке та напів-контрольоване навчання

Active Learning: відбір «невпевнених» прикладів (максимум ентропії/різноманітності).
Weak Supervision: евристики/distant supervision + модель шуму для лейблів.
Semi-Supervised: псевдолейбли з температурним порогом і подальшою перевіркою.

python
U = unlabeled_pool()
scores, conf = model. predict(U)
C = pick_top_k_by_uncertainty(U, conf, k=500)
labels = annotate (C) # person train (model, L ∪ labels) # additional training

9) Анти-лейкедж і контроль часу

Point-in-time join для фіч і лейблів.
Заборона лейблів/фіч з майбутнього (після'asof').
Роздільні пайплайни online/offline з тестом еквівалентності трансформацій.
Версіонування датасетів і логіки ('logic _ version','data _ version','asof _ date').

10) Метрики якості моделей

• Класифікація: PR-AUC/ROC-AUC, F1@k, Recall@k, expected cost (веса FP/FN).
• Скоринг ризику: KS/ROC-AUC, Brier, калібрування (ECE), PSI/CSI для дрейфу.
• Рекомендації: NDCG/MAP @K, coverage/diversity, новизна.
• Аномалії: Precision @k, AUCPR на синтетиці/золотому наборі.

python best_thr = argmin_thr(cost_fpFPR(thr) + cost_fnFNR(thr))

11) Слайс-аналіз і fairness

Слайси: ринок, провайдер, девайс/ASN, вік аккаунта, розмір депозиту, час доби.
Fairness: disparate impact (ratio), equalized odds (різниця FPR/TPR).
Дії: перезбір фіч, калібрування по слайсах, перегляд порогів, навчальні ваги.

12) Моніторинг production-якості

Дрейф даних/прогнозів: PSI/KL по фічам/скорам.
Калібрування: ECE, reliability-діаграми.
Стабільність порогу: alert, якщо expected cost ↑> X% або PR-AUC ↓.
Схеми/контракти: відловлювати breaking changes (schema registry).
Feedback loop: швидкі ручні лейбли по інцидентах (case-закриття, RG-результати).

13) Приватність, безпека, комплаєнс

PII-мінімізація: псевдоніми, окремий захищений маппінг.
Резидентність: роздільні пайплайни/ключі (EEA/UK/BR); заборона крос-регіональних join'ів без підстави.
DSAR/RTBF: обчислювані проекції та селективні редагування.
Legal Hold: WORM-архіви для кейсів та звітних пакетів.
Журнали: незмінний аудит доступу/експорту.

14) Організація процесу розмітки

Інструменти: task-трекер, черга прикладів, перегляд контексту, маскування PII, гарячі клавіші.
Контроль швидкості та якості: KPI анотатора (швидкість, точність на golden), навчання та атестація.
Версіонування: 'guidelines _ version','annotator _ id','reviewer _ id', таймстемпи.
Документація: картка набору (owner, джерело, вікна, правила, метрики).

15) Приклади шаблонів

yaml name: aml_tx_2025q1_pt owner: ml-risk asof_range: ["2024-10-01", "2024-12-31"]
positive_label: fraud_confirmed guidelines_version: "1. 3. 0"
feature_window: "[-30d, 0d)"
holdout: ["2024-12-15", "2024-12-31"]
pii_policy: "tokenized_user_ids; masked_pan; no_raw_ip"

yaml qa:
min_kappa: 0. 6 golden_accuracy_min: 0. 9 max_unknown_share: 0. 15 reannotation_on_disagreement: true

sql
SELECT pred, label, COUNT() n
FROM eval_predictions
GROUP BY pred, label;

16) Дорожня карта впровадження

1. Онтологія та інструкції v1, золотий набір (≥1000 прикладів на домен).

2. Анотаційний потік з PII-маскуванням, κ -метрика на щотижня.

3. Базова модель + offline-оцінка (PR-AUC, expected cost), point-in-time вибірки.

4. Моніторинг дрейфу фіч/скорів; регістр датасетів і версій гайдів.

• Active/weak-supervision конвеєр, auto-triage'unknown'.
• Слайс-аналіз і fairness-звіти, калібрування ймовірностей.
• Процедури DSAR/RTBF для розмічених наборів, Legal Hold для кейсів.

• Повна автоматизація QA (golden/honey-pots), регресійні тести розмітки.
• Каталог датасетів і картки «якість моделі»; expected-cost оркестрація порогів.
• Chargeback за вартістю розмітки/інференсу, SLA за оновленнями лейблів.

17) RACI

R (Responsible): Data Science (онтологія, метрики), Label Ops (процес/QA), Data Eng (вибірки/PII/сховище).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/DPO (PII/residency/DSAR), Risk/AML/RG (правила), Security (KMS/аудит).
I (Informed): Продукт/Маркетинг/Операції/Підтримка.

18) Чек-лист перед продом

• Онтологія і гайди затверджені, версія зафіксована.
• Якісна вибірка: стратифікація, holdout за часом/ринками.
• κ/ α ≥ цільового порогу; golden-accuracy дотримана.
• Point-in-time збір фіч і лейблів; тест на відсутність лейкеджу пройдено.
• Метрики вибрані по expected cost, виконаний слайс-аналіз і fairness.
• Моніторинг дрейфу/калібрування включений; алерти налаштовані.
• Політики PII/DSAR/RTBF і Legal Hold дотримані; аудит включено.

19) Анти-патерни і ризики

Розмітка без чітких критеріїв → низький κ, галасливі лейбли.
Лейкедж з майбутнього (пост-фактум ознаки/лейбли).
Незбалансовані вибірки, метрика ROC-AUC без урахування вартості.
Відсутність golden/QA і регресійних тестів розмітки.
PII в датасетах без маскування і резидентності.
Немає слайс-аналізу → прихована деградація на регіонах/провайдерах.

20) Підсумок

Якість моделей починається з якості лейблів. Сувора онтологія, інструкції з прикладами, point-in-time дисципліна, QA-контури і метрики, що враховують вартість помилок, - основа відтворюваного ML в iGaming. Вбудувавши ці практики в конвеєр даних і MLOps, ви отримаєте стійкі, етичні та комплаєнтні моделі, які покращують бізнес-результати без сюрпризів.