Обзор Ось 4 — Данные и интеллект (резюме простыми словами)

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

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

Этот документ — резюме четвёртой архитектурной оси платформы для непрофильного читателя. Он не заменяет каноничный документ Ось данных и интеллекта (ось 4), а служит коротким и понятным введением для тех, кто не работает с архитектурой каждый день: руководителей, новых членов команды, внешних консультантов, партнёров на этапе знакомства.

Цель резюме — чтобы любой грамотный читатель за 10–15 минут понял, как платформа собирает данные, где их хранит, как ими пользуется для аналитики и машинного обучения, и почему всю эту инфраструктуру нужно закладывать с самого начала, а не «потом».

О чём документ

Документ описывает четвёртую из шести архитектурных осей платформы — ось данных и интеллекта. Простыми словами: это «нервная система платформы». Каждое значимое действие в платформе (пользователь нашёл предложение, агент создал коммерческую фиксацию, партнёр забронировал тур, поставщик вернул аномальные данные) превращается в событие. Эти события движутся по платформе, накапливаются в хранилище данных, превращаются в аналитику, питают модели машинного обучения и тестируемые гипотезы.

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

Главный тезис

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

Из этого следует:

• события — первоисточник данных платформы, а не побочный продукт работы;
• хранилище данных — отдельный класс хранилища от боевой и транзакционной баз;
• информационные конвейеры (extract-transform-load, потоковые) — первоклассная инфраструктура, а не пакетные задания «на ночь»;
• платформа машинного обучения — стандартизированная инфраструктура с витриной признаков, реестром моделей, системой выдачи предсказаний, мониторингом моделей;
• A/B-тестирование — каркас, а не разовые эксперименты в коде.

Пять компонентов оси

Компонент 1. Захват событий

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

Доменные события

Отражают изменения в каноничной модели платформы — «что-то случилось внутри платформы».

Примеры: «бронирование подтверждено», «коммерческая фиксация создана», «предложение опубликовано», «объект размещения обновлён», «решение о маппинге применено», «событие взаиморасчётов проведено», «кейс модерации создан».

Источник: каноничные сущности (см. резюме Оси 1).

Транспорт: шина сообщений (event bus, Kafka).

Потребители: другие сервисы платформы между собой, доставка webhook'ов партнёрам, аналитические конвейеры.

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

Аналитические события

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

Примеры: «выполнен поиск», «по результату поиска кликнули», «предложение просмотрено», «шаг воронки бронирования», «пользователь зарегистрировался», «сессия началась», «страница загружена».

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

Транспорт: отдельный конвейер (сборщик событий → очередь сообщений → хранилище данных).

Потребители: хранилище данных, инженерия признаков для машинного обучения, каркас A/B-тестирования, партнёрская аналитика.

Роль: работают как наблюдательный материал, не источник истины.

Принципы захвата событий

• Со схемой — каждое событие имеет явную схему.
• С версиями — схемы событий версионируются с явной политикой совместимости.
• Под управлением — изменения схем проходят ревью и не ломают потребителей.
• С границей приватности — персональные данные минимизируются в событиях; для требуемых случаев — анонимизация на уровне захвата.
• С изоляцией тенантов — события несут контекст тенанта; объединение данных нескольких тенантов возможно только через явные правила агрегации.

Компонент 2. Хранилище данных (data warehouse)

Главный принцип: отдельный класс хранилища от боевого и транзакционного слоёв. Разные обещания доступности, разная политика хранения, разные границы приватности, разные запросы.

Что хранится в хранилище данных

• Все аналитические события в форме «только дописывание» (журнал событий).
• Материализованные представления — заранее посчитанные сводки для типовых запросов (объём бронирований за день, воронка конверсии, разбивка по поставщикам, потребление партнёра).
• Снимки каноничных сущностей — периодические слепки для исторических запросов («какие туры были опубликованы 6 месяцев назад»).
• Витрина признаков для машинного обучения — признаки, выведенные из событий и каноничных сущностей, для использования в обучении и выдаче предсказаний.
• Данные экспериментов — данные A/B-экспериментов: распределение по когортам, события показа, метрики конверсии.

Что не хранится в хранилище данных

• Сырая транзакционная истина (бронирования) — это транзакционный слой, отдельный класс.
• Сырые нагрузки от поставщиков — это слой следов поставщиков, отдельный класс.
• Операционные кеши и проекции — пересчитываемый слой кеша.
• Чувствительные персональные данные в неанонимизированной форме (только если есть законное основание).

Принцип приватности по дизайну

