Оптимизация роя с помощью агентного ИИ с использованием искусственной колонизации пчел (ABC)

Агенты Gemini Bee для адаптивной кластеризации

Делиться

Оглавление

📄Записная книжка Python
🍯Введение
🔍Пример хода поиска агента ABC
⏳Жизненный цикл агента в роевой оптимизации
🐝Три роли пчелиного агента
🪻Набор данных Iris
❄ Кластеризация – Нет меток? Не проблема!
🏋️Модель пригодности для кластеризации
🤔Матрица ошибок как диагностический инструмент
🏃Запуск цикла Agentic AI
📊Отчет о результатах
💬Разработка подсказок для агентов-близнецов
⚠️Проблемы Gemini Agentic AI
⚔️Конкурентная среда в сфере агентного ИИ до 2026 года
✨Заключение и дальнейшая работа

📄Записная книжка Python

Изучите мой интерактивный блокнот в Google Colab — и не стесняйтесь обращаться ко мне в LinkedIn с любыми вопросами или отзывами.

🍯 Введение

Учитывая невероятные инновации в области агентного ИИ, мне захотелось поучаствовать в проекте, который интегрирует подсказки LLM в рабочий процесс анализа данных. Алгоритм искусственной пчелиной колонии (ABC) вдохновлен поведением медоносных пчел при сборе нектара и замечательно работает в природе. Он принадлежит к семейству алгоритмов роевого интеллекта , разработанных для децентрализованных процессов принятия решений, в которых «пчелиные агенты» автономно преследуют свои индивидуальные цели, коллективно улучшая качество общего решения («медоносной ловушки»).

Этот популярный метод широко применяется во многих областях, в частности: планирование, маршрутизация, оптимизация энергопотребления, распределение ресурсов и обнаружение аномалий . Исследователи часто комбинируют алгоритм ABC с нейронными сетями в гибридном подходе, например, используя ABC для настройки гиперпараметров или оптимизации весов модели. Алгоритм особенно актуален, когда данных мало или когда задача носит комбинаторный характер – когда пространство решений растет экспоненциально (или даже факториально) с увеличением числа признаков.

В этом проекте я использовал подход, имитирующий алгоритм роевой оптимизации для адаптивного поиска по сетке . Креативный момент заключается в том, что я применил новые инструменты Google Agentic AI для реализации пчелиных агентов. В алгоритме ABC существует три типа автономных пчелиных агентов, и я определил их роли с помощью текстовых подсказок, созданных на основе новейших модулей Gemini LLM.

Каждый цикл поиска пищи ( итерация алгоритма ) протекает следующим образом:

1. Пчелы-разведчики исследуют → обнаруживают новые источники пищи (возможные решения) .
2. Рабочие пчелы используют → совершенствуют эти источники и танцуют, чтобы поделиться информацией о качестве нектара ( функция приспособленности ).
3. Пчелы-наблюдатели используют ситуацию в своих интересах еще активнее → руководствуясь танцами, они усиливают сосредоточенность колонии на лучших источниках пищи.

🔍Пример хода поиска агента ABC

⏳Жизненный цикл агента в роевой оптимизации

Алгоритм ABC был впервые предложен Дервишем Карабогой в 2005 году. В моей модернизированной метаэвристической адаптации я сосредоточился на цели повышения эффективности кластеризации для неконтролируемого набора данных.

Ниже представлены реализованные мной классы на Python:

1. WebResearcher : Отвечает за исследование и обобщение алгоритмов кластеризации scikit-learn и их ключевых гиперпараметров. Собранная информация имеет решающее значение для генерации точных и эффективных подсказок для пчелиных агентов, и этот класс реализован как агент на основе LLM.
2. ScoutBeeAgent : Генерирует разнообразные исходные варианты кластеризации для набора данных Iris, используя сводные данные о параметрах, предоставленные WebResearcher.
3. EmployedBeeAgent : Уточняет существующие варианты решений, исследуя локальные области параметров и используя данные WebResearcher для внесения обоснованных корректировок.
4. OnlookerBeeAgent : Оценивает сгенерированные и уточненные кандидаты, выбирая наиболее перспективные для дальнейшей итерации.
5. Runner : Координирует общий цикл оптимизации ABC, организуя и координируя поток агентов Gemini AI. Он управляет последовательностью действий между различными агентами-пчелами и отслеживает общий прогресс. В то время как Runner обеспечивает структуру и контроль, каждый агент-пчела работает полностью распределенным и автономным образом, независимо выполняя свои специализированные задачи без централизованного управления.
6. FitnessModel : Оценивает качество каждого варианта решения с использованием скорректированного индекса Рэнда (ARI) с целью минимизации значения 1 – ARI для достижения лучших результатов кластеризации.
7. Программа Reporter : визуализирует сходимость наилучших значений ARI на протяжении итераций и сравнивает наиболее эффективные решения с базовыми моделями кластеризации.

