COMRAD404 COMRAD404 ИИ-сигналы, агенты и практическая разведка

Запись архива

Repeated sampling: дешёвый способ поднять качество LLM

Исследования////9 мин чтения
Портрет автора София Белова
Автор София Белова Редактор исследований и методологии

Brown et al. показали, что множество независимых попыток может заметно поднять качество LLM без нового обучения. Разбираем repeated sampling, результаты на SWE-bench Lite и главный предел метода — качество верификатора.

Схема repeated sampling: LLM генерирует множество независимых кандидатов, после чего верификатор через unit tests, proof checker или селектор выбирает корректный ответ

Работа Large Language Monkeys: Scaling Inference Compute with Repeated Sampling Брэдли Брауна и соавторов из Stanford, Oxford и Google DeepMind разбирает почти банальную, но практически важную идею: что будет, если давать модели не один шанс на ответ, а много независимых попыток. По записи arXiv, препринт появился 31 июля 2024 года, а доступная сейчас версия v3 датирована 30 декабря 2024 года. Авторы не обучают новую модель и не добавляют сложный поиск по дереву; они проверяют, как далеко можно зайти, если просто многократно сэмплировать ответы и потом выбрать верный через верификатор.

Для практиков это важно потому, что paper переводит разговор о test-time compute из общих слов в инженерную схему с тремя частями: генератор, бюджет попыток и механизм проверки. И именно на этой границе становится видно, где дополнительные попытки реально окупаются, а где всё упирается не в модель, а в слабый селектор.

Коротко

  • Repeated sampling — это многократная генерация независимых кандидатов с ненулевой температурой и последующий выбор ответа через верификатор.
  • Главная рамка Brown et al. — разделение на coverage и precision: модель должна не только иногда порождать правильный ответ, но и система должна уметь его распознать.
  • По авторским результатам Brown et al., на задачах с автоматической проверкой дополнительные попытки дают большой выигрыш: в их конфигурации на SWE-bench Lite score DeepSeek-Coder-V2-Instruct вырос с 15.9% при одной попытке до 56% при 250 попытках. Это именно результат авторов для их setup, а не независимый межлабораторный консенсус.
  • На задачах без сильного верификатора эффект быстро упирается в потолок: обычные majority vote и reward models у авторов почти перестают расти после сотен сэмплов.
  • Практический вывод: прежде чем платить за более крупную модель, имеет смысл проверить, есть ли у вашей задачи дешёвый и надёжный верификатор.

Контекст

До этой работы идея «давайте пробовать много раз» уже появлялась в нескольких формах. Self-Consistency Improves Chain of Thought Reasoning in Language Models предложила сэмплировать несколько цепочек рассуждения и брать наиболее согласованный ответ. Competition-Level Code Generation with AlphaCode показала, что в программировании массовое сэмплирование и фильтрация кандидатов могут быть не побочным трюком, а центральной частью системы. А работа The Larger the Better? Improved LLM Code-Generation via Budget Reallocation прямо поставила инженерный вопрос: лучше один запуск большой модели или несколько запусков маленькой при том же бюджете.

Новизна Brown et al. не в самой мысли «сэмплировать больше», а в том, что они пытаются сделать из неё общую, измеримую ось масштабирования вывода. Вместо разговора только о финальной accuracy авторы вводят два отдельных вопроса. Первый: coverage, то есть для какой доли задач хотя бы один из сэмплов оказался правильным. Второй: precision, то есть насколько хорошо мы умеем найти этот правильный сэмпл среди множества неправильных.

Это различение особенно полезно для практики. Если у вас есть unit tests, proof checker или другой точный автоматический критерий, то рост coverage почти напрямую превращается в рост итогового качества. Если такого критерия нет, repeated sampling быстро превращается в задачу «найти иголку в стоге сена», где правильный кандидат уже есть, но система выбора не умеет его распознать.

Ещё один важный контекст — исторический. Когда paper сравнивает свой результат с 43% single-attempt SOTA на SWE-bench Lite, речь идёт о состоянии бенчмарка и моделей на лето 2024 года, как это зафиксировано в самой работе. Это не утверждение о текущих лидербордах 2026 года.

Метод

Базовая процедура у авторов очень проста.

