Computer Science МФТИ Changes    |    Index    |    Search
::: ProtocolEncoding :::

 
  ACM . Agent . ProtocolEncoding # Edit # Attach # Diffs # Printable # More :::

Main
• Register
• Users
• Site Map

Curriculum

Agent Web
• projects

Algorithms

Web Learn

Image Kit

ProgTech

Publishing

О способе представления поведения агентов для построения динамически обучаемых многоагентных систем

Введение

     Многие современные задачи, такие, как поиск в internet, для решения требуют инструментов работы с разнородными данными больших объемов, представленными в разнообразных форматах. Часто для обработки каждого формата требуется свой алгоритм. Програмирование и хранение этих алгоритмов внутри системы изначально приведет к необоснованной затрате вычислительных ресурсов. Альтернативным способом является построение систем, способных изменять свою функциональность без необходимости остановки и повторного запуска. В данной работе приводятся результаты исследования по построению динамически обучающейся агентной [1,2] системы.

     Понятие агента и агентной системы плохо формализуемо; однако некоторые авторы[] дают следующие определения. Согласно[] агентом можно называть програмный модуль, имеющий ориентированную на обработку внешней информации архитектуру, имеющий относительную автономность и способный решать и распределять задачи между другими агентами. Агентная система представляет собой множество агентов, работающих над решением определенной задачи. Важным понятием является _поведение агента_- под этим понимается алгоритм "реакции" на какие-либо события.      Важным объектом при изучении агентных систем являются протоколы- алгоритмы обмена данными. Они помогают более эффективно использовать главное преимущество агентных систем- ориентироавнность на общение.

Постановка задачи

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

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

Об онтологиях

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

     Практически все существующие на данный момент реализации онтологий обладают большим недостатком. Онтологии статичны и для изменения требуют остановки системы. Агенты, использующие данную онтологию, также обречены на статичность. Следовательно, необходимо видоизменить онтологию и представить ее в виде, пригодном для расширения и быстрого изменения некоторых элементов[4].

     Одно из решений этой задачи состоит в поиске общих понятия в требуемых предметных областях. На уровне базовых понятий все знания совпадают. Такими понятиями являются понятие строки, записи, таблицы. Конкретными данными эти общие понятия наполняются только при определении конкретного домена[6,7].

     Формально разделим онтологию на три уровня- общий, уровень поведений и частный. Верхний уровень будет «содержать» информацию общего характера. Это будут определения основных понятий и действий. На третьем уровне будут содержаться описания конкретных понятий предметной области. Элементы этого уровня онтологии будут «наследоваться», расширять понятия первого уровня. Второй уровень будет использоваться для описания поведения системы. Здесь будут храниться данные обо всех алгоритмах, обеспечивающих реакцию агента на различные события.

Предлагаемая модель

     Агенты общаются посредством сообщений, доставляемых средствами платформы. Мы будем рассматривать JAVA- платформу JADE[1]. Реализованный в этой платформе механизм передачи сообщений таков, что задача доставки сообщений и контроля за ошибками выполняются данной платформой и нет необходимости вмешиваться в ее работу.

     Будем считать, что процесс обучения рано или поздно остановится. В процессе обмена обучающей информацией агенты пересылают друг другу описания поведений. В случае, если поведение сложное и в его состав входит другое, алгоритм сначала выполнит передачу схемы "внутреннего" поведения. Для того, чтобы процесс обучения остановился, необходимо наличие некоторых действий, с которыми агент знаком, и описаний которых ему не требуется. Подобные действия будут входить в состав нижнего уровня онтологии.

      В процессе выполнения алгоритма поведения агенты могут использовать понятия предметной области. Примером этого является запрос о наличии записи в базе данных. В запросе помимо предиката "существует" должен фигурировать терм "запись"[1]. Описания всех подобных объектов находятся на нижнем уровне онтологии; одним из дополнительных предположений будет полная идентичность нижних уровней. Иными словаим, знания всех агентов о конкретных понятиях предметной области, в том числе элементарных действиях, совпадают.

