Telegram-канал agi_and_rl - Агенты ИИ | AGI_and_RL: Unsorted

Агенты ИИ | AGI_and_RL

12 March 2025 14:58

Тренили OlympicCoder со следующими параметрами:

Базовая модель: Qwen2.5 Coder Instruct 7B and 32B
количество эпох: 10
батч сайз: 128
Learning rate: 4e-5
Scheduler: Cosine with a decay to 10% of the peak learning rate
длина контекста: 32,768 токенов для 7B и 22,528 токенов 32B

И вот что выяснили

Урок 1: packing ухудшает качество рассуждений

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

Без упаковки производительность улучшается в течение нескольких эпох, прежде чем стабилизируется.

Тем не менее, мы обнаружили, что во всех анализируемых датасетах упаковка давала худшие результаты.

(в trl трейнере за это отвечает параметр packing)

Урок 2: Используйте большой learning rate для лучшей производительности

Для большинства экспериментов SFT, которые мы проводили с моделями Qwen, lr 2e-5 обычно достаточна для достижения высокой производительности. Однако при применении SFT с данными рассуждений к уже существующей модели-инструктору, мы обнаружили, что значительное улучшение результатов можно получить, используя гораздо большую скорость обучения — 4e-5. Как показано на диаграмме ниже, каждое удвоение скорости обучения давало улучшение почти на 10 пунктов по LiveCodeBench!

Урок 3: Включение редакционных комментариев не повышает производительность

Когда мы создавали поднабор solutions_w_editorials из open-r1/codeforces-cots, наша интуиция заключалась в том, что, предоставив R1 проблему и решение, мы получим лучшие трассы рассуждений. Однако, к нашему удивлению, эта интуиция не подтвердилась при оценке: наивная выборка из описаний задач давала скромное, но последовательное улучшение в процессе обучения.

Урок 4: Используйте префилл с <think>, чтобы стабильно активировать длинные цепочки рассуждений

При тестировании некоторых наших моделей мы столкнулись с любопытным явлением: при подаче запросов из той же предметной области (например, по конкурентному программированию) модель генерировала ожидаемую длинную цепочку рассуждений, заключённую между токенами <think> и </think>, за которой следовал окончательный ответ. Однако для запросов из другой области, таких как «Какая столица Швейцарии?», модель возвращалась к поведению исходной модели-инструктора!

Это показывает, что при дистилляции трейсов рассуждений в уже обученную модель-инструктора следует по умолчанию использовать префилл в шаблоне чата финальной модели. Кстати, именно так поступает DeepSeek со своими дистиллированными моделями, и описанное выше поведение может быть объяснением их подхода.

Урок 5: Используйте 8-битные оптимизаторы для масштабирования больших моделей с длинным контекстом

На одном узле 8xH100 авторы смогли обучить модели с контекстом в 32k используя DeepSpeed ZeRO-3. Однако при попытке применить подход к 32B модели возникло множество проблем с памятью. В частности, наши эксперименты приводили к ошибке Out Of Memory, когда контекст увеличивался свыше 20к токенов, даже на 16 узлах 8xH100. А в датасете CodeForces-CoTs 20% трейсов больше 20к токенов, значит они бы обрезались во время трена.

Корень проблемы в том, что и трансформеры, и trl пока не поддерживают параллелизм по контексту, хотя по данной проблеме можно следить по соответствующему issue.

В то же время мы изучили различные техники экономии памяти и обнаружили, что сочетание FSDP с оптимизатором paged_adamw_8bit позволило нам масштабировать контекст до 22,528 токенов: всё ещё не идеально, но теперь обрезается только 9% данных.