Сначала решите, что именно сравниваете
Вопрос «какая модель лучше?» слишком широк. Опишите рабочее решение: например, извлечь из письма номер заказа, заявленную проблему и просьбу клиента, не назначая причину возврата. Укажите, что считается критической ошибкой, а что допустимым недостатком. Для одной задачи важна полнота полей, для другой — точность цитирования или умение остановиться при неполном входе. Без критерия команда будет менять оценку после каждого красивого ответа.
Подготовьте одинаковые условия
Используйте один и тот же набор входных примеров, формат ответа, системные ограничения, температуру или доступные параметры, инструменты и предел длины. Сохраните точное имя и версию модели, регион и способ доступа: интерфейс, API и развёрнутая копия могут вести себя по-разному. Если провайдер обновил модель во время проверки, отметьте это и не объединяйте результаты разных версий в одну таблицу. Не отправляйте чувствительные данные без разрешения владельца и проверки условий хранения.
Соберите не только простые примеры
Начните с обычных задач, затем добавьте короткий, неполный и противоречивый вход, опечатку, редкий случай и пример с отсутствующей опорой. Для каждого запишите ожидаемое поведение. Иногда правильный ответ — пустое поле, цитата источника или просьба уточнить, а не правдоподобное заполнение. Выборка должна отражать реальный поток: если в жизни большинство писем короткие, не делайте тест целиком из идеально оформленных длинных документов.
Оценивайте обезличенно и по рубрике
Спрячьте название модели и перемешайте ответы. Проверяющий отмечает фактологическую точность, полноту обязательных полей, соблюдение границ и необходимость существенной правки. Два проверяющих полезнее одного: расхождения показывают, что критерий пока неясен. Не превращайте субъективное «нравится» в точность. Для результата, который влияет на клиента или деньги, установите отдельный порог критических ошибок и ручное подтверждение.
Считайте экономику принятого результата
Сравните не только цену токена или тарифа. В полную стоимость входят повторные запросы, задержка, инструменты, хранение, контроль доступа, время сотрудника и исправление ошибки. Модель с дешёвым ответом может оказаться дороже, если редактор тратит на него больше времени. Зафиксируйте медиану и разброс задержки, а не только самый быстрый запуск. Если тест использует слишком маленький набор, обозначьте это как предварительное наблюдение, а не статистически надёжный вывод.
Сделайте вывод узким и проверяемым
Результатом сравнения должна быть рекомендация для конкретного маршрута: какая версия подходит, какие случаи передаются человеку, что нельзя автоматизировать и когда повторить тест. Сохраните входной набор, рубрику, дату, версии и журнал исправлений. Не переносите результат на другую задачу или обновлённую модель без проверки. Для повторяемого процесса используйте сравнение ответов двух моделей, а проверку фактических утверждений — в руководстве о проверке источников в ответе.
FAQ
**Сколько примеров нужно?** Столько, чтобы покрыть основные типы и известные сбои; универсального размера выборки нет. Для первичного пилота можно начать с нескольких десятков размеченных случаев, но результат считать предварительным. **Можно ли сравнивать модель и сервис с разными инструментами?** Можно, если цель — выбор готового процесса. Но отдельно фиксируйте, что именно сравниваете: саму модель, поиск, интеграцию или качество всей связки. **Что делать при равных результатах?** Выбирать по приватности, цене принятого результата, стабильности, удобству проверки и возможности перейти на другой вариант.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.