Хранилище данных проектируется с принципом приватности по дизайну (privacy by design):

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

Компонент 3. Информационные конвейеры

Двухпутевой подход: реальное время плюс пакетная обработка.

Реальное время (потоковый конвейер)

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

Пакетная обработка

• источник: захват изменений из транзакционного слоя плюс журнал событий из хранилища данных;
• обработка: пакетные задания, запускающиеся периодически (час, день);
• назначение: тяжёлые сводки, инженерия признаков для машинного обучения, подготовка обучающих данных, отчёты бизнес-аналитики.

Повторное воспроизведение как первоклассная возможность

Платформа обязана уметь повторно воспроизводить события для:

• изменения логики обработки (например, новая нормализация с учётом новых полей);
• восстановления после инцидентов;
• перерасчёта признаков машинного обучения при изменении схемы;
• восполнения данных при подключении новых конвейеров.

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

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

Стандартизированная инфраструктура с четырьмя главными компонентами.

4.1. Витрина признаков (feature store)

• хранит признаки (входы для моделей) с согласованностью между обучением и выдачей предсказаний;
• поддерживает офлайн-признаки (для обучения) и онлайн-признаки (для инференса);
• признаки могут быть потоковыми (рассчитываются в реальном времени) и пакетными (рассчитываются периодически);
• версионирование признаков — изменение признака не ломает существующие модели.

4.2. Реестр моделей (model registry)

• хранит обученные модели с версионированием;
• метаданные модели: данные обучения, гиперпараметры, метрики, дата обучения, ответственный специалист;
• модели проходят процесс одобрения перед боевым внедрением;
• откат к предыдущей версии модели — операционная процедура.

4.3. Выдача предсказаний (model serving)

• инфраструктура для боевых моделей;
• онлайн-инференс для случаев реального времени (ранжирование поиска, динамическое ценообразование, рекомендации);
• пакетный инференс для периодических случаев (обнаружение аномалий, оценка риска партнёра);
• параллельный показ нескольких версий модели (A/B exposure).

4.4. Мониторинг моделей (model monitoring)

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

Где машинное обучение применяется

Не все случаи применения реализуются сразу — многие в фазе 3+:

Случай применения	Описание	Фаза реализации
Ранжирование поиска	Под намерение пользователя, потенциал конверсии, здоровье поставщика	Фаза 2-3
Рекомендации	Персонализированные рекомендации в результатах поиска, на страницах продуктов	Фаза 3
Динамическое ценообразование	Динамическая цена услуг платформы на основе нагрузки и эластичности	Фаза 3
Обнаружение аномалий в приёме данных	Обнаружение странностей в данных поставщиков (резкое падение цен, странные характеристики объекта)	Фаза 2
Оценка риска партнёра	По поведению (для лимитов клиринга, защиты от мошенничества)	Фаза 3
Оптимизация конверсии	Оптимизация UX через персонализацию	Фаза 3
Обнаружение мошенничества	Мошеннические бронирования	Фаза 3
Модерация контента	Модерация фото и описаний на неприемлемое содержимое	Фаза 2-3
Прогноз спроса	Для планирования мощности, маркетинга	Фаза 4
Совместимость в конструкторе туров	Оценка совместимости компонентов тура	Фаза 3
Прогноз здоровья поставщиков	Предсказание операционных проблем поставщиков	Фаза 3-4

Компонент 5. A/B-тестирование

Главный принцип: эксперимент как первоклассная возможность продукта, а не разовое включение чего-то в коде.

Что включает каркас

• Флаги функций (feature flags) — управление включением и отключением возможностей по когортам.
• Распределение по когортам — детерминированное разделение пользователей по группам. Хеш-распределение с явным определением групп.
• Захват показа (exposure tracking) — события «когорта X увидела вариант Y». Не считается «увидел» пока пользователь не увидел вариант.
• Каркас метрик — основные метрики (главная цель), вторичные метрики, метрики защиты (то, что не должно ухудшиться).
• Статистическая значимость — расчёт значимости результатов, оценка размера выборки, последовательное тестирование.
• Жизненный цикл эксперимента — фазы: проектирование → постепенный запуск → полный показ → анализ → решение (запустить, отменить, итерация).

Применение A/B-тестирования на платформе

• Эксперименты на витрине для клиентов — оптимизация конверсии на vitrip.store.
• Эксперименты ранжирования поиска — сравнение моделей ранжирования.
• Ценовые эксперименты — тестирование вариантов цены для собственных продуктов и тарифов программного интерфейса.
• Эксперименты рекомендаций — сравнение моделей.
• Эксперименты в конструкторе туров — оптимизация рабочего процесса композиции.
• Эксперименты доставки webhook'ов — оптимизация политики повторов.

