я обучала одну модель

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

🌟 s1: Simple test-time scaling. Одна из самых прикольных и простых идей из недавнего: собираем маленький, но хороший датасет с трудными задачами (в основном математика), получаем reasoning traces решений (от Gemini), тренируемся без всякого RL, просто SFT. Test-time compute скейлим очень в лоб, а именно когда модель закончила генерить, добавляем "wait" к ее ответу и просим модель продолжать генерировать, и повторяем до тех пор, пока не наберется достаточное количество токенов. Файнтюн 32B модели в итоге превосходит o1-preview на задачках на олимпиадную математику. Понятно, что дело здесь не в магическом датасете или в волшебном слове "wait", а в том, что мы заставляем модель потратить очень много времени на генерацию и перепроверять свой ответ много раз.

В некоторых других статьях авторы тоже используют трюк с тем, чтобы гонять модель дольше, но более осмысленно передают ей фидбек. Например тут с помощью GRPO обучали модель-критика, задача которой оптимальным образом оценивать генерируемые решения и отмечать, что в них нужно улучшить, и заводили генерацию в multi-turn на несколько раундов. Кажется у NVIDIA в эксперименте с тем, чтобы заставить модель генерировать хорошие CUDA kernels, был такой же сетап: r1 сначала генерировала решения, потом некий verifier (о котором они ничего особо не сказали) поправляет промпт, и так по кругу, пока в итоге r1 не начинает генерить кернелы лучше, чем в торче.

Несмотря на то, что идея простая и рабочая, мне на этом фоне становится все больше интересно, что делали OAI с o3 моделями, чтобы повысить их эффективность и сократить длину рассуждений там, где задача полегче и не требует такого большого времени ответа. Даже в репорте про r1 авторы показывали, что чем дальше шла RL трена, тем длинее становился в среднем ответ, и под конец длина болтается около 10k токенов. Очевидно, что это бустит перформанс, но не для каждой задачи это нужно. В тему этого мне попалась одна статья про возможно более оптимальную архитектуру:

🌟 Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach. Тут у нас сотое по счету возрождение RNN. На входе и выходе у модели находятся слои фиксированного размера – prelude and coda (по сути энкодер и декодер). Между ними располагается реккурентный блок, который мы можем перепрогонять нужное количество раз at test-time. Например, рекурсия останавливается, если KL-дивергенция на между последними двумя итерациями меньше, чем какой-то заданный порог. Таким образом мы экономим на вычислениях, потому что вместо генерации chain-of-though (или reasoning trace, как угодно) в токенах, все размышления происходят прямо в latenet space. Кстати больше всего итераций модели понадобилось на бенчмарках про философию и моральные дилеммы, и только во-вторых на математических задачах 🥂

Обучать такую модель достаточно запарно, и про это много написано в разделе про тренировку, но я очень рекомендую целиком прочитать эту статью, она просто отлично написана. Тем более что им удалось эту архитектуру как-то даже хорошо заскейлить, пока не кончились ГПУ

Please open Telegram to view this post

VIEW IN TELEGRAM

www.group-telegram.com/us/def_model_train.com/1050

2.8K viewsedited  Mar 12 at 01:27

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

🌟 s1: Simple test-time scaling. Одна из самых прикольных и простых идей из недавнего: собираем маленький, но хороший датасет с трудными задачами (в основном математика), получаем reasoning traces решений (от Gemini), тренируемся без всякого RL, просто SFT. Test-time compute скейлим очень в лоб, а именно когда модель закончила генерить, добавляем "wait" к ее ответу и просим модель продолжать генерировать, и повторяем до тех пор, пока не наберется достаточное количество токенов. Файнтюн 32B модели в итоге превосходит o1-preview на задачках на олимпиадную математику. Понятно, что дело здесь не в магическом датасете или в волшебном слове "wait", а в том, что мы заставляем модель потратить очень много времени на генерацию и перепроверять свой ответ много раз.

В некоторых других статьях авторы тоже используют трюк с тем, чтобы гонять модель дольше, но более осмысленно передают ей фидбек. Например тут с помощью GRPO обучали модель-критика, задача которой оптимальным образом оценивать генерируемые решения и отмечать, что в них нужно улучшить, и заводили генерацию в multi-turn на несколько раундов. Кажется у NVIDIA в эксперименте с тем, чтобы заставить модель генерировать хорошие CUDA kernels, был такой же сетап: r1 сначала генерировала решения, потом некий verifier (о котором они ничего особо не сказали) поправляет промпт, и так по кругу, пока в итоге r1 не начинает генерить кернелы лучше, чем в торче.

Несмотря на то, что идея простая и рабочая, мне на этом фоне становится все больше интересно, что делали OAI с o3 моделями, чтобы повысить их эффективность и сократить длину рассуждений там, где задача полегче и не требует такого большого времени ответа. Даже в репорте про r1 авторы показывали, что чем дальше шла RL трена, тем длинее становился в среднем ответ, и под конец длина болтается около 10k токенов. Очевидно, что это бустит перформанс, но не для каждой задачи это нужно. В тему этого мне попалась одна статья про возможно более оптимальную архитектуру:

🌟 Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach. Тут у нас сотое по счету возрождение RNN. На входе и выходе у модели находятся слои фиксированного размера – prelude and coda (по сути энкодер и декодер). Между ними располагается реккурентный блок, который мы можем перепрогонять нужное количество раз at test-time. Например, рекурсия останавливается, если KL-дивергенция на между последними двумя итерациями меньше, чем какой-то заданный порог. Таким образом мы экономим на вычислениях, потому что вместо генерации chain-of-though (или reasoning trace, как угодно) в токенах, все размышления происходят прямо в latenet space. Кстати больше всего итераций модели понадобилось на бенчмарках про философию и моральные дилеммы, и только во-вторых на математических задачах 🥂

Обучать такую модель достаточно запарно, и про это много написано в разделе про тренировку, но я очень рекомендую целиком прочитать эту статью, она просто отлично написана. Тем более что им удалось эту архитектуру как-то даже хорошо заскейлить, пока не кончились ГПУ