Моніторинг якості відповідей LLM: метрики, дрейф і алерти

Моніторинг LLM: де ламається якість відповідей моделі

Якість відповідей моделі майже ніколи не падає повністю — вона просідає по краях: на рідкісних формулюваннях, на темах поза навчальним зрізом, на даних, які змінюються швидше за пошуковий індекс.

Середня оцінка при цьому залишається в нормі, тому збій не видно ні в доступності сервісу, ні в логах застосунку.

Перша типова відмова — невмотивовані відмови на коректний запит. Причина зазвичай у перекручених фільтрах, зміненій системній інструкції або у форматі входу, який не розібрав шар попередньої обробки.

Рахувати їх потрібно часткою відмов за класами запитів: у загальній цифрі зростання у вузькому сценарії розчиняється в потоці.

Друга — застарівання фактів: відповідь звучить так само впевнено, як правильна, і відрізняється лише змістом. Такі недостовірні відповіді не ловляться перевіркою формату — їх виявляють звіркою з еталонним набором і ручним розбором спірних місць.

Третя — тиха деградація на рідкісних запитах: середні метрики тримаються завдяки масовим сценаріям, а хвіст розподілу зсувається — змінюються довжина відповіді, частка уточнювальних запитань, посилання на джерела.

Дрейф якості моделі накопичується непомітно — після оновлення індексу, правки інструкції, зміни версії або зростання навантаження. Скарги користувачів на відповіді надходять із затримкою і в розмитому вигляді: люди просто перепитують, переформульовують запит, ідуть до оператора.

Ранні ознаки ловляться за непрямими сигналами — повторні спроби, глибина діалогу, ескалації. Далі розбираємо, як влаштовано моніторинг LLM: які метрики рахуємо, де ставимо межі норми і що йде в оповіщення.

Що дає безперервний контроль якості відповідей моделі

Разовий прогін перевірок на реліз фіксує стан моделі на конкретний момент, а між релізами якість зникає непомітно: оновлюється пошуковий індекс, змінюється склад запитів, оновлюється сама зовнішня модель.

Безперервний контроль перетворює це на потік метрик, де відхилення видно раніше, ніж про нього напише користувач.

Що стає вимірюваним

Базовий набір — частка невдалих відповідей (порожня, не за темою, без опори на знайдене джерело), частка запитів, що пішли на уточнення або до оператора, і точність розпізнавання наміру.

Рахуємо двома контурами: автооцінка на еталонних парах і ручна розмітка вибірки — друга потрібна, щоб калібрувати першу і не довіряти їй наосліп. На питання «чи стало гірше після правки шаблону запиту» відповідаємо за хвилини, а не за тиждень збору зворотного зв’язку.

Як це змінює експлуатацію

Дрейф відстежуємо за зсувом розподілу тем і за падінням частки відповідей із підтвердженим джерелом: алерт зав’язаний на швидкість зміни, а не на абсолютний поріг, інакше потік сигналів починають ігнорувати.

Час виявлення відхилень скорочується з доби до годин, на критичних сценаріях — до десятків хвилин. Час відновлення сервісу тримається на зафіксованих версіях інструкцій та індексів: відкат до попередньої збірки займає хвилини замість повторного налагодження на живих користувачах.

Що перестає доходити до користувача

Частину усунених класів відмов перехоплюємо до видачі: відповідь без опори на джерело, дані з чужого контексту у відповіді, впевнене формулювання на запит поза зоною компетенції. Такі випадки йдуть у сценарій з уточненням або до оператора.

Трасування, оцінку та зрізи за версіями збираємо в Langfuse — метрика прив’язана до конкретної збірки, тому деградацію можна розібрати, а не переказати.

Моніторинг LLM: порівняння підходів до спостереження

Вибір режиму спостереження визначається тим, що дорожче пропустити: деградацію на живому трафіку чи регрес після правки промпту. Онлайн-оцінка відповідей рахує метрики на кожному запиті, але без еталона дає сигнал «стало гірше» без пояснення причини.

Офлайн-оцінка відповідей проганяє еталонний набір запитів на кожній збірці — результат відтворюваний і порівнюваний між версіями, але покриває лише ті сценарії, що потрапили в набір. Нижче — чотири режими в тому вигляді, у якому ми їх збираємо.

Автоматичні метрики на потоці рахуємо засобами Ragas і зберігаємо з прив’язкою до версії промпту.

Гібрид працює так: онлайн-контур ловить дрейф, а відкладена вибірка з потоку раз на тиждень звіряється з еталоном і ручною розміткою — це калібрує пороги алертів, не перевантажуючи розмітників.

Порядок впровадження: від аудиту логів до передачі сервісу

Моніторинг якості відповідей — це не дашборд, який ставлять після релізу, а інженерний контур із прийманням і регламентом. Тому ведемо його як проєкт: спочатку фіксуємо, що саме вважаємо деградацією, і тільки потім пишемо код. Нижче — порядок робіт, за яким проходимо на кожному впровадженні.

