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

Это продолжается больше 2 лет. Самое смешное, что я ни разу не видел, как люди показывали поведение «тогда» и «сейчас» на том же самом промпте. Вот ни разу не было "смотрите тот же самый промпт 3 недели назад и сейчас!" (но даже если бы показали — один промпт особо ничего не покажет).

Сам таким грешу, и редко перепрогоняю одни и те же запросы 3-4 раза на разных моделях в разные моменты времени. По моей версии, никакого оглупления не происходит (по крайней мере у OpenAI — 80%+ моих запросов улетают им), просто люди а) не делают прям одинаковые запросы б) имеют маленькие выборки в) плохо понимают границу работоспособности (написать один и тот же код на двух разных фреймворках одного языка — крайне разные задачи).

Так вот — недавно Anthropic (весьма скрытно и без огласки) написали, что Opus на несколько дней и вправду отупел! «С 17:30 UTC 25 августа до 02:00 UTC 28 августа в Claude Opus 4.1 наблюдалось снижение качества ответа на некоторые запросы. Пользователи могли столкнуться с более низким перформансом, некорректными ответами или проблемами с вызовом инструментов в Claude Code».

Причина: «Это было вызвано выкткой нового кода для инференса, который мы с тех пор откатили для Claude Opus 4.1. Хотя мы часто вносим изменения, направленные на повышение эффективности и производительности наших моделей, мы стремимся всегда сохранять неизменное качество отклика модели. Мы также обнаружили, что Claude Opus 4.0 подвержен той же проблеме, и сейчас решаем её.»

Ждём чистосердечного от OpenAI, где они признают, что вместо GPT-5 людям отвечает ChatGPT из 2022-го года (ведь она им ТАК нравилась).

Inference-Time Scaling for Generalist Reward Modeling

Разбор весенней статьи от DeepSeek, я прочитал сразу как вышла, но долго откладывал разбор, не доходили руки. Возможно, эта работа — часть подготовки компании к выпуску следующей флагманской модели, DeepSeek R2.

Я уже писал несколько раз, что в основном обучение рассуждениям работает с задачами, для которых легко проверить, правильный ли ответ — математика и программирование. В этих доменах мы за короткий период увидели существенный скачок в навыках моделей, вплоть до золотых медалей международных олимпиад IMO и IOI. Основная проблема масштабирования RLVR на другие домены — получение точной оценки вознаграждения для обучения LLM, выходящей за рамки простых правил вроде «сколько слов в ответе».

В общих доменах генерация оценок представляет собой более сложную задачу потому, что критерии для вознаграждений более разнообразны и сложны, а явного указания на лучший или даже просто хороший ответ нет. А хочется научиться тренировать Generalist reward
model (GRM) — модель, которая умеет давать оценку для широкого набора доменов; если будет доступ к такой модели, и она будет качественной, то можно запустить классический цикл RLVR на существенно большем наборе промптов.

DeepSeek вводят классификацию для GRM и оценивают их по двум параметрам:
1) inference-time scalability (масштабируемость во время инференса); пункт вдохновлён выходом R1 и других рассуждающих моделей, которые позволили масштабировать количество вычислений, выполняемых при генерации ответа. Inference-time scalability определяется тем, можно ли получить различные оценки при параллельном семплировании. Модель, которая сначала генерирует цепочку рассуждений (называемую критикой), а затем оценку — масштабируемая, так как критики будут разными, и финальные оцени тоже. А классические RM, предсказывающие одно число, так не могут, перегенерация ничего не даст.
2) input flexibility (гибкость входов для модели), определяется тем, поддерживает ли RM оценку одиночных, парных и множественных ответов на один и тот же промпт. Некоторые датасеты имеют больше двух ответов для промпта, и их можно или использовать все и сразу, чтобы показать модели ранжирование от лучшего к худшему, или разбить на пары (1 и 2, 1 и 3, 2 и 3 в случае трёх оценок) и учить на парах.

DeepSeek для себя решают следующее: они будут учить модель, которая получает на вход промпт, от одного до нескольких ответов на него, генерирует критику для каждого из ответов, и в конце выдаёт оценки всех ответов по шкале от 1 до 10. Получается что модель обладает и input flexibility, и можно генерировать несколько ответов в параллель, если хочется потратить больше мощностей.