🐝Три роли пчелиного агента

Агенты определяют значения параметров и диапазоны с помощью подсказок на естественном языке, предоставляемых генеративной модели ИИ Gemini. Все три агента наследуют от базового класса BeeAgent, который обрабатывает общую настройку и отслеживание кандидатов. Часть каждой подсказки формируется на основе WebResearcher, который обобщает алгоритмы кластеризации scikit-learn и их ключевые гиперпараметры для обеспечения точности и релевантности. Вот как работает каждый агент:

• 🐝 ScoutBeeAgent (Генерация начальных параметров): Создает подсказки, позволяющие LLM проявить некоторую креативность в рамках заданных ограничений. Параметр allowed_algorithms определяет, какие модели следует рассматривать из популярных алгоритмов кластеризации в scikit-learn. Модель Gemini интерпретирует эти инструкции и генерирует разнообразные варианты решений, обеспечивая отсутствие дубликатов и сбалансированное распределение по алгоритмам.
• 🐝 EmployedBeeAgent (Уточнение параметров): Генерирует подсказки с инструкциями по уточнению, направляя LLM на корректировку параметров примерно на ±10–20%, оставаясь в допустимых диапазонах и избегая создания неподдерживаемых параметров. Он берет текущие решения и применяет эти правила для создания слегка измененных (уточненных) вариантов в локальной окрестности существующего пространства параметров.
• 🐝 OnlookerBeeAgent (Оценка и отбор): генерирует подсказки, оценивающие кандидатов, сгенерированных и уточненных другими агентами. Используя показатель пригодности, основанный на скорректированном индексе Рэнда (ARI), он выбирает k наиболее перспективных решений, поддерживает разнообразие алгоритма и избегает дубликатов. Это усиливает ориентацию колонии на наиболее сильных кандидатов.

По сути, код на Python определяет цель задачи, параметры, ограничения и возвращаемые значения в виде текста в подсказках. Затем генеративная модель ИИ (Gemini) «читает» и «понимает» эти инструкции, чтобы получить или изменить фактические числовые и категориальные значения параметров для алгоритмов кластеризации. Различные модели LLM могут по-разному реагировать на незначительные изменения во входном тексте, поэтому важно поэкспериментировать с формулировкой подсказок для трех классов агентов. Для дальнейшего уточнения формулировки вы всегда можете обратиться к предпочитаемой вами модели LLM.

🪻Набор данных Iris

Естественным выбором для этого исследования является классический набор данных о цветах ирисов сэра Рональда Фишера, представленный в его статье 1936 года. В последующих разделах этот набор данных используется в качестве небольшого, четко определенного демонстрационного примера для иллюстрации того, как предложенный метод оптимизации ABC может быть применен в контексте задачи кластеризации .

Набор данных Iris (лицензия: CC0 1.0) содержит 150 размеченных образцов, каждый из которых принадлежит к одному из 3 классов ирисов : Iris Setosa, Iris Versicolor, Iris Virginica. Каждому образцу цветка соответствует 4 числовых признака : длина чашелистика, ширина чашелистика, длина лепестка, ширина лепестка.

Как показано на графиках попарных взаимосвязей и графиках важности признаков на основе взаимной информации, длина и ширина лепестков являются наиболее информативными признаками при сравнении с целевыми метками набора данных Iris.

Взаимная информация (MI) вычисляется для каждого признака отдельно относительно меток, тогда как скорректированный индекс Рэнда (ARI) , используемый в этом проекте для оценки пригодности, измеряет соответствие между двумя разделами (предполагаемые метки кластеров и истинные метки). Следует отметить, что даже если применяется отбор признаков, поскольку ирисы разноцветные и ирисы виргинские имеют схожие длину и ширину лепестков, их кластеры перекрываются в пространстве признаков. В результате ARI может быть высоким, но не может достичь идеального значения 1,0.

❄ Кластеризация – Нет меток? Не проблема!

Алгоритмы кластеризации являются краеугольным камнем обучения без учителя , поэтому я решил сосредоточиться на цели слепого определения классов цветов, основываясь исключительно на их характеристиках. Другими словами, модель не обучалась на метках цветов; эти метки использовались только для проверки показателей производительности. Традиционные алгоритмы кластеризации, такие как KMeans или DBSCAN, часто испытывают проблемы с чувствительностью к параметрам и изменчивостью набора данных. Поэтому метаэвристический алгоритм, такой как ABC, который уравновешивает исследование и использование , представляется многообещающим.

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

