Deskhero
Українська
Спробувати безкоштовно

← Back to articles

ШІ з участю людини: як працює та коли його використовувати

ШІ з участю людини: як працює та коли його використовувати

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

У цій статті пояснюється, як працює HITL, де він допомагає і що командам потрібно спроєктувати перед використанням у виробничому середовищі.

Зміст

Як насправді працює ШІ із залученням людини?

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

Команда перевіряє людські контрольні точки в системі ШІ

Люди зазвичай беруть участь на двох етапах:

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

HITL під час виконання додає перевірку в процес роботи розгорнутої системи. Система може призупинитися перед чутливою дією, як-от надсиланням повідомлення або зміною запису, і попросити людину схвалити, відредагувати чи відхилити запропоновану дію. У документації LangChain HITL описано проміжне програмне забезпечення, яке може переривати вибрані виклики інструментів, зберігати стан і відновлювати роботу після рішення перевіряльника.

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

Практичний процес може містити:

  • Анотувати дані або результати моделі людськими мітками
  • Навчити або оцінити модель за допомогою перевірених прикладів
  • Розгорнути модель або робочий процес ШІ
  • Перервати процес перед вибраними діями з високим ризиком
  • Ухвалити рішення — схвалити, відредагувати, відхилити або іншим чином відреагувати
  • Зафіксувати рішення як структурований операційний зворотний зв’язок

Синхронні шлюзи зупиняють відповідний робочий процес, доки не відреагує перевіряльник. Асинхронні конструкції можуть дозволити іншій роботі тривати, поки рішення очікується. У будь-якому разі довготривалі робочі процеси потребують надійного збереження стану. Документація середовища виконання inference.sh — один із прикладів системи, що описує шлюзи схвалення та постійне виконання саме для цієї мети.

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

Інфографіка з етапами процесу ШІ із залученням людини

Чому HITL важливий: точність, безпека та довіра

Людський контроль може покращити робочий процес ШІ у три практичні способи.

Краще опрацювання нестандартних випадків. Моделі можуть мати труднощі з незвичними вхідними даними або змінними умовами. Перевіряльник може розпізнати виняток і виправити запропонований результат. Якщо виправлення належно зафіксувати та врегулювати, згодом воно може допомогти в оцінюванні або вдосконаленні моделі. Виправлення не покращує модель автоматично; команді все одно потрібен продуманий конвеєр зворотного зв’язку.

Безпечніші дії. Система ШІ, здатна надсилати повідомлення, оновлювати записи або обробляти транзакції, може завдати шкоди, якщо неправильно витлумачить вхідні дані. Шлюз перевірки може зменшити цей ризик, зупиняючи вибрані дії до їх виконання. Databricks розглядає людську перевірку рішень із більшим впливом і цінність повернення зворотного зв’язку в систему.

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

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

Де застосовують HITL: приклади з реального світу

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

Рентгенолог перевіряє медичні зображення, позначені ШІ

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

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

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

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

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

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

Як спроєктувати виробничу HITL-систему?

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

Надійне виконання та збереження стану

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

Шаблони шлюзів схвалення

Тип шлюзу Коли використовувати Компроміс
Схвалення для кожного інструмента Вибрані чутливі дії Точний контроль; більше налаштувань
Глобальне схвалення Кожна дія в робочому процесі з жорстким контролем Проста політика; може створити велику чергу перевірок
Умовне схвалення Перевірка залежно від суми, одержувача або сигналу ризику Вибірковість; потребує протестованої логіки правил
Впорядкована черга перевірки Кілька залежних рішень в одному запуску Зберігає послідовність; може збільшити затримку

Маршрутизація та ескалація

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

Журнали аудиту та інтерфейс перевіряльника

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

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

Для передавання чат-бота людині зберігайте контекст розмови, фіксуйте причину зупинки автоматизації та спрямовуйте отриманий запит відповідному Користувачеві або в потрібну чергу.

HITL проти Human-on-the-Loop і Human-over-the-Loop

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

