Семинар-2
Семинар №2. Агентный подход к поддержке принятия решений
Что такое «решение» в сложной, динамичной среде? Это не просто выбор из пункта А или Б. Это процесс, вовлекающий множество источников данных, противоречивые интересы, неопределенность и ограниченные ресурсы. Традиционные системы поддержки принятия решений часто работают как монолитные базы данных с набором отчетов. Они полезны, но недостаточно гибки для современного мира.
Создание скоординированной совокупности узкоспециализированных автономных программных сущностей, обладающих своими знаниями и целями, способной к коммуникации и кооперации для достижения общей цели называется агентным подходом.
Агент (Software Agent) – это компьютерная система, находящаяся в некоторой среде, которая способна к автономным действиям в этой среде для достижения поставленных перед ней целей.
Ключевые свойства интеллектуального агента:
· Автономность: Действует без прямого вмешательства извне.
· Реактивность: Воспринимает среду и реагирует на ее изменения.
· Проактивность: Не просто реагирует, но и проявляет целенаправленное поведение.
· Способность к коммуникации (Social Ability): Взаимодействует с другими агентами по стандартизированным протоколам.
2. Многоагентные системы (Multi-Agent Systems, MAS) как основа для СППР
MAS – это сеть взаимодействующих агентов, решающая задачи, которые не под силу одному агенту.
Архитектура агентной СППР:
1. Пользователь-агент (User Interface Agent): Взаимодействует с лицом, принимающим решение (ЛПР). Анализирует запросы, предпочтения, представляет результаты в удобной форме.
2. Информационные агенты (Information Agents): Специализируются на поиске, фильтрации и интеграции данных из различных источников (базы данных, датчики, внешние API, новостные ленты).
3. Агенты-эксперты (Expertise Agents): Воплощают в себе знания и модели принятия решений (например, агент для финансового прогнозирования, агент для оценки рисков, агент для оптимизации логистики).
4. Агент-координатор (Mediator Agent): Управляет взаимодействием между другими агентами. Разрешает конфликты, распределяет задачи, синтезирует финальные рекомендации.
5. Агент-посредник (Broker Agent): Знает, «кто есть кто» в системе. Выполняет функцию «желтых страниц», помогая агентам находить друг друга для сотрудничества.
Пример: «Оптимизация глобальной цепочки поставок»
· Проблема: Срыв поставок из-за погодных условий в Азии. Нужно перенаправить груз, минимизировав убытки и задержки.
· Агентное решение:
· Информационный агент по логистике фиксирует задержку.
· Агент-координатор инициирует процесс перепланирования.
· Агенты-эксперты по альтернативным маршрутам, таможенному оформлению, стоимости перевозки активируются и начинают «торговаться».
· Агент-эксперт по рискам оценивает надежность новых поставщиков.
· Пользователь-агент представляет ЛПР несколько сценариев с оценкой по ключевым показателям (время, стоимость, риск).
Система не просто выдает сырые данные. Она моделирует переговоры и конкурентное взаимодействие, рождая решение, которое было бы трудно просчитать централизованно.
3. Ключевые технологические вызовы и направления исследований
1. Онтологии и семантика: Как агентам с разной специализацией понять друг друга? Необходимы общие словари и модели данных (онтологии).
2. Координация и кооперация: Как избежать хаоса? Механизмы: аукционы (задача назначается агенту, предложившему лучшую цену), коалиции (агенты объединяются во временные команды для сложной задачи), протоколы взаимодействия (например, FIPA-стандарты).
3. Переговоры (Negotiation): Как агенты с противоположными интересами (например, агент-покупатель и агент-продавец) могут прийти к соглашению? Используются теории игр и алгоритмы поиска консенсуса.
4. Trust и Reputation: Как агенту выбрать надежного партнера? Вводятся системы репутации, где агенты оставляют друг о друге «отзывы».
Практикум по программированию к Семинару №2
Цель: Реализовать ключевые аспекты агентного подхода и прочувствовать их преимущества и сложности.
Задача 1: "Реактивный агент для мониторинга"
Концепция: Самый простой тип агента — реактивный. Он не строит сложных моделей мира, а просто реагирует на изменения в среде по принципу «стимул-реакция».
Постановка задачи: Напишите агента для мониторинга цены акции.
1. Среда: Ваш агент получает на вход поток чисел (например, из файла или генерируемый случайным образом), представляющих цену акции в последовательные моменты времени.
2. Поведение агента: Агент должен иметь два порога:
· buy_threshold (например, -3%): Если цена падает ниже этого порога по сравнению с начальной ценой, агент выдает действие "BUY".
· sell_threshold (например, +5%): Если цена поднимается выше этого порога, агент выдает действие "SELL".
3. Выход: Агент должен выводить в консоль сообщения вида: [Time: 5] Price: 95.0 -> ACTION: BUY.
Что проверить: Насколько просто изменить логику агента? Попробуйте поменять пороги и увидеть, как меняется его поведение.
Задача 2: «Проактивный агент-планировщик»
Концепция: Проактивный агент имеет внутреннюю цель и планирует последовательность действий для ее достижения.
Постановка задачи: Реализуйте агента-логиста, который должен доставить пакет из точки A в точку D.
1. Среда: Представлена в виде графа (словаря). Например:
```python
graph = {
'A': {'B': 5, 'C': 2},
'B': {'D': 4},
'C': {'D': 7, 'B': 3},
'D': {}
}
```
2. Цель агента: Найти путь из start='A' в goal='D' с минимальной общей стоимостью.
3. Внутреннее состояние: Агент должен использовать алгоритм поиска пути (например, А* или Dijkstra) для построения плана до начала движения.
4. Исполнение: После построения плана (например, ['A', 'C', 'B', 'D'] с стоимостью 9) агент должен "симулировать" движение, выводя сообщения: "Moving from A to C (cost: 2)", "Moving from C to B (cost: 3)" и т.д.
Что проверить: Как агент реагирует на изменения в графе? Измените веса ребер после того, как агент построил план. Сможет ли он адаптироваться? (В этой задаче — нет, и это станет мостиком к следующей).
Задача 3: «Многоагентная система: Аукцион задач»
Концепция: Несколько агентов с разными возможностями конкурируют или кооперируются за выполнение задач. Здесь мы реализуем механизм координации через аукцион.
Постановка задачи: Создайте систему, где один агент-заказчик (Auctioneer) распределяет задания между несколькими агентами-исполнителями (Bidders) через аукцион.
1. Агенты-исполнители:
· Каждый исполнитель имеет id и speed (скорость выполнения работы, например, 1, 2, 3 ед. времени за задачу).
· Его "ставка" на задачу — это расчетное время выполнения (task_complexity / speed).
2. Агент-заказчик:
· Имеет список задач с указанной сложностью (complexity). Например, tasks = [10, 5, 15].
· На каждую задачу он проводит аукцион: рассылает запрос предложений, собирает ставки от всех исполнителей.
3. Протокол взаимодействия:
1. Call for Proposal (CFP): Заказчик рассылает сообщение: "New task: complexity=10".
2. Bid: Каждый исполнитель вычисляет свое время (10 / speed) и отправляет заказчику ставку: (bidder_id, time).
3. Award: Заказчик выбирает исполнителя с наименьшей ставкой (наименьшим временем) и назначает ему задачу.
4. Confirm: Исполнитель подтверждает получение задачи.
4. Выход системы: Должна быть видна вся "переписка" между агентами.
[AUCTIONEER]: CFP for task with complexity=10.
[BIDDER_1]: My bid is 10.0 hours.
[BIDDER_2]: My bid is 5.0 hours.
[BIDDER_3]: My bid is 3.3 hours.
[AUCTIONEER]: Awarding task to BIDDER_3.
[BIDDER_3]: Confirm. I will complete the task in 3.3 hours.
Что проверить: Эффективно ли распределяются задачи? Что произойдет, если самому быстрому агенту дать все задачи? Появится ли "queue"? Это уже проблема планирования нагрузки.
Задача 4: «Агенты с репутацией»
Концепция: В реальном мире важна не только цена, но и надежность.
Модификация Задачи 3: Добавьте каждому агенту-исполнителю параметр reliability (надежность, от 0.0 до 1.0) и reputation_score (начальный рейтинг, например, 5.0).
· Когда заказчик назначает задачу, он с вероятностью (1 - reliability) исполнитель может "провалить" ее (симуляция сбоя).
· Если исполнитель провалил задачу, его reputation_score уменьшается.
· Теперь заказчик при выборе победителя аукциона учитывает не только ставку (time), но и репутацию. Например, итоговая оценка = time * (1 / reputation_score). Таким образом, агент с плохой репутацией будет проигрывать аукцион, даже если предлагает низкую цену.
Вопросы: Как такая система становится более устойчивой к ненадежным участникам? Не приводит ли это к "вечной каре" для агентов, которые однажды ошиблись? Как ввести механизм "прощения"?
Критерии оценки кода:
1. Четкое разделение на классы: Agent, Environment, Auctioneer, Bidder.
2. Инкапсуляция: Состояние агента (скорость, репутация) должно быть защищено.
3. Механизм обмена сообщениями: Реализован в виде методов send_message(to_agent, message) и receive_message(message).
4. Ясность и читаемость: Код должен быть документирован так, чтобы ваши коллеги могли легко его понять и продолжить разработку.
Процесс принятия решений агентами
Уровень 1: Принятие решений внутри отдельного агента
Каждый агент в системе — это микроменеджер, постоянно принимающий решения.
· В Задаче 1 (Реактивный агент): Решение примитивно, но оно есть. Агент постоянно решает: «При текущей цене 95 — это сигнал к покупке? Или к продаже? Или к бездействию?». Его решение основано на простом правиле «если-то».
· В Задаче 2 (Агент-планировщик): Решение уже сложнее. Агент решает, какой путь выбрать. Он оценивает различные альтернативы (пути через узел B или C), просчитывает их стоимость и выбирает оптимальную. Это классическое принятие решений на основе оптимизации.
· В Задачах 3 и 4 (Агенты-исполнители): Агент решает, участвовать ли в аукционе и какую ставку сделать. Это стратегическое решение! Если его ставка будет слишком высокой, он не выиграет аукцион. Если слишком низкой — может работать в убыток. В Задаче 4 он также неявно решает, поддерживать ли свою репутацию.
Вывод: На микроуровне каждый агент — это автономная система принятия решений.
Уровень 2: Принятие решений агентом-координатором (Мета-уровень)
Это уровень, где разворачивается основное действие с точки зрения ЛПР (Лица, Принимающего Решения).
· В Задаче 3 (Аукцион): Агент-заказчик не просто пассивно собирает ставки. Он должен принять ключевое решение: какому агенту назначить задачу?
· Критерий принятия решения: Минимизация времени выполнения.
· Альтернативы: Выбор среди всех агентом-исполнителей.
· Результат: Конкретное назначение, определяющее эффективность всей системы.
Это решение уже сложнее, чем у отдельных агентов. Оно основано на анализе предложений и применении четкого критерия выбора.
Уровень 3: Эмерджентное (возникающее) принятие решений на уровне системы
Это самый интересный и самый сложный уровень. Решение здесь принимается не одним агентом, а рождается в результате взаимодействия множества агентов.
· Система в целом становится инструментом для поддержки принятия стратегических решений человеком.
· Пример из кейса с цепочкой поставок: ЛПР (менеджер) сталкивается с проблемой: "Как перестроить логистику?". Он не знает ответа.
· Он не решает задачу сам. Он ставлет задачу перед агентной системой.
· Агенты (логисты, аналитики рисков, финансисты) начинают взаимодействовать: торговаться, обмениваться данными, формировать коалиции.
· В результате их взаимодействия система генерирует несколько сценариев (например, "Вариант А: дешевле, но рискованнее; Вариант Б: дороже, но надежнее").
Ключевой момент: Ни один агент не обладает полной информацией, чтобы принять итоговое стратегическое решение. Оно эмерджентно, то есть возникает из коллективного поведения системы.
Итоговое решение за человеком. Но агентная система кардинально меняет роль ЛПР. Он перестает быть "вычислителем" и становится "арбитром", "стратегом", который оценивает предложенные системой варианты и делает окончательный выбор на основе своего опыта.
Итог:
1. Процесс принятие решений есть на всех уровнях.
2. Агентный подход переносит фокус с программирования единственного "правильного" алгоритма на проектирование правил взаимодействия между автономными субъектами.
3. Система не выдает один "ответ". Она моделирует сложный процесс (как рынок или переговоры) и представляет ЛПР спектр возможных решений с оценкой их последствий.
Таким образом, агентный подход не просто поддерживает принятие решений — он коренным образом меняет его философию, делая акцент на распределенном интеллекте и моделировании сложных социально-экономических процессов.