Здесь представлено краткое визуальное сравнение различных алгоритмов кластеризации, примененных к нескольким тестовым наборам данных; разные цвета обозначают разные кластеры, которые каждый алгоритм обнаружил для двумерных представлений:

В классическом наборе данных Iris два наиболее похожих вида — versicolor и virginica — часто представляют собой проблему для алгоритмов кластеризации. Многие методы ошибочно объединяют их в один кластер, рассматривая их как одну непрерывную плотную область. В отличие от них, более обособленный вид setosa неизменно определяется как отдельный кластер.

Таблица, сравнивающая несколько популярных алгоритмов кластеризации, доступных в библиотеке scikit-learn :

K-средних как базовый пример кластеризации

Алгоритм K-средних — один из наиболее широко используемых алгоритмов кластеризации, ценимый за свою простоту и эффективность. Ввиду его распространенности, я опишу его здесь более подробно как показательный пример того, как обычно выполняется кластеризация. Его популярность обусловлена простотой и эффективностью, хотя у него есть и ограничения. Ключевым недостатком является то, что количество кластеров k должно быть задано заранее.

Как работает алгоритм K-средних

1. Инициализация центроидов:
   Выберите k начальных центроидов либо случайным образом, либо с помощью более эффективных стратегий, таких как K-Means++, которые распределяют их для улучшения качества кластеризации.
2. Присвоить точки кластерам:
   Представьте каждую точку данных в виде n-мерного вектора, где каждая компонента соответствует одному признаку. Присвойте точкам местоположение ближайшего центроида, используя метрику расстояния (обычно евклидову). В многомерных пространствах этот шаг усложняется «проклятием размерности», из-за которого расстояния теряют свою дискриминационную способность.
3. Обновите центроиды и повторите:
   Пересчитайте каждый центроид как среднее значение всех точек в его кластере, затем переназначьте точки ближайшему центроиду. Повторяйте до тех пор, пока назначения не стабилизируются — это и есть сходимость.

Практические соображения

• Проклятие размерности : в очень больших размерностях метрики расстояния становятся менее эффективными, что снижает надежность кластеризации.
• Снижение размерности : Для упрощения пространства признаков и улучшения результатов перед алгоритмом K-средних часто применяются такие методы, как PCA или t-SNE .
• Выбор K : Такие методы, как метод «локтя» , оценка силуэта или метаэвристические алгоритмы (например, оптимизация ABC), помогают оценить оптимальное количество кластеров.

🏋️Модель пригодности для кластеризации

Модель FitnessModel оценивает варианты кластеризации на наборе данных. Цель хорошего алгоритма кластеризации — создать кластеры, которые в идеале точно соответствуют истинным классам, но обычно это не идеальное совпадение. ARI (скорректированный индекс Рэнда) используется для измерения сходства между двумя кластеризациями (предполагаемой и истинной) — это широко используемая метрика для оценки эффективности кластеризации, поскольку она корректирует случайное совпадение, работает с различными алгоритмами кластеризации и предоставляет четкую шкалу от −1 до +1, которую легко интерпретировать.

Показатель пригодности равен 1 – ARI, поэтому чем ниже значение пригодности, тем лучше. Это позволяет алгоритму ABC напрямую оптимизировать качество кластеризации. Ниже показан пример запуска начальных итераций алгоритма ABC с агентами Gemini, который я разработал, включая предварительный просмотр необработанных текстов ответов LLM. Обратите внимание, как модель GMM ( Gaussian Mixture Models) неуклонно улучшается по мере выбора новых кандидатов на каждой итерации различными агентами-пчелами. Для просмотра логов других итераций обратитесь к блокноту Google Colab.

