Перейти к основному содержимому

Платформа машинного обучения

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа​

Документ определяет платформу машинного обучения (machine learning platform, ML-платформа) Vitiana — стандартизированную инфраструктуру для всех применений машинного обучения на платформе. Включает:

  • Каноничную модель сущностей машинного обучения (MlModel, MlFeature, MlExperiment, MlInferenceRequest, MlTrainingRun).
  • Четыре подкомпонента ML-платформы (хранилище признаков — feature store; реестр моделей — model registry; обслуживание моделей — model serving; наблюдаемость моделей — model monitoring).
  • Каталог применений (use cases) с фазами реализации.
  • Цикл MLOps — от данных к боевому развёртыванию.
  • Защиту приватности при машинном обучении (privacy-preserving ML).
  • Согласованность признаков между обучением и сервингом (training-serving consistency).
  • Эксперименты с моделями (A/B exposure, shadow mode, canary).
  • Наблюдаемость качества моделей и обнаружение деградации.
  • Фазы развёртывания.

Документ читается после:

В корневых документах зафиксировано что ML-платформа делает и где она применяется. Этот документ описывает как — каноничные сущности, четыре подкомпонента, MLOps-цикл, защиту приватности, фазы.

ML-платформа — общая инфраструктура, не отдельный проект. Все применения ML на платформе (ранжирование поиска, обнаружение мошенничества, динамическое ценообразование, рекомендации, прогнозирование отмен) идут через одну платформу, не через множество локальных решений. Это закон правила «современных лучших практик»: один Feature store, один Model registry, один сервис обслуживания моделей.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: ML-модели обучаются на каноничных данных платформы, не на сырых данных конкретного поставщика. Конкретный поставщик может быть отключён, заменён, добавлен — модели продолжают работать на каноничной модели.

Главное решение​

Платформа машинного обучения — единая стандартизированная инфраструктура для всех применений ML на платформе, с четырьмя обязательными подкомпонентами и каноничным MLOps-циклом.

Это означает:

  • Каждое применение ML использует одну и ту же платформу — ранжирование поиска, обнаружение мошенничества, динамическое ценообразование, рекомендации.
  • Признаки общие — Feature store содержит признаки, переиспользуемые между моделями. Не локальные feature engineering на каждое применение.
  • Реестр моделей единый — каждая боевая модель зарегистрирована, версионирована, отслеживаема.
  • Сервинг стандартизирован — все модели разворачиваются через единый сервис обслуживания, не через локальные эндпоинты.
  • Согласованность обучения и сервинга — признаки в обучении и в сервинге должны быть идентичны. Архитектурно гарантировано, не процессом ревью.
  • Privacy by design — модели обучаются на анонимизированных данных платформы данных. Прямой доступ моделей к необработанным персональным данным запрещён.

Каноничная модель ML-платформы​

Главные сущности​

MlFeature — признак​

Сущность, представляющая именованный признак для использования в моделях.

{
  feature_id: string,
  feature_name: string,
  feature_namespace: string,
  data_type: enum,
  source_type: enum,
  source_definition: object,
  freshness_class: enum,
  privacy_class: enum,
  retention_class: string,
  owners: array,
  documentation: string,
  schema_version: string,
  is_active: boolean,
  created_at: timestamp,
  updated_at: timestamp
}

Поля:

  • feature_namespace — пространство имён (например, partner, property, actor_session, supplier, commercial).
  • data_type — тип значения (numeric / categorical / boolean / embedding / temporal_aggregate).
  • source_type — источник: streaming (real-time из tracking pipeline), batch (периодическая выборка из DWH), derived (вычисляется из других признаков).
  • source_definition — определение источника (для batch — SQL-запрос; для streaming — описание stream-агрегации; для derived — формула).
  • freshness_class — класс свежести (real_time — секунды; near_real_time — минуты; daily — пересчёт раз в день; weekly — пересчёт раз в неделю).
  • privacy_class — класс приватности из системы Платформа данных и захват событий. Признак с классом pii_strict запрещён в Feature store.
  • owners — команды, владеющие признаком и отвечающие за его качество.

Каноничный пример признаков:

  • partner.daily_search_volume_7d — 7-дневное скользящее среднее поисковых вызовов партнёра. numeric, daily, aggregate_only.
  • actor_session.click_through_rate — конверсия просмотров в клики в текущей сессии. numeric, real_time, behavioral.
  • property.embedding — векторное представление объекта размещения для рекомендаций. embedding, weekly, public.
  • commercial.average_quote_to_booking_conversion_30d — конверсия коммерческих фиксаций в бронирования за 30 дней. numeric, daily, aggregate_only.

MlModel — модель​

Сущность, представляющая зарегистрированную ML-модель.

{
  model_id: UUID,
  model_name: string,
  model_namespace: string,
  use_case: string,
  task_type: enum,
  framework: string,
  framework_version: string,
  current_version: string,
  active_version: string,
  feature_dependencies: array,
  evaluation_metrics: object,
  business_metrics_owner: string,
  privacy_class: enum,
  retention_class: string,
  owners: array,
  documentation: string,
  created_at: timestamp,
  updated_at: timestamp
}

Поля:

  • use_case — каноничное применение (search_ranking / chargeback_prevention / dynamic_platform_pricing / cancellation_prediction / tour_recommendation / supplier_health_anomaly / quote_to_booking_conversion_prediction / partner_segmentation).
  • task_type — задача (ranking / binary_classification / multi_class_classification / regression / clustering / embedding / anomaly_detection).
  • framework — рамочное решение (PyTorch, TensorFlow, scikit-learn, XGBoost, LightGBM, ONNX).
  • current_version, active_version — последняя зарегистрированная и текущая боевая версия.
  • feature_dependencies — массив feature_id, от которых модель зависит.
  • business_metrics_owner — команда, отвечающая за бизнес-результаты модели.

