Соберите 30–50 своих реальных задач с эталонными ответами, прогоните на них 2–3 модели-кандидата с одинаковым промптом и параметрами и сравните три вещи: долю правильных ответов, стоимость 1000 задач и задержку ответа. Побеждает не лидер общего рейтинга, а модель, которая даёт достаточно правильных результатов при приемлемых для вас цене и скорости.
Почему публичные бенчмарки не отвечают на ваш вопрос
Бенчмарк — это стандартный набор тестовых заданий, по которому сравнивают модели. Он показывает средний результат на чужих задачах, часто на английском и на коротких вопросах. Ваши входы могут быть длиннее, содержать таблицы, профессиональные термины или требовать строгого JSON на выходе.
Есть и вторая причина. Публичные наборы широко известны, и часть примеров могла попасть в обучающие данные моделей. Тогда высокий балл отражает знакомство с тестом, а не умение решать вашу задачу. Поэтому рейтинг полезен только для первичного отбора кандидатов, а решение принимается на своих данных.
До старта запишите, что именно считаете успехом. Например: «из счёта извлечены четыре поля, JSON валиден, ответ приходит быстрее 10 секунд, тысяча задач стоит не дороже заданного бюджета». Без такого критерия сравнение превращается в спор о вкусах.
Кандидатов отбирайте по цене за токен, размеру контекстного окна, доступности API и поддержке нужного языка. Характеристики и лимиты берите из официальной документации провайдера на дату теста: названия моделей и тарифы меняются быстро, а обзоры-пересказы отстают. Свежие Новости технологий о выходе новой версии — повод перепроверить свой набор, а не причина менять выбор без прогона.
Сборка собственного тест-сета: сколько примеров и какие
Берите примеры из реальной работы, а не придуманные. Для каждого сохраните входные данные и эталон — то, что вы считаете правильным ответом. Минимум для одной задачи — 30 примеров; на 10 штук разница в один ответ даёт сразу 10 процентных пунктов и легко оказывается случайной.
Включите в набор типовые запросы, 10–15% сложных и пограничных случаев, а также редкие форматы: длинный текст, таблицу, смешанный русско-английский ввод. Так вы увидите не средний балл, а место, где модель ломается.
- Храните тест-сет с версией и датой: набор, изменённый в середине эксперимента, обнуляет сравнение.
- Не берите примеры из публичных наборов, на которых могли обучаться модели.
- Размечайте, что проверяете: точность факта, формат ответа, тон, полноту.
- Обезличьте данные перед отправкой в API: уберите имена, номера договоров и контакты, если политика это требует.
Единый протокол запуска: промпты, параметры и условия
Все модели должны получить одни и те же входы и одинаковые настройки. Зафиксируйте системную инструкцию, шаблон запроса, температуру (параметр случайности ответа: 0 делает ответ максимально повторяемым), лимит длины ответа и формат вывода. Запишите точное название модели и дату прогона.
Сделайте 3–5 повторов на каждой модели. Модель с температурой выше нуля может ответить по-разному на один и тот же запрос, и единичный удачный ответ ничего не доказывает. Повторы показывают разброс: если ответы скачут, для рабочей задачи это важнее среднего балла.
Логируйте сырые запросы и ответы, идентификатор прогона и ошибки API. Отдельный прогон с промптом, доработанным под каждую модель, допустим как дополнительный сценарий — но основной вывод делайте на одинаковом промпте, иначе сравниваете не модели, а качество ваших подсказок.
Метрики: качество, стоимость и скорость в одной таблице
Для задач с однозначным ответом — число, классификация, извлечение поля — считайте долю правильных ответов. Для открытых ответов задайте критерии и оценивайте по одному за раз: «все ключевые факты на месте», «нет выдуманных деталей», «уложился в лимит слов».
Стоимость считайте не по прайсу за миллион токенов, а по расходу на вашу задачу. Умножьте среднее число входных и выходных токенов на цену провайдера и получите стоимость 1000 задач. Задержку фиксируйте двумя числами: время до первого токена и полное время ответа, отдельно медиану и 95-й процентиль — значение, которое не превышают 95% ответов, потому что редкие долгие ответы мешают работе.
| Модель | Качество, % | Стоимость 1000 задач | Задержка p95, с | Ошибки API |
|---|---|---|---|---|
| A | 88 | средняя | 6 | 0 |
| B | 81 | вдвое ниже A | 4 | 1% |
| C | 90 | средняя | 18 | 0 |
Итоговый балл считайте с весами под свою задачу. Если ошибка в сумме недопустима, качество получает вес 0,7, а цена — 0,2; для массовой рассылки веса сместятся в сторону стоимости. Числа в таблице иллюстративные: подставьте свои замеры и пересчитайте.
Пример: сравнение трёх моделей на извлечении данных из счетов
Задача: из текста счёта достать номер, дату, сумму и ИНН в JSON. Тест-сет — 40 счетов, включая несколько с плохим распознаванием. Критерий успеха — все четыре поля верны и JSON валиден; за три поля из четырёх даётся частичный балл.
- Разметьте эталоны: 40 счетов на 4 поля — 160 значений.
- Прогоните три модели с одинаковым промптом и JSON-схемой, температура 0, по 3 повтора.
- Сверьте каждое поле с эталоном: совпало или нет.
- Посчитайте долю полностью корректных счетов и стоимость 1000 задач по фактическому расходу токенов.
Допустим, модель A дала 88% полной корректности при средней цене, модель B — 81% и вдвое дешевле, модель C — 90%, но с задержкой p95 втрое выше. Если счета обрабатываются пакетно ночью и ошибки в сумме критичны, берите C. Если нужен потоковый разбор писем и редкая ошибка допустима, разумнее B или A. Вывод зависит от ваших весов, а не от места в рейтинге.
Типичные ошибки и как их избежать
Самая частая — вывод по одному-двум примерам. Второй промах — разные промпты и параметры у моделей: тогда вы сравниваете настройки, а не модели. Третий — игнорировать цену и задержку, когда качество почти одинаковое.
- Не меняйте тест-сет в середине эксперимента.
- Не принимайте единичный удачный ответ за стабильность.
- Сверяйте названия моделей и тарифы с документацией провайдера перед каждым прогоном.
- Считайте стоимость по расходу токенов на вашей задаче, а не по рекламной цене за миллион.
- Проверяйте, что ответы не содержат выдуманных полей: для извлечения данных это отдельная метрика.
Как оформить результат и когда пересматривать сравнение
Отчёт на одну страницу: цель, версия тест-сета, условия прогона, таблица метрик, итоговый балл и ограничения. Приложите промпты, ответы и скрипт подсчёта — через месяц вы не вспомните, почему выбрали модель, а воспроизвести прогон будет легко.
Пересматривайте сравнение при выходе новой версии модели, изменении цен или состава задач. Если доля сложных примеров в работе выросла, добавьте их в набор и прогоните заново. Так выбор остаётся решением на данных, а не привычкой.
Сколько примеров нужно, если модели идут почти вровень?
Начните с 30 и добавьте ещё 20–30 именно тех случаев, где модели расходятся. Если разница сохраняется на расширенном наборе и повторных прогонах, она устойчива; если исчезает — модели для вашей задачи равноценны, выбирайте по цене и задержке.
Можно ли оценивать открытые ответы без ручной разметки?
Можно, если критерии проверяемы автоматически: наличие обязательных полей, валидность JSON, лимит слов, отсутствие запрещённых формулировок. Смысловую точность и тон надёжнее проверять выборочно вручную, иначе оценка покажет умение проверяющего скрипта, а не модели.
Что делать, если у моделей разный формат ответа?
Задайте единую схему вывода в промпте и считайте несоответствие схеме отдельной ошибкой. Если модель не поддерживает нужный параметр, отметьте это в отчёте и не смешивайте её результат с остальными без оговорки.
Как часто повторять сравнение?
При смене версии модели, тарифов или заметном изменении входных данных. Для стабильной задачи достаточно перепроверки раз в квартал: прогон на сохранённом наборе занимает меньше часа и защищает от незаметного ухудшения.