1. Аудит логів і запитів. Вивантажуємо історію звернень, розбираємо типи сценаріїв і частку відповідей, які вже зараз ідуть у відмову або перепитують. На виході — карта шляхів і розуміння, де втрачається якість.

2. Схема метрик. Узгоджуємо набір: точність на еталонній вибірці, частка невпевнених відповідей, стабільність формулювань між прогонами, час відповіді. Кожна метрика має обчислюватися автоматично з логів, а не оцінюватися «на око».

3. Збірка еталонної вибірки. Розмічаємо вручну діалоги, включно з рідкісними та пограничними випадками, закріплюємо правила розмітки і версію набору. Без цього порівнювати релізи між собою немає з чим.

4. Налаштування оповіщень. Задаємо пороги та вікна усереднення так, щоб сигнал спрацьовував на дрейф, а не на одиничний викид. Критичні та інформаційні повідомлення розводимо за різними каналами.

5. Приймання на історичних даних. Проганяємо контур за минулий період і звіряємо: де сигнали спрацювали б і чи збігається це з реальними просіданнями. Тут же відстроюємо хибні спрацювання і домовляємося про поріг терпимості.

6. Передача в експлуатацію. Віддаємо регламент чергування, інструкції щодо реакції на кожен тип сигналу, порядок відкату на попередню версію моделі. Команда замовника далі веде контур самостійно.

Такий порядок дає передбачуваність: на момент запуску в команди є метрики, перевірені на історії, і зрозумілий протокол дій при деградації.

Що залишається в команди замовника після впровадження

Моніторинг LLM корисний команді як робочий інструмент, а не як звіт: бачити, чому відповіді стали гіршими, і втручатися самостійно. Тому впровадження закінчується не запуском дашборда, а передачею комплекту артефактів — нижче, що залишається в замовника.

• Схема метрик і логування: частка відмов, відхилення від еталонних відповідей, спрацювання фільтрів і поля логів, з яких вони збираються, — нова метрика підключається без переробки конвеєра.
• Набори запитів для перевірки: еталонні та свідомо проблемні звернення за ключовими сценаріями; прогін нової версії моделі до викату показує, стало краще чи гірше, за хвилини.
• Дашборди якості: частка успішних відповідей, розподіл за темами, затримка — з розбивкою за версіями моделі, щоб відрізняти загальну деградацію від локальної.
• Налаштування алертів: пороги на дрейф розподілу запитів і падіння метрик прив’язані до вікна спостереження, тому черговий бачить реальну деградацію, а не потік хибних спрацювань.
• Регламент реагування: хто підтверджує спрацювання, як локалізують причину, у який момент відкочують версію моделі і що фіксують у журналі.
• Політики доступу: хто бачить сирі діалоги, хто — лише агрегати, терміни зберігання і маскування персональних даних.
• Інструкції для чергової зміни: чек-листи на типові спрацювання, шаблони повідомлень і порядок ескалації.
• Схема інтеграції: обов’язкові точки логування при підключенні нового сценарію або провайдера моделі.

Передаємо комплект із навчанням чергової зміни і розбором першого інциденту разом.

Кейс: як скоротили частку невдалих відповідей і час реакції

Кейс — сервіс підтримки, де асистент відповідає за внутрішньою базою знань і оформлює заявки. Кілька тисяч звернень на добу, оновлення моделі та інструкцій для неї виходять кожні два тижні.

До впровадження спостереження якість відстежували за скаргами: про невдалу відповідь команда дізнавалася від користувача, а не від системи.

Розбір одного інциденту займав у середньому робочий день: журнали вивантажували вручну, зіставляли питання і відповідь, відтворювали контекст розмови. Близько 70% відхилень знаходили заднім числом — уже після того, як відповідь пішла клієнту.

Окремий біль — регрес після оновлення моделі: падіння точності спливало через тиждень і за випадковими зверненнями.

Що змінили: кожна відповідь зберігається разом із контекстом, версією моделі та параметрами генерації; раз на добу проганяється еталонний набір питань з оцінкою точності та повноти; розподіл тем, довжини і структури відповідей порівнюється з базовим зрізом — так видно дрейф. Події та алерти зведені в Grafana, черговий отримує сигнал, а не завдання шукати причину з нуля.

Що стало з метриками

Частка невірних відповідей знизилася з 12% до 3–4%, час реакції на інцидент — з 6–8 годин до 30–40 хвилин, частка відхилень, знайдених заднім числом, — з 70% до 15%.

Регрес після оновлення моделі тепер ловлять на перевірці: якщо оцінка на еталонному наборі падає більш ніж на 5% щодо попереднього прогону, збірка не йде до користувачів.

Чим відрізняється оцінка відповідей моделлю від ручної розмітки?