MlModelVersion — версия модели​

Каждая обученная версия модели — отдельная сущность с детализацией:

{
  version_id: UUID,
  model_id: UUID,
  version_label: string,
  training_run_id: UUID,
  artifact_uri: string,
  feature_snapshot: array,
  evaluation_report: object,
  approval_state: enum,
  approved_by: string,
  approved_at: timestamp,
  deployed_at: timestamp,
  retired_at: timestamp
}

Поля:

  • feature_snapshot — точный снимок признаков на момент обучения (имена, версии схем, диапазоны значений).
  • approval_state — состояние одобрения (pending_review / approved / rejected / retired).
  • approved_by — кто одобрил для боевого использования.

MlTrainingRun — обучающий прогон​

Сущность, представляющая конкретный прогон обучения модели.

{
  run_id: UUID,
  model_id: UUID,
  triggered_by: string,
  trigger_reason: enum,
  training_data_snapshot: object,
  hyperparameters: object,
  evaluation_metrics: object,
  resource_usage: object,
  state: enum,
  started_at: timestamp,
  completed_at: timestamp,
  artifact_uri: string
}

Поля:

  • trigger_reason — причина (scheduled_retrain / data_drift_detected / manual_retrain / feature_schema_changed / hyperparameter_search).
  • training_data_snapshot — точное определение обучающих данных (период, фильтры, объём).
  • resource_usage — потреблённые ресурсы (часы CPU/GPU, память, стоимость).

MlInferenceRequest — запрос к модели​

Сущность, представляющая конкретный запрос на инференс модели.

{
  request_id: UUID,
  model_id: UUID,
  model_version: string,
  caller_service: string,
  input_features: object,
  feature_resolution_source: enum,
  output: object,
  inference_latency_ms: integer,
  experiment_assignment: object,
  privacy_class: enum,
  request_at: timestamp
}

Поля:

  • feature_resolution_source — где брались признаки (real_time_lookup — Feature store online / batch_precomputed — заранее рассчитанные / caller_provided — переданные вызывающим сервисом).
  • experiment_assignment — если запрос попал в эксперимент A/B, тут отметка.
  • output — результат инференса (для ranking — упорядоченный список с скорами; для classification — класс с уверенностью; для regression — значение с интервалом).

MlExperiment — эксперимент​

Сущность, представляющая эксперимент над моделью (A/B сравнение версий, shadow mode, canary).

{
  experiment_id: UUID,
  experiment_name: string,
  use_case: string,
  experiment_type: enum,
  control_model_version: string,
  treatment_model_versions: array,
  traffic_allocation: object,
  segmentation_rules: object,
  primary_metric: string,
  secondary_metrics: array,
  duration_days: integer,
  state: enum,
  started_at: timestamp,
  ended_at: timestamp,
  conclusion: object
}

Поля:

  • experiment_type — тип (ab_test — параллельные версии на разном трафике; shadow_mode — новая модель работает параллельно, не влияя на боевые ответы; canary — постепенный rollout с уровнями трафика).
  • primary_metric — главная метрика (например, quote_to_booking_conversion, chargeback_loss_reduction).

Связь с другими каноничными сущностями​

Четыре подкомпонента ML-платформы​

Подкомпонент 1. Хранилище признаков (feature store)​

Хранилище признаков — центральная сущность ML-платформы.

Главное правило: согласованность обучения и сервинга​

Признаки, доступные модели в момент обучения, и признаки, доступные в момент сервинга — должны быть идентичны на уровне определения и значений на момент вычисления. Это называется согласованностью обучения и сервинга (training-serving consistency).

Без этой согласованности модель, обученная на одних признаках, в боевом режиме получает другие, и качество деградирует — это известная проблема ML, которую Feature store решает архитектурно.

Два режима хранения​

  • Offline store — для обучения. Хранит исторические значения признаков, реализован поверх DWH (Платформа данных и захват событий, gold layer). Запросы — пакетные, низкая стоимость, высокая задержка.
  • Online store — для сервинга. Хранит текущие значения признаков, реализован как key-value хранилище (Redis / DynamoDB / собственный sharded). Запросы — мгновенные, низкая задержка, высокая стоимость.

Один и тот же признак (MlFeature) реализован в обоих режимах. Архитектурный закон — определение признака одно, реализация двойная, согласованность гарантирована рамочным решением.

Поток наполнения​

Источник (DWH gold layer / streaming pipeline)
       ↓
Feature pipeline (преобразование, агрегация)
       ↓
   ├── Offline store (DWH-таблица с историей)
   └── Online store (key-value текущее значение)

Запрет локальных feature engineering​

Запрещено: разработчик ML-модели создаёт собственные локальные пайплайны вычисления признаков, не регистрируя их в Feature store. Это разрушает согласованность обучения и сервинга и дублирует работу.

Разрешено: разработчик регистрирует новый признак в Feature store, и потом использует его. Это занимает время на одну итерацию (определение, документация, ревью), но окупается долгосрочно.

Подкомпонент 2. Реестр моделей (model registry)​

Реестр моделей — единая система регистрации и управления версиями моделей.

Что хранится​

  • Все обученные версии всех моделей (даже отброшенные — для аудита).
  • Метаданные обучения (когда, на каких данных, с какими гиперпараметрами, какие метрики).
  • Артефакты модели (бинарные файлы) в Object Storage.
  • Состояние одобрения каждой версии.
  • История развёртывания (когда какая версия была активна).
  • Connection с экспериментами и оценочными отчётами.

Жизненный цикл версии​

Training run completed
      ↓
Артефакт зарегистрирован в реестре, состояние pending_review
      ↓
   ├── Approved by владельцем — переход в shadow mode или experiment
   ├── Rejected — состояние rejected, не разворачивается
      ↓
