Как оценивать ИИ‑агентов в проде: нижняя планка, трассы и кодовые проверки

О чем здесь речь

Под ИИ‑агентом я дальше понимаю систему, которая отвечает текстом и сама выбирает шаги: вызывает функции, ищет данные, читает файлы, работает с RAG, открывает тикеты, меняет статус заказа, пишет код или запускает команды.

Для таких систем привычный вопрос «хороший ли у нас промпт» слишком узкий. Агент может получить хороший промпт и все равно ошибиться из‑за старого индекса поиска, неверной схемы прав, неудачного вызова инструмента или состояния продукта, которое тест вообще не воспроизвел.

Оценка качества агента похожа на тестирование программного продукта. Есть вход, есть окружение, есть код, есть состояние, есть ожидаемый результат. Разница в том, что внутри появляется вероятностная часть, поэтому вдобавок к unit‑тестам нужен регулярный разбор реальных ошибок.

Сначала выберите цель проверки

Перед тем как писать первые evals, полезно честно ответить: вы хотите показать высокий балл на бенчмарке или сделать так, чтобы агент реже проваливался в важных сценариях?

Для исследовательской модели, которая помогает эксперту, бенчмарк может быть нормальной целью. Эксперт увидит странный ответ, перепроверит, поправит. Для продуктового агента, который заменяет кусок работы человека, важнее нижняя планка надежности. Пользователь не будет изучать ваш средний балл, если агент уверенно ошибся там, где ошибка ^[1] дорогая.

Возьмем финансового агента. Пусть он умеет находить подписки, прогнозировать траты и сам отменять лишние сервисы. Все это бесполезно, если иногда он не может ответить на простой вопрос: «Сколько денег у меня на счете?» После такой ошибки доверие ломается быстрее, чем растет от сложных возможностей.

Хороший тест для команды звучит так: если у вас есть версия с 90% успешных прогонов и версия с 99%, какой вопрос вы зададите первым? Если только «почему не 99%», вы мыслите как владелец бенчмарка. Если первый вопрос «какой именно 1% падает», вы мыслите как команда, которая поднимает нижнюю планку.

Поднимать нижнюю планку значит разбирать ошибки

Этот подход близок к error analysis: разбор ошибок часто дает самый высокий возврат на вложенное время в разработке ИИ‑систем. Для агентов это особенно заметно.

Работа начинается не с абстрактного набора тестов. Сначала нужно читать реальные или максимально похожие на реальные трассы:

• сообщение пользователя;

• ответ агента;

• найденный контекст;

• вызовы инструментов;

• ошибки инструментов;

• промежуточные решения;

• финальное состояние продукта.

По каждой плохой трассе стоит задавать одни и те же вопросы.

• Где был последний правильный шаг?

• Где случился первый настоящий сбой?

• Поиск не нашел нужный документ?

• Агент проигнорировал найденный контекст?

• Инструмент вернул ошибку, а агент сделал вид, что все нормально?

• Финальный ответ был увереннее, чем позволяли данные?

• Ошибка относится к одному случаю или к классу похожих сценариев?

Затем чинится паттерн, который породил инцидент. Иногда нужен лучший поиск. Иногда — ограничение действий агента. Иногда — новый guardrail, изменение схемы инструмента, более явная ошибка в API или правило «остановись и скажи, что данных не хватает».

После этого ошибка превращается в targeted eval: тест, который фиксирует конкретный урок. Набор проверок становится памятью ^[2] о важных сбоях, которые команда не хочет вернуть в продукт.

«Не знаю» часто лучше уверенной ошибки

Одна из самых дешевых техник для повышения надежности — научить агента отказываться от ответа при нехватке данных.

Примеры правил:

• если найденный контекст не содержит нужной политики, агент пишет, что не может подтвердить ответ;

• если запрос вне домена продукта, агент не фантазирует;

• если инструмент вернул ошибку, агент не говорит «готово»;

• если действие требует прав, которых нет, агент останавливается и объясняет причину.

