ainews
Gemini 3.6 Flash: когда улучшение на бумаге не гарантирует апгрейд в продакшене
Google выпустил Gemini 3.6 Flash с улучшениями на бенчмарках и на 17% меньшим расходом токенов. Но ранние тесты показывают возможные регрессии в генерации интерфейсов и пространственном мышлении. Автор предлагает методологию, как правильно тестировать новую модель перед апгрейдом: заморозить промпты и настройки, прогнать на реальных задачах, установить чёткие критерии отказа заранее — и использовать роутинг, а не слепую замену.
Если вы используете LLM в продакшене, слепой апгрейд на «улучшенную» версию может сломать критические сценарии. Методология автора помогает принимать обоснованные решения и избегать дорогих откатов.
Google анонсировал Gemini 3.6 Flash с улучшениями по ключевым метрикам. Модель на 17% экономнее расходует выходные токены по сравнению с версией 3.5, показывает рост на бенчмарках DeepSWE (49 против 37), MLE-Bench (63.9 против 49.7), OSWorld-Verified (83.0 против 78.4) и GDPval-AA v2 (1421 против 1349). Цена за миллион токенов снизилась до $7.50.
На бумаге это выглядит как чистый апгрейд. Но реальность сложнее.
Проблема: агрегированные метрики скрывают регрессии
В ранних отчётах всплыли регрессии в генерации фронтенда и пространственном мышлении. Правда, эти примеры не содержат полных промптов, настроек или воспроизводимых конфигураций — так что считать их доказательством деградации модели нельзя. Но они достаточны, чтобы заподозрить проблему.
Автор поста справедливо отмечает: агрегированный рост и узкие провалы легко уживаются. Бенчмарк усредняет результаты по своему набору задач. Ваше приложение может делать упор на категорию, которая почти не влияет на итоговый скор. Модель может стать лучше в агентах и работе с данными, но хуже в одном конкретном UI-паттерне. Общий балл растёт — ваш продукт ломается.
Методология принятия решения
Автор предлагает парное тестирование на реальной нагрузке перед апгрейдом:
- Заморозить всё: системный промпт, пользовательский промпт, инструменты, контекст, температуру, уровень «мышления», лимиты на вывод, политику повторов.
- Прогнать старую и новую модель на одних и тех же репрезентативных задачах, включая редкие, но дорогие сценарии отказа.
- Ослепить оценщиков: рандомизировать порядок ответов, где возможно.
- Измерить всё: процент принятых задач, критические ошибки, повторы, вызовы инструментов, латентность, токены, итоговую стоимость на принятый результат.
- Установить критерии отказа заранее — до просмотра результатов.
Последний пункт критичен. Если команда после теста решает, что регрессия «достаточно мала», оценка превращается в адвокацию модели. Предварительный порог заставляет решение следовать за рабочей нагрузкой.
Роутинг вместо глобальной замены
Автор призывает отказаться от идеи единого победителя. Если 3.6 Flash выигрывает на анализе документов, но проигрывает на фронтенд-задачах — это результат для роутинга. Оставьте старую модель для проблемной категории, используйте новую там, где она прошла порог.
Продакшен-единица — не просто «Gemini 3.6 Flash». Это модель + настройки + промпты + инструменты + рабочая нагрузка вместе.
Вопрос к сообществу: какой конкретный критерий отказа заставил бы вас оставить 3.5 Flash или роутить только часть задач, даже если агрегированные бенчмарки улучшились?
Ключевые выводы
- Агрегированные бенчмарки могут расти, пока модель деградирует на вашей конкретной задаче — усреднение скрывает узкие регрессии
- Решение об апгрейде модели требует парного тестирования на реальной нагрузке с заранее установленными критериями отказа
- Роутинг моделей по типам задач эффективнее глобальной замены: используйте новую версию там, где она лучше, и старую — где проседает
- Продакшен-единица — не сама модель, а связка: модель + промпты + настройки + инструменты + рабочая нагрузка
- Ранние скриншоты регрессий без полных промптов и настроек — повод для гипотезы, но не доказательство деградации модели
Автор: Артём Ковалёв · Источник: reddit.com
Это один из самых зрелых постов об оценке LLM, что я видел за последнее время. Автор не спорит с Google и не кричит «модель сломалась» на основе пары скриншотов — он предлагает инженерный подход: тестируй на своих задачах, фиксируй критерии заранее, не бойся держать две версии модели одновременно.
Особенно ценна мысль про роутинг. Мы привыкли думать категориями «какая модель лучше», но в реальности стоит вопрос «какая модель лучше для какой задачи». Если новая версия хороша в анализе данных, но проседает в UI-генерации — это не провал, это карта для умного роутинга. Именно так и строятся устойчивые продакшен-системы.
Комментарии