«На демо всё работало» — самая дорогая фраза в ИИ-проектах. На демо звучат десять вежливых вопросов. В продакшене их тысячи — с опечатками, на разных языках, раздражённые, иногда откровенно враждебные, — а ещё обновления моделей, о которых никто не просил, и база знаний, которая меняется каждую неделю.
Поэтому главный барьер для ИИ-агентов — качество, а не цена. В отчёте LangChain State of Agent Engineering 2026 32% команд называют качество основным препятствием на пути в продакшен, задержку — около 20% (опрос LangChain). Gartner ожидает, что к концу 2027 года будет закрыто более 40% агентных ИИ-проектов (Gartner). У команд, которые доходят до результата, есть общая привычка: они системно измеряют качество до и после запуска. Эта привычка называется evals.
В этом руководстве — что такое evals, как за несколько дней собрать первый эталонный набор, какой метод оценки для чего подходит и как продолжать измерять, когда пришли реальные клиенты.
Что такое evals и почему юнит-тестов недостаточно
Eval — это повторяемая проверка поведения ИИ: фиксированный набор входных данных, описание того, как выглядит хороший результат, метод оценки и порог. Классические тесты проверяют, что функция возвращает ожидаемое значение. С ИИ-системами всё иначе:
- Ответы варьируются. Один и тот же вопрос может дать разные, одинаково верные формулировки — и время от времени неверную.
- Изменения дают побочные эффекты. Правка промпта, которая чинит ответы про возвраты, может сломать ответы про доставку. Обновление модели у провайдера способно за ночь изменить тон, длину ответов или работу с инструментами.
- Типичная ошибка — «почти правильно». В опросе Stack Overflow 2025 года 66% разработчиков назвали главным раздражителем ответы ИИ, которые «почти правильные, но не совсем», а 46% заявили, что не доверяют точности ИИ (Stack Overflow). Именно это «почти правильно» демо и не показывает.
Зрелая схема состоит из трёх уровней:
- Офлайн-evals на подготовленном «эталонном» наборе во время разработки.
- Контроль релизов: evals автоматически прогоняются при каждом изменении промптов, моделей, инструментов или поиска и блокируют релиз при регрессии.
- Онлайн-evals: непрерывная оценка выборки реальных диалогов из продакшена.
Шаг 1. Определите «хорошо» в терминах бизнеса
Evals начинаются с бизнес-результата, а не с метрик модели. Для ИИ-агента поддержки результат — правильно решённое обращение. Для обработки документов — верно проведённый счёт, для голосового администратора — запись с правильным временем, именем и услугой.
Это важно и с коммерческой стороны. Платформы уже берут деньги за результат: Intercom Fin — $0,99 за решённое обращение (Intercom), Zendesk — $1,50–2,00 за автоматическое решение (Macha), HubSpot с апреля 2026 года — $0,50 за решённый диалог (Resolve247). Аналитики HFS предупреждают, что определение «решённого» обращения станет следующим полем споров в SLA, поэтому его нужно прописывать в договоре и делать проверяемым (HFS Research). Если вы платите или получаете деньги за результат, определения из ваших evals становятся частью договора.
И ещё одно правило, которое подтверждают разборы неудачных проектов: без базового замера «до» эффект ИИ невозможно доказать. Зафиксируйте текущие показатели команды — долю решённых обращений, время ответа, число ошибок — до того, как включите агента.
Разложите результат на измеримые параметры:
- Правильность: факты, цифры, цены и правила совпадают с эталонным источником.
- Обоснованность: каждое утверждение подтверждено найденными документами, ничего не выдумано.
- Точность действий: вызван нужный инструмент с нужными параметрами — номер заказа, сумма, дата.
- Соблюдение правил: никаких запрещённых обещаний, обязательное уведомление об ИИ на месте, эскалация происходит, когда должна.
- Тон и язык: ответ на языке клиента и в голосе бренда — включая выбор между «вы» и «ты».
- Задержка и стоимость: в пределах бюджета канала.
Шаг 2. Соберите эталонный набор за дни, а не за месяцы
Для старта не нужны тысячи примеров. Нескольких десятков — пары сотен тщательно отобранных случаев хватает, чтобы ловить большинство регрессий. Хорошие источники:
- Реальная история. Прошлые обращения, письма, расшифровки звонков и документы, обезличенные. В них — вопросы, которые клиенты задают на самом деле, и их собственные формулировки.
- Длинный хвост. Редкие, но дорогие случаи: расторжения, жалобы, угрозы судом, VIP-клиенты, смешение языков — например, вопрос на русском с казахскими или узбекскими названиями.
- Случаи «обязан отказать» и «обязан передать человеку». Запросы вне зоны ответственности, медицинские или юридические советы, раздражённый клиент, который требует живого сотрудника. Агент, который отвечает на всё, — это риск.
- Атакующие случаи. Попытки вытащить системный промпт, выпросить скидку или протащить инструкции через документы — см. наше руководство по защите от промпт-инъекций.
- Неудобные форматы. Сканы PDF, фото счетов на телефон, голосовые записи с шумом.
Для каждого случая запишите ожидаемый результат: факты, которые обязаны прозвучать, утверждения, которых быть не должно, ожидаемый вызов инструмента с параметрами или ожидаемые извлечённые поля. Храните набор в Git, как код, и добавляйте в него каждую ошибку из продакшена. Набор должен расти с каждым инцидентом.
Шаг 3. Выберите подходящий метод оценки
| Метод | Что проверяет | Сильные стороны | Ограничения |
|---|---|---|---|
| Точное или структурное сравнение | Извлечённые поля, JSON-схема, аргументы вызовов, классификация | Дёшево, быстро, однозначно | Только для структурированных ответов |
| Проверки по правилам | Запрещённые фразы, обязательные уведомления, цены по каталогу, форматы | Детерминированно и легко объяснить | Не оценивает смысл |
| LLM-судья с рубрикой | Правильность, обоснованность, полезность, тон | Масштабируется на свободный текст, дёшево за случай | Нужна калибровка по оценкам людей; возможны перекосы |
| Ручная проверка | Всё, включая нюансы | Золотой стандарт | Медленно и дорого; для калибровки и выборок |
| Успех задачи в песочнице | Действительно ли агент выполнил задачу — создан возврат, оформлена запись? | Измеряет результат, а не слова | Нужна тестовая среда с реалистичными данными |
| Метрики для голоса | Распознавание имён, чисел и дат; перебивания; задержка реплики | Ловит то, что пропускают текстовые evals | Нужны аудионаборы |
Два совета. Первый: используйте детерминированные проверки везде, где можно, а LLM-судью оставьте для того, что действительно требует суждения. Второй: откалибруйте судью. Пусть люди оценят 50–100 случаев, сравните их оценки с оценками судьи и уточняйте рубрику, пока они не совпадут. Никогда не позволяйте модели оценивать собственные ответы тем же промптом.
Голосу нужно особое внимание. По данным AssemblyAI, в реальных условиях распознавание речи обычно работает в два–три раза хуже, чем на лабораторных бенчмарках (AssemblyAI), а телефонный звук ухудшает его ещё сильнее. Для русского языка на сложном бенчмарке доля ошибок распознавания (WER) у российских API составляет 0,39–0,55 (Хабр). Казахский и узбекский поддерживаются частью сервисов, но метрики качества для них не публикуются (документация SpeechKit) — их придётся измерять самостоятельно. Имена, адреса, номера телефонов и даты — то, на чём голосовые агенты ошибаются чаще всего. Тестируйте именно это.
Шаг 4. Пороги и контроль релизов
Eval без порога — отчёт, который никто не читает. Определите для каждого параметра допустимый уровень и отделяйте средние значения от критических ошибок.
Ниже — пример плана evals для агента поддержки. Значения иллюстративные; задавайте свои исходя из рисков.
| Параметр | Метрика | Метод | Пример порога |
|---|---|---|---|
| Решение | Доля случаев, решённых правильно от начала до конца | Успех в песочнице плюс ручная выборка | Не ниже текущего уровня команды |
| Обоснованность | Доля ответов, полностью подтверждённых источниками | Откалиброванный LLM-судья | 95% и выше |
| Критические ошибки | Неверная цена, неверная сумма возврата, данные другого клиента | Правила плюс структурное сравнение | Ноль |
| Эскалация | Обязательные эскалации переданы человеку | Структурное сравнение | 100% |
| Уведомление об ИИ | Уведомление есть там, где оно обязательно (EU AI Act, ст. 50) | Проверка по правилу | 100% |
| Задержка | Время ответа по 95-му перцентилю | Логи | Бюджет канала, например до 3 секунд в чате |
| Стоимость | Стоимость одного решённого случая | Логи шлюза | В рамках бизнес-кейса |
Прогоняйте полный набор при каждом изменении: промпта, модели, описания инструмента, настроек поиска, загрузки в базу знаний. Блокируйте релиз, если критическая метрика упала. Сравнивая модели, используйте один и тот же набор и смотрите на качество, задержку и стоимость рядом. Именно такие доказательства нужны LLM-шлюзу, чтобы безопасно переводить трафик на более дешёвые модели.
Шаг 5. Продолжайте измерять после запуска
С запуском начинает поступать настоящий набор данных. Онлайн-evals замыкают цикл:
- Оценивайте выборку живых диалогов по той же рубрике — ежедневно для новых систем, еженедельно для стабильных. Автоматическая оценка делает полный охват доступным: ручной контроль качества в контакт-центрах обычно проверяет лишь 1–2% звонков (AssemblyAI). Для ориентира по цене: Retell берёт $0,10 за минуту автоматической проверки качества голосовых агентов (Retell).
- Отслеживайте поведенческие сигналы. Долю эскалаций, повторные обращения в течение 48 часов, негативные оценки, брошенные диалоги, ручные исправления в учётных системах.
- Следите за дрейфом. Устаревшая база знаний — самая частая причина роста галлюцинаций через несколько месяцев после запуска; обновления моделей у провайдеров — на втором месте. После каждого обновления прогоняйте офлайн-набор заново.
- Используйте пороги уверенности. Пусть система передаёт диалог человеку, когда не уверена. Один из разработчиков ИИ-агентов для CRM, например, автоматически эскалирует разговор, когда релевантность найденных материалов падает ниже 0,40 (NOVA). Важно не конкретное число, а то, что порог есть и его подстраивают по данным.
- Возвращайте ошибки в набор. Каждая серьёзная ошибка в продакшене становится новым тестом, чтобы она никогда не вернулась незаметно.
Как выглядят хорошие результаты
Evals превращают расплывчатые обещания в цифры. Несколько опубликованных примеров — все со слов самих вендоров, поэтому воспринимайте их как ориентир, а не бенчмарк:
- Fractional AI сообщает о сокращении галлюцинаций на 80% в ИИ-системе, построенной для Zapier (Fractional AI).
- Vstorm приводит проект, где точность выросла с 44% до 98% (Vstorm).
- По данным Salesforce, 70% сервисных подразделений с ИИ-агентами видят измеримый эффект в первые 60 дней (Salesforce).
Объединяет эти случаи не более сильная модель, а измеряемый цикл: базовый замер, изменение, повторный замер.
Кто отвечает за evals
Evals чаще проваливаются из-за организации, чем из-за техники. Работают они, когда есть три роли:
- Владелец со стороны бизнеса — руководитель поддержки, операционного блока или продаж — определяет, что значит «хорошо», утверждает пороги и отвечает за баланс между уровнем автоматизации и риском.
- Предметные эксперты — опытные операторы, бухгалтеры, диспетчеры — размечают случаи и проверяют выборки. Два часа в неделю от правильного человека ценнее тысячи синтетических примеров.
- Технический владелец поддерживает тестовую среду, контроль релизов и дашборды и следит, чтобы каждый инцидент превращался в тест.
Ставьте ежемесячный отчёт по evals в ту же повестку, что и остальные операционные показатели. Когда цифры качества стоят рядом с затратами и объёмами, решения о моделях, промптах и масштабе автоматизации принимаются по фактам, а не по историям.
Инструменты: начните с простого
Для старта достаточно таблицы с тестовыми случаями и скрипта, который вызывает вашу систему и оценивает ответы. С ростом объёма добавьте инструменты трассировки и оценки. Langfuse или Helicone для трасс и оценок, Sentry для ошибок и PostHog для продуктовых сигналов — распространённая связка в продакшен-пакетах ИИ (HouseofMVPs).
Чем бы вы ни пользовались, храните наборы, рубрики и результаты в системах, которые принадлежат вам, а не только в дашборде вендора. После самих данных это самый ценный актив ИИ-проекта: с ним можно сменить модель, вендора или агентство, не начиная с нуля.
Типичные ошибки
- Тестировать на демо-вопросах. Если набор лёгкий, оценка ничего не значит.
- Оценивать текст, но не действия. Вежливый ответ с неверной суммой возврата — это ошибка.
- Прятать критические ошибки в средних. Средние 97% могут включать утечку данных.
- Неоткалиброванные LLM-судьи или модель, которая оценивает сама себя.
- Нет случаев отказа и эскалации — тогда агент учится отвечать на всё.
- Evals один раз перед запуском и больше никогда. Модели, данные и клиенты постоянно меняются.
- Промпты и наборы без версий — невозможно понять, что вызвало регрессию.
Вывод
Evals — самая дешёвая страховка в ИИ. Эталонный набор из реальных случаев, несколько удачно выбранных метрик с порогами, автоматический контроль релизов и непрерывная оценка живого трафика превращают эффектное демо в систему, которой можно доверять — и которую можно посчитать. Большинству застрявших пилотов, которые мы видим, не хватает не более сильной модели, а способа доказать, что текущая работает. Если это про вас, следующим стоит прочитать, как довести ИИ-пилот до продакшена.
Наша команда Systems строит наборы evals, контроль релизов и дашборды качества для агентов поддержки, голосовых и документных агентов. Запишитесь на бесплатный 15-минутный аудит — посмотрим, как сейчас измеряется качество вашего ИИ и где у вас слепые зоны.