Стоит ли переходить с Sonnet 5 на 5.5: совместимость, расходы и откат

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

Руководство адресовано командам, уже использующим Sonnet 5. Оно посвящено решению о развёртывании, а не общему рейтингу моделей. Документация проверена 29 сентября 2026 года после выпуска Sonnet 5.5 28 сентября. Здесь не утверждается, что каждое приложение должно немедленно перейти на новую модель в production.

Что сохраняется и что проверять заново

Источники: страница Sonnet 5.5 и описание изменений. Неизменный токенизатор означает согласованную токенизацию одного входного текста, но не одинаковое число токенов в ответах двух моделей.

Сформулируйте гипотезу обновления

Запишите одну конкретную причину попробовать новую модель. Например: «сократить число повторов на наших ограниченных задачах исправления ошибок, сохранив долю прохождения регрессионных тестов». Другой вариант — меньше пропущенных обязательных разделов в черновиках документов. Это проверяемые гипотезы, а не улучшения, доказанные объявлением о выпуске.

Не меняйте одновременно промпт, поиск данных, инструменты и модель: при улучшении не будет понятно, что его вызвало. Сохраните старую конфигурацию и сравнивайте один набор задач. Если для допустимого запроса Sonnet 5.5 пришлось менять поля, зафиксируйте эту правку совместимости как часть новой конфигурации.

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

Совместимость проверяется раньше производительности

Приоритетны поддерживаемый режим thinking, принудительный вызов инструментов, история рассуждений, computer use и совместимость advisor. Sonnet 5.5 не принимает thinking.type: disabled. Документированная альтернатива без предварительных рассуждений — between_tools с effort high или ниже. Принудительные значения tool_choice тоже требуют миграции.

Примеры запросов и оговорки о платформах собраны в руководстве по ошибкам 400; здесь не повторяется вся диагностика. Включите в план проверки успешные ответы: приложение может получить HTTP 200, но не показать прогресс или не вызвать ожидаемый инструмент.

Проверьте парсер для обычного текста, вызовов инструментов, блоков рассуждений и отказов. При смене модели внутри диалога выясните судьбу несовместимых блоков. При правке ранних сообщений проверьте привязку. Один ответ на «hello» не подтверждает исправность полного агентного цикла в production.

Измеряйте качество и расходы вместе

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

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

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

Сохраните возможность отката

Сначала запустите обновлённую конфигурацию в изолированной тестовой среде. Если проверки проходят, выберите разрешённое ограниченное развёртывание, подходящее продукту. Зафиксируйте точную модель, настройки и время релиза, чтобы различать последующий трафик и старую версию. Не смешивайте версии незаметно в одном отчёте.

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

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

Сначала определите тип интеграции

У приложения, которое отправляет один запрос и читает финальный текст, меньше точек совместимости, чем у агента со сменой моделей, подписанной историей thinking и потоковым отображением инструментов. Классифицируйте приложение до замены ID. Это определит тесты, но не гарантирует одинаковых ответов простого приложения.

Корректный JSON не доказывает верность извлечённых фактов. Схема может требовать invoice_total, но сумму нужно сверить с документом. Вызов с правильными аргументами может обращаться не к той записи. Тест совместимости показывает возможность работы приложения, а тест задачи — полезность результата.

Платформа имеет значение. Действующее руководство указывает, что Sonnet 5.5 на Bedrock не поддерживает structured outputs, включая strict tool use. Старый инструмент computer use также обрабатывается по-разному. Нельзя переносить готовность одного endpoint на другой сервис. Рядом с ID фиксируйте семейство endpoint.

Минимальный регрессионный набор под ваше приложение

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

Для каждого случая запишите необходимое поведение и явный отказ. Извлечение может требовать точных суммы, валюты и ссылки на источник; выдуманные отсутствующие данные означают провал. Кодовый тест должен падать на базе и проходить после патча, без редактирования приёмочного теста. Документ должен содержать исходные факты в заданных разделах, без придуманных цитат.

Для парсера сохраните исходную структуру ответа и видимый пользователю результат. Проверьте правильный блок текста, отсутствие thinking в роли финального ответа и поведение интерфейса при пустом прогрессе. Sonnet 5.5 может изменить промежуточную структуру при успешном запросе. Проверка только HTTP-кода пропустит такую регрессию.

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

Опишите обе конфигурации, включая значения по умолчанию

Сохраните ID модели, endpoint, версии SDK и клиента, thinking, effort, выходной лимит, хеш системного промпта, хеш схем инструментов и версию поиска. Даже пропущенные поля имеют действующие значения по умолчанию, которые нужны в записи. Для Sonnet 5.5 API это high, а для Claude Code — medium: одинаковое имя модели не гарантирует одинаковый старт в двух клиентах.

Сохраняйте неизменный базовый commit или версию конфигурации. Если нужны новые поля, создайте отдельную конфигурацию 5.5 вместо перезаписи единственного старого запроса. Возврат ID со всё ещё несовместимыми полями 5.5 — ненадёжный откат. Не помещайте секреты в отчёт: хешей и нечувствительных настроек достаточно для идентификации.

По официальным данным у Sonnet 5 и 5.5 одинаковы tokenizer и прайс. Это помогает сопоставить идентичный вход, но не определяет длину выхода и поведение инструментального цикла. Начните с прежнего промпта, если совместимость не требует изменения. Последующую настройку сохраните отдельно, чтобы не приписывать всё улучшение только новой модели.

Превратите результаты в решение о выпуске

Разделяйте отказы совместимости, задачи и эксплуатации. Отклонённое поле — совместимость. Правильно оформленный ответ с неверной суммой — ошибка задачи. Таймаут или недоступная зависимость — эксплуатация. Любой из них может заблокировать выпуск, но исправления различаются. Одна общая «точность» скрывает следующий шаг.

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

Если из двадцати задач обе версии приняли восемнадцать, эквивалентность ещё не установлена. Старая могла провалить два малозначимых черновика, новая — финансовое извлечение и миграцию. Сопоставляйте ID и тяжесть отказов, не только 90% с 90%. Изучайте новые сбои, повторяйте неоднозначные случаи и оставляйте размер малой выборки в решении.

Откат должен восстановить поведение

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

При срабатывании условия отката прекратите новые задачи на новой конфигурации, восстановите рабочий адаптер и обработайте текущие задачи по сохранённому состоянию. До повтора сверяйте внешние действия с неясным исходом. Сохраняйте ошибочные ответы и usage для расследования с защитой чувствительных данных. Откат production не требует стирать свидетельства новой версии.

Итоговая запись должна перечислять пройденные фикстуры, нерешённые проблемы, исполнителя или механизм приёмки и резервную конфигурацию. Если доступ к модели или платформе препятствует запуску, статус — «подготовлено, не проверено». Чтение документации и локальная проверка формы запроса полезны, но не равны успешной сквозной миграции.

Что читать дальше

Для расчётов есть руководство по цене, для настройки — сравнение уровней effort. Если вопрос в переходе на более крупную модель, используйте Sonnet против Opus, не объединяя тест версии со сменой класса модели.