Ваш конспект

Систематическая оценка качества агентов (Eval)

Ключевые тезисы:

• Eval — это систематическая, автоматизированная и повторяемая проверка работы системы, выдающая измеримый результат.
• Для агентских систем (в отличие от single/multi-turn LLM) критически важно оценивать всю траекторию (reasoning, действия, состояние), а не только финальный ответ.
• Надёжный пайплайн оценки состоит из четырёх взаимосвязанных компонентов: корзина задач, инфраструктура, критерии и грейдинг.
• Качество оценки напрямую влияет на надёжность, безопасность и управляемость развития агента в продакшене.

Что такое Eval и почему это сложно для агентов

Eval (Evaluation) — это систематическая проверка системы: подача задачи, получение результата и применение логики оценки для измерения успешности.

Эволюция сложности Eval:

1. Single-turn LLM: один промт → один ответ → простая метрика.
2. Multi-turn LLM: добавляется диалог, состояние, следование контексту → диалоговые метрики.
3. Агентские системы: цикл reasoning → action → изменение состояния среды. Необходимо оценивать полную траекторию.

Агент — это система на базе LLM, которая автономно планирует и выполняет задачи с помощью внешних инструментов.

Зачем нужен Eval для агентов:

• Надёжность и безопасность: ловим баги до попадания к пользователям, особенно для агентов с сайд-эффектами.
• Понимание поведения: анализируем почему агент принял решение, а не только итог.
• Контроль прогресса и регресса: объективно сравниваем версии при изменении промта, модели или инструментов.
• Эффективность и коммуникация: получаем численные метрики для обоснованных решений (например, "дешевле, но немного хуже").

Почему оценивать агентов сложно:

• Каскадные ошибки: ошибка на одном шаге портит все последующие.
• Множество путей к успеху: агент может решить задачу неочевидным, но корректным способом, который не учтён в критериях.
• Стохастичность: система состоит из множества вероятностных компонентов (LLM), нельзя написать простой assert.
• Скрытые ошибки: агент может ошибиться в параметре, не вызвать нужный инструмент, но заявить об успехе.
• Проверка сайд-эффектов: важно убедиться, что агент реально выполнил задуманное действие в среде.

Терминология

• Корзина (Evaluation Suite) — набор тестовых задач для оценки.
• Задача (Task) — один тестовый пример с входными данными и критериями успеха.
• Прогон (Trial) — одна попытка выполнения задачи агентом.
• Траектория (Trace) — полная запись всех шагов, входов и выходов агента за прогон.
• Результат (Outcome) — финальное состояние среды после выполнения задачи (не текст ответа!).
• Оценщик/Судья/Грейдер (Grader) — логика, оценивающая конкретный аспект работы агента.
• Инфраструктура Eval (Eval Harness) — инженерная система для запуска и оценки прогонов.

Пайплайн оценки агентов (4 компонента)

Слабость в любом из компонентов обесценивает всю систему.

1. Корзина задач (Evaluation Suite)

Репрезентативный набор задач — самый ценный артефакт. Определяет, что именно мы оцениваем.

Как создавать и развивать:

• Версия 1: 5-10 задач "с потолка" + анализ ошибок первых прогонов + добавление corner-кейсов.
• Версия 2: Масштабирование через LLM-генерацию задач по матрицам (фичи × сценарии × персоны) + балансировка категорий.
• Версия 3: Фиксация регрессионного набора для CI/CD + постоянное пополнение багами и фидбеком из продакшена.

Источники задач:

• Ручной анализ и постановка
• Логи и обратная связь из продакшена (лучший источник реализма)
• Публичные бенчмарки (например, TAIBench)
• LLM-генерация (для масштабирования)

Структура задачи:

• Запрос пользователя
• Начальное состояние среды (БД, политики и т.д.)
• Ожидаемое конечное состояние среды

Свойства хорошей корзины:

• Недвусмысленность: два эксперта одинаково определяют успех/провал.
• Объективность: проверка по состоянию среды, а не только по тексту.
• Баланс: репрезентативное распределение по сложности и типам задач.
• Решаемость: для каждой задачи есть reference solution.
• Двунаправленность: есть задачи, где агент должен и не должен действовать.
• Воспроизводимость: задача выполняется с чистого состояния много раз.
• Тегирование: задачи помечены сложностью, категорией, навыком для детального анализа.

2. Инфраструктура прогонов (Eval Harness)

Инженерная система, обеспечивающая воспроизводимость, изоляцию и масштабирование.

Ключевой принцип: Агент в Eval должен быть тем же самым, что и в продакшене (код, промт, тулы). Различаться должно только окружение (мокированная/тестовая среда).

Компоненты инфраструктуры:

• Раннер (Runner): запускает агента на корзине параллельно, с таймаутами и ретраями.
• Окружение (Environment): изолированная среда для каждого прогона с чистым состоянием.
• Логгер/Трейсер (Logger/Tracer): фиксирует полную траекторию (запросы к тулам, ответы, reasoning).
• Железный пользователь (Iron User): LLM-based симулятор пользователя для мульти-турных диалогов.
• Хранилище (Storage): хранит все прогоны, траектории, метрики.
• Компаратор (Comparator): инструмент для сравнения разных прогонов (например, двух версий агента).

Железный пользователь (Iron User):

• Цель: симулировать поведение реального пользователя в диалоге.
• Проблемы: недетерминированность, галлюцинации, излишняя "кооперативность", риск бесконечных циклов.
• Решения: верификация ответов другой LLM, ограничение по числу шагов, чёткие сценарии.

Чек-лист для инфраструктуры:

• Запуск на общей виртуалке (не на ноутбуке)
• Стабильность (retry, graceful shutdown)
• Автоматическая выгрузка результатов
• Параллельный запуск задач
• Возможность сравнения версий
• Полная изоляция сред

3. Критерии оценки (Criteria)

Правила, определяющие, что такое "успех" агента.

Свойства хорошего критерия:

• Соответствие цели (Aligned): измеряет то, что действительно важно.
• Проверяемость (Checkable): можно автоматизировать.
• Понятность (Readable): смысл ясен без объяснений.
• Дискриминативность (Diagnosable): по провалу понятно, что чинить.
• Стабильность (Stable): не зависит от интерпретации и не дрейфует.

Две группы критериев:

1. Output-based: проверяют свойства конечного результата (формат ответа, вызов нужного тула, изменение состояния среды). Реализуются через ассерты и state-чеки.
2. Поведенческие (Trajectory-based): оценивают путь к результату (логичность цепочки, сохранение цели, эффективность, обоснованность действий). Требуют LM-судьи.

Пример универсальных критериев для ассистента:

• Полезность: решил ли задачу пользователя? (Output-based, state-check)
• Корректность: были ли ошибки/исключения? (Output-based, strict-check)
• Обоснованность: соответствуют ли действия/параметры диалогу? (Trajectory-based, LM Judge)
• Эффективность: можно ли было сделать меньше шагов/потратить меньше токенов? (Trajectory-based)
• Стабильность: насколько стабильно агент решает одну и ту же задачу? (Pass@K, Success@K)
• Безопасность/Этика: соблюдал ли политики общения? (Output-based, классификатор)

Метрики стабильности (из-за стохастичности):

• Pass@K: вероятность, что хотя бы один из K прогонов успешен. Полезна для задач с повторными попытками (генерация кода).
• Success@K: вероятность, что все K прогонов успешны. Критична для ассистентских агентов.

4. Грейдинг (Grading)

Процесс применения критериев к конкретному прогону.

Три типа грейдеров (используются в комбинации):