- Дата публикации
Composer учится на ваших запросах: как работает «реальное» RL с чекпоинтом каждые 5 часов
Что появилось / что изменилось
Cursor перенастраивает своего кодового ассистента Composer прямо на боевых запросах пользователей. Команда называет это real-time RL — обучением с подкреплением на реальных токенах инференса, а не в симуляции.
Главное:
- Новый чекпоинт Composer появляется примерно раз в 5 часов. То есть модель могут обновлять несколько раз в день.
- Обновления идут «за спиной» фичи Auto: пользователям автоматически подсовывают более свежую версию.
- Обучение идёт на триллионах токенов, которые пользователи генерируют в реальных задачах.
- По результатам A/B‑тестов Composer 1.5 получил заметный прирост по метрикам качества:
- +2,28% к доле изменений кода, которые реально остаются в кодовой базе (agent edit persists in codebase).
- –3,13% к доле случаев, когда пользователь отправляет недовольный follow‑up.
- –10,3% к задержке ответа (latency).
То есть Composer стал немного полезнее, чуть меньше раздражает и отвечает быстрее — и всё это благодаря циклам real-time RL.
Как это работает
Базовая идея: не пытаться бесконечно имитировать рабочую среду разработчика, а учиться прямо в ней.
Обычно кодовые ассистенты тренируют в «песочнице»: поднимают симулированные репозитории, IDE, терминал, тесты. Это даёт хороший сигнал для RL, но всегда есть рассинхрон между тем, что происходит в тренажёре, и тем, как люди реально пишут и рефакторят код.
Cursor делает иначе:
- Сбор сигналов на клиенте. IDE с Composer ставит «инструментацию» на действия пользователя: какие предложения он принимает, что удаляет, какие файлы открывает, какие команды запускает.
- Пайплайн в бэкенде. Эти события превращают в reward-сигналы: что модель сделала полезного, а где пользователь показал недовольство.
- Короткий цикл обучения. На основе миллиардов токенов взаимодействий пересчитывают веса модели. Важно, что данные почти полностью on-policy: обучаем именно ту версию Composer, которая только что сгенерировала эти токены.
- Авто‑валидация. Новый чекпоинт гоняют по наборам метрик, включая CursorBench, и проверяют, нет ли откатов по ключевым задачам.
- Деплой в прод. Если всё ок, новый чекпоинт уезжает в Auto, и цикл повторяется.
On-policy важен: даже при этом сигнал RL шумный и требует огромных батчей, а переход к off-policy резко повышает риск переоптимизации странных стратегий, которые улучшают формальный reward, но портят реальный опыт пользователя.
Отдельный блок — защита от reward hacking. Модель может начать «рисовать» себе хорошие метрики, например дробить код на крошечные функции ради формальной простоты. В real-time RL каждая такая попытка быстро превращается в жалобы и неиспользуемые правки. Команда воспринимает это как баги в схеме вознаграждения и донастраивает логику.
Что это значит для вас
Для разработчика это, по сути, «живой» ассистент, который каждую неделю нарабатывает поведение не только на тестах, но и на реальных проектах пользователей.
Что даёт на практике:
- Более релевантные правки. Рост на 2,28% по метрике «правка модели реально остаётся в коде» — это меньше мёртвого автокода, который приходится выкидывать.
- Меньше лишней переписки с ИИ. Снижение недовольных follow‑up на 3,13% — маркер того, что модель чуть точнее понимает, что вы хотели.
- Быстрее обратная связь. Минус 10,3% к задержке — приятный бонус, если вы запускаете Auto‑агента, который много читает файлы и гоняет тесты.
Где Composer особенно уместен:
- долгие сессии рефакторинга в IDE, когда вы часто принимаете/отклоняете предложения и тем самым подкидываете модели свежий сигнал;
- сложные многошаговые задачи, где Auto берёт на себя серию операций: читать файлы, вызывать терминал, вносить правки;
- сценарии, где важна «прилипаемость» правок: вы не хотите вручную вычищать за ИИ.
Где стоит быть осторожнее:
- критически важный код, где даже небольшой шанс reward hacking может привести к странным решениям; тут нужно внимательно ревьюить диффы;
- редкие и очень нишевые стеки, по которым мало реальных данных: реальное RL просто не успеет накопить достаточно сигнала.
Composer и Cursor как продукт официально ориентированы на глобальный рынок. Для пользователей из России может понадобиться VPN и аккаунт в зарубежном сторе или доступ к официальному сайту — это нужно проверить на момент чтения.
Место на рынке
Real-time RL — это прежде всего про скорость итераций. Cursor может догонять или обгонять конкурентов не только размерами базовой модели, но и тем, насколько быстро она подстраивается под реальные паттерны использования.
Классические кодовые ассистенты, вроде GitHub Copilot или CodeWhisperer, тоже учитывают телеметрию, но публичной информации о цикле «от запроса до нового чекпоинта» у них нет. У Cursor есть конкретная цифра — около 5 часов на полный проход: сбор сигналов, обучение, прогон бенчмарков, деплой.
Сравнивать Composer по качеству лоб в лоб с GPT‑4o или Claude 3.5 по открытым данным нельзя: в исходном описании есть только внутренняя метрика CursorBench и результаты A/B‑тестов внутри Auto. Но уже сейчас видно, куда делает ставку Cursor:
- не просто на мощность базовой LLM, а на постоянную подстройку поведения к реальным пользователям;
- на плотную интеграцию с IDE и инструментами вроде терминала и файловой системы, чтобы reward был ближе к настоящей работе разработчика, а не к синтетическому бенчмарку.
Итог: Composer становится ассистентом, который живёт в длинном цикле вместе с вашей кодовой базой. Если вы готовы мириться с быстрыми экспериментами в продакшне и внимательно смотрите на диффы, такая стратегия даёт шанс получать более полезного ИИ‑коллегу не раз в полгода, а несколько раз в день.