Как сравнить две ИИ-модели без подгонки запроса под любимую

Почему один и тот же тест легко сделать нечестным

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

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

Шаг 1. Опишите одну задачу

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

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

Шаг 2. Соберите контрольные примеры

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

Разделите примеры на набор настройки и отложенную проверку. На первом можно уточнить общие правила для обеих моделей, на втором промпт уже не меняют. Это помогает не «натренировать» оценку на нескольких знакомых случаях.

Шаг 3. Закрепите условия

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

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

Шаг 4. Оцените вслепую

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

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

Шаг 5. Добавьте время и стоимость

Учитывайте не только оплату API. Измерьте задержку, повторы, отказы, стоимость проверки и исправления. Если модель делает черновик быстрее, но сотрудник тратит ещё столько же времени на проверку, экономии может не быть. Для переменных тарифов посчитайте типичный, тяжёлый и пиковый запрос, а не только средний.

Проверьте повторяемость на нескольких запусках. Небольшое изменение ответа нормально для вероятностной системы; вопрос в том, меняются ли вместе с формулировкой факты и решения. Критическую задачу нельзя запускать в эксплуатацию, если результат нестабилен и команда не может объяснить критерий принятия.

Шаг 6. Примите ограниченное решение

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

Хороший итог теста иногда звучит как «пока не внедряем». Это нормальный результат: у команды остаётся список слабых мест и условия, при которых эксперимент можно повторить. Для источникового контроля используйте отдельный протокол проверки цитат; для документов — обзор OCR-процесса.

FAQ

Сколько примеров нужно?

Столько, чтобы включить типичные и рискованные случаи; маленький пилот не даёт статистической гарантии, поэтому вывод следует ограничить его объёмом.

Можно ли попросить одну модель улучшить слабый ответ, а другую нет?

Нет, если сравнивается модель. Правила повторной попытки должны быть одинаковыми либо отдельно учитываться как часть системы.

Кто должен оценивать ответы?

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

Что важнее — точность или скорость?

Зависит от последствий ошибки. Определите приоритет до теста; в задачах с серьёзным вредом скорость не компенсирует критическую ошибку.

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