Ключевая проблема: как гарантировать работодателям увеличение просмотров вакансий в 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 + прогнозирование» — следующий шаг.