Публичные лидерборды обновляются быстрее, чем команды успевают внедрять новые модели. Утром модель может появиться, к вечеру возглавить несколько рейтингов, а через пару недель уступить следующей версии. Для продукта, где LLM работает в контуре разработки, это создаёт практический вопрос: когда обновляться и как не сломать то, что уже работает.
В «Первой Форме» ИИ-агент помогает разработчикам: разбирает репозиторий, работает с инструментами, вносит правки и участвует в ревью. Состав моделей в этом контуре регулярно пересматривается. За последние недели команда обновила Muse Spark с версии 1.2 до 1.3, добавила Gemini 3.8 Flash и подготовила для него быстрый откат на предыдущую модель.
| Группа проверок | Результат Muse Spark 1.3 |
|---|---|
| Ревью с эталоном | 12 из 12 |
| Приёмочные регрессии | 8 из 8 |
| Работа с инструментами | 4 из 4 |
| Точность правок | 4 из 4 |
| Smoke-проверки | Пройдены |
Публичные бенчмарки в этом процессе играют ограниченную роль. Они позволяют заметить новую модель, понять её позиционирование, цену, размер контекстного окна и заявленные возможности. Но лидерборд отвечает на усреднённый вопрос: как модель справилась с определённым набором общих задач по методике конкретного рейтинга. В продукте вопрос звучит иначе: сможет ли эта модель выполнять наши задачи не хуже текущей, работать с нашими инструментами и не создавать дополнительных проблем в эксплуатации.
В контур добавлен Gemini 3.8 Flash с подготовленным быстрым откатом на предыдущую модель.
Есть и более общий риск: публичные тесты со временем становятся известны лабораториям-разработчикам, и они переобучают модели под них. Кроме того, поведение модели зависит от промпта, провайдера, режима вызова и обвязки вокруг неё. Поэтому публичный результат в «Первой Форме» воспринимают только как сигнал для отбора кандидатов.
Сам агент не привязан к одной модели. В контуре есть пул провайдеров, из которого модель выбирается с учётом заданных весов. Для отдельных случаев можно вручную запросить конкретную модель. Такой подход позволяет постепенно вводить новые модели, не делает продукт зависимым от одного провайдера, даёт возможность сравнивать модели на одинаковых сценариях и упрощает откат, если после включения обнаружится проблема.
Когда новая модель проходит проверку, старая версия не удаляется из конфигурации. Она переводится в состояние dormant: не участвует в обычном выборе, но остаётся готовой к возврату. Откат в этом случае — это изменение состава пула в конфигурации, которое проходит значительно проще. Эта деталь кажется небольшой, пока не возникает инцидент. В момент, когда нужно быстро вернуть предыдущее состояние, наличие уже подготовленной модели заметно снижает цену ошибки.
2 сентября команда сравнила Muse Spark 1.3 с использовавшейся версией 1.2. Обе модели запускались через один endpoint и получали одинаковые промпты. Это важно: если одновременно меняются модель, провайдер, системные инструкции и режим вызова, понять причину различий уже сложно. Проверка состояла из пяти групп внутренних сценариев: ревью изменений относительно эталона, регрессии по заранее внесённым дефектам, работа с инструментами и репозиторием, точность редактирования и базовые smoke-проверки.
Результат прогона: ревью с эталоном — 12 из 12, приёмочные регрессии — 8 из 8, работа с инструментами — 4 из 4, точность правок — 4 из 4, smoke-проверки пройдены. В этих сценариях версия 1.3 не показала ухудшений относительно 1.2. На части задач средней сложности, связанных с подготовкой текстового ответа, она работала примерно в 1,5 раза быстрее. На основании этого Muse Spark 1.3 вошла в рабочий пул вместо 1.2.
Команда отдельно оговаривает границы результата: она не заявляет, что Muse Spark 1.3 «лучше всех», и не публикует состав сценариев и способ их оценки. Формулировка «не хуже и быстрее» относится к конкретному прогону и конкретному набору задач.
Деплой не заканчивается сменой конфигурации. После включения новой модели нужно проверить, что агент использует именно её, а система не перешла на fallback и не оставила в логах скрытых ошибок. После обновления Muse команда сделала отдельный живой probe: отправила запрос через нужный маршрут, подтвердила по техническим данным, что ответ пришёл от Muse Spark 1.3, проверила отсутствие признаков fallback и убедилась, что в журналах исключений нет новых ошибок.
Такой probe занимает немного времени и защищает от распространённой ситуации: конфигурация выглядит верной, а фактический запрос по другой причине обслуживает предыдущая модель или резервный провайдер. Для «Первой Формы» это обязательная часть смены модели. Ответ от агента сам по себе ещё не означает, что его дала именно та модель, которую включили в пул.
