Урок 1. Зачем нужны эвалы и из чего они состоят

Промпт написали, пару раз потыкали, ответы вроде норм — выкатили. Через неделю поменяли одну строчку в промпте, и снова: потыкали, вроде норм. Проблема в том, что «вроде норм» — не измерение. Вы не знаете, стало ли лучше, и не узнаете, пока не пожалуется пользователь.

Вот две цитаты команды Solutions Architects из Anthropic — они объясняют, почему это главная боль:

Неспособность команды измерить качество своей модели — самый большой блокер вывода LLM в продакшн. Именно из-за этого промптинг остаётся искусством, а не наукой.

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

Разработчики не пишут эвалы по двум причинам: многие вообще не знают, что это такое, и почти никто не понимает, как их реализовать на практике. Курс закрывает обе дыры. Этот урок — про первую.

Бенчмарки — не про вас

Одна форма оценки знакома всем — бенчмарки моделей. Это стандартизированные тесты мира ИИ: как баллы ЕГЭ дают вузу общее представление об абитуриенте, так бенчмарки дают общее представление о способностях модели.

Компании-разработчики прогоняют модели по тестам с названиями вроде ARC, MMLU или TruthfulQA и публикуют результаты в карточках моделей. Тесты покрывают всё: от понимания текста до сложных рассуждений и знаний в разных областях. Для сравнения моделей между собой и отслеживания общего прогресса — вещь полезная.

Но это не вся история. Это как знать чей-то IQ: возможно, он что-то говорит об общем интеллекте человека — а возможно, и нет, — но точно не говорит, справится ли он с вашей конкретной работой.

Что даёт эвал

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

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

Здесь и появляются эвалы (их также называют прикладными или клиентскими оценками). Это систематические тесты, которые измеряют, как связка «модель + промпт» работает на вашем сценарии. Мост между общими способностями LLM и конкретными требованиями вашего продукта.

Что вы получаете:

• Итеративное улучшение промпта — версия v2 действительно лучше v1 на моей задаче?
• Контроль качества до и после деплоя — последняя правка промпта не сломала ничего из того, что работало?
• Объективное сравнение моделей — можно ли перейти на новую модель и не потерять в качестве?
• Экономия — можно ли перейти на самую дешёвую и быструю модель и сохранить текущий результат?

Работа с промптом при таком подходе идёт по кругу:

1. Собираем тестовые случаи.
2. Пишем черновик промпта под свою задачу.
3. Прогоняем промпт по всем тестовым случаям и измеряем результат — получаем базовую оценку (baseline).
4. Меняем промпт и повторяем: сравниваем новую оценку с базовой.

Суть эвалов — превратить качество связки «промпт + модель» в число. Без количественного измерения непонятно, ведут ли правки промпта к улучшению или вы просто ходите по кругу.

Из чего состоит эвал

У хорошо спроектированного эвала четыре части:

• Входные данные — вопрос или задание, которое уходит в модель. Важно, чтобы они были похожи на то, что реально приходит в ваше приложение, а не на удобные примеры из головы.
• Эталонный ответ (golden answer) — правильный или идеальный ответ, с которым сравнивается вывод модели. Качественные эталоны часто требуют участия предметных экспертов.
• Ответ модели — то, что реально выдала LLM на этот вход.
• Оценка — количественное или качественное значение, показывающее, насколько модель справилась с этим случаем. Как именно её ставить, зависит от задачи и выбранного грейдера.

Как собрать тестовый набор

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

eval_data = [
    {
        "complaint": "Приложение вылетает каждый раз, когда я загружаю фото",
        "golden_answer": ["Программная ошибка"]
    },
    {
        "complaint": "Компьютер не видит мой принтер",
        "golden_answer": ["Неисправность оборудования"]
    },
    {
        "complaint": "Не могу разобраться, как поменять пароль",
        "golden_answer": ["Ошибка пользователя"]
    }
]

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

Три способа оценивать

Выбор грейдера определяет, насколько вообще полезен ваш эвал. У каждого подхода свои сильные стороны и своя область задач.

Грейдер-код

Оценку ставит программа. Подход идеален для задач с чёткими объективными критериями: например, если LLM извлекает из текста конкретные поля, код проверит, совпали ли они с ожидаемыми значениями.

