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

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

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

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

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

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

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