Почему 95% точности не отвечают на вопрос, готов ли ИИ к запуску

Предположим, система распределяет обращения поддержки. Большинство сообщений — обычные вопросы, а отмены и жалобы встречаются редко. Модель, которая всегда выбирает самый частый класс, может получить убедительную общую оценку и провалить именно важные сценарии. Поэтому число без распределения примеров почти ничего не говорит. Начните с перечня решений, которые принимает система, и последствий каждого неверного решения. Пропущенная отмена, лишнее уточнение и ошибочная метка темы имеют разную цену; оценка должна отражать это различие.

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

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

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

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

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

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

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