Shadow mode (опционально, для критических моделей)
      ↓
A/B эксперимент vs текущая активная версия
      ↓
   ├── Эксперимент успешен — повышение до active_version
   ├── Эксперимент неуспешен — retired
      ↓
Полный rollout как active_version
      ↓
Через N циклов (или по триггеру) — retired

Запрет на боевое развёртывание без реестра​

Запрещено: модель разворачивается в боевую среду без регистрации в реестре. Это включает любые «временные» модели и «маленькие эксперименты». Если модель влияет на боевые ответы платформы — она должна быть в реестре.

Подкомпонент 3. Обслуживание моделей (model serving)​

Обслуживание моделей — единый сервис, отвечающий за выполнение инференсов в боевом режиме.

Главные требования​

  • Низкая задержка — типично p95 ниже 50 мс для real-time моделей (ранжирование, обнаружение мошенничества).
  • Высокая параллельная нагрузка — тысячи инференсов в секунду на пиковой нагрузке.
  • Единый интерфейс — все модели вызываются через один каноничный программный интерфейс независимо от рамочного решения (PyTorch / TensorFlow / scikit-learn).
  • Версионирование при сервинге — параллельная работа нескольких версий одной модели для A/B-экспериментов.
  • Деградация под нагрузкой — при перегрузке модели либо возврат предыдущей версии, либо возврат базовой эвристики (см. Поиск и обнаружение, правило стабильности ранжирования).

Режимы инференса​

  • Real-time — синхронный вызов вызывающего сервиса. Применяется для ранжирования поиска, обнаружения мошенничества при платеже, прогнозирования конверсии в момент показа.
  • Async batch — пакетный инференс по расписанию. Применяется для прогнозирования отмен, сегментации партнёров, регулярного пересчёта рекомендаций.
  • Stream — инференс на потоке событий. Применяется для обнаружения аномалий в реальном времени.

Запрет локальных серверов моделей​

Каждый сервис, использующий ML, не запускает собственный сервер модели. Все инференсы идут через единый сервис обслуживания моделей. Это даёт:

  • Единую наблюдаемость моделей.
  • Единое управление ресурсами (один общий пул GPU вместо разрозненных).
  • Единое версионирование и эксперименты.
  • Минимальный blast-радиус (ошибка в одной модели не ломает другие сервисы).

Подкомпонент 4. Наблюдаемость моделей (model monitoring)​

Наблюдаемость моделей — система метрик и алертов для качества моделей в боевом режиме.

Метрики мониторинга​

  • Дрейф входных признаков (input feature drift) — изменение распределения входных признаков. Если распределение в боевом режиме сильно отличается от обучающего, модель работает не так, как ожидалось.
  • Дрейф целевой метрики (target drift) — изменение фактической ценности предсказания. Если конверсия из ранжирования падает, модель деградирует.
  • Latency и throughput — задержка и пропускная способность инференса.
  • Error rate — доля неуспешных вызовов модели.
  • Calibration — соответствие предсказанных вероятностей фактическим (для классификации).
  • Бизнес-метрики — конкретные показатели применения (для ранжирования — конверсия в коммерческую фиксацию; для обнаружения мошенничества — доля предотвращённых возвратных платежей).

Триггеры переобучения​

При обнаружении деградации:

  • Предупреждение в контур наблюдаемости.
  • Автоматический триггер обучающего прогона с новыми данными.
  • Эскалация к команде ML при значимой деградации.

См. Наблюдаемость и реагирование на инциденты для общего контура.

Прозрачность для регуляторов​

По Закону о цифровых услугах (Digital Services Act) платформы обязаны прозрачно описывать рекомендательные системы. Наблюдаемость моделей даёт основу для такого описания:

  • Какие признаки использует модель.
  • Как часто переобучается.
  • Какие метрики отслеживает.
  • Какие меры защиты от bias применяются.

Подробности — в Соответствие требованиям регуляторов.

Каталог применений ML​

ПрименениеОписаниеТип задачиФаза реализации
Ранжирование поиска (search ranking)ML-ранжировщик в поиске поверх эвристикrankingФаза 3
Обнаружение мошенничества и анализ риска платежаПрогнозирование вероятности возвратного платежа и мошеннической транзакцииbinary_classificationФаза 3
Динамическое ценообразование платформыПрогнозирование оптимальных тарифных параметров для динамической тарификации платформенных услугregressionФаза 3+
Прогнозирование отменВероятность отмены бронирования для оптимизации удержанияbinary_classificationФаза 3
Рекомендации туров (Tour Recommendation)Подбор шаблонов туров и компонентов для конструктора туровranking, embeddingФаза 3+
Аномалии здоровья поставщика (supplier health anomaly)Обнаружение деградации поставщика по операционным метрикамanomaly_detectionФаза 2+
Прогноз конверсии коммерческой фиксации (quote-to-booking)Вероятность того, что коммерческая фиксация превратится в бронированиеbinary_classificationФаза 3
Сегментация партнёров (partner segmentation)Кластеризация партнёров по поведению для индивидуальной поддержкиclusteringФаза 3+
Распознавание контекста гео-запросаПарсинг текстового гео-запроса в каноничную геомодельNER + classificationФаза 3
Кросс-язычные эмбеддингиМногоязычный поиск через семантические векторыembeddingФаза 3+
Conversational-помощник для разработчиковLLM-помощник для партнёров в портале разработчиковLLM-basedФаза 4
Conversational-поиск для конечных клиентовLLM-интерфейс поиска на vitrip.storeLLM-basedФаза 4

Не все применения реализуются одновременно. Приоритет — по бизнес-ценности и операционной готовности.

Цикл MLOps (DevOps для ML)​

[Данные]
   ↓
Feature engineering (регистрация в Feature store)
   ↓
Training run (обучение модели)
   ↓
Evaluation (оценка качества на отложенных данных)
   ↓
