Предложили вышеупомянутый метод Budget forcing, где можно задать минимальное и максимальное количество токенов в test time. Для форсирования ответа используется end-of-thinking token delimiter и строка “Final Answer:”, для форсирования размышлений — подавление генерации end-of-thinking token delimiter и строка “Wait”. В качестве бейзлайна сравнивали с __(I) Conditional length-control methods__, когда в промпте говорят, какой длины ответ нужен (там внутри несколько разных методов про длину в токенах, в шагах и общая рекомендация генерить подлиннее или покороче), и __(II) Rejection sampling__, когда генерим, пока не попадём в заданный бюджет. 🏁Evaluation При оценке смотрим не только на точность, но и на контролируемость. На фиксированном бенчмарке варьируем test-time compute и получаем кусочно-линейную функцию с зависимостью точности от длины размышлений. Измеряем несколько метрик: * Control — доля ответов вписавшихся в бюджет (мин/макс количество токенов). * Scaling — наклон кусочно-линейной функции, положительный наклон хорошо и чем больше, тем лучше. * Performance — максимальное качество на бенчмарке. Проверяли на AIME24, MATH500 и GPQA Diamond. Сравнивались с серией o1 от OpenAI, DeepSeek R1 (оригинал и 32B дистиллят), Qwen QwQ-32B-preview, Sky-T1-32B-Preview, Bespoke32B, Google Gemini 2.0 Flash Thinking Experimental. В целом у модели достойный результат, качество приближается к Gemini. Перформанс растёт с увеличением количества размышлений. На AIME24 после шести Wait происходит насыщение. Majority voting не скейлится так хорошо, как форсирование более длинной цепочки размышлений. Абляции показали, что от датасета много зависит. Если пожертвовать одним из трёх принципов, качество выходит хуже. Обучение на полном 59K датасете даёт более высокое качество (но не то чтобы прям сильно), ценой сильно больших ресурсов, 394 H100 GPU часов против 7. Среди разных методов контроля длины budget forcing даёт максимальное качество на AIME24, отличную (100%) контролируемость и хороший скейлинг (у class-conditional control он повыше). Если попробовать просто сэмплить ответы нужной длины и отбрасывать что не вписывается (Rejection sampling), то так не работает, тренд скейлинга негативный — модель выдаёт более хороший результат при более коротком ответе (но для этого надо сэмплить сильно больше раз). Это всё очень прикольный результат, чисто SFT очень малого размера. Интересно, что будет, если таки совместить это с последующим RL.