Критики будут опираться на принципы, которые специфичны для каждого промпта и генерируются самой моделью. Принципы — это описание человеческим языком того, что может служить критерием хорошего и плохого ответа на данный вопрос. Они гибкие: для запроса про код можно вписать корректность, качество кода, читаемость, итд; для запроса по переводу текста принципы совершенно другие. DeepSeek не пишут про это явно, но по примерам + визуализациям становится ясно, что критерии ещё и имеют вес в процентах. Корректность может отвечать за 40% оценки, понятность, скажем, ещё за 40%, и стиль — за 20%. Тогда если модель в ходе своих же рассуждений оценит ответ на 6/8/6, то финальная оценка (которую посчитает сама модель; никаких калькуляторов к ней не подключено) будет 6*0.4 + 8 * 0.4 + 6 * 0.2=6,8.

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

Картинка для облегчения понимания происходящего.

Слева Q & R — промпт и ответы от _какой-то_ модели (условно DeepSeek R2 в момент тренировки).

GRM — это модель, которую мы получаем в рамках этой статьи, её мы и пытаемся обучить.

Дальше эта GRM для Q & R генерирует принципы. Можно генерировать несколько наборов в параллель. Принципы имеют вес в финальной оценке. Обратите внимание, что количество наборов принципов никак не связано с количеством ответов R в Q & R — каждый набор основан на всех ответах, предоставленных GRM. Можно генерировать хоть один набор, если ресурсов мало, хоть 100 (правда они будут сильно повторяться).

На основе принципов также в параллель пишется критика, в которой анализируется каждый из ответов. Критика оканчивается фразой Final Scores:, после которой следует самая желанная часть, оценки каждого из ответов R в Q & R.

Именно эти оценки будут использоваться для дообучения условной DeepSeek R2, как будто человек посмотрел на ответы, сравнил их и сказал «вот этот лучше вот этого».

В самой правой части картинки эти оценки просто извлечены парами. Три пары из 4 покрашены в зелёный — это потому что в них второй ответ получил оценку выше первого; для четвёртой пары это неверно. Разметка тут произведена на основе некоторого датасета, где конкретно для этой пары ответов на запрос человек уже проделал работу, и мы сравниваемся с ней, насколько модель хорошо аппроксимирует человеческое мнение.

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

Стратегия I, голосование
Давайте предположим, что мы сделали 4 параллельных генерации с принципами и критиками, и ответа у нас 2. Пусть это будут ответы [4, 7], [3, 6], [3, 5], [5, 5] — 4 оценки для двух ответов. Авторы предлагают просто их просуммировать и сравнивать финальные цифры: 4+3+3+5=15, 7+6+5+5=23, второй ответ лучше, потому что 15 < 23.

Процесс голосования фактически расширяет пространство вознаграждений в k раз (k = количество параллельных и независимых генераций) и позволяет GRM генерировать большое количество принципов, что повышает качество и детализацию оценок вознаграждений. Интуитивное объяснение заключается в том, что если каждый принцип рассматривать как точку зрения, большее количество принципов может точнее отражать реальное распределение, что приводит к улучшению качества.

И вот тут авторы пишут явно, что при параллельных генерациях перемешивают ответы в промпте местами.

Делают до 32 генераций, чем больше тем лучше по разным бенчмаркам.

Стратегия II, MetaRM и голосование
Если мы делаем много генераций для одной пары, то есть шанс, что какие-то из них будут менее качественными. Ну, получилось так, что один из принципов дурацкий, и вес у него GRM написала очень большой. Чтобы такое отсечь, авторы тренируют MetaRM — просто классификатор, который получает на вход четверки «запрос—ответы—принципы—критика» и предсказывает 0, если ответ скорее неправильный (то есть критика невалидна), и 1, если скорее правильный.

MetaRM тренируются на данных от RFT — помните мы генерировали сотни тысяч ответов и отсекали неправильные? Вот правильные — это единички, а те, что выкинули — нолики, так как эти критики и принципы приводят к неправильной оценке.

MetaRM позволяет отфильтровать оценки до того, как мы их просуммируем. Пусть будет также 2 ответа и 4 параллельных генерации, те же оценки [4, 7], [3, 6], [3, 5], [5, 5]. MetaRM для каждой из 4 предскажет по одному числу, [0.8, 0.9, 0.4, 0.5]. Последние два самые маленькие — их выкидываем, и проводим суммирование по первым двум: 4+3 = 7, 7+6=13, второй ответ лучше первого.

Выкидываем всегда худшую половину, то есть при 32 генерациях выкинем 16.

