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, датасет, релизные гейты и цена типовых ошибок |
Принципы хорошего eval
Заголовок раздела «Принципы хорошего eval»- 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 request5. Пополнять набор реальными сбоями из production6. Сделать полный прогон релизным гейтомПятый шаг отличает работающую практику от одноразовой проверки. Именно production-ошибки превращаются в регрессионные тесты и защищают от повторения.
Чего раздел не заменяет
Заголовок раздела «Чего раздел не заменяет»- Инструменты и метрики — короткий обзор платформ (Langfuse, Ragas, DeepEval, promptfoo, LangSmith) остаётся в Оценке качества.
- Наблюдаемость — трассы, стоимость по шагам и связка «инцидент → датасет» разобраны в Наблюдаемости. Evals без трассировки пополняются вручную и быстро устаревают.
- A/B-тест — измеряет влияние изменения на продуктовые метрики. Eval измеряет качество ответов; одно другое не заменяет.
- Red teaming — отдельный наступательный процесс, который ищет провал, а не измеряет его распространённость.
Материалы и источники
Заголовок раздела «Материалы и источники»- Evals: что должен знать каждый AI-инженер в 2026 — Артем Тарасов, обзор eval-стека и практик
- Evals для чайников: как тестировать AI-агента — минимальный набор покомпонентных проверок
- Anthropic: Demystifying evals for AI agents
- OpenAI: How evals drive the next chapter in AI
- Towards a Science of AI Agent Reliability — каталог реальных инцидентов и четыре измерения надёжности