«Вы приносите промпты и функцию награды, инфраструктуру берём мы»: Google Cloud собрала практики RL-дообучения Gemini

Что Google Cloud вынесла в управляемый сервис

Обучение с подкреплением давно считается опорой посттренировки больших языковых моделей, но требует крупных тренировочных кластеров и доступа к внутренностям модели — того, чего у внешних клиентов проприетарных моделей вроде Gemini нет.

Решение Google Cloud — упаковать это в управляемый сервис RL-дообучения (RLFT): клиент приносит промпты и функцию награды, а вендор берёт на себя инфраструктуру и внутренности модели.

Смысл в том, чтобы адаптировать Gemini по сигналу награды, который вы определяете сами, вместо фиксированного набора размеченных ответов. Это открывает класс задач, которые трудно продемонстрировать, но легко оценить: идеальный SQL под каждую схему руками не напишешь, а выполнить запрос и проверить результат — можно.

Механика такая: на каждом шаге обучения сервис генерирует несколько вариантов ответа на ваши промпты, оценивает их вашей наградой и меняет модель так, чтобы более высоко оценённые ответы становились вероятнее, а сама модель при этом оставалась близка к исходной Gemini.

Сам алгоритм обучения полностью управляемый — его не конфигурируют. Единственное, чем владеет клиент и что сильнее всего определяет результат, — это награда.

Три свойства, которые задают границы метода

Свойство первое: RLFT учится на собственных выходах модели. Он уточняет то, что модель уже производит, вместо копирования внешней цели, и поэтому, по утверждению Google, меньше задевает способности, не связанные с задачей, чем SFT.

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

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

Когда RLFT оправдан, а когда нет

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

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

Двухступенчатая схема SFT → RLFT нужна, когда есть данные SFT или базовая доля успеха слишком низка, чтобы RL зацепился: SFT служит коротким и дешёвым разогревом, который держат лёгким, потому что переобучение на демонстрациях оставляет меньше пространства для RL, а дальше обучение продолжается через Continuous Tuning с инициализацией от чекпоинта SFT.

Пять сценариев с измеримым результатом

Первыми Google приводит игровых NPC: нужны реплики в образе и в рамках бренда на длинных многоязычных многоходовых диалогах, а готовые модели ломают погружение — путают язык, выдумывают предметы, игнорируют игрока и зацикливаются. Наградой здесь служит автооценщик Gemini (LLM-as-a-judge), который судит каждый ход по персоне, связности и синтаксису игрового состояния и штрафует ошибки формата и языка; в итоге, как утверждается, повторы и языковой дрейф исчезли, а синтаксис состояния удержался.

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

Третий — модерация контента, где нужно применять сложные политики и деревья решений в масштабе, а модели путаются в ложных срабатываниях и обходят оценку невалидным форматом. Здесь награда на Cloud Run соединяет проверку формата с детерминированным грейдером, чтобы удержать многошаговое следование политике: по описанию, модель разобралась со сложными исключениями, резко срезала ложные срабатывания и перестала обходить награду, что уменьшило объём эскалаций людям.

Четвёртый сценарий — код, измеряемый исполнением: запросы SQL или вызовы API оцениваются по тому, действительно ли они работают на данных клиента. SFT в такой задаче имитирует один эталонный запрос и ломается на незнакомых проприетарных схемах, а награда за исполнение запускает код в защищённой песочнице и платит только если он компилируется, выполняется и возвращает правильный результат; модель выдавала исполнимые с первого раза запросы при меньшей стоимости инференса.

Пятый — генерация презентаций в HTML/CSS, где обучение только на тексте слепо к визуальному качеству: переполнения, обрезанные элементы и разъезжающаяся типографика проходят незамеченными. Награда за исполнение рендерит слайды и оценивает визуальный дизайн, целостность вёрстки, структурную полноту и следование рубрике; на выходе, по описанию Google, получились модульные оформленные деки с единой темой и без переполнений.

Что нужно подготовить на входе

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

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

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

Что добавляет документация сервиса

Документация сразу обозначает статус: сервис — Pre-GA, продукты Pre-GA могут иметь ограниченную поддержку и несовместимость между версиями, а проприетарные, чувствительные и конфиденциальные данные использовать с ними нельзя; предоставляются они для ограниченного тестирования и оценки и не могут применяться в коммерческих или продакшен-целях.

Сейчас RL-дообучение поддержано для Gemini 3.5 Flash и Gemini 3.1 Flash-Lite в регионах us-central1 и europe-west4. Тюнинг работает на двух уровнях «мышления» — MINIMAL и HIGH (динамическое мышление) — и использует адаптеры, которые позволяют переиспользовать существующую инфраструктуру обслуживания.

В датасетах поддержаны текст, аудио, изображения и видео, причём видео — только для Gemini 3.5 Flash. Непрерывное дообучение допускается в двух вариантах: из SFT в RLFT и из RLFT в RLFT, а после успешного задания настроенная модель по последнему чекпоинту разворачивается на эндпоинте в проекте.

Отдельно оговорена цена: токены генерируются в двух фазах — сэмплирования и обучения, а для моделей начиная с Gemini 3 прогноз на эндпоинте дообученной модели стоит в 1,5 раза дороже базовой.