Human-in-the-Loop для AI-агентів: налаштування контролю зі зворотним зв'язком

Human-in-the-Loop: де ламається автономний агент

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

Щойно агенту видають робочий доступ, Human-in-the-Loop стає єдиним бар'єром між помилковою дією агента та незворотним наслідком.

Ламається це в передбачуваних місцях. Необоротна дія — масове злиття дублікатів у клієнтській базі, видалення гілки, підтверджене повернення або зміна прав доступу: відкотити таке можна тільки з резервної копії, і то не завжди.

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

За розборами інцидентів в AI Incident Database видно, що шкоду завдає не слабка модель, а відсутність точки підтвердження перед необоротним кроком.

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

Усе інше потрапляє в журнал і аналізується постфактум — за трасуванням видно, на якому кроці агент відійшов від початкової задачі.

Що дає контур контролю зі зворотним зв'язком

Контур Human-in-the-Loop — це не перевірка заради перевірки, а набір контрольних точок, де рішення агента підтверджує або відхиляє оператор. Зворотний зв'язок оператора не губиться: кожне підтвердження й правка потрапляють у журнал і повертаються в правила агента. Нижче — чотири ефекти, за якими видно, що контур працює.

Частка помилкових дій

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

На повторюваних сценаріях частка невірних кроків падає не на відсотки, а в рази, і падіння утримується, а не відкочується через тиждень.

Час реакції на інцидент

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

Клас усунених відмов

Контур закриває не всі збої, а цілком визначені: необоротні дії — надсилання, видалення, запис у зовнішню систему, — а також вихід за ліміти та неоднозначні випадки, де агент не впевнений. Саме цей клас відмов коштує найдорожче під час розбору, і саме його знімає підтвердження оператора.

Навантаження на оператора

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

У міру накопичення правок поріг підвищується, а потік на оператора знижується — контроль залишається, ручна робота зникає.

Режими контролю: порівняння підходів та обмежень

Контроль над AI-агентом — це не «увімкнути галочку», а вибрати точку, де людина в контурі (Human-in-the-Loop) справді потрібна. Занадто жорсткий режим зупиняє потік на діях, які агент виконує безпомилково; занадто м'який — пропускає помилку в необоротну операцію.

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

Чотири режими контролю на одному агенті

Режими не взаємовиключні: типовий сценарій — повна автоматизація на підготовці даних, поріг впевненості на узгодженні та ручне підтвердження на необоротному кроці.

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

Етапи впровадження контролю зі зворотним зв'язком

Контур зі зворотним зв'язком не вмикають «на всяк випадок» — його ставлять у конкретні точки, де помилка моделі дорожча за затримку на відповідь.

Порядок робіт при цьому однаковий: спочатку розбираємо маршрут рішень, потім розставляємо перевірки і тільки потім виводимо Human-in-the-Loop на реальне навантаження. Нижче — як виглядає впровадження контролю в проєкті.

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

2. Схема контрольних точок. Для кожної точки визначаємо тип перевірки: підтвердження до дії, перевірка результату після або вибірковий контроль частки запитів. Частину кроків залишаємо повністю автоматичною — контроль потрібен там, де він змінює результат.

3. Правила та схема ескалації. Прописуємо умови передачі оператору: низька впевненість моделі, конфлікт із бізнес-правилом, запит вище заданого порогу. Фіксуємо, що бачить оператор, скільки часу в нього на реакцію і що відбувається із завданням, якщо відповіді немає.

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

5. Передача та навчання операторів. Проводимо розбір спірних кейсів із тіньового запуску, даємо інструкцію щодо типових ситуацій і регламент дій у разі збою, призначаємо відповідального за перегляд правил.

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

Артефакти: схеми потоку, політики, регламенти

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

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

Мінімальний комплект, який ми передаємо разом із рішенням:

