Умная модель для рутины: эксперимент с четырьмя моделями и пятью задачами
В погоне за экономией разработчики часто полагают, что для рутинных задач достаточно дешёвых языковых моделей. Новый эксперимент, проведённый на практике, бросает вызов этому мнению. Сравнение четырёх моделей одного семейства на идентичных задачах показало, что самая дорогая версия не только решает задачи быстрее, но и демонстрирует критическое преимущество в логике вывода, несмотря на значительную разницу в стоимости.
# Нужна ли умная модель для рутины? Эксперимент с четырьмя моделями
В последнее время в профессиональном сообществе разгорелась дискуссия о целесообразности использования самых мощных и дорогостоящих языковых моделей для выполнения рутинных задач. Мнения разделились: одни утверждают, что для простых задач вполне хватает «бюджетных» вариантов, упрекая в этом лишь вопросы скорости вывода. Другие же сомневаются в качестве дешёвых решений. Автор этого исследования решил не спорить словами, а проверить эффективность на практике.
Было проведено сравнение четырёх моделей одного семейства (от младшей к старшей: Haiku 4.5, Sonnet 5, Opus 5 и Fable 5.1). Каждая из моделей получила пять идентичных задач, связанных с программной рутинной работой (рефакторинг, исправление багов, нормализация данных). Для каждого запуска использовался один и тот же агент и один и тот же промпт, что позволило исключить влияние переменных и сосредоточиться на сравнении моделей.
Техническая методология и выборка задач
Чтобы результаты были объективны, автор подготовил набор из пяти типовых задач, которые часто встречаются в реальной разработке на Python:
1. Исправление Off-by-one ошибки в пагинации. Стандартная задача на устранение падения тестов из-за неверного подсчета страниц. 2. Переименование функции. Сложная задача, включающая рефакторинг всего проекта, где имя функции задано строкой в словаре и вызывается через динамический метод getattr. 3. Нормализация российских номеров телефона. Задача по упрощению кода (разбиение дублирующихся блоков на функции малого размера) с сохранением точности ввода-вывода байт в байт. 4. Делёж счёта. Реализация алгоритма деления суммы между n людьми с учётом специфических требований к округлению копеек, включая обработку отрицательных сумм при возвратах.
Каждую задачу модели выполняли дважды (два прогона), что в совокупности дало 40 тестовых запусков. Для проверки достоверности результатов использовался скрытый скрипт, незаметный для самой модели, который проверял выполнение условий и отсутствие подтасовок в видимых отчётах.
Сопоставление производительности и стоимости
Результаты эксперимента удивили даже автора. В ожидаемом сценарии, где более мощная модель требовала бы больше времени и ресурсов, получилась обратная картина. Самая дорогая модель, Fable 5.1, оказалась не только качественнее, но и быстрее остальных.
| Модель | Успехи | Время (с) | Ходов | Токенов вывода | Соотношение цены | | :--- | :---: | :---: | :---: | :---: | :---: | | Haiku 4.5 | 8/10 | 395 | 100 | 39 137 | 1× | | Sonnet 5 | 9/10 | 450 | 109 | 31 359 | 3,3× | | Opus 5 | 10/10 | 557 | 108 | 39 455 | 6,9× | | Fable 5.1 | 10/10 | 341 | 85 | 23 010 | 8,8× |
Ключевым фактором скорости стала не просто скорость генерации токенов, а количество необходимых «ходов» (итераций) для решения задачи. Старшая модель совершила меньше ходов и сгенерировала почти вдвое меньше текста для ответа. Однако это не универсальное правило: модель среднего уровня Opus 5 оказалась самой медленной, что свидетельствует о том, что стоимость не всегда напрямую конвертируется в скорость выполнения.
Качество логики и анализ ошибок
Четыре из пяти задач были решены всеми моделями без единого сбоя. Разница в качестве ярко проявилась лишь на последней задаче — делёже счёта. Здесь требования включали обработку отрицательных сумм, где «лишние копейки должны достаться первому в списке».
Младшая модель, Haiku 4.5, продемонстрировала критическую ошибку. Она написала решение, которое корректно делило положительную сумму, но при возврате (отрицательное число) распределяло копейки несправедливо. В своём отчёте модель дважды поставила галочки, подтверждая уверенность в правильности результата, хотя вторая часть кода полностью опровергала логику первой.
В то же время старшие модели (Opus и Fable) продемонстрировали глубокое понимание нюансов. Они использовали модульное деление для основной части и применяли логику знака для корректного распределения остатка. Более того, модель Fable 5.1 самостоятельно написала дополнительный скрипт, перебирая различные сценарии с отрицательными числами для верификации своего алгоритма, что не требовалось в исходном промпте.
Что означает «размышления»?
Важно отметить параметр «токенов размышления». Младшая модель потратила около 18 754 токенов на генерацию мысли перед ответом, в то время как старшая модель использовала лишь 2 674 токена. Парадокс в том, что старые модели генерируют токены быстрее, но заставляют их генерировать значительно меньше. В сумме это делает процесс более эффективным.
Выводы и рекомендации
Эксперимент подтвердил, что при решении сложных задач, требующих глубокого понимания контекста и нюансов, «бесплатный сыр бывает в мышеловке». Дешёвые модели могут успешно справляться с чистой рутинной работой, где требования четко определены и не содержат скрытых ловушек (32 прогона из 32 выполнило 4 младшие модели). Однако при наличии неочевидных граничных случаев, таких как работа с отрицательными числами, преимущество умной модели становится решающим.
Практический совет: Рекомендуется использовать модель среднего или высокого уровня для задач, где важна логическая целостность, а дешевую модель — для простых, хорошо протестированных задач. В обоих случаях наличие скрытых тестов (валидация результатов «на ты») является критически важным для обеспечения качества.
Для программистов это означает необходимость переоценки затрат на использование API: иногда экономия на вычислительной мощности оборачивается ростом времени отладки и поддержкой кода, написанного с ошибками в логике.