for problem in benchmark:
    candidates = sample(model, problem, n=N, temperature>0)
    verified = [verify(c) for c in candidates]
    answer = select(candidates, verified)

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

Ключевые определения такие:

  • Coverage: доля задач, для которых среди N сэмплов нашёлся хотя бы один правильный ответ.
  • Precision: способность системы выбора действительно вернуть правильный ответ, если он уже присутствует среди кандидатов.

Авторы рассматривают пять наборов задач. По их setup это подмножества GSM8K и MATH, формальные доказательства в MiniF2F, соревновательное программирование в CodeContests и реальные багфиксы в SWE-bench Lite. Для MiniF2F, CodeContests и SWE-bench Lite проверка автоматическая: proof checker или unit tests. Для GSM8K и MATH такого проверяющего контура нет, поэтому авторы вынуждены отдельно анализировать методы выбора ответа.

В кодовых задачах Brown et al. прямо приравнивают coverage к метрике pass@k. Это удобно для инженера: repeated sampling здесь фактически означает рост вероятности того, что хотя бы одна из k попыток пройдёт тесты.

Результаты

Ниже — ключевые числа из Brown et al. Для большинства именно этих конфигураций мы не нашли независимой репликации в других первичных источниках с теми же моделями, теми же промптами, тем же агентом и теми же бюджетами. Поэтому таблицу ниже стоит читать как авторский эксперимент, а не как окончательно установленный факт поля.

Сценарий Малый бюджет Больший бюджет Что это показывает
CodeContests, Gemma-2B По Brown et al.: pass@1 = 0.02% По Brown et al.: pass@10000 = 7.1% Даже слабая модель может резко увеличить coverage, если verifier точный и бюджет попыток большой.
SWE-bench Lite, DeepSeek-Coder-V2-Instruct + Moatless Tools По Brown et al.: pass@1 = 15.9% По Brown et al.: pass@250 = 56% Много попыток с дешёвой open-weight кодовой моделью могут обойти более сильные single-attempt системы в историческом setup лета 2024 года.
MATH, Llama-3-8B-Instruct, oracle verifier По Brown et al.: coverage 82.9% при 100 сэмплах По Brown et al.: coverage 98.44% при 10000 сэмплах Модель всё чаще «умеет» породить правильный ответ, если давать ей больше шансов.
MATH, те же кандидаты, но обычные селекторы По Brown et al.: лучший прирост около 40.50% По Brown et al.: лучший прирост около 41.41% Бутылочное горлышко смещается из генерации в выбор ответа: правильные решения уже есть, но селектор почти не умеет их находить.

Отдельно paper делает важный экономический ход. В таблице 1 Brown et al. сравнивают исторические API-цены и solve rate на SWE-bench Lite для конкретного агентного фреймворка Moatless Tools. По авторскому расчёту, пять попыток с DeepSeek-Coder-V2-Instruct решали больше задач, чем один запуск GPT-4o или Claude 3.5 Sonnet, и при этом были заметно дешевле в тогдашнем ценовом режиме. Здесь важно дважды оговориться: это исторический ценовой срез 2024 года и авторская конфигурация с конкретным агентом.

Не менее важен не только масштаб выигрыша, но и форма кривой. Brown et al. пишут, что зависимость между количеством сэмплов и coverage часто можно аппроксимировать степенным законом в экспоненте. Позднее работа How Do Large Language Monkeys Get Their Power (Laws)? уже в 2025 году предложила объяснение: на уровне отдельных задач вероятность неуспеха падает экспоненциально, а агрегированная «степенная» картина возникает из-за тяжёлого хвоста по сложности задач.

Интерпретация

Главный смысл paper в том, что repeated sampling превращает качество модели в задачу поиска по собственному распределению. Если базовая модель иногда уже попадает в правильное решение, то добавочные попытки покупают не новую способность, а лучший доступ к уже существующей способности. Именно поэтому метод особенно хорош в программировании, формальных доказательствах и других средах, где есть внешний критерий корректности.

Это также помогает точнее говорить о test-time compute. Не всякое «думать дольше» одинаково. Есть параллельный вариант — породить много гипотез и проверить их. Есть последовательный вариант — пересматривать и уточнять ответ. Brown et al. изучают в основном первый путь. А работа Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters показывает, что более адаптивные стратегии могут использовать бюджет вывода эффективнее, чем простой best-of-N.

