Перевірка дій штучних інтелектуальних агентів: дозволи, бар’єри схвалення та рівні ризику

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

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

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

Чому неправильна дія коштує більше, ніж неправильна відповідь

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

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

Reads information
↓
Makes a decision
↓
Calls another system
↓
Changes something
↓
Continues automatically

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

Мінімальні привілеї: визначайте, що може робити агент

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

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

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

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

Людське схвалення для важливих дій

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

AI identifies issue
↓
AI proposes solution
↓
AI prepares changes
↓
Human reviews
↓
Human approves
↓
System executes

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

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

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

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

Перевірка як ключова навичка

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

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

Підбір ступеня автономії під ризик

Формулювання запитання «Чи можна довіряти ШІ?» з відповіддю «так» чи «ні» є некорисним. Довіру слід надавати для кожного завдання пропорційно ймовірності виникнення проблем. Проста трьохрівнева модель є гарною відправною точкою.

Низький ризик: дозволити автономне виконання

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

Середній ризик: автоматизувати, а потім перевірити

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

Високий ризик: необхідна пряма авторизація

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

Цей принцип можна узагальнити так: перевірка має бути пропорційною вартості можливої помилки.

Більше автономії не означає автоматично кращого результату

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

• лише пропонувати
• підготувати роботу для виконання іншою особою
• виконувати після підтвердження

функціонує повністю автоматично

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

Питання, які потрібно поставити перед підключенням інструменту

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

APIs
Databases
Browsers
File systems
Cloud infrastructure
Development tools
Business applications
External services

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

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

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

Грамотність у роботі з ШІ тепер включає грамотність у розумінні ризиків

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

Людське судження, машинна реалізація

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

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

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

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