Перейти к содержимому

Evals: как измерять качество AI-системы

Evals — дисциплина измерения AI-системы: набор задач с ожидаемым поведением, способы оценки и процесс, который превращает результаты в инженерные решения. Раздел отвечает не на вопрос «какая модель умнее», а на вопрос «решает ли наша система наши задачи и где именно она ломается».

Актуальность выросла вместе с ценой ошибки. Агенты перестали только отвечать и начали действовать: писать код, тратить деньги, ходить в прод, дёргать чужие API. В июле 2025 coding-агент в Replit проигнорировал запрет на изменения и удалил production-базу примерно 1200 компаний; Operator от OpenAI, которого просили только найти дешёвые яйца, купил их на $31.43 в обход подтверждения. Ни один из этих случаев не всплыл бы в демо и не был бы предсказан публичным бенчмарком.

Evals отвечают на три разных вопроса. Один общий success rate смешивает их в одно число и теряет диагностику.

ВопросЧто проверяетсяГде разобрано
Нашла ли система нужноеКачество retrieval: precision, recall, попадание в top-kПокомпонентные evals
Верен ли ответГенерация, обоснованность контекстом, форматСудья и статистика
Сделала ли система нужноеВыбор инструментов, аргументы, траектория, результатОценка по результату

Метрика без датасета бесполезна: набор задач с ожидаемым поведением важнее выбора библиотеки. Публичный лидерборд отвечает на другой вопрос — он измеряет модель, а не вашу систему.

СтраницаВопрос, на который отвечает
Модель или обвязкаГде искать причину сбоя и почему смена модели обычно разочаровывает
Сбои обвязкиШесть категорий поломок вокруг модели и как они выглядят в проде
Слои проверокКакие бывают evals, что каждый слой ловит и что пропускает
Покомпонентные evalsМинимальный набор проверок по слоям системы и как их собрать
Оценка по результатуКак судить по фактическому эффекту, а не по тексту ответа
Судья и статистикаКалибровка LLM-судьи, pass^k, доверительные интервалы
Evals как инфраструктураCI, датасет, релизные гейты и цена типовых ошибок
  • Relevant. Проверяет то, от чего продукт действительно зависит, а не то, что легко измерить.
  • Diagnostic. Показывает причину и место провала, а не только pass/fail.
  • Repeatable. На одинаковом входе даёт сравнимый результат; иначе разницу «до и после» не отличить от случайного разброса.
  • Hard to game. Почти всегда измеряется proxy, а не цель: «есть ключевые слова» вместо «ответ полезен». Положительный proxy ещё не доказывает, что задача решена.
  • Statistically honest. Один прогон ничего не значит: 85% сегодня и 80% завтра — нормальный шум. Нужны доверительный интервал и проверка значимости разницы.
  • Runnable often. Набор, который гоняется на каждое изменение, состоит из быстрых атомарных проверок; иначе его перестанут запускать.

Формулировка задачи тоже проверяется: если два эксперта, глядя на один ответ, независимо выносят одинаковый вердикт pass/fail, задача сформулирована хорошо. Расходятся — проблема в формулировке, а не в системе.

1. Взять 20–50 реальных задач с ожидаемым поведением
2. Покрыть их детерминированными проверками там, где это возможно
3. Разложить проверки по компонентам: retrieval, tools, state, ошибки, формат
4. Запускать smoke-набор на каждом pull request
5. Пополнять набор реальными сбоями из production
6. Сделать полный прогон релизным гейтом

Пятый шаг отличает работающую практику от одноразовой проверки. Именно production-ошибки превращаются в регрессионные тесты и защищают от повторения.

  • Инструменты и метрики — короткий обзор платформ (Langfuse, Ragas, DeepEval, promptfoo, LangSmith) остаётся в Оценке качества.
  • Наблюдаемость — трассы, стоимость по шагам и связка «инцидент → датасет» разобраны в Наблюдаемости. Evals без трассировки пополняются вручную и быстро устаревают.
  • A/B-тест — измеряет влияние изменения на продуктовые метрики. Eval измеряет качество ответов; одно другое не заменяет.
  • Red teaming — отдельный наступательный процесс, который ищет провал, а не измеряет его распространённость.