Model registration в реестре (версия)
   ↓
Approval workflow (ревью, подпись)
   ↓
Shadow mode (опционально)
   ↓
A/B experiment vs текущая активная версия
   ↓
   ├── Treatment лучше — Promote to active
   ├── Treatment хуже — Retire
   ↓
Production serving
   ↓
Monitoring (drift detection, бизнес-метрики)
   ↓
   ├── Деградация — auto-retrain trigger
   └── Schedule retrain — periodic
   ↓
Возврат на Training run

Стандартизованная разработка моделей​

  • Шаблоны проектов модели — стандартный layout (структура каталогов, обязательные файлы) для каждого нового модельного проекта.
  • Контрактные тесты для признаков — каждый признак имеет тесты на корректность вычисления.
  • Reproducibility (воспроизводимость) — каждый обучающий прогон фиксирует: версию данных, версию признаков, гиперпараметры, версию рамочного решения. Можно повторить точно.
  • Continuous training pipelines — автоматизация обучения по расписанию или по триггеру. Не «руками раз в N месяцев».

Запрет «sandbox-моделей в production»​

Запрещено: разработчик пишет модель локально (Jupyter notebook), сохраняет файл, развёртывает в production. Каждая боевая модель проходит полный цикл MLOps — обучение через пайплайн, регистрация, ревью, A/B.

Privacy-preserving ML​

Главное правило​

Модели обучаются на анонимизированных данных платформы данных (см. Платформа данных и захват событий, раздел про анонимизацию). Прямой доступ моделей к необработанным персональным данным запрещён архитектурно.

Защитные подходы​

Federated learning (федеративное обучение)​

В фазе 4 для сценариев, где данные не должны покидать локального хранилища (например, для крупных корпоративных партнёров с требованиями локальности данных) — рассматривается федеративное обучение: модель обучается на распределённых данных без их централизации.

Differential privacy (дифференциальная приватность)​

Для агрегированных моделей рассматривается дифференциальная приватность: добавление контролируемого шума в обучение, гарантирующее, что наличие или отсутствие конкретного индивидуума в обучающих данных не влияет на модель значимо.

k-анонимизация для агрегационных признаков​

Признаки на уровне агрегатов (например, статистика по тенанту) — к-анонимизированы по правилам Платформа данных и захват событий.

Запрет на запоминание тренировочных данных (memorization)​

Большие модели (LLM-based для conversational интерфейсов) рискуют запомнить персональные данные из обучающих данных. Применяются меры:

  • Фильтрация обучающих данных от PII.
  • Тестирование модели на запоминание (memorization probing) перед боевым развёртыванием.
  • Регулярная переобучение со свежими отфильтрованными данными.

Прозрачность для регулятора​

Каждая боевая модель имеет карточку модели (model card) — документ, описывающий:

  • Цель применения.
  • Источники данных и методы сбора.
  • Меры защиты приватности.
  • Известные ограничения и biases.
  • Метрики качества и справедливости.
  • Контактное лицо для вопросов от регулятора.

Карточки моделей публикуются для команды compliance и доступны регулятору при запросе.

События ML-платформы​

ML-платформа публикует следующие каноничные события:

СобытиеКогдаГлавные потребители
ml.feature.registeredРегистрация нового признака в Feature storeКонтур аудита, контур документации
ml.feature.deprecatedПризнак помечен как устаревшийКоманды-владельцы зависимых моделей
ml.training.run.startedСтарт обучающего прогонаКонтур наблюдаемости, контур учёта расходов
ml.training.run.completedЗавершение обучающего прогонаРеестр моделей, оценочный пайплайн
ml.model.registeredРегистрация новой версии моделиРеестр, команда ML, владельцы применения
ml.model.approvedОдобрение версии для развёртыванияСервис обслуживания моделей
ml.model.deployedРазвёртывание версии в боевую средуКонтур наблюдаемости
ml.model.retiredПеревод версии в архивКонтур ауди
ml.experiment.startedСтарт экспериментаКонтур экспериментов, наблюдаемость
ml.experiment.concludedЗавершение эксперимента с выводомКоманда ML, реестр
ml.inference.degradationОбнаружение деградации модели в боевом режимеКонтур наблюдаемости, оперативная команда
ml.feature.drift.detectedОбнаружение дрейфа входных признаковКоманда-владелец признака, инженер MLOps

Полная таксономия — в Первоначальная таксономия событий.

Технологический выбор по фазам​

ФазаFeature storeModel registryModel servingMonitoring
Bootstrap(нет — простые SQL-запросы для прототипа)(нет — артефакты в Object Storage с metadata)(нет — простые HTTP-эндпоинты)(нет — базовые метрики в Grafana)
2 (Production)Feast self-hosted (open-source baseline)MLflow open-source (стандарт индустрии)TorchServe / Triton Inference Server для критичных, sklearn-server для простыхWhylabs / Evidently AI / собственное на Grafana
3 (ML scale)Расширенный Feast + online store на Redis clusterMLflow с интеграцией в Tecton (опционально, build vs buy)Triton с GPU поддержкой; собственный inference gatewayРасширенный stack с auto-retraining триггерами
4 (Multi-region)Multi-region feature store с локальностью данныхMulti-region реестрMulti-region inference gateway с маршрутизацией по близостиFederated monitoring

Конкретный выбор технологий — открытая развилка (Развилка 2 «Build vs Buy для ML platform» из оси данных и интеллекта). Эскалируется при выходе с Bootstrap в фазу 2.

Учёт расходов на ML​

