Большинство команд оценивают производительность AI-агентов через end-to-end метрики: success rate, количество токенов, tool usage, стоимость запроса, долю успешных задач. Это полезно для общего контроля ситуации, но почти бесполезно для реальной диагностики системы.
Например, если success rate упал с 85% до 72%, то само по себе число не объясняет причину деградации. Команда вынуждена гадать, какая часть системы вдруг начала допускать ошибки. Сломался retrieval? Модель хуже начала выбирать инструменты? Контекст загрязняется после нескольких ходов? Или система уперлась в возможности base model? При росте проекта и увеличении сложности кодовой базы, сбои начинают расти мультипликативно – ошибки всех систем начинают перемножаться между собой. В конечном итоге, команда теряет реальный контроль.
Проблему решает внедрение покомпонентных eval. Они дополняют end-to-end метрики, показывая, какой слой AI-агента работает, какой деградировал – и где именно искать причину. То есть внедрение evals помогает получать метрики производительности каждого компонента вашего агента.
Evals – инструменты и процессы для тестирования, измерения качества и безопасности ответов искусственного интеллекта (ИИ) и нейросетей (LLM).
В этой статье я разберу базовый набор evals для AI-агента, который можно внедрить минимальными затратами, дам очерк о том, как должен работать хороший evals, и приведу пример ошибки, которую мог бы поймать evals.
Как должен работать хороший evals
В сложных недетерминированных системах — например, в AI coding agents, недостаточно проверять только конечный результат. Один общий success rate смешивает в себе качество retrieval, поведение модели, схемы инструментов, состояние системы, обработку ошибок и валидацию вывода.
Хороший eval suite раскладывает систему на отдельные слои. Каждый важный компонент оценивается отдельно и регулярно: при изменении prompt’а, схемы tool call, retrieval-индекса, retry-логики или модели. Тогда деградация становится видна сразу и привязана к конкретной части системы.
В идеале такой suite прогоняется на каждом pull request в CI. Не обязательно запускать полный (и дорогой) набор проверок: даже небольшой smoke-suite на 20-50 кейсов уже помогает увидеть регрессию до того, как она попадет в продукт и начнет выглядеть как случайное поведение агента.
Разные компоненты требуют разных методов оценки. Retrieval нельзя оценивать так же, как structured output: в первом случае важны precision, recall и попадание нужного чанка в top-k, во втором — валидность схемы, обязательные поля, типы и поведение при ошибке парсинга.
Подробные методологии составления evals я разберу отдельно в следующих статьях. В этой статье хочу сделать фокус на том, в какие части AI-агента стоит внедрить evals в первую очередь, и какими базовыми способами это возможно сделать.
Минимальный набор evals
Оценка результатов evals может быть как детерминированным (алгоритмическим ; по заранее размеченным данным), так и использовать LLM-as-judge подход — когда оценку дает другой агент.
Всегда, когда возможно, советую отдавать предпочтение детерминированным подходам оценки. Их не всегда можно применить, но почти всегда, когда можно, лучше потратить время на написание программного алгоритма оценки, чем потенциально потерять точность из-за bias агента-судьи.
Retrieval precision eval
Проверяет, достает ли RAG нужные документы/чанки.
Метод: собрать 20-50 вопросов с известными реливантными источниками из индекса. Для каждого запроса запустить top-k. Проверить есть ли правильный чанк в топ 3-5. Нет ли мусора в топе.
Tool-call schema eval
Проверяет, правильно ли модель вызывает инструменты.
Метод: дать набор задач, где ожидается конкретный tool call. Проверить имя инструмента, обязательные параметры, типы, отсутствие лишних полей.
State-consistency eval
Проверяет, не расходится ли представление модели с реальным состоянием системы.
Метод: после несколько ходов агента сравнивать то, что агент «думает» о состоянии с фактическим состоянием: документ, workflow, визуальный граф (как в моей прошлой статье).
Особенно важно для умения агента работать на длинных горизонтах.
Retry / error propagation eval
Проверяет, как система ведет себя при ошибках.
Метод: искусственно вернуть validation error, permission denied, not found или другие ошибки свойственные вашей системе. Проверить делает ли система retry на retriable ошибках, не делает ли retry на no-retry ошибках. Передает ли ошибку обратно агенту.
Structured-output validation eval
Проверяет, возвращает ли агент валидный структурированный ответ, как этого требует пользователь или system prompt.
Метод: прогнать задачи с ожидаемой схемой ответа. Валидировать парсером. Ошибка должна быть видна агенту в явном виде. Ни в коем случае не должна быть silent, неявно превращающейся агентом в пустой или частичный результат «под капотом».
«I don’t know» eval
Проверяет, умеет ли агент не отвечать, когда данных недостаточно, и не галлюцинирует ли он при недостаточности данных.
Метод: дать вопросы без ответа в контексте агента (или весах базовой модели) или с конфликтующими данными. Ожидаемый результат: отказ выполнения из-за недостаточности данных, уточнение дополнительных данных.
Model swap eval
Проверяет, является ли модель bottleneck в каком-то из компонентов системы.
Метод: прогнать один и тот же eval suite на разных моделях без изменения в коде обвязки.
Если прирост производительности резкий и чистый, то возможно, вы уперлись в потолок возможностей выбранной модели, и стоит задуматься об апгрейде.
Пример ошибки, которую бы поймал eval
В одной из прошлых статей я разбирал ошибку state-drift в агенте созданном для написания визуального кода в Unreal Engine.
Агент выполнял длинные Blueprint-задачи: создавал ноды, соединял пины, менял структуру графа и двигался к целевому результату через серию tool calls. На коротких сценариях все выглядело нормально. Но после 10-20 ходов представление агента о графе начинало расходиться с реальным состоянием. Он считал, что нода уже создана, хотя она не существовала; пытался соединить пины, которых уже не было; пересоздавал элементы или уходил в попытки исправить последствия собственных действий.
Проблема была не в модели как таковой. Модель планировала следующий шаг не от фактического состояния графа, а от своей памяти о предыдущих действиях. Поэтому здесь нужен был не «более умный LLM», а state-consistency eval: проверка, совпадает ли внутреннее представление агента с реальным состоянием системы после серии действий.
После этого кейса я добавил такой eval в общий suite: агент выполняет длинную задачу, а тест периодически сравнивает ожидаемое состояние графа, фактическое состояние в Unreal и то, на что агент опирается при следующем ходе. Если эти три слоя расходятся, задача считается не просто “failed”, а failed по конкретной причине — потеря консистентности состояния.
Заключение
Многие сейчас предпочитают говорить, что AI в разработке непредсказуем, и с этим необходимо смириться. Но это правда в том, что современные инженеры AI-систем могут (и должны) полностью контролировать производительность. Сейчас это является основой построения сильного и масштабируемого AI продукта. В противном случае команда обречена на бесконечный цикл поиска множащихся ошибок, и исправления симптомов, а не первопричин.
Контроль может быть достигнут внедрением evals – стандартизированных тестов и фреймворков для оценки качества. Задача evals — не только в том, чтобы дать руководителям красивый отчет, что агент работает «хорошо». Их задача — помогать инженерной команде находить и устранять сбои, давать возможность проверять гипотезы и показывать, какие изменения действительно повышают надежность и производительность.
В следующих статьях я подробно разберу подходы к evals в production-системах, поэтому не забудь подписаться. А если контроль метрик актуален для вашего продукта уже сейчас, я консультирую команды и помогаю с внедрением и развитием evals. Написать мне можно здесь или в моем LinkedIn.
ссылка на оригинал статьи https://habr.com/ru/articles/1042924/