Обучение с подкреплением

RL на собеседовании (FAANG)

Предварительные знания

  • PPO и clipped objective: самый частый алгоритм на RL-собеседованиях
  • Offline RL (CQL, IQL): почему в production редко допустимо онлайн-исследование
  • RLHF: reward model, KL-ограничение и DPO для выравнивания языковых моделей
  • Основы MDP: state, action, reward, transition, discount - формулировка, с которой начинается любой design-вопрос
  • PPO: Proximal Policy Optimization
  • Offline RL: обучение на логах
  • RLHF: RL для выравнивания AI

От исследовательского любопытства к приоритету найма

RL оставался академической нишей, пока AlphaGo не обыграл Lee Sedol в марте 2016 года, впервые, когда программа победила сильнейшего профессионала-человека в го. Этот результат вывел RL из исследовательских лабораторий в индустриальные дорожные карты и воронки найма. Второй всплеск пришёл в конце 2022 года, когда ChatGPT сделал RLHF (Reinforcement Learning from Human Feedback) центральной техникой за выровненными языковыми моделями. За несколько месяцев 'RL engineer' и 'RLHF' стали одними из самых востребованных и высокооплачиваемых ML-специализаций, а собеседования в стиле FAANG начали проверять RL system design напрямую, а не относиться к нему как к экзотике.

Роль «ML Engineer, Reinforcement Learning» в DeepMind, Meta AI или Google Brain - одна из самых высокооплачиваемых в индустрии ($300-500K total comp в US). Но RL-собеседования специфичны: ценят не знание формул, а умение проектировать системы под реальные ограничения и чётко формулировать компромиссы.

  • **Google (Ads Bidding)**: RL для оптимизации ставок в реальном времени на миллиардах аукционов в день. Алгоритм: offline RL на исторических логах, online deplyment с safety constraints.
  • **Netflix (Recommendation)**: RL для долгосрочной оптимизации engagement и retention, обновление раз в сутки, exploration на 1% трафика.
  • **Meta (Feed Ranking)**: Contextual bandit + RL-элементы для балансировки краткосрочного engagement и долгосрочного user wellbeing.

Проектирование MDP для реальных задач

На FAANG-собеседовании по RL часто дают задачу: «Спроектируйте RL-систему для рекомендаций» или «Как применить RL к оптимизации рекламных ставок?». Первый шаг всегда одинаковый: сформулировать задачу как MDP (S, A, R, T, γ).

  1. **S (State)**: что агент наблюдает? Для рекомендаций: история просмотров пользователя, контекст (время, устройство), демография. Избегать включения будущего в состояние.
  2. **A (Action)**: что агент решает? Для рекомендаций: выбор одного из K item-кандидатов или ранжирование списка.
  3. **R (Reward)**: что максимизируем? Клик (+1)? Время просмотра (+t)? Конверсия (+purchase_value)? Важно: R должен отражать бизнес-цель, а не прокси-метрику.
  4. **T (Transition)**: как меняется состояние? Обычно детерминированное: state <- append(state, action, reward).
  5. **γ (Discount)**: γ=0.99 для долгосрочной оптимизации, γ=0.9 для краткосрочной.

Типичная ошибка на собеседовании: слишком сложное состояние. Если состояние включает всё (все клики за год, все демографические данные), обучение невозможно. Правило: state должен содержать Марковскую достаточную статистику - минимум для предсказания будущего.

При проектировании MDP для рекомендательной системы интервьюер спрашивает: «Как определить reward?». Какой ответ правильный?

Выбор алгоритма: framework для собеседования

После формулировки MDP: «Какой алгоритм использовать?» - стандартный вопрос. Правильный ответ зависит от свойств задачи, а не от любимого алгоритма. На собеседовании это демонстрирует системное мышление.

  • **Дискретные действия + можно симулировать**: DQN / Rainbow - достаточно data-efficient, хорошо изучен.
  • **Непрерывные действия (роботика, управление)**: SAC (Soft Actor-Critic) - sample-efficient, устойчив к гиперпараметрам.
  • **Большой дискретный action space (рекомендации, 10^6 items)**: Policy Gradient + embedding layer для actions.
  • **Offline данные доступны, онлайн дорого**: Conservative Q-Learning (CQL) или IQL - обучение без онлайн взаимодействия.
  • **RLHF / LLM alignment**: PPO + KL penalty (OpenAI), DPO (Anthropic/Meta open-source).
  • **Мало данных, нужна обобщаемость**: MAML / Model-based RL с планировщиком.

На FAANG-собеседовании ожидается знание Offline RL: в production редко можно безопасно запустить агента онлайн. CQL, BCQ, IQL обучаются на исторических данных без деградации OOD-действий.

Задача: оптимизация ставок в рекламном аукционе, действия непрерывные (bid price), исторические данные есть, онлайн эксперименты дорогие. Какой алгоритм выбрать?

