Нужно разобрать документ, подготовить письмо или проверить код, но непонятно, какую версию выбрать? Я бы начал не с поиска «самой сильной», а с одного конкретного задания: так проще оценить ответ и не тратить время на абстрактное сравнение.
Как выбрать между Sonnet 4.6 и 5
Для редактуры, сводки по документу и ревью небольшого фрагмента кода я бы сначала попробовал Sonnet 4.6. Страница модели относит к её рабочим задачам код, аналитику, редактуру и клиентскую коммуникацию. Это отправная точка, а не обещание, что любой ответ окажется точным.
Sonnet 5 имеет смысл попробовать, когда задание состоит из нескольких связанных этапов: нужно сопоставить аргументы, учесть ограничения, затем выдать решение в заданном формате. Разработчик описывает её как улучшение относительно Sonnet 4.6 в рассуждениях, работе с кодом и профессиональных задачах. Но преимущество на вашей задаче лучше проверить одинаковым запросом, а не принимать на веру.
На сайте STIVA.ai, который также называют СТИВА ИИ, страницы моделей в каталоге - не подтверждение того, что обе версии сейчас доступны в настройках вашего чата. Проверьте список моделей в своём аккаунте до работы и не рассчитывайте цену по старой карточке: фактическое списание и условия смотрите в интерфейсе. Если доступны обе версии, выберите по качеству ответа на вашей задаче и его стоимости.
Первый запуск: короткий порядок действий
- Выберите страницу модели. Откройте страницу Sonnet 4.6 и проверьте, есть ли она в выборе модели вашего чата; если нет, не считайте карточку подтверждением доступа. Аналогично проверьте Sonnet 5.
- Сформулируйте результат, а не тему. Вместо «посмотри договор» напишите: «найди три риска для заказчика и покажи фрагмент, на котором основан каждый вывод».
- Отделите исходные данные от инструкции. Назовите блок «Текст», «Код» или «Черновик». Укажите адресата, ограничения и формат ответа.
- Проверьте итог по оригиналу. Сверьте цифры, цитаты и выводы. Если материала недостаточно, попросите перечислить вопросы, а не заполнять пробелы догадками.
Мне ближе запросы, в которых заранее понятно, как оценивать ответ. Ниже три примера: их можно копировать целиком, а затем заменить учебные данные своими. Не вставляйте в рабочий запрос сведения, которыми не готовы делиться в выбранном сервисе.
Пример 1. Найти риск в коротком документе
Начните с небольшого фрагмента, даже если позже планируете разбирать большой файл. Здесь проверка простая: каждый вывод должен опираться на конкретное предложение из исходника.
Ты - помощник по анализу деловых документов. Найди риски для заказчика в тексте ниже. Не считай это юридическим заключением.
Задача: назови до 3 рисков. Для каждого приведи точную цитату из текста, объясни последствие простыми словами и предложи вопрос для переговоров. Если данных недостаточно, напиши «нужны уточнения». Не придумывай пункты договора.
Формат: нумерованный список «Цитата / Риск / Вопрос».
<текст>
Исполнитель передаёт итоговый отчёт в течение 10 рабочих дней после получения материалов. Заказчик направляет замечания в течение 2 рабочих дней после получения отчёта. При отсутствии замечаний отчёт считается принятым. Порядок исправления замечаний стороны согласуют отдельно.
</текст>Проверьте, заметила ли модель короткий срок для замечаний и неопределённый порядок исправлений. Не выдавайте её формулировки за правовую оценку: для реального договора важны остальные разделы и контекст сделки.
Пример 2. Превратить вводные в письмо клиенту
Для письма полезнее дать точные факты и границы обещаний, чем просить «написать красиво». В этом примере дата и ситуация учебные; перед отправкой замените их подтверждёнными данными.
Ты - редактор клиентской переписки. Напиши письмо клиенту на русском языке.
Факты: отправка заказа планировалась на 16 октября, теперь ожидается 21 октября. Причина задержки не подтверждена. Менеджер сообщит обновление статуса 18 октября.
Адресат: клиент, который уже ждёт заказ. Тон: спокойный и уважительный. Объём: до 800 знаков. Признай задержку, назови новую ожидаемую дату и ближайший шаг. Не выдумывай причину, компенсацию или гарантию доставки. Если дата отправки не равна дате получения, не называй её датой получения.
Верни только тему письма и текст письма.Перед использованием проверьте даты и то, что письмо не превратило «ожидается» в безусловное обещание. Если это произошло, не переписывайте всё с нуля: укажите конкретную ошибку и попросите исправить только её.
Пример 3. Получить проверяемое ревью кода
При работе с кодом просите не только исправление, но и способ воспроизвести проблему. Так легче отличить полезную правку от уверенно написанного, но неподтверждённого объяснения.
Ты - Python-разработчик. Проверь функцию ниже. Сначала назови ошибки и покажи входные данные, на которых каждая проявляется. Затем предложи минимальное исправление и тесты для исходного и исправленного поведения.
Ограничения: сохрани имя функции и сигнатуру. Не добавляй внешние библиотеки. Если поведение на пустом списке неоднозначно, явно предложи правило и объясни выбор. Не утверждай, что запускал код.
<код>
def average(values):
return sum(values) / len(values)
</код>
Формат: «Проблемы», «Исправленный код», «Тесты», «Что проверить вручную».Здесь легко увидеть, обработан ли пустой список. Но предложенные тесты всё равно нужно выполнить в своей среде: текст ответа сам по себе не подтверждает работоспособность изменения.
Как сравнить версии без самообмана
Возьмите один из запросов выше и отправьте его обеим версиям без изменений. Затем сравните ответы по трём пунктам: соблюдён ли формат, подтверждены ли выводы исходными данными и сколько правок понадобится до использования. Для документа считайте неподкреплённый риск ошибкой; для письма ищите выдуманные обещания; для кода проверяйте тестами.
Не сравнивайте один аккуратный ответ с другим запросом, куда вы уже добавили подсказки. Если после первого прохода хотите улучшить результат, внесите одинаковое уточнение в оба диалога и снова проверьте по исходнику. Такой подход не докажет, какая модель лучше вообще, зато поможет выбрать подходящую для вашей повторяющейся задачи.
Что важно не переоценить
Страницы моделей описывают возможности широко, но не заменяют проверку конкретного результата. У Sonnet 4.6 отдельно отмечено, что для свежих событий нужны актуальные материалы в контексте. Для Sonnet 5 также не стоит считать, что запрос сам по себе даёт доступ к внешним системам: работа модели с инструментами и доступные действия в конкретном чате - разные вопросы. В примерах выше исходные данные передаются прямо в запросе, а итог проверяет человек.
В карточке Sonnet 5 разные разделы указывают разные годы выпуска. Официальные сообщения разработчика относятся к 2026 году, а не к указанному в одном разделе карточки 2025-му. Обе версии уже не являются новейшими в линейке Sonnet. Не стройте выбор на спорной дате карточки или обещании вместить документ любого размера. Практический критерий надёжнее: помещается ли ваш материал в доступный способ ввода и можно ли проверить ответ по первоисточнику.
