---
title: "Evals: как измерять качество AI-системы"
description: Зачем нужны собственные evals, из чего складывается eval-стек, какие проверки вскрывают сбои обвязки и почему evals — production-инфраструктура, а не разовый эксперимент.
---

## О разделе

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

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

## Три вопроса, и их нельзя смешивать

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

| Вопрос | Что проверяется | Где разобрано |
|---|---|---|
| Нашла ли система нужное | Качество retrieval: precision, recall, попадание в top-k | [Покомпонентные evals](https://wpcraft.ru/kb/ai/evals/component-evals.md) |
| Верен ли ответ | Генерация, обоснованность контекстом, формат | [Судья и статистика](https://wpcraft.ru/kb/ai/evals/judge-and-statistics.md) |
| Сделала ли система нужное | Выбор инструментов, аргументы, траектория, результат | [Оценка по результату](https://wpcraft.ru/kb/ai/evals/execution-based.md) |

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

## Карта подраздела

| Страница | Вопрос, на который отвечает |
|---|---|
| [Модель или обвязка](https://wpcraft.ru/kb/ai/evals/system-not-model.md) | Где искать причину сбоя и почему смена модели обычно разочаровывает |
| [Сбои обвязки](https://wpcraft.ru/kb/ai/evals/harness-failure-modes.md) | Шесть категорий поломок вокруг модели и как они выглядят в проде |
| [Слои проверок](https://wpcraft.ru/kb/ai/evals/eval-layers.md) | Какие бывают evals, что каждый слой ловит и что пропускает |
| [Покомпонентные evals](https://wpcraft.ru/kb/ai/evals/component-evals.md) | Минимальный набор проверок по слоям системы и как их собрать |
| [Оценка по результату](https://wpcraft.ru/kb/ai/evals/execution-based.md) | Как судить по фактическому эффекту, а не по тексту ответа |
| [Судья и статистика](https://wpcraft.ru/kb/ai/evals/judge-and-statistics.md) | Калибровка LLM-судьи, `pass^k`, доверительные интервалы |
| [Evals как инфраструктура](https://wpcraft.ru/kb/ai/evals/evals-as-infrastructure.md) | CI, датасет, релизные гейты и цена типовых ошибок |

## Принципы хорошего eval

- **Relevant.** Проверяет то, от чего продукт действительно зависит, а не то, что легко измерить.
- **Diagnostic.** Показывает причину и место провала, а не только `pass/fail`.
- **Repeatable.** На одинаковом входе даёт сравнимый результат; иначе разницу «до и после» не отличить от случайного разброса.
- **Hard to game.** Почти всегда измеряется proxy, а не цель: «есть ключевые слова» вместо «ответ полезен». Положительный proxy ещё не доказывает, что задача решена.
- **Statistically honest.** Один прогон ничего не значит: 85% сегодня и 80% завтра — нормальный шум. Нужны доверительный интервал и проверка значимости разницы.
- **Runnable often.** Набор, который гоняется на каждое изменение, состоит из быстрых атомарных проверок; иначе его перестанут запускать.

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

## Маршрут внедрения

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

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

## Чего раздел не заменяет

- **Инструменты и метрики** — короткий обзор платформ (Langfuse, Ragas, DeepEval, promptfoo, LangSmith) остаётся в [Оценке качества](https://wpcraft.ru/kb/ai/agents/evaluation.md).
- **Наблюдаемость** — трассы, стоимость по шагам и связка «инцидент → датасет» разобраны в [Наблюдаемости](https://wpcraft.ru/kb/ai/agents/observability.md). Evals без трассировки пополняются вручную и быстро устаревают.
- **A/B-тест** — измеряет влияние изменения на продуктовые метрики. Eval измеряет качество ответов; одно другое не заменяет.
- **Red teaming** — отдельный наступательный процесс, который ищет провал, а не измеряет его распространённость.

## Материалы и источники

- [Evals: что должен знать каждый AI-инженер в 2026](https://habr.com/ru/articles/1050736/) — Артем Тарасов, обзор eval-стека и практик
- [Evals для чайников: как тестировать AI-агента](https://habr.com/ru/articles/1042924/) — минимальный набор покомпонентных проверок
- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [OpenAI: How evals drive the next chapter in AI](https://openai.com/index/evals-drive-next-chapter-of-ai/)
- [Towards a Science of AI Agent Reliability](https://arxiv.org/html/2602.16666v1) — каталог реальных инцидентов и четыре измерения надёжности