Показывают, что на бенчмарках MetaRM позволяет ещё больше разогнать качество, особенно на маленьких значениях K (кол-во параллельных генераций), так как там вклад шума может быть большим. А главное её прогон очень дешёвый — модель предсказывает всего одно число за один forward pass, никаких генераций.

Сравнение с другими подходами. Оно не особо информативно, как по мне, главное что MetaRM накидывает, и позволяет иметь лучшее качество даже при 4 генерациях (по сравнению с 32 без неё, синяя линия) и даже обходить GPT-4o (с одной генерацией).

Когда написал разбор статьи на 5 постов с утра пораньше

Ещё в конце июля наткнулся на репост вот этого текста парой каналов и хотел написать его разгромную критику.

Автор пишет своё мнение про вайб-кодинг с опорой на другой текст с разбором результатов соревнования K-prize. Перед критикой важно отметить, что я во многом согласен с выводами про важность скиллов пользователя AI/LLM-продуктов в контексте кодинга.

K-prize — это соревнование по построению автономных АИ-агентов для решения задач, созданных на основе самых свежих PR'ов, собранных с GitHub. По сути то же самое, что SWE-Bench (Verified), по которому измеряют навыки фронтир моделей последний год с хвостиком.

Главные отличия — менее популярные репозитории с кодом, самые свежие PR (часть, по которой производилась оценка для формирования рейтинга, вообще была добавлена после заморозки отправки решений), и наказание за неправильный ответ.

Так что первая формулировка, "турнир по вайб-кодингу, результат данного турнира меня совсем не удивил," — бред, так как это не турнир по вайбкодингу. Тут нет людей, которые управляют процессом и итеративно закидывают промпты в агента.

Его даже нельзя один-к-одному соотнести с SWE-bench из-за штрафа: в этом соревновании лучше ничего не выдавать в качестве ответа на задачу, нежели давать ответ, который не пройдёт тесты. Потому авторы решений намеренно закручивали гайки и строили пайплайны для само-проверки (через генерацию тестов), чтобы ни дай бог ошибочное решение не прошло. Кто знает, может без этого топ-решение дошло бы до 20% решений вместо 11%?

"тестирование LLM по современным бенчмаркам зачастую не показывает объективной картины." — это в целом верно, но в посте делается заключение на основе сравнения в неравных условиях. Помимо ограничения, описанного выше, Kaggle существенно ограничивает вычислительные мощности, выделяемые решению — всего 4 карты прошлого поколения L4. Этого хватает, чтобы уложить в топ-решение модель на... 32 миллиарда параметров — причём даже не рассуждающую, так как скорее всего не хватило бы времени (оно ограничено, на 120 задач выделяется 9 часов).

(в посте есть ещё несколько фраз, которые показывают, что автор оригинального поста не понял, что это не соревнование по вайб-кодингу, а по автономным агентам, но всё переписывать не буду)

Как ясно из описания, это очень, нет, ооооочень далеко от того, что вам доступно в Cursor / Codex и чем хвастаются Anthropic / OpenAI. Я решил найти, как бы сравнить, чтобы показать разницу — поэтому делать вывод «ну вот AI может решать 10%» неверно. Qwen 2.5 такая старая модель (ноябрь 2024-го), что её в большом количестве актуальных бенчмарков и нет уже.

На помощь пришёл SWE-ReBench от команды исследователей из Nebius. Они тоже видят проблему в SWE-Bench (что он статичен и заточен на 12 очень популярных python-репозиториев), и потому полу-автоматизировали пайплайн сбора задач и прогоняют модели на них каждый месяц. Хоть сами репозитории наверное и были в тренировочных данных моделей, решения почти наверняка не попадались LLM — их просто не существовало в момент обучения, они были опубликованы позже.

И что мы видим? Qwen-2.5-Coder-32B одна из худших моделей на лидерборде, с самой высокой долей полностью решённых задач в 7.5% (в мае, до этого колыхался на 4%). Зато в том же мае Claude 4 Sonnet решала 56% новых задач, DeepSeek V3 — 38%. Банально если бы соревнование проводилось в режиме, в котором ресурсы не ограничены (или можно использовать API проприетарных моделей) — получился бы пруф от обратного, что оказывается автономные агенты уже решают чуть ли не половину всех проблем на гитхабе (без участия человека). Но мы так конечно говорить не будем :)

А в остальном бенчмарк очень похож на SWE-Bench. Правда, ребята намеренно не используют никаких продвинутых агентов (читай скаффолдингов), поэтому оценка качества тут скорее прокси снизу — можно прибавить условные 5-7%, если заменить на кого-то из топа SWE-Bench.