ML-платформа — дорогой компонент (GPU, обучение моделей, хранение features). Учёт расходов:

  • Tенантная атрибуция — каждое применение ML привязано к источнику запроса (тенант + поверхность). Это позволяет отнести часть стоимости в тариф потребления (см. Учёт потребления и квоты, метрика «вызовы ML-инференса»).
  • Бюджеты на обучение — каждое применение имеет квоту на месячные расходы обучения. Превышение требует одобрения.
  • Эффективность модели — отслеживается отношение «бизнес-польза от модели / расходы на модель». Модели с низкой эффективностью отправляются на пересмотр.

Stage 1 minimum — обязательные данные с нулевого дня​

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором отмечен риск: «ML-платформа описана как first-class, но в Stage 1-2 фактически отсутствует — есть риск накопить данные в DWH в формате, который потом потребует мучительного re-engineering для обучения моделей».

Раздел фиксирует минимально обязательный контракт данных, которые должны накапливаться платформой с нулевого дня (Stage 1), чтобы при включении ML-платформы на Stage 2-3 не пришлось переписывать collectors, переиндексировать DWH или восстанавливать историю по фрагментарным данным.

Принцип​

«Накапливай данные в правильной схеме, даже если ещё не используешь.»

В Stage 1 нет ML-платформы как working component — нет feature store, нет model registry, нет inference service. Но есть обязательство собирать данные так, чтобы будущие ML-модели смогли обучиться на исторических данных без переинженеринга.

Каталог планируемых MVP-моделей​

Для каждой модели зафиксирован минимальный набор полей и событий который должен начать накапливаться в Stage 1.

Модель 1: Search ranking (ранжирование результатов поиска)​

Stage активации: 3.

Назначение: упорядочивать результаты поиска по probability of conversion для конкретного user/tenant context.

Stage 1 minimum data:

  • Search events (search.requested, search.results_shown):
    • search_id, tenant_id, hashed user_id, generalized geo (country + region, не city).
    • Search query: destination, dates, party_size, filters[].
    • Returned results: ordered list of property_id с position.
    • Search context: timestamp, session_id (hashed), referrer surface.
  • Click events (search.result_clicked):
    • search_id (для join'а), property_id, position.
    • Time to click (от показа до клика).
  • Conversion events (booking.committed):
    • search_id (linkage от search до booking — ключевой для training!).
    • property_id.
    • Booking value, currency, lead_time (дни от search до checkin).

Критично: search_id → booking_id linkage обязателен с Stage 1. Без него ranking models не смогут обучиться на conversion signal. Это самая дорогая часть data, поскольку требует cross-session correlation.

Модель 2: Dynamic pricing (динамическое ценообразование платформенных услуг)​

Stage активации: 4.

Назначение: оптимизировать платформенные ставки и квоты в зависимости от utilization, supplier load, partner tier elasticity.

Stage 1 minimum data:

  • Usage events для каждого платного объекта (search, quote, booking, supplier-call):
    • tenant_id, surface_id, timestamp.
    • Объект потребления: event_type (search_executed, quote_generated, booking_committed, supplier_called).
    • Cost-attribution: какие internal resources были потреблены (compute time, supplier bandwidth, ML inference if applied).
  • Pricing events (tenant.tariff_applied):
    • При начислении: tariff_id, applied_rate, total_charge, breakdown.
  • Partner outcome events:
    • partner.churned, partner.upgraded_tier, partner.downgraded_tier — для elasticity learning.

Критично: все usage events должны быть explicit и structured с Stage 1, не «выжимаемыми» из логов post-factum. Лог-парсинг не годится для обучения price-elasticity моделей.

Модель 3: Fraud detection (платежи и контентные злоупотребления)​

Stage активации: 3.

Назначение: обнаруживать fraudulent транзакции и аномалии партнёрского поведения.

Stage 1 minimum data:

  • Payment events с обогащёнными context-полями:
    • payment_intent_id, tenant_id, hashed user_id.
    • Payment method type (без полной PII): card_brand, card_country, bin_first6.
    • Geo context: hashed IP geo (country + region), generalized device fingerprint.
    • Velocity context: count of attempts in last N minutes за этим tenant/user.
  • Booking events с anomaly fields:
    • Lead-time (короткий lead-time + высокая стоимость = signal).
    • Multi-payment splitting attempts.
    • Refund-after-checkin signals.
  • Account behaviour events:
    • Login patterns, scope-elevation requests, key rotation events.

Критично: geo и device fingerprint должны собираться с consent и в anonymized виде с Stage 1. После Stage 1 добавлять anonymization сложно — у вас уже есть raw history.

Модель 4: Recommendation (для B2C-витрины)​

Stage активации: 3.

Назначение: рекомендовать relevant property/destinations конкретному user'у.

Stage 1 minimum data:

  • Browse events (browse.property_viewed, browse.destination_explored):
    • hashed user_id, property_id или destination_id, dwell_time.
    • Surface (B2C / agency / partner).
  • Engagement events: shares, saves, wishlists.
  • Demographic features (с consent + anonymized): age band, language, currency preference.
  • Trip history features:
    • Past bookings: destinations, durations, party_sizes, price ranges.

Критично: event de-duplication между surfaces должна быть продумана с Stage 1: один и тот же user может browser'ить через B2C-сайт и через partner UI; recommendation должен видеть unified history.

Модель 5: Demand forecasting (прогноз спроса)​

Stage активации: 4.

Назначение: прогнозировать spike'и спроса на конкретные destination'ы для capacity planning, inventory negotiation с supplier'ами, partner-level alerts.

Stage 1 minimum data:

  • Search aggregates по destination и date:
    • Daily search counts по (destination_id, checkin_date, party_size_band).
    • Distribution of search lead-times.
  • Booking aggregates:
    • Daily booking counts с теми же ключами.
    • Conversion rates search→booking.
  • External signals (для cross-correlation):
    • Public holiday calendars by region.
    • Major events (festivals, conferences) — если есть calendar source.
  • Pricing aggregates:
    • Median price per night by (destination_id, date, property_class).

Критично: aggregations должны храниться в structured forms с Stage 1 — не должно быть нужно reconstructing из raw events post-factum (это создаст ML training delay в 6-12 месяцев на Stage 4).

Каноничные требования к event schema (Stage 1)​

Чтобы накопленные данные были usable для ML training, каждое событие должно соответствовать минимуму:

  1. Schema versioning. Каждое событие имеет явное schema_version поле; breaking changes увеличивают major version.
  2. Stable identifiers. tenant_id, user_id, property_id, booking_id — стабильные UUID, не auto-increment integer'ы (защита от кражи последовательностей и shard rebalancing'а).
  3. Hashed personal data. Все user-связанные идентификаторы хешируются (HMAC-SHA256 с rotating key); raw email/phone никогда не попадают в analytics events.
  4. Generalized geo. Geo до уровня country+region, не city и не lat/lng (за исключением когда city — критичный feature, тогда — отдельный consent).
  5. ISO datetime. Все timestamps в ISO 8601 с TZ; никаких local timestamps.
  6. Currency normalization. Все money fields имеют explicit currency_code; никаких unmarked numbers.
  7. Cross-event linkage. Ключевые цепочки (search → click → quote → booking → payment) обязательно линкуются через persistent IDs.
  8. No PII in event payloads. Имена, адреса, paspport numbers — никогда не в analytics events. Если нужно — отдельный stream с тру PCI/GDPR controls.

