Оценка качества агентной системы

Что делает слой

Оценка — систематическая проверка качества retrieval, генерации и агентного поведения. Без неё систему нельзя улучшать: любое изменение промпта, модели или чанкинга оценивается по ощущениям, а регрессии обнаруживаются пользователями.

Оценка отвечает на три разных вопроса, и смешивать их нельзя:

1. Нашёл ли поиск нужное — качество retrieval.
2. Верен ли ответ — качество генерации и обоснованность контекстом.
3. Сделал ли агент нужное — выбор инструментов, аргументы, траектория, достижение цели.

Что измеряют

• Context Precision / Context Recall — сколько найденного релевантно и не потеряно ли нужное.
• Faithfulness — подтверждается ли ответ извлечённым контекстом, а не достроен моделью.
• Tool Call Accuracy — вызван ли правильный инструмент с корректными аргументами.
• Agent Goal Accuracy — достигнута ли цель задачи за отведённые шаги.
• Формат и структура — соответствует ли вывод схеме, которую парсит код.

Метрика без датасета бесполезна: набор задач с ожидаемым поведением важнее выбора библиотеки.

Инструменты

Инструмент	Что даёт
Langfuse	Трассировки, датасеты, эксперименты и оценка: LLM-as-a-judge, программные проверки, человеческая разметка
Ragas	Библиотека метрик для RAG и агентов: Context Precision, Context Recall, Faithfulness, Tool Call Accuracy
DeepEval	Тестирование LLM-приложений с интеграцией в pytest и CI/CD, оценка выбора инструментов и траектории
promptfoo	CLI для сравнения промптов, моделей и приложений на тест-кейсах; red teaming
LangSmith Evaluation	Датасеты, оценщики, offline-оценка перед релизом и online-оценка трассировок

Ключевое различие: Ragas — инструмент оценки, а не отдельная метрика. Langfuse — платформа, которая хранит и трассировки, и результаты проверок.

Рабочий цикл

1. Собрать набор задач с ожидаемым поведением (10–50 хватает для старта)
2. Прогнать базовую версию, зафиксировать результаты
3. Изменить промпт / модель / чанкинг
4. Прогнать тот же набор, сравнить
5. Добавить в набор новые production-ошибки

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

Оценка действий, а не только текста

Финальный ответ может быть красивым и при этом вредным. Поэтому проверяют:

• выбор инструмента — не вызван ли неразрешённый инструмент;
• аргументы вызова — не перепутаны ли идентификатор, сумма, получатель;
• соблюдение ограничений — не вышло ли действие за пределы политики;
• достижение цели — решена ли задача, а не «получен ли ответ».

Ограничения подхода

• LLM-судья смещён. Его оценки нужно сверять с человеческой разметкой; расхождение — повод пересмотреть критерии, а не доверять судье.
• Формат ≠ правильность. Успешная валидация схемы доказывает только то, что ответ разбирается парсером.
• Оценка стоит денег. Прогон датасета на сильной модели — регулярные расходы; дешёвая модель для рутинных проверок и сильная для спорных случаев обычно достаточна.
• Датасет стареет. Задачи, которые легко решает текущая модель, перестают что-либо измерять.

Что проверить в проекте

• Есть ли датасет вообще. До него любые разговоры о «стало лучше» — вкусовые.
• Проверяются ли действия. Агент с инструментами без проверки tool-call — половина системы вне контроля.
• Запускается ли оценка в CI. Проверка перед релизом дешевле разбора инцидента после.
• Пополняется ли набор. Источник новых кейсов — реальные ошибки, а не фантазия.

Материалы и источники

• Системное мышление для агентного ИИ — статья WPCraft, раздел «Evaluation»
• Ragas: метрики — список метрик RAG и агентов
• DeepEval: оценка агентов — проверки в pytest и CI
• promptfoo — сравнение промптов и red teaming