Реализация представленя поведения.

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

      Поведение агента может быть описано в рамках некоторого формального языка. В качестве такого языка был выбран механизм beanshell скриптов. Это аналог языка JAVA, но без возможностей сложных объявлений и функций. Однако, его достаточно для представления сложных, нелинейных поведений. Язык JAVA достаточно универсален и позволяет добиться гибкости описания. Beanshell скрипты выполняются динамически; не требуется предварительной компиляции. Кроме того, представленные в таком виде поведения могут быть преобразованы к строке символов (String). Это гарантирует простоту передачи схем поведений и их интерпретацию.

     Архитектура агента, способного обучаться с помощью языка beanshell имеет некоторые особенности. Любой агент обладает неким списком известных ему поведений и элементарных действий- словарем. В словаре любого агента, кроме того, должно сожержаться действие "обучаться". При запросе на выполнение любого действия[2,5] проводится проверка на наличие этого действия в словаре.

     Для демонстрации был реализован пример, иллюстрирующий работу книжного магазина. Два агента, играющие роли Продавца и Покупателя, общаются на тему покупки книги. Один из агентов(Продацев) изначально не знаком с поведением при продаже(это неестественная ситуация, но она подходит для демонстрации работы данного решения). У каждого агента есть словарь, причем словари Продавца и Покупателя отличаются только отсутствием у первого описания поведения "Купить". Словарь играет также и роль онтологии. Верхний уровень обеспечен стандартами языка JAVA и не требует внесения изменения. Средний уровень пуст для продавца (он будет заполнен во время работы), а у Покупателя состоит из единственного поведения- "Купить". Нижний уровень для обоих агентов одинаков (см. Предлагаемая модель) и состоит из элементарных действий "Спросить о наличии" , "Получить", "Закрыть диалог".

     Вот схема обмена данными между агентами при помощи механизма обучения. Teaching.jpg

     Диалог начинается, когда Покупатель отравляет продавцу сообщение, содержащее формальный запрос на покупку книги(Buy:book). Агент-продавец просматривает свой словарь и не находит описания этого поведения. В ответ на пришедшее ему сообщение Продавец отсылает Покупателю сообщение, в котором просит его предоставить описание действия Buy. Такой запрос выполняется с помощью действия "Обучить" (Т.е. ответное сообщение будет выглядеть так: Teach:Buy). Агент покупатель, получает это сообщение; реакцией на него является поиск в словаре описания поведения "Купить" и получение его формального представления на языке beanshell. Выполнив эти операции, Покупатель отсылает Продавцу сообщение, содержащее полученный beanshell-код(что также делается с помощью действия Teach). Агент-продавец получает это сообщение и расширяет свой словарь. Он может это сделать благодаря пересланому формальному представлению действия "Купить". После этого словари обоих агентов оказываются идентичными и диалог может быть продолжен, что и происходит. Поведение "Купить" (со стороны покупателя) состоит из следующих действий. Необходимо "Спросить о наличии" книги и если придет положительный ответ, получить ее.

     Вот как выглядит код инструкции для продавца, написанной на языке beanshell.

import jade.*; 
if (s.equals("book")) 
{
   acm= Ask4Ava.takes(); 
}else{
   acm= Ask4Ava.refs();
}
(Здесь Ask4Ava- класс, отвечающий за представление элементарного действия «Спросить о наличии»,) В этой инструкции s- передаваемая в качестве аргумента строка, acm- выходной параметр. Этот код просто проверяет, является ли переданное слово словом «книга» и в случае положительного ответа выходное сообщение устанавливается на положительный ответ агенту, пославшему запрос.

Аналогичная инструкция для покупателя выглядит так.

import jade.*;
       if(s.equals("Yes"))
        {
                    acm= Getter.takes();
        }
        else
        {
                  acm= Closer.takes();
        }
(Здесь Getter- класс, отвечающий за представление элементарного действия «Получить», а Closer- класс, отвечающий за представление элементарного действия «Закрыть диалог») Здесь, как и в предыдущем случае s- входной параметр, а acm- выходное сообщение. Данная инструкция проверяет ответ на предыдущий запрос на действие «спросить о наличии». Если результат действия положительный, то ответное сообщение будет определяться действием Get. В противном случае, у агента- продавца в наличии нет запрашиваемого объекта, и диалог должен закрыться. Агенту будет выслано сообщение, которое проинтерпретируется как инструкция завершить работу.

Обсуждение

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

      Предлагаемый подход позволяет отказаться от необходимости все время держать активной базу данных библиотек; все необходимые данные получаются агентом от другого, в онтологии которого точно содержится требуемая информация. Разработчики получат возможность выстраивать агентов "с нуля", при наличии минимального набора знаний. Даже после выключения агент через некоторое время восстановит свою функциональность, при условии, что вся система ее не утратила. Среди недостатков нужно низкую на данный момент возможность встраивания в существующие системы.

Заключение.

Итоги.

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

Дальнейшие разработки.

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

Литература и источники данных.

  • 1. Сайт разработчиков JADE- агентной платформы
http://jade.cselt.it/
  • 2. В.Б. Тарасов, От многоагентных систем к интеллектуальным организациям, М.2002
  • 3. Сайт разработчиков системы BeanShell? scripts
http://beanshell.org/
  • 4. Онтологии: Определение и философия
http://www.jfsowa.com/ontology/
  • 5. Open Agent Architecture- сайт разработчиков.
http://www.ai.sri.com/~oaa/distribution/v2.3/doc/tutorial/index.html


Rambler's Top100 Rambler's Top100


# Edit menu  

Topic revision r1.13 - 28 Jun 2004 - 08:24 GMT - PeterD? Copyright © 2003-2017 by the contributing authors.

Agent.ProtocolEncoding moved from Agent.ProtocolLearning on 15 Jun 2004 - 10:58 by AndreyUstyuzhanin - put it back