Компанії дедалі більше інвестують в AI, але далеко не завжди можуть зрозуміти, які з цих витрат справді окупаються. Причина — даних із рахунків AI-провайдерів недостатньо, щоб пов’язати витрати з конкретним бізнес-результатом.
HBJ адаптував матеріал про те, чому так відбувається, яких даних бракує компаніям і чому з AI-агентами проблема лише ускладнюється. А про те, як налагодити вимірювання на практиці, ми запитали Павла Лисого, ex-Senior Machine Learning Engineer в Universe Group.
Чому компаніям складно порахувати ROI від AI
У випадку з, наприклад, хмарною інфраструктурою, пов’язати витрати із бізнес-результатами доволі не складно. Наприклад, AWS дає змогу побачити, який акаунт, регіон чи ресурс сформував витрати. Якщо поєднати ці дані з інформацією про клієнтів і продукти, можна зрозуміти, на що саме пішли кошти та оцінити економіку конкретного продукту чи напряму.
Рахунки AI-провайдерів такої деталізації не дають. Вони показують, скільки токенів використала певна модель, іноді — з розбивкою за API-ключами. Але з них не зрозуміло:
який клієнт ініціював конкретний запит;
яка функція продукту звернулася до моделі;
чи привів цей виклик до потрібного бізнес-результату.
Очікувати, що цю проблему вирішать самі AI-провайдери, навряд чи варто. Їхні рахунки містять дані, необхідні насамперед для білінгу, а не для оцінки економіки конкретного продукту чи функції. Тому потрібну деталізацію компаніям доводиться збирати самостійно — на рівні власного продукту.
Яких даних бракує для вимірювання ROI
Щоб порахувати ROI від AI, компанії потрібно поєднати три типи даних. Разом вони дають змогу зрозуміти не лише, скільки коштує AI, а й на що саме пішли гроші та який результат вони принесли.
Дані про витрати. Кожен AI-провайдер по-своєму обліковує використання та формує рахунки. Окремо компанія може платити за хмарні GPU, векторні бази даних та інші сервіси. Тому всі ці витрати спочатку потрібно звести до єдиного формату. Але навіть тоді компанія знатиме лише, скільки витратила, а не що отримала за ці гроші.
Телеметрія на рівні застосунку. Саме цих даних, за словами автора оригінального матеріалу, компаніям найчастіше бракує. Для кожного AI-виклику потрібно фіксувати:
клієнта або сесію, які ініціювали запит;
функцію продукту, з якої надійшов виклик;
окремі кроки AI-агента, якщо йдеться про багатокроковий сценарій;
повторні спроби та fallback-виклики;
модель, яку використали;
до якого результату привів виклик.
У рахунку провайдера цієї інформації немає, тому її потрібно збирати всередині самого продукту.
Бізнес-дані. Це інформація про дохід, сегменти клієнтів, продукти та використання окремих функцій. Частину цих даних компанія вже може збирати у CRM та аналітичних системах. Їх потрібно пов’язати з телеметрією та витратами на AI.
Поєднавши всі три джерела, компанія може порахувати вартість окремої взаємодії з користувачем, маржинальність AI-функції чи прибутковість агентного сценарію. Так можна оцінювати AI-рішення не лише за якістю роботи, а й за тим, чи виправдовують вони свої витрати.
Чому з AI-агентами вимірювання стає ще складнішим
З простими запитами все відносно зрозуміло: один запит користувача → один виклик моделі → одна вартість → один результат.
З AI-агентами ланцюжок стає значно довшим. Щоб виконати одне завдання, агент може:
кілька разів звертатися до різних моделей;
переключатися на резервну модель (fallback), якщо перша не впоралася;
повторювати запит (retry), якщо результат виявився невдалим;
використовувати зовнішні інструменти та API, які теж коштують грошей.
У результаті один запит користувача може спричинити десятки платних операцій у різних провайдерів. А в загальному рахунку складно побачити, скільки насправді коштувало виконання конкретного завдання і на яких етапах виникли найбільші витрати.
Якщо телеметрія не фіксує окремі кроки агента, проблема може стати помітною лише після отримання загального рахунку. На той момент невдалий або надто дорогий сценарій уже може відпрацювати тисячі разів.
Як все ж таки налагодити вимірювання ефективності AI
Знати, які дані потрібні для розрахунку ROI, недостатньо. Бо компанії ще потрібно зрозуміти, як пов’язати витрати з бізнес-результатом на практиці. А якщо AI не приносить дохід напряму — слід визначити, що саме вважати таким результатом і хто всередині команди має відповідати за його вимірювання. Про це ми запитали Павла Лисого, ex-Senior Machine Learning Engineer у Universe Group.
Павло радить починати не з оптимізації вартості моделей, а з аналітики навколо AI. Сама інформація про те, скільки компанія витратила на OpenAI, Anthropic чи власні GPU, майже нічого не говорить про ефективність цих витрат.
«Перше, що треба зробити, — почати логувати кожен AI-запит у розрізі продукту: яка фіча його викликала, який користувач, яка модель, скільки було токенів, скільки це коштувало і який результат ми отримали. Для цього я зазвичай використовую окремий observability-шар на кшталт Langfuse або аналогічні інструменти», — пояснює Павло.
Наступний крок — поєднати ці технічні дані з продуктовою аналітикою. Наприклад, якщо генерація для конкретного користувача коштувала $0,15, важливо простежити, що відбулося далі: він придбав підписку, залишився у продукті чи закрив його через 30 секунд.
Після цього кожну AI-функцію варто розглядати як окремий use case і визначати для неї власну бізнес-метрику. Для support-бота це може бути кількість звернень, закритих без оператора, для генерації контенту — retention або conversion, а для внутрішнього copilot — зекономлений час команди.
«І тільки коли ця система є, можна рахувати ROI. Після цього вже є сенс оптимізувати моделі. Десь потужніші моделі реально потрібні, а десь той самий результат дасть модель у десять разів дешевша. Десь можна кешувати відповіді, десь скоротити контекст, десь взагалі прибрати LLM із частини пайплайна», — додає Павло.
Тобто послідовність така: спочатку відстежити роботу AI, потім пов’язати її з бізнес-метриками, порахувати юніт-економіку і лише після цього оптимізувати витрати. Так бізнес може зрозуміти, скільки отримує з кожного долара, вкладеного в AI.
Окреме питання: що робити, якщо AI-функція не приносить дохід напряму, а, наприклад, скорочує час виконання завдання чи покращує користувацький досвід. Тут, каже Павло, не обов'язково все зводити до прямого revenue — важливіше зрозуміти, яку саме ручну роботу чи проблему AI прибирає:
«У нас є внутрішній AI-інструмент, який допомагає сапорту готувати відповіді клієнтам. До нього оператор у середньому витрачав 8 хвилин на одне звернення, після впровадження AI — 5 хвилин. Це вже конкретна метрика, яку можна виміряти. Далі цей час переводять у гроші: якщо команда обробляє 20 тисяч звернень на місяць і економить по 3 хвилини на кожному, це вже тисяча годин роботи, вартість якої легко порахувати і зіставити з повною вартістю AI — не лише API моделі, а й інфраструктурою, розробкою, підтримкою та observability».
Однак, як наголошує Павло, важливо не зупинятися лише на швидкості: «Якщо оператор почав відповідати швидше, але якість відповідей впала і клієнти почали частіше повертатися з тією самою проблемою, то ми нічого насправді не оптимізували».
Тому оцінювати результат варто за кількома показниками. У випадку із тим-таки сапортом основною метрикою може бути час обробки звернення, а контрольними — якість відповіді, кількість повторних звернень і частка випадків, коли оператору довелося суттєво переписувати відповідь AI.
Логіка та сама і для продуктових AI-фіч: якщо йдеться, наприклад, про AI-пошук, дивитися варто не на прямий дохід, а на те, чи користувач швидше знаходить потрібне, чи частіше завершує потрібну дію, чи повертається в продукт.
«Спочатку треба поставити просте питання: яку поведінку або процес ця AI-функція повинна змінити, — підсумовує Павло. — Потім виміряти цей показник до впровадження і після, бажано через A/B-тест або хоча б на контрольній групі. І вже після цього рахувати, чи варта ця зміна своїх грошей. Бо AI-фіча може взагалі не генерувати revenue напряму. Але якщо вона економить команді сотні годин або помітно покращує ключову продуктову метрику — це цілком нормальний і вимірюваний бізнес-результат».
Ще одне питання: хто всередині компанії має відповідати за всі ці вимірювання? Павло не радить повністю віддавати ROI від AI ні технічній, ні бізнес-команді: «Якщо за нього відповідають усі, дуже часто виходить, що не відповідає ніхто».
За його словами, у кожного AI use case має бути конкретний owner — найчастіше продакт або бізнес-власник процесу. Саме він визначає, якого бізнес-результату компанія хоче отримати та за якою метрикою його оцінювати. Технічна команда відповідає за свою частину: вартість моделей, latency, якість, стабільність, використання токенів та інфраструктури. Тобто має давати прозорі дані про те, скільки насправді коштує AI і наскільки добре він працює.
«А далі ці дві частини треба з'єднати, — пояснює Павло. — Наприклад, AI-команда каже, що фіча коштує $5 тис. на місяць, а продакт показує, що вона економить команді $15 тис. на місяць — ось і перемога».
CTO або AI Lead у цій конфігурації, за словами Павла, відповідає за саму систему вимірювання: щоб діяли єдині правила, був коректний трекінг і AI-проєкти не запускалися без зрозумілої метрики успіху.
Чому власна система вимірювання ROI може стати окремою проблемою
Побудувати власну систему для вимірювання ROI від AI можна. Але що більше AI використовує компанія, то складніше її підтримувати. Великі AI-продукти можуть генерувати мільйони подій телеметрії, які потрібно пов’язувати з витратами та бізнес-результатами. А якщо компанія працює з кількома AI-провайдерами, доводиться ще й враховувати різні формати білінгу та зміни в їхніх API.
Тому таку систему недостатньо один раз налаштувати, бо її потрібно постійно підтримувати. І помилки тут можуть впливати вже на бізнес-рішення: якщо витрати неправильно пов’язані з результатами, компанія ризикує отримати хибну картину ефективності AI.
Саме тому автор матеріалу пропонує ставити питання не лише «чи можемо ми побудувати таку систему самостійно?», а й «чи варто це робити?». Адже час інженерів, витрачений на її створення та підтримку, можна спрямувати на розвиток самих AI-продуктів.
Але чи потрібна компанії, яка лише починає вимірювати ефективність AI, одразу така складна система? І якого мінімуму даних та метрик буде достатньо на старті?
За словами Павла, універсального набору тут немає: кожен AI-сценарій має свої цілі та метрики. Але на старті він не радить збирати десятки показників. Достатньо даних, які допоможуть відповісти на три базові запитання: хто використав AI, скільки це коштувало і який результат компанія отримала.
«На рівні кожного запиту я б збирав модель, кількість токенів, вартість, latency і конкретний use case. Далі додав би одну метрику якості: наприклад, успішність відповіді, оцінку користувача або кількість перегенерацій. І для кожного AI-сценарію обов’язково має бути одна бізнес-метрика: час виконання задачі, conversion, кількість автоматизованих операцій, закритих звернень тощо», — пояснює Павло.
Важливо також мати baseline — показник, з яким компанія порівнюватиме результат.
«На старті необхідний набір — це п’ять метрик: costs, usage, latency, quality і одна бізнес-метрика на use case. Уже цього вистачить, щоб бачити, які сценарії реально дають результат, які коштують занадто дорого і де є сенс щось оптимізувати», — підсумовує Павло.