Многотенантный аспект

• эксперименты могут быть в пределах одного тенанта (только для определённых тенантов) или на всю платформу (для всех);
• эксперименты в пределах тенанта не должны влиять на других тенантов;
• этика и соответствие регуляторам: эксперименты на витринах для клиентов требуют соответствия GDPR (согласие на использование cookie для распределения по когортам).

Архитектура движения данных

Упрощённая схема:

• Доменные события идут через шину сообщений и в реальном времени реплицируются в хранилище данных как журнал на дописывание.
• Аналитические события идут через сборщик событий в то же хранилище.
• Каноничные сущности через захват изменений периодически снимают слепки в хранилище.
• В хранилище данных конвейеры строят материализованные представления и витрину признаков.
• Витрина признаков питает обучение моделей, обученные модели уходят в реестр моделей, оттуда — в выдачу предсказаний.
• Предсказания возвращаются в доменный слой (ранжирование поиска, рекомендации, динамическое ценообразование).
• Каркас A/B-тестирования распределяет пользователей по когортам через флаги функций, показ фиксируется как событие, метрики уходят обратно в хранилище.
• Из хранилища данных идут отчёты бизнес-аналитики (внутренние дашборды + партнёрская аналитика для платных тарифов).

Границы приватности

Главный принцип

Платформа разрабатывается с приватностью по дизайну:

• минимизация персональных данных в событиях (только то, что необходимо);
• анонимизация на уровне захвата;
• хранение с автоматическим удалением;
• журнал аудита каждого доступа к персональным данным;
• явное управление согласием для cookie на витрине для клиентов.

Категории данных по приватности

Категория	Что включает	Обработка
Публичные данные	Содержимое объектов, классификация, география	Без ограничений
Операционные данные	Объёмы поисков, фиксаций, бронирований, метрики задержек	Сводно — публично, сырые — только внутренние
Данные тенанта	Конкретные бронирования конкретного партнёра	Видны только тенанту, между тенантами — только сводно
Персональные данные конечного клиента	Имена, паспорта, контактные данные клиентов	Максимально ограниченный доступ, анонимизация в аналитических событиях, минимально необходимое хранение
Чувствительные данные партнёра	Маржа, коммерческие условия, баланс партнёра	Только внутри платформы и только сам партнёр

Соответствие GDPR

GDPR-соответствие напрямую влияет на эту ось:

• Право на доступ — клиент может запросить все свои данные. Хранилище должно поддерживать запросы по конкретному субъекту.
• Право на удаление — клиент может потребовать удаления. Хранилище должно поддерживать удаление со всеми соответствующими аналитическими событиями.
• Право на переносимость — экспорт данных в стандартном формате.
• Ограничение цели — данные используются только для тех целей, для которых были собраны.
• Минимизация данных — собираем только то, что необходимо.
• Трансграничная передача — для пар Украина–EU, Казахстан–EU необходимы стандартные договорные положения.

Связь с шестью осями архитектуры

• Каноничная доменная ось — все каноничные сущности порождают доменные события, происхождение полей в каноничной модели — основа для мониторинга качества данных, аналитические события наблюдают за поведением вокруг каноничных сущностей, машинное обучение использует признаки, выведенные из каноничных сущностей и событий.
• Поверхности взаимодействия — каждая дверь платформы является источником аналитических событий, самый интенсивный источник — витрина для клиентов, события партнёрского интерфейса используются для динамической тарификации.
• Платформа как продукт — учёт потребления — базовый источник для динамической тарификации (через аналитические события), партнёрская аналитика — часть профессионального и корпоративного тарифов, машинное обучение — основа для динамического ценообразования и премиум-возможностей как расширений, A/B-тестирование — возможность для оптимизации продукта.
• Операционная ось — наблюдаемость пересекается с этой осью (операционные метрики в аналитических конвейерах), обнаружение аномалий в приёме данных — операционный случай применения машинного обучения, предиктивное масштабирование основано на моделях из этой оси.
• Связь с реализацией — карта соответствия с уже работающим кодом существующей реализации.

Связь с реальной реализацией

В уже работающем коде существующей реализации сейчас:

