ai-agents-for-beginners
AI-агенты в промышленной эксплуатации: наблюдаемость и оценка
По мере того как AI-агенты переходят от экспериментальных прототипов к реальным приложениям, становится важным умение понимать их поведение, контролировать их производительность и систематически оценивать их результаты.
Цели обучения
После прохождения этого урока вы будете знать и понимать:
- Основные концепции наблюдаемости и оценки агентов
- Методы улучшения производительности, затрат и эффективности агентов
- Что и как систематически оценивать у ваших AI-агентов
- Как контролировать затраты при развертывании AI-агентов в промышленной эксплуатации
- Как инструментировать агентов, построенных с помощью Microsoft Agent Framework
Цель — дать вам знания, которые помогут превратить ваших “черных ящиков” агентов в прозрачные, управляемые и надежные системы.
Примечание: Важно развертывать AI-агентов, которые являются безопасными и заслуживают доверия. Также ознакомьтесь с уроком Создание заслуживающих доверия AI-агентов.
Трейсы и спаны
Инструменты наблюдаемости, такие как Langfuse или Microsoft Foundry, обычно представляют запуски агентов в виде трейсов и спанов.
- Трейс представляет собой полное задание агента от начала до конца (например, обработка пользовательского запроса).
- Спаны — это отдельные шаги внутри трейса (например, вызов языковой модели или получение данных).
Без наблюдаемости AI-агент может ощущаться как “черный ящик” — его внутреннее состояние и логика не прозрачны, что затрудняет диагностику проблем и оптимизацию производительности. С наблюдаемостью агенты становятся “стеклянными ящиками”, предлагая прозрачность, которая крайне важна для построения доверия и обеспечения правильной работы.
Почему наблюдаемость важна в производственной среде
Переход AI-агентов в производственную среду приводит к новым вызовам и требованиям. Наблюдаемость уже не просто “желательная”, а критически необходимая функция:
- Отладка и анализ корневых причин: Когда агент не справляется или выдает неожиданный результат, инструменты наблюдаемости предоставляют трейсы, позволяющие точно определить источник ошибки. Это особенно важно для сложных агентов с множественными вызовами LLM, взаимодействиями с инструментами и условной логикой.
- Управление задержками и затратами: AI-агенты часто используют LLM и другие внешние API, которые тарифицируются по токенам или вызовам. Наблюдаемость позволяет точно отслеживать эти вызовы, помогая выявлять слишком медленные или дорогие операции. Это даёт возможность оптимизировать запросы, выбирать более эффективные модели или перестраивать рабочие процессы для управления затратами и обеспечения хорошего пользовательского опыта.
- Доверие, безопасность и соответствие: Во многих приложениях важно гарантировать, что агенты ведут себя безопасно и этично. Наблюдаемость обеспечивает аудит действий и решений агента. Это можно использовать для обнаружения и предотвращения таких проблем, как инъекция подсказок, генерация вредоносного контента или неправильное обращение с персональными данными (PII). Например, можно просмотреть трейсы, чтобы понять, почему агент дал определённый ответ или использовал определённый инструмент.
- Циклы непрерывного улучшения: Данные наблюдаемости — это основа итеративного процесса разработки. Мониторинг работы агентов в реальном мире позволяет командам выявлять области для улучшения, собирать данные для тонкой настройки моделей и проверять эффективность изменений. Это создает замкнутый цикл, в котором данные из онлайн-оценки помогают определять эксперименты и доработки, что приводит к постепенному улучшению работы агента.
Ключевые метрики для контроля
Для контроля и понимания поведения агента следует отслеживать множество метрик и сигналов. Хотя конкретные метрики могут варьироваться в зависимости от цели агента, некоторые из них универсальны.
Вот несколько наиболее распространённых метрик, которые отслеживают инструменты наблюдаемости:
Задержка: Насколько быстро агент отвечает? Длительное время ожидания негативно влияет на пользовательский опыт. Следует измерять задержку для задач и отдельных шагов, отслеживая запуски агента. Например, агент, который совершает все вызовы модели за 20 секунд, можно ускорить, используя более быструю модель или запуская вызовы моделей параллельно.
Затраты: Какова стоимость каждого запуска агента? AI-агенты зависят от вызовов LLM, тарифицируемых по токенам, или внешних API. Частое использование инструментов или множество подсказок может быстро увеличить затраты. Например, если агент обращается к LLM пять раз ради незначительного улучшения качества, нужно оценить, оправданы ли затраты или можно снизить количество вызовов либо использовать более дешевую модель. Мониторинг в реальном времени помогает выявлять неожиданные всплески (например, из-за ошибок, вызывающих циклы API).
Ошибки запросов: Сколько запросов агент не смог обработать? Это может включать ошибки API или неудачные вызовы инструментов. Для повышения надежности агента в производстве можно настроить резервные варианты или повторные попытки. Например, если провайдер LLM A недоступен, переключитесь на провайдера B в качестве резерва.
Обратная связь пользователей: Реализация прямой оценки пользователями дает ценные данные. Это могут быть явные оценки (👍лайк/👎дизлайк, ⭐от 1 до 5 звезд) или текстовые комментарии. Последовательный негативный отзыв должен вызывать сигнал тревоги, так как это признак того, что агент работает не так, как ожидалось.
Неявная обратная связь пользователей: Поведения пользователей дают косвенную обратную связь даже без явных оценок. Это может включать немедленное переформулирование вопроса, повторные запросы или нажатия на кнопку повторного запроса. Например, если вы видите, что пользователи многократно задают один и тот же вопрос, это знак, что агент работает неэффективно.
Точность: Как часто агент генерирует правильные или желательные результаты? Определения точности различаются (например, правильность решения задачи, точность поиска информации, удовлетворенность пользователя). Первый шаг — определить, что для вашего агента значит успех. Вы можете отслеживать точность через автоматизированные проверки, оценки, или метки завершения задач. Например, отмечая трейсы как «успешные» или «неуспешные».
Автоматизированные метрики оценки: Вы также можете настроить автоматическую оценку. Например, использовать LLM для оценки выходных данных агента по критериям полезности, точности и т.д. Существуют открытые библиотеки для оценки различных аспектов работы агента, например RAGAS для RAG-агентов или LLM Guard для обнаружения вредоносного языка и инъекций подсказок.
На практике комбинация этих метрик дает наилучшее представление о состоянии AI-агента. В этом разделе в примерном блокноте мы покажем, как эти метрики выглядят на реальных примерах, а сначала изучим типичный рабочий процесс оценки.
Инструментируйте вашего агента
Чтобы собирать данные трассировки, нужно инструментировать ваш код. Цель — внедрить в код агента механизмы для создания трейсов и метрик, которые можно захватывать, обрабатывать и визуализировать с помощью платформы наблюдаемости.
OpenTelemetry (OTel): OpenTelemetry стал отраслевым стандартом для наблюдаемости LLM. Он предоставляет набор API, SDK и инструментов для создания, сбора и экспорта телеметрических данных.
Существует множество библиотек для инструментирования, которые оборачивают существующие фреймворки агентов и облегчают экспорт спанов OpenTelemetry в инструменты наблюдаемости. Microsoft Agent Framework интегрирован с OpenTelemetry изначально. Ниже пример инструментирования агента MAF:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# Agent execution is traced automatically
pass
В примерном блокноте этого раздела показано, как инструментировать вашего агента MAF.
Ручное создание спанов: Хотя библиотеки инструментирования обеспечивают хорошую базу, часто требуется более подробная или кастомная информация. Вы можете создавать спаны вручную для добавления пользовательской логики приложения. Более того, вы можете обогащать автоматически или вручную созданные спаны пользовательскими атрибутами (также называемыми тегами или метаданными). Эти атрибуты могут включать бизнес-данные, промежуточные вычисления или любой контекст, полезный для отладки или анализа, например user_id, session_id или model_version.
Пример ручного создания трейсов и спанов с помощью Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
Оценка агента
Наблюдаемость даёт нам метрики, а оценка — это процесс анализа этих данных (и проведения тестов), чтобы понять, насколько хорошо работает AI-агент и как его можно улучшить. Другими словами, имея трейсы и метрики, как их использовать для оценки агента и принятия решений?
Регулярная оценка важна, потому что AI-агенты часто не детерминированы и могут эволюционировать (через обновления или изменения поведения модели) – без оценки вы не узнаете, хорошо ли ваш “умный агент” справляется со своей задачей или же ухудшился.
Существуют две категории оценки агентов: онлайн-оценка и оффлайн-оценка. Обе ценны и дополняют друг друга. Обычно начинают с оффлайн-оценки, так как это минимальный необходимый шаг перед развертыванием любого агента.
Оффлайн-оценка
Это оценка агента в контролируемой среде, обычно с использованием тестовых наборов данных, а не живых пользовательских запросов. Вы используете подготовленные датасеты, где известен ожидаемый результат или правильное поведение, и запускаете агента на этих данных.
Например, если вы создали агента для решения текстовых математических задач, у вас может быть тестовый набор данных из 100 задач с известными ответами. Оффлайн-оценка часто проводится во время разработки (и может быть частью CI/CD) для проверки улучшений или предотвращения регрессий. Преимущество — это повторяемость и получение четких метрик точности, так как у вас есть эталонные данные. Можно также симулировать пользовательские запросы и измерять ответы агента по сравнению с идеальными ответами или использовать автоматические метрики, описанные выше.
Основная сложность оффлайн-оценки в том, чтобы набор тестовых данных был всесторонним и актуальным — агент может хорошо вести себя на фиксированном тестовом наборе, но столкнуться с совершенно иными запросами в продакшене. Поэтому тестовые наборы следует обновлять, добавляя новые крайние случаи и примеры, отражающие реальные сценарии. Полезно сочетать небольшие “смоук-тесты” для быстрой проверки и большие наборы для обширной оценки.
Онлайн-оценка
Это оценка агента в реальном, производственном окружении, то есть во время фактического использования. Онлайн-оценка включает мониторинг производительности агента в реальных взаимодействиях с пользователем и непрерывный анализ результатов.
Например, вы можете отслеживать показатели успеха, оценки удовлетворенности пользователей или другие метрики на живом трафике. Преимущество онлайн-оценки в том, что она фиксирует то, что сложно предсказать в лабораторных условиях — вы можете наблюдать дрейф модели со временем (если эффективность агента ухудшается с изменением паттернов входных данных) и выявлять неожиданные запросы или ситуации, которых не было в тестовых данных. Она дает реальную картину поведения агента в работе.
Онлайн-оценка часто включает сбор неявной и явной обратной связи пользователей, как обсуждалось ранее, и возможно проведение теневых или A/B-тестов (когда новая версия агента работает параллельно со старой для сравнения). Сложность в том, что может быть трудно получать достоверные метки или оценки для живых взаимодействий — приходится полагаться на отзывы пользователей или косвенные метрики (например, клик по результату).
Комбинирование двух подходов
Онлайн и оффлайн оценки не исключают друг друга, они сильно дополняют друг друга. Инсайты из онлайн-мониторинга (например, новые типы запросов пользователей, на которых агент работает плохо) могут использоваться для расширения и улучшения оффлайн тестовых наборов данных. С другой стороны, агенты, хорошо показавшие себя в оффлайн тестах, могут быть с большей уверенностью развернуты и контролироваться онлайн.
Многие команды используют цикл:
оценка оффлайн -> развертывание -> мониторинг онлайн -> сбор новых случаев сбоев -> добавление в оффлайн набор -> доработка агента -> повторение.
Распространённые проблемы
При развертывании AI-агентов в продакшене вы можете столкнуться с разными проблемами. Вот некоторые из них и возможные решения:
| Проблема | Возможное решение |
|---|---|
| AI-агент выполняет задачи непоследовательно | - Уточните подсказку для агента; чётко определите цели. - Определите, можно ли разбить задачи на подзадачи и поручить их нескольким агентам. |
| Агент зацикливается | - Обеспечьте чёткие условия завершения, чтобы агент знал, когда прекратить. - Для сложных задач с рассуждениями используйте более крупную модель, специализированную на логических задачах. |
| Вызовы инструментов AI-агента работают плохо | - Тестируйте и проверяйте выходные данные инструментов вне системы агента. - Улучшайте параметры, подсказки и названия инструментов. |
| Мультиагентная система ведет себя непоследовательно | - Уточните подсказки для каждого агента, чтобы они были специфичными и различались. - Постройте иерархическую систему с агентом-маршрутизатором или контроллером для определения корректного агента. |
Многие из этих проблем можно эффективнее выявлять с помощью наблюдаемости. Обсуждавшиеся ранее трейсы и метрики помогают точно определить, на каком этапе рабочего процесса агента возникают проблемы, что значительно ускоряет отладку и оптимизацию.
Управление затратами
Вот несколько стратегий для управления затратами развертывания AI-агентов в промышленной эксплуатации:
Использование более маленьких моделей: Малые языковые модели (SLM) могут хорошо справляться с определёнными агентными сценариями и значительно снижать затраты. Как упоминалось ранее, создание системы оценки для определения и сравнения производительности по сравнению с большими моделями — лучший способ понять, насколько хорошо SLM подойдёт для вашего сценария. Рассмотрите возможность использования SLM для более простых задач, таких как классификация намерений или извлечение параметров, а для сложного рассуждения оставьте большие модели.
Использование модели маршрутизатора: Похожая стратегия — использовать разнообразие моделей и размеров. Вы можете применять LLM/SLM или бессерверную функцию для маршрутизации запросов на основе их сложности к наиболее подходящим моделям. Это также поможет снизить расходы, при этом обеспечив производительность на правильных задачах. Например, направляйте простые запросы к меньшим и более быстрым моделям, а дорогие большие модели используйте только для сложных задач рассуждения.
Кэширование ответов: Определение часто встречающихся запросов и задач и предоставление ответов до того, как они пройдут через вашу агентную систему, — хороший способ уменьшить количество похожих запросов. Вы даже можете реализовать поток, позволяющий определить степень схожести запроса с кэшированными с помощью более простых ИИ-моделей. Эта стратегия может значительно снизить затраты на часто задаваемые вопросы или общие рабочие процессы.
Давайте посмотрим, как это работает на практике
В примерно ноутбуке этого раздела мы рассмотрим примеры использования инструментов наблюдаемости для мониторинга и оценки нашего агента.
Есть ещё вопросы по AI-агентам в продакшене?
Присоединяйтесь к Microsoft Foundry Discord, чтобы познакомиться с другими обучающимися, посещать часы работы и получить ответы на вопросы по AI-агентам.
Предыдущее занятие
Следующее занятие
Отказ от ответственности: Этот документ был переведен с использованием сервиса машинного перевода Co-op Translator. Несмотря на наши усилия по обеспечению точности, имейте в виду, что автоматический перевод может содержать ошибки или неточности. Оригинальный документ на его исходном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется обратиться к профессиональному человеческому переводу. Мы не несем ответственности за любые недоразумения или неправильные толкования, возникшие в результате использования этого перевода.