KPI для AI-агентів: де ламається контроль якості
Агент запущено в робочий контур: він відповідає на звернення, частину заявок закриває без участі людини. Приймання при цьому зазвичай вичерпується десятком питань — їх ставили до запуску, відповіді влаштували, і далі якість ніхто не вимірює.
Реальний потік запитів відрізняється від тестового, тому перший сигнал про проблему надходить від незадоволених користувачів, а не від системи.
Деградація відповідей майже ніколи не виглядає як поломка. Оновили системну інструкцію під новий сценарій, розширили базу знань, змінили модель під навантаження — і на частині запитів агент починає впевнено відповідати без опори на джерело.
Кожна зміна окремо виглядає безневинно, а накопичений ефект видно лише в порівнянні: тим самим питанням, поставленим до і після.
KPI для AI-агентів працюють, коли це набір вимірюваних величин, а не один агрегат «задоволені чи ні».
Частка звернень, закритих без передачі людині; частка відповідей із підтвердженим джерелом; частка повторних звернень з того самого питання; час до корисної відповіді; частка діалогів, де користувач перепитав.
Ці величини знімаються двома способами — на регулярному прогоні еталонного набору запитів і на живій вибірці з діалогів.
Оцінка роботи агента без еталонного набору впирається в ручне розмічування, а без живої вибірки — у самообман: тестові питання перестають відображати реальні формулювання.
Розбираємо, як зібрати обидві частини, пов'язати метрики зі змінами конфігурації й отримати контроль якості агентів, за якого проблеми впровадження агентів ловляться до скарг, а рішення відкочується за конкретним показником, а не за відчуттям.
Що дає система метрик для AI-агентів у роботі
Метрики AI-агентів починають працювати, коли їх рахують на кожному діалозі, а не за фактом скарги.
Базова величина — частка коректних відповідей: фіксований набір реальних звернень із розміткою проганяється на кожній зміні промптів, інструментів і моделі, результат порівнюється з попередньою версією. Розбіжність вище за поріг — оновлення не йде в бойовий контур, а повертається на доопрацювання.
Другий контур — час реакції на відхилення. Поки якість відстежують очима, між просіданням і його виявленням минає доба, і весь цей час агент упевнено відповідає неправильно.
Метрика переводить строк у хвилини: падіння частки коректних відповідей або зростання відмов виклику інструментів піднімає сигнал одразу, черговий відкриває конкретний діалог і бачить причину, а не лише факт.
Зниження ескалацій — інтегральний показник, тому ми розносимо їх за класами: агент не знайшов дані, невірно визначив намір, вийшов за межі регламенту, зірвав строк відповіді.
У кожного класу своя метрика і свій власник у команді замовника, тому усувається причина, а не окремий випадок із черги.
Збирається це на штатній телеметрії: події діалогу, виклики інструментів, затримки та результати потрапляють у спільний контур спостережуваності, панелі в Grafana оновлюються без ручних вивантажень.
Просідання стає видно до того, як про нього напише клієнт, а відкат версії конфігурації займає хвилини.
Підходи до вимірювання: розбір діалогів і автоперевірки
Оцінювати агента однією цифрою безглуздо: методи різняться ціною, охопленням і тим, які помилки взагалі потрапляють у поле зору. Нижче — чотири робочі опції та їхні сліпі зони: від повністю машинних прогонів до ручного розбору.
| Метод | Коли підходить | Де впирається в обмеження |
|---|---|---|
| Автоперевірки за правилами | Формат відповіді, обов'язкові кроки, коректність виклику внутрішніх функцій | Формально правильна, але марна відповідь проходить як успіх |
| Автоперевірка моделлю-арбітром за рубрикою | Масові прогони, регрес після кожної правки інструкцій агента | Успадковує сліпі зони моделі, потребує калібрування на людях |
| Еталонні набори діалогів | Порівняння версій агента між собою, захист від деградації | Застарівають, покривають лише відомі сценарії |
| Експертний розбір діалогів | Спірні кейси, запуск нової лінії, розбір відмов | Дорогий за часом експертів, мала вибірка |
Методи не конкурують, а ділять ролі. Еталонний набір фіксуємо як регрес-контур: правка інструкцій проганяється по ньому, і видно, що саме стало гірше. Автоперевірки йдуть на кожну репліку потоку, експертний розбір — за вибіркою з розбіжностей і відмов.
Зв'язка тримається на калібруванні: поки оцінка арбітра й оцінка експерта розходяться в межах кількох відсотків, машинні прогони можна вважати метрикою.
Як тільки розбіжність зростає, рубрику переглядаємо — інакше KPI для агентів починає вимірювати не якість відповідей, а їхню гладкість.
Як ми вибудовуємо KPI для AI-агентів: етапи робіт
KPI для AI-агентів починається не з графіків, а з аудиту: поки не описано кожен сценарій і не ясно, де саме агент помиляється, будь-яка цифра у звіті спірна. Тому перші дні роботи йдуть на розбір потоку звернень і визначення точок, де якість можна виміряти об'єктивно.
- Аудит сценаріїв. Розбираємо всі шляхи, якими агент веде діалог: типові запити, рідкісні гілки, передачі оператору. За кожним фіксуємо, що вважаємо успіхом, а що збоєм.
- Збір даних. Налаштовуємо логування так, щоб зберігалися запит, відповідь агента, використані джерела та дія користувача. Без цього пороги не буде на чому перевіряти.
- Узгодження метрик. Зводимо технічні показники з цілями бізнесу: частка звернень, закритих без оператора, точність відповіді за базою знань, час до відповіді, частка відмов.
- Налаштування порогів. Для кожної метрики задаємо не одне значення, а коридор: норма, попередження, аварійний рівень. Межі рахуємо за накопиченою статистикою, а не на око.
- Перевірка метрик. Проганяємо систему на відкладеній вибірці й навмисно ламаємо сценарії: якщо метрика цього не помічає, вона не працює.
- Впровадження та передача. Виводимо показники в загальний моніторинг, описуємо регламент реакції на відхилення і вчимо команду замовника змінювати пороги самостійно.
Після передачі регламент живе без нас — нові сценарії та правки порогів команда додає сама.
Що замовник отримує на руки за підсумками проєкту
Проєкт із метрик для AI-співробітників закінчується не презентацією, а робочим комплектом: кожен артефакт команда замовника використовує без нашої участі.
Передаємо все із зазначенням власника, версії та порядку змін — щоб за півроку ніхто не відновлював логіку метрики з листування.
- Каталог метрик. За кожною: що саме вимірює, на якому рівні рахується (окремий діалог, сценарій, виконавець), цільовий коридор і що вважається відхиленням.
- Схеми розрахунку метрик. Формули, джерела даних, вікно агрегації, правила обробки пропусків і повторних звернень. Та сама метрика дає однаковий результат під час перерахунку на іншому періоді.
- Панель моніторингу. Зрізи за сценаріями та виконавцями, динаміка в часі й окремий блок відхилень — черговий бачить проблему раніше, ніж її помічає користувач.
- Політики доступу до даних. Хто і на якій підставі бачить діалоги, хто — лише агрегати, де знеособлення під час вивантаження і як ведеться журнал звернень.
- Регламенти розбору. Порогові значення, за яких запускається розбір, відповідальні ролі, строки реакції та порядок фіксації висновку за інцидентом.
- Документація та передача. Інструкція з додавання нової метрики, схема її зв'язку з бізнес-показниками підрозділу та запис навчальної сесії для ваших інженерів і операторів.
Такий комплект переживає зміну підрядника й зростання кількості AI-співробітників: метрики додаються за описаною процедурою, а не вигадуються заново під кожен новий сценарій.
Кейс: якість відповідей агента до і після впровадження
Точка відліку
Агент-консультант відповідав неточно приблизно на 4 з 10 звернень: пропускав умову з бази знань або підставляв застарілі дані про послугу.
Якість при цьому вимірювалася вибірково — 30 діалогів на тиждень вручну, а розбір одного відхилення займав у середньому 40 хвилин: журнал діалогу лежав окремо від викликів інструментів і фрагментів, які агент витягнув з бази.
Повторні звернення з тієї самої теми становили 23% — клієнт повертався, бо перша відповідь була формально правильною, але завдання не закривала.
Що змінили
Ввели схему розмітки відповідей: коректна, неповна, вигаданий факт, відмова. Журнал викликів зшили з журналом діалогу в Langfuse — на одному екрані видно весь ланцюжок: запит, витягнуті фрагменти, викликаний інструмент, фінальна відповідь. Розбір відхилення перестав бути археологією за розрізненими файлами.
Зібрали еталонний набір із 240 питань з очікуваними відповідями й повісили прогін на кожен реліз інструкцій агента: падіння частки коректних відповідей нижче за поріг блокує викат.
Частка коректних відповідей зросла з 61% до 89%, час розбору відхилення скоротився з 40 до 8 хвилин, повторні звернення з тієї самої теми впали з 23% до 9%.
Метрики стоять у панелі моніторингу поряд із числом звернень — просідання точності після правки бази знань видно того самого дня, а не через місяць за скаргами.
Чим метрики якості відрізняються від метрик навантаження
Метрики навантаження рахують те, що легко зняти з інфраструктури: число звернень, час до першого токена, повну затримку відповіді, частку технічних помилок, обсяг спожитих токенів.
Вони відповідають на питання «сервіс живий і справляється з потоком», але нічого не кажуть про те, чи розв'язав агент задачу користувача. Рівний графік затримок однаково добре виглядає і в працюючого помічника, і у ввічливого автоінформатора, який переказує інструкцію.
Метрики якості вимірюють результат діалогу, а не його обслуговування.
Ключові з них: частка сценаріїв, закритих без передачі людині; частка повторних звернень з тієї самої теми в межах однієї сесії; частка відповідей, підкріплених джерелом, а не згенерованих із пам'яті; частка діалогів, де користувач переформулював запит двічі й більше — це пряма ознака, що корисність відповіді низька.
Розбіжність між двома наборами проявляється швидко. Прискорюємо генерацію, скорочуючи ланцюжок перевірок, — затримка падає вдвічі, а частка ескалацій на оператора зростає, бо агент частіше відповідає впевнено й неправильно. Метрики навантаження при цьому виглядають краще, ніж до змін, і рішення легко ухвалити помилкове.
Рахувати якість можна лише на розміченій вибірці реальних діалогів: еталонні набори з очікуваним результатом, періодична ручна розмітка, трасування кроків агента.
У нас для цього розгортається контур спостереження — наприклад, LangSmith — де кожен прогін порівнюється з попереднім за часткою розв'язаних задач, а не за швидкістю.
Практичний висновок простий: навантаження — тло й умова працездатності, якість — критерій приймання. KPI для AI-агентів будуються на другому, інакше оптимізація веде систему в бік швидких, але марних відповідей.
Сумніви щодо метрик агентів: відповідаємо по суті
Заперечення щодо метрик зазвичай ті самі: немає еталонних відповідей, журнали діалогів надходять неповними, а перевірки агент проходить формально й на живих зверненнях поводиться інакше.
Жоден із цих сумнівів не скасовує вимірювань — він змінює схему: де брати опору замість еталона, що вважати повнотою журналу і як відрізнити реальну якість від підгонки під перевірку.
У нас немає еталонних відповідей — із чим тоді порівнювати?
Еталон потрібен лише там, де відповідь однозначна. Для діалогових сценаріїв опора інша: рубрики оцінювання за критеріями, парні порівняння двох версій агента між собою та розмітка вибірки людьми з калібруванням розбіжностей. Такий набір стійкіший за одну «правильну» відповідь і показує рух якості від версії до версії.
Журнали діалогів неповні — оцінка буде недостовірною?
Повнота журналу — сама собою метрика. Ми фіксуємо, скільки кроків зберігається: виклики інструментів, вхідні та вихідні дані, факт передачі людині.
Якщо в записі губляться проміжні кроки, це окремий клас відмов — за ним видно, де зникає контекст, і його закривають до того, як рахувати показники за задачею.
Агент формально проходить перевірки — як це ловиться?
Формальне проходження — ознака того, що перевірки стали передбачуваними. Тому частину наборів тримаємо прихованими, завдання перемішуємо й не показуємо підряд, а рішення про готовність ухвалюємо за роботою на потоці реальних звернень, а не за внутрішніми прогонами.
Розбіжність між перевіркою та живою роботою теж вимірюємо: вона показує, де агент вивчив шаблон замість задачі.
Обговоримо задачу: розберемо сценарії та зберемо метрики
Щоб розбір не перетворився на обмін загальними міркуваннями, для першої розмови достатньо трьох речей: переліку сценаріїв, де AI-співробітник уже працює або має працювати, прикладів його відповідей за останні тижні й розуміння, хто в компанії ухвалює рішення «відповідь правильна чи ні». Цього досить, щоб намітити KPI для AI-агентів і не вгадувати наосліп.
Що розбираємо на старті:
- які сценарії закриває агент і де проходить межа його відповідальності;
- як виглядає коректна й некоректна відповідь у кожному сценарії — із цього виростає розмітка;
- які метрики вже збираються, а які доведеться додати в логування;
- де потрібен автоматичний контроль, а де вибірка з ручною перевіркою;
- хто з боку замовника підтверджує еталонні відповіді і з якою частотою;
- які обмеження щодо даних і доступів є в команди агента.
Після розбору повертаємося з планом робіт: перелік метрик із визначеннями та порогами, схема збору даних, етапи впровадження з контрольними точками.
Там само — оцінка строків за кожним етапом і склад команди: хто відповідає за розмітку, хто за оцінку якості, хто за доопрацювання інструкцій агента й правил відкату. Опишіть задачу — обговоримо сценарії та повернемося з оцінкою і планом.
