Дхивья Нагасубраманиан, Вице-президент по трансформации и инновациям ИИ – Интервью

Дхивья Нагасубраманиан является Вице-президентом по трансформации и инновациям ИИ в крупном финансовом учреждении США, где она руководит разработкой, развертыванием и управлением производственными агентными системами ИИ. Она является автором книги Агентный ИИ для инженеров (Apress/Springer Nature), практического руководства по созданию автономных систем ИИ, которые можно доверять в производстве. С момента ее выпуска книга получила более 6 000 институциональных доступов на SpringerLink, хранится в более чем 260 библиотеках по всему миру и используется в университетах. Она является обладателем патента, выданного Управлением по патентам и товарным знакам США, в области прикладного машинного обучения. Ее исследовательские интересы включают создание приложений, устойчивых к атакам на прорыв тюрем, и вклад в более широкие отраслевые усилия по разработке лучших моделей для многонациональной безопасности и безопасности. Она является востребованным экспертом и участником многочисленных отраслевых и академических конференций.

Ваша карьера прошла путь от корпоративных консультаций и науки о данных к руководству трансформацией ИИ в финансовых услугах. Как эти опыт сформировали книгу “Агентный ИИ для инженеров”, и какая повторяющаяся разница между исследованиями ИИ и развертыванием в корпорациях убедила вас, что эта книга должна быть написана?

Я начала в 2008 году, создавая системы учета портфелей и измерения производительности для банковских платформ. Одним из этих проектов был движок, соответствующий требованиям GIPS, для расчета временно-взвешенных доходов, который в конечном итоге использовался финансовыми учреждениями более чем в 80 странах. Эта работа научила меня уроку, который сформировал всю мою карьеру. В регулируемой финансовой сфере наиболее опасная неудача – это неправильное число, которое выглядит правильным. Субтильно неверный расчет доверяется, сообщается и действует в течение многих лет, потому что ничего не кажется сломанным.

Я увидела тот же шаблон снова позже. Я обнаружила структурный пробел в марковской модели широко используемой модели атрибуции маркетинга. Фреймворк использовался сотнями тысяч пользователей, и ошибка выжила в течение многих лет по одной причине: выходные данные выглядели разумными. Когда я перешла в трансформацию ИИ в финансовых услугах, я наблюдала, как агентные системы повторяют этот шаблон с гораздо более высокими ставками. Агент не только производит неправильный результат. Он совершает действия на его основе.

Пробел, который убедил меня написать книгу, заключается в том, что исследования и корпоративное развертывание заботятся о разных вещах. Исследования измеряют возможности на основе бенчмарков. Корпорации полагаются на то, как система ведет себя в условиях неоднозначности, изменений данных и враждебного давления. Большинство написанного об агентах останавливается на стадии демонстрации. Я написала “Агентный ИИ для инженеров” для инженера, который должен поставить свое имя на систему, которая будет работать с ограниченным надзором внутри регулируемого учреждения.

Ваша книга описывает переход от автоматизации к автономности как новый инженерный образ мышления. Что действительно отделяет автономного агента ИИ от сложной автоматизированной рабочей нагрузки, и где организации наиболее вероятно перепутают два?

Я даю командам простой тест. Можете ли вы перечислить каждый путь, который система может пройти, прежде чем запустить ее? Если да, у вас есть автоматизация. Она может быть очень сложной автоматизацией с моделью языка внутри нее, но это все равно автоматизация. Если система разбивает цели, выбирает инструменты и решает порядок действий во время выполнения на основе контекста, который вы не запрограммировали, у вас есть автономность. Разница не имеет отношения к модели, которую вы используете. Она заключается в том, где принимаются решения.

Организации путают два в обоих направлениях, но только одно направление дорого. Называть скриптовую рабочую нагрузку LLM агентной в основном является маркетинговой проблемой. Самая дорогая ошибка – обратное. Команды развертывают真正 автономное принятие решений под управлением, предназначенным для детерминированной автоматизации. Их тестирование предполагает повторяемость. Их мониторинг предполагает известные шаблоны неудач. Их аудиторский след предполагает, что есть отслеживаемое правило за каждым действием. Ни одно из этих предположений не действует для агента.

Это тот сдвиг образа мышления, за который я выступаю в книге. С автоматизацией основным вопросом является, выполнила ли система свою задачу правильно. С автономностью вопросом становится, решила ли система правильно. Ответ на этот вопрос требует другой инструментария, другой методологии оценки и другого уровня осторожности.

