AI-спостережуваність: чому відповіді моделі деградують у продакшені
Відмова, якої не видно на дашбордах, — найдорожча.
Сервіс відповідає, час відгуку в нормі, частка помилок нульова, а якість відповідей тихо знижується: модель частіше пропускає умови з інструкції, у відповідях з'явилися факти без джерела, на частині запитів втратився контекст попередніх кроків.
Інфраструктурний моніторинг такого не зловить — він дивиться на доступність і затримки, а не на сенс того, що повернулося користувачеві.
Типових місць втрати контексту три. Перше — збій одного кроку в ланцюжку викликів: пошук повернув порожній результат, крок нормалізації віддав обрізаний фрагмент, і далі модель досформувала відповідь за здогадкою.
Друге — непомічена зміна поведінки після оновлення моделі або промпту: формально той самий контракт, але змінилися довжина відповіді, формат посилань, готовність дотримуватися обмежень. Третє — відповіді без джерела, коли посилання на документ або відсутнє, або веде не туди.
Ловляться такі відмови зазвичай від користувачів: надходить скарга на конкретну відповідь, і далі починається розбір інциденту за логами.
Діагностика впирається в те, що запит і відповідь збережені як один рядок, без розбиття за кроками, без вхідних даних кожного виклику, без версії промпту й моделі. Відтворити ситуацію не вдається — вхідні дані вже змінилися, а збірки оцінок і регресійних наборів немає.
Саме це закриває спостережуваність AI-сервісів: трасування всього ланцюжка із збереженням проміжних результатів, прив'язка до версій промптів і моделей, регулярна оцінка відповідей за набором перевірок і алерти на зсув якості, а не лише на помилки. Нижче розбираємо, як це влаштовано і які інструменти для AI-спостережуваності беремо в роботу.
Що дає AI-спостережуваність: вимірювані зміни
Трасування звернень до моделі дає зв'язку «запит — знайдений контекст — відповідь — оцінка». Збір метрик іде на боці застосунку, тому видно не лише факт збою, а й крок, де він виник: підготовка промпту, пошук у базі знань, виклик інструмента, постобробка.
Платформи цього класу — від відкритого Langfuse до хмарних сервісів — приймають такі трасування без переписування логіки застосунку. Ефект від спостережуваності рахується у перевірюваних величинах.
Час розбору інцидентів
Скарга «модель відповідає не те» раніше розбиралася вручну: відтворити діалог, знайти версію промпту, зіставити з релізом.
За трасуванням інцидент локалізується за хвилини — видно вхідні дані, спрацьовані інструменти й повний текст відповіді, тому не доводиться здогадуватися про контекст.
Частка виявлених відхилень
Автоматичні оцінки рахують частку відповідей, що пройшли перевірки на релевантність, коректність формату й відсутність вигаданих фактів. Відхилення видно на всій вибірці, а не лише на тих діалогах, які хтось устиг відкрити.
Обсяг ручних перевірок
Ручний перегляд звужується до зрізу: система сама відбирає відповіді з низькою оцінкою, довгим відгуком або незвичним споживанням токенів.
Обсяг звернень до моделі видно за кожним сценарієм — зрозуміло, які підказки й розділи бази знань тягнуть навантаження, а які не використовуються.
Варіанти підключення спостережуваності: порівняння
Телеметрію знімають двома способами: зсередини застосунку — клієнтською бібліотекою платформи, або ззовні — шлюзом між застосунком і моделлю.
Перший бачить весь ланцюжок кроків, пошук у базі знань і виклики інструментів; другий не потребує правок у коді, але фіксує лише обмін із моделлю. Нижче — п'ять режимів збору телеметрії та межі кожного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Інструментування всередині застосунку | Потрібні спани за кроками ланцюжка, пошуком у базі знань, викликами інструментів | Правки в коді й супровід версій бібліотеки |
| Зовнішній шлюз телеметрії перед моделлю | Швидкий старт без правок у коді, єдина точка для всіх сервісів | Бачить лише обмін із моделлю, внутрішні кроки не розкриває |
| Хмарний сервіс спостережуваності — LangSmith, Helicone | Свого сховища немає, потрібні готові панелі й розбір помилок | Дані йдуть постачальнику сервісу, є ліміти за обсягом |
| Відкрита платформа трасування у власному контурі — Langfuse | Вимога зберігати промпти й відповіді в себе | Розгортання, оновлення й резервні копії на вашому боці |
| Самостійна збірка: колектор телеметрії та власне сховище | Нестандартні метрики й своя схема зберігання | Розробка й підтримка цілком на вашому боці |
Режими зазвичай комбінують: шлюз збирає мережевий шар за всіма сервісами одразу, а бібліотека додає деталізацію на критичних сценаріях. Якщо промпти й відповіді не можуть покидати ваш контур, хмара відпадає — залишається відкрита платформа або самостійна збірка.
Порядок впровадження: від аудиту до передачі
Спостережуваність LLM-застосунку не з'являється від підключення бібліотеки: спочатку потрібно зрозуміти, які виклики відбуваються і що за ними потрібно відновити під час розбору інциденту.
Нижче — порядок робіт, за яким ми йдемо від інвентаризації до передачі регламентів команді замовника.
Аудит та інвентаризація викликів
Збираємо карту всіх точок виклику моделі: користувацькі сценарії, фонові завдання, ланцюжки агентів, службові й повторні запити. Для кожної точки фіксуємо склад трасування — ідентифікатор сесії, версію промпту, вхід і вихід, споживання токенів, затримку, статус. Окремим списком іде те, що зберігати не можна: персональні дані й ключі маскуються до запису.
Схема потоків і зберігання даних
Проєктуємо шлях телеметрії до сховища: запис із застосунку або через проксі-шар, поведінку при недоступності приймача, проріджування рутинних викликів, щоб обсяг не зростав лінійно.
Готові платформи на кшталт Langfuse закривають візуалізацію, але розміщення й строк життя даних диктують вимоги замовника.
- Інвентаризація викликів і узгодження переліку полів.
- Схема збору: точки знімання, формат подій, буфер на боці застосунку.
- Налаштування зберігання: політика очищення, строк життя записів, маскування.
- Перевірка на тестовому контурі: прогін сценаріїв, звірка з логами, розбір навчального інциденту.
- Оцінка зростання обсягу й поведінка під навантаженням.
- Передача регламентів: читання трасування, алерти, дії при збої збору.
Артефакти на виході: що залишається у команди
Ми передаємо не звіт про виконану роботу, а робочий контур спостережуваності, який команда далі веде сама. Усі матеріали лежать у репозиторії поруч із кодом: правки проходять рев'ю, історія змін зберігається, а залежності від зовнішніх сервісів описані явно.
Конфігурації та схеми
- Конфігурація збору даних: які виклики моделі пишуться цілком, що йде у вибірковий запис, де вирізаються персональні дані — до збереження, а не після.
- Схема потоків телеметрії: точки знімання, буфери, сховище трейсів, строк зберігання й поведінка системи, коли приймач недоступний.
- Налаштований проєкт у Langfuse з дашбордами: затримка відповіді, частка помилок, споживання токенів за моделями й сценаріями.
- Довідник метрик і розмітки: що вважається помилкою, як позначаються сценарії, за якими розрізами будуються зрізи.
Політики доступу та регламенти
- Політики доступу до даних: ролі, кому видно повні трейси, кому — лише агрегати, строки зберігання й порядок видалення на запит.
- Оповіщення про відхилення: пороги за часткою помилок, затримкою й споживанням, канали повідомлень, порядок чергування.
- Регламент розбору інцидентів: хто відкриває розбір, за який час, що фіксується у висновку і як перевіряється виправлення.
Після передачі інженери додають нові метрики й змінюють пороги без нас — це одна правка в конфігурації, а не окремий проєкт.
Кейс: як скоротили час розбору інцидентів
Клієнт — сервіс з AI-асистентом: відповідь збирається з кількох звернень до моделі та викликів внутрішніх сервісів. Звернулися після серії скарг — відповіді приходили порожніми, обрізаними або не за темою, а відтворити збій за логами застосунку не вдавалося.
Що було до
Діагностика трималася на текстових логах: видно факт запиту й код відповіді, але не видно, який крок ланцюжка зіпсував результат. Контекст збирали вручну, і це з'їдало основну частину часу.
- Локалізація збою — 5–6 годин, якщо контекст узагалі вдавалося зібрати.
- Першопричина знаходилася у 40% випадків, решту закривали перезапуском — і скарга поверталася.
- Повторні звернення щодо тієї самої проблеми — близько третини користувачів.
- До 25 інцидентів на місяць, частину помічав лише клієнт.
Що змінилося після
Розгорнули трасування на Langfuse: кожен запит — дерево кроків із входом, виходом, затримкою й числом токенів, тому збійний крок видно без ручного збирання. Зверху — набір еталонних питань з автоперевіркою відповідей і оповіщення на падіння частки успішних відповідей.
- Локалізація збою — 15–20 хвилин разом із підтвердженням причини.
- Першопричина знаходиться у 9 з 10 розборів, спірні випадки закриваються посиланням на трасу.
- Повторні звернення знизилися на 60%: розбір закінчується правкою, а не перезапуском.
- Інцидентів — з 25 до 8 на місяць, решту ловить регресійний набір до релізу.
Кожен розбір поповнює набір перевірок, тому схожий збій випливає на тестуванні, а не у клієнта.
Чим трасування відрізняється від логування запитів
Логи — плоский потік: рядок на вхідний запит, рядок на відповідь, окремий на помилку. Поки запит один, картина читається; під паралельним навантаженням події різних користувачів перемішуються, і причину збою відновлюють за мітками часу — з помилками на межах кроків.
Трасування описує запит деревом кроків із спільним наскрізним ідентифікатором. В одній трасі видно, скільки фрагментів підняли зі сховища, з якими параметрами викликали модель, які інструменти запустили й скільки зайняв кожен крок.
Батьківсько-дочірні зв'язки показують ланцюжки викликів моделі, включно з вкладеними й повторними зверненнями, які в журналі виглядають як набір незв'язаних рядків.
Різниця помітна під час розбору деградації. За логами видно, що час відповіді виріс; за трасою — що гальмує саме пошук у базі знань, а генерація залишилася такою самою.
Кореляція кроків обробки дозволяє порівнювати два прогони одного запиту після зміни промпту або моделі й бачити, де результати розходяться, замість здогадів за фінальним текстом.
Логування при цьому не скасовується: журнали ширші й дешевші, вони покривають інфраструктуру, відмови, обмеження доступу — усе, що відбувається поза обробкою конкретного запиту.
Контекст запиту й відповіді зберігається на своєму рівні траси й не змішується із загальним потоком, а зв'язка тримається на наскрізному ідентифікаторі запиту в кожному записі: від аномалії в метриці переходиш до траси й до потрібних рядків журналу без ручного зіставлення за часом.
Із цієї зв'язки й збирається спостережуваність — коли метрики, траси й журнали посилаються одне на одного.
Обмеження: зберігання даних, приватність, затримки
Траси зростають лінійно вслід за трафіком, і обсяг сховища телеметрії швидко стає головною статтею утримання контуру. Тому строк зберігання задаємо політикою: детальні трейси з усіма кроками живуть коротке вікно, агреговані метрики якості — довге.
Вибірка теж керована: повні трейси пишуться для частки запитів, решта дають метрики без тіл промптів і відповідей.
Приватність даних запитів вирішується на вході, а не вичисткою заднім числом. Чутливі поля — персональні дані, реквізити, ключі доступу — розмічаються списком правил і закриваються маскуванням або хешуванням на боці застосунку, ще до запису у сховище.
У трейсі залишається структура виклику й метрики, достатні для розбору, але не текст, який не можна показувати поза контуром. Список правил супроводжується разом зі змінами в коді — інакше нове поле у формі знову почне витікати в телеметрію.
Вплив збору на затримку відповіді знімається тим, що експорт іде поза критичним шляхом: запис у локальний буфер, відправлення пакетами, жодних синхронних мережевих викликів між моделлю й користувачем.
Якщо політика забороняє винесення даних, трейси залишаються у вашому контурі — Langfuse розгортається всередині вашої мережі, і назовні не виходить жоден фрагмент запиту.
Збір трейсів сповільнить відповіді користувачеві?
Ні, якщо він винесений за критичний шлях. Застосунок пише подію в локальний буфер, окремий процес відправляє пакети у сховище. При недоступності сховища буфер обмежений за розміром і скидає старі події, а не блокує запит до моделі.
Обговоримо задачу: що уточнюємо на першому розборі
Такий розбір займає менше години й не потребує підготовленої інфраструктури — достатньо, щоб з вашого боку була людина, яка знає контур, і доступ до опису того, як зараз влаштовані виклики моделей.
Ми розбираємо задачу спостережуваності, фіксуємо, що вже збирається, і повертаємося з оцінкою та планом робіт.
- перелік вихідних даних: які сервіси звертаються до моделей, де живуть промпти, як виглядає поточне логування і в якому вигляді приходять трасування;
- обсяги: приблизна кількість запитів на добу, довжина контексту, частка відповідей, які зараз розбирають вручну;
- порядок доступу до контуру: хто видає ключі до середовища, чи потрібні погодження і в якому режимі дозволено доступ — лише читання метрик або розгортання збирача;
- вимоги до приватності: які поля не можна виносити за периметр, що маскуємо до відправлення, де зберігається історія;
- питання, на які система має відповідати: де втрачається час, які запити дорожчі за інші, чому частина відповідей іде в брак;
- ролі: хто з боку замовника приймає результат і в які строки першого етапу ми вкладаємося.
Після розбору ви отримуєте склад етапів із порядком робіт, точки контролю й розуміння, що знадобиться від вашої команди на кожному кроці. Опишіть задачу — повернемося з оцінкою та планом.
