Победа в бенчмарке, которая не выдерживает столкновения с реальным кодом
Открытые модели, включая Kimi, GLM, DeepSeek и Qwen, часто демонстрируют впечатляющие результаты в бенчмарках, иногда даже сравниваясь с передовыми моделями, такими как Claude Opus от Anthropic (Claude) и Project Project Astra от OpenAI, или превосходя их. Однако эти победы часто зависят от контекста: они отражают результаты на конкретных самодостаточных задачах по программированию, а не весь спектр разработки ПО.
Ключевое различие заключается в сложности и продолжительности задач. Открытые модели хорошо справляются с короткими, отдельными задачами, где сильные способности к рассуждению можно применить к изолированным проблемам. Это делает их весьма эффективными для многих бизнес-автоматизаций и отдельных шагов рабочих процессов.
Реальная программная инженерия, напротив, требует от агента способности сохранять контекст, следовать меняющимся инструкциям и поддерживать архитектурные решения на протяжении множества вызовов инструментов и итеративных доработок. Именно такой согласованности в длительной работе открытым моделям пока не хватает.
Хотя бенчмарки дают ценные сигналы, они не полностью отражают сквозное мастерство в программировании. Ресурсы вроде SWE-bench обеспечивают более всестороннюю оценку возможностей модели в программной инженерии, показывая разрыв между результатами на изолированных задачах и устойчивой работой над проектом.
Где открытые модели действительно оправдывают себя
Тем не менее открытые модели оправдывают себя в более ограниченных контекстах. По практическому опыту Medin, в конкретных, замкнутых задачах — набросок функции, преобразование схемы или генерация модульных тестов — эти модели могут предложить качество, сопоставимое с передовыми моделями. Такое равенство распространяется и на многие рутинные шаги бизнес-автоматизаций.
Компании часто используют открытые модели, чтобы контролировать расходы и сохранять конфиденциальность данных, запуская их локально или через экономичные API. Модель высшего уровня, такая как Project Project Astra или Claude Opus 5.5, нужна не всегда, например для таких задач:
- Проверка данных
- Простая генерация контента
- Внутренняя логика маршрутизации API
Важно, что стоимость — это не простое сравнение цены за токен. Реальная цена успешного результата включает надёжность, частоту повторных попыток, трудозатраты людей на ревью и возможную стоимость неудачного изменения. Хотя открытые модели могут казаться дешевле по числу токенов, их ограничения в работе с контекстом в сложных долгосрочных задачах могут приводить к более высоким общим расходам из-за большего числа итераций и исправлений. Этот нюанс важен для эффективного распределения ресурсов.
Сбой в длительной работе: дрейф, повторные попытки и потерянные правила
Открытые модели заметно хуже справляются, когда рабочие процессы программирования расширяются по объёму. Medin отмечает, что они часто теряют из виду соглашения репозитория, игнорируют установленные ограничения и запутываются в дорогостоящих циклах «ревью — исправление». Этот «сбой в длительной работе» объясняется неспособностью сохранять внимание к растущему набору правил и контекста.
Чтобы оценить это количественно, Medin провёл контролируемый эксперимент по созданию игры Northstar. Он поручил трём моделям — Claude, OpenAI и Kimi — 12 тикетов на реализацию функций. Claude выполнил все 12 тикетов примерно за 14 часов. OpenAI завершил 11 тикетов, но потратил около 28 часов. Kimi, напротив, справился лишь с 5 тикетами за 44 часа.
Это сравнение — тест одного автора, а не универсальный рейтинг, — тем не менее наглядно показывает, как соблюдение инструкций и издержки на итерации могут влиять на итоги проекта. Открытые модели часто обходятся дороже в целом из-за повторного расхода токенов на исправления и повторные попытки, несмотря на более низкую цену за токен. Чтобы подробнее изучить методологии бенчмарков, обратитесь к SWE-bench Official Benchmark and Leaderboard.
Этот разрыв в результатах указывает на принципиальное различие в том, как модели справляются с долгосрочными задачами. Хотя открытые модели могут превосходно генерировать изолированный код, им трудно поддерживать устойчивое понимание контекста, необходимое для сложной разработки ПО, где модель должна вносить согласованные изменения в большую кодовую базу, соблюдая меняющиеся ограничения и принципы проектирования.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Гибридный рабочий процесс лучше, чем ставка «всё или ничего»
Вместо ставки «всё или ничего» гибридный рабочий процесс даёт пользу сразу. Отдельные, чётко очерченные задачи — например, набросок функции или преобразование схемы — направляйте открытым моделям, используя их экономичность и конкурентные результаты на ограниченных задачах. Передовые системы, такие как Claude Opus, оставьте для сложного архитектурного планирования, ответственного ревью и изменений, охватывающих большую кодовую базу.
Сохраняйте обвязку (harness) явной и надёжной. Разбивайте работу на более мелкие тикеты, обеспечивайте соблюдение соглашений о коде с помощью автоматических тестов и линтинга и непрерывно отслеживайте ключевые показатели. Фиксируйте долю завершённых задач, число повторных попыток, неудачные ревью и стоимость одного принятого изменения, чтобы объективно оценивать качество и эффективность моделей.
Открытые модели уже практичны, но равенство в бенчмарках не гарантирует, что они смогут обеспечить работу всей «фабрики ПО». Командам следует тщательно проверять модели на собственных рабочих процессах, передавая им больше ответственности по мере подтверждённого роста надёжности. Такой прагматичный подход, основанный на данных, позволяет стратегически использовать инновации с открытым исходным кодом, снижая риски дрейфа в длительной работе и нестабильного исполнения.
Часто задаваемые вопросы
Почему открытые модели могут показывать высокие результаты в бенчмарках по программированию, но испытывать трудности в реальных проектах?
Бенчмарки часто проверяют ограниченные задачи, тогда как реальные проекты требуют от агентов следовать правилам, сохранять контекст и принимать согласованные решения на протяжении многих шагов.
Полезны ли модели с открытыми весами для программирования с помощью ИИ?
Да. Они могут хорошо справляться с отдельными короткими задачами и рутинными шагами рабочих процессов, особенно когда задача чётко очерчена.
Что такое долгосрочная задача по программированию?
Это работа, охватывающая множество шагов, таких как планирование, редактирование файлов, запуск тестов, реагирование на замечания при ревью и поддержание согласованности во всей кодовой базе.
Как командам использовать открытые модели, не полагаясь на них во всём?
Используйте открытые модели для чётко определённых задач с более низким риском, а передовые модели оставьте для сложного планирования, ревью и работы, требующей устойчивого контекста.