Моніторинг та KPI агента ШІ: як вимірювати ефективність

Компанія впроваджує агента ШІ, перші тижні виглядають чудово — кількість звернень до консультантів знижується. Потім з’являється рекламація: агент надав неправильну інформацію про ціну. Потім ще одна: запропонував термін, який був недоступний. Ніхто не помітив, бо ніхто не вимірював нічого, крім факту, що агент «відповідає». Це стандарт для більшості перших впроваджень у Польщі та Центральній Європі.

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

Ефективний моніторинг агента ШІ складається з чотирьох рівнів, які відповідають на різні запитання. Кожен з них є необхідним, жоден не замінює інші.

Операційний рівень є найпростішим технічно (логи HTTP, Prometheus). Рівень якості відповідей є найскладнішим, бо вимагає оцінки, чи відповідь була змістовно хорошою, а не лише «доставленою». Рівень не можна зводити до однієї цифри. Компанія, яка вимірює лише CSAT, не побачить зростання коефіцієнта галюцинацій доти, доки клієнти не перестануть запитувати.

Галюцинації — це відповіді, правильні синтаксично, але помилкові змістовно. У системах RAG їхньою основною причиною є низька релевантність пошуку: модель отримує неправильний фрагмент і на ньому будує відповідь. Тому першим KPI якості є retrieval precision — відсоток запитів, для яких топ-3 фрагменти з векторної бази є змістовно релевантними.

Способи вимірювання retrieval precision:

• Семплінг з оцінкою людиною — щотижня випадково обираються 50-100 пар (запит, відповідь RAG), які оцінюються експертом домену. Релевантність вище 85% — хороший результат для першого етапу.
• LLM-as-judge — друга модель оцінює пару (фрагмент, запит) без генерації відповіді. Ефективний для швидкого сканування великих обсягів, вимагає калібрування на людській вибірці.
• Оцінка кінцевого користувача — thumbs up/down або коротке опитування після обробленої справи. Найпростіший спосіб, але вимірює враження, а не змістовність.

Другий KPI якості — коефіцієнт ескалації — відсоток діалогів, які агент передав людині. Здоровий діапазон — 15–35% для першого вузького впровадження. Нижче 10% варто перевірити, чи правильно працюють guardrails — агент може відповідати там, де має ескалувати. Вище 50% база знань є занадто бідною для покриття запитів.

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

Containment rate — це відсоток справ, закритих агентом без ескалації до людини. Для вузького діапазону (наприклад, лише FAQ та статус) 50–70% — реальна мета через 8 тижнів. Зростаючий containment rate при стабільному або зростаючому CSAT — доказ того, що система дозріває. Зростаючий containment rate при падаючому CSAT — сигнал, що агент закриває справи, які не повинен.

Вартість на оброблену справу (cost-per-case) поєднує вартість токенів (inference), інфраструктури та людського нагляду. Розраховується з телеметрії LLM-роутера: скільки токенів використав кожен запит, помножене на ставку моделі, плюс частка вартості інфраструктури. Порівняйте з вартістю обробки тієї ж справи консультантом. Різниця — ваш реальний фінансовий результат, а не оцінений.

Час до першої відповіді, виміряний за перцентилями p50 та p95. Медіана p50 нижче 3 секунд досяжна для більшості архітектур RAG + LLM. P95 вище 15 секунд сигналізує про вузьке місце (тайм-аут ембедінгу, перевантажений llm-router, відсутність кешу). Клієнти сприймають 3-4 секунди, не сприймають 20.

Хороший моніторинг агента ШІ вимагає трьох компонентів: збору даних у реальному часі, зберігання з відповідним TTL та агрегованого перегляду.

Збір даних вбудовується в LLM-роутер. Кожен виклик логує: timestamp, модель, кількість токенів (input/output), латентність, результат guardrails (pass/block/escalate), ідентифікатор сесії (анонімізований), джерела RAG (ідентифікатори фрагментів, не вміст). Цей лог є фундаментом для всіх подальших метрик.

Зберігання має мати TTL, адаптований до політики RODO — зазвичай 30–90 днів для операційних логів, довше лише для агрегованих метрик без PII. Вміст розмов зберігається окремо і має власний коротший TTL (див. RODO та AI Act).

Рівень агрегації — це Prometheus + Grafana або власний аналітичний скрипт, залежно від масштабу. Для організацій з обсягом до 10 000 запитів на місяць простий дашборд у таблиці з даними з API роутера є достатнім на старті. Вище цього обсягу Prometheus з алертами на аномалії є стандартом.

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