Многие агентные системы ИИ работают впечатляюще на демонстрациях, но испытывают трудности, когда сталкиваются с реальными пользователями, меняющимися данными и непредсказуемыми инструментами. Какие компоненты следует учитывать обязательными в архитектуре агента, готового к производству?

Честный ответ заключается в том, что производство требует всего, что демонстрация позволяет пропустить. Демонстрация работает, потому что кто-то контролировал среду. Производство отнимает этот контроль.

В книге я описываю семислойную архитектуру, но следующие компоненты я считаю обязательными. Контракты инструментов с типизированными входами и явными разрешениями, чтобы досягаемость агента ограничивалась дизайном, а не надеждой. Управление состоянием, которое выживает после прерываний и неудач. Структурированное обработка неудач с определенным путем эскалации. Оценочный каркас, который запускается непрерывно, а не один раз перед запуском. И аудиторский след, который записывает решения и рассуждения, лежащие в их основе, а не только действия, совершенные.

Компонент, который команды пропускают чаще всего, – это проверка во время выполнения. Это слой, который проверяет каждое действие против заявленной цели агента и политик, которые к нему применяются. Стандартная инфраструктура говорит вам, удалось ли вызов. Верификация спрашивает, должен ли был совершен вызов вообще. Она никогда не доказывает свою ценность в демонстрации, потому что в демонстрации ничего не нужно поймать. В производстве это первое, чего вы пожалеете, что не сделали.

Ваша книга охватывает безопасность, соответствие, обратные связи, тестирование, отладку, оценку и развертывание. Как инженерные команды должны объединить эти элементы в непрерывный процесс обеспечения, а не рассматривать безопасность как окончательный предстартовый обзор?

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

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

Организационный аспект имеет значение так же, как и технический аспект. Безопасность не может быть отдельной командой, которая появляется в конце с контрольным списком. Инженеры, которые строят агента, должны владеть его наборами оценок, его инвариантами и его дизайном эскалации, потому что они знают лучше, чем кто-либо другой, где суждение системы самое слабое.

Вы подчеркнули семантический мониторинг вызовов агента. Что открывает семантический мониторинг, чего не могут традиционные журналы и инструменты наблюдаемости, и как он может обнаружить, когда агент технически функционирует, но преследует неправильную цель?

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

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

Это также то, как вы обнаруживаете дрейф цели, который я считаю определяющей неудачей агентных систем. Дрейф цели выглядит как агент, который завершает каждый шаг правильно согласно журналам, а тихо работает над неправильной целью. Он никогда не появляется в журнале, потому что ничего не терпит неудачи. Семантический мониторинг рассматривает намерение как нечто, что измеряется напрямую, и намерение – это то, где агенты терпят неудачу.

Когда агент сталкивается с неоднозначными инструкциями, противоречивыми политиками, недоступными инструментами или недостаточной уверенностью, какой должна быть структурированная обработка неудач? Как разработчики могут обеспечить, чтобы система паузировала, эскалировала или восстанавливалась вместо того, чтобы импровизировать?

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

На практике это означает, что отказ и эскалация спроектированы и протестированы с тем же уходом, что и успех. Я рекомендую определять типизированные состояния неудач: неоднозначная инструкция, конфликтующая политика, недоступный инструмент, недостаточная уверенность. Каждый из них сопоставляется с конкретным поведением. Задайте уточняющий вопрос. Передайте человеку с полным контекстом, прикрепленным к нему. Перейдите в режим только для чтения. Повторите в более узких пределах. Или остановитесь. Пороги уверенности должны соответствовать риску конкретного действия. Порог для составления внутреннего резюме и порог для прикосновения к учетной записи клиента никогда не должны быть одним и тем же числом.

Две практики делают это реальным. Во-первых, спроектируйте путь эскалации до счастливого пути. Если человек получит передачу, решите, какой контекст он получит и какую власть он будет иметь, прежде чем вы напишете первый запрос. Во-вторых, протестируйте неудачу так же, как и функции. Введите неоднозначные инструкции. Отключите инструменты на этапе тестирования. Подайте агенту конфликтующие политики. Система, которая никогда не практиковала неудачу, будет действовать без руководства в первый раз, когда это произойдет в производстве.

Финансовым учреждениям необходимо сбалансировать экспериментирование с жесткими требованиями вокруг конфиденциальности, аудитности, риска модели и соблюдения нормативных требований. Где должно оставаться обязательным одобрение человека, и где агенты могут быть безопасно предоставлены большей операционной автономией?

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

