ai-agents-for-beginners
AI-агенты в производстве: наблюдаемость и оценка
По мере того как AI-агенты переходят от экспериментальных прототипов к реальным приложениям, становится важным понимать их поведение, контролировать их работу и систематически оценивать их результаты.
Цели обучения
После завершения этого урока вы будете знать/понимать:
- Основные концепции наблюдаемости и оценки агентов
- Методы улучшения производительности, затрат и эффективности агентов
- Что и как систематически оценивать у ваших AI-агентов
- Как контролировать затраты при развертывании AI-агентов в производстве
- Как инструментировать агентов, созданных с помощью Microsoft Agent Framework
Цель — дать вам знания, чтобы превратить ваши “черные ящики” агентов в прозрачные, управляемые и надежные системы.
Примечание: Важно развертывать AI-агентов, которые безопасны и заслуживают доверия. Также ознакомьтесь с уроком Построение надежных AI-агентов.
Трейсы и спаны
Инструменты наблюдаемости, такие как Langfuse или Microsoft Foundry, обычно представляют запуски агентов в виде трейсов и спанов.
- Трейс отражает полное выполнение задачи агента от начала до конца (например, обработку пользовательского запроса).
- Спаны — это отдельные шаги внутри трейса (например, вызов языковой модели или получение данных).
Без наблюдаемости AI-агент может казаться “черным ящиком” — его внутреннее состояние и рассуждения непрозрачны, что затрудняет диагностирование проблем или оптимизацию производительности. С наблюдаемостью агенты превращаются в “стеклянные ящики”, обеспечивающие прозрачность, которая важна для построения доверия и гарантии правильной работы.
Почему наблюдаемость важна в производственных средах
Переход AI-агентов в производственные среды приносит новые вызовы и требования. Наблюдаемость уже не “приятное дополнение”, а критически важная функция:
- Отладка и анализ причин сбоев: Когда агент выходит из строя или выдает неожиданный результат, инструменты наблюдаемости предоставляют трейсы, позволяющие точно определить источник ошибки. Это особенно важно для сложных агентов с множественными вызовами LLM, взаимодействиями с инструментами и условной логикой.
- Управление задержками и затратами: AI-агенты часто используют LLM и внешние API, которые тарифицируются за токен или вызов. Наблюдаемость позволяет точно отслеживать эти вызовы, помогая выявлять операции, которые слишком медленные или дорогие. Это позволяет оптимизировать запросы, выбирать более эффективные модели или перестраивать рабочие процессы для управления затратами и обеспечения хорошего пользовательского опыта.
- Доверие, безопасность и соответствие требованиям: Во многих приложениях важно, чтобы агенты действовали безопасно и этично. Наблюдаемость обеспечивает аудиторский след действий и решений агента. Это можно использовать для обнаружения и смягчения таких проблем, как внедрение вредоносных запросов (prompt injection), генерация опасного контента или неправильное обращение с персональными данными (PII). Например, можно просмотреть трейсы, чтобы понять, почему агент дал определенный ответ или использовал конкретный инструмент.
- Циклы постоянного совершенствования: Данные наблюдаемости служат основой итеративного процесса разработки. Наблюдая за производительностью агентов в реальном мире, команды могут выявлять области для улучшения, собирать данные для тонкой настройки моделей и проверять влияние изменений. Это создает обратную связь, где производственные данные из онлайн-оценки направляют оффлайн-эксперименты и доработку, что ведет к постепенному улучшению работы агента.
Ключевые метрики для отслеживания
Для мониторинга и понимания поведения агента следует отслеживать ряд метрик и сигналов. Конкретные метрики могут отличаться в зависимости от назначения агента, но некоторые из них универсально важны.
Вот некоторые из наиболее распространенных метрик, которые отслеживают инструменты наблюдаемости:
Задержка: Как быстро агент отвечает? Длительное ожидание негативно влияет на пользовательский опыт. Следует измерять задержку для задач и отдельных шагов, отслеживая запуски агентов. Например, агент, который тратит 20 секунд на все вызовы моделей, можно ускорить, используя более быструю модель или выполняя вызовы параллельно.
Затраты: Какова стоимость одного запуска агента? AI-агенты опираются на вызовы LLM, которые тарифицируются за токен, или внешние API. Частое использование инструментов или многократные запросы могут быстро увеличить затраты. Например, если агент вызывает LLM пять раз ради небольшого улучшения качества, нужно оценить, оправданы ли такие расходы, или стоит сократить количество вызовов или использовать более дешевую модель. Мониторинг в реальном времени также помогает выявлять неожиданные всплески (например, баги, вызывающие избыточные циклы API).
Ошибки запросов: Сколько запросов не удалось выполнить? Это может включать ошибки API или неудачные вызовы инструментов. Чтобы сделать агента более устойчивым в производстве, можно настроить резервные варианты или повторные попытки. Например, если провайдер LLM А недоступен, переключиться на провайдера 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"):
# Выполнение агента отслеживается автоматически
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-агенты часто недетерминированы и могут эволюционировать (через обновления или изменение поведения модели) — без оценки вы не узнаете, делает ли ваш «умный агент» свою работу хорошо или произошел регресс.
Существует две категории оценки AI-агентов: онлайн-оценка и оффлайн-оценка. Обе важны и дополняют друг друга. Обычно начинают с оффлайн-оценки, так как это минимально необходимый шаг перед развертыванием любого агента.
Оффлайн-оценка
Включает оценку агента в контролируемой среде, обычно с использованием тестовых наборов данных, а не живых пользовательских запросов. Вы используете кураторские наборы данных, где известен ожидаемый результат или правильное поведение, а затем запускаете агента на них.
Например, если вы создали агента для решения текстовых математических задач, у вас может быть тестовый набор данных из 100 задач с известными ответами. Оффлайн-оценка часто проводится во время разработки (может быть частью CI/CD) для проверки улучшений или защиты от регрессий. Преимущество в том, что она повторяема, и вы получаете четкие метрики точности, поскольку у вас есть эталон. Также можно симулировать пользовательские запросы и сравнивать ответы агента с идеальными или использовать автоматические метрики, описанные выше.
Главное сложность оффлайн-оценки — обеспечение полноты и актуальности тестового набора — агент может хорошо работать на фиксированном наборе, но столкнуться с совершенно иными запросами в производстве. Поэтому тестовые наборы следует регулярно обновлять новыми крайними случаями и примерами, отражающими реальные сценарии. Полезна комбинация небольших «дымовых тестов» и больших наборов для более масштабных метрик: маленькие для быстрых проверок, большие — для более широкой оценки.
Онлайн-оценка
Оценка агента в живой, реальной среде, т.е. во время фактического использования в производстве. Онлайн-оценка включает мониторинг работы агента на реальных взаимодействиях с пользователями и непрерывный анализ результатов.
Например, вы можете отслеживать коэффициенты успеха, оценки удовлетворенности пользователей или другие метрики на реальном трафике. Преимущество онлайн-оценки в том, что она фиксирует явления, которые нельзя предсказать в лаборатории — вы можете наблюдать дрейф модели со временем (если эффективность агента снижается из-за смены паттернов вводимых данных) и обнаруживать неожиданные запросы или ситуации, отсутствовавшие в тестах. Это дает реальное понимание поведения агента в боевых условиях.
Онлайн-оценка часто включает сбор явной и неявной обратной связи от пользователей, а также проведение теневых тестов или A/B тестов (когда новая версия агента работает параллельно со старой для сравнения). Сложность в том, что сложно получить надежные метки или оценки для живых взаимодействий — часто приходится полагаться на отзывы пользователей или последующие метрики (например, кликнул ли пользователь на результат).
Комбинирование двух подходов
Онлайн- и оффлайн-оценка не исключают друг друга; они сильно дополняют. Выводы из онлайн-мониторинга (например, новые типы пользовательских запросов с плохой работой агента) можно использовать для дополнения и улучшения оффлайн-тестов. И наоборот, агенты, хорошо показавшие себя в оффлайн-тестах, более уверенно развертываются и контролируются в онлайн.
Многие команды фактически следуют циклу:
оценка оффлайн -> развертывание -> мониторинг онлайн -> сбор новых ошибок -> добавление в оффлайн-набор -> улучшение агента -> повторение.
Распространённые проблемы
При развертывании AI-агентов в производство могут возникать различные проблемы. Вот некоторые распространённые вопросы и возможные решения:
| Проблема | Возможное решение |
|---|---|
| AI-агент работает непоследовательно | - Уточните подсказку (prompt), данную AI-агенту; чётко сформулируйте задачи. - Определите, где может помочь разбиение задач на подзадачи с обработкой их несколькими агентами. |
| AI-агент зацикливается | - Обеспечьте чёткие условия завершения, чтобы агент понимал, когда нужно остановиться. - Для сложных задач, требующих рассуждений и планирования, используйте более крупную модель, специализированную на таких задачах. |
| Вызовы инструментов AI-агентом работают плохо | - Протестируйте и проверьте результат работы инструмента вне системы агента. - Уточните параметры, подсказки и наименование инструментов. |
| Мультиагентная система работает нестабильно | - Уточните подсказки для каждого агента, чтобы они были конкретными и различались между собой. - Постройте иерархическую систему с “маршрутизирующим” или управляющим агентом, который выбирает правильного агента. |
Многие из этих проблем можно эффективнее выявлять с помощью наблюдаемости. Трейсы и метрики, обсуждавшиеся выше, помогают точно определить, где в рабочем процессе агента возникают проблемы, делая отладку и оптимизацию намного эффективнее.
Управление затратами
Вот несколько стратегий управления затратами на развертывание ИИ-агентов в производстве:
Использование меньших моделей: Малые языковые модели (SLM) могут хорошо справляться с определёнными агентскими задачами и значительно снижать расходы. Как упоминалось ранее, построение системы оценки для определения и сравнения производительности с более крупными моделями — лучший способ понять, насколько хорошо SLM подойдёт для вашего варианта использования. Рассмотрите возможность использования SLM для более простых задач, таких как классификация намерений или извлечение параметров, оставляя более крупные модели для сложных рассуждений.
Использование модели маршрутизатора: Аналогичная стратегия — использовать разнообразие моделей и их размеров. Вы можете использовать LLM/SLM или безсерверную функцию для маршрутизации запросов по сложности к наиболее подходящим моделям. Это также поможет сократить затраты, одновременно обеспечивая производительность в нужных задачах. Например, перенаправляйте простые запросы к меньшим, более быстрым моделям и используйте дорогие крупные модели только для сложных задач рассуждения.
Кэширование ответов: Выявление часто встречающихся запросов и задач и предоставление ответов до того, как они поступят через вашу агентскую систему, является хорошим способом уменьшить объём похожих запросов. Вы даже можете реализовать процесс для определения степени похожести запроса на кэшированные с использованием более базовых ИИ-моделей. Эта стратегия может значительно снизить расходы на часто задаваемые вопросы или распространённые рабочие процессы.
Давайте посмотрим, как это работает на практике
В примерном блокноте этого раздела мы увидим примеры использования инструментов наблюдаемости для мониторинга и оценки нашего агента.
Есть ещё вопросы о ИИ агентах в производстве?
Присоединяйтесь к Microsoft Foundry Discord, чтобы встретиться с другими учащимися, посетить часы приёма и получить ответы на ваши вопросы об ИИ агентах.
Предыдущий урок
Следующий урок
Отказ от ответственности: Этот документ был переведен с использованием сервиса машинного перевода Co-op Translator. Несмотря на наши усилия по обеспечению точности, имейте в виду, что автоматический перевод может содержать ошибки или неточности. Оригинальный документ на его исходном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется обратиться к профессиональному человеческому переводу. Мы не несем ответственности за любые недоразумения или неправильные толкования, возникшие в результате использования этого перевода.