Обязательные feature naming conventions (Stage 1)​

Чтобы при появлении Feature store на Stage 2 фичи не пришлось переименовывать:

  • Все feature names в snake_case.
  • Префикс по entity: user_*, property_*, tenant_*, partner_*, booking_*.
  • Time windows в имени: _last7d, _last30d, _last90d, _lifetime.
  • Aggregation type: _count, _sum, _avg, _median, _max, _min, _last.
  • Examples: user_booking_count_last30d, property_avg_rating_last90d, tenant_search_volume_last7d, booking_lead_time_days.

Этот naming должен быть зашит в DWH схемы с Stage 1, чтобы Feature store on Stage 2 building имел consistent naming уже в источниках.

DWH partitioning для будущего ML​

Партиционирование DWH таблиц с Stage 1:

  • Time-based: дневные partitions для events, помесячные для aggregates.
  • Tenant-based (для multi-tenant isolation + parallel ML training): partitioning by tenant_id для feature tables.
  • Date+entity composite key: ускоряет point-in-time training joins (типичный ML pattern).

Без этого partitioning Stage 3 ML training будет требовать full-table scans — что физически невозможно для больших объёмов.

Что НЕ нужно делать в Stage 1​

Чтобы избежать over-engineering и ложного чувства готовности:

  • Не разворачивать Feature store (Feast) — на Stage 1 нет нужды, добавляет сложность.
  • Не делать model registry (MLflow) — нет моделей для регистрации.
  • Не делать online feature serving — нет real-time inference.
  • Не строить ML pipelines — нет training pipelines для построения.

Что нужно делать: накапливать data в правильной структуре, следовать каноничной schema, поддерживать data quality — это инвестиция, окупающаяся через 12-18 месяцев когда ML-платформа активируется.

Метрики готовности к Stage 2​

Перед активацией ML-платформы на Stage 2 проверяется готовность данных:

  • Schema compliance rate > 99% — все events соответствуют declared schemas.
  • Event linkage completeness > 95% — search → booking journey можно проследить для ≥95% bookings.
  • PII leak rate = 0% — нет raw PII в analytics events (audit log).
  • Feature naming conformance > 98% — feature names follow conventions.
  • DWH partition coverage = 100% — все expected partitions присутствуют.
  • Historical depth ≥ 6 месяцев — для baseline моделей нужно минимум 6 мес. данных.

Если эти метрики не достигнуты — Stage 2 ML activation откладывается до их достижения. Это правило защищает от запуска ML на «гнилой» истории.

Обоснование (тезисы)​

Тезис 1. Schema-aware accumulation с Stage 1 предотвращает re-engineering на Stage 3.

Альтернативы: (а) накапливать данные в произвольной форме, реструктурировать перед ML-активацией; (б) изначально структурированный сбор по будущей ML schema.

Trade-off: вариант (а) требует data migration больших объёмов, вынужденного backfill'а отсутствующих полей (часто невозможного), задержки ML на 6-12 месяцев; вариант (б) — каноничный, инвестиция в правильную инженерную дисциплину сразу.

Тезис 2. Cross-event linkage (search_id → booking_id) — самая критичная часть Stage 1 data.

Альтернативы: (а) собирать события каждого слоя независимо; (б) обеспечить explicit linkage через persistent IDs.

Trade-off: вариант (а) делает невозможным conversion-based training; вариант (б) — каноничный, ключевой для search ranking, recommendation, demand forecasting.

Тезис 3. Privacy-aware data collection (hashed IDs, generalized geo) обязательна с Stage 1.

Альтернативы: (а) собирать raw данные сейчас, anonymize позже; (б) anonymize на point of capture с Stage 1.

Trade-off: вариант (а) создаёт regulatory exposure (GDPR violation), невозможность retroactive anonymization (raw данные уже в backups), репутационный риск; вариант (б) — каноничный для GDPR-by-design подхода.

Фазы развёртывания ML-платформы​

Фаза Bootstrap (0–6 месяцев)​

Что разворачивается:

  • Каноничная модель (MlFeature, MlModel, MlModelVersion, MlTrainingRun, MlInferenceRequest, MlExperiment) зафиксирована.
  • Базовая аналитика без ML (на SQL и эвристиках).
  • Прототипы признаков на отдельном песочничном проекте без формального Feature store.

Триггер выхода:

  • Готовность к запуску первого боевого применения ML (типично — anomaly detection для здоровья поставщика).

