Методология оценки и оценка AI-систем

Открытый текст нельзя оценить так же просто, как классификацию. Энтропия описывает неопределённость данных, cross-entropy добавляет расхождение между истинным и выученным распределениями, а perplexity показывает, насколько модель затрудняется предсказать следующий токен. Эти меры полезны разработчикам моделей, но низкая perplexity ещё не доказывает полезность приложения; слишком уверенный результат на тестовом корпусе может даже указывать на утечку бенчмарка в обучение. После preference tuning языковая метрика способна ухудшиться, хотя ответы станут удобнее людям. Метрика отвечает на вопрос только внутри своего уровня абстракции. Perplexity помогает сравнивать способность продолжать распределение текста, но пользователь может ждать правильного решения, понятного объяснения или безопасного отказа. Если команда не разделяет эти уровни, улучшение внутреннего показателя легко принять за улучшение продукта, хотя реальный сценарий остался прежним.

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

LLM-as-a-judge получает запрос, ответ, критерии и шкалу, а затем выставляет оценку. Это дешёвый и масштабируемый способ проверять фактическую согласованность, следование инструкции или стиль; более сильная модель может оценивать работу дешёвой и при провале перегенерировать ответ. Полезно сохранять reasoning судьи, чтобы понять низкий скор и вернуть замечание в следующий цикл. Но оценщик меняется вместе с версией модели, предпочитает собственные ответы и неоднозначно читает рубрики, поэтому его нужно калибровать и не принимать за окончательную истину. Калибровка означает сравнить его решения с размеченной людьми выборкой, отдельно разобрать ложные пропуски и ложные тревоги и зафиксировать версию промта и модели. Без этой воспроизводимости смена судьи незаметно меняет саму шкалу. Команда видит движение метрики, которое на деле вызвано новым оценщиком, а не новым качеством продукта.

Попарное сравнение часто надёжнее абсолютного балла: человеку или модели проще выбрать лучший из двух ответов, чем поставить объективную оценку от одного до пяти. Так строятся рейтинги, хотя порядок сравнений, нетранзитивные предпочтения и состав запросов способны исказить итог. Для важных фактов Евгений описывает более строгий контур: извлечь утверждения из текста, найти подтверждения и противоречия в доверенных источниках, присвоить источникам разный вес и передать эксперту ссылки. В медицинском контенте PubMed ценнее случайного обсуждения, а финальное решение остаётся у medical-legal reviewer. Такой пайплайн не просит судью «оценить правдивость текста» целиком. Он дробит ответ на проверяемые утверждения и оставляет человеку обозримый пакет доказательств. Стоимость выше, зато можно объяснить, какой факт не прошёл проверку и почему система остановила публикацию.

Сначала команда определяет критерии: доменные знания, способность генерировать нужный результат, следование инструкциям, стоимость и задержку. Hard constraints, например запрет выводить данные за контур, сразу исключают часть вариантов. Публичные описания и бенчмарки формируют короткий список, но выбирать победителя нужно на собственном gold set с рубриками. Человеческий baseline показывает, достигла ли модель практически достаточного уровня. Для разных подзадач лучшими могут оказаться разные модели, поэтому evals становятся правилами маршрутизации, а не только конкурсом одного общего победителя. Baseline важен и для экономики: система не обязана превосходить идеального эксперта, если задача сегодня выполняется новичком долго и нестабильно. Сравнение должно учитывать реального исполнителя, время проверки и цену исправления. Тогда выбор модели связывается с устройством процесса, а не с абстрактным лидербордом.

После выбора проверяются отдельные компоненты и весь end-to-end-путь: извлечение текста, retrieval, генерация, проверка и итоговый пользовательский результат. Команда описывает гайдлайны, собирает размеченные или синтетические примеры, выбирает сочетание детерминированных проверок, судьи и человека; стартовый gold set может быть небольшим и расти из производственных ошибок. Последний слой — бизнес-метрика. Если чат поддержки полезно закрывает половину запросов, дальнейшая погоня за лабораторным скором может не окупиться. Онлайн-мониторинг замыкает цикл и выявляет дрейф после смены модели, промта или поведения пользователей. Компонентный тест локализует причину, а end-to-end проверка показывает, сохранилась ли ценность после их соединения. Производственный инцидент должен возвращаться в набор как новый пример вместе с категорией причины. Так evals становятся памятью системы и условием безопасного изменения, а не разовой приёмкой модели.