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