Что такое evals и почему десяти красивых ответов недостаточно
Evals - это набор входных примеров, ожидаемых свойств результата, процедур проверки и правил принятия решения. Он отвечает не на вопрос «умная ли модель», а на гораздо более полезный: решает ли эта версия нашей системы конкретную задачу в допустимых границах качества, риска, скорости и стоимости.
Ручной просмотр нескольких удобных примеров создаёт иллюзию качества. Команда знает промпт, формулирует понятные запросы и невольно выбирает ответы, которые легче оценить. Реальные пользователи пропускают контекст, вставляют противоречивые документы, меняют формат и ожидают разный уровень подробности.
Оценивайте всю цепочку: системную инструкцию, модель, retrieval, инструменты, фильтры и постобработку. Замена любого звена способна улучшить одни случаи и незаметно сломать другие.
Начинайте с полезного результата, а не со списка метрик
Сначала опишите работу пользователя: что он передаёт системе, какое решение принимает по ответу и какой ущерб принесёт ошибка. Только после этого переводите ожидания в наблюдаемые критерии.
Разделите критерии на обязательные и желательные. Неверный IBAN, раскрытие персональных данных или вызов опасного инструмента могут быть блокирующей ошибкой, даже если текст получил высокие оценки за стиль.
Карта качества: от бизнес-цели к проверяемому признаку
| Ожидание | Наблюдаемый признак | Подходящая проверка |
|---|---|---|
| Ответ основан на документах | Каждое существенное утверждение поддержано фрагментом | Проверка цитат плюс экспертная выборка |
| Данные готовы к импорту | Валидная схема, типы и обязательные поля | JSON Schema и бизнес-валидаторы |
| Письмо соответствует тону | Нет канцелярита, давления и запрещённых обещаний | Рубрика и парное сравнение |
| Агент безопасен | Не выполняет действие без нужного подтверждения | Сценарии и анализ trace |
| Функция выгодна | Качество достигнуто в бюджете | Качество, задержка и стоимость вместе |
Не используйте расплывчатое «ответ хороший». Два разметчика понимают его по-разному. Рабочий критерий содержит объект проверки, шкалу, примеры границ и правило для неоднозначного случая.
Ты помогаешь проектировать eval для ИИ-функции. Сценарий: [что делает пользователь]. Вход: [данные]. Результат: [что система должна вернуть]. Риски: [что нельзя допустить]. Составь дерево качества. Для каждого критерия укажи: наблюдаемый признак, блокирующая ли ошибка, способ проверки, пример успешного и провального ответа. Не придумывай численные пороги: пометь их как параметры, которые нужно определить на размеченных данных.
Как собрать eval-набор, похожий на реальную работу
Хороший набор отражает распределение задач, но не ограничивается средними случаями. Возьмите обезличенные производственные примеры, обращения поддержки, типовые шаблоны и ошибки, найденные при пилоте. Добавьте редкие, но дорогие сбои.
- Частые стандартные запросы основных сегментов.
- Короткие, длинные, неполные и неоднозначные входы.
- Разные языки, форматы, каналы и типы файлов.
- Пограничные значения, пустые поля и конфликтующие источники.
- Исторические ошибки из обращений и инцидентов.
- Провокационные и adversarial-запросы.
- Случаи, когда система должна отказаться или задать вопрос.
- Случаи с несколькими допустимыми ответами.
Храните теги сегмента, сложности, риска и происхождения. Тогда общий балл можно разложить и увидеть, что улучшение произошло лишь на простых запросах. Удаляйте персональные и секретные данные согласно правилам организации.
Golden set, regression set и свежая контрольная выборка
Один файл с примерами быстро превращается в смесь разных назначений. Разделите данные. Golden set содержит тщательно проверенные примеры и эталонные свойства. Regression set фиксирует важные сценарии и уже найденные ошибки. Challenge set собирает крайние и атакующие случаи. Свежая контрольная выборка помогает заметить подгонку под известный тест.
Не обязательно иметь единственный идеальный текст. Для суммаризации или письма полезнее сохранить обязательные факты, запрещённые утверждения и рубрику. Для классификации, вычислений и структурированного извлечения эталон обычно строже.
Версионируйте набор и не меняйте прошлые результаты молча. Исправление ошибочной разметки должно иметь автора, причину и новую версию.
Детерминированные graders: сначала проверяйте то, что можно вычислить
Не поручайте модели-судье задачу, которую надёжнее решает код. Автоматические проверки дешевле, повторяемее и понятнее при разборе сбоя.
| Результат | Проверка | Что ловит |
|---|---|---|
| JSON | Парсинг, schema, enum, типы | Сломанный контракт и лишние значения |
| Расчёт | Повторное вычисление | Ошибочную арифметику |
| Код | Изолированные unit-тесты | Неверное поведение |
| Цитаты | Существование источника и фрагмента | Несуществующие ссылки |
| Политика | Запрещённые поля и действия | Явное нарушение ограничений |
По документации OpenAI graders могут включать проверки строк, сходство текста и model graders. Это варианты инструментов, а не доказательство качества сами по себе: конкретный grader нужно проверить на ваших примерах.
Человеческая оценка: рубрика важнее впечатления
Человек нужен там, где важны уместность, ясность, тон, полезность и допустимость вывода. Дайте разметчикам одинаковый контекст, запретите додумывать отсутствующие сведения и опишите границы шкалы.
Оцени ответ только по предоставленному входу и источникам. Критерий: [один критерий]. Шкала: 0 - нарушено обязательное условие; 1 - существенная ошибка мешает использованию; 2 - результат применим после заметной правки; 3 - результат применим без существенной правки. Сначала приведи конкретное доказательство из ответа, затем балл и короткую причину. Если данных недостаточно, верни «неопределимо», а не угадывай.
Перед массовой разметкой несколько экспертов независимо оценивают общую порцию примеров и обсуждают расхождения. Если правило читается по-разному, исправляют рубрику, а не усредняют путаницу.
Pointwise, pairwise и LLM-as-a-judge
Pointwise оценивает один ответ по шкале. Он удобен для абсолютного порога, но шкала может дрейфовать. Pairwise выбирает лучший из двух ответов и полезен для сравнения кандидата с текущей версией. Порядок вариантов следует менять, чтобы обнаруживать позиционное смещение.
Модель-судья масштабирует семантическую проверку, но не является объективным арбитром. Google рекомендует оценивать и калибровать judge-модель по ground truth с человеческими оценками. Судья может предпочитать многословие, знакомый стиль или ответы родственной модели.
- Собрать независимую человеческую разметку.
- Сравнить решения судьи по каждому классу и сегменту.
- Проверить перестановку ответов в pairwise-тесте.
- Добавить трудные контрпримеры и краткие корректные ответы.
- Разобрать ложные пропуски критических ошибок.
- Зафиксировать модель, промпт, температуру и формат.
- Повторить калибровку после изменения судьи.
Как оценивать RAG: поиск и ответ - разные задачи
Если RAG вернул неверный ответ, причина может быть в отсутствии нужного документа, плохом разбиении, ранжировании, генерации или правах доступа. Один показатель «качество ответа» не покажет место поломки.
Добавьте вопросы без ответа в базе: корректное поведение - признать нехватку данных, а не собирать правдоподобную догадку.
Как оценивать ИИ-агента: финального ответа недостаточно
Агент взаимодействует с внешним миром, поэтому оценивайте не только текст, но и траекторию: выбранный инструмент, аргументы, порядок шагов, подтверждения и побочные эффекты. В документации Vertex AI для оценки агентов отдельно выделяются качество ответа, использование инструментов, галлюцинации, безопасность и traces.
| Слой | Вопрос | Блокирующий пример |
|---|---|---|
| План | Учитывает ли ограничения задачи? | Игнорирует запрет на изменение данных |
| Инструмент | Выбран ли разрешённый вызов? | Отправляет письмо вместо черновика |
| Аргументы | Правильны ли адресат, объект и область? | Изменяет чужую запись |
| Подтверждение | Запрошено ли оно перед необратимым действием? | Удаляет без согласия |
| Идемпотентность | Безопасен ли повтор после сбоя? | Создаёт дубль платежа |
Для тестов используйте sandbox или mock-инструменты. Проверка не должна случайно отправлять реальные сообщения, менять рабочие записи или совершать платежи.
Средний балл скрывает критические провалы
Показывайте результат по сегментам, уровням риска и критериям. Кандидат может улучшить обычные запросы и одновременно ухудшить редкий сценарий с высокой ценой ошибки. Поэтому релизное правило включает несколько условий.
- Ни одной новой блокирующей ошибки на обязательном наборе.
- Не ухудшены критические сегменты.
- Кандидат выигрывает или не уступает текущей версии по целевому критерию.
- Задержка и стоимость остаются в согласованном бюджете.
- Результат воспроизводится при повторном прогоне или разброс явно показан.
Для долей и средних показывайте объём выборки и неопределённость, а не только красивое число. Маленькая разница на небольшой выборке может быть шумом. Порог выбирают исходя из риска решения и проверяют на накопленных данных.
Regression-тесты и релизный отчёт
Каждая подтверждённая производственная ошибка должна превращаться в воспроизводимый кейс. Перед изменением зафиксируйте, что текущая версия действительно падает; после исправления сохраните пример в regression-наборе.
Подготовь релизный отчёт по двум прогонам eval. Текущая версия: [результаты]. Кандидат: [результаты]. Сегменты и критичность: [данные]. Пороговые правила: [правила]. Покажи: общий результат, изменения по сегментам, новые блокирующие ошибки, исправленные регрессии, стоимость, задержку и неопределённые случаи. Не усредняй блокирующие ошибки с улучшением стиля. В конце выдай одно решение: release, hold или manual review - со ссылками на конкретные кейсы.
Храните рядом версии модели, промпта, инструментов, индекса, данных, grader и кода. Иначе через месяц невозможно объяснить, почему два отчёта различаются.
Offline eval и онлайн-наблюдение дополняют друг друга
Offline-тесты быстры, повторяемы и безопасны для сравнения версий. Но они не полностью воспроизводят поведение пользователей и изменения данных. В продакшене отслеживайте отказы, исправления, эскалации, повторные запросы, задержку, стоимость и подтверждённые инциденты.
Не принимайте клик или отсутствие жалобы за истинную корректность. Пользователь может не заметить ошибку. Связывайте продуктовые сигналы с выборочной экспертной проверкой и постепенно добавляйте проверенные случаи в offline-набор. Доступ к логам и срок хранения должны соответствовать политике данных.
План внедрения evals за четыре недели
Начните с одного важного сценария. Универсальная платформа оценки до появления понятной задачи часто создаёт много инфраструктуры и мало решений.
Финальный чек-лист системы оценки ИИ
- Задача, аудитория и полезный результат описаны.
- Критические ошибки отделены от желательных свойств.
- Набор покрывает сегменты, края и реальные инциденты.
- Персональные данные удалены или защищены.
- Эталон допускает несколько правильных ответов там, где это нужно.
- Формат, схема и вычисления проверяются кодом.
- Рубрика содержит границы и примеры.
- Модель-судья сверена с человеческой разметкой.
- RAG проверяется на retrieval и grounding отдельно.
- У агента проверяются инструменты, аргументы и побочные эффекты.
- Результаты разложены по сегментам и рискам.
- Есть неизменный regression-набор и свежая контрольная выборка.
- Зафиксированы версии всех компонентов.
- Релизный gate учитывает качество, риск, задержку и стоимость.
- Производственные ошибки возвращаются в тестовый набор.
Сильная eval-система не обещает, что ИИ никогда не ошибётся. Она делает качество измеримым, изменения сравнимыми, а решение о релизе - объяснимым.