Success rate упал с 85% до 72% — и что теперь с этим делать
Success rate упал — но почему? Разбираем 7 покомпонентных evals для AI-агента: retrieval, tool call, state drift, retry и другие. С методами и примерами.
End-to-end метрики говорят «что-то сломалось», но не говорят «где». Если у вас нет покомпонентных evals, команда начинает гадать: retrieval? tool call? галлюцинация модели? Вот минимальный набор проверок, который даёт конкретные ответы.
Почему одного success rate недостаточно
Представьте: success rate агента упал на 13 процентных пунктов за неделю. Само по себе число ни о чём не говорит. Сломался retrieval и нужный чанк перестал попадать в top-5? Модель начала неправильно выбирать инструменты? Контекст засоряется после нескольких ходов диалога? Или вы просто упёрлись в потолок базовой модели?
При росте кодовой базы ошибки разных подсистем начинают перемножаться: небольшой сбой в retrieval плюс небольшой сбой в structured output дают заметную просадку на выходе. End-to-end метрика это фиксирует, но не раскладывает. Покомпонентные evals — раскладывают.
Как устроен хороший eval suite
Главный принцип: каждый важный компонент оценивается отдельно и по своим критериям. Retrieval нельзя мерить так же, как structured output — у них разные метрики, разные тестовые наборы, разные определения «правильного ответа».
Хороший suite запускается на каждом pull request в CI. Не нужно гонять полный дорогой набор при каждом коммите — достаточно smoke-suite на 20–50 кейсов. Этого хватает, чтобы поймать регрессию до того, как она попадёт в продакшн и начнёт выглядеть как «агент иногда ведёт себя странно».
Оценка может быть детерминированной (алгоритм по размеченным данным) или использовать LLM-as-judge (другая модель выступает судьёй). Когда есть выбор — берите детерминированный подход. Он точнее, дешевле и не тащит за собой bias модели-судьи.
Семь evals, которые стоит внедрить первыми
Retrieval precision eval — проверяет, достаёт ли RAG нужные документы.
Соберите 20–50 вопросов с заранее известными релевантными чанками в индексе. Для каждого запроса запустите top-k и проверьте два условия: нужный чанк есть в топ-3–5, мусора в топе нет. Метрики — precision и recall по размеченному набору.
Tool-call schema eval — проверяет, правильно ли модель вызывает инструменты.
Дайте агенту задачи, где ожидается конкретный tool call. Проверяйте: правильное имя инструмента, все обязательные параметры присутствуют, типы совпадают, лишних полей нет. Это детерминированная проверка — никакого LLM-as-judge не нужно.
State-consistency eval — проверяет, не расходится ли представление агента с реальным состоянием системы.
После нескольких ходов сравнивайте то, что агент «думает» о состоянии (документ, граф, workflow), с фактическим состоянием. Особенно критично для агентов, которые работают на длинных горизонтах — именно здесь накапливается state drift.
Retry / error propagation eval — проверяет поведение системы при ошибках.
Искусственно возвращайте типичные для вашей системы ошибки: validation error, permission denied, not found. Проверяйте три вещи: система делает retry на retriable ошибках, не делает retry на no-retry ошибках, ошибка явно передаётся обратно агенту — не проглатывается молча.
Structured-output validation eval — проверяет, возвращает ли агент валидный структурированный ответ.
Прогоните задачи с ожидаемой схемой ответа через парсер. Ключевое требование: ошибка парсинга должна быть видна агенту явно. Silent failure — когда агент под капотом превращает невалидный ответ в пустой или частичный результат — один из самых коварных багов в продакшне.
"I don't know" eval — проверяет, умеет ли агент отказываться отвечать.
Дайте вопросы, на которые в контексте агента нет ответа, или вопросы с конфликтующими данными. Ожидаемый результат: явный отказ или запрос дополнительных данных. Если агент уверенно отвечает — это галлюцинация, и eval её поймает.
Model swap eval — проверяет, является ли модель узким местом.
Прогоните один и тот же eval suite на разных моделях без изменений в коде обвязки. Если при смене модели производительность резко и чисто вырастает — вы упёрлись в потолок текущей модели, а не в баг в коде. Это меняет приоритеты: не рефакторинг, а апгрейд модели.
Где это ломается на практике
Типичный пример — state drift в агенте, работающем с визуальным кодом. Агент корректно выполняет первые несколько шагов, но к шагу 7–8 его представление о состоянии системы расходится с реальным. Без state-consistency eval это выглядит как «агент иногда делает странные вещи на длинных задачах» — и команда тратит часы на воспроизведение и отладку. С eval — регрессия видна сразу после коммита, который изменил логику обновления контекста.
Ещё одна частая ловушка: silent failure в structured output. Агент возвращает невалидный JSON, обвязка тихо подставляет дефолтное значение, задача формально завершается успешно — но с неправильным результатом. Success rate не падает, пользователи получают мусор.
Evals также не ловят то, для чего они не спроектированы. Если вы не покрыли какую-то категорию сбоев тестами — она будет накапливаться в слепой зоне. Поэтому важно периодически смотреть на сырые логи агента, а не только на дашборд метрик.
Что попробовать дальше
Начните с retrieval precision eval и tool-call schema eval — они дают максимум информации при минимуме усилий и полностью детерминированы. Добавьте smoke-suite в CI на 20–50 кейсов: даже такой набор радикально меняет скорость диагностики.
Когда базовый набор заработает, идите глубже: LLM-as-judge для оценки качества рассуждений, adversarial-кейсы для "I don't know" eval, автоматическая генерация тестовых наборов из production-логов. Методологии для каждого из этих направлений — отдельная большая тема.