Термін Типовий момент Роль людини Зазвичай блокує виконання? Поширене застосування
Human-in-the-loop (HITL) Перед або під час вибраного рішення Надає ввід, схвалення або виправлення Часто Рішення з вищим ризиком і зворотний зв’язок для навчання
Human-on-the-loop (HOTL) Під час роботи Здійснює моніторинг і може втрутитися Зазвичай ні Активність із більшим обсягом і можливістю легшого скасування
Human-over-the-loop Упродовж життєвого циклу системи Встановлює політику та перевіряє результати Ні Управління та контроль на рівні системи

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

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

Визначити потрібний підхід допоможуть такі запитання:

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

Які реальні виклики масштабування HITL?

HITL створює витрати та сценарії відмов, які слід врахувати під час проєктування.

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

Упередженість і корельовані помилки. Модель, навчена на людських виправленнях, може успадкувати людські упередження. Перевіряльник також може надто легко покластися на модель, яка виглядає впевненою. Дослідження узгодженості та взаємодоповнюваності в командах людина—ШІ аналізують, коли модель має відповідати людським уподобанням, а коли різні сильні сторони можуть покращити роботу команди. Різноманітна перевірка, калібрування та перевірки узгодженості можуть допомогти виявити систематичні відмінності.

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

Втома та непослідовність людей. Повторювані перевірки можуть призводити до поспішних рішень і зміни стандартів. Корисні заходи контролю включають:

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

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

Практичний контрольний список для розгортання HITL-систем

Перед розгортанням HITL-робочого процесу послідовно опрацюйте ці запитання.

  1. Оцінювання ризиків. Перелічіть дії, які може виконувати система. Класифікуйте їх за впливом, можливістю скасування та вимогами до відповідальності.
  2. Визначення перевіряльників. Визначте, хто може перевіряти кожну дію та які інформація й повноваження їм потрібні.
  3. Проєктування інтерфейсу. Покажіть достатньо контексту для реального рішення. Визначте шляхи схвалення, редагування, відхилення та ескалації, якщо вони застосовні.
  4. Стратегія збереження. Зберігайте стан, потрібний для безпечного відновлення, і тестуйте перезапуски та дубльовані рішення.
  5. План зворотного зв’язку. Вирішіть, чи призначені записи перевірки для аудиту, оцінювання, повторного навчання або їх поєднання. Не припускайте, що вони підходять для кожної мети.
  6. Управління. Призначте відповідальних за якість перевірки, доступ, зберігання, правила маршрутизації та зміни контролю.

Корисні показники можуть включати:

  • Частка перевірок: частка відповідних дій, надісланих на перевірку
  • Час до рішення: затримка від переривання до завершення перевірки
  • Розподіл рішень: частка схвалених, відредагованих, відхилених або ескальованих рішень
  • Наслідки помилок: проблеми, виявлені перевіркою, і ті, що залишилися непоміченими попри неї
  • Узгодженість перевіряльників: послідовність на вибіркових випадках, де порівняння має сенс

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

Що сучасні дослідження говорять про майбутнє HITL?

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

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

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

Варто оцінювати такі підходи:

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

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

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

Ключові висновки

ШІ із залученням людини найцінніший, коли людське рішення пов’язане з чітким ризиком, підтримане корисним контекстом і зафіксоване для визначеної мети.

Пункт Деталі
HITL може підтримувати навчання та контроль під час виконання Людський ввід може маркувати дані, оцінювати результати або блокувати вибрані дії.
Маршрутизація на основі ризику допомагає контролювати витрати Зосередьте блокувальну перевірку на діях, вплив яких виправдовує затримку та витрачені зусилля.
Надійне збереження стану підтримує безперебійні переривання Виробничий робочий процес має витримувати перезапуски та тривалі затримки перевірки.
Реальні повноваження мають значення Перевіряльникам потрібні контекст, час і можливість змінити або зупинити результат.
Deskhero забезпечує контроль автоматичних функцій підтримки Його чат-бот і автоматичні відповіді ШІ використовують схвалений загальнодоступний контент FAQ, є функціями за згодою та передають запитання без відповіді людям.