Наш комментарий

Для практической разработки repeated sampling полезно воспринимать не как «магическую прибавку к IQ модели», а как очень дешёвую форму поиска, которая работает только при трёх условиях.

  • У базовой модели уже есть ненулевая вероятность иногда выдать правильный ответ.
  • У вас есть сильный и желательно автоматический верификатор.
  • Инфраструктура умеет батчить много попыток без неприемлемой задержки и стоимости.

Если хотя бы одно из условий нарушается, эффект быстро слабеет. Поэтому repeated sampling — не универсальная замена лучшей модели, а хороший рычаг именно для verifiable tasks.

Ограничения и критика

  • Большая часть headline-цифр — авторские результаты. Paper хорошо документирован и код открыт, но большинство ключевых чисел не являются многократно перепроверенным межлабораторным стандартом.
  • Не все эксперименты идут на полном тесте. Для GSM8K и MATH авторы, по собственному описанию setup, берут случайные подмножества задач, чтобы сдержать стоимость инференса. Это нормально для исследовательской статьи, но важно для интерпретации абсолютных процентов.
  • Метод силён там, где есть verifier. Brown et al. сами показывают, что на MATH без oracle-проверки рост coverage почти не превращается в рост финальной accuracy.
  • SWE-bench Lite шумный как измерительный прибор. В самом paper Brown et al. отдельно обсуждают flaky tests и показывают, что тренд сохраняется и после удаления проблемных задач. Но позже, по статье UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench от 10 июня 2025 года, в SWE-Bench Lite и SWE-Bench Verified обнаружились и более системные проблемы: недостаточные тесты и ошибочные pass-метки меняли позиции лидербордов. Это не отменяет идею repeated sampling, но делает абсолютные баллы по SWE-bench менее «твёрдыми», чем может показаться по одному графику.
  • Сравнение по цене быстро стареет. Стоимость API, лимиты контекста, latency и даже сами модели меняются быстрее, чем живёт исследовательская статья. Поэтому ценовой аргумент Brown et al. нужно читать как исторический кейс, а не как вечную формулу закупки инференса.
  • Repeated sampling не решает задачи с почти нулевой базовой вероятностью успеха. Если модель не умеет попадать в правильную область решений даже изредка, простое увеличение числа попыток будет сжигать бюджет почти впустую.

Итог

Brown et al. сделали важную вещь: показали, что дополнительный compute во время ответа можно масштабировать не только через более длинные рассуждения, но и через множество независимых попыток. Для задач с сильным автоматическим verifier repeated sampling действительно выглядит как дешёвый и практичный способ поднять качество без нового обучения.

Но работа так же ясно показывает и предел метода. Как только verifier слабый или неточный, выигрыш от дополнительных попыток почти перестаёт доходить до конечного пользователя. Поэтому главный вопрос для практики звучит не «сколько ещё раз запустить модель?», а «чем мы проверим, что одна из попыток действительно правильная?»

Источники

FAQ

Repeated sampling и self-consistency — это одно и то же?

Не совсем. Self-consistency — частный случай: модель сэмплирует несколько цепочек рассуждения и выбирает наиболее согласованный финальный ответ. Repeated sampling у Brown et al. шире: кандидаты могут проверяться unit tests, proof checker, reward model или другим селектором.

Когда repeated sampling особенно полезен?

Когда правильность ответа можно автоматически и дёшево проверить: через тесты, симулятор, формальный checker, вычислимый constraint или строгий бизнес-правилник.

Можно ли так заменить более крупную модель?

Иногда да, но не всегда. Brown et al. и Hassid et al. показывают, что на некоторых проверяемых задачах много попыток от более дешёвой модели могут быть выгоднее одного ответа от дорогой модели. Но это зависит от verifier, latency, стоимости и базовой вероятности успеха.

Почему метод хуже работает в открытых текстовых задачах?

Потому что там обычно нет точного верификатора. Модель может сгенерировать хороший ответ, но система выбора не умеет уверенно отличить его от убедительно звучащих, но неверных вариантов.

Читайте также