Главные плюсы — скорость и масштабируемость: один раз настроили и прогоняете тысячи случаев быстро и одинаково. Минус — код плохо справляется с нюансами и субъективными ответами.

• Точное совпадение строк — самый строгий вариант: ответ модели должен совпасть с эталоном символ в символ. Как тест с одним верным вариантом: на вопрос «Столица Франции?» принимается только «Париж».
• Наличие ключевых слов — проверяем, что в ответе есть нужные слова или фразы, независимо от порядка. В боте поддержки на запрос «Как сбросить термостат SmartHome?» ответ обязан содержать «удерживать», «кнопка», «5 секунд», «мигающий индикатор».
• Регулярные выражения — проверка сложных текстовых паттернов. Банковский бот, оценивающий право на кредитную карту, должен выдавать ответ по шаблону Ваш кредитный рейтинг \d{3} (позволяет|не позволяет) оформить карту \w+ — так мы гарантируем, что в ответе есть и рейтинг, и вердикт.
• И многое другое.

Грейдер-модель

Оценку ставит другая LLM (иногда та же самая). Вы пишете грейдинг-промпт с критериями, и модель судит ответы. Это середина между кодом и человеком: сложнее и субъективнее, чем умеет код, но быстрее и масштабируемее, чем люди.

Цена — нужен аккуратный промпт-инжиниринг для грейдера, иначе оценки будут нестабильными. И всегда есть риск, что модель-судья принесёт собственные искажения.

• Качество саммари — насколько пересказ краток и точен?
• Оценка тона — соответствует ли ответ голосу бренда?
• Любой другой критерий — можно описать свою рубрику под что угодно: насколько ответ извиняющийся? упоминает ли конкурента?

Грейдер-человек

Для задач, где нужно тонкое понимание или субъективное суждение, человек остаётся золотым стандартом. Люди — часто предметные эксперты — читают ответы модели, оценивают качество и ставят баллы.

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

• Экспертная проверка — специалисты оценивают ответы на точность и глубину. Для банковского бота про ипотеку юристы проверяют соответствие законам и корректность описания условий. Дерматологи оценивают советы модели по скринингу рака кожи: верно ли определена проблема, адекватна ли срочность, соответствует ли это актуальным исследованиям.
• Панель пользователей — группа людей оценивает ответы на понятность, полезность, вовлекающесть и прочие человеческие критерии.

Упражнения

Теория без рук не работает. Возьмите любую свою задачу с LLM — или ту, что предложена ниже.

Упражнение 1.1 — Выберите грейдер

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

1. Модель извлекает из письма дату и сумму счёта.
2. Модель пишет короткое саммари статьи.
3. Модель отвечает на медицинские вопросы пациентов.

Упражнение 1.2 — Соберите свой первый набор

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

eval_data += [
    {
        # два класса сразу — эталон содержит оба
        "complaint": "Принтер печатает полосами, и приложение при печати вылетает",
        "golden_answer": ["Неисправность оборудования", "Программная ошибка"]
    },
    {
        # формулировка обвиняет продукт, но это ошибка пользователя
        "complaint": "У вас всё сломано, я ввожу пароль и ничего не работает (капс был включён)",
        "golden_answer": ["Ошибка пользователя"]
    },
    {
        # не попадает ни в одну категорию
        "complaint": "Хочу узнать, будет ли скидка на подписку в чёрную пятницу",
        "golden_answer": ["Другое"]
    }
]

Что запомнить

• Проверка «на глаз» не измеряет ничего: без числа непонятно, стала ли новая версия промпта лучше.
• Бенчмарки моделей говорят об общих способностях, а не о вашей задаче. Прикладной эвал пишете вы.
• Эвал — это набор тестовых случаев плюс грейдер. Один случай = вход + эталонный ответ + ответ модели + оценка.
• Грейдер бывает трёх типов: код (быстро, объективно), модель (масштабируемо, субъективные критерии), человек (дорого, но золотой стандарт для экспертных областей).
• Anthropic рекомендует минимум 100 пар «случай — эталон»; собирать их надо из реальных и пограничных входов.
• Цикл работы: тестовые случаи → черновик промпта → базовая оценка → правки → сравнение с базой.