ai-agents-for-beginners

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

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

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

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

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

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

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

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

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

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

Без наблюдаемости AI-агент может казаться “черным ящиком” — его внутреннее состояние и логика остаются непрозрачными, что затрудняет диагностику проблем или оптимизацию производительности. С наблюдаемостью агенты становятся “стеклянными ящиками”, обеспечивая прозрачность, которая необходима для создания доверия и гарантии их правильной работы.

Почему наблюдаемость важна в производственных средах

Переход AI-агентов в производственные среды вводит новые вызовы и требования. Наблюдаемость становится не просто “приятным дополнением”, а критически важной способностью:

• Отладка и анализ причин ошибок: Когда агент терпит неудачу или выдает неожиданный результат, инструменты наблюдаемости предоставляют трейсы, необходимые для выявления источника ошибки. Это особенно важно для сложных агентов, которые могут включать множество вызовов LLM, взаимодействий с инструментами и условной логики.
• Управление задержками и затратами: AI-агенты часто полагаются на LLM и другие внешние API, которые оплачиваются за токен или вызов. Наблюдаемость позволяет точно отслеживать эти вызовы, помогая выявить операции, которые слишком медленные или дорогие. Это позволяет командам оптимизировать запросы, выбирать более эффективные модели или переработать рабочие процессы для управления операционными затратами и обеспечения хорошего пользовательского опыта.
• Доверие, безопасность и соответствие требованиям: Во многих приложениях важно гарантировать, что агенты ведут себя безопасно и этично. Наблюдаемость предоставляет журнал действий и решений агента. Это можно использовать для выявления и устранения таких проблем, как инъекция запросов, генерация вредоносного контента или неправильное обращение с персональными данными (PII). Например, вы можете просмотреть трейсы, чтобы понять, почему агент дал определенный ответ или использовал конкретный инструмент.
• Циклы непрерывного улучшения: Данные наблюдаемости являются основой итеративного процесса разработки. Отслеживая, как агенты работают в реальном мире, команды могут выявлять области для улучшения, собирать данные для тонкой настройки моделей и проверять влияние изменений. Это создает цикл обратной связи, где производственные инсайты из онлайн-оценки информируют оффлайн-эксперименты и доработки, приводя к постепенному улучшению производительности агентов.

Основные метрики для отслеживания

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

Вот некоторые из наиболее распространенных метрик, которые отслеживают инструменты наблюдаемости:

Задержка: Как быстро агент отвечает? Долгое ожидание негативно влияет на пользовательский опыт. Вы должны измерять задержку для задач и отдельных шагов, отслеживая выполнение агентом. Например, агент, который тратит 20 секунд на все вызовы модели, может быть ускорен с помощью более быстрой модели или параллельного выполнения вызовов модели.

Затраты: Какова стоимость выполнения задачи агентом? AI-агенты полагаются на вызовы LLM, оплачиваемые за токен, или внешние API. Частое использование инструментов или множество запросов могут быстро увеличить затраты. Например, если агент вызывает LLM пять раз для незначительного улучшения качества, вы должны оценить, оправданы ли затраты, или можно сократить количество вызовов или использовать более дешевую модель. Мониторинг в реальном времени также помогает выявлять неожиданные всплески (например, ошибки, вызывающие чрезмерные циклы API).

Ошибки запросов: Сколько запросов агент не смог выполнить? Это может включать ошибки API или неудачные вызовы инструментов. Чтобы сделать вашего агента более устойчивым к этим проблемам в производстве, вы можете настроить резервные варианты или повторные попытки. Например, если провайдер LLM A недоступен, вы переключаетесь на резервный провайдер LLM B.

Обратная связь от пользователей: Реализация прямой оценки пользователями предоставляет ценные инсайты. Это может включать явные оценки (👍положительно/👎отрицательно, ⭐1-5 звезд) или текстовые комментарии. Постоянная негативная обратная связь должна вас насторожить, так как это признак того, что агент работает не так, как ожидалось.

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

Точность: Как часто агент выдает правильные или желаемые результаты? Определения точности могут варьироваться (например, правильность решения задач, точность извлечения информации, удовлетворенность пользователей). Первый шаг — определить, что означает успех для вашего агента. Вы можете отслеживать точность с помощью автоматических проверок, оценочных баллов или меток завершения задач. Например, маркировка трейсов как “успешных” или “неудачных”.

Автоматические метрики оценки: Вы также можете настроить автоматическую оценку. Например, вы можете использовать LLM для оценки результата агента, например, насколько он полезен, точен или нет. Существуют также несколько библиотек с открытым исходным кодом, которые помогают оценивать различные аспекты агента. Например, RAGAS для агентов RAG или LLM Guard для обнаружения вредоносного языка или инъекции запросов.

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

Инструментирование вашего агента

Чтобы собирать данные о трейсах, вам нужно инструментировать ваш код. Цель — настроить код агента так, чтобы он генерировал трейсы и метрики, которые могут быть захвачены, обработаны и визуализированы платформой наблюдаемости.

OpenTelemetry (OTel): OpenTelemetry стал отраслевым стандартом для наблюдаемости LLM. Он предоставляет набор API, SDK и инструментов для генерации, сбора и экспорта телеметрических данных.

Существует множество библиотек инструментирования, которые оборачивают существующие фреймворки агентов и упрощают экспорт спанов OpenTelemetry в инструмент наблюдаемости. Ниже приведен пример инструментирования агента AutoGen с помощью библиотеки инструментирования OpenLit:

import openlit

openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)

Пример ноутбука в этой главе продемонстрирует, как инструментировать вашего агента AutoGen.

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

Основная проблема оффлайн-оценки — обеспечение того, чтобы ваш тестовый набор данных был всеобъемлющим и оставался актуальным — агент может хорошо работать на фиксированном тестовом наборе, но сталкиваться с совершенно другими запросами в производстве. Поэтому вы должны регулярно обновлять тестовые наборы новыми крайними случаями и примерами, отражающими реальные сценарии​. Полезно иметь смесь небольших “smoke test” наборов и больших наборов для оценки: небольшие наборы для быстрых проверок и большие для более широких метрик производительности​.

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

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

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

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

Сочетание двух подходов

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

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

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

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

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

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

• Для сложных задач, требующих рассуждений и планирования, используйте более крупные модели, специализированные для таких задач.
  | Вызовы инструментов AI Agent работают плохо | - Тестируйте и проверяйте результаты работы инструмента вне системы агента.
  - Уточняйте параметры, подсказки и названия инструментов. |
  | Система с несколькими агентами работает нестабильно | - Уточняйте подсказки для каждого агента, чтобы они были конкретными и отличались друг от друга.
  - Постройте иерархическую систему с использованием “маршрутизирующего” или управляющего агента, который определяет, какой агент является подходящим. |

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

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

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

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

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

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

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

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

Остались вопросы о AI-агентах в продакшн?

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

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

Шаблон проектирования метакогниции

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

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

---

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

This site is open source. Improve this page.