Мы видим, как за последние несколько лет произошёл сдвиг от создания жёстких программных систем к рабочим процессам, управляемым естественным языком, что стало возможным благодаря более мощным большим языковым моделям.
Одним из интересных аспектов этих агентных ИИ-систем является разница между построением одноагентных и мультиагентных рабочих процессов, или, возможно, разница между более гибкими и более контролируемыми системами.
Эта статья поможет вам понять, что такое агентный ИИ, как создавать простые рабочие процессы с LangGraph и каких результатов можно достичь с различными архитектурами. Я продемонстрирую это, создавая агента для новостей в области технологий, используя различные источники данных.
Что касается области применения, то я немного одержим получением автоматических новостных обновлений на основе предпочтений, но при этом предпочитаю умеренность, чтобы каждый день не утопать в информационном потоке.
Работа с суммированием и сбором информации — это одна из тех областей, где агентный ИИ может продемонстрировать свою наибольшую эффективность.
Итак, давайте рассмотрим разницу между одноагентными и мультиагентными системами.
Я всегда стараюсь рассказывать про свою работу без технического жаргона, поэтому если вы новичок в агентном ИИ, эта статья поможет вам понять, что это и как с ним работать.
Агентный ИИ и большие языковые модели (LLM)
Агентный ИИ — это про программирование с использованием естественного языка. Вместо того чтобы использовать жёсткий и явный код, вы инструктируете большие языковые модели (LLM), чтобы они направляли данные и выполняли действия через обычный язык, автоматизируя задачи.
Использование естественного языка в рабочих процессах — не новое веяние. Мы использовали NLP в течение многих лет для извлечения, обработки данных и других задач. Что ново, так это тот уровень свободы, который теперь мы можем предоставить языковым моделям, позволяя им работать с неопределённостью и принимать решения динамически.
Но только потому, что LLM могут понимать нюансы языка, не означает, что они автоматически проверяют факты или сохраняют целостность данных. Я рассматриваю их прежде всего как слой для взаимодействия, который функционирует поверх структурированных систем и существующих источников данных.
Обычно я объясняю это так, когда говорю с неспециалистами: они работают немного как мы. Если у нас нет доступа к чистым структурированным данным, мы начинаем придумывать. То же самое с LLM. Они генерируют ответы на основе паттернов, а не проверки фактов.
Так что, как и мы, они делают всё возможное с имеющимися данными. Если мы хотим получить лучший результат, нам нужно строить системы, которые предоставляют им надёжные данные для работы. Таким образом, в агентных системах мы создаём механизмы для их взаимодействия с различными источниками данных, инструментами и системами.
Однако то, что мы можем использовать эти большие модели в большем количестве случаев, не означает, что мы должны это делать. LLM хорошо справляются с интерпретацией нюансов естественного языка, например, в обслуживании клиентов, исследовательской работе или в человеко-машинном взаимодействии.
Но для структурированных задач — таких как извлечение чисел и их передача — следует использовать традиционные подходы. LLM не лучше калькулятора в математике. Так что вместо того, чтобы заставить LLM делать вычисления, вы даёте LLM доступ к калькулятору.
Таким образом, когда вы можете строить части рабочего процесса программным способом, это по-прежнему будет лучшим вариантом.
Тем не менее, LLM отлично адаптируются к беспорядочному вводу из реального мира и интерпретируют расплывчатые инструкции, поэтому комбинирование этих технологий может быть отличным способом создания систем.
Агентные фреймворки
Я знаю, что многие начинают с CrewAI или AutoGen, но я бы порекомендовал ознакомиться с LangGraph, Agno, Mastra и Smolagents. Согласно наблюдениям, эти фреймворки получили наилучшие отзывы на данный момент.
LangGraph более технически сложный, но является предпочтительным выбором для многих разработчиков. Agno является более простым для начала, но менее технически насыщенным. Mastra — отличная опция для разработчиков на JavaScript, а Smolagents представляет собой перспективную легковесную альтернативу.
Я выбрал LangGraph, основанный на LangChain, не потому, что это мой любимый фреймворк, а потому, что он становится стандартом, который всё больше разработчиков начинают использовать. Поэтому имеет смысл с ним познакомиться.
Однако, у него много абстракций, и вам, возможно, захочется переписать некоторые части, чтобы лучше контролировать и понимать их.
Я не буду сейчас углубляться в детали LangGraph. Для тех, кто хочет подробнее его изучить, я написал руководство.
Что касается этого примера, вы сможете запустить рабочий процесс без написания кода, но вероятно, вам также будет интересно понять, как это работает.
Выбор LLM
Теперь вы, возможно, задаётесь вопросом, почему в качестве основы для агентов я выбираю определённые LLM.
Нельзя просто выбрать любую модель, особенно если вы работаете в рамках фреймворка. Они должны быть совместимы, и важным аспектом является поддержка вызова инструментов и способность генерировать структурированные результаты.
Я рекомендую проверить Agent Leaderboard на HuggingFace, чтобы посмотреть, какие модели действительно хорошо работают в реальных агентных системах.
Для этого рабочего процесса вы можете использовать модели от Anthropic, OpenAI или Google. Если вы рассматриваете другие модели, убедитесь, что они совместимы с LangChain.
Одноагентные vs мультиагентные системы
Если вы строите систему на одной LLM и даёте ей набор инструментов для использования, вы работаете с одноагентным рабочим процессом. Это быстрый процесс, и если вы новичок в агентном ИИ, вам может показаться, что модель должна решить всё сама.
Но дело в том, что такие рабочие процессы — это всего лишь ещё одна форма проектирования систем. Как и в любом программном проекте, вам нужно спланировать процесс, определить шаги, структурировать логику и решить, как должна вести себя каждая часть.
Вот тут и вступают в игру мультиагентные рабочие процессы.
Однако не все из них иерархические или линейные; некоторые являются коллаборативными. Коллаборативные рабочие процессы также представляют собой более гибкий подход, с которым я нахожу сложнее работать, по крайней мере, с текущими возможностями.
Тем не менее, коллаборативные рабочие процессы также разделяют функции на отдельные модули.
Одноагентные и коллаборативные рабочие процессы хорошо подходят для начала, когда вы только экспериментируете, но они не всегда обеспечивают необходимую точность для реальных задач.
Для рабочего процесса, который я буду строить здесь, я уже знаю, как должны использоваться API — так что моя задача — направить систему на их правильное использование. Мы сравним одноагентную настройку с иерархической мультиагентной системой, где ведущий агент делегирует задачи небольшой команде, чтобы вы увидели, как они функционируют на практике.
Создание одноагентного рабочего процесса
С одним потоком — т.е. одним агентом — мы даём LLM доступ к нескольким инструментам. Агент сам решает, какой инструмент использовать и когда, основываясь на запросе пользователя.
Проблема одноагентного рабочего процесса — это управление.
Независимо от того, насколько детализирован запрос, модель может не следовать нашим инструкциям (такое может происходить и в более контролируемых средах). Если мы дадим ей слишком много инструментов или опций, существует высокая вероятность, что она не использует все из них или даже выберет неправильные.
Для иллюстрации мы создадим агента для новостей технологий, который будет иметь доступ к нескольким API с пользовательскими данными и параметрами в инструментах. Агент сам решает, сколько инструментов использовать и как сформировать финальный отчёт.
Не забывайте, что я строю эти рабочие процессы с использованием LangGraph. Я не буду углубляться в LangGraph здесь, так что если вы хотите изучить основы, чтобы иметь возможность настроить код, переходите в руководство.
Вы можете найти одноагентный рабочий процесс здесь. Для его запуска установите LangGraph Studio и последнюю версию Docker.
После настройки откройте папку проекта, добавьте GOOGLE_API_KEY в файл .env и сохраните. Ключ можно получить от Google здесь.
Gemini Flash 2.0 предлагает щедрый бесплатный тариф, поэтому запуск не должен стоить ничего (но вы можете столкнуться с ошибками, если будете использовать его слишком часто).
Если вы хотите сменить LLM или инструменты, можно настроить код напрямую. Но, опять же, помните, что LLM должна быть совместима.
После настройки запустите LangGraph Studio и выберите правильную папку. Это запустит наш рабочий процесс, чтобы мы могли его протестировать.
Если у вас возникли проблемы с запуском, дважды проверьте, что вы используете последнюю версию Docker.
Как только он загрузится, вы можете протестировать рабочий процесс, введя сообщение от пользователя и нажав на кнопку отправки.
Посмотрите ниже, как я запускаю рабочий процесс.
Ниже виден конечный ответ.
Для этого запроса система решила, что будет проверять еженедельные трендовые ключевые слова, отфильтрованные только по категории «компании», а затем собирать источники этих ключевых слов и подводить итог для нас.
У неё возникли проблемы с предоставлением единой сводки, где она просто использовала информацию, которую получила последней, и не смогла использовать все данные исследований.
На самом деле, мы хотим, чтобы система собирала как трендовые, так и топовые ключевые слова в нескольких категориях (не только компании), проверяла источники, отслеживала конкретные ключевые слова, анализировала и красиво подводила итог перед возвращением ответа.
Конечно, мы можем её корректировать и продолжать задавать вопросы, но, как вы понимаете, если задача усложняется, она начнёт упрощать рабочий процесс.
Главное: агентная система не будет думать так, как мы ожидаем, нам нужно на самом деле оркестрировать её действия, чтобы она выполняла нужные задачи.
Таким образом, один агент — это здорово для чего-то простого, но, как вы понимаете, он может думать или вести себя не так, как мы ожидаем.
Именно поэтому использование более сложной системы, где каждый агент отвечает за одну задачу, может быть действительно полезным.
Тестирование многоагентного рабочего процесса
Создание мультиагентных рабочих процессов значительно сложнее, чем создание одноагентной системы с доступом к нескольким инструментам. Для этого необходимо заранее тщательно продумать архитектуру системы и способы передачи данных между агентами.
Мультиагентный рабочий процесс, который я настрою, включает две команды — команду исследования и команду редактирования, каждая из которых состоит из нескольких агентов.
Каждый агент имеет доступ к определённому набору инструментов.
Мы вводим новые инструменты, такие как исследовательская панель, для совместной работы: одна команда записывает свои находки, а другая их читает. Последний LLM будет читать всё, что было исследовано и отредактировано, чтобы составить сводку.
Альтернативой исследовательской панели является хранение данных в черновике состояния, что позволяет изолировать краткосрочную память для каждой команды или агента. Но это также означает, что нужно тщательно продумывать, что должна включать память каждого агента.
Я также решил улучшить инструменты, чтобы предоставить более полные данные с самого начала и избежать необходимости агентам собирать источники для каждого ключевого слова по отдельности. Здесь я использую обычную программную логику, потому что могу.
Основной вывод, который стоит запомнить: если можно использовать обычную программную логику, используйте её.
Поскольку мы используем несколько агентов, можно снизить затраты, используя более дешёвые модели для большинства агентов, оставляя более дорогие для выполнения ключевых задач.
Здесь я использую Gemini Flash 2.0 для всех агентов, кроме резюмирующего агента, который работает на GPT-4o от OpenAI. Если вы хотите получать более качественные резюме, можно использовать ещё более продвинутую LLM с большим контекстным окном.
Рабочий процесс настроен для вас здесь. Прежде чем загрузить его, убедитесь, что вы добавили ключи API для OpenAI и Google в файл .env.
В этом рабочем процессе маршруты (рёбра) настраиваются динамически, в отличие от одного агента, где они настраиваются вручную. Это будет выглядеть сложнее, если вы заглянете в код.
Как только вы запустите рабочий процесс в LangGraph Studio (тот же процесс, что и ранее), вы увидите граф с готовыми узлами.
LangGraph Studio позволяет визуализировать, как система делегирует задачи между агентами при запуске — точно так же, как это происходило в более простом рабочем процессе.
Поскольку я знаком с инструментами, которые использует каждый агент, я могу направить систему в правильное русло. Но обычные пользователи не будут знать, как сделать это правильно. Поэтому если вы строите нечто подобное, я бы порекомендовал ввести агента, который преобразует запрос пользователя в то, с чем другие агенты могут работать.
Это можно протестировать, задав сообщение:
«Я инвестор, и мне интересно получать обновления по событиям недели в области технологий и о том, о чём говорят люди (это означает, что интересны такие категории, как компании, люди, сайты и темы). Пожалуйста, отслеживай также следующие ключевые слова: AI, Google, Microsoft и Large Language Models».
Затем выберите “supervisor” в качестве следующего параметра (Next parameter) (обычно мы делаем это программно).
Этот рабочий процесс займёт несколько минут — в отличие от рабочего процесса с одним агентом, который мы запускали ранее и который завершился за минуту.
Так что будьте терпеливы, пока инструменты выполняются.
В целом, этим системам нужно время, чтобы собрать и обработать информацию, и к этому нужно просто привыкнуть.
Итоговое резюме будет следующим:
С полным результатом можно ознакомиться здесь.
Новости будут, естественно, различаться в зависимости от того, когда вы запустите рабочий процесс. Я запускал его 28 марта, поэтому пример отчёта будет для этой даты.
Система должна сохранить резюме в текстовом документе, но если вы запускаете его внутри контейнера, скорее всего, вам будет сложно получить к нему доступ. Лучше отправить результат куда-нибудь ещё — например, в Google Docs или по электронной почте.
Что касается результатов, я оставлю вам возможность самим оценить разницу между использованием более сложной системы и простой, а также то, как это даёт нам больше контроля над процессом.
Заключительные мысли
Я работаю с хорошим источником данных. Без него пришлось бы добавить гораздо больше обработки ошибок, что ещё сильнее замедлит всё.
Чистые и структурированные данные — это ключ. Без них LLM не будет работать на максимуме своих возможностей.
Даже с хорошими данными всё не идеально. Всё равно нужно работать с агентами, чтобы убедиться, что они делают то, что должны.
Вы, наверное, уже заметили, что система работает — но она ещё не до конца готова.
Кое-что ещё нужно улучшить: преобразование запроса пользователя в более структурированный формат, добавление ограничителей, чтобы агенты всегда использовали свои инструменты, более эффективное резюмирование для сохранения компактности исследовательского документа, улучшение обработки ошибок и введение долгосрочной памяти для лучшего понимания того, что на самом деле нужно пользователю.
Состояние (краткосрочная память) особенно важно, если вы хотите оптимизировать производительность и стоимость.
Сейчас мы просто закидываем каждое сообщение в состояние и даём всем агентам доступ к нему, что не идеально. Мы действительно хотим разделить состояние между командами. В этом случае я этого не сделал, но вы можете попробовать, введя черновик в схему состояния, чтобы изолировать то, что знает каждая команда.
В любом случае, надеюсь, что это был увлекательный опыт, и вы начали понимать, какие результаты можно получить, создавая различные агентные рабочие процессы.
Если вам важно не просто понять основы, а погрузиться в детали и применить их в реальных проектах, приглашаем на серию открытых уроков. Мы сосредоточимся на актуальных и практичных аспектах Data Science и машинного обучения, которые пригодятся как в работе с данными, так и в анализе сложных систем:
28 апреля в 20:00 — Подготовка данных в Pandas
В реальной жизни данные не всегда идеальны. На уроке разберём, как справляться с пропусками, дубликатами и выбросами, чтобы повысить точность анализа.30 апреля в 18:00 — Data Science — это проще, чем кажется!
Урок, который даёт ясное представление о Data Science и машинном обучении. Если вы всё ещё сомневаетесь, что это реально применимо, этот урок для вас.13 мая в 18:00 — Прикладные методы поиска аномалий
Вебинар для тех, кто хочет разобраться, как различные методы поиска аномалий могут быть применены к реальным данным, от простых статистических до сложных моделей.