Human-in-the-Loop (HITL)(Людина в контурі управління ШІ)

1. Огляд концепції та системна проблема

Повна автономність агентів (Fully Autonomous Agents) стикається з фундаментальним обмеженням: недетермінованістю великих мовних моделей. Навіть якщо модель демонструє точність у 98%, накопичувальна ймовірність помилки у 20-кроковому ланцюжку виконання наближається до 33%. Якщо агент має прямий доступ до системного шеллу, продакшен-баз даних, фінансових API або хмарної інфраструктури, одиничний збій або галюцинація можуть призвести до видалення даних чи багатотисячних збитків.

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

2. Архітектурна таксономія та ментальна модель

Архітектура HITL розділяється на три ключові моделі взаємодії залежно від протоколу та критичності:

┌─────────────────────────────────────────────────────────────┐
│                 HITL INTERACTION TAXONOMY                   │
├─────────────────────────────────────────────────────────────┤
│ 1. Synchronous CLI Gate (Block on STDIN: [y/N] Prompt)      │
│    Локальні інструменти розробника (Claude Code, Cline)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Asynchronous Durable Gate (State Checkpointing / Webhook)│
│    Ланцюжки тривалих процесів (LangGraph, Temporal, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Escalation & Tiered RBAC Policy                          │
│    • Read-only ➔ Auto-approved (Рівень 0)                   │
│    • Local Mutate ➔ Dev approved (Рівень 1)                 │
│    • Production / Money ➔ Lead / Multi-sig approved (Рівень 2)│
└─────────────────────────────────────────────────────────────┘

1. Синхронний локальний бар'єр (Synchronous Approval):
   • Використовується в CLI-агентах та IDE. Агент блокує потік виконання, виводить у консоль плановану shell-команду чи diff і очікує натискання клавіші користувачем.
2. Асинхронний довготривалий бар'єр (Durable Asynchronous Gate):
   • Використовується в бекенд-агентах. При досягненні критичної точки агент зберігає свій робочий стан у базу даних (Checkpointer), генерує подію (наприклад, повідомлення в Slack або email із кнопками «Схвалити» / «Відхилити») і засинає.
3. Гранульована матриця дозволів (Tiered Action Policies):
   • Дії класифікуються за рівнем потенційного ризику (Blast Radius). Безпечні операції не потребують схвалення, тоді як незворотні операції вимагають багаторівневого підтвердження.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл асинхронного процесу з участю людини (на прикладі LangGraph):

1. Виконання кроків до контрольної точки: Агент аналізує запит, формує план і виконує підготовчі обчислення (наприклад, генерує SQL-запит на міграцію даних).
2. Перехоплення інструменту (Tool Interceptor): Шар безпеки перевіряє виклик: якщо викликається інструмент execute_production_migration, спрацьовує переривання interrupt().
3. Серіалізація та збереження стану (State Persisting): Поточний граф пам'яті, історія повідомлень та аргументи виклику інструменту фіксуються в сховищі станів.
4. Маршрутизація до оператора: Сервіс відправляє інтерактивне повідомлення в командний Slack-канал із описом змін і кнопками підтвердження.
5. Людська ревізія та модифікація: Інженер може:
   • Схвалити: передати сигнал відновлення виконання.
   • Відхилити: перервати сесію та зафіксувати причину відмови.
   • Скоригувати (Human-in-the-Edit): відредагувати параметри (наприклад, зменшити batch size запиту) перед виконанням.
6. Відновлення виконання (Resume Thread): Движок завантажує стан із БД, застосовує рішення інженера і продовжує автономний цикл.

4. Практичні інженерні сценарії в продакшені

01. Контроль небезпечних SQL-міграцій на живій базі

Агент аналізує нову функціональність і пропонує зміну схеми PostgreSQL:

• Замість прямого виконання ALTER TABLE users ADD COLUMN status text NOT NULL агент виставляє запит на погодження.
• DBA бачить, що додавання колонки без дефолту на таблиці в 20 млн рядків заблокує читання. Інженер коригує команду на створення поля з DEFAULT через безпечний міграційний патерн і схвалює виконання.

02. Схвалення видалення хмарних ресурсів для оптимізації витрат

FinOps-агент здійснює аудит AWS-інфраструктури:

• Знаходить 14 невикористовуваних RDS-інстансів та дисків EBS, що накопичують витрати $2,000 на місяць.
• Агент не видаляє їх самостійно, а надсилає структурований звіт техліду в корпоративний месенджер із посиланням на кожен ресурс. Лікар або техлід натискає «Terminate All», після чого агент виконує очищення.

03. Генерація персоналізованих юридичних або комплаєнс-відповідей

ШІ формує відповіді на запити користувачів щодо видалення персональних даних (GDPR Right to be Forgotten):

• Агент знаходить усі зв'язані сутності в сервісах, формує скрипт видалення та готує офіційний лист клієнту.
• Співробітник відділу безпеки перевіряє правильність складання документів перед відправкою.

5. Підводні камені, типові помилки та безпека

• Втома від погоджень (Approval Fatigue): Якщо агент запитує підтвердження на кожен дрібний крок (наприклад, читання кожного окремого файлу), розробник перестає вчитуватися і автоматично погоджує всі запити. Налаштовуйте розумні пороги чутливості.
• Вразливість підміни наміру через Prompt Injection: Якщо агент обробляє неперевірені зовнішні дані (наприклад, текст із веб-сторінки), зловмисник може змусити модель сформулювати оманливий опис дії для оператора («Це безпечне оновлення кешу», хоча під капотом виконується крадіжка токенів).
• Втрата транзакційності при таймаутах: Якщо потік завис в очікуванні відповіді людини на кілька годин або днів, відкриті транзакції в базах даних або тимчасові токени доступу можуть протухнути, спричинивши збій системи після повернення людини.
• Відсутність журналу аудиту (Audit Logging): Кожне рішення людини про схвалення чи відхилення дії агента повинно обов'язково протоколюватися в захищеному журналі з прив'язкою до ID користувача для забезпечення прозорості та розслідування інцидентів.