Оцени, прежде чем доверять: как сделать AI-агента полезным

Начальные шаги по созданию агента на базе LLM (например, юридического агента, пишущего контракты, или банковского агента, одобряющего или отклоняющего заявки на кредит) выполняются удивительно быстро. С помощью простых промптов, few-shot обучения, Retrieval-Augmented Generation (RAG) и структурированных выходных данных многие разработчики могут собрать proof of concept всего за несколько дней. Инструменты вроде v0.dev и bolt.new позволяют сократить этот этап до нескольких часов.

Однако агент, работающий в нескольких конкретных тестовых кейсах, — это лишь начало. Переход от первого драфта к продакшн-готовому агенту требует серьёзных усилий. Разработчикам приходится делать бесконечное количество тонких настроек, чтобы добиться быстрых, стабильных, надежных и экономически эффективных результатов. Это одна из характерных особенностей программирования AI-агентов.

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

• Архитектура модели:

— Для монолитных агентов — размер LLM.
— Для роев специализированных агентов — зоны ответственности каждого агента, их количество, размер и т.д.

• Вендор модели: Anthropic, Google, Meta, Mistral, OpenAI и др., а также конкретные версии моделей.
• Параметры модели: temperature, top-k, top-p и т.п.
• Инструкции в промпте.
• Примеры для few-shot learning.
• При использовании RAG:

— Процесс индексации и стратегия chunking для документов.
— Embedding-модель.
— Векторная база данных (pgvector, Pinecone, Faiss и др.).
— Метрика схожести (косинусное сходство, approximate nearest neighbor и др.).
— Количество извлекаемых chunkов.
— Логика reranking'а.

• Guardrailing: вспомогательные модели меньшего размера для проверки на вредоносные или нерелевантные выходные данные.
• Инфраструктура модели: кэширование, quantization, timeouts и прочее.
• Логика пост-процессинга.

Количество возможных комбинаций этих параметров — огромное. По моему опыту, поиск оптимальной конфигурации может занять недели. Я бы оценил, что около 90% времени, затраченного на разработку агента, уходит именно на фазу оптимизации.

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

Агент, как правило, должен удовлетворять ряду требований:

• Предоставляемый им сервис должен быть полезным.
• Он не должен галлюцинировать или выдавать неверные ответы.
• Формат вывода должен быть стабильным и предсказуемым.
• Агент должен корректно обрабатывать широкий спектр входов, включая пограничные кейсы.
• Он должен избегать вредоносного контента (например, предвзятости, дезинформации).
• Ответ должен приходить в разумные сроки.
• Решение должно быть экономически эффективным.

Идеально, если все эти требования выполняются одновременно, но на практике они часто конфликтуют. Например, уменьшение размера модели с целью снижения затрат может привести к ухудшению качества ответа. Задача оптимизации — найти наилучший компромисс между этими параметрами.

Традиционно разработчики ПО используют unit-тесты, integration-тесты и end-to-end тесты, чтобы убедиться, что их код работает как положено. Но LLM по своей природе стохастичны и не детерминированы, поэтому эти методы здесь не работают. Вместо этого требуется другой подход.

Существующая в AI специализированная область — Model Evaluation (чаще просто оценка/eval) — занимается измерением эффективности работы AI-агентов. Суть заключается в том, чтобы оценивать модель по её выходным данным. Однако эта задача остаётся непростой: большинство специалистов сходятся во мнении, что оценка LLM по своей природе крайне сложна.

Среди eval-инструментов есть общие бенчмарки, такие как HELM, MMLU или Chatbot Arena — они полезны для оценки foundation-моделей, но недостаточны, когда речь идёт о кастомных агентах. Агентам, ориентированным на конкретные задачи, требуются инструменты, способные измерять производительность в контексте адаптированных, приближенных к реальности сценариев. К счастью, таких инструментов уже немало.

Процесс оценки AI-агентов опирается на специализированные тулкиты и фреймворки, которые упрощают и автоматизируют тестирование. Наиболее распространённые из них:

• Библиотеки: DeepEval, Ragas, Promptfoo, HuggingFace Evaluate, Prometheus Eval, OpenAI evals
• Платформы: LangSmith, Weights & Biases, OpenAI Eval API, Anthropic Evaluation, Laminar evaluations

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

Среди них:

• Детерминированные метрики:

– Стоимость (Cost)
– Время отклика (Response time)
– Наличие конкретной строки в output'е (String presence)
– Перплексия (Perplexity)
– F-Score
– BLEU / ROUGE

• Вероятностные (модельно-основанные) метрики:

– Фактическая точность (Factual correctness)
– Релевантность (Relevance)
– Токсичность (Toxicity)

Для более полного списка см. гайд по метрикам в Ragas.

