Метрики, які дійсно мають значення в ШІ: пояснює Дмитро Кияшко, інженер з тестування

Ця ситуація для індустрії типова. Команди інвестують місяці в оптимізацію показників, які добре виглядають на презентаціях – і не розуміють, чому утримання аудиторії падає.

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

Коли 97% гірше за 90%

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

Реальний випадок з його практики: модель працювала з точністю 90% і генерувала відповідь за сім секунд. Бізнес вирішив підвищити точність до 97%. Технічно це вдалося – але ціною додаткового навантаження на систему, додаткових запитів до ШІ-агента. В результаті відповідь почала генеруватися 20–23 секунди.

"Клієнт не побачив реальної різниці у якості відповіді, – каже він. – Але метрика задоволення впала. Люди не хочуть чекати по пів хвилини. Вони починають оновлювати сторінку, перевіряти, чи не завис додаток".

Сім відсотків приросту точності вбили конверсію.

Що відбувається, коли користувач чекає 20 секунд? Спершу сумнів: чи система взагалі працює. Потім – оновлення сторінки. Потім – спроба переформулювати запит. І коли відповідь нарешті з'являється – довіри вже немає.

Метрики, які ігнорують

Індустрія оптимізує те, що легко виміряти – і не помічає того, що насправді топить продукт.

Є речі, які майже ніхто не міряє. Частка ручних виправлень (Human Override Rate) – випадки, коли людина переробляє за системою. Після третього разу рівень довіри падає різко – користувач починає перевіряти кожну відповідь.

Ще одна критично недооцінена метрика – якість відновлення після збою (Recovery Quality). Йдеться не про сам факт помилки, а про те, як агент поводиться після неї: чи коректно відновлює контекст, чи зберігає вже зібрані дані, чи може продовжити сценарій без повторного проходження всього флоу. Recovery Quality важко автоматизувати, тому цю метрику часто не міряють або замінюють іншими, які не фіксують реальний досвід користувача.

Ці проблеми першими бачить не аналітика, а підтримка. Користувачі не формулюють це як "низький Recovery Quality" – вони пишуть: "я вже тричі відповідав на одні й ті самі питання" або "бот кожного разу починає з нуля". Або просто перестають користуватися продуктом. Масові звернення – це не ранній сигнал, а індикатор того, що деградація вже давно відбувається в реальній експлуатації.

Тестове середовище vs реальність

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

У тесті: "Забронюй готель у Львові на 15 травня". У реальній експлуатації: "той готель, де ми були, можеш глянути на вихідні але не дорого". Більшість таких збоїв не видно в тестових звітах. Метрики показують норму – а користувач уже пішов.

Друга різниця – навантаження. Дмитро наголошує: критично важливо розуміти реальну кількість запитів до ШІ-агента та кількість одночасних користувачів. Без цього оцінка системи під навантаженням не буде валідною.

І все одно продукти регулярно випускають протестованими лише на "чистих" даних. Цю проблему він бачить і коли працює в експертних журі – на подіях на кшталт UAtech Venture Night під час Web Summit у Ванкувері.

Агенти – інша гра

Робота з агентами – це інша історія. Змінюється сам об'єкт: оцінюється не відповідь, а поведінка.

"При оцінці статичної моделі об'єкт – правильність конкретної відповіді, – пояснює Дмитро. – При оцінюванні агента об'єкт – якість стратегії. Які інструменти були використані? Скільки разів їх викликали? Чи відбулася делегація задачі людині, якщо інструменти не надали всієї інформації?"

Це не один крок "запит–відповідь". Користувача не цікавить, скільки разів агент викликав інструмент і в якій послідовності. Його цікавить одне: чи задача вирішена без втручання. Агентні системи неможливо оцінювати метриками класичних моделей – вони просто не враховують цю багатокроковість.

Кияшко працює в Endpoint – дочірній компанії First American – і паралельно будує рішення для автоматизації тестування агентних систем у Xenoss.

Що змінили LLM

Великі мовні моделі змінили не лише методи оцінки – а сам об'єкт. Раніше були вузькоспеціалізовані моделі під конкретні задачі. Тепер – універсальні системи.

LLM перестали бути інструментами, які виконують команди. Вони стали поведінковими системами, які інтерпретують наміри.

"Ми почали оцінювати якість міркування, – каже Дмитро. – Поведінку відповідно до заданих інструкцій. Стабільність відповідей. Це зовсім інші виміри".

Одноразова перевірка – один запит, одна відповідь – більше не працює. LLM занадто чутливі до формулювань. Той самий запит, переформульований іншими словами, може дати зовсім інший результат.

Як побудувати систему оцінювання з нуля? Дмитро посилається на книгу "AI Systems Testing and Assessment: An Engineering Guide", де детально описав покрокову методологію – від архітектури до метрик якості.

Коли покращення шкодить

Оптимізація метрики не дорівнює оптимізації користувацького досвіду.

Приклад: повнота відповіді (Answer Coverage) зростає – агент дає більш розгорнуту відповідь, описує план і кроки перед тим, як надати результат. Але відповіді стають занадто довгими. Користувач втомлюється читати.

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

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

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

Ціна помилки

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

"Неправильно обрані метрики можуть призвести і до юридичних наслідків, – попереджає Дмитро. – Якщо пропустити критичні дефекти".

На міжнародних конференціях, де він рецензує дослідження колег, ця проблема виринає регулярно. Дмитро й сам автор наукової роботи про тестування мультимодальних ШІ-систем.

Що робити

Проблема не в тому, що індустрія покладається на погані метрики. Проблема – у їхньому використанні.

"Метрик дуже багато, – каже Кияшко. – Відповідно до задач та технічних характеристик продукту їх потрібно правильно підбирати і комбінувати. Помилка – покладатися на одну-дві метрики і вважати, що цього достатньо".

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

Красивий звіт нічого не гарантує. Метрика – це не відповідь. Це лінза, через яку ви дивитесь на продукт. І кожна лінза має сліпі зони.

Питання не в тому, які метрики ви використовуєте. Питання – що саме ці метрики від вас приховують