Cursor учит свою модель прямо на вас - и это не кликбейт

Представьте: вы пишете код в IDE, а ваш ИИ-помощник в это самое время учится на том, как вы с ним взаимодействуете. Не где-то в лаборатории на синтетических задачах, а прямо сейчас, на вашем реальном проекте, с вашими реальными ошибками и вашими реальными запросами. Каждые пять часов выкатывается обновлённая версия модели, которая чуть лучше предыдущей. Звучит как фантастика? Команда Cursor только что рассказала, что именно так работает их новый подход к обучению Composer — и результаты впечатляют.

Классическая схема обучения ИИ-кодеров выглядит так: берём кучу репозиториев, создаём симулированные среды, придумываем задачи, запускаем Reinforcement Learning, получаем модель. И она работает хорошо — в тепличных условиях. Но между лабораторной задачей и реальным программистом, который в три часа ночи дебажит продакшн, — пропасть.

Эта пропасть в ML называется train-test mismatch (расхождение между обучением и реальным использованием). Сам по себе код неплохо симулируется: можно создать виртуальную среду, запустить линтер, прогнать тесты. Но есть одна вещь, которую невозможно симулировать идеально, — живой человек. Программист с его непредсказуемым стилем, контекстом проекта, привычками и нюансами формулировок промптов. Существуют исследования (например, arxiv.org/abs/2505.10831) по созданию моделей-симуляторов пользователя, но они неизбежно вносят ошибку моделирования. Вы никогда не воспроизведёте все паттерны настоящего разработчика.

Cursor решил эту проблему радикально: зачем симулировать пользователя, если можно учиться на реальном?

Подход, который Cursor назвал real-time RL, — это не просто маркетинговый термин. За ним стоит конкретный инженерный пайплайн, и он устроен довольно элегантно.

Каждый цикл обучения выглядит так:

⚙️ Сбор данных. Текущая версия модели (чекпоинт) работает в продакшне. Тысячи разработчиков взаимодействуют с Composer — редактируют код, принимают или отклоняют правки, задают уточняющие вопросы, отправляют фидбек. Из этих взаимодействий собираются миллиарды токенов.

⚙️ Дистилляция в сигнал награды. Сырые данные превращаются в reward-сигнал — по сути, числовую оценку того, насколько удачным было поведение модели. Приняли ли пользователь правку? Отправил ли недовольный отзыв (follow-up)? Остался ли код в кодовой базе после ревью?

⚙️ Обновление весов. На основе этих наград пересчитываются веса модели методами policy gradient — семейством алгоритмов, где модель усиливает поведение, получившее высокую награду, и подавляет поведение с низкой.

⚙️ Проверка на регрессии. Обновлённый чекпоинт прогоняется через набор тестов, включая CursorBench — собственный бенчмарк Cursor. Только если всё чисто, модель уезжает в продакшн.

⚙️ Деплой. Новая версия становится доступна пользователям — и цикл начинается заново.

Весь этот конвейер укладывается примерно в пять часов. То есть за рабочий день модель может обновиться несколько раз. Для сравнения: большинство AI-провайдеров выпускают обновления модели раз в несколько месяцев.

Почему пять часов — это принципиально важно

Тут есть тонкий, но критически важный нюанс из теории RL. Алгоритмы policy gradient дают несмещённые оценки градиента только тогда, когда данные собраны on-policy — то есть той же моделью, которую мы сейчас обновляем. Если модель уже изменилась, а данные остались от предыдущей версии (off-policy), обучение становится нестабильным и склонным к переоптимизации — модель начинает «выкручивать» метрики вместо реального улучшения качества.

Пятичасовой цикл позволяет Cursor держать данные почти полностью on-policy. Это как разница между обучением по свежей обратной связи от ментора и попыткой учиться по записям, сделанным кем-то другим полгода назад.

Cursor честно публикует результаты A/B-тестирования обновлённого Composer 1.5: