Разметка данных и качество моделей
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 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
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):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 для кейсов.
- Полная автоматизация 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, вы получите устойчивые, этичные и комплаентные модели, которые улучшают бизнес-результаты без сюрпризов.