Що більшість команд неправильно розуміє про HITL

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

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

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

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

Deskhero ставить людський контроль у центр підтримки на основі ШІ

Deskhero застосовує кілька принципів людського контролю в підтримці клієнтів. Він може готувати чернетки відповідей для перевірки Користувачами. Його клієнтський чат-бот і автоматичні відповіді ШІ відповідають лише на основі схваленого загальнодоступного FAQ робочого простору. Обидві автоматичні функції активуються за згодою, а автоматичні дії позначаються та записуються в журнал.

Deskhero

Deskhero пропонує записи FAQ на основі вирішених звернень і сторінок, отриманих із вебсайтів. Користувач перевіряє, редагує, схвалює або відхиляє кожну пропозицію, перш ніж вона стане загальнодоступною. Для роботи чат-бота потрібно щонайменше 100 схвалених загальнодоступних елементів FAQ. Якщо він не може відповісти, система перемикається на форму, щоб людина могла продовжити розмову електронною поштою.

Для команд електронної комерції інтеграція Shopify використовує доступ лише для читання, щоб показувати інформацію про клієнта та замовлення всередині звернення. Deskhero також пропонує двосторонні підключення поштових скриньок для Gmail, Google Workspace і Microsoft 365, тож команди можуть зберегти наявну електронну адресу.

Ви можете почати 30-денний безкоштовний пробний період без кредитної картки.

Корисні джерела

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

Джерело Що охоплює
Документація LangChain HITL Переривання, рішення під час перевірки, збереження та налаштування схвалення для конкретних інструментів
Документація inference.sh HITL Шлюзи схвалення та надійне виконання в середовищі виконання
Databricks про системи із залученням людини Людський зворотний зв’язок, маршрутизація та операційний дизайн
IBM: Що таке human-in-the-loop? Визначення, поширені способи використання та міркування для підприємств
Stanford HAI: Що таке human-in-the-loop? Людський контроль і підхід, орієнтований на людей, які контролюють процес
Stanford HAI: Люди в циклі — дизайн інтерактивних систем ШІ Дизайн інтерактивного ШІ та співпраця людини зі ШІ
AAAI: Узгоджувати, коли вони цього хочуть, доповнювати, коли їм це потрібно Узгодженість, взаємодоповнюваність і продуктивність команд людина—ШІ
Harvard Data Science Review: Наука про дані та інженерія із залученням людини Ролі людей у науці про дані, інженерії та контролі
PMC: Підходи із залученням людини в клінічному ШІ Клінічні застосування та людський контроль

FAQ

Що означає human-in-the-loop у ШІ?

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

У чому різниця між human-in-the-loop і human-on-the-loop?

У поширеному розумінні HITL вимагає людського вводу для вибраного рішення та часто призупиняє відповідний робочий процес. Human-on-the-loop зазвичай описує систему, яка працює під наглядом людини, що може втрутитися. Термінологія різниться, тому в описі системи слід зазначати фактичний контроль, а не покладатися лише на назву.

Що означає human-in-the-loop для ШІ-агентів?

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

Що таке human-on-the-loop у ШІ?

Human-on-the-loop зазвичай означає, що система ШІ працює, а людина відстежує результати та може зупинити, виправити або скасувати її дії. Зазвичай цей підхід не вимагає схвалення перед кожною дією.

Як Deskhero реалізує ШІ із залученням людини для команд підтримки?

Deskhero готує чернетки відповідей для перевірки Користувачами. Його чат-бот і автоматичні відповіді ШІ активуються за згодою та відповідають лише на основі схваленого загальнодоступного FAQ. Автоматичні дії позначаються та записуються в журнал, а запитання без відповіді в чаті передаються у форму для подальшого опрацювання людиною електронною поштою.