Контроль якості AI-агентів: де ламається процес
Агент, який впевнено відповідає на демо, ламається на десятому реальному запиті. Перша точка відмови — нестабільність: на два однакових звернення модель видає різні структури, втрачає обов’язкові поля й по-різному тлумачить одну й ту саму інструкцію.
У робочому контурі таке розходження перетворюється на інцидент: клієнт отримує неправильну відповідь, оператор — зайву ручну правку, підтримка — розбір.
Друга точка — деградація після оновлення моделі. Зміна ваг, контексту або системної інструкції змінює поведінку на крайових сценаріях, тоді як базові відповіді виглядають як раніше. Без зафіксованих еталонів регрес помічають через тижні — за накопиченою статистикою відмов.
Третя — немає відтворюваних еталонів, і відтворюваність відповідей агента перевірити нічим. Розмітка еталонних діалогів фіксує очікувані кроки, допустимі варіації формулювань і критерії відмови: розмова «здається, стало гірше» перетворюється на перевірюване порівняння.
Контроль якості AI-агентів тримається на прогоні таких наборів до викладки, а не на вибірковому перегляді журналів.
Четверта — помилки в робочому контурі, де агент працює з реальними даними, інтеграціями й правом на дію. Тут ціна помилки вища, ніж у чаті: неправильний виклик залишається в системі.
Розбираємо, як це закривається — які еталони збираємо, як ловимо регрес і як вбудовуємо перевірки у викладку.
Як вимірюємо поведінку агентів: метрики та еталонні набори
Поки якість агента оцінюють на кількох показових прикладах, висновки тримаються на враженні. Ми фіксуємо еталонний набір запитів — реальні звернення з логів продукту, розмічені вручну: типові сценарії, рідкісні формулювання та пограничні випадки, де агент помиляється найчастіше.
Набір версіонується разом із промптами, тому ітерації порівнюються на одних і тих самих даних, а зростання метрики не можна пояснити «вдалою» новою вибіркою.
Правила розмітки описуємо до першого прогону: що вважаємо коректною відповіддю, де допустиме інше формулювання, як розбирати спірні випадки. Два розмітники проходять вибірку незалежно, розходження знімає арбітр — еталон не «пливе» від настрою перевіряючого.
Розрахунок метрик автоматизовано на LangSmith: ручний прогін потрібен лише при оновленні самого набору.
Чек-ліст, за яким агент допускається в продукт:
- Частка коректних відповідей — базова метрика: скільки запитів еталонного набору закрито правильно. Дивимося не лише середнє, а й зріз за групами: типові, рідкісні, пограничні.
- Стійкість поведінки — один і той самий запит проганяємо багаторазово. Якщо сенс відповіді змінюється від запуску до запуску, агент не готовий до продакшену навіть за високої середньої частки коректних.
- Опора на джерело — у відповіді немає вигаданих фактів і посилань на дані, яких агент не отримував.
- Коректна відмова — поза своєю областю агент відмовляється від завдання, а не видає впевнену неправильну відповідь.
- Стабільність розмітки — вибірку періодично перерозмічують наосліп: збільшене розходження означає, що еталон застарів і його пора оновлювати.
Метрики знімаються на кожній ітерації до релізу, тому регрес видно в цифрах раніше, ніж його помітить користувач.
Порівняння режимів перевірки агентів: прогони, розмітка, гібрид
Режим перевірки вибирають не за зручністю, а за класом помилок, який потрібно зловити. Автоматичні прогони на еталонному наборі сценаріїв закривають регрес: повторювані збої ловляться одразу після кожної зміни промпту, моделі або логіки виклику інструментів.
Чого прогони не бачать — нових формулювань, неоднозначних запитів і помилок тону, для яких еталону ще немає.
Ручна експертиза дає розбір там, де критерій «правильно» потребує людини: спірні теми, якість джерел, зв’язність багатокрокової відповіді.
Її обмеження — трудомісткість і розбіг оцінок між експертами: без протоколу розмітки й калібрування оцінки з одного й того самого діалогу розходяться. Гібридна схема знімає це, розподіляючи потік за рівнем ризику.
| Режим | Коли підходить | Що дає | Обмеження |
|---|---|---|---|
| Автоматичні прогони | Є еталонні відповіді та метрики, сценарії повторюються | Перевірка на кожному релізі, відтворюваність, раннє виявлення регресу | Ловить лише те, що вже описано в перевірках; не оцінює сенс і тон |
| Ручна експертиза | Нові напрями, спірні теми, розмітка еталону | Глибина: розбір логіки, оцінка джерел, формування еталону | Трудомісткість експертів, розходження оцінок, не масштабується на весь потік |
| Гібридна схема перевірки | Агенти в проді, потік звернень зростає | Автоматика покриває весь потік, експертиза — вибірку за ризиком і новими кейсами | Потрібні розмітка й налаштування відбору вибірки, інакше схема не працює |
Вибір режиму контролю — не разове рішення: у міру накопичення розібраних збоїв ручні кейси переводяться в автоматичні перевірки, а час експертів іде на розмітку наступного шару.
Етапи впровадження: від аудиту поточних перевірок до передачі
Порядок етапів фіксуємо до старту: кожен закривається артефактом, який можна перевірити, а не звітом про роботу. Ітерації всередині етапу нормальні, але перехід до наступного — лише після того, як результат прийнято обома сторонами.
- Аудит поточних перевірок. Розбираємо, що вже працює: ручні розбори, журнали, метрики, спірні випадки. Рахуємо, яку частку відхилень ловлять зараз і де автоперевірка розходиться з рішенням людини.
- Схема контролю якості. Визначаємо метрики та розкладку за ними: автоматичні перевірки, вибірковий ручний розбір, ескалація. Фіксуємо пороги й правила зупинки прогону, щоб результат не залежав від настрою чергового.
- Налаштування прогонів. Збираємо еталонні набори, розмічуємо пограничні випадки, проганяємо на історичних даних і калібруємо пороги. На виході — відтворюваний прогін: ті самі вхідні дані дають той самий вердикт.
- Пробний прогін. Запускаємо в тіньовому режимі поруч із поточним контролем і звіряємо вердикти. Розходження розбираємо: частину закриваємо правкою правил, частину — донавчанням на спірних прикладах.
- Приймання системи. Ідемо за критеріями, узгодженими заздалегідь: частка впійманих відхилень, рівень хибних спрацювань, час розбору одного випадку.
- Передача документації. Віддаємо регламенти, описи метрик, інструкції для чергових, порядок оновлення еталонних наборів і доступи. Далі супроводжуємо в узгодженому режимі, поки команда не вийде на самостійний цикл.
Що залишається у вас: конфігурації, схеми та регламенти перевірок
Ми передаємо не звіт про виконану роботу, а робочу систему перевірок, яку ваша команда веде далі без нас.
Усі артефакти лежать у вашому репозиторії в текстовому вигляді, проходять рев’ю та версіонуються разом із кодом агентів — правка порогу або правила не потребує перезбирання всієї системи.
- Конфігурації перевірок — де задані пороги, умови зупинки випуску та правила порівняння версій агента. Змінюються в одному місці, застосовуються до всіх потоків одразу.
- Схеми потоків даних — шлях від запиту користувача до вердикту перевіряючого: де зберігаються відповіді, де еталон, на якому кроці підключається ручний розбір.
- Регламент розмітки — що вважати правильною відповіддю, як розв’язувати спірні випадки та скільки перевіряючих дивиться одну вибірку. Без нього частка згоди між розмітниками падає вже на другому тижні.
- Еталонні набори — фіксовані приклади з узгодженими оцінками. На них відтворювано порівнюються версії: видно, що покращилося, а що деградувало.
- Документація з метрик — як рахується кожна величина, звідки беруться дані та яке відхилення вважається спрацюванням, а не шумом.
- Інструкції для команди — що робить перевіряючий при розходженні, хто має право змінювати правило й куди записується виняток.
- Журнал інцидентів і порядок розбору — випадки, коли перевірка пропустила помилку, розбираються й перетворюються на нове правило або приклад у еталонному наборі.
- Порядок випуску нової версії — прогін на еталонному наборі, допуск за метриками, порядок відкату на попередню конфігурацію.
Новий інженер входить у роботу за цими документами, а не за пам’яттю попередньої команди. Це і є перевірка зрілості: якщо систему перевірок не можна передати, вона тримається на людях, а не на процесі.
Кейс: частка помилок агентів до і після регресійних прогонів
До нас прийшов замовник з асистентом першої лінії: агент відповідав на питання щодо замовлень, термінів і повернень. На стартових вимірюваннях частка відповідей, що збіглися з еталоном, трималася близько 78%, решту оператори розбирали вручну.
Помилка була плаваючою — те саме питання в різному формулюванні отримувало різну відповідь, і за логами це виглядало як шум, а не як закономірність.
Що показали вимірювання до впровадження
Ми розмітили потік звернень за класами й побачили, що більше половини розходжень — одна причина: агент підставляв загальний термін повернення, ігноруючи категорію товару. Друга група — обрив на уточненні: агент не запитував номер замовлення й ішов у здогад замість питання.
Траси та зрізи метрик збирали в Langfuse, щоб кожне розходження можна було розібрати до конкретного кроку діалогу.
Що змінили і що вийшло
Зібрали 240 еталонних сценаріїв — за кожним еталонна відповідь і формальні критерії зарахування. Регресійний прогін запускається на кожну зміну інструкції агенту й набору правил, триває близько 12 хвилин і блокує викладку, якщо частка зарахувань падає нижче порогу. Окремо додали обов’язковий крок уточнення: агент не відповідає, поки не отримав номер замовлення.
Частка коректних відповідей зросла з 78% до 94%, а клас «неправильний термін повернення» зник повністю — 0 попадань на 240 сценаріїв і 0 у потоці звернень за наступний місяць. Покриття гілок діалогу довели до повного за розміткою, обрив на уточненні перестав відтворюватися.
Регресійні прогони не скасовують помилки назавжди: нова інструкція може зламати сусідній сценарій. Але тепер такий відкат видно до викладки, а не в скарзі клієнта.
Чим тіньовий прогін відрізняється від регресійного тесту?
Це два різних інструменти перевірки, і плутати їх дорого. Тіньовий прогін запускає нову версію агента поруч із поточною на живому потоці запитів: відповіді не йдуть користувачеві, але фіксується, як модель відповіла б у реальній ситуації.
Регресійний тест працює на фіксованому наборі сценаріїв із заздалегідь відомими еталонними відповідями.
Тіньовий прогін ловить те, чого немає в жодному підготовленому наборі: нові формулювання, зсув тематики, рідкісні, але регулярні типи запитів. Плата за це — відсутність еталону: вердикт доводиться виводити з розходження з відповідями бойової версії та розмітки вибірки інженером.
Регресійний тест сильний іншим: він відтворюваний і дешевий у прогоні. Один і той самий фіксований набір проганяється після зміни моделі, промпту або ланцюжка викликів — і будь-який зсув видно одразу, з точністю до конкретного сценарію, який зламався.
Порівняння режимів зводиться до трьох питань: чи є в нас еталон, чи потрібна повторюваність і що ми перевіряємо — відомі вимоги чи невідомі ризики. Тіньовий прогін закриває друге, регресія — перше; вони не замінюють одне одного.
Тому регресія йде на кожен випуск, а тіньовий прогін — за розкладом і після великих змін. Усе, що тіньова перевірка знайшла вперше, перетворюється на новий сценарій фіксованого набору: покриття зростає, а старі дефекти не повертаються.
Часті технічні сумніви перед стартом робіт
Перед стартом інженерні команди ставлять одні й ті самі питання: чи впишеться шар контролю якості у вже розгорнутий контур, чи вистачить закритого периметра й де взяти дані для перевірок. Нижче — чотири технічні сумніви, які найчастіше гальмують рішення про початок робіт.
У нас своя модель — її доведеться міняти?
Оцінка будується поверх моделі, а не замість неї: відповіді проходять через спільний інтерфейс виклику й перевіряються за правилами та еталонними прикладами.
Ваша модель залишається робочою, доповнення стосуються лише набору перевірок — від формату відповіді до повноти розв’язання задачі.
Доступ до інфраструктури обмежений, стенд закритий
Тоді перевірки розгортаються всередині вашого периметра, а назовні йдуть лише знеособлені метрики — без запитів і відповідей. Якщо й це неприйнятно, передаємо конфігурації та схеми, а запуск і оновлення виконує ваша команда за описом.
У нас уже розгорнутий контур — не зламаєте?
Ми вбудовуємося окремим шаром оцінки й не чіпаємо маршрутизацію, зберігання та логіку обробки запитів. Такий шар вимикається одним налаштуванням, тому відкат до попередньої поведінки займає хвилини й не потребує перезбирання всього контуру.
Розмітки немає — збирати еталони з нуля?
Стартуємо на формальних правилах і згоді кількох моделей між собою, а еталонний набір нарощуємо на спірних випадках по ходу роботи. Ваші фахівці розмічують лише ті відповіді, де автоматика не дає однозначного рішення — зазвичай це мала частка від загального потоку.
Обговоримо вашу задачу й повернемося з оцінкою та планом
Перший крок — не комерційна пропозиція, а розбір задачі. Ми дивимося, які агенти й моделі вже в роботі, як влаштований потік звернень і де саме втрачається якість відповідей.
Цього достатньо, щоб повернутися з оцінкою обсягу робіт і планом впровадження: етапи, контрольні точки, зона відповідальності з обох сторін. Рішення про старт ви ухвалюєте після оцінки — обсяг заздалегідь не фіксуємо.
Щоб оцінка була по суті, а не «за відчуттями», потрібен мінімальний набір ввідних:
- Задача й контекст: що вже автоматизовано, скільки звернень на добу проходить через AI-агентів, які помилки вважаєте неприпустимими.
- Дані для перевірки: вивантаження діалогів за період, еталонні відповіді, якщо є — журнал правок операторів після автовідповідей.
- Доступи: до середовища, де працюють агенти, до журналів і до черги звернень — на читання достатньо, міняти нічого не потрібно.
- Критерії якості: як формулюєте «хорошу» відповідь і які теми обов’язково мають іти на перевірку людині.
- Обмеження: вимоги до зберігання даних, розподіл доступу, ізоляція контурів, заборона на винесення чутливих відомостей.
- Оцінка обсягу: на цій базі рахуємо число сценаріїв, частку відповідей під автоматичну перевірку й трудовитрати на розмітку.
Далі збираємо план впровадження: пілот на одному сценарії, вимірювання метрик до і після, розширення за результатом. Опишіть задачу — повернемося з оцінкою та планом, старт робіт призначимо у зручному для вас темпі.
