Практика: как сравнить модели для кода на одинаковых задачах

Зачем проводить собственное сравнение

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

Хороший эксперимент не обязан быть большим. Даже 20 разнообразных задач дадут больше пользы, чем десятки повторов одного синтетического задания, если у каждой есть проверяемое условие успеха и одинаковые исходные данные. Цель — не найти абсолютного чемпиона, а увидеть профиль сильных и слабых сторон.

Соберите задачи из реального проекта

Возьмите закрытые или обезличенные задачи: исправить ошибку, добавить небольшой параметр, объяснить незнакомую функцию, дописать тест, обновить документацию и найти нарушение контракта API. Для каждой сохраните исходную ревизию кода, нужные файлы и тесты. Уберите секреты, внутренние адреса и персональные данные до передачи во внешний API.

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

Зафиксируйте протокол заранее

До запуска назначьте одинаковый лимит времени, число попыток, доступ к терминалу, инструменты и объём контекста. Версия модели и параметры генерации должны быть записаны. Не давайте одному кандидату полный интернет и shell, а другому — только фрагмент. Если ваша реальная разработка допускает несколько итераций, разрешите одинаковое число уточнений всем моделям.

Опишите критерии до того, как увидите имена результатов. Например: обязательные тесты пройдены; публичный интерфейс не сломан; нет изменения вне заявленной области; объяснение ссылается на реальные файлы; исправление понятно ревьюеру. Разделите критические нарушения и мелкие замечания. Ошибку безопасности нельзя уравновесить красивым объяснением.

Выполните запуск без утечки предпочтений

Соберите ответы под случайными метками A, B и C. Запустите каждую модель на чистой копии одного коммита. Если инструмент позволяет, сохраните команды и diff, а не только финальное сообщение. Сбросьте среду между попытками и проверьте, что тесты запускаются из одинакового состояния. В случаях, где модель делает несколько действий, сохраните журнал, чтобы видеть не только итог, но и лишние чтения файлов или команды.

Попросите не генерировать поясняющие рассуждения, которые не нужны вашей команде; оценивайте артефакт и краткое обоснование. Не позволяйте случайному ответу записывать в рабочую ветку, отправлять pull request или менять удалённые ресурсы. Эксперимент — это контролируемый тест, а не делегирование production-доступа.

Посчитайте больше, чем «прошло тесты»

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

Сделайте ручное слепое ревью минимум двумя разработчиками для спорных заданий. Разногласие — сигнал пересмотреть критерий или пример, а не повод выбрать удобного эксперта. Если разница между моделями меньше естественного разброса на повторных запусках, результат пока не даёт основания менять стек.

Сохраните воспроизводимость

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

FAQ

Сколько задач достаточно для первого пилота?

Начните с 15–30 типовых и пограничных задач, затем расширяйте выборку по обнаруженным ошибкам. Не называйте малый пилот универсальным рейтингом.

Нужно ли запускать каждую задачу много раз?

Повторите часть заданий, если ответы стохастические. Это покажет нестабильность, скрытую единичным удачным прогоном.

Как сравнить закрытое API и локальную модель?

Дайте обеим одинаковые задачи и разрешённые инструменты, но отдельно учтите качество, задержку, инфраструктуру, приватность и эксплуатационные затраты.

Что почитать дальше?

Сопоставьте это с проверкой агента в изолированной песочнице и журналом принятого решения.

Вывод

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