Схема «модель пишет, модель критикует, модель переписывает» стала стандартом в агентных системах, и почти все делают её одинаково: берут одну большую модель и гоняют её на всех трёх ролях. Свежая работа с ArXiv показывает, что это расточительство. Критик может быть крошечным, а вот на исполнителе экономить опасно: слабый refiner способен сделать ответ хуже, чем был изначально.

Что такое self-refinement

Self-refinement это паттерн инференса, при котором языковая модель сначала генерирует решение, затем сама формулирует критику этого решения, а потом переписывает ответ с учётом замечаний. Цикл «генератор, критик, исполнитель» лежит в основе SELF-REFINE, Reflexion и большинства современных агентных фреймворков, где промежуточные результаты оцениваются перед следующим шагом.

Паттерн пришёл из когнитивистики: ещё Flower и Hayes в 1980 году описывали письмо как три отдельных процесса, производство текста, его оценку и ревизию. В LLM-конвейерах эти роли играют три вызова модели, и вопрос, который почти никто не задавал системно, звучит просто: а нужна ли одинаковая мощность на каждой стадии?

Как устроен эксперимент

Авторы статьи «Asymmetric Capacity Allocation in Self-Refinement Pipelines» формализуют конвейер как P(G, C, R), где G это генератор, C это критик, R это исполнитель (refiner). Запись P(32B, 0.6B, 32B) означает: генерирует модель на 32 миллиарда параметров, критикует крошка на 0.6 миллиарда, переписывает снова 32B. Дальше они меняют размер ровно одной стадии, фиксируя две другие, и смотрят, как двигается итоговое качество.

Тестовый стенд солидный. Пять бенчмарков разного типа: Meeting Planning (планирование встреч с временными ограничениями), CNN/DailyMail (саммаризация), ZebraLogic (логические головоломки), PIE (оптимизация кода) и CollaboSentGen (совместное написание историй). Выбор не случаен: задачи покрывают планирование, сжатие информации, формальную логику, программирование и открытую генерацию, то есть почти весь спектр применений, где сейчас встраивают циклы самопроверки. На каждом бенчмарке взяли управляемые подвыборки: по 500 примеров для Meeting Planning, CNN/DailyMail, PIE и CollaboSentGen и 320 для ZebraLogic, причём самые сложные инстансы отсекли, потому что с ними не справляется даже самая большая модель в тесте.

Два семейства открытых моделей: Qwen3 от 0.6B до 32B и Gemma 3 от 1B до 27B. Оба семейства дают широкую линейку размеров при единой архитектуре и методике обучения, что делает их удобным материалом для изолированного изучения ёмкости. Четыре полные конфигурации (Qwen3-32B, Qwen3-14B, Qwen3-8B и Gemma 3-27B в роли фиксированных стадий) позволяют проверить, не зависит ли вывод от максимального доступного размера. Всё прогонялось на NVIDIA H100 с жадным декодированием, температурой 0.0 и лимитом в 700 новых токенов, причём настройки держали одинаковыми для всех размеров и ролей, чтобы различия относились именно к ёмкости моделей, а не к параметрам сэмплирования.

Контекст: куда деньги утекают на инференсе

Работа стоит на пересечении двух трендов. Первый это масштабирование на инференсе: после того как классические законы масштабирования Каплана и Chinchilla описали рост качества от размера и данных, индустрия сместилась к идее докупать качество вычислениями во время ответа. Длинные цепочки рассуждений у o1 и DeepSeek-R1, самопроверка, голосование по нескольким samples: всё это способы потратить больше токенов на один запрос.

Второй тренд это экономия на маршрутизации. FrugalGPT ещё в 2023 году показал, что каскад из дешёвых и дорогих моделей режет счёт на порядки без потери качества, а адаптивные роутеры вроде BEST-route подбирают модель под конкретный запрос. Исследование асимметричной ёмкости добавляет к этому новый уровень детализации: оказывается, роутить имеет смысл не только запросы целиком, но и отдельные роли внутри одного рассуждающего контура. Пока индустрия спорит, сколько токенов выделять на размышление, эта работа спрашивает точнее: какой модели эти токены отдавать.

Генератор: масштаб работает всегда

Первый вывод предсказуем, но его полезно измерить. Увеличение генератора стабильно улучшает конечный результат на всех пяти задачах. Стандартное отклонение качества при переборе размеров генератора доходит до 10.43 процентных пункта на оптимизации кода и держится заметно выше нуля везде, кроме самой простой творческой задачи (0.96 пункта на CollaboSentGen).

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

Критик: почти плоская кривая

А вот здесь начинается интересное. Кривая качества при росте размера критика выглядит почти горизонтальной на всех бенчмарках и в обоих семействах. Стандартное отклонение критика ниже 0.21 пункта на CollaboSentGen и не превышает 3.1 пункта нигде, тогда как у генератора и исполнителя разброс в разы больше.

