ai-agents-for-beginners

AI-агенты в производстве: наблюдаемость и оценка

По мере того как AI-агенты переходят от экспериментальных прототипов к реальным приложениям, становится важным умение понимать их поведение, отслеживать их производительность и систематически оценивать их результаты.

Цели обучения

После завершения этого урока вы узнаете/понять:

Основные концепции наблюдаемости и оценки агентов
Техники улучшения производительности, затрат и эффективности агентов
Что и как систематически оценивать у ваших AI-агентов
Как контролировать расходы при развертывании AI-агентов в продакшн
Как инструментировать агентов, созданных с помощью Microsoft Agent Framework

Цель — вооружить вас знаниями, чтобы превратить ваши «черные ящики» агентов в прозрачные, управляемые и надежные системы.

Примечание: Важно развертывать безопасных и надежных AI-агентов. Ознакомьтесь также с уроком Построение надежных AI-агентов.

Трейсы и спэны

Инструменты наблюдаемости, такие как Langfuse или Microsoft Foundry, обычно представляют запуски агентов в виде трейсов и спэнов.

Трейс представляет собой полную задачу агента от начала до конца (например, обработку пользовательского запроса).
Спэны — это отдельные шаги внутри трейса (например, вызов языковой модели или получение данных).

Trace tree in Langfuse

Без наблюдаемости 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"):
    # Выполнение агента отслеживается автоматически
    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-агентов: онлайн-оценка и оффлайн-оценка. Обе важны и дополняют друг друга. Обычно мы начинаем с оффлайн-оценки, так как это минимально необходимый шаг перед развертыванием агента.

Оффлайн-оценка

Dataset items in Langfuse

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

Например, если вы создали агента для решения текстовых математических задач, у вас может быть тестовый набор данных из 100 задач с известными ответами. Оффлайн-оценка часто проводится в процессе разработки (и может быть частью CI/CD), чтобы отслеживать улучшения или предотвращать регрессии. Преимущество в том, что она повторяема и позволяет получать точные метрики точности, поскольку есть эталонные данные. Вы также можете симулировать пользовательские запросы и сравнивать ответы агента с идеальными ответами или использовать автоматические метрики, описанные выше.

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

Онлайн-оценка

Observability metrics overview

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

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

Онлайн-оценка часто включает собирание явной и неявной обратной связи от пользователей, а также возможные параллельные тесты или A/B тесты (когда новая версия агента работает параллельно со старой для сравнения). Сложность в том, что получить надёжные метки или оценки для живых взаимодействий сложно — часто приходится полагаться на отзывы пользователей или косвенные метрики (например, кликнул ли пользователь на результат).

Комбинирование двух подходов

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

Фактически многие команды используют цикл:

оценка оффлайн -> деплой -> мониторинг онлайн -> сбор новых случаев сбоев -> добавление в оффлайн-набор -> доработка агента -> повтор.

Распространённые проблемы

При развертывании AI-агентов в продакшн вы можете столкнуться с разными проблемами. Вот некоторые типичные вопросы и возможные решения:

Проблема	Возможное решение
AI-агент выполняет задачи непоследовательно	- Уточните промты, задайте чёткие цели для агента. - Определите, можно ли разбить задачи на подзадачи и поручить их нескольким агентам.
AI-агент попадает в бесконечные циклы	- Обеспечьте чёткие условия завершения, чтобы агент знал, когда остановить работу. - Для сложных задач с рассуждениями и планированием используйте более крупную модель, специализированную на этих задачах.
Вызовы инструментов AI-агентом работают неэффективно	- Тестируйте и проверяйте работу инструментов вне системы агента. - Уточните параметры, промты и имена инструментов.
Мультиагентная система работает нестабильно	- Уточните промты для каждого агента, чтобы они были специфичны и различны. - Постройте иерархическую систему с «маршрутизирующим» или управляющим агентом, который определяет, какой агент должен работать.

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

Управление затратами

Вот несколько стратегий управления затратами на внедрение AI-агентов в промышленную эксплуатацию:

Использование меньших моделей: Малые языковые модели (SLM) могут хорошо справляться с некоторыми агентными сценариями и значительно снизить затраты. Как упоминалось ранее, лучшим способом понять, насколько хорошо SLM справится с вашим кейсом, является построение системы оценки для определения и сравнения производительности с более крупными моделями. Рассмотрите возможность использования SLM для более простых задач, таких как классификация намерений или извлечение параметров, при этом оставляя большие модели для сложных рассуждений.

Использование маршрутизирующей модели: Похожая стратегия — использовать разнообразные модели и размеры. Вы можете использовать LLM/SLM или бессерверную функцию для маршрутизации запросов по сложности к наиболее подходящим моделям. Это также поможет снизить затраты, обеспечивая при этом производительность на нужных задачах. Например, направляйте простые запросы к меньшим, более быстрым моделям и используйте дорогие большие модели только для сложных задач рассуждения.

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

Давайте посмотрим, как это работает на практике

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

Есть вопросы об AI-агентах в промышленной эксплуатации?

Присоединяйтесь к Microsoft Foundry Discord, чтобы встретиться с другими учащимися, посетить часы приёма и получить ответы на свои вопросы об AI-агентах.

Предыдущий урок

Метакогнитивный паттерн проектирования

Следующий урок

Агентные протоколы

Отказ от ответственности:
Этот документ был переведён с помощью сервиса автоматического перевода Co-op Translator. Несмотря на наши усилия по обеспечению точности, пожалуйста, учтите, что автоматические переводы могут содержать ошибки или неточности. Оригинальный документ на его родном языке следует считать авторитетным источником. Для получения критически важной информации рекомендуется обратиться к профессиональному переводу, выполненному человеком. Мы не несем ответственности за любые недоразумения или неправильные толкования, возникшие в результате использования этого перевода.

This site is open source. Improve this page.