Выбирайте модель на основе проверок

Определите, какое решение принимаете

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

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

Используйте типичные задачи

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

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

Часть задач не используйте при разработке промпта. Если постоянно настраивать промпт на всех примерах, итоговый балл может завысить общие возможности. Отдельный набор помогает понять, работает ли улучшенный промпт за пределами примеров, на которых его создавали.

Обеспечьте сопоставимость

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

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

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

Оценивайте качество до скорости

Сначала проверьте обязательные критерии приёмки. Выполняет ли изменение требование? Сохраняет ли управление доступом? Проходят ли нужные тесты? Может ли проверяющий понять diff?

Затем сравните трудозатраты, общее время и стоимость приемлемых результатов. Учитывайте повторы и review человеком. Дешёвый ответ, который нужно многократно исправлять, может оказаться дорогим в расчёте на задачу.

Публичные benchmark помогают выбрать кандидатов. Они используют определённые наборы задач и способы оценки. Не считайте результат benchmark прямым измерением продуктивности команды.

Зафиксируйте решение и условия его пересмотра

Результатом может быть узкая рекомендация. Например: «Используйте эту модель для небольших дополнений тестов в этом репозитории с существующими требованиями к review». Одна модель для всех задач не нужна.

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

Цель оценки — снизить неопределённость конкретного решения. Не превращайте сравнение моделей в постоянное соревнование, которое требует больше усилий, чем работа, ради которой оно проводится.