Выбор правильных метрик критически важен, но этого недостаточно. В дополнение к автоматическим метрикам разработчики агентов часто тратят немало времени на human evaluation — в основном, вручную просматривая выборки выходных данных агента.

Некоторые продвинутые инструменты, известные как LLM-as-judge, позволяют оценивать ответы агента, сравнивая их с эталонным вариантом — написанным человеком или сгенерированным мощной LLM, например, Claude. Более того, можно обучить компактные модели специально для роли автоматизированных оценщиков.

Вот пошаговое руководство по оценке AI-агента:

1. Создание тестового датасета

Соберите или сгенерируйте входные данные для агента. Включите разнообразные примеры, edge cases и сложные сценарии, которые должны отражать реальные задачи, для которых предназначен агент.

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

2. Выберите метрики и инструменты

Выберите метрики, соответствующие требованиям к агенту. Например, агента для суммирования можно оценивать по метрикам вроде ROUGE score, accuracy, completeness, размера summary, времени отклика и стоимости одного запроса.

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

Постройте eval-платформу — от простого ноутбука до полностью автоматизированного пайплайна, способного выполнять тысячи оценок параллельно.

3. Запустите агента на тестовом датасете

Это сгенерирует output для каждого примера из тестового датасета.

4. Рассчитайте оценку для запуска

Для каждого output'а вычислите метрики из шага 2 с использованием eval-платформы. Затем рассчитайте агрегированные значения метрик по всему датасету, используя статистические показатели, такие как среднее значение, медиана и процентили. В завершение, на основе этих метрик вычислите итоговую оценку модели.

5. Обновите агента

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

Затем вернитесь к шагу 3 и повторяйте процесс до тех пор, пока не найдете оптимальную конфигурацию.

Мы давно занимаемся оценкой и за это время усвоили несколько важных уроков. Вот рекомендации, которые помогут сделать ваш процесс оценки более результативным:

Подготовка

• Стройте с прицелом на гибкость:

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

• Инвестируйте в тестовый датасет:

Потратьте время на создание разнообразного и устойчивого набора данных. Включайте edge cases, сложные входы и все критически важные сценарии. Если 25% времени уходит на это — считайте, что это инвестиция, а не потеря времени.

• Ставьте четкие цели заранее:

Определите целевой скор и приоритеты до начала оптимизации. Без конкретной цели можно застрять в бесконечном fine-tuning'е.

Метрики и оценка

• Фокусируйтесь на ключевых метриках:

Не отслеживайте слишком много метрик одновременно — это замедлит прогон бенчмарков. Поскольку тесты придётся запускать тысячи раз, выбирайте только самые релевантные показатели.

• Сначала тестируйте метрики:

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

• Храните результаты:

Фиксируйте все прогоны: конфигурации агента, тестовые данные, результаты — в индексируемом хранилище. Это станет незаменимым при отладке и дальнейшей оптимизации.

• Ищите выбросы:

После каждого прогона проверяйте edge cases и outliers. Часто именно они выявляют критические баги или зоны для улучшения.

• Не ограничивайтесь средними значениями:

Ориентируйтесь на распределение и перцентили, а не только на среднее значение. Хороший агент должен стабильно работать на всём спектре входов, а не только в "среднем случае".

• Следите за вариативностью:

Обращайте внимание на стандартное отклонение метрик. Игнорируйте незначимые флуктуации — они могут ввести в заблуждение при оптимизации.

Оптимизация и мониторинг

• Отслеживайте прогресс визуально:

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

• Не полагайтесь только на агрегированную оценку:

Model grade — полезен, но не отражает всей картины. Установите пороговые значения для ключевых метрик и убедитесь, что агент стабильно их выдерживает.

• Изучайте всё пространство конфигураций:

Постройте матрицу возможных параметров и систематически прогоняйте их.

• Начинайте с максимального качества, потом оптимизируйте:

Сначала используйте самые большие модели — так вы фиксируете базовый уровень качества. Затем постепенно снижайте размер модели, чтобы сократить стоимость и ускорить ответы, но только если качество остается приемлемым.

• Используйте продакшен-данные:

После деплоя агент начнет сталкиваться с новыми edge cases и вызовами. Отслеживайте его поведение в проде и возвращайте эти данные обратно в eval-процесс.

Фаза оценки критически важна для создания успешных AI-агентов. Пользователь может потерять доверие после всего одной ошибки, поэтому поиск наилучшей конфигурации — с учётом стоимости, скорости, релевантности и других факторов — абсолютно необходим.

Этот процесс требует специфических навыков и инструментов, которыми у разработчиков может пока не быть. Потратьте время на создание надежного тестового датасета, выбор правильных метрик и использование лучших eval-инструментов. Да, путь будет долгим — но усилия того стоят.