Масштабирование RL в production

Академический RL: 1 агент, 1 среда, 1 GPU, несколько дней. Production RL в Netflix или Google: миллионы пользователей, реальное время, требования latency < 100ms. Разрыв огромный.

  • **Inference latency**: политика должна принимать решения за < 50ms. Решение: distillation в маленькую сеть или предвычисление Q-values offline.
  • **Sample efficiency**: онлайн сбор данных медленный и дорогой. Решение: Prioritized Experience Replay, Offline RL pretraining.
  • **Non-stationarity**: среда меняется (сезонность, новые items). Решение: частые дообучения, Continual RL.
  • **Exploration/Exploitation**: нельзя показывать плохие рекомендации ради исследования. Решение: ε-greedy с ε=0.001, Thompson Sampling на bandit-уровне.
  • **Multi-objective**: бизнес требует баланс engagement, revenue, safety. Решение: составной reward с learnable weights.

Netflix (2022) описал свою RL-систему рекомендаций: 200M пользователей, state = 500-dim embedding истории, action space = 10K candidates, обновление модели каждые 24 часа на batch offline данных. Online exploration - только 1% трафика.

Recommendation RL система обновляется раз в сутки offline. Какая проблема возникает при этом?

Ключевые компромиссы и «ловушки»

На финальном раунде FAANG-собеседования часто спрашивают не о деталях алгоритма, а о компромиссах: «Почему не использовать более простой подход?» или «Какие риски у этого решения?».

  • **RL vs supervised learning**: RL нужен когда reward зависит от последовательности действий и нет labeled optimal responses. Для простых задач supervised или bandit лучше.
  • **Model-based vs Model-free**: model-based быстрее сходится но требует точного симулятора; model-free надёжнее но дороже по данным.
  • **Online vs Offline RL**: online exploration опасен в production; offline RL безопасен но страдает от OOD-действий.
  • **Dense vs Sparse reward**: sparse reward естественнее (победа в игре) но учиться труднее; dense reward проще учить но приводит к reward hacking.
  • **Exploration**: без исследования не найти оптимум; с исследованием - риск плохого опыта для пользователей.

Частый вопрос: «Как измерить, хорошо ли работает RL-система?». Правильный ответ включает: offline evaluation (OPE метрики: IS, DM, DR), A/B тест с контролем, долгосрочные метрики (не только CTR но и retention, LTV).

Чем сложнее алгоритм RL - тем лучше результат в production

В production часто выигрывают простые, надёжные подходы: contextual bandit вместо full RL, offline обучение вместо online, dense reward вместо sparse

Google и Netflix публично говорят, что многие их системы используют multi-armed bandit или offline supervised imitation, а не full RL. Сложность RL оправдана только при явной необходимости: длинные горизонты, сложные зависимости между шагами.

Интервьюер спрашивает: «Зачем использовать RL для рекомендаций, если supervised learning уже работает?». Лучший ответ:

Ключевые идеи

  • **MDP design**: state (Марковская достаточная статистика), action (что решается), reward (бизнес-цель, не прокси), γ (горизонт планирования).
  • **Algorithm selection**: дискретные - DQN/Rainbow, непрерывные - SAC, offline данные - CQL/IQL, LLM alignment - PPO/DPO.
  • **Production challenges**: latency, non-stationarity, safe exploration, distribution shift при offline обучении.
  • **Ключевой trade-off**: RL оправдан когда нужна оптимизация долгосрочного reward; для краткосрочных задач bandit или supervised learning надёжнее.

Связанные темы

Подготовка к RL-собеседованию охватывает весь курс:

  • RLHF и выравнивание AI — Популярная тема в LLM-компаниях: понимание PPO+KL и DPO обязательно для позиций в OpenAI, Anthropic, Google DeepMind
  • DQN и Deep RL — DQN - стандартный baseline, который интервьюер ожидает как точку отсчёта при выборе алгоритма

Вопросы для размышления

  • YouTube изменил reward с watch time на composite score включающий surveys о удовлетворённости. Какие trade-offs возникают при переходе от proxy-метрики к составному reward?
  • Если RL-агент для рекомендаций начинает показывать пользователям всё более экстремальный контент (reward hacking), как это детектировать и остановить в production?
  • Offline Reinforcement Learning обещает обучение без опасного онлайн взаимодействия. Почему тогда не все production системы используют только offline RL?

Связанные уроки

  • rl-02 — Формулировка MDP - первый шаг на интервью
  • rl-07 — DQN - канонический ответ при выборе алгоритма
  • rl-10 — PPO - самый упоминаемый алгоритм на интервью
  • rl-17 — Дизайн RLHF-систем встречается на современных интервью
  • ml-55-ml-system-design — Та же структурная логика tradeoff, что и в ML system design
  • prob-01-intro
RL на собеседовании (FAANG)

0

1

Войти