Ключевая проблема:
Как гарантировать работодателям увеличение просмотров вакансий в 3–10 раз (платный KPI), не нарушая релевантность выдачи для пользователей, если:

Просмотры зависят от позиции, но нет формулы «позиция → клики»;

Статические бусты приводят к перегреву/исчезновению вакансий.

Решение:
PID-регулятор, заимствованный из инженерных систем (температура, круиз-контроль), адаптированный для ранжирования в реальном времени.

Технические компоненты:
A/B-тест для измерения «ненаблюдаемого»:
5% трафика (контроль) → базовый уровень просмотров для каждой вакансии.
Цель для платных тарифов: Базовый уровень × 3 (или 10).

PID-логика:
P (ошибка «цель vs факт»), I (история дефицита), D (предсказание перебуста).
Формула коэффициента: U(t) = K_p × e(t) + K_i × ∫e(t)dt + K_d × de(t)/dt.

Архитектура:

Нормирование релевантности (скоры → [0,1]), фичстор (история просмотров, PID-параметры), стартовый буст для новых вакансий через сигмоиду.

Результаты для highload-систем:

KPI для бизнеса:
89% вакансий на тарифе ×3 и 94% на ×10 выполнили цели.

Для пользователей:
CTR +1.5%, время отклика ↗7% (более релевантный выбор).

Применимость подхода:

Класс задач: Динамическое ранжирование с бизнес-ограничениями (просмотры, конверсии, доход).

Стек: Высоконагруженные поисковые системы, где требуется баланс между монетизацией и UX.

Ограничения: Требует A/B-тестов для калибровки и точного измерения «ненаблюдаемых» метрик.


Почему это будет в докладе:

Реальные кейсы «танцующих» вакансий в выдаче (графики + логика PID).
Архитектурные решения для работы в реальном времени.

Сравнение PID vs ML: когда что выбрать.


Ключевой вывод:
PID-регулятор — интерпретируемый и ресурсоэффективный способ балансировки в highload, не требующий глубокого ML. Но гибрид «PID + прогнозирование» — следующий шаг.