• Имеется первая итерация захвата событий (схема events_themes, выполнено DDL 2026-04-24) — требует разделения на доменные и аналитические события.
• Не реализовано полноценное хранилище данных — текущая боевая база не предназначена для аналитических запросов в продуктивном объёме.
• Не реализована платформа машинного обучения.
• Не реализован каркас A/B-тестирования.

Развёртывание оси по фазам

Фаза 1 (Старт, 0-12 месяцев)

Развёртывается: базовый захват доменных событий через шину сообщений; прототип сборщика аналитических событий (можно через основную базу для начала); базовый дашборд для операционных метрик; скрипты для аналитики по запросу (без полного хранилища); система флагов функций для базовых экспериментов.

Не развёртывается: управляемая шина сообщений, управляемое аналитическое хранилище, платформа машинного обучения, полноценный каркас A/B-тестирования.

Фаза 2 (Изоляция сервисов, 12-24 месяца)

Развёртывается: управляемая шина сообщений как главная; разделение доменных и аналитических событий; управляемый поисковый движок для поисковой проекции; базовое хранилище данных в реплике основной базы (или отдельной); первые случаи применения машинного обучения (обнаружение аномалий в приёме данных, прототип ранжирования поиска); каркас A/B-тестирования в базовой реализации.

Фаза 3 (Специализированная упаковка, 24-36 месяцев)

Развёртывается: управляемое аналитическое хранилище для боевого использования; боевая платформа машинного обучения (обучение, развёртывание, выдача предсказаний); витрина признаков; реестр моделей; инфраструктура выдачи предсказаний; зрелый каркас A/B-тестирования; партнёрская аналитика для профессионального и корпоративного тарифов; потоковый конвейер.

Фаза 4 (Многорегиональная, 36+ месяцев)

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

Открытые вопросы (развилки)

• Технологический выбор хранилища данных. Управляемое аналитическое хранилище у текущего облачного провайдера — текущая рекомендация. Альтернативы — облачные сервисы на других провайдерах. Решается в фазе 3.
• Купить или собрать платформу машинного обучения. Коммерческая витрина признаков или открытая, само-размещённая. Решается в фазе 3.
• Каркас A/B-тестирования — собственный или внешний. Коммерческие сервисы, открытые решения, собственная реализация. Решается в фазе 2.
• Машинное обучение с сохранением приватности. Для расширенных возможностей (признаки между тенантами, федеративное обучение) нужны соответствующие подходы. Решается в фазе 4.

Что нельзя делать с этой осью

• Откладывать инфраструктуру событий на «когда понадобится» — это разрушает возможность машинного обучения и аналитики в будущем.
• Смешивать доменные и аналитические события в одну шину — у них разные требования к надёжности и схемам.
• Хранить аналитические события в боевой базе — это разрушает её производительность.
• Допускать утечку персональных данных в аналитические события без анонимизации — нарушение регуляций и репутационный риск.
• Делать машинное обучение «в коде сервиса» вместо отдельной платформы — невозможно потом версионировать модели и проводить откат.
• Делать A/B-тесты как «if/else в коде» — нет статистической значимости, нет журналирования, нет жизненного цикла.

Итог

Документ закрепляет информационную инфраструктуру платформы — пять компонентов (захват событий, хранилище данных, конвейеры, машинное обучение, A/B-тестирование), все первоклассные с нулевого дня. Главное послание простое: информационная инфраструктура — это не «бонус для зрелой стадии», а архитектурная основа сразу. Если её не заложить правильно с самого начала, через год-полтора её придётся переписывать с потерей данных, моделей и доверия партнёров. Вместо этого платформа сразу проектируется так, чтобы каждое событие было правильно захвачено, сохранено, доступно для анализа и обучения моделей — независимо от того, на какой фазе развития находится платформа в данный момент.

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

• Ось данных и интеллекта (ось 4) — полный каноничный документ, источник истины этой оси.
• Главная архитектурная ось — карта всех шести осей платформы.
• Манифест переосмысления платформы — роль и принципы платформы.
• Каноничная доменная ось (ось 1) — словарь главных понятий.
• Поверхности взаимодействия (ось 2) — двери платформы к миру.
• Платформа как продукт (ось 3) — коммерческая модель.
• Обзор Ось 1 — резюме простыми словами — резюме первой оси по тому же шаблону.
• Обзор Ось 2 — резюме простыми словами — резюме второй оси по тому же шаблону.
• Обзор Ось 3 — резюме простыми словами — резюме третьей оси по тому же шаблону.
• Операционная ось (ось 5) — надёжность и восстановление.
• Связь с реализацией (ось 6) — мост между архитектурой и существующей реализацией.