1. Коефіцієнт ескалації вище порогу — якщо протягом години ескалація перевищить, наприклад, 60%, щось пішло не так з базою знань або моделлю. Негайне сповіщення.
2. Латентність p95 вище 10 с — сигнал вузького місця в інфраструктурі, а не якості. Вимагає дослідження стеку, а не даних.
3. Guardrails block rate зріс у 3 рази за 1 годину — сигнал спроби атаки промптами або аномалії у вхідних даних. Вимагає перегляду логів guardrails.
4. Вартість токенів зросла на 50% при сталому обсязі — сигнал зміни поведінки моделі (довші відповіді, більше фрагментів retrieval) або помилки конфігурації.

Алерти не повинні всі надходити до однієї людини. Латентність — це DevOps, guardrails block rate — безпека, коефіцієнт ескалації — власник продукту. Human-oversight має бути закладений в архітектуру з самого початку, а не доданий постфактум.

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

• Дрейф бази знань — документи застаріли (нові ціни, змінені процедури), але векторна база не була переіндексована.
• Дрейф розподілу запитів — клієнти почали запитувати про нові речі, яких база знань не покриває.
• Дрейф моделі — постачальник оновив модель без попередження, поведінка змінилася.

Виявлення дрейфу вимагає регулярного регресійного тесту. Підтримуйте набір із 50–100 запитань із очікуваними відповідями (golden set) і запускайте його щотижня або при кожній зміні бази знань чи версії моделі. Зниження retrieval precision більше ніж на 5 процентних пунктів — сигнал для аудиту. Стаття про RAG та fine-tuning описує, коли погіршення якості вимагає донавчання моделі, а коли достатньо оновлення бази.

Агент ШІ, який обслуговує клієнтів, є системою з AI Act на радарі. Не кожен агент є системою високого ризику, але кожна конверсаційна система повинна відповідати вимозі прозорості: клієнт має знати, що спілкується з ШІ. Лог цієї інформації є частиною аудиторського сліду.

Аудиторський слід для агента ШІ містить мінімум:

• Ідентифікатор сесії (анонімізований або псевдонімізований)
• Версію моделі та конфігурації guardrails, використану в даній сесії
• Результат кожної перевірки guardrails (pass/block/escalate) з timestamp
• Ідентифікатори джерел RAG (не вміст, лише посилання на документ)
• Події handoff до людини з контекстом

Цей лог дозволяє відповісти на запитання інспектора: «Чому агент дав таку відповідь 15 березня?» без відтворення всього стану системи. Для секторів, що підпадають під DPIA (фінанси, охорона здоров’я, HR), вимоги суворіші — огляд деталей у статті про AI Act та RODO 2026.

Опишіть вашу поточну або плановану агентську систему, і модель вкаже, які KPI впровадити в першу чергу та які алерти є критичними для вашого діапазону (playground: PII маскуються, нульове зберігання):

Три цифри, які розуміє кожне керівництво: containment rate (відсоток справ, оброблених без людини), CSAT після обслуговування ШІ порівняно з людським каналом та вартість на оброблену справу. Технічні метрики, як латентність p95 чи retrieval precision, потрапляють до власника продукту або інженерів, а не до звіту для керівництва. Керівництву потрібен тренд цих трьох чисел щомісяця, а не щоденна деталізація.

Мінімальний ритм — раз на два тижні для впроваджень нижче 1 000 запитів на день і щотижня вище цього порогу. Ключовим є підтримка постійного golden set запитань з очікуваними відповідями та автоматичний запуск його при кожній зміні бази знань або версії моделі. Одноразовий аудит впровадження без ритмічних регресійних тестів не захищає від дрейфу. Шаблони роботи з базою знань описує стаття про корпоративний GPT.

Коефіцієнт ескалації вище 40–50% при вузькому діапазоні зазвичай вказує на занадто малу базу знань: агент не знаходить достатньо релевантних відповідей і обережно передає справу людині. Це бажана поведінка з точки зору безпеки, але дорога операційно. Виправлення полягає в розширенні та покращенні якості документів у базі, а не в зниженні порогу ескалації. Оцінку прогалин у базі знань полегшує інструмент finder автоматизації.

AI Act вимагає прозорості (розкриття, що співрозмовник — ШІ), можливості пояснення рішень та повного human-oversight для систем високого ризику. Моніторинг є інструментом виконання цих вимог: аудиторський слід дозволяє відтворити, чому агент повівся певним чином, а алерти на guardrails та ескалації документують, що людський нагляд працює. Відсутність моніторингу — це не лише ризик якості, а й прогалина в документації, яку вимагає регулятор. Деталі обов’язків компаній у 2026 році описує стаття AI Act та RODO.

Залежить від масштабу та того, що у вас вже є. При наявному стеку (Prometheus, Grafana) вартість впровадження — це переважно інженерний час. При впровадженні з нуля для малого обсягу базовий моніторинг (логи JSON, golden set тест, простий дашборд) можна побудувати як частину пілотного проекту без окремої статті бюджету. Вартість зростає при high-availability, складних structured output пайплайнах та аудиті LLM-as-judge на великих обсягах. Реальний кошторис для вашого діапазону згенерує калькулятор ROI. }