Если вам приходится выводить агентов в продакшн, вы можете подтвердить, что демо — это самая легкая часть. Модель демонстрирует что-то впечатляющее в блокноте, все приходят в восторг, а затем вам нужно подключить ее к реальным данным с реальными правами доступа, когда от результатов зависят операторы. Проблемы, с которыми вы сталкиваетесь на этом этапе, связаны не столько с выбранной вами моделью, сколько с тем, как ваши системы и процессы были построены задолго до появления агентов.
В недавнем выпуске подкаста Data and AI Weekly директор по маркетингу Redpanda Мелисса Чапига побеседовала с двумя людьми, которые работали с этими проблемами еще тогда, когда агенты не были опцией.
Брайан Бейер — соучредитель и генеральный директор Red Canary (теперь входящей в состав Zscaler), а Джо Моулз был там техническим директором, прежде чем перейти в furl, где он строит платформу для автономного исправления уязвимостей на конечных точках. Совместно они создали платформу, которая обрабатывала петабайты данных о безопасности в день силами относительно небольшой команды инженеров, а затем внедрили поверх нее агентов.
В этой статье излагаются уроки, извлеченные из этого процесса, а также последовательность действий, которая имеет большее значение, чем любое отдельное решение.
Если вы предпочитаете посмотреть полную беседу, вы можете сделать это ниже. Если нет — продолжайте читать.
1. Начинайте с результата, а не с данных
Red Canary никогда не ставила перед собой задачу создать систему обработки больших данных. По словам Брайана, отправной точкой стал более конкретный вопрос: каким образом злоумышленники наносят вред организациям и как их обнаружить, что означало необходимость выяснить, какие следы оставляет злоумышленник.
Исходя из этого, команда действовала от обратного. Как только они поняли, как действуют злоумышленники, они смогли задаться вопросом, где их можно поймать на этом пути, и только после этого — какие данные для этого потребуются. Ответ заключался в том, что никакой более узкий набор данных не подойдет, поэтому им пришлось просматривать абсолютно все, в результате чего они столкнулись с задачей обработки больших данных. Масштаб следовал из цели, а не наоборот.
Джо подошел к этому со стороны операционной деятельности и описывает аналогичный процесс: начните с конечного состояния и простройте путь назад, чтобы найти точки принятия решений и определить, какая информация нужна на каждом этапе. Получив такую картину, вы можете задать более полезный вопрос: можно ли выполнить данный шаг с помощью программного обеспечения и насколько далеко можно продвинуться в сторону подхода, ориентированного на софт. Там, где решение или проверка человеком имели наибольшее значение, эта точка принятия решений оставалась за человеком, и рабочий процесс был построен так, чтобы поддерживать это. Такое сотрудничество между операционным отделом и разработчиками — причина, по которой агентов позже удалось внедрить без труда, поскольку к моменту появления ИИ он стал еще одним слоем, наложенным на процесс, который команда уже понимала.
2. Стройте сложные системы из простых компонентов
Если и есть какой-то один архитектурный принцип, который Брайан ставит выше остальных, то это следующий:
«Мы хотим создавать действительно сложные системы, состоящие из очень простых компонентов». — Ранний архитектор Netflix
Переводя это на реальный язык, Брайан описал архитектуру потока данных в Red Canary, где каждый блок выполняет одну конкретную задачу.
Результат проявляется там, где происходит маршрутизация работы. Телеметрия поступает через модули приема, формируется и стандартизируется, проходит через механизмы обнаружения и настройки, а затем направляется либо на агентское расследование, либо на автоматизированное, причем инженер по обнаружению подключается к процессу при необходимости. Каждый из них представляет собой отдельный компонент со своей собственной задачей, поэтому конвейеру, подающему на них данные, не нужно знать, какой именно компонент обрабатывает конкретный случай. Это означает, что вы можете изменить то, что происходит в этой точке маршрутизации, или добавить к ней путь, не разрывая запутанную сеть компонентов обработки данных и не ломая процессы ниже по потоку.
Такое разделение также делает эксперименты с агентами достаточно дешевыми для проведения. Брайан описывает, как работало добавление нового агента: если у кого-то появлялась идея поиска угроз с помощью какой-то новой агентской технологии, для него создавался новый блок, подписывался на стандартизированные данные, а перед ним ставился фильтр, чтобы он видел только выборку, не затрагивая остальную систему. Если результаты вызывали доверие, агент отправлялся в основной конвейер, а если нет — сначала проходил процедуру контроля качества. Во многих случаях им удавалось делать это вообще без какого-либо влияния на основную производственную систему.
В ходе сессии Брайан разбирает полную схему и компоненты каждого блока, так что посмотрите запись, если вам нужны подробности.
3. Сначала детерминизм, затем агенты
Подход Джо к определению того, где место агентам, начинается с противоположного направления: спросите себя, где работа уже является детерминированной. Если вы можете написать сигнатуру или логика надежно сводится к формуле «A плюс B равно C», напишите это на программном коде, потому что это дешево, быстро и работает без накладных расходов более глубокого стека. Это был первый этап в Red Canary, и в основном он заключался в поиске повторяющихся задач и передаче их софту.
Агенты становились интересны на следующем уровне, где работа не была чисто детерминированной, но все же была хорошо понятна. Джо описывает это как знание вопросов, которые вы хотите задать, и концепций, которые вам нужно объединить, без возможности записать это в виде скрипта или блок-схемы.
Для определенного источника данных и класса поведения у вас может быть 20 или 30 вопросов, которые вы хотите задать, и в этот момент у вас появляется то, для чего можно составить промпт: исследовать данные этой конечной точки на предмет определенного поведения, задать эти вопросы, вернуть сводку.
Стоит отметить, что использование агента не означает, что модель выполняет всю задачу целиком. Вы даете указания на естественном языке, но также предоставляете агенту инструменты и вспомогательную информацию. При правильном подходе агент представляет собой довольно компактную сущность, координирующую набор окружающих его инструментов, что обходится дешевле и проще для понимания, чем требовать от модели выполнения абсолютно всего.
«Вместо того чтобы говорить об ИИ, думайте о нем как об автоматизации на естественном языке». — Джо Моулз, технический директор, furl
4. Вводите агентов в строй так же, как новых сотрудников
Оба гостя используют для описания агентов лексику, которую обычно применяют к людям. У каждого агента в Red Canary была своя карточка (как в бейсболе, по словам Джо), где были расписаны его задачи и то, что ему необходимо делать. Новые агенты проходили этап первого дня с жестким контролем и коучингом на основе их результатов, а по мере совершенствования агента этот контроль ослаблялся до периодических проверок и выборочного контроля — в основном для того, чтобы убедиться, что он не сошел с рельсов и что окружение не изменилось настолько, чтобы потребовалось обновление.
Режим сбоя, с которым Джо сталкивается чаще всего — это противоположный подход, когда кто-то подключает первый попавшийся под руку фреймворк для агентов, загружает туда все свои данные и пытается решить всю проблему разом. По его словам, это ведет к разочарованию, а альтернативой является тот же процесс итеративной разработки, который вы применили бы где угодно еще: начните с чего-то хорошо понятного, где вы знаете, что поступает на вход и как выглядит качественный результат.
Брайан утверждает, что такого рода декомпозицию проще проводить с агентами, чем с людьми, отчасти потому, что у агентов нет чувств, они не пререкаются и довольно хорошо следуют инструкциям. Вы можете сказать агенту контроля качества проверять свою работу каждый раз, и если он окажется слаб в каком-то одном типе анализа, вы можете разделить задачу так, чтобы один агент занимался анализом А, а другой — анализом Б. Это позволяет разбивать процесс такими способами, которые невозможны с человеческой командой, хотя вы и теряете значительную часть креативности, присущей людям, а в основе появляется более жесткая зависимость.
Читайте блог нашего технического директора: «Агенты в штате. Теперь нам нужен HR».
5. Оценивайте их точно так же
Кадровый подход применим и к тому, как вы оцениваете работу агента. Первые вопросы Джо — это те, которые вы задали бы в отношении любой конкретной должности: что здесь означает производительность, каковы ключевые показатели эффективности (KPI) и какие результаты это должно приносить? Исходя из этого, вы определяете, каково измеримое состояние на самом деле: будь то стоимость, скорость или что-то еще, подходящее для данной задачи.
Он описывает это как проведение аттестации агента, проверку того, выполнил ли он столько-то задач определенным образом, и рассмотрение затрат и накладных расходов на его управление в качестве самостоятельного KPI. Затем вы продолжаете развивать это до тех пор, пока не достигнете намеченной вехи — это тот же цикл, который вы бы провели с человеком на новой роли.
6. Зависимость: данные, обученные людьми, и человеческое суждение
Брайан говорит, что если бы команда попыталась создать что-то вроде Red Canary сегодня, просто поручив агентам эту проблему, у них бы ничего не вышло. Агенты преуспели там, потому что у них был большой резерв опытных специалистов по безопасности, которые уже потратили десятилетие на превращение собственного опыта в программное обеспечение, поэтому декомпозиция этих умственных процессов на агентов стала логичным шагом на основе уже имеющегося фундамента. Дайте ту же инструкцию команде без такого бэкграунда, и вы получите совсем другой результат.
«Это было бы эквивалентно тому, как если бы вы поручили группе ChatGPT уровня детского сада заниматься вопросами операционной безопасности», — Брайан Байер, соучредитель и генеральный директор Red Canary.
По его словам, примерно в 10% случаев вы будете впечатлены тем, что он что-то нашел, а в остальные 90% будете объяснять ему, что эту работу делать не следует.
Джо добавляет «новую половину» аргумента о данных. Ускорить настройку помог большой массив данных, обученных людьми, то есть годы записанных решений экспертов, которые знали свою работу и могли служить примерами. Это позволило им направить агента на набор данных, который, как они знали, был чистым, со словами: «Это правильные решения и хорошие примеры, а вот данные для будущих решений», — и при этом оградить его от данных, которым они не доверяли настолько, чтобы принимать на их основе решения. Дайте агенту кучу нечистых данных неизвестного происхождения, и он будет учиться на плохом материале.
7. Контроль доступа: относиться к агентам как к новобранцам
Что касается того, к чему агентам должно быть позволено прикасаться, Брайан предлагает тест, который легко провести везде: задайте вопрос, предоставили бы вы недавно нанятому инженеру или аналитику данных доступ ко всем вашим производственным данным.
Если ответ «да», вы, вероятно, можете создавать агентов на тех же условиях. Если «нет», то вы не должны предоставлять такой доступ и агенту, и вам нужно подумать о том, как вы будете это контролировать.
Он отмечает, что это эволюция, через которую в любом случае проходит каждая команда. По мере того как команды становятся все больше и международнее, проверять людей становится все сложнее, и проверка агентов из разных мест становится сложнее точно так же.
8. С чего начать, если у вас нет этого фундамента
Мелисса задала вопрос, который волнует большинство команд: что делать, если у вас нет десятилетия задокументированных решений и чистых примеров данных?
Оба гостя дали одинаковый ответ: запишите то, что вы уже делаете.
Брайан называет это единственной реальной отправной точкой, а Джо описывает это как старое упражнение по объяснению того, как приготовить арахисовую пасту и сэндвич с желе, смысл которого в том, чтобы понять, сможете ли вы пошагово описать собственный процесс. Его единственная оговорка заключается в том, что описывать это для всех бизнес-процессов — огромная работа, поэтому начните с небольшой части. «Не документируйте весь сэндвич целиком, — говорит он. — Просто задокументируйте нанесение арахисовой пасты на хлеб, и вы обнаружите шаги, о которых даже не думали, которые затем тоже сможете задокументировать».
Нарисуйте схему, и нарисуйте ее для людей
Из этого вытекают два практических момента. Первый заключается в том, что вам не нужно настраивать систему агентов так, чтобы она читала вашу документацию, потому что агентные системы сейчас не собираются самостоятельно разбираться в вашей архитектуре. Они управляются человеком, а это значит, что ваша собственная команда — это аудитория, которая имеет значение.
Во-вторых, артефакт, который работает — это диаграмма вроде той, что приведена выше. Рекомендация Брайана — выбрать Google Slides или PowerPoint, использовать реальные иконки того облачного провайдера, на котором вы работаете, и нарисовать, как движутся данные и где находятся границы интерфейсов. Он спешит признать, что вы можете автоматически сгенерировать картинку того, какие компоненты могут взаимодействовать друг с другом, но это бесполезная часть, потому что вы не можете автоматически сгенерировать причины, почему они должны это делать, или какова предполагаемая циркуляция данных.
Версия Джо заключается в использовании приложения для создания белых досок (whiteboard) и постоянной просьбе просто нарисовать ему схему, показывающую, где находятся блоки и где принимаются решения. Как только она появляется, разговор меняется, потому что вы можете пройтись по ней и спросить, почему тот или иной блок находится на своем месте или почему поток возвращается назад. Вы также можете указать на один переход и сказать: «Эта часть хорошо изучена и измерена», так что именно сюда отправляется агент, или заметить, что поток возвращается назад непредвиденным образом, и сначала выпрямить его.
Кратко (TL;DR): 8 уроков по масштабированию агентов
Если вы планируете запускать агентов в продакшн в больших масштабах, последовательность, вытекающая из этого разговора, выглядит следующим образом:
- Двигайтесь от результата к началу. Определите целевое состояние, процессы и точки принятия решений, прежде чем решать, какие данные или технологии вам нужны.
- Декаплируйте все. Простые компоненты, выполняющие одну задачу, позволяют добавить новый блок, отфильтровать его на выборке трафика и протестировать идею, не затрагивая продакшн.
- Сначала найдите детерминированную работу. Если вы можете написать правило, напишите его, а агентов оставьте для задач, которые хорошо понятны, но не поддаются полному скриптингу.
- Дайте каждому агенту одну задачу. Определите задачу, входные данные и ожидаемые результаты так же, как вы сделали бы это для нового сотрудника.
- Оценивайте их как сотрудников. Установите ключевые показатели эффективности и ожидаемые результаты, решите, основана ли производительность на затратах, скорости или чем-то еще измеримом, и проводите оценку на основе этого.
- Следите за данными, на которых вы их обучаете и настраиваете. Чистые образцы, утвержденные человеком, — это то, что ускоряет настройку, поэтому не допускайте ненадежные данные в конвейер принятия решений.
- Ограничивайте доступ осознанно. Используйте тест нового сотрудника, и если вы не доверили бы данные новому человеку, не давайте их и агенту.
- Набросайте схему. Диаграмма, нарисованная для людей и показывающая потоки данных и границы интерфейсов, является базовым артефактом, и начинать нужно с одного ее фрагмента.
Почти ничего из этого не специфично для ИИ, что примерно так Джо подводит итог этому подходу.
"Все это — построение систем, а агентная система — это просто еще одна система". — Джо Моулз (Joe Moles), технический директор furl
Посмотрите полную запись сессии, чтобы погрузиться в тему
В полной сессии подробно разбирается архитектура, а также обсуждается роль агентов по отношению к людям и детерминированному программному обеспечению. Посмотрите 7-й выпуск Data and AI Weekly, чтобы узнать все подробности.
Если вы хотите увидеть, как это выглядит на практике, закажите демонстрацию Redpanda Agentic Data Plane, чтобы обсудить вопросы развертывания, управления и масштабирования агентных систем на основе ваших собственных данных.