Как работает Hyperstone

Эта страница объясняет основные концепции Hyperstone и то, как платформа оптимизирует конфигурацию вашего приложения в реальном времени. Вам не нужны глубокие знания в machine learning, чтобы использовать Hyperstone, но понимание этих основ поможет вам настраивать более эффективные оптимизации и правильно интерпретировать результаты.

Общая картина

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

flowchart
    Hyperstone[Hyperstone] -->|1. Передает конфигурацию| App[Ваше приложение]
    App -->|2. Влияет на опыт| User((Пользователь))
    User -.->|3. Генерирует события| App
    App -->|4. Отправляет измерения| Hyperstone

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

Ключевые концепции

Параметры (Parameters)

Параметры — это значения конфигурации, которые оптимизирует Hyperstone. Каждый параметр имеет имя и набор возможных значений, которые вы определяете.

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

Параметр	Возможные значения
`n_lives`	1, 2, 3, 5
`ad_cooldown_seconds`	30, 60, 120, 300
`show_ads_after_death`	true, false
`starting_coins`	0, 50, 100, 500
`difficulty`	easy, normal, hard

Конкретная комбинация значений параметров называется конфигурацией. Например:

n_lives: 3
ad_cooldown_seconds: 60
show_ads_after_death: true
starting_coins: 100
difficulty: normal

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

Метрики и измерения (Metrics and Measurements)

Измерения (measurements) — это сырые сигналы, которые ваше приложение отправляет в Hyperstone. Каждое измерение имеет имя и числовое значение. Измерения накапливаются со временем для каждого пользователя.

Примеры измерений:

ad_revenue: 0.03 (пользователь посмотрел рекламу стоимостью $0.03)
levels_completed: 1 (пользователь прошел один уровень)
session_time_minutes: 12.5 (пользователь провел в приложении 12.5 минут)

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

Например, метрика ARPU (Average Revenue per User) может рассчитываться так:

ARPU = Total Revenue / Number of Users

Где Total Revenue и Number of Users являются агрегированными измерениями. Некоторые метрики встроены (например, количество сессий, retention и время вовлеченности), другие вы определяете как кастомные метрики (custom metrics), специфичные для вашего приложения.

Целевая метрика (Target Metric)

Целевая метрика — это метрика, которую Hyperstone должен максимизировать. Она определяет «цель» оптимизации.

Распространенные целевые метрики включают:

Ad Revenue per User — максимизация рекламного дохода от каждого пользователя
Retention Day 7 — максимизация процента пользователей, которые возвращаются через 7 дней
Session Count — максимизация количества сессий пользователей
LTV — максимизация пожизненной ценности пользователя

Выбор целевой метрики определяет, какие конфигурации будет отдавать предпочтение алгоритм. Например, оптимизация по рекламному доходу может привести к более частому размещению рекламы, в то время как оптимизация по retention может привести к более плавному, менее прерывистому опыту. Задача алгоритма — найти баланс в вашем пространстве параметров, который лучше всего служит выбранной цели.

Лейблы (Labels)

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

Например, измерение показа рекламы может включать такие лейблы:

ad_network: "admob"
ad_format: "rewarded"

Лейблы позволяют системе разбивать метрики по измерениям (dimensions), не создавая отдельные типы измерений для каждой комбинации.

Алгоритм: Multi-Armed Bandit

В своей основе Hyperstone моделирует проблему оптимизации как Multi-Armed Bandit (MAB).

Аналогия

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

В контексте Hyperstone:

Каждый рычаг (arm) — это возможная конфигурация (комбинация значений параметров)
Каждое нажатие (pull) — это пользователь, получивший эту конфигурацию
Награда (reward) — это значение целевой метрики, наблюдаемое для этого пользователя

Как это работает на практике

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

Почему не просто A/B тест?

Ключевое преимущество подхода MAB перед традиционным A/B тестированием заключается в том, что он начинает улучшать результаты немедленно, а не ждет завершения теста. В A/B тесте половина ваших пользователей остается с контрольным вариантом на протяжении всего теста. В оптимизации на базе MAB алгоритм динамически переключает трафик на более эффективные конфигурации, как только получает достаточно сигналов — таким образом, каждый пользователь извлекает выгоду из того, что система уже выучила.

Кроме того, MAB естественным образом справляется с:

Большим количеством параметров одновременно — нет необходимости тестировать их по одному
Меняющимися условиями — алгоритм может адаптироваться, если поведение пользователей изменится
Отсутствием ручного принятия решений — не нужен аналитик, чтобы решить, когда остановиться и какой вариант «победил»

Что происходит «под капотом»

Вот полная последовательность событий между сервером Hyperstone, SDK в вашем приложении и вашими пользователями:

sequenceDiagram
    actor User
    participant App as Ваше приложение
    participant SDK as Hyperstone SDK
    participant Server as Сервер Hyperstone

    Note over User, Server: 1. Получение конфигурации
    User->>App: Открывает приложение
    App->>SDK: Initialize
    SDK->>Server: Request Config
    Server->>Server: Генерация оптимальной конфигурации
    Server-->>SDK: Config values
    SDK-->>App: Deliver Config
    App->>App: Применение настроек<br/>(например, жизни, реклама)

    Note over User, Server: 2. Петля обратной связи
    User->>App: Играет, создает события
    App->>SDK: Log events
    SDK->>SDK: Буферизация измерений
    SDK->>Server: Batch send
    Server->>Server: Обновление модели алгоритма

Пошаговый разбор одного цикла оптимизации:

Новый пользователь открывает ваше приложение. SDK вызывает Hyperstone API для запроса конфигурации.
Сервер генерирует конфигурацию. Алгоритм оптимизации — основываясь на всем, что он выучил до сих пор — выбирает конфигурацию для этого пользователя. Это может быть текущий лучший вариант или альтернатива, которую он хочет исследовать.
Конфигурация передается в SDK. SDK предоставляет эту конфигурацию вашему приложению через callback. Ваше приложение применяет значения (например, устанавливает сложность на “hard”, дает 3 жизни, показывает рекламу каждые 60 секунд).
Пользователь взаимодействует с приложением. Пока он играет, смотрит рекламу, совершает покупки или вызывает кастомные события, SDK отслеживает их как измерения.
Измерения отправляются на сервер. SDK группирует и отправляет накопленные измерения на бэкенд Hyperstone. Они связаны с конфигурацией, которую получил этот пользователь.
Алгоритм обновляется. Сервер записывает новые данные и уточняет свое понимание того, насколько эффективно работает эта конфигурация. Эти обновленные знания влияют на то, какую конфигурацию получит следующий пользователь.

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

Резюме

Концепция	Что это
Parameter	Настраиваемое значение в вашем приложении (например, `n_lives`, `ad_cooldown`) с определенными возможными значениями
Configuration	Конкретная комбинация значений параметров, назначенная пользователю
Measurement	Сырой числовой сигнал, отправленный из приложения (например, `ad_revenue: 0.03`)
Metric	Расчетный показатель, производный от измерений (например, LTV = Revenue / Users)
Target Metric	Метрика, которую алгоритм пытается максимизировать
Label	Метаданные с низкой кардинальностью, прикрепленные к измерениям для сегментации
Optimization	Непрерывный процесс поиска лучшей конфигурации для вашей целевой метрики
Algorithm (MAB)	Статистический метод, используемый для баланса между исследованием и эксплуатацией

Следующие шаги

Теперь, когда вы понимаете, как работает Hyperstone, посмотрите, что нужно для начала работы:

→ Быстрый старт и настройка