ai-agents-for-beginners
AI Агенти в продакшені: Спостережуваність і оцінка
У міру того як AI агенти переходять від експериментальних прототипів до застосувань у реальному світі, здатність розуміти їхню поведінку, моніторити продуктивність та систематично оцінювати їхні виходи стає важливою.
Цілі навчання
Після проходження цього уроку ви знатимете/зрозумієте:
- Основні поняття спостережуваності та оцінки агентів
- Техніки покращення продуктивності, витрат і ефективності агентів
- Що і як систематично оцінювати у ваших AI агентах
- Як контролювати витрати при розгортанні AI агентів у продакшені
- Як інструментувати агентів, побудованих з Microsoft Agent Framework
Мета — надати вам знання, щоб перетворити ваших “чорних ящиків” агентів на прозорі, керовані та надійні системи.
Примітка: Важливо розгортати AI Агенти, які є безпечними та заслужують довіри. Перегляньте також урок Building Trustworthy AI Agents.
Трейси та спани
Інструменти спостережуваності, такі як Langfuse або Microsoft 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 в інструмент спостережуваності. 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 процесів) для перевірки покращень або запобігання регресії. Перевага в тому, що вона повторювана і дає чіткі метрики точності, бо у вас є істина на землі (ground truth). Ви можете також імітувати запити користувачів і порівнювати відповіді агента з ідеальними або застосовувати автоматичні метрики, описані вище.
Головне завдання офлайн оцінки — гарантувати, що тестовий датасет всебічний і залишається актуальним — агент може добре працювати на фіксованому тесті, але зіштовхнутися з дуже різними запитами в продакшені. Тому варто оновлювати тестові набори новими крайніми випадками та прикладами, які відображають реальні сценарії. Корисно мати суміш із невеликих “smoke test” кейсів і більших тестових вибірок: маленькі — для швидких перевірок, великі — для ширших метрик продуктивності.
Онлайн оцінка
Вона означає оцінку агента в живому, реальному середовищі, тобто під час фактичного використання у продакшені. Онлайн оцінка вимагає моніторингу продуктивності агента на реальних взаємодіях користувачів і безперервного аналізу результатів.
Наприклад, ви можете відстежувати рівень успішності, оцінки задоволеності користувачів або інші метрики на живому трафіку. Перевага онлайн оцінки в тому, що вона ловить речі, які ви могли не передбачити в лабораторних умовах — можна спостерігати дрейф моделі з часом (якщо ефективність агента погіршується через зміну патернів вхідних даних) і виявляти несподівані запити чи ситуації, яких не було у ваших тестових даних. Це дає реальну картину поведінки агента в реальному світі.
Онлайн оцінка часто включає збір неявного і явного відгуку користувачів, про що вже йшлося, а також може проводитися тіньове тестування або A/B тести (коли нова версія агента паралельно запускається для порівняння зі старою). Виклик в тому, що іноді складно отримати надійні мітки або оцінки для живих взаємодій — можливо, доводиться покладатися на відгуки користувачів або опосередковані метрики (наприклад, чи клікнув користувач по результату).
Поєднання двох методів
Онлайн і офлайн оцінка не виключають одна одну; вони дуже доповнюють. Інсайти з онлайн-моніторингу (наприклад, нові типи користувацьких запитів, де агент працює погано) можуть використовуватись для розширення і покращення офлайн тестових датасетів. Навпаки, агенти, які добре працюють в офлайн тестах, можна з більшою впевненістю розгортати і моніторити онлайн.
Багато команд фактично впроваджують цикл:
оціночна офлайн -> розгортання -> онлайн моніторинг -> збір нових кейсів провалів -> додавання до офлайн датасету -> вдосконалення агента -> повторення.
Поширені проблеми
При розгортанні AI агентів у продакшені ви можете зіткнутися з різними викликами. Ось деякі поширені проблеми і потенційні рішення:
| Проблема | Потенційне рішення |
|---|---|
| AI агент не виконує завдання послідовно | - Уточніть промпт для AI агента; будьте чіткими в цілях. - Визначте, де розбивка задач на підзадачі і їх обробка кількома агентами може допомогти. |
| AI агент потрапляє у нескінченні цикли | - Переконайтеся, що є чіткі умови завершення, щоб агент знав, коли зупинити процес. - Для складних завдань, що потребують міркувань і планування, використовуйте більшу модель, спеціалізовану на завданнях міркувань. |
| Виклики інструментів AI агента працюють погано | - Тестуйте і валідируйте вихід інструментів поза системою агента. - Уточнюйте параметри, промпти та іменування інструментів. |
| Система з кількох агентів працює непослідовно | - Уточнюйте промпти для кожного агента, щоб вони були специфічними і відмінними один від одного. - Побудуйте ієрархічну систему з “маршрутизуючим” або контролюючим агентом для визначення правильного агента. |
Більшість цих проблем можна ефективніше виявити завдяки наявній спостережуваності. Трейси та метрики, про які ми згадували раніше, допомагають точно визначити, де в робочому процесі агента виникають проблеми, роблячи відлагодження і оптимізацію набагато ефективнішими.
Управління витратами
Ось деякі стратегії управління витратами при розгортанні AI агентів у продакшені:
Використання менших моделей: Невеликі мовні моделі (SLM) можуть добре працювати в певних агенських сценаріях і значно знизять витрати. Як було зазначено раніше, створення системи оцінки для визначення та порівняння продуктивності з більшими моделями – найкращий спосіб зрозуміти, наскільки добре SLM спрацює для вашого випадку використання. Розгляньте можливість використання SLM для простіших завдань, таких як класифікація намірів або вилучення параметрів, залишаючи більші моделі для складних завдань мислення.
Використання маршрутизатора моделей: Схожа стратегія – використовувати різноманітність моделей і розмірів. Ви можете використовувати LLM/SLM або безсерверну функцію для маршрутизації запитів на основі складності до моделей, які найкраще відповідають. Це також допоможе знизити витрати, одночасно забезпечуючи продуктивність для відповідних завдань. Наприклад, направляйте прості запити до менших, швидших моделей, а дорогі великі моделі використовуйте лише для складних завдань мислення.
Кешування відповідей: Виявлення поширених запитів і завдань і надання відповідей на них до того, як вони пройдуть через вашу агенську систему, є хорошим способом зменшити обсяг подібних запитів. Ви навіть можете реалізувати потік для визначення того, наскільки запит схожий на кешовані вами, використовуючи більш прості моделі ШІ. Ця стратегія може суттєво зменшити витрати на часто задавані питання або типові робочі процеси.
Давайте подивимося, як це працює на практиці
У прикладі ноутбука цього розділу ми побачимо приклади того, як ми можемо використовувати інструменти спостереження для моніторингу та оцінки нашого агента.
Є ще питання про AI-агентів у виробництві?
Приєднуйтесь до Discord Microsoft Foundry, щоб зустрітися з іншими учнями, відвідати години консультацій та отримати відповіді на свої питання про AI-агентів.
Попередній урок
Наступний урок
Відмова від відповідальності: Цей документ було перекладено за допомогою сервісу штучного інтелекту для перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ рідною мовою слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникли внаслідок використання цього перекладу.