Эксперимент: сравнение производительности четырёх ИИ-моделей на типовых задачах разработки
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Автор провёл независимое тестирование четырёх моделей Claude на пяти стандартных программистских задачах, выявив, что младшие модели справляются с рутинной работой не хуже старших. Ключевые различия проявились в корректности обработки граничных условий и скорости выполнения, где самая дорогая модель оказалась самой быстрой.
Ценность: Исследование демонстрирует, что для типовых задач разработки использование самых мощных и дорогих ИИ-моделей не всегда оправдано. Результаты помогают разработчикам оптимизировать расходы на автоматизацию, выбирая инструменты с учётом специфики задач и требований к надёжности.
В ответ на дискуссию о целесообразности использования наиболее интеллектуальных ИИ-моделей для рутинных задач автор провёл практический эксперимент. В тестировании приняли участие четыре модели из семейства Claude: Haiku 4.5, Sonnet 5, Opus 5 и Fable 5.1. Все они выполняли пять одинаковых задач на Python, от исправления ошибок в пагинации до сложного рефакторинга и распределения суммы с учётом копейных остатков. Каждую задачу каждая модель решала дважды, что дало в сумме сорок прогонов. Для проверки использовался скрытый скрипт, исключающий возможность манипуляции видимыми тестами со стороны моделей.
Результаты показали, что четыре из пяти задач все модели решили безупречно в обоих прогонах. Это свидетельствует о том, что для стандартных операций, таких как переименование функций или базовая нормализация данных, разница в цене между моделями не влияет на качество кода. Однако пятая задача, связанная с делением суммы на несколько частей с учётом отрицательных значений, выявила существенные различия в логике рассуждений.
Особого внимания заслуживает поведение младшей модели Haiku 4.5. Она дважды предоставила решение, которое формально проходило видимые тесты, но содержало скрытый баг при работе с отрицательными числами. В отчёте модель отмечала выполнение требований, хотя её код нарушал условие о распределении остатка первым участникам списка. Старшие модели Opus и Fable корректно обработали этот граничный случай, а Fable даже самостоятельно написала дополнительный скрипт для перебора всех возможных комбинаций сумм и делителей, чтобы убедиться в правильности решения.
Интересным наблюдением стала скорость выполнения. Вопреки ожиданиям, самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой. Это объясняется меньшим количеством «ходов» и объёмом генерируемого текста. Младшая модель тратила значительно больше токенов на рассуждения (18 754 против 2 674 у старшей), что замедляло процесс, несмотря на более высокую скорость генерации токенов в секунду.
Автор также провёл дополнительные замеры с изменённым уровнем детализации рассуждений (reasoning). При снижении уровня с high до low модель Opus стала самой быстрой, сохранив 100% точность, тогда как Sonnet допустила ошибки на сложной задаче. Стоимость при этом снизилась примерно на треть, что подтверждает, что основной расход ресурсов приходится на входной префикс агента, а не на сами размышления.
Вывод автора состоит в том, что для задач с чётко прописанными требованиями и тестами достаточно использовать младшие модели. Однако если в спецификации присутствуют нюансы вроде обработки отрицательных значений или пустых данных, целесообразно применять более мощные модели, которые способны лучше интерпретировать контекст и избегать скрытых ошибок. Надёжность результата зависит не столько от «интеллекта» модели, сколько от качества проверок, которые проводит разработчик.