Дхів’я Нагасубраманьян, Віце-президент з трансформації та інновацій штучного інтелекту – Серія інтерв’ю

Дхів’я Нагасубраманьян є Віце-президентом з трансформації та інновацій штучного інтелекту в одному з великих фінансових інститутів США, де вона очолює розробку, розгортання та управління системами штучного інтелекту. Вона є автором книги Agentic AI for Engineers (Apress/Springer Nature), практичного посібника з будівництва автономних систем штучного інтелекту, яким можна довіряти виробництву. З моменту виходу книги було здійснено понад 6 000 інституційних доступів на SpringerLink, а також було здійснено замовлення в більш ніж 260 бібліотеках світу та прийнято в університетах. Вона є володаркою патенту, виданого офісом США з патентів і товарних знаків, в галузі прикладного машинного навчання. Її дослідження спрямовані на розробку застосунків, які є стійкими до атак з боку противників, та внесок у більш широкі зусилля галузі з розробки кращих моделей для мультикультурної безпеки та безпеки. Вона є затребуваним експертом і учасником панельних дискусій на різних промислових і академічних конференціях.

Ваша кар’єра пройшла від корпоративних консультацій та наук про дані до керівництва трансформацією штучного інтелекту в сфері фінансових послуг. Як ці досвіди сформували книгу “Agentic AI for Engineers”, і яку повторювану прогалину між дослідженнями штучного інтелекту та розгортанням у підприємствях переконало вас, що ця книга повинна бути написана?

Я почала свою кар’єру в 2008 році з будівництва систем обліку портфелів та вимірювання продуктивності для банківських платформ. Одним з цих проєктів була система розрахунку часу-зважених доходів, яка згодом була використана фінансовими інститутами в понад 80 країнах. Ця робота навчила мене уроку, який сформував всю мою кар’єру. У регульованій сфері фінансів найнебезпечнішою помилкою є неправильна цифра, яка виглядає правильною. Неправильний розрахунок довіряється, повідомляється та здійснюється протягом років, оскільки нічого не здається пошкодженим.

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

Прогалина, яка переконала мене написати книгу, полягає в тому, що дослідження та розгортання підприємств переймаються різними речами. Дослідження вимірюють можливості на основі бенчмарків. Підприємства залежать від того, як система поводиться під неоднозначністю, зміною даних та тиском супротивників. Більшість написаного про агентів зупиняється на етапі демонстрації. Я написала “Agentic AI for Engineers” для інженера, який повинен поставити свою підпис під системою, яка буде працювати з обмеженим наглядом всередині регульованого інституту.

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

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

Організації плутатимуть їх у обидві сторони, але тільки одна сторона дорога. Назвати скриптовану LLM-робочий потік агентським є переважно маркетинговою проблемою. ДорогомистAKE є зворотне. Команди розгортають真正 автономне прийняття рішень під управлінням, яке було розроблено для детермінірованої автоматизації. Їхнє тестування припускає повторюваність. Їхнє моніторинг припускає відомі моделі відмов. Їхній слід аудиту припускає, що за кожною дією є слідова правило. Ні одна з цих припущень не виконується для агента.

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

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

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

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

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

Як інженерні команди повинні поєднувати ці елементи в процес безперервної гарантії, а не розглядати безпеку як остаточний попередній огляд?

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

Безперервна гарантія означає закриття циклу. Поведінкові оцінки працюють у CI (безперервній інтеграції) так само, як і тести одиниць, і вони блокують кожну зміну до підказок, інструментів та моделей. Моніторинг на час виконання подає сліди виробництва назад до наборів оцінювання. Я описую чотири моделі моніторингу в книзі, оскільки жодна модель не покриває повну поверхню відмов. Кожна інцидент створює новий перевірку, так само, як кожна помилка повинна створити регресійний тест. І тестування на противників працює за регулярним графіком, а не один раз перед запуском.

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

Ви підкреслили семантичний моніторинг викликів інструментів агента. Що відкриває семантичний моніторинг, чого не можуть традиційні журнали та інструменти спостереження?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дякую за велике інтерв’ю, читачам також можна замовити її книгу Agentic AI for Engineers.