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

Модель демонструє точність на рівні 97%. Випадки галюцинацій є незначними. Графіки показують зростання. Проте користувачі втрачаються.

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

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

Коли 97% є менш вражаючими, ніж 90%

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

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

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

Сім відсотків зростання точності призвели до зниження конверсії.

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

Ігноровані метрики

Індустрія зосереджується на оптимізації тих аспектів, які можна легко оцінити, і не звертає уваги на те, що насправді завдає шкоди продукту.

Існують аспекти, які рідко піддаються вимірюванню. Одним із таких є частка випадків, коли люди втручаються в автоматизовані процеси (Human Override Rate) - це ситуації, коли користувач вносить зміни до результатів системи. Після третього такого випадку рівень довіри до системи різко знижується, і користувач починає ретельно перевіряти кожну відповідь.

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

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

Тестове середовище проти реального життя

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

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

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

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

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

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

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

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

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

Які зміни принесли LLM?

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

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

"Ми розпочали аналізувати якість міркувань, - зазначає Дмитро. - А також поведінку згідно з наданими інструкціями та стабільність відповідей. Це абсолютно інші критерії."

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

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

Коли вдосконалення приносить шкоду.

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

Приклад: розширеність відповіді (Answer Coverage) збільшується – агент надає більш детальну інформацію, пояснюючи свій підхід та етапи, перш ніж представити результат. Однак такі відповіді стають занадто об’ємними, і користувач може втомитися від тривалого читання.

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

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

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

Вартість помилки

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

"Невірно вибрані показники можуть спричинити юридичні проблеми, - зазначає Дмитро. - Це особливо стосується випадків, коли важливі дефекти залишаються непоміченими."

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

Що слід вчинити

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

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

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

Гарний звіт не забезпечує жодних гарантій. Метрика не є остаточним рішенням; це лише інструмент, який допомагає вам аналізувати продукт. Але пам'ятайте, що кожен інструмент має свої обмеження та недоліки.

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