Можливості спостережуваності для корпоративних агентів ІІ за допомогою Langfuse та OCI
Чому журнали, метрики та трекінги не підходять для агентів генеративного ІІ, та як відстежувати запити, виклики інструментів, токени та сеанси за допомогою open-source Langfuse у OCI Agents.
Джерела: Observability for Enterprise AI Agents: an open-source solution
Журнали, метрики та трейси не покажуть вам, чому корпоративний AI-агент дав погану відповідь. Щоб зрозуміти ці системи, вам також потрібно бачити запити, контекст, який надається моделі, виклики інструментів, використання токенів, час відповіді та якість результату. У цій статті пояснюється, чому генеративній AI потрібен інший підхід до можливості спостереження, а потім показана конкретна налаштування з використанням Langfuse, яка підключається до OCI Enterprise AI Agents завдяки сумісності з API OpenAI Responses.
Чому це важливо
Термін „агент“ використовується для будь-якого робочого процесу, який використовує одну або кілька великих мовних моделей для отримання результату. Це стирає справжню різницю. Справжній агент забезпечує автономію, можливість використання інструментів та керування контекстом, а разом з цим — значно більшу операційну складність.
Друга проблема є ще більш актуальною в корпораціях. Увага зосереджується на „чарівності“ ШІ, тоді як робота, необхідна для надійної, контрольованої та якісної роботи цих систем, залишається поза увагою. Оперативність спостереження посідає одне з провідних місць у цьому списку. Для складного агента генеративного ШІ це не технічна дрібниця – це те, що дозволяє розуміти поведінку, аналізувати помилки, оцінювати якість відповідей та контролювати витрати та затримки.
Перша частина нижче визначає поняття оперативності спостереження та його значення для генеративного ШІ. Друга частина розглядає встановлення на основі відкритого коду, яке легко запустити на OCI, з прикладами того, що воно збирає, та чому ці дані є корисними.
Що означає оперативність спостереження
Спостережуваність — це властивість складних систем. Простіше кажучи, система є спостережуваною, якщо можна визначити її внутрішню поведінку на основі сигналів, які вона випромінює, та які можна зібрати та проаналізувати. Формальніше кажучи, два різні внутрішні стани мають бути розрізнені за допомогою зовнішніх сигналів. Те, що випромінює система, має надійно відображати те, що відбувається всередині неї.
З цього випливають два наслідки. Спостережуваність має найвище значення там, де є багато компонентів, залежностей та взаємодій. Крім того, достатньо лише спостерігати ззовні, оскільки систему потрібно спроєктувати та оснастити засобами для отримання корисної інформації. Правильна робота чогось на кшталт корпоративного AI-агента означає збір телеметричних даних, які розкривають його стан, поведінку, аномалії та продуктивність.
Саме тут спостережуваність відрізняється від класичного моніторингу. Моніторинг відповідає на запитання, які ви передбачили заздалегідь, наприклад, скільки CPU використовує певний сервіс чи наскільки повільним був запит. Спостережуваність також має дозволяти вам досліджувати несподіванки, проблеми та запитання, яких ніхто не передбачив на етапі проектування, що часто називається «невідомими невідомими».
Спостережуваність до появи генеративного ШІ
«Традиційні системи» тут означають додатки, створені до того, як генеративний ШІ став популярним, приблизно до 2023 року. Їхня спостережуваність ґрунтувалася на трьох типах даних: журналах, метриках та слідах.
Журнали та метрики є знайомими поняттями. Трейс — це повний запис однієї запиту чи взаємодії, який складається з елементів, що описують окремі кроки. У архітектурі мікросервісів один трейс може охоплювати всю транзакцію додатку, містячи елементи для виклику API, запиту до бази даних чи виклику зовнішнього сервісу. Щоб цей підхід був ефективним, він має відстежувати запит у кожному компоненті, з яким він взаємодіє.
Для агентів GenAI ця класична модель сама по собі недостатня. Окрім журналів, метрик та трейсів, необхідно також спостерігати за тим, що робить модель, який контекст вона отримує, які інструменти вона використовує та наскільки якісними є її відповіді.
Що змінюється з появою GenAI
Традиційне програмне забезпечення є досить прогнозованим. Системи, побудовані на генеративному ШІ, менш прогнозовані, особливо коли вони мають певну свободу у прийнятті рішень. Результат роботи ШІ залежить від набагато більшої кількості факторів, ніж вхідні дані користувача, і всі ці фактори мають бути видимими.
Система для спостереження за роботою системи на основі ШІ має фіксувати принаймні чотири аспекти:
- модель та параметри виклику
- інструкції та фактичний запит, надісланий користувачем
- контекст, наданий системі, включаючи попередню історію розмови
- спосіб виконання завдання системою: виклики інструментів, проміжні результати, час відгуку та кількість використаних токенів
Достатньо лише дивитися на кінцеву відповідь — цього недостатньо. Щоб зрозуміти систему генеративного ШІ, потрібно мати можливість відтворити для кожної сліду всі фактори, які сприяли формуванню відповіді.
Це ще більш актуально, коли у моделі є свобода дій. Якщо вона може вибирати, які інструменти використати, порядок дій, які джерела звернутися чи коли зупинитися, тоді простих запитів та результатів недостатньо. Потрібно бачити сам процес прийняття рішень, включаючи послідовність викликів інструментів, час виконання та проміжні результати.
Навіть повний запис дій часто не може відповісти на питання, чи є результат корисним. Для цього до кожного запису зазвичай додаються оцінки. Вони можуть походити з традиційної логіки або від іншої ШІ, відомої зараз як техніка „ШІ як суддя“.
Розгляньте можливість оцінки відповіді RAG. Вона може бути частково правильною або здаватися правдоподібною без підтримки знайдених джерел. Тоді потрібно розрізнити принаймні два аспекти: первинну причину, таку як пошук, переранжування чи генерація, та обґрунтованість, тобто чи справді відповідь ґрунтується на знайдених документах. Перевірка обґрунтованості виявляє непідтверджені твердження та, отже, можливі галюцинації.
Усе це означає, що звичайна платформа для моніторингу не підійде для GenAI. Вам потрібен інструмент, який би нативно фіксував цю інформацію та зменшував зусилля з її збору. Справжня різниця полягає у обсязі. Для GenAI ви продовжуєте стежити за інфраструктурою та швидкістю, як і раніше, а також за контекстом, який бачив модель, прийнятими нею рішеннями, якістю отриманого результату та стабільністю її роботи.
Langfuse
Серед інструментів відкритого коду для спостережуваності LLM та агентів Langfuse вирізняється. Це платформа для відстеження, спостережуваності та оцінки (надання балів) додатків, заснованих на LLM, яка охоплює більшість вищезгаданих даних: запити, результати, записи діяльності, метадані, час відповіді, використання токенів, виклики інструментів та оцінкові бали. Це більше, ніж просто сервіс для журналізації даних. Він надає структурований погляд на те, як насправді поводиться додаток GenAI, організований навколо записів діяльності та сеансів, а не навколо простого потоку рядків тексту, які доводиться переглядати вручну.
Чому OCI полегшує інтеграцію
OCI Enterprise AI Agents надає API, який є повністю сумісним з API OpenAI Responses. Це має велике значення не лише з точки зору зручності, адже це дозволяє використовувати знову інструменти, бібліотеки та патерни розробки широкої екосистеми, сумісної з OpenAI. Для Langfuse це значно скорочує час, необхідний для збору телеметричних даних від викликів моделей та створення шару спостережливості, тож більше часу залишається на аналіз, а не на технічну налагодку. Саме тому OCI та Langfuse чудово поєднуються в корпоративному середовищі.
Швидке впровадження на основі концепції
Для демонстраційної версії Langfuse легко встановлюється на OCI, наприклад, на віртуальній машині Linux, за допомогою офіційного скрипту Docker Compose з репозиторію Langfuse. Це не обов’язково є кінцевою архітектурою для продакшн-середовища корпоративного рівня. Цього цілком достатньо для перевірки ідеї, збору реальних даних та визначення можливостей аналізу після інтеграції. На практиці це дозволило швидко створити функціональну платформу, до якої можна отримати доступ через браузер та яка готова приймати дані від додатків на основі Python LLM.
Підключення коду
Коли інстанція Langfuse працює, наступним кроком є налаштування додатку так, щоб телеметрія викликів моделі надходила автоматично. Завдяки сумісності з API Responses це просто для Python-додатків, вже написаних з використанням викликів у стилі OpenAI. Додаток продовжує викликати модель так, як завжди, а Langfuse записує важливі деталі.
Зміни є незначними:
- Встановіть кілька змінних середовища.
- Використовуйте клієнта, наданого бібліотекою Langfuse, який вже налаштований для збору та надсилання даних телеметрії.
- Передавайте
conversation_idзамістьsession_id, щоб запити в межах однієї розмови були поєднані в одну сесію. - За бажанням можна примусово надіслати дані телеметрії відразу. Інакше вони надсилаються автоматично через кілька секунд.
Що збирається
Після інтеграції Langfuse автоматично збирає багато корисної інформації. Для агентів це включає не лише вхідні та вихідні дані моделі, а й процес її виконання — проміжні етапи, виклики інструментів та часові показники, які допомагають відтворити процес отримання результату.
Найважливіші елементи є наступними:
- модель та її версія
- надісланий запит
- створений результат
- метадані, приєднані до виклику
- структура треку та всі його етапи
- показники затримки, включаючи ті, що видно користувачеві, як-от час до першого токена
- кількість токенів у вхідних та вихідних даних, яка використовується для аналізу витрат
- виклики інструментів та їхні деталі
- бали та оцінки, пов’язані з треком
Не все корисне надходить автоматично, і це є частиною дизайну, адже платформа не може знати, що ваш бізнес вважає хорошою відповіддю. Оцінки, специфічні для домену, індикатори та метадані бізнесу можуть, а іноді навіть повинні, додаватися за допомогою додатку. Саме поєднання автоматичного збору даних та свідомого їх поповнення робить інструмент ефективним.
Сеанси
Langfuse може поєднувати кілька записів з одного сеансу користувача за допомогою session_id. У цій конфігурації розмова ідентифікується за допомогою стандартного conversation_id API Responses, тож встановлення session_id у рівність йому зв’язує всі запити з однієї розмови. Потім сеанси можна переглядати в інтерфейсі користувача, де кожен з них містить кілька записів.
Перегляд запису
Результати аналізу стають видимими під час його виконання. Інтерфейс Langfuse дозволяє детально досліджувати кожну взаємодію, виявляючи інформацію, яка інакше була б розкидана серед журналів додатку, вільних метаданих та коду. Для окремого запису можна побачити саме те запитання, яке було надіслано, модель, її параметри, час виконання, кількість використаних токенів, послідовність усіх викликів та результати на кожному етапі. Це особливо важливо під час дослідження дивної поведінки, проблем з затримками, зростання витрат чи відповідей незадовільної якості. Наприклад, повільна відповідь може бути наслідком довгої послідовності викликів інструментів, занадто довгого запитання чи повільного отримання першого токена, і кожна з цих проблем потребує окремого рішення. Без одночасного показу часу виконання на рівні кожного етапу та кількості токенів доводилося б здогадуватися, у чому саме проблема.
Практичною звичкою, яка виникає внаслідок цього, є сприйняття кожної розмови як чогось, що можна переглянути пізніше. Коли користувач повідомляє про погану відповідь через тиждень, можливість перегляду сеансу дозволяє відкрити точні записи, прочитати справжні запит та контекст та побачити, який інструмент надав що, замість того, щоб намагатися відтворити ситуацію з пам’яті.
Обмеження, про які варто пам’ятати
Впровадження Langfuse не вирішує всіх проблем зі спостережуваністю та оцінкою в системах GenAI. Записи з детальним контекстом є необхідними, але не завжди достатніми. Найкорисніші показники зазвичай залежать від сфери застосування та мають бути розроблені навмисно. Крім того, справжнє корпоративне середовище вимагає ретельного розгляду питань безпеки, конфіденційних даних, зберігання телеметричних даних, контролю доступу та архітектури розгортання.
Незважаючи на це, платформа з відкритим кодом у поєднанні з повною сумісністю API OCI створює міцну основу для реалізації конкретного рішення з можливостями моніторингу для корпоративних агентів.
Коротко кажучи
Для корпоративних AI-агентів можливості моніторингу — це не технічна деталь чи додатковий елемент. Це передумова для розуміння їхньої поведінки, аналізу помилок, оцінки якості відповідей, а також зниження часу відповіді та витрат на їх роботу. Спостереження за інфраструктурою, журналами додатків та стандартними показниками недостатньо. Також потрібні дані, які безпосередньо стосуються діяльності агента: запити, контекст, виклики інструментів, споживання токенів, сприйняття затримок користувачем та оцінки якості.
Langfuse є особливо цікавим варіантом з відкритим кодом, оскільки він фіксує та організовує значну частину цих телеметричних даних, а API, сумісне з OpenAI, у OCI Enterprise AI Agents полегшує інтеграцію. Проте жодна платформа не може сама вирішити все — безпека, управління, обробка конфіденційних даних та розробка показників, специфічних для певної галузі, залишаються надзвичайно важливими.
Якщо ці агенти мають вийти за межі демонстрацій та стати надійними складовими реальних систем, питання спостережуваності не може залишатися другорядним. Їхню складність неможливо усунути, але її можна та потрібно зробити видимою.
Природним наступним кроком є збагачення слідів діяльності показниками, які більш систематично оцінюють якість, зокрема показниками, створеними ШІ як суддею, щоб кожен слід містив оцінки якості відповіді разом із технічними даними її виконання.
Пов’язана література
- Як зберігання даних у браузері тихо пошкоджує дані користувача та як цього уникнути — Втрачені оновлення, застарілі знімки, зміни схеми та витоки даних на спільних пристроях можуть пошкодити дані localStorage без жодних помилок. Шаблони для визначення власності, версіонування та перевірки.
- Практичні нотатки: RAG Systems: Повний посібник від початку до кінця (видання 2026 року) — Детальний посібник з використання Practical notes: RAG Systems: Повний посібник від початку до кінця (видання 2026 року): контракти, перевірки та готові фрагменти коду для команд, які впроваджують цю модель.