Фаза 2 — Базовая ML-инфраструктура (6–18 месяцев)​

Что разворачивается:

  • Feast self-hosted как Feature store.
  • MLflow self-hosted как реестр моделей.
  • Простой сервис обслуживания моделей (sklearn-server для классификации/регрессии).
  • Базовый мониторинг моделей с Grafana дашбордами.
  • Первое боевое применение — обнаружение аномалий здоровья поставщика.
  • Первое экспериментальное применение — A/B-тестирование между эвристикой и простым ML-классификатором.

Триггер выхода:

  • Готовность к боевому ML-ранжированию поиска и обнаружению мошенничества в платежах.

Фаза 3 — ML-зрелость (18–30 месяцев)​

Что разворачивается:

  • Online store на Redis cluster для real-time сервинга.
  • Triton Inference Server для нейросетевых моделей.
  • ML-ранжирование поиска как боевое применение.
  • Обнаружение мошенничества в платежах.
  • Прогнозирование отмен.
  • Карточки моделей и compliance-отчётность.
  • Continuous training pipelines с автотриггерами.

Триггер выхода:

  • Появление крупных корпоративных партнёров с требованиями локальности данных или privacy-preserving подходов.

Фаза 4 — Расширенная ML и privacy (30+ месяцев)​

Что разворачивается:

  • Federated learning для крупных партнёров (опционально, по запросу).
  • Differential privacy для общих моделей.
  • LLM-based conversational интерфейсы (партнёрский помощник, B2C-поиск).
  • Multi-region inference gateway.
  • ML-driven dynamic platform pricing с автоматической оптимизацией.

Архитектурные решения с тезисным обоснованием​

Решение 1. Единая ML-платформа для всех применений​

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

Тезисы:

  1. Без единой платформы каждая команда строит локальные пайплайны, дублируя работу. Признаки actor_session.click_through_rate появляются в 5 местах с разной семантикой.
  2. Согласованность обучения и сервинга — критическое свойство ML, обеспечиваемое только централизованным Feature store. Распределённое решение не работает.
  3. Современные платформы (Uber Michelangelo, Airbnb Bighead, Lyft LyftLearn) — все построены на единой ML-платформе. Это база.

Альтернатива: каждая команда строит собственное ML-решение. Отклонено: операционные расходы и фрагментация.

Решение 2. Согласованность обучения и сервинга — архитектурная гарантия​

Цель: исключить класс ошибок, когда модель работает в обучении, но деградирует в боевом режиме из-за несоответствия признаков.

Тезисы:

  1. Это самая частая причина деградации ML-моделей в индустрии. Известная как «training-serving skew».
  2. Архитектурное решение (Feature store с двумя режимами хранения) — единственный надёжный способ избежать.
  3. Процессы и code review не работают на масштабе многих моделей.

Решение 3. Боевая модель = модель в реестре​

Цель: обеспечить аудит, наблюдаемость, версионирование и откат всех боевых моделей.

Тезисы:

  1. Без реестра нет ответственности — никто не знает, какая версия какой модели сейчас работает.
  2. Без реестра нет отката — при деградации невозможно быстро вернуть предыдущую версию.
  3. Без реестра нет compliance — регулятор требует прозрачности рекомендательных систем (Закон о цифровых услугах).

Решение 4. Single inference gateway, не локальные сервисы​

Цель: обеспечить единую наблюдаемость, единое управление ресурсами, минимальный blast-радиус.

Тезисы:

  1. Распределённые серверы моделей создают операционный кошмар — каждая команда отвечает за свой uptime, свои GPU.
  2. Единый шлюз позволяет шерить пул GPU между моделями (один GPU обрабатывает несколько моделей в очереди).
  3. Ошибка в одной модели через локальный сервер может уронить вызывающий сервис. Через шлюз — только инференсы этой модели.

Решение 5. Каждое применение ML имеет fallback к базовой логике​

Цель: обеспечить устойчивость платформы при отказе ML-моделей.

Тезисы:

  1. ML-модели иногда падают, деградируют, возвращают аномальные результаты. Платформа должна продолжать работать.
  2. Fallback к эвристическому ранжированию в поиске уже зафиксирован в Поиск и обнаружение. Тот же подход во всех применениях.
  3. Без fallback одна неисправность ML-сервера ломает критический поток платформы.

Открытые развилки​

Развилка 1. Build vs Buy для Feature store​

Feast (open-source self-hosted) vs Tecton (commercial managed). Tecton дороже, но имеет расширенный набор возможностей и снимает операционные расходы. Feast — стандарт open-source, но требует команды.

Эскалируется: при выходе из фазы Bootstrap в фазу 2.

Развилка 2. Inference gateway — собственный или сторонний​

Triton Inference Server (NVIDIA, open-source) — стандарт для нейросетевых моделей с GPU. Альтернатива — собственный gateway с маршрутизацией к специализированным серверам по типу модели.

Эскалируется: при подходе к фазе 3 (ML-ранжирование поиска).

Развилка 3. Privacy-preserving подходы — приоритет​

Federated learning, differential privacy — какой подход в приоритете. Зависит от регуляторных и партнёрских требований.

Эскалируется: при появлении крупных корпоративных партнёров с требованиями.

Развилка 4. LLM-стратегия — собственная или сторонняя​

LLM-based applications (conversational) могут использовать сторонние модели (OpenAI, Anthropic) либо открытые (Llama, Mistral) с дообучением. Выбор имеет существенные коммерческие, регуляторные и приватностные следствия.

Эскалируется: при создании conversational интерфейсов в фазе 4.

Развилка 5. Continuous training — granularity автотриггеров​

Как часто и при каких триггерах автоматически переобучать модели. Слишком часто — расходы; слишком редко — деградация.

Эскалируется: при первом боевом применении ML с continuous training (фаза 3).

Связанная документация​

Корневые архитектурные документы​