Модель-суддя розбирає відповідь за рубрикою: перевіряє опору на джерело, відсутність вигаданих фактів, повноту і дотримання формату — і ставить вердикт або бал. Це дає змогу оцінювати весь потік відповідей, а не окремі приклади, і ловити регресії між версіями інструкцій.

Обмеження вбудоване в конструкцію: суддя зміщений до довгих і гладко написаних відповідей і гірше розрізняє смислові помилки у вузькій предметній області.

Ручна розмітка залишається еталоном, але її ціна не лише в часі. Поки двоє перевіряльників не зійдуться на одному зрізі, неясно, з чим узагалі порівнювати модель. Тому спочатку рахуємо узгодженість перевіряльників: частку збігів і каппу за кожним критерієм. Якщо розбіг між людьми більший, ніж між моделлю і людиною, проблема в рубриці, а не в судді.

Розходження оцінок рахують на вибірці для перевірки, і вона не випадкова. Стратифікуємо за типом запиту, довжиною, мовою і окремо добираємо крайові випадки — відмови, короткі питання, відповіді без опори на джерело.

За бінарними критеріями дивимося частку незбіглих вердиктів, за шкальними — середню різницю балів та її знак: систематично м’якший суддя за людину чи суворіший.

Автоматична оцінка тримає достатню точність там, де критерій формальний: чи дотримано формат, чи є посилання на джерело, чи не вигаданий факт, чи відмовилася модель відповідати.

Без людей не обійтися в тоні, юридичних і предметних обмеженнях і там, де правильна відповідь потребує зовнішнього контексту, якого немає в рубриці.

Практичне правило: суддю калібрують на розміченому людьми зрізі, а потім звіряють на ньому при кожній зміні моделі або інструкцій. Якщо розходження з еталоном зростає, довіру до автоматичних метрик знімають до перекалібрування.

Часті технічні сумніви щодо спостереження за моделлю

Спостереження за моделлю впирається в одні й ті самі заперечення: чи не сповільнить збір відповіді користувачам, чи не витечуть персональні дані, чи обов’язково віддавати листування назовні. Нижче — як ці ризики закриваються на практиці.

Окремо — деградація моделі. Чекати її лише після зміни версії невірно: якість частіше ронить дрейф даних — зміщення запитів, нові формулювання, сезонні сценарії. Тому входи і виходи вимірюються разом, а не за скаргами користувачів.

У відповідях є персональні дані клієнтів

Маскування виконується до запису, а не при читанні: номери, адреси та ідентифікатори замінюються на плейсхолдери ще на вході в сховище. Якщо політика забороняє винесення даних, метрики рахуються на стороні замовника, а назовні йдуть лише агрегати.

Чи можна стежити без доступу до запитів користувачів?

Так. Збирається синтетичний набір з еталонними відповідями і проганяється за розкладом — він ловить регресії після оновлень і зміни промптів. Реальний трафік підключається пізніше, коли узгоджено контур зберігання.

Скільки зберігати історію запитів?

Сирі пари — коротким вікном, цього достатньо для розбору інцидентів і перевірки гіпотез. Далі залишаються агрегати за зрізами: обсяг зростає повільно, а динаміка якості видна на довгому горизонті.

Обговоримо задачу: що потрібно для старту спостереження

Обговорення починається з того, що вже є у вас: доступ до тестового контуру, вивантаження реальних запитів і відповідей за останні тижні, перелік сценаріїв, де помилка коштує дорого — видача невірної довідки, обхід правил, втрата формату відповіді.

Цього достатньо, щоб оцінити обсяг. Якщо розмітки немає, ми зберемо еталонний набір самі: частину розмічає замовник, спірні випадки розбираємо разом, щоб метрика відображала ваше уявлення про якість, а не наше.

На дзвінку уточнюємо межі: де працює рішення, хто і як реагує на алерт, які перевірки вже є в релізному циклі, які відповіді вважаються неприпустимими.

Окремо проговорюємо, що вважаємо дрейфом — зміну розподілу запитів, падіння частки коректних відповідей на еталонному наборі або розходження з незалежною моделлю-суддею. Від цього залежить і набір метрик, і пороги спрацювання, і те, куди йдуть повідомлення.

Повертаємося письмовим планом робіт: етапи, строки, склад команди і точки, де рішення можна зупинити без втрати зробленого.

• Що приносите ви: доступи до контуру, приклади трафіку, список критичних сценаріїв, контакт чергового.
• Що уточнюємо на дзвінку: межі якості, пороги алертів, канали повідомлень, вимоги до зберігання історії.
• Що отримуєте у відповідь: план робіт за етапами з оцінкою строків і складом команди.
• Як виглядає перший крок: пілотний запуск на одному сценарії — збір метрик, дрейф і алерти в робочому контурі.
• Що вирішуємо за підсумками пілоту: розширення на інші сценарії, автопрогін регресії перед релізом, регламент розбору спрацювань.

Опишіть задачу у вільній формі — повернемося з оцінкою строків і планом робіт, без загальних слів.