Выбирайте AI-модели по личным evals, а не только по рейтингам
Лидерборд полезен как первый сигнал, но плох как финальное решение. Модель на первом месте может выигрывать публичные предпочтения и все равно плохо писать ваши письма поддержки, помогать с код-ревью, работать с таблицами, агентскими процессами, бюджетом или задержкой. LM Arena и Chatbot Arena полезны, но не заменяют ваши реальные задачи.
Публичные рейтинги сжимают промпты, аудиторию, метод оценки и продуктовый интерфейс в одно число. Ваш случай уже: тон бренда, риск, стоимость, скорость, приватность, инструменты и допустимые ошибки. Для общей ориентации можно прочитать наш гайд Claude vs GPT, но выбирать лучше по собственному eval set.
Соберите репрезентативный личный eval set
Личный eval set — это небольшая коллекция реальных задач, критериев качества и правил оценки. Одному человеку часто хватает 20 хороших промптов. Небольшой команде обычно достаточно 50-100 кейсов, чтобы увидеть различия до миграции.
Берите недавнюю работу: тикеты поддержки, sales-письма, комментарии code review, продуктовые спецификации, чистку таблиц, исследовательские вопросы, конспекты встреч и агентские workflow. Уберите приватные данные, но оставьте сложность: длинный контекст, неоднозначные инструкции, многоязычный текст, плохие входные данные и ограничения безопасности. Для разработки полезны AI for developers guide и GPT-5 developer migration playbook.
Напишите рубрику до сравнения
Не оценивайте после того, как узнали модель. Сначала задайте правила: успех задачи 0-3, фактическая надежность 0-3, следование инструкциям 0-3, применимость 0-3. Снимайте баллы за опасные действия, выдуманные факты, утечки приватности и чрезмерную уверенность.
Для субъективных задач добавьте тон, краткость и соответствие бренду. Для кода используйте тесты, если можно. Для инструментов проверяйте, выбрала ли модель правильный инструмент, запросила ли недостающие данные и остановилась ли вовремя. Если eval включает инструменты, полезна статья про MCP, CLI и function calling.
Примеры промптов
Исследование: по пяти фрагментам источников резюмировать решение, перечислить открытые вопросы и отметить claims, требующие проверки.
Поддержка: клиент злится из-за двух сбоев экспорта; ответить без обещания даты исправления, запросив один диагностический факт, до 140 слов.
Код: по падающему тесту, функции и diff предложить минимальный вероятный фикс и проверки перед изменением.
Закупка: сравнить три AI writing tools только по предоставленным заметкам, разделив факты и предположения.
Агент: имея календарь, черновик email и CRM, определить, какие шаги требуют подтверждения перед переносом звонка.
Полезные источники: Anthropic про testing and evaluation, OpenAI про custom evals and graders и Hamel Husain про LLM evals.
Регрессия, стоимость и задержка
Модель на 5% лучше, но в три раза медленнее может быть хуже для продукта. Дешевая модель, молча ошибающаяся в рисковых задачах, дорого обходится поддержке. Записывайте модель, дату, версию промпта, задержку, примерную стоимость, pass rate, серьезные ошибки и заметки.
Смотрите категории, а не только среднее. Одна модель может побеждать в письме, другая в extraction, третья в безопасном использовании tools. Это означает routing, а не единственного чемпиона. Для браузерных агентов см. AI browser automation stack guide.
Когда запускать evals заново
Повторяйте оценку при новых моделях, изменениях цены, routing провайдера, крупных правках prompts, новых правах инструментов, обновлении retrieval corpus или изменении бизнес-процесса. Одному пользователю достаточно раз в месяц прогнать 10 любимых prompts; indie hacker должен запускать риск-набор перед сменой default; покупатели AI-инструментов оценивают до закупки, до rollout и после реального использования.
Цель не в том, чтобы стать исследователем evals. Цель — использовать публичные рейтинги для короткого списка, а решение принимать по собственной работе.