Запуск алгоритма ABC с использованием модели пригодности для набора данных: Iris. Признаки: 4, Классы: 3. Базовые модели (ARI): {'DBSCAN': 0.6309344087637648, 'KMeans': 0.6201351808870379, 'Agglomerative': 0.6153229932145449, 'GMM': 0.5164585360868599, 'Spectral': 0.6451422031981431, 'MeanShift': 0.5681159420289855}. Runner: Инициализация агента Scout для получения начальных решений… Scout: Генерация начальных решений-кандидатов… Scout: Отправка запроса модели Gemini… n_candidates=12 Scout: Получен ответ от модели Gemini. Scout: Исходный текст ответа: «`json[{«model»:»KMeans»,»params»:{«n_clusters»:3,»init»:»k-means++»,»n_init»:10,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_clusters»:4,»init»:»random»,»n_init»:10,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_clusters»:5,»init»:»k-mean… Scout: Сгенерированы начальные кандидаты. Runner: Агент Scout вернул 12 начальных решений. Runner: Начало итерации 1/8… Runner: Агенты завершили действия для итерации 1. — Подробности итерации 1 — Кандидат GMM 1 (Источник: Scout-10010): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42} Кандидат KMeans 2 (Источник: Scout-10000): Лучший предыдущий ARI=0.620, Текущий ARI=0.620, Параметры: {'n_clusters': 3, 'init': 'k-means++', 'n_init': 10, 'random_state': 42} Кандидат DBSCAN 3 (Источник: Scout-10004): Лучший предыдущий ARI=0.550, Текущий ARI=0.550, Параметры: {'eps': 0.7, 'min_samples': 4} Кандидат GMM 4 (Источник: Scout-10009): Лучший предыдущий ARI = 0,820, Текущий ARI = 0,516, Параметры: {'n_components': 3, 'covariance_type': 'full', 'max_iter': 100, 'random_state': 42} Кандидат KMeans 5 (Источник: Scout-10001): Лучший предыдущий ARI = 0,620, Текущий ARI = 0,462, Параметры: {'n_clusters': 4, 'init': 'random', 'n_init': 10, 'random_state': 42} Кандидат DBSCAN 6 (Источник: Scout-10003): Лучший предыдущий ARI = 0,550, Текущий ARI = 0,442, Параметры: {'eps': 0,5, 'min_samples': 5} Кандидат KMeans 7 (Источник: Scout-10002): Лучший предыдущий ARI=0.620, Текущий ARI=0.435, Параметры: {'n_clusters': 5, 'init': 'k-means++', 'n_init': 5, 'random_state': 42} Кандидат DBSCAN 8 (Источник: Scout-10005): Лучший предыдущий ARI=0.550, Текущий ARI=0.234, Параметры: {'eps': 0.4, 'min_samples': 6} *** Лучший глобальный результат на данный момент: ARI=0.820, Кандидат={'model': 'GMM', 'params': {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42}, 'origin_agent': 'Scout-10010', 'current_ari_for_display': 0.8202989638185834} —————————— Runner: Начало итерации 2/8… Scout Генерация начальных решений-кандидатов… Scout: Отправка запроса модели Gemini… n_candidates=12 Employed Уточнение текущих решений… Employed: Отправка запроса модели Gemini… n_variants=12 Onlooker Оценка кандидатов и выбор перспективных… Onlooker: Отправка запроса модели Gemini… top_k=5 Scout: Получен ответ от модели Gemini. Scout: Текст ответа: «`json[{«model»:»KMeans»,»params»:{«n_clusters»:3,»init»:»k-means++»,»n_init»:10,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_clusters»:4,»init»:»random»,»n_init»:10,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_clusters»:5,»init»:»k-mean… Scout: Сгенерированы начальные кандидаты. Employed: Получен ответ от модели Gemini. Используемый: Исходный текст ответа: «`json[{«model»:»GMM»,»params»:{«n_components»:5,»covariance_type»:»tied»,»max_iter»:100,»random_state»:42}},{«model»:»GMM»,»params»:{«n_components»:3,»covariance_type»:»full»,»max_iter»:100,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_cluster… Используемый: Решения уточнены. Наблюдатель: Получен ответ от модели Gemini. Наблюдатель: Исходный текст ответа: «`json[{«model»:»GMM»,»params»:{«n_components»:4,»covariance_type»:»tied»,»max_iter»:100,»random_state»:42}},{«model»:»KMeans»,»params»:{«n_clusters»:3,»init»:»k-means++»,»n_init»:10,»random_state»:42}},{«model»:»DBSCAN»,»params»:{«eps»:0.7,»min_sam… Наблюдатель: Выбраны перспективные кандидаты. Участник: Агенты выполнили действия для итерации 2. — Подробности итерации 2 — Кандидат GMM 1 (Источник: Scout-10022): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42} Кандидат GMM 2 (Источник: Scout-10010): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42} Кандидат GMM 3 (Источник: Onlooker-30000): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42} Кандидат GMM 4 (Источник: Employed-20007): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 80, 'random_state': 42} Кандидат GMM 5 (Источник: Employed-20006): Лучший предыдущий ARI=0.820, Текущий ARI=0.820, Параметры: {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 120, 'random_state': 42} Кандидат GMM 6 (Источник: Employed-20000): Лучший предыдущий ARI=0.820, Текущий ARI=0.693, Параметры: {'n_components': 5, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42} Кандидат KMeans 7 (Источник: Scout-10012): Лучший предыдущий ARI=0.620, Текущий ARI=0.620, Параметры: {'n_clusters': 3, 'init': 'k-means++', 'n_init': 10, 'random_state': 42} Кандидат KMeans 8 (Источник: Scout-10000): Лучший предыдущий ARI=0.620, Текущий ARI=0.620, Параметры: {'n_clusters': 3, 'init': 'k-means++', 'n_init': 10, 'random_state': 42} *** Лучший глобальный результат на данный момент: ARI=0.820, Кандидат={'model': 'GMM', 'params': {'n_components': 4, 'covariance_type': 'tied', 'max_iter': 100, 'random_state': 42}, 'origin_agent': 'Scout-10010', 'current_ari_for_display': 0.8202989638185834}

🤔Матрица ошибок как диагностический инструмент

В то время как скорректированный индекс Рэнда (ARI) дает единый показатель качества кластеризации, матрица ошибок показывает, где происходят ошибки классификации, демонстрируя, как истинные классы распределены по прогнозируемым кластерам.

В наборе данных Iris библиотека scikit-learn кодирует виды в фиксированном порядке:

0 = Сетоза, 1 = Версиколор, 2 = Вирджиния .

Несмотря на то, что существует всего три истинных вида , алгоритм, представленный ниже, ошибочно выделил четыре кластера . Матрица иллюстрирует это несоответствие:

[[ 0 6 44 0]
[ 2 0 0 48]
[49 0 0 1 ]
[ 0 0 0 0 ]]

⚠️ Примечание: порядок столбцов (кластеров) не обязательно соответствует порядку строк (истинных классов). Идентификаторы кластеров — это произвольные метки, присвоенные алгоритмом, и они не несут в себе никакого смыслового значения.

Построчная интерпретация (идентификаторы строк и столбцов начинаются с 0)

• Строка 0: [ 0 6 44 0]
  Класс Setosa → Его образцы попадают только в столбцы 1 и 2, не пересекаясь с Versicolor или Virginica. Эти два столбца следовало бы рассматривать как единый кластер, соответствующий классу Setosa.
• Строка 1: [ 2 0 0 48]
  Класс Versicolor → Разделение между столбцами 0 и 3 показывает, что алгоритм не смог четко выделить класс Versicolor.
• Строка 2: [49 0 0 1]
  Класс Virginica → Также разделен между столбцами 0 и 3, перекрываясь с Versicolor, а не образуя отдельный кластер.
• Строка 3: [ 0 0 0 0]
  Дополнительный ошибочный кластер → Здесь нет истинных образцов, что отражает тот факт, что алгоритм создал 4 кластера для набора данных, содержащего всего 3 класса.

📌Матрица ошибок показывает, что Setosa является отдельным видом (его кластеры не перекрываются с другими видами), в то время как Versicolor и Virginica не разделены четко — оба вида распределены по одним и тем же двум кластерам (столбцы 0 и 3). Это перекрытие подчеркивает сложность алгоритма в их различении. Матрица ошибок делает эти ошибки классификации видимыми таким образом, как это не может сделать один показатель ARI.

🏃Запуск цикла Agentic AI

Бегун организует итерации:

1. Пчелы-разведчицы предлагают разнообразные решения.
2. Рабочие пчёлы их перерабатывают.
3. Пчелы-наблюдатели выбирают наиболее перспективные экземпляры.
4. Список решений обновлен.
5. Наилучший ARI для каждой итерации отслеживается.

В классе Runner и во всем алгоритме искусственной пчелиной колонии (ABC) кандидат обозначает конкретную модель кластеризации вместе с заданными параметрами. В приведенном ниже примере из пула решений возвращаются два кандидата.

Процесс отбора кандидатов осуществляется с помощью класса Python concurrent.futures.ThreadPoolExecutor , который обеспечивает параллельное выполнение. В результате объекты ScoutAgent , EmployedBeeAgent и OnlookerBeeAgent выполняются асинхронно в отдельных потоках на каждой итерации алгоритма.

Метод runner.run() возвращает два объекта:

solution_pool: Это список наиболее перспективных кандидатов размером pool_size (каждый из которых представляет собой словарь, содержащий модель и ее параметры), найденных на всех итерациях. Этот список отсортирован по показателю пригодности (ARI), поэтому самый первый элемент, solution_pool[0], будет представлять собой наиболее подходящую модель и ее конкретные параметры, обнаруженные алгоритмом ABC.

best_history: Это список, отслеживающий только лучшие показатели скорректированного индекса рэнда.

Например:

solution_pool = [ { «model»: «KMeans», «params»: {«n_clusters»: 3, «init»: «k-means++»}, «origin_agent»: «Employed», «current_ari_for_display»: 0.742 }, { «model»: «AgglomerativeClustering», «params»: {«n_clusters»: 3, «linkage»: «ward»}, «origin_agent»: «Onlooker», «current_ari_for_display»: 0.715 } ] best_history = [ {«ari»: 0.642, «model»: «KMeans», «params»: {«n_clusters»: 3, «init»: «random»}}, {«ari»: 0.742, «model»: «KMeans», «params»: {«n_clusters»: 3, «init»: «k-means++»}} ]

Настройка пула решений с помощью ThreadPoolExecutor

ThreadPoolExecutor(): Инициализирует пул рабочих потоков, которые могут выполнять задачи одновременно.

ex.submit(…): Отправляет метод действия каждого агента в пул потоков как отдельную задачу.

from concurrent.futures import ThreadPoolExecutor import copy # … внутри Runner.run() … for it in range(iterations): print(f»Runner: Starting iteration {it+1}/{iterations}…») if it == 0: results = [] else: # Используйте потоки вместо процессов с ThreadPoolExecutor(), как в примере: futures = [ ex.submit(self.scout.act), ex.submit(self.employed.act, solution_pool), ex.submit(self.onlooker.act, solution_pool) ] results = [f.result() for f in futures] print(f»Runner: Agents completed actions for iteration {it+1}.») # … остальная часть цикла без изменений …

Метод `act` каждого агента отправляется в пул потоков, что позволяет им выполняться параллельно. Вызов `f.result()` гарантирует, что исполнитель дождется завершения всех задач, прежде чем двигаться дальше.

Данная конструкция позволяет достичь двух целей:

1. Параллельное выполнение в рамках итерации — агенты действуют одновременно, имитируя поведение настоящей пчелиной колонии.
2. Управление последовательной итерацией — Бегун продвигается вперед только после того, как все агенты завершат свою работу, что обеспечивает упорядоченность и детерминированность всего цикла.

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

Настройка пула решений с помощью ProcessPoolExecutor

Хотя ThreadPoolExecutor обеспечивает параллелизм за счет потоков, его можно легко заменить на ProcessPoolExecutor для достижения истинного параллельного выполнения на ЦП .

С помощью ProcessPoolExecutor каждый агент работает в отдельном процессе , что обходит блокировку глобального интерпретатора ( GIL ) Python. GIL — это мьютекс (блокировка взаимного исключения), который гарантирует, что только один поток выполняет байт-код Python одновременно, даже в многоядерных системах. Использование процессов вместо потоков позволяет в полной мере использовать ресурсы нескольких ядер ЦП для ресурсоемких вычислительных задач, обеспечивая подлинный параллелизм и улучшенную производительность.

from concurrent.futures import ProcessPoolExecutor import copy # … внутри Runner.run() … for it in range(iterations): print(f»Runner: Starting iteration {it+1}/{iterations}…») if it == 0: results = [] else: # Используйте процессы вместо потоков с ProcessPoolExecutor() как ex: futures = [ ex.submit(self.scout.act), ex.submit(self.employed.act, solution_pool), ex.submit(self.onlooker.act, solution_pool) ] results = [f.result() for f in futures] print(f»Runner: Agents completed actions for iteration {it+1}.») # … остальная часть цикла без изменений …

Основные различия между ProcessPoolExecutor и ThreadPoolExecutor

• ProcessPoolExecutor запускает отдельные процессы Python , а не потоки.
• Каждый агент работает независимо на отдельном ядре центрального процессора.
• Это позволяет избежать GIL (Global Inclusion Interaction), поэтому задачи, сильно зависящие от ЦП (такие как кластеризация, оценка пригодности, численная оптимизация), действительно выполняются параллельно. Задача, сильно зависящая от ЦП, — это любое вычисление, где ограничивающим фактором является скорость процессора, а не ожидание ввода/вывода (I/O).
• Поскольку процессы работают в отдельных областях памяти, они не могут напрямую обмениваться объектами. Вместо этого все, что передается между ними, должно быть сериализовано (записано в сериализованный формат, например, pickle). Простые объекты Python, такие как словари, списки, строки и числа, можно сериализовать, поэтому можно безопасно обмениваться словарями-кандидатами.

📌 Главный вывод:

✅ Используйте ProcessPoolExecutor, если ваши агенты выполняют ресурсоемкие вычисления (матричные операции, кластеризация, обучение машинного обучения).

❌ Используйте ThreadPoolExecutor, если ваши агенты в основном работают с операциями ввода-вывода (ожидание данных, сети, диска).

Почему некоторые из значений параметров-кандидатов повторяются в разных итерациях?

Повторение значений параметров-кандидатов на разных итерациях является естественным следствием работы алгоритма искусственной пчелиной колонии и взаимодействия агентов:

Исследование агента ScoutBee : Задача агента ScoutBeeAgent — генерировать новые и разнообразные варианты решений. Хотя он стремится к разнообразию, при ограниченном пространстве параметров или если генеративная модель обнаруживает, что определенные комбинации параметров неизменно эффективны, он может предлагать похожие решения в разных итерациях.

Использование возможностей агента EmployedBeeAgent: EmployedBeeAgent совершенствует существующие перспективные решения. Если решение уже очень хорошее или близко к оптимальной конфигурации, исследование «локального окружения» (например, корректировка параметров на ±10-20%) может привести к тем же или очень похожим значениям параметров, особенно после округления или если корректировки параметров незначительны.

Выбор агента OnlookerBee: OnlookerBeeAgent выбирает k наиболее перспективных решений из большего набора кандидатов (который включает в себя недавно найденные, уточненные с помощью работающих алгоритмов и ранее перспективные решения). Если алгоритм сходится или если несколько различных решений дают очень похожие высокие оценки пригодности, OnlookerBeeAgent может неоднократно выбирать наборы параметров, которые фактически идентичны от одной итерации к другой.

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

Сходимость: По мере выполнения алгоритма ABC ожидается его сходимость к оптимальным или близким к оптимальным решениям. Эта сходимость часто означает сужение пространства поиска, и агенты неоднократно находят одни и те же высокоэффективные конфигурации параметров, если не применяется какой-либо метод отсечения (например, дедупликация).

📊Отчет о результатах

Сравнительный анализ стандартных алгоритмов кластеризации

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

• KMeans
• DBSCAN
• Агломеративная кластеризация
• Модели гауссовых смесей (GMM)
• Спектральная кластеризация
• MeanShift

Как показано в блокноте Google Colab, агенты ABC обнаружили наборы параметров, которые значительно улучшили скорректированный индекс Рэнда (ARI), уменьшив количество ошибок классификации между близкородственными классами Versicolor и Virginica.

Результаты работы репортера

Класс Reporter отвечает за генерацию окончательных результатов оценки после выполнения оптимизации с помощью алгоритма искусственной пчелиной колонии (ABC). Он выполняет три основные функции:

1. Таблица сравнения
   • Сравнивает скорректированный индекс Рэнда (ARI) каждого предлагаемого решения с базовыми моделями кластеризации.
   • Сообщает об улучшении (candidate_ari – baseline_ari).
2. Отображение матрицы ошибок
   • Выводит матрицу ошибок лучшего варианта решения, демонстрирующую эффективность на уровне классов и количество ошибок классификации.
3. Визуализация сходимости

• Отображает динамику изменения наилучшего значения ARI на протяжении итераций.
• Добавляет к графику названия моделей и параметры для каждой итерации.

💬Разработка подсказок для агентов-близнецов

Для обеспечения структурированного подхода я решил разработать для каждого агента подсказку, используя следующий шаблон:

• Цель задачи: Чего должен достичь агент.

• Параметры : Входные данные, такие как название набора данных, количество кандидатов на определенный тип агента, разрешенные алгоритмы и словарь входных гиперпараметров, возвращаемый WebResearcher через его запрос LLM.

• Ограничения: Необходимо обеспечить уникальность каждого кандидата, поддерживать сбалансированное распределение по алгоритмам, требовать, чтобы гиперпараметры оставались в допустимых диапазонах.

• Возвращаемые значения: JSON-список возможных решений.

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

generation_config={ «temperature»: 0.0, «top_p»: 1.0, «top_k»: 1, «max_output_tokens»: 4096 } res = genai_model.generate_content(prompt, generation_config=generation_config)

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

⚠️ Проблемы с Gemini Agentic AI

Типы моделей искусственного интеллекта Gemini

• Lite (Flash‑Lite): Приоритет — скорость и экономичность. Идеально подходит для выполнения больших объемов задач, таких как перевод или классификация.
• Flash: Хорошо подходит для производственных задач, требующих масштабируемости и умеренной логики.
• Pro: Флагманский уровень – лучше всего подходит для сложных логических рассуждений, понимания мультимодальных данных (текст, изображения, аудио, видео) и задач, связанных с агентным ИИ.

Почему одних только подсказок недостаточно в облегченных моделях?

Я столкнулся с распространенным ограничением моделей «Lite»:
Модели с низким уровнем детализации (LLM) не всегда надежно выполняют инструкции типа «всегда включайте эти параметры» только потому, что вы указали их в запросе. На сегодняшний день модели часто возвращаются к значениям по умолчанию или минимальным наборам, если после генерации не обеспечивается соблюдение структуры. Почему явный запрос все равно не сработал:

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

📌 Главный вывод: Одних подсказок недостаточно для обеспечения соответствия требованиям. Для того чтобы выходные данные постоянно содержали необходимые параметры, необходимы подсказки и контроль схемы .

Оперативное решение вопросов соответствия требованиям и разработка схем.

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

• Пример инструкции: «Возвращаемые значения: выводите ТОЛЬКО словарь в формате JSON. Длина возвращаемой строки не должна превышать 1024 символа».
• Наблюдаемый результат: len(res_text) = 1036 – количество ответов превысило лимит.
• Отсутствующие поля: Обязательные поля иногда не отображались, даже если были четко указаны. Предоставление конкретных примеров результатов улучшило соблюдение требований.
• Практическое решение: объединить запросы с обеспечением соблюдения схемы (например, проверка обязательных ключей, проверка длины) и нормализацией после генерации для гарантирования структуры.

Ошибки пустых кандидатов в API Gemini

Иногда я получал такой ответ:

>> ScoutAgent: Ошибка при вызове API (попытка 1/3): Недопустимая операция: Быстрый доступ response.text требует, чтобы ответ содержал допустимую часть, но она не была возвращена. finish_reason кандидата равен 2.

Это сообщение об ошибке означает, что модель фактически не вернула никакого полезного контента в своем ответе, поэтому, когда мой код попытался получить доступ к response.text, не было допустимой «Части» для чтения. Ключевая подсказка — finish_reason = 2 , что в API Google соответствует СТОП или состоянию отсутствия сгенерированного контента (модель завершила работу, не создав текст).

Почему это происходит:

• Пустой кандидат: вызов API прошел успешно, но модель не выдала никакого результата.
• FinishReason = 2: Указывает, что генерация остановилась до получения корректной детали.
• Быстрая ошибка доступа: Поскольку response.text ожидает как минимум одну допустимую текстовую часть, он выдает ошибку, если таковых нет.

Как с этим справиться:

• Перед обращением к response.text проверьте finish_reason. Читайте текст только в том случае, если кандидат содержит допустимую часть.
• Добавьте резервную логику: если текст не возвращается, запишите причину завершения и повторите попытку или обработайте проблему корректно.
• Проверка соответствия схеме: Перед анализом проверьте наличие обязательных полей в ответе.

📌 Главный вывод: это не ошибка сети — модель сигнализирует о том, что процесс остановился, не сгенерировав текст. Полный список значений FinishReason и рекомендации по их интерпретации можно найти в документации Google: Generate Content API – FinishReason.

Периодические ошибки подключения к API.

В отдельных случаях вызов API Gemini завершался с ошибкой:

• Ошибка: ConnectionError: ('Соединение прервано.', RemoteDisconnected('Удаленный сервер закрыл соединение без ответа'))

📌 Главный вывод: Это сетевая ошибка, возникшая без изменений в коде, что указывает на временные проблемы с сетью или сервисом. Добавьте повторные попытки с экспоненциальной задержкой, таймаутами и надежным логированием для сбора контекста (размер запроса, ограничения скорости, причина завершения) и обеспечения корректного восстановления.

Вопросы безопасности агентов

Ещё один важный момент, особенно если вы используете агенты в корпоративных целях: безопасность имеет первостепенное значение!

⚠️ Обеспечьте строгий контроль за взаимодействием агентов и LLM. Активно предотвращайте удаление агентами критически важных файлов, совершение действий, не относящихся к теме, несанкционированные вызовы внешних API и т. д.

📌 Главный вывод: Примените принцип наименьших привилегий.

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

⚔️Конкурентная среда в сфере агентного ИИ до 2026 года

Поставщики моделей

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

Фреймворки оркестрации агентов

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

✨Заключение и дальнейшая работа

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

Дальнейшая работа

• Применение метаэвристики ABC к более крупным и разнообразным наборам данных.
• Расширение возможностей агента WebResearcher для автоматического создания наборов данных из источников, специфичных для конкретной предметной области (например, Королевские ботанические сады Кью – POWO), вдохновленное новаторской работой сэра Рональда Фишера в области статистической ботаники.
• Проведение экспериментов с расширенным пулом рабочих потоков и корректировка количества кандидатов для каждого типа пчелиных агентов.
• Исследование полуконтролируемой кластеризации, в которой небольшой размеченный набор данных дополняет более крупный неразмеченный набор.
• Сравнение результатов, полученных с помощью API Gemini от Google, с результатами, полученными с помощью API других поставщиков.

Источник: towardsdatascience.com