Dmitry Dementiev
8f1e997cc9
- Зачем: - поток генератора должен соответствовать модели интенсивности и профилю сида перед реализацией состояния версии 2. - Что: - событийный бюджет тика переведён в рождения визитов через ожидаемую среднюю длину визита. - дефолты интенсивности и обычный docker-compose запуск синхронизированы с целевыми 30 событиями в минуту. - добавлены статистические проверки длины визита, воронки, новых пользователей, межсессионных пауз и долгого окна потока. - обновлены README, OPERATIONS и карточка задачи 05. - Проверка: - uv run --with-requirements generator/requirements.txt pytest generator/tests -q. - git diff --check.
56 lines
4.1 KiB
Markdown
56 lines
4.1 KiB
Markdown
Status: ready-for-human
|
|
|
|
# Интенсивность и калибровка потока
|
|
|
|
## What to build
|
|
|
|
Связать иерархическую модель с целевой интенсивностью потока. Старая идея
|
|
Пуассона, часового коэффициента и jitter должна задавать бюджет активности, из
|
|
которого рождаются визиты; фактические события выходят по запланированным
|
|
паузам активных визитов.
|
|
|
|
На этом шаге также нужно проверить, что параметры модели дают поток,
|
|
сопоставимый с профилем сида: длина визита около 10 событий в среднем и по
|
|
медиане, доля дошедших до `/confirmation` около 25%, межсессионные паузы
|
|
согласованы с формулой из спеки.
|
|
|
|
Источник решений: `docs/specs/2026-06-10-generator-math-model.md`, разделы
|
|
«Связка с моделью интенсивности», «Параметры» и «Критерии приёмки».
|
|
|
|
## Acceptance criteria
|
|
|
|
- [x] Средняя интенсивность событий за длинное окно соответствует
|
|
`GEN_LAMBDA_BASE_PER_MIN * часовой коэффициент` с разумным отклонением.
|
|
- [x] Рождения визитов рассчитываются из бюджета событий и средней длины визита,
|
|
а не из старых границ `GEN_MIN/MAX_EVENTS_PER_TICK` в прежнем смысле.
|
|
- [x] Доля новых пользователей за длинное окно близка к `GEN_P_NEW_USER`.
|
|
- [x] Межсессионные паузы одного пользователя не меньше кулдауна, а среднее на
|
|
дефолтах находится в районе расчёта из спеки.
|
|
- [x] Распределение длины визита на симуляции сопоставимо с сидом: медиана около
|
|
10, среднее около 10, максимум не выше потолка.
|
|
- [x] Воронка по шагам `/home -> товары -> /cart -> /payment -> /confirmation`
|
|
монотонно затухает на длинной симуляции.
|
|
|
|
## Blocked by
|
|
|
|
- `.scratch/feature-data-generator/issues/04-user-population-and-returns.md`
|
|
|
|
## Comments
|
|
|
|
2026-06-11: реализована калибровка потока через `TickStreamGenerator`: событийный
|
|
бюджет тика копится как бюджет рождений визитов через ожидаемую среднюю длину
|
|
визита (~10 событий), а фактические события выходят по запланированным паузам
|
|
активных визитов. Дефолт `GEN_LAMBDA_BASE_PER_MIN` в коде снижен до 30
|
|
событий/мин и синхронизирован с обычным запуском через `docker-compose.yml`;
|
|
`GEN_MIN/MAX_EVENTS_PER_TICK` теперь ограничивают событийный бюджет тика до
|
|
пересчёта в рождения визитов.
|
|
|
|
Калибровка таблицы переходов и пауз проверена тестами: средняя интенсивность
|
|
длинного окна близка к целевому бюджету, доля новых пользователей близка к
|
|
`GEN_P_NEW_USER`, межсессионные паузы не меньше кулдауна и имеют часовой
|
|
масштаб около формульного ориентира из спеки, длина визита сопоставима с сидом,
|
|
доля `/confirmation` остаётся около 25%, воронка монотонно затухает.
|
|
|
|
Проверка: `uv run --with-requirements generator/requirements.txt pytest
|
|
generator/tests -q` — 96 passed.
|