Сравнение ИИ-моделей в повседневных задачах: стоит ли платить за флагманы

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

Что и как я тестировал

Для эксперимента я сформировал тестовый набор из пяти типичных задач на Python, с которыми регулярно сталкиваюсь при разработке. Объем кода составлял от одного до пяти файлов:

• Ошибка пагинации (Off-by-one): исправление упавшего теста, где индекс сдвигался на единицу.
• Глобальный рефакторинг с подвохом: переименование конкретной функции по всему проекту. Сложность заключалась в том, что в одном месте имя функции передавалось строкой внутри словаря и вызывалось через getattr.
• Нормализация номеров телефонов: приведение номеров к единому формату по описанию правил простым текстом.
• Упрощение спагетти-кода: функция объемом порядка пятидесяти строк содержала тройное дублирование. Требовалось разбить ее на небольшие модули до двадцати строк без изменения итогового байтового вывода.
• Деление финансовых сумм: распределение счета между несколькими людьми с корректным учетом остающихся копеек. Дополнительное требование гласило: нераспределенный остаток отдается первым участникам в списке, а алгоритм должен корректно обрабатывать отрицательные суммы (возвраты средств).

В испытаниях участвовали четыре модели одной линейки различной ценовой категории: Haiku 4.5, Sonnet 5, Opus 5 и Fable 5.1. Все они запускались через единый кодинг-агент Claude Code в автономном режиме без сторонних интеграций (MCP был отключен). Для каждого прогона создавалась абсолютно чистая директория, а промпт остается неизменным. Каждую из пяти задач я запускал ровно по два раза на каждой модели, что в сумме дало сорок контрольных прогонов.

Проверку результатов я доверил скрытому скрипту. Модели не имели к нему доступа: он автоматически запускал тесты и контролировал, чтобы алгоритм не подправлял сами тестовые сценарии для искусственной успешности.

Стоит сразу оговориться: данный замер сделан в формате экспресс-теста. Задачи относительно небольшие, два прогона на каждую ячейку не претендуют на академический бенчмарк, а выборка ограничена одним семейством. Тем не менее полученные закономерности дают отличную пищу для размышлений.

Результаты и оценка эффективности

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

• Haiku 4.5: успешно решено 8 задач из 10. Общее время — 395 секунд, 100 шагов агента, 39 137 токенов на вывод. Относительная стоимость — 1x (базовая).
• Sonnet 5: успешно решено 9 задач из 10. Общее время — 450 секунд, 109 шагов агента, 31 359 токенов на вывод. Стоимость — 3,3x.
• Opus 5: успешно решено 10 задач из 10. Общее время — 557 секунд, 108 шагов агента, 39 455 токенов на вывод. Стоимость — 6,9x.
• Fable 5.1: успешно решено 10 задач из 10. Общее время — 341 секунда, 85 шагов агента, 23 010 токенов на вывод. Стоимость — 8,8x.

Главный неожиданный вывод: самая дорогая модель Fable 5.1 оказалась одновременно и самой быстрой. Ей потребовалась всего 341 секунда против 395 у самой доступной Haiku. Причина кроется в структуре рассуждений: старшая модель делает меньше лишних шагов и генерирует почти вдвое меньше текста. Младшая модель Haiku тратит гигантский объем токенов на внутренние рассуждения (18 754 токена против 2 674 у топовой). Хотя скорость выдачи токенов у младшей модели выше, из-за их количества общее время исполнения возрастает.

С другой стороны, модель Opus 5 показала самое медленное время выполнения — 557 секунд. Это доказывает, что правило «чем дороже, тем быстрее» работает далеко не всегда. Оценивать производительность стоит по полному циклу выполнения задачи, а не по замеру генерации токенов в секунду.

Первые четыре задачи (пагинация, рефакторинг с getattr, нормализация телефона и разбиение функций) абсолютно все модели решили со 100% успехом — 32 успешных прогона из 32. Если ваша ежедневная рутина состоит из подобных типичных тасков, переплата в 8–9 раз за старшую модель не дает никакой практической выгоды.