На бенчмарках такие отказы могут выглядеть как падение успешности. В продукте уверенная выдумка часто хуже честного «не знаю». Особенно если агент заменяет участок работы человека.

До релиза: 5–10 эталонных сценариев

Перед первым запуском в прод не нужно строить огромную систему оценок. Начните с 5–10 сценариев, которые покрывают критические пути.

Такой сценарий можно хранить даже в markdown:

## Возврат денег по счету с действующей политикой

Пользователь: "Верни деньги по счету inv_123"

Ожидаемое поведение:
- агент находит счет через lookupInvoice;
- проверяет, что счет подходит под политику возврата;
- вызывает createRefund;
- отвечает пользователю, что возврат создан.

Проверяем:
- итоговый статус: approved;
- вызовы инструментов: lookupInvoice, createRefund;
- агент не обещает ручных действий, которых не выполнил;
- агент не раскрывает внутренние данные счета сверх нужного.

Это не обязано быть красиво. Важно, чтобы команда явно зафиксировала: вот пути, на которых агент не имеет права ломаться. Если новая версия падает на таком сценарии, релиз останавливается.

Проверяйте весь путь агента

Финальный ответ может выглядеть нормальным, хотя путь был плохим. Агент мог вызвать лишний инструмент, проигнорировать ошибку, взять данные из старого индекса или случайно получить правильный результат.

Для эталонных сценариев полезно смотреть всю доступную трассу:

• какие инструменты были вызваны;

• с какими аргументами;

• какой контекст был найден;

• какие ошибки появились;

• что изменилось в состоянии системы;

• какие файлы, записи или объекты были созданы.

Инструменты вроде Raindrop Workshop ^[3] помогают локально захватывать и просматривать трассы. Но сама идея не привязана к конкретному сервису. Для начала хватит логов, локального harness и простого HTML‑отчета, если они показывают путь агента целиком.

Иногда полезно спросить самого агента

У агентов часто нет открытой цепочки рассуждений. Даже когда фреймворк показывает часть траектории, внутренние рассуждения модели могут быть недоступны или намеренно скрыты.

Еще один практичный прием: восстановить запуск ровно в том виде, в котором его получил агент, добавить видимую трассу и спросить модель:

Ты ошибся. Правильный ответ был X. Что нужно было изменить во входных данных, контексте или инструкциях, чтобы ты ответил правильно?

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

Это диагностический прием. Автоматическим судьей он не становится.

Офлайн‑проверки должны запускать реальный путь агента

Когда агент связан с кодом, инструментами, поиском, правами и состоянием продукта, проверка промпта отдельно теряет смысл. Поведение ^[4] живет в системе целиком.

Офлайн eval для агента больше похож на обычный тест в pytest, Vitest или jest:

1. Подготовить окружение и состояние.

2. Запустить реальный agent loop или максимально близкий harness.

3. Подать пользовательский запрос.

4. Проверить ответ, вызовы инструментов, измененные данные и побочные эффекты.

В vitest‑evals ^[5] от Sentry эта идея выглядит примерно так:

// evals/refund-agent.eval.ts
import { expect } from 'vitest'
import { describeEval, toolCalls } from 'vitest-evals'
import { refundAgentHarness } from '../harness'

describeEval('refund agent', { harness: refundAgentHarness() }, (it) => {
  it('approves refundable invoice', async ({ run }) => {
    const result = await run('Refund invoice inv_123')

    expect(result.output.status).toBe('approved')
    expect(toolCalls(result.session).map((c) => c.name)).toEqual([
      'lookupInvoice',
      'createRefund',
    ])
  })
})

OpenAI в cookbook про macro evals для агентных систем ^[6] описывает тот же принцип: прогонять полный цикл агента на репрезентативных входах и оценивать траекторию, включая инструменты, промежуточное состояние и финальный ответ.

Название вторично. Главное — проверять агента целиком, включая LLM, код и инструменты.

Локальный отчет часто лучше раннего дашборда