Связанные доменные документы​

Документы развития​

Операционная сторона​

Архитектурные правила​

Уточнение под Фазы 5–6 (28.04.2026) — связь с saga, state machine, isolation, security​

Документ опубликован 26.04.2026 в Фазе 4. После Фаз 5–6 ML-платформа имеет дополнительные требования и интеграции, которые должны быть зафиксированы.

Связь со статусной машиной бронирования​

reference/booking-state-machine.md (Фаза 5) — 14 каноничных состояний. ML-фичи на основе booking lifecycle:

  • unknown_external_state rate per supplier — вход для модели supplier health prediction;
  • time-in-state distribution per state — feature для anomaly detection (например, аномально длинный pending_supplier_confirmation);
  • state transition graph per booking — feature для fraud detection (нетипичные переходы);
  • partial_confirmed → cancelled rate per supplier — для supplier risk scoring.

Все эти features живут в feature store с consistency между training и serving (см. компонент Feature Store этого документа).

Связь с saga Tour Builder​

reference/tour-builder-operational-model.md (Фаза 5) генерирует saga events. ML use cases:

  • DriftEvent rate per supplier per composition rule — для compatibility scoring модели;
  • Compensation frequency per saga template — для saga policy optimization;
  • Time-to-publish для proposals — для UX optimization модели;
  • Tour Builder compatibility scoring (упомянуто в data-and-intelligence-spine.md как фаза 3 use case) — модель over saga events.

Tour Builder ML use cases требуют saga-aware feature engineering: saga events должны попадать в feature store с правильными temporal boundaries.

Связь с уровнями тенантной изоляции​

reference/multi-tenant-isolation-strength.md (Фаза 5) определяет 3 уровня. Влияние на ML:

Training data isolation:

  • logical tenants — модели training может использовать pooled data от множества tenants (cross-tenant aggregation), но с k-anonymization (k≥10);
  • dedicated_compute — модели обучаются на pooled data, но inference per-tenant;
  • dedicated_infrastructure (Enterprise) — может потребовать tenant-specific модели обученные только на данных этого tenant (no cross-tenant pooling). Это влияет на cost (отдельный training pipeline per tenant) и качество (меньше данных).

Inference isolation:

  • modelos serving обязательно tenant-aware (не leak prediction между tenants);
  • prediction logging изолирован per tenant (не доступен другим);
  • model performance metrics — per-tenant breakdown с k-anonymization.

Privacy-preserving ML (упомянутая развилка в data-and-intelligence-spine.md) — для расширенных cross-tenant features:

  • differential privacy для training datasets;
  • federated learning для tenants с регуляторными требованиями;
  • homomorphic encryption — фаза 6 рассмотрение.

Связь со security architecture​

reference/security-architecture.md (Фаза 10) определяет threat model. ML-specific угрозы:

  • Model poisoning — атакующий вводит malicious training data → корректное feature validation, anomaly detection в training pipeline;
  • Training data leakage — модели запоминают PII → privacy review каждой модели до deployment;
  • Inference abuse — массовые inference запросы для extraction model behavior → rate limiting, anomaly detection;
  • Model inversion attacks — извлечение training data через carefully crafted queries → output sanitization.

Каждая модель проходит security review перед production deployment (часть model registry approval process).

Связь со SLA-моделью​

operations/sla-and-on-call-model.md (Фаза 6) — модель ML serving имеет свой SLA:

  • inference latency p95 (обычно строже основных API — например, для search ranking менее 100мс);
  • inference availability — best-effort для Free tier, 99% для Professional+, 99.9% для Enterprise;
  • model freshness — гарантия retraining cadence (например, daily для search ranking, weekly для recommendation).

Графит ML SLA отдельно от Partner API SLA (ML — internal capability, не contract surface), но влияет на partner-visible SLA через downstream impact.

Связь с DR и capacity​

operations/disaster-recovery-and-capacity.md (Фаза 6) — ML serving требует:

  • Tier 2 backup для feature store (RTO 4ч, RPO 30мин);
  • Tier 3 backup для model registry (RTO 24ч, RPO 1ч — модели можно retrain);
  • Tier 3 backup для prediction log (analytics, не transactional);
  • Capacity forecasting для GPU pools (Phase 3+) — separate cost driver;
  • DR drills для ML serving — фаза 4+.

Связь с experimentation framework​

reference/ab-testing-platform.md (Фаза 4) — ML модели A/B testing:

  • shadow deployment (новая модель работает параллельно, не влияет на production decisions);
  • canary deployment (% traffic на новую модель);
  • multi-armed bandit для optimization (где applicable);
  • guardrail metrics для предотвращения регрессий.

ML model deployment обязательно проходит через A/B testing для critical use cases (search ranking, dynamic pricing, recommendation).

Связь с compliance​

reference/compliance-and-legal.md (Фаза 4) — GDPR требования к automated decision-making:

  • Right not to be subject to automated decision-making — opt-out пользователя из ML-driven personalization, ranking, pricing;
  • Explainability requirement — для решений со significant effect (например, отказ в кредитной линии для партнёра) — обязательное объяснение decision basis;
  • Privacy Impact Assessment для high-risk ML use cases (large-scale profiling, automated decisions).

Каждая ML use case проходит compliance review (см. compliance-and-legal.md, Процесс 1. Privacy review).

Каноничный итог уточнения​

ML-платформа теперь интегрирована со всеми операционными доменами:

  • Features опираются на caноничные state transitions (booking-state-machine, tour saga);
  • Training data учитывает уровни tenant isolation (cross-tenant pooling vs tenant-specific);
  • Models проходят security и privacy review;
  • Serving имеет свои SLA и DR обязательства;
  • Deployment через A/B testing с guardrail metrics;
  • Compliance — opt-out, explainability, PIA.

Уточнение выполнено через no-destruction.