Как перейти с Gemini 3.6 на 3.7 Flash: безопасная миграция по шагам
Замена имени модели в коде занимает минуту. Надёжная миграция — дольше: нужно проверить параметры API, формат сообщений, инструменты, расход токенов и возможность отката. Ниже — рабочий план для небольшого сервиса или внутреннего агента.
Основа гайда — официальная инструкция Google. Не отправляйте в тесты секреты, реальные персональные данные и материалы, для которых не согласован облачный обработчик.
Шаг 1. Зафиксируйте исходную точку
Запишите точный model ID, версию SDK, средний расход токенов, задержку и долю успешно завершённых задач. Сохраните 20–50 обезличенных примеров: короткие, длинные, ошибочные и с вызовом каждого инструмента.
Важно оценивать не «красивый ответ», а критерий приёмки: правильный JSON, прошедшие тесты, отсутствие лишних изменений, верная ссылка на источник.
Шаг 2. Проверьте несовместимые параметры
Для Gemini 3.x Google требует убрать устаревшие параметры семплирования temperature, top_p, top_k и candidate_count. Вместо числового thinking_budget используется уровень thinking_level: low, medium или high.
Начните с medium. high оставьте для действительно сложных задач: он может увеличить задержку и расход. low проверяйте на коротких процессах, где важна скорость.
Шаг 3. Проверьте историю диалога
Для продолжения серверного диалога используйте previous_interaction_id. Не смешивайте старый формат заранее заполненного ответа модели с новым процессом. На тестах обязательно включите длинную цепочку и восстановление после ошибки.
Шаг 4. Прогоните инструменты отдельно
Для каждой функции подготовьте минимум три случая:
- нормальный вызов с полными аргументами;
- отсутствующее обязательное поле;
- потенциально опасное действие, которое должно быть заблокировано.
Проверяйте call_id, имя функции и фактические права среды. Модель не должна получать право записи или отправки сообщения только потому, что умеет вызвать инструмент.
Шаг 5. Установите бюджет задачи
Определите максимум входных и выходных токенов на один цикл, число циклов, долю повторных запусков и стоимость ручной проверки. Рассчитать сценарий можно в планировщике стоимости ИИ-агента.
Сравните Gemini 3.7 Flash и Gemini 3.5 Flash-Lite: дорогая модель не обязана выполнять все подзадачи, если классификацию и извлечение полей надёжно закрывает Lite.
Шаг 6. Запустите теневой режим
В течение нескольких дней отправляйте одинаковые обезличенные задачи в старую и новую версии, но пользователю показывайте только проверенный результат текущей системы. Сравнивайте:
- долю принятых ответов;
- число лишних правок;
- ошибки структуры;
- вызовы не тех инструментов;
- стоимость принятого результата;
- p50 и p95 задержки.
Шаг 7. Подготовьте откат
Model ID должен задаваться конфигурацией, а не быть размазан по коду. Сохраните совместимую версию SDK и переключатель возврата на 3.6 Flash. Откат нужен при росте критических ошибок, расходов или задержки, а не только при полном падении сервиса.
Шаг 8. Переключайте постепенно
Начните с небольшой доли трафика и простых сценариев. Увеличивайте её после проверки метрик. Задачи, которые меняют данные, публикуют контент или тратят деньги, оставьте под человеческим подтверждением.
Минимальный чек-лист приёмки
- контрольная выборка не содержит секретов;
- все функции проверены на ошибочных аргументах;
- лимит расходов срабатывает;
- логирование не записывает чувствительные данные;
- есть рабочий переключатель отката;
- важные действия требуют подтверждения;
- тариф и региональная доступность перепроверены.
FAQ
Можно ли сравнить модели на пяти запросах?
Этого достаточно только для первичной проверки интеграции. Для решения о миграции нужна выборка, отражающая реальные типы и сложность задач.
Нужно ли использовать high для всех запросов?
Нет. Уровень рассуждения — часть бюджета. Используйте минимальный уровень, который стабильно проходит критерии приёмки.
Что важнее: цена токена или число токенов?
И то и другое, плюс число повторов и стоимость проверки человеком. Итоговая метрика — цена принятого результата.
Что важно проверить на практике
Третий шаг — договориться об остановке. Если модель не видит источник, меняет число, нарушает разметку или предлагает действие с внешним эффектом, результат отправляется на ручную проверку. Сохраните пример ошибки, чтобы не спорить о впечатлениях.
После пробного запуска измерьте время до принятого результата и количество ручных правок. Повторите тест на другом примере через несколько дней. Только стабильный процесс стоит расширять на команду; единичный удачный ответ ещё ничего не доказывает.
Начните с результата, который можно проверить. Для темы «Как перейти с Gemini 3.6 на 3.7 Flash: безопасная миграция по шагам» запишите исходные данные, формат ответа и человека, который принимает итог. Если критерий готовности нельзя сформулировать заранее, сначала уточните задачу, а не выбирайте новую модель.
Первый шаг — собрать небольшой набор примеров: обычный, пограничный и заведомо сложный. Удалите персональные данные, сохраните исходные версии и подпишите дату. Такая выборка показывает реальные ограничения лучше, чем демонстрация на одном удачном запросе.
Второй шаг — разделить работу на этапы. Сначала получите черновик, затем отдельно проверьте факты, структуру, формат и тон. Не просите исправить всё одним длинным запросом: независимые проверки легче повторить и передать коллеге.
Сохраните исходник и финальную версию рядом. Через неделю вернитесь к примеру и отметьте, что пришлось исправить. Такая маленькая история правок превращает публикацию в практический материал, а не в пересказ возможностей.