Сдерживание, наблюдение, адаптация: три тренда, формирующие разработку агентного ПО

Фото: Alexas_Fotos (Pixabay) — https://pixabay.com/photos/bottles-alcohol-to-form-three-1640819/

Источник: Dynatrace news•

Сдерживание, наблюдение, адаптация: три тренда, формирующие разработку агентного ПО

tldr; По мере того как становятся очевидными реальные проблемы запуска ИИ-агентов в промышленную эксплуатацию, на конференции We Are Developers World Congress North America выделились три темы: сдерживание агентов, наблюдаемость и оценка, а также опыт взаимодействия с агентами. Статья…

tldr; По мере того как реальные проблемы запуска ИИ-агентов в промышленную эксплуатацию становятся очевидными, на конференции We Are Developers World Congress North America выделились три темы: сдерживание агентов, наблюдаемость и оценка, а также опыт взаимодействия с агентами.

В прошлом месяце мы посетили конференцию We Are Developers World Congress North America в Сан-Хосе. Это была возможность почувствовать пульс сообщества разработчиков. Мы провели отличный прием совместно с The New Stack, организовали сессии по разработке с помощью ИИ и ответственному ИИ, провели практический семинар, основанный на реальных инцидентах и реальном коде, и потратили два дня на общение с разработчиками на нашем стенде.

Три важные темы всплывали снова и снова на протяжении всей недели.

1: Сдерживание агентов

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

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

2: Наблюдаемость и оценка

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

Как сказал Лори Восс, руководитель отдела по работе с разработчиками в Arize, в своем выступлении на главной сцене, ИИ сейчас создает слишком много кода для проверки человеком. Несколько докладчиков осветили различные аспекты этой проблемы. «Если в промышленную среду попадает больше вещей без прочтения человеком, это означает, что проверки на «корректность» также должны переместиться из CI/CD-тестов в промышленную среду, а это означает оценки», — написал Лори в своем итоговом посте. Оценка ИИ — это, конечно, именно то, чем занимается Arize, новейший член семьи Dynatrace.

Существует множество элементов головоломки наблюдаемости ИИ, включая отображение топологий инфраструктуры и корреляцию различных типов данных. На нескольких сессиях конференции докладчики подчеркивали важность мониторинга промышленной среды, оценки и своевременного контекста выполнения. Как выразился Боб Уамбах, вице-президент Dynatrace по анализу рынка и клиентов, в своем выступлении: «Безопасность — это свойство среды выполнения». Понимание того, что делает модель в реальной среде, является ключевой частью этой работы.

3: Опыт взаимодействия с агентами

Инструментарий разработчика раньше создавался для людей. Это меняется, поскольку агенты становятся основными пользователями баз данных, MCP-серверов и API. В своем обзоре конференции Лори отметил, что Хан Ван из Mintlify сообщил, что запросы от автоматизированных агентов составили 67% трафика к размещенной документации компании за период, который измеряла Mintlify.

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

Лори перечислил несколько лучших практик: предоставляйте документацию в виде чистого markdown, открывайте свои интерфейсы через MCP, включайте файл llms.txt и добавляйте точки входа, созданные специально для агентов.

Чего еще не хватает

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

В Dynatrace мы решаем эту проблему с помощью Grail, нашего унифицированного озера данных (data lakehouse).

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

Dynatrace, Grail и BlueBox являются торговыми марками группы компаний Dynatrace, Inc. Все остальные торговые марки являются собственностью их соответствующих владельцев.

Dynatrace, Grail и BlueBox являются торговыми марками группы компаний Dynatrace, Inc. Все остальные торговые марки являются собственностью их соответствующих владельцев.

О чём эта статья

Ещё в разделе «Данные и аналитика»

Все →

Ещё от Dynatrace