Ricursive выпустила Ripple-65B: модель набрала 80,5% на Terminal-Bench 2.1

Когда агент исправляет баг, деньги и время уходят на весь маршрут: прочитать файлы, найти причину, внести правку, запустить тесты и разобраться с новой ошибкой. Ricursive предлагает для такой работы Ripple-65B Preview. Практический интерес понятен: проверить, справится ли модель с вашим репозиторием при приемлемой задержке и стоимости. Например, сможет ли сама починить сломанный обработчик API и подтвердить результат тестом.

Это модель с открытыми весами и 65 млрд параметров. В опубликованной разработчиками оценке она набрала 80,52% на Terminal-Bench 2.1. У Reflection Beam в той же таблице — 80,1%. Разница небольшая, поэтому заголовок про безоговорочную победу здесь был бы лишним. Интереснее сама возможность получить ещё одного кандидата для программирующего агента. Источник: Ricursive.

Что именно выпустили

Ripple использует плотную архитектуру: в отличие от моделей со смесью экспертов, она задействует все свои параметры при обработке каждого токена. Поэтому сравнение только по общему размеру может вводить в заблуждение. У более крупной модели со смесью экспертов одновременно работает лишь часть параметров; меньшее число в названии само по себе не обещает более дешёвый ответ.

Разработчики заявляют контекст до 1 048 576 токенов. Веса опубликованы под Apache 2.0, доступны варианты BF16 и NVFP4. Для команды с требованиями к размещению кода это расширяет выбор: можно рассматривать собственное развёртывание. Но объём контекста ещё не показывает, насколько уверенно агент найдёт нужную зависимость среди сотен файлов. Источник: карточка модели.

Здесь полезно разделить две задачи. Первая — разместить модель и добиться приемлемой скорости ответа. Вторая — собрать агента, который правильно использует поиск, терминал и тесты. Хороший результат первой задачи не гарантирует успеха второй. Длинный контекст тоже не отменяет необходимости выбирать, какие файлы передавать модели.

Почему результат теста нельзя перенести прямо в репозиторий

Авторы сами описывают чувствительность агентских оценок к условиям запуска. В карточке указано, что смена управляющей программы и настроек контекста меняла результаты Terminal-Bench. Их сравнительная таблица объединяет официальные показатели других лабораторий и собственные измерения там, где опубликованных данных не хватало. Это ограничивает точность прямого сравнения. Методика оценки.

Представим обычный баг: после обновления зависимости перестал работать вход пользователя. Агент должен прочитать сообщение об ошибке, найти изменившийся вызов, поправить обработчик и запустить подходящий тест. Красивый ответ с объяснением причины здесь недостаточен. Нужна работающая правка, которая сохраняет прежнее поведение остальных сценариев.

Теперь добавим реальные условия: тестовая база недоступна, документация устарела, а ошибка воспроизводится только с определённой настройкой. Именно здесь проявляются различия между моделями и настройками агента. Одной понадобится подсказка человека, другая начнёт менять лишние файлы, третья корректно обозначит, каких данных ей не хватает. Общая оценка бенчмарка не заменяет такой проверки.

Как проверить пользу для команды

Я бы начал с небольшой подборки уже решённых задач: исправление ошибки, добавление теста, изменение API и работа с незнакомым модулем. Для каждой нужны исходное состояние проекта и понятный критерий успеха. Затем стоит дать Ripple и текущей модели одинаковые инструменты, ограничения времени и доступ к окружению.

Считать лучше стоимость принятой правки. В неё входят повторные попытки, время выполнения команд и проверка человеком. Дешёвые токены мало помогают, если разработчик потом полчаса убирает ненужные изменения. Отдельно стоит записывать случаи, когда агент объявил задачу решённой, хотя проверка результата не состоялась.

Для продукта это способ принять конкретное решение: подходит ли Ripple для выбранного класса задач, нужна ли дополнительная проверка и когда передавать работу человеку. Открытые веса делают такой эксперимент доступнее с точки зрения контроля развёртывания. Основанием для перехода должны стать результаты на вашем коде — вместе со временем, расходами и качеством правок.