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