Для первых проверок не обязательно покупать или строить большой hosted dashboard. У агентных evals самая сложная часть обычно находится рядом с продуктом: поднять нужное состояние, подменить внешние сервисы, дать правильные права, сохранить трассу и проверить побочные эффекты.

UI отчета сделать проще, чем хороший harness. Поэтому на раннем этапе разумно держать проверки рядом с кодом продукта и выводить простой локальный отчет:

• сценарий;

• pass/fail;

• финальный ответ;

• список вызовов инструментов;

• отличия от ожидаемого состояния;

• ссылка на полную трассу.

Такой отчет можно открыть в браузере после CI или локального запуска. Он скучный, зато команда видит именно те данные, которые нужны для отладки.

После релиза главный источник данных — пользователи

До релиза команда предполагает, где агент может сломаться. После релиза пользователи показывают это сами.

Начинать стоит с сырых логов. Читать сообщения пользователей, ответы агента, вызовы инструментов, ошибки и моменты, где ожидание пользователя разошлось с поведением ^[7] продукта. Делать это нужно до насыщения: пока одни и те же паттерны не начнут повторяться.

Это медленная работа. Зато без нее легко автоматизировать не те метрики. Например, можно долго улучшать среднюю оценку ответа, но пропустить, что пользователи злятся из‑за одного конкретного типа отказа или из‑за невнятного объяснения после ошибки инструмента.

Масштаб процесса зависит от объема

По объему запусков удобно ориентироваться на такую лестницу.

1–100 запусков в день

Читайте почти все. Ищите путаницу, раздражение, повторные запросы, почти‑ошибки, ситуации «пользователь вынужден объяснять продукту, как им пользоваться». Цель этапа — вкус ^[8] и таксономия: понять, какие сбои вообще бывают.

100–1000 запусков в день

Повторяющиеся сбои превращайте в issues: обсуждаемые проблемы, которые можно воспроизвести, оценить по важности и решить. На этом этапе уже полезны кластеры похожих трасс и ручная разметка причин.

1000+ запусков в день

Появляются долгоживущие сигналы: жалобы на тон ответа, плохие отказы, игнорирование ошибок инструментов, потеря контекста после нескольких шагов, признаки пользовательского раздражения. Тут помогает автоматическая классификация, но ее нужно калибровать на уже изученных примерах.

5000+ запусков в день

Исправления лучше катить как эксперименты: фича‑флаг, часть трафика, сравнение affected issues и сигналов. Офлайн eval покажет, что вы не сломали эталонные сценарии. Прод покажет, стало ли лучше для пользователей.

Самодиагностика агента полезна, но шумная

В Raindrop есть идея самодиагностики: в запуск агента добавляется скрытый инструмент, через который агент может сообщить о проблеме. Например, ему не хватает контекста, сломан инструмент, не хватает возможности или он понимает, что задача не выполнена.

В интеграции это может выглядеть так:

const { generateText } = raindrop.wrap(ai, {
  selfDiagnostics: { enabled: true },
})

Концептуально скрытый инструмент похож на такой вызов:

__raindrop_report({
  category: 'missing_context',
  summary: 'I could not find the refund policy for enterprise plans.',
  severity: 'medium',
})

Практическая оговорка важнее кода: такие сигналы не становятся качественными сами по себе. Формулировка инструкции влияет на то, будет ли агент вообще репортить проблему. Чувствительность приходится настраивать. На деле это задача бинарной классификации с шумными признаками.

Относиться к самодиагностике лучше как к дополнительному потоку подсказок. Иногда там найдется полезный паттерн, но заменять этим чтение трасс нельзя.

Как чинить найденные проблемы

Некоторые исправления прямые. Сломался вызов инструмента. В системном промпте не хватает явного правила. Поиск возвращает устаревший документ. В таком случае правка понятна: исправить, прогнать проверки, выкатить.

Сложные проблемы сначала нужно воспроизвести. Если команда не может снова получить сбой, она еще не поняла причину. Нужно вернуться к трассе, найти похожие случаи, отделить симптом от источника.

