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