GH GambleHub

Разметка данных и качество моделей

1) Назначение и принципы

Цель: получать воспроизводимые лейблы и измеряемое качество моделей без лейкеджа и с учетом комплаенса.

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

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

Определите объект разметки, классы, исключения и источники правды: Пример (AML/Антифрод):
  • Объект: транзакция / сессия.
  • Классы: `legit`, `fraud_suspected`, `fraud_confirmed`, `unknown`.
  • Исключения: chargeback без доказательств → `unknown`.
  • Источники: кейс-менеджмент, chargeback-реестры, провайдеры/банк.
YAML-схема:
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 депозита < REPORT_LIMIT за 10 мин + связка IP/карта с колечком.
  • `legit`: нет флагов и подтвержденных кейсов в окне 60 дней.
  • `unknown`: конфликтующие признаки или недостаточно данных.

4) Источники лейблов и point-in-time правила

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

Шаблон SQL «без будущего»:
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: псевдолейблы с температурным порогом и последующей проверкой.

Pipeline (эскиз):
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 на синтетике/золотом наборе.
Expected-Cost (псевдокод):
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):
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"
Правила QA разметки:
yaml qa:
min_kappa: 0. 6 golden_accuracy_min: 0. 9 max_unknown_share: 0. 15 reannotation_on_disagreement: true
Confusion matrix (SQL-идея):
sql
SELECT pred, label, COUNT() n
FROM eval_predictions
GROUP BY pred, label;

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

MVP (2–4 недели):

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

2. Аннотационный поток с PII-маскированием, κ-метрика на каждую неделю.

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

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

Фаза 2 (4–8 недель):
  • Active/weak-supervision конвейер, auto-triage `unknown`.
  • Слайс-анализ и fairness-отчеты, калибровка вероятностей.
  • Процедуры DSAR/RTBF для размеченных наборов, Legal Hold для кейсов.
Фаза 3 (8–12 недель):
  • Полная автоматизация 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, вы получите устойчивые, этичные и комплаентные модели, которые улучшают бизнес-результаты без сюрпризов.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.