Хороший цикл выглядит так:

1. Найти сбой в проде.

2. Воспроизвести локально.

3. Добавить эталонный сценарий или eval, если сбой важный и может повториться.

4. Исправить систему.

5. Проверить, что eval проходит.

6. Выложить изменение.

7. Смотреть, как поменялись продовые сигналы.

Опасное место — специальные правила под конкретную фразу пользователя. Обработка одного текста редко чинит класс ошибок и часто приносит более странный баг позже. Например, правило «если пользователь написал „верни оплату“, вызови createRefund» слабее расследования: почему агент не понимает намерение возврата как класс?

Не каждый баг заслуживает место в eval suite

Есть соблазн добавлять в проверки каждый найденный баг. Через полгода в наборе 500 сценариев, из них 400 про редкие крайние случаи, которые больше никто не видел. CI идет 20 минут. Команда начинает игнорировать падения, потому что «там опять что‑то в evals».

Набор проверок нужно чистить так же, как код.

Перед добавлением сценария спросите:

• это критический путь?

• ошибка может вернуться после будущих изменений?

• сценарий представляет класс проблем?

• его можно стабильно воспроизвести?

• падение этого теста будет требовать немедленной реакции ^[9]?

20 сильных проверок обычно полезнее 200 слабых. Если сценарий не падал три месяца, стоит проверить, нужен ли он еще. Возможно, агент действительно стал лучше. Возможно, тест давно не ловит ничего важного.

Закладывайте время на оценку качества

Практичная рекомендация — планировать 10–20% времени разработки агента на оценку и мониторинг. Не только на написание тестов. В это время входят чтение трасс, группировка ошибок, настройка сигналов, расследование issues, поддержка harness, чистка eval suite и проверка продовых экспериментов.

Это выглядит дорого, пока первый инцидент не попадет к пользователям. Агентные системы ломаются в неочевидных местах. Они могут уверенно ошибаться после третьего вызова инструмента, терять часть контекста, неправильно интерпретировать отказ API или красиво объяснять действие, которое не выполнили.

Если этот контур не поддерживать постоянно, набор проверок устаревает. Уверенность становится театром: отчеты зеленые, а продукт уже изменился.

Что может измениться дальше

Сейчас многие агенты построены как SDK плюс модель плюс явный tool loop. Такой подход удобно трассировать: видны инструменты, сообщения, промежуточные состояния.

Но граница между моделью и агентом размывается. Claude Code, Cursor CLI и похожие инструменты уже выглядят как агент, который живет внутри модели и ее окружения. Чем меньше явного harness‑кода, тем сложнее смотреть внутрь.

Это меняет мониторинг. Если промежуточные шаги становятся непрозрачными, сильнее растет роль end‑to‑end проверок: вход, состояние, результат, побочные эффекты. Эталонные сценарии и продовый разбор не исчезают. Они становятся главным способом понять, делает ли автономная система то, что от нее ждут.

Минимальный план для команды

Если нужно начать на этой неделе, я бы сделал так:

1. Выписал 5–10 критических пользовательских сценариев.

2. Для каждого сценария описал ожидаемый ответ, инструменты и изменения состояния.

3. Настроил локальный запуск агента через harness, близкий к продовому пути.

4. Добавил простой отчет pass/fail с трассой.

5. После релиза начал читать сырые логи до повторения ^[10] паттернов.

6. Повторяющиеся сбои оформлял как issues.

7. Важные воспроизводимые сбои добавлял в eval suite.

8. Раз в несколько недель чистил проверки, которые перестали давать сигнал.

Главная мысль здесь простая: надежность агента растет не от большого количества синтетических тестов. Она растет от плотного контакта с реальными ошибками, быстрых воспроизведений и небольшого набора проверок, которые защищают критические пути.

Источник — howtoeval.com ^[11]

Сообщество энтузиастов — https://t.me/agents_lab ^[12], а также наш уютный чатик — https://t.me/agents_lab_community ^[13]