Ну и давайте уж сразу не отходя от кассы посмотрим на самый свежий срез за июль. Внезапно GPT-5 оказывается впереди с большим отрывом от всех, особенно на pass@5 метрике (это процент решённых задач, если даётся по 5 попыток на каждую).

GPT-5-medium Pass@1: 29.4% Pass@5: 38.2%
Claude Sonnet 4 Pass@1: 20.6% Pass@5: 23.5%
(Qwen 3 на 480B параметров тоже приятно удивил)

Правда, тут всего 34 задачи (зато каждая по 5 раз прогнана, что позволяет оценить доверительные интервалы, см. картинку), выборка не велика, поэтому очень ждём начала следующей недели — автор лидерборда лично пообещал, что подкинут новых задач. Кстати, подписывайтесь на его канал: @c0mmit и на соавтора и на моего приятеля Сашу тоже: @AIexTime

(Отвечу на немой вопрос, почему качество так упало к концу лета, и вместо 50%+ мы видим 20-30: автор бенчмарка сказал, что они намеренно начали фильтровать более сложные задачи, чтобы лучше дифференцировать модели. Чтож, разница действительно заметна)

((Отвечу на второй немой вопрос: GPT-5-high должен быть выше, но упирается в заданный лимит количества ходов агента, и потому просто не успевает закончить работу; это обещали исправить к следующему релизу результатов, и GPT-5 потенцильно сможет разогнаться ещё выше))

Ну и чтож, очень хороший прыжок от o3! It's a good model sir

Writing-Zero: Bridge the Gap Between Non-verifiable Tasks and Verifiable Rewards

Вчера мы разбирали статью DeepSeek, в которой рассказывалось, как натренировать GRM — модель для оценки ответов LLM и поверх которой должна запускаться процедура тренировки. Однако второй части не было — китайцы просто замерили качество как соответствие человеческим предпочтениям, и на этом остановились. Сегодня разберём статью, как их коллеги из Quark LLM, Alibaba Group, использовали подход для улучшения творческого письма в LLM.

Как гласит китайская поговорка, в литературном искусстве нет абсолютного первенства; творческое письмо представляет собой одну из типичных non-verifiable задач, где оценка качества по своей сути субъективна и не имеет однозначной точки отсчета качества, в отличии от математики и программирования.

В процессе разработки 2 этапа: это обучение своей GRM, следуя рецепту DeepSeek, и обучение LLM через RLVR с использованием предсказанных критик и оценок от GRM.

Итак, что изменилось в GRM?
— собирают внутренний датасет из 200к пар предпочтений, для которых люди отметили, что один ответ лучше другого; 30 тысяч пар из них связаны с письмом. В отличии от DeepSeek, здесь для запроса всегда дана пара ответов, а не 1 или 3.
— отбирают пары более высокого качества, прогнав на них какую-то простую RM (она не пишет критики, сразу выдаёт оценку по паре «запрос—ответ», не беря в расчёт другой ответ) и оставив те пары, где как минимум один из ответов получил достаточно высокую оценку, и при этом разница со вторым ответом существенна, то есть они качественно отличаются; получилось примерно 10 тысяч пар
— отбирают из них одну тысячу, и делают из неё две методом «переставим ответ 1 и ответ 2 местами». Пишут большой промпт (есть в статье) с описание того, как надо писать критику, как проводить оценку, как формировать ответ, и прогоняют через Claude 3.5 Sonnet
— для всех полученных пар проверяют, что при перестановке ответов местами Claude выдал одинаковый и правильный ответ (так как у нас для пар есть оценка, данная человеком). Оставляют только их — получается 500 штук (и 1000, если переставлять ответы местами)
— на этом дообучают Qwen3-32B-Base одну эпоху, это и есть этап RFT. Теперь модель хотя бы минимально понимает свою задачу + унаследует хоть какие-то знания от Claude
— дальше, как и у DeepSeek, запускают GRPO для обучения генерации критик и оценок. В нём есть несколько ключевых отличий:
1) если оценка хорошего и плохого вариантов расходятся меньше чем на 2 по десятибальной шкале (то есть относительно близки), то награда и штраф уменьшаются пропорционально — так как трудно различать ответы с мелкими текстовыми или семантическими расхождениями, да и сама разметка неидеальна. Если расхождение на 2 и более баллов, то даётся полная награда в 1 и штраф в -1 при обучении
2) вводят дополнительное нормирование для advantage (если не знаете что это, то и бог с ним) для учёта position bias, когда модель больше предпочитает первый ответ и даёт ему большую награду. Вкупе с тем, что в самих запросах оцениваемые ответы тоже меняются местами, это позволяет, если верить авторам, полностью победить position bias
3) как сейчас принято, делают Dynamic Sampling, то есть выкидывают промпты, для которых модель научилась делать идеальные предсказания, или наоборот всегда ошибается. В GRPO для одного запроса делается несколько генераций (группа, G в GRPO), обычно 4-16, и вот если все они приводят к одинаковому результату, то учиться тут не на чём.