Общая ошибка заключается в том, что требуется одобрение человека на каждом шаге. Это не делает систему более безопасной. Это воссоздает ручной процесс с дополнительными шагами и обучает рецензентов штамповать. Одобрения принадлежат реальным точкам принятия решений. Их должно быть немного, и каждый из них должен быть укомплектован кем-то с реальной властью сказать нет.

Другим принципом является то, что автономность должна быть заслужена, а не предоставлена. Начните с узкого круга. Расширьте, когда система доказывает себя под наблюдением. Сохраните доказательства. В терминах риска модели ваша среда контроля должна позволить вам показать регулирующему органу не только то, что сделал агент, но и почему вы были оправданы в предоставлении ему такого уровня независимости. Этот рекорд – это настоящая лицензия на эксплуатацию.

Через вашу работу над средствами безопасности и стандартами ИИ вы помогаете определять правила для систем, чьи возможности продолжают меняться. Какие средства безопасности можно реально стандартизировать сегодня, и какие области остаются слишком зависимыми от контекста, отрасли или случая использования?

Мы можем стандартизировать средства безопасности сегодня, которые являются структурными. Они требуют, чтобы определенные контроли существовали, были задокументированы и могли быть проверены. Документированные границы возможностей и разрешений для автономных систем. Определенные механизмы надзора человека и эскалации. Обязанности по обнаружению и сообщению о инцидентах. Методы оценки и требования к доказательствам. Ясная подотчетность на протяжении всего жизненного цикла системы, чтобы, когда что-то идет не так, ответ на вопрос, кто ответственный, никогда не был просто ИИ. Эти можно стандартизировать, потому что они касаются того, существуют ли контроли и насколько они хороши, а не конкретные значения, которые они принимают.

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

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

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

Рассматривая только усредненные бенчмарки, можно пропустить неудачи, которые имеют наибольшее значение. Модель может показать сильный общий балл безопасности, а в то же время плохо работать для конкретного языка, диалекта или культурного контекста, потому что эти неудачи исчезают в среднем. Западно-центричная оценка добавляет еще одну слепую зону. Она пропускает вред, который является культурно-специфичным, такой как идиомы, жесты и религиозные или региональные контексты, где один и тот же вывод безобиден в одной культуре и вреден в другой. Она также недооценивает код-свитчинг, транслитерацию и не западные имена и сущности. Есть также враждебный угол. Атакующие не нацеливаются на вашу среднюю производительность. Они находят ваш самый слабый срез, и для большинства моделей этот срез является языком с низкими ресурсами или недооцененным культурным контекстом.

Это то, что привело меня к вкладу в исследования бенчмарков безопасности ИИ. Основным выводом является то, что оценка безопасности в разных культурах требует оценочных данных и человеческого суждения, полученных из этих культур. Вы не можете оценить вред извне контекста, в котором он происходит.

Для предприятий я предлагаю три правила. Оцените каждый сегмент, который вы обслуживаете, и никогда не принимайте среднее значение в качестве доказательства. Создайте наборы оценок из ваших фактических популяций клиентов. Запустите враждебное тестирование на языках, которые используют ваши клиенты. Если вы обслуживаете клиентов в 40 странах и оцениваете только на английском языке, вы измерили свою систему для кого-то другого.

Вы также обладаете патентом, выданным Управлением по патентам и товарным знакам США, в области прикладного ИИ. Какую проблему вы пытались решить, что процесс преподал вам о превращении исследований ИИ в практические инновации, и какая нерешенная задача агентного ИИ вас больше всего интересует?

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

Вы можете увидеть те же темы, которые я описал на протяжении всего этого интервью. Маршрутизируйте каждый задачу к инструменту, который лучше всего подходит для ее выполнения. Держите людей в цикле, где суждение имеет значение. И делайте каждое автоматическое решение отслеживаемым, потому что в регулируемом учреждении ответ без доказательств не является ответом.

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

Нерешенная задача, которая меня больше всего заботит сейчас, – это верификация во время выполнения для многоагентных систем. Определение семантических инвариантов для одного агента является управляемым. Я знаю, потому что мы делаем это в производстве. Когда агенты делегируют работу другим агентам, поведение становится эмерджентным, и неудачи перемещаются в передачи. Инструкция немного переинтерпретируется на каждом шаге. Политика применяется к одному агенту, но не к агенту, которого он набирает. Верификация взаимодействия между агентами, а не только их действий, – это то, где я ожидаю, что появится следующее поколение скрытых неудач. Это проблема, над которой я хочу работать дальше.

Спасибо за отличное интервью, читатели также могут заказать ее книгу Агентный ИИ для инженеров.