• Схема потоку рішень — де агент діє сам, де обов'язкове підтвердження оператора, які гілки зупиняються. За нею логіка відновлюється без читання коду.
• Політики доступу операторів — хто підтверджує, хто може скасувати рішення, хто бачить чутливі дані і на який строк видані права. Доступ відкликається при зміні співробітника.
• Регламент ескалації — пороги впевненості, таймаути очікування, поведінка при недоступності оператора: зупинка й передача далі, а не здогад моделі.
• Журнал рішень — на кожен запуск вхід, версія конфігурації, вердикт і той, хто його підтвердив. Вивантажується для розбору і слугує доказовою базою.
• Правила зворотного зв'язку — як правки оператора перетворюються на розмічені приклади, що йде на донавчання, а що достатньо виправити в правилах.
• Регламент розбору інцидентів — класифікація відмов, строки реакції, порядок відкату на попередню версію агента і критерії зупинки потоку.
• Інструкції оператору та документація передачі — типові сценарії, спірні випадки, точки моніторингу та метрики якості в одному місці.

Кейс: як прибрали цілий клас відмов агента

Контур підтримки працював у повному автозапуску: агент сам відповідав клієнту, змінював статус замовлення й ініціював повернення.

Логи писалися, але зв'язку між кроком агента та наслідком у системі не було — помилки спливали постфактум, у середньому через 40 хвилин і вже у вигляді звернення клієнта.

Частка дій, що вимагали ручного відкату, сягала 18% у пікові зміни, а критичні помилки — неправильно знятий статус, зайве повернення — траплялися 6–8 разів на тиждень.

Що змінили

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

Це і є Human-in-the-Loop у робочому вигляді, а оркестрацію переривань і збереження стану зібрали на LangGraph — завдання не губиться, якщо оператор повернеться до нього пізніше.

Що стало

Під підтвердження пішли саме необоротні дії, решту агент робить сам: частка відкатів упала з 18% до 2%. Критичні помилки припинилися не тому, що модель стала розумнішою, а тому, що жодна необоротна дія не проходить без оператора — за квартал спостережень жодної.

Медіанний час до втручання скоротився з 40 хвилин до 90 секунд, і метрики підтверджені на двох незалежних потоках: клієнтська підтримка та обробка повернень.

Чим Human-контур відрізняється від повної автоматизації?

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

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

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

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

Якщо дія необоротна, поріг підвищується до обов'язкового підтвердження за будь-якого значення — автоматика тут просто не отримує права на виконання.

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

Усі рішення потрапляють у журнал аудиту: видно, хто підтвердив дію і на яких підставах, що важливо під час розбору інцидентів і перевірок.

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

Технічні сумніви перед впровадженням

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

Чи не стане оператор вузьким місцем?

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

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

Що робити, якщо черговий недоступний?

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

Доступи до розбору видають кільком співробітникам — єдина точка відмови на одному черговому неприпустима.

З чого починати поетапне розширення контролю?

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

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

Обговоримо задачу й повернемося з оцінкою та планом

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

Щоб повернутися з оцінкою та планом впровадження, а не з уточнювальними питаннями, до першої розмови корисно додати таке.

• Сценарій і точки контролю: які дії агента потребують підтвердження, правки або відхилення і що відбувається в разі відмови.
• Приклади даних: 20–50 реальних запитів і відповідей агента, включно з невдалими — на них налаштовується контур зі зворотним зв'язком (Human-in-the-Loop).
• Логи звернень за 2–4 тижні та метрики: частка рішень, що пішли на перевірку, час реакції перевіряльного, повторювані класи помилок.
• Регламент: хто уповноважений підтверджувати, що вважається критичною помилкою, хто розбирає інцидент і в який строк.
• Карта інтеграцій: системи, з якими обмінюється рішення, — черга заявок, облікова система, база знань, шлюз повідомлень.
• Доступи: тестовий контур і облікові записи з мінімально потрібними правами — інженери відтворюють сценарій повністю, не торкаючись робочих даних.
• Обмеження: де дозволено обробляти запити, строки зберігання, обов'язкові перевірки та склад журналу дій.

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