8 инженерных уроков по запусклу ИИ-агентов в продакшене

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

В одном из недавних выпусков программы Data and AI Weekly директор по маркетингу Redpanda Мелисса Чапига (Melissa Czapiga) побеседовала с двумя специалистами, которые решали эти задачи еще тогда, когда агенты не были opción.

Брайан Байер (Brian Beyer) — соучредитель и генеральный директор Red Canary, которая сейчас входит в состав Zscaler, а Джо Моулз (Joe Moles) был там техническим директором, прежде чем перейти в furl, где он строит платформу для автоматического восстановления на конечных точках. Вместе они создали платформу, которая обрабатывала петабайты данных безопасности в день силами относительно небольшой команды инженеров, а затем надстроили над ней агентов.

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

Если вы предпочитаете посмотреть полное выступление, вы можете сделать это ниже. Если нет, читайте дальше.

1. Начинайте с результата, а не с данных

Red Canary никогда не ставила перед собой задачу создать систему обработки больших данных. По словам Брайана, отправной точкой стал более конкретный вопрос: как злоумышленники вредят организациям и как их обнаружить, что означало необходимость выяснить, какие следы оставляет злоумышленник.

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

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

2. Создавайте сложные системы из простых компонентов

Если и есть какой-то один архитектурный принцип, который Брайан ставит выше остальных, то это следующий:

«Мы хотим создавать действительно сложные системы из очень простых компонентов». — Архитектор раннего Netflix

Переводя это на реальный язык, Брайан описал архитектуру потоков данных в Red Canary, где каждый блок выполняет одну задачу.

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

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

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

3. Сначала детерминизм, потом агенты

Способ Джо определять, где место агентов, начинается с противоположного направления: спросите себя, где работа уже является детерминированной. Если вы можете написать сигнатуру или логика надежно сводится к «А плюс Б равно С», напишите это на программном обеспечении, потому что это дешево, быстро и работает без накладных расходов более глубокого стека. Это был первый этап в 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, использовать реальные значки того облачного провайдера, на котором вы работаете, и нарисовать, как перемещаются данные и где находятся границы интерфейсов. Он спешит признать, что вы можете автоматически сгенерировать картинку того, какие компоненты могут соприкасаться друг с другом, но это бесполезная часть, потому что вы не можете автоматически сгенерировать причину, по которой они должны это делать, или предполагаемые потоки данных.

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

Кратко: 8 уроков по масштабируемому запуску агентов

Если вы планируете запуск агентов в продакшене в масштабе, последовательность, вытекающая из этого разговора, выглядит следующим образом:

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

Почти ничего из этого не специфично для ИИ, что примерно так Джо резюмирует этот подход.

«Всё это — создание систем, а агентная система — это просто еще одна система», — Джо Моулз (Joe Moles), технический директор furl.

Смотрите полную запись сессии, чтобы погрузиться в тему

В полной записи подробно разбирается архитектура, а также обсуждается место агентов по отношению к людям и детерминированному программному обеспечению. Смотрите все это в 7-м эпизоде Data and AI Weekly.

Если вы хотите увидеть, как это выглядит на практике, запишитесь на демонстрацию Redpanda Agentic Data Plane, чтобы обсудить, как развертывать, контролировать и масштабировать агентные системы на основе вашим собственных данных.