В чём споткнулись модели: разбор пятой задачи

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

Стандартный подход к делению сумм в Python использует целочисленное деление с остатком. Например, деление 1000 на троих дает массив [334, 333, 333] — остаток в 1 копейку отправляется первому человеку. Однако при обработке отрицательной суммы в -1000 стандартное деление в Python округляется вниз, из-за чего результат превращается в [-333, -333, -334]. Лишняя копейка уходит в конец списка. С логической точки зрения происходит абсурд: при обычном платеже человек заплатил на копейку больше других, а при возврате получит на копейку меньше.

Результаты по этой задаче распределились следующим образом:

• Haiku 4.5: провалила оба прогона, выдав ошибку с ушедшей в конец списка копейкой.
• Sonnet 5: справилась в одном случае из двух.
• Opus 5 и Fable 5.1: успешно прошли все 4 прогона. Они сначала вычисляли распределение для модуля суммы, а затем применяли знак возврата. В отчетах старшие модели отдельно пояснили это решение. Fable в одном из прогонов даже самостоятельно написала дополнительный скрипт, проверив варианты сумм от -300 до 299 для разного количества людей.

Особенно примечателен отчет младшей модели Haiku. В финальном резюме она рапортовала: «✓ Остаток достается первым в списке; ✓ Работает для возвратов: split_bill(-100, 3) = [-33, -33, -34]». Модель вывела две галочки успеха подряд, хотя вторая строчка наглядно противоречит первой. Тест прошел, отчет выглядит убедительно, но в реальном продакшене баг вылезет на первой же операции возврата.

Практические выводы: как я распределяю задачи

По итогам эксперимента я сформулировал для себя простые правила работы с кодинг-агентами:

• Четко сформулированные задачи с покрытием тестами я без опасений отдаю дешёвым младшим моделям. Они отлично справляются с базовым кодом и обходятся почти на порядок дешевле.
• Если в ТЗ присутствуют неоднозначные краевые условия, формулировки вроде «учитывай отрицательные значения», «обработай пустые входящие данные» или «сохрани прежнее поведение», я подключаю флагманские модели. Младшая модель корректно напишет синтаксис, но запросто упустит скрытый смысл логики.
• Никогда не стоит слепо верить текстовому отчету модели о том, что «все работает». Доверять можно только автоматизированным проверкам. Наличие одного скрытого теста на граничные случаи обойдется значительно дешевле, чем вызов самой дорогой нейросети.

GPT-6 Astra взломала радиограмму Enigma 1941 года, над которой бились 21 год

Параллельно со сравнением моделей в рутине приходят интересные новости из сферы криптоанализа. Сотрудник Bloomberg Картер Леффен применил модель GPT-6 Astra в режиме Extra High для расшифровки оригинальной немецкой военной радиограммы под кодом MVUEH от 10 июля 1941 года.

Сообщение состояло всего из 82 зашифрованных символов и хранилось в архивах криптографического проекта CryptoCellar. Как отметил эксперт по шифровальным машинам Enigma Фроде Вайеруд, исследователи пытались подобрать ключ к этой конкретной записи начиная с 2005 года. В некоторых источниках появилось ошибочное утверждение, будто шифр не могли разгадать 83 года, однако в действительности целевые попытки взлома начались именно с момента цифровой публикацией записи в 2005 году.

Леффен поставил перед GPT-6 Astra достаточно обобщенную задачу: проанализировать оставшиеся нерасшифрованными тексты из базы CryptoCellar и попытаться вскрыть один из них. Сама работа ИИ-модели до момента нахождения правильного ключа заняла около десяти часов непрерывных вычислений. Весь комплекс исследований с проверкой источников и воспроизведением результата занял у исследовательской группы два дня.

Источник: habr.com