Чтобы понять причину, авторы вручную оценили по 50 критик от 0.6B и 32B моделей на каждом бенчмарке, используя пятибалльную рубрику: 5 это полностью корректная и обоснованная критика, 1 это принципиально неверная. Результат: маленький и большой критики редко расходятся в качестве радикально. На ZebraLogic 70% критик от 32B получили оценки 3–5, у 0.6B таких 64%. Когда большой критик прав, маленький обычно тоже не вводит в заблуждение, просто находит меньше ошибок. Когда большой критик ошибается, маленький ошибается вслед за ним.

Показателен пример из Meeting Planning. Задача: спланировать маршрут, где встреча с Рональдом требует 75 минут, а Нэнси доступна только в своём окне. Критик на 0.6B заметил одну ошибку: встреча с Рональдом запланирована на 60 минут вместо 75. Критик на 32B нашёл обе: плюс то, что Нэнси поставлена вне её доступности. Оценка 4 против 5. Разница в полноте есть, но она не переворачивает итоговое качество конвейера.

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

Важная оговорка: даже самый маленький критик лучше, чем его отсутствие. Авторы сравнили стандартный конвейер с базовой линией без критики, где исполнитель переписывает ответ напрямую. Критик на 0.6B даёт прирост над этой линией на всех пяти задачах: +9.67–10.34 пункта на Meeting Planning, +7.86–7.97 на ZebraLogic, +9.03–11.06 на PIE, +4.56–5.21 на CNN/DailyMail, +3.71–4.01 на CollaboSentGen. Польза self-refinement это не просто «ещё один проход модели», явная вербализованная критика несёт собственный сигнал.

Исполнитель: вот где прячется риск

Третья стадия оказалась самой чувствительной. На PIE стандартное отклонение исполнителя составляет 20.60 процентных пункта против 1.63 у критика. На Meeting Planning: 11.20 против 3.10. На CNN/DailyMail: 8.99 против 3.10. Масштаб refiner влияет на итог сильнее, чем масштаб любой другой роли.

Хуже того, слабый исполнитель способен навредить. В конфигурации с Qwen3-32B 12 из 30 проверенных конвейеров (5 бенчмарков × 6 размеров refiner) выдали результат хуже исходной генерации. То есть цикл самоулучшения формально отработал, критика была, а ответ стал хуже, чем до всякой критики.

Чтобы разобраться в механике провала, авторы вручную разобрали 50 случаев деградации из самого экстремального конвейера P(32B, 32B, 0.6B): сильные генератор и критик, крошечный исполнитель. Картина разделилась на два сценария. В 41 случае из 50 критика была корректной (оценки 3–5), но исполнитель на 0.6B, пытаясь её применить, заодно ломал правильные части решения. Большой refiner в тех же условиях вносил только нужные правки и сохранял остальное. В оставшихся 9 случаях критика была ошибочной, и слабый исполнитель послушно тащил ошибку в финальный ответ, тогда как сильный игнорировал плохой совет и оставлял решение как есть.

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

Что это значит на практике

Практический вывод формулируется как асимметричное распределение бюджета: большой генератор, маленький критик, большой исполнитель. Если вы строите агентный контур с самопроверкой, критика это то место, где можно поставить модель в 20–50 раз меньше основной и почти ничего не потерять. Для продакшен-систем с тысячами циклов в секунду это прямая экономия на инференсе: стадия критики обычно генерирует длинный развернутый разбор, и её удешевление даёт ощутимый эффект на счёте за GPU.

Есть и обратная сторона. Экономия на исполнителе это ложная экономия: конвейер вида P(32B, 32B, 0.6B) не просто дешёвый, он активно вредный, потому что тратит вычисления на то, чтобы сделать хуже. Если бюджет вынуждает выбирать, где срезать, срезать нужно критика, а не refiner. А если исполнитель заведомо слаб, честнее вообще отключить цикл ревизии и отдать исходную генерацию.

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

Ограничения исследования

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

Часто задаваемые вопросы

Можно ли заменить большого критика маленьким без потерь?

Почти. По данным исследования, критик на 0.6B параметров даёт большую часть эффекта критика на 32B: разница в итоговом качестве конвейера мала на всех пяти бенчмарках. Большой критик находит больше ошибок, но исполнитель часто не успевает использовать эту полноту.

Почему слабый refiner ухудшает ответ?

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

Работает ли это для агентных систем с несколькими циклами?

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

Итог

Self-refinement перестаёт быть чёрным ящиком, куда ставят «модель побольше». Ёмкость внутри цикла распределяется неравномерно: генератор и исполнитель жадны до масштаба, критик почти равнодушен к нему. Самая дорогая ошибка здесь не переплата за большого критика, а недооценка исполнителя, который способен испортить готовое решение. Если вы проектируете агентный контур с самопроверкой, проведите у себя простой тест: поменяйте местами размеры ролей и измерьте дельту. Велика вероятность, что бюджет на инференс у вас распределён не так, как диктует структура задачи.