После этого считаем, что у нас есть GRM для качественной оценки творческого письма, и теперь уже можно учить LLM, которая будет хорошо писать (потому что её во время тренировки будет оценивать качественный учитель). Авторы называют свой подход Bootstrapped Relative Policy Optimization (BRPO).

Проблема GRPO в том, что он считает среднее по всей группе генераций, а затем «хорошие» и «плохие» варианты выбираются относительно этого среднего. Для креативного письма это будет работать хуже, так как сложно сделать объективную оценку, выбрать что-то среднее итд. Поэтому авторы переходят к более простой задаче: выбор случайного в группе + сравнение всех вариантов генерации с ним.

Здесь тоже используется Dynamic Sampling, но слегка другой. Как я написал, в рамках группы выбирается случайный ответ — он называется референсным, и с ним идёт сравнение всех остальных генераций. Во время тренировки может выйти так, что выбранный пример является выбросом — слишком хорошей генерацией или слишком плохой. Это приведёт к тому, что при оценке advantage на основе группы генераций на фоне этого выброса все тексты будут оценены или очень высоко, или очень плохо.

Поэтому предлагается выкидывать из батча такие запросы, для которых выбранный референсный текст выбивается. Там написана формула, которую долго объяснять, поэтому на пальцах: пусть в группе 16 генераций (то есть для одного запроса LLM сгенерирует 16 текстов, а GRM даст 16 критик + 16 оценок, по одной на генерацию). Если 13 и более генераций проигрывают или выигрывают референсной — выкидываем. Таким образом, мы всегда держим пачку текстов, в которой есть достаточная доля и хороших, и плохих текстов, что позволяет получать качественный сигнал для обучения.

Но это же и стреляет в ногу: чем дольше идёт обучение, тем сложнее этого добиться; авторы пишут, что после 400 шагов тренировки они уже выкидывают 80% примеров — а ведь перед тем как выкинуть вам нужно его прогнать, сгенерировать несколько текстов, потом несколько критик, оценок. На всё это тратится много вычислений, которые идут вникуда.

Авторы конечно показывают что модель улучшается по разным оценкам и всё круто, это не так интересно.

Интересно другое. Часто во время обучения через RL происходит reward hacking, когда обучаемая модель вместо выдачи хороших результатов начинает эксплуатировать неидеальность оценщика. Рассуждающие модели, как раз такие GRM, про которые мы говорили вчера, этому подвержены меньше, так как могут написать длинную критику и трезво оценить проблемы, разложить всё по полочкам: «так, ну тут вода и хрень написана, а это вообще не к месту. Минус баллы».

Какого рода проблемы могут быть в творческом письме? Авторы выявляют две:
— длина текста (чем длиннее, тем в среднем выше оценка); то же самое происходит и с людьми, как показала LMArena
— длина объяснения в тексте, когда ответ сопровождается длинными, часто ненужными, комментариями, добавленному как бы ни к месту

Исследователи сравнивают свою модель по этому показателю с двумя другими (см. картинку):

Первая строчка — обучение на тех же данных и также, но где вместо модели-оценщика GRM простая scalarRM (не пишет критику, просто сразу выдаёт одно число)

Третья строчка — WritingSFT, это внутренняя модель компании, обученная без RLVR, просто на написанных людьми цепочках рассуждений и финальных текстах. Так как тут нет RL, то модель не подвержена проблемам, описанным выше, и просто следует тем паттернам, что были в примерах, написанных людьми.

И вторая строчка — это как раз модель с подходом из статьи. Видно, что она почти не добавляет ненужного текста с объяснениями (последняя колонка), и при этом средняя длина ответа почти как у WritingSFT. Говоря иначе, модель пишет чётко и по делу, без воды.

Таким образом можно сказать, что RL не привёл к reward hacking, и GRM в этом помогает.