скачать книгу бесплатно
Поскольку агенты могут существовать в гетерогенной среде, основное требование предъявляется к потенциальной возможности коммуникации.
Агенты-молчуны и вещатели
Многоагентная среда, прежде всего, предъявляет требования к коммуникативному уровню агентов. Однако часть агентов может никак не проявлять себя и заниматься исключительно сбором данных. Такой вид агентов является частным случаем. Например, это агенты, собирающие широковещательные сообщения – публичную информацию (сообщения, размещенные в публичных хранилищах), а также агенты-перехватчики частных сообщений. Примером агентов-молчунов являются индексирующие подсистемы поисковых систем.
Противоположностью «молчунам» являются «вещатели», которые не запрашивают, не принимают и не хранят внешнюю информацию, зато постоянно сообщают вовне некоторую информацию. Самым распространенным, элементарным и нужным агентом такого типа является агент-часы. Человек не может самостоятельно объективно и точно определить время, он может основываться только на своих ощущениях. Для получения данных о времени человек обращается к этому агенту. Компьютеры также синхронизируют собственное, не совсем точное время, с глобальными часами.
Структура агентов
Определение агента
Агент существует в определенной среде. По отношению к самому агенту, окружение, в котором он существует, является внешней средой.
Например, компьютерные агенты могут существовать в среде глобальной сети Интернет. И хотя мы можем на время отказаться от рассмотрения лишних и громоздких механизмов взаимодействия между агентами и сосредоточиться на внутренней структуре агента, в то же время мы не должны отказываться от его существования во внешней среде в целом при определении структуры агента.
Процессы взаимодействия с внешней средой не менее важны, чем процессы, протекающие внутри самой системы.
Рис.1 Взаимодействие агента с внешней средой
Несмотря на то, что в данном случае используется понятие «агент», в общем, любая программная система в той или иной степени может рассматриваться как агент. В то же время, большинство программных систем нацелены на взаимодействие с человеком либо со строго определенными информационными системами, поэтому они в чистом виде не являются агентами многоагентных систем. Если рассматривать такое взаимодействие сквозь призму агентных систем, то большинство программных систем можно определить как частный вид агента, реализующих коммуникацию через человеко-машинный интерфейс (HMI, Human machine interface). При этом построение жестко структурированных экранных и электронных интерфейсов характеризует системы как жестко коммуницирующие. Это результат того, что системы являются слабо адаптивными, имеющими статичную структуру данных, а их функциональность может изменяться только под воздействием ручных корректировок программистом.
Поскольку мы рассматриваем человеко-машинные системы, мы предполагаем взаимодействие машинных систем между собой, взаимодействие человека с машинными системами и, разумеется, взаимодействие людей между собой. Все они, таким образом, могут рассматриваться как единая коммуникативная среда. А, соответственно, мы можем рассматривать человека как агента. Разумеется, с точки зрения современных машинных систем, человек – это очень умный агент.
Агент отличается от жестко коммуницирующих систем тем, что агент самостоятельно может инициировать контакт с другим агентом либо, как частный случай, выбирать источник данных для получения данных. Например, хорошим примером агента являются индексирующие системы поисковых интернет-систем. Они обращаются к серверам с данными на основе собственных предпочтений и алгоритмов индексации данных.
Большинство программ можно рассматривать как частный случай агента в человеко-машинной среде. Одновременно с этим существует большое количество программных систем, взаимодействующих между собой автономно. Большинство из них являются агентами, хотя их нельзя назвать интеллектуальными агентами. В частности, агентами в машинной среде являются любые программные продукты, которые взаимодействуют между собой, используя любой возможный интерфейс. Будь это FTP-протокол для обмена файлами по сети, HTTP для передачи запросов и данных через web-среду, SMTP для обмена почтовыми сообщениями или UDP для обмена различными данными на низком уровне.
Для обмена данными между программными системами существует масса протоколов обмена данных, средств упаковки данных и структур данных. Например, XML как язык разметки, позволяющий упаковать в себя произвольную структуру данных; SOAP как транспортный протокол передачи упакованных данных (сообщений).
Также сформировался специализированный класс программ, называемых middleware (ПО промежуточного уровня) как промежуточный уровень в коммуникации между различными программами. Программное обеспечение этого класса позволяет получать, отправлять, преобразовывать и буферизировать данные между различными программами-источниками и программами-получателями. Вместе с middleware существует и класс программ, обозначающих ETL (extract, transform, load – выделение, трансформация, загрузка), которые делают подготовку данных при их передаче для некоторой программной системы.
Агент – автономная сущность, обладающая памятью, совершающая процессы обработки данных и позволяющая обмениваться информацией через каналы коммуникации.
Автономность является одной из важнейших характеристик агента. Помимо прочего, эта характеристика связана с понятием собственности, в том числе материальной собственности, как например, наличие собственных носителей данных. Собственность агента может быть связана с материальной сущностью агента, то есть все, что заключено в аппаратном обеспечении агента рассматривается как собственность. Кроме того, собственность может быть связана с хранимыми данными, специфическими правилами обработки данных, специфическими правилами и средствами коммуникации. Таким примером являются авторские права и ноу-хау.
Необходимо сказать несколько слов о целостности агента. Агент – это система с определенным набором составляющих компонентов. Без части составляющих, например, носителей данных, агент не может существовать или рассматриваться как агент.
Примерами агентов могут служить компьютеры, отдельные приложения, люди, группы людей. Для каждого из этих агентов характерны единый коммуникационный канал, а для группы людей – единая позиция для внешних коммуникаций, единая структура хранения данных и система обработки данных.
Составные части агента
Переместимся от макро-объектов, где агент представлялся как один из участников общего взаимодействия с другими агентами, к рассмотрению агента как основного объекта исследований. Вопросы коммуникации, взаимодействия в общей среде будут затронуты позже.
Агент как объект является самостоятельной и самодостаточной структурой. Для обеспечения своей деятельности агент должен включать в себя ряд составляющих элементов, описываемых ниже.
Рис.2 Составные части агента
Большинство программных продуктов включает в себя составляющую, связанную с структурированием и хранением данных, составляющую, связанную с обработкой данных, и интерфейсную часть с внешними системами или с пользователем.
Сравнивая структуру агента с аппаратными реализациями различных систем, можно сравнить его с компьютером. Так, в Intel x86-архитектуре присутствует процессор, который отвечает за выполнение команд и, соответственно, за обработку данных, память, хранящую данные и программный код. Архитектура разделяется на две подсистемы, которые обслуживаются двумя разными микросхемами окружения. Контроллер-концентратор памяти «Северный мост» (North Bridge) обеспечивает работу центрального процессора, оперативной памяти и видеоадаптера. Контроллер-концентратор ввода-вывода «Южный мост» (South Bridge) обеспечивает работу контроллеров ввода-вывода, интегрированных в материнскую плату, в том числе сети, внешние устройства и пр.
Центром агента является буфер данных. Он является аналогом быстрой памяти и используется для оперативной обработки выбранных данных из внутреннего хранилища данных, для последующего обновления хранилища данных и для целей коммуникации.
В качестве еще одной аналогии рассмотрим классическую трехзвенную архитектуру приложений: сервер баз данных – сервер приложений – клиент. Сервер баз данных хранит операционные данные, сервер приложений обрабатывает эти данные, клиент отображает данные. В сопоставлении с агентом, сервер баз данных – это хранилище данных, сервер приложений является блоком обработки, а вот клиент – это блок, связанный с коммуникацией, получением данных и формированием данных. Буфер данных агента существует на уровне сервера приложений.
Поскольку буфер данных является центром агента, рассмотрим его подробнее. А именно, почему он является центром, и зачем он нужен как таковой. Начнем с обработки данных. Данными невозможно оперировать непосредственно внутри хранилища данных (имеется ввиду интерактивные, коммуникативные операции), поскольку давно прошли те времена, когда данные запись за записью анализировались программой в базе данных, а затем они извлекались для последующих операций. Сейчас рутинная работа по выборке данных перенесена на уровень сервера баз данных. Мы даем задание системе управления базами данных выбрать, обновить, удалить, добавить данные, а система выбирает их для нас в наш промежуточный буфер либо обновляет данные в хранилище данных. Другими словами, все фактические операции производятся в буфере данных – туда выбирается ограниченная часть данных, которые нужны для обработки. Там формируются изменения в данных, которые затем транслируются (переносятся) в хранилище данных.
Для каналов коммуникации буфер данных играет другую роль. Дело в том, что каналы коммуникации не должны напрямую обращаться к данным во внутреннем хранилище данных, так же как коммуникационные каналы не должны иметь прямого влияния на хранилище данных. Это так, поскольку одним из основных принципов построения агента является его автономность, а, следовательно, и независимость от внешних факторов. В дополнение к этому мы обсуждали гетерогенность структур агента (см. главу «Агенты как черный ящик»), где мы предполагаем, что реализация агента может быть различной. При этом язык коммуникации с другими агентами остается единым в среде взаимодействия агентов. Таким образом, при формировании данных для внешней среды и для коммуникации с другими агентами, мы должны транслировать данные из внутренней структуры агента в структуру языка для взаимодействия с другими агентами. Такая трансляция является результатом обработки. И поэтому только результаты обработки (а не данные из хранилища данных) должны отправляться в выходные каналы агента.
Аналогичная ситуация с поступающей извне информацией. С одной стороны, агент должен транслировать входящую информацию во внутреннюю структуру данных, а с другой стороны агент также должен сделать определенные предварительные обработки, такие как оценка входящей информации на непротиворечивость (валидация информации). Первый вид обработки входящей информации соответствует гармонизации с внутренней структурой данных по форме, а второй вид обработки – это гармонизация по содержанию.
Воспроизведение агентов, априорная информация
Если мы рассматриваем мультиагентную систему как среду или сообщество, то агенты в этой среде должны быть подобны организмам – возникать и исчезать из среды и присоединяться и уходить из сообществ. А потому агенты должны иметь возможность совершать действия, характеризующие живые организмы, в том числе развитие и размножение.
Интеллектуальное (не физическое) развитие агента целиком связано с процессом обучения через коммуникацию, то есть через наблюдение и обучение. Развитие агента связано с внутренними механизмами и возможностями агента.
Размножение, то есть воспроизведение себе подобных агентов, используется как основная идея программ-вирусов, центральная задача которых максимально быстро распространиться и прикрепиться к другим программам на различных компьютерах.
В мультиагентных системах могут существовать различные подходы к воспроизведению. Некоторые мультиагентные системы (например, web-среда) определяют формат протокола взаимодействия агентов, например, протокол HTTP. Создание новых видов агентов не контролируется, основное требование – соответствие требованиям протоколам обмена данными. То есть реализация агента может быть создана с нуля или может быть создана через модификацию существующей реализации агента, например, агента с открытым исходным кодом. И, разумеется, воспроизводство нового агента – это использование некоторой реализации агента.
Другие мультиагентные системы предъявляют требования к конкретной реализации агента (например, Skype и другие системы обмена сообщениями). Протокол обмена данными между агентами является недокументированным, закрытым. А создание нового агента – это инсталляция агента на некотором компьютере в определенной среде (сети Интернет).
После установки некоторой реализации агента как программного продукта вы можете использовать его с данными, которые развертываются при установке. Второй вариант – это копирование данных из существующего агента. Копирование совершенно невозможно для живых существ, но в том-то и отличие информационных систем, что мы понимаем их внутреннее наполнение, а потому можем контролировать его и управлять им.
В корпоративных системах управления (ERP-системах) практикуются подобные копирования данных и настроек. Например, если компания внедряет систему в своих нескольких филиалах (дочерних компаниях), то обычно выбирается один из филиалов для пилотного проекта внедрения, а затем внедренная система развертывается (roll out) на другие филиалы. Филиалы могут располагаться в других странах и, соответственно, предъявлять требования к системе в зависимости от государственного регулирования и местных обычаев в этих странах. Различные филиалы могут иметь собственные бизнес-процессы или применять различный объем бизнес-процессов, а, следовательно, и использовать различный функционал в системе. Тем не менее, основные бизнес-процессы остаются едиными во всей компании, они позволяют получать единообразную отчетность, как финансовую, так и по различным натуральным показателям деятельности компании.
Развертывание настроек делается следующим образом:
1) Выделяются общие настройки для всей компании и, соответственно, для всех филиалов, где внедряется система. Эти настройки образуют так называемый корпоративный шаблон системы.
2) Выделяются общие данные всех инсталляций и/или компаний системы. Например, основная часть плана счетов (детализация плана счетов может зависеть от особенностей бизнеса каждого филиала), единые коды элементов запасов, единые коды глобальных поставщиков и заказчиков и пр. Такие данные обычно контролируются и управляются централизованно, и они образуют специализированную базу данных, называемую нормативно-справочной информацией (НСИ, MDM – Master Data Management).
3) Из базы данных пилотного филиала вычищаются настройки и данные, специфичные для этого конкретного филиала. Затем эти настройки и данные развертываются через копирование в другие филиалы.
Аналогичным образом данные из одного агента могут переноситься в другие агенты. То есть платформа для обработки данных и структуры данных остаются теми же самыми, что и в исходной системе, данные же и способы обработки данных переносятся ограниченно. Эти переносимые данные и способы обработки данных далее будут описаны как априорные данные.
Остается открытым вопрос, что включают в себя априорные данные. Ответ на этот вопрос целиком зависит от возможностей системы, её гибкости и специфичности данных. Априорные данные не должны влиять на дальнейшие возможности системы к обучению, к взаимодействию с другими системами, то есть не должны формировать ненужных шаблонов поведения системы. В смысле переноса предопределенных данных принцип «чем больше информации, тем лучше» не способствует развитию обучающихся систем, поскольку у системы, которая уже имеет определенный набор данных, не возникает потребности в её восполнении. А пересмотр и замещение базовых (в данном случае априорных) данных – гораздо более затяжной процесс, чем выстраивание системы и структуры собственных данных с нуля, так как агенту не требуется сомневаться в актуальности данных, а он при потребности в них видит их отсутствие, и добывает их.
Анализ агентов
Как я упоминал выше, агенты в общей картине мира представляют собой чёрный ящик. Подобно принципу инкапсуляции в объектно-ориентированном программировании, все входящие данные должны быть обработаны внутренними механизмами агента и через них помещены во внутреннюю память, а выходящие – сформированы внутренними механизмами агента. То есть прямая запись и чтение в/из внутренней памяти недопустимы: извне не должно быть прямого доступа к хранилищу данных агента.
Тем не менее, структуры данных агента, процедуры обработки данных агента и накопленные данные агента представляют интерес для нас с точки зрения получения очищенных данных. Под очищенными данными имеется ввиду информация с отсеченной интерфейсной частью сообщений и отфильтрованная от различных конвенций и правил, связанных с общепринятыми правилами коммуникации, в том числе и языком коммуникации. То есть мы предполагаем, что внутренняя структура данных агента должна быть выстроена в соответствии с нашими требованиями, как архитекторов агента. Таким образом, мы сможем понимать, как организованы данные и, в частности, сможем получить ответ на вопросы «почему», «зачем», как и другие аналитические вопросы. Внутренняя логика агента должна быть в состоянии дать ответ на этот вопрос.
Противопоставлением логическим агентам, дающим такую возможность, выступают нейронные сети. Нейронные сети могут давать оптимальные решения, однако нейронные сети основаны на адаптивных механизмах обучения и, соответственно, они могут дать количественные характеристики выходящим данным, но не качественные. А, соответственно, мы не сможем узнать у них ответ на ключевой вопрос «почему?».
Далее рассмотрим реализацию агента. Будем подразумевать, что реализуется именно агент, однако будет рассматривать его с точки зрения интеллектуальной системы.
Вариативность платформ и аппаратных реализаций
Фактически мы считаем, что агент – это программная система, работающая на некоторой платформе. Платформа для агента является совокупностью аппаратной и программной платформ (операционная система). Аппаратная платформа реализуется некоторой архитектурой (например, x86 или SPARC). Программная платформа реализуется некоторой операционной системой и библиотеками, например, MS Windows,.NET, ADO.NET.
Платформа является некоторой оболочкой, которая может характеризовать собственность по отношению к агенту и изолированность агента по отношению к внешней среде.
С развитием технологий виртуализации аппаратная платформа стала превращаться в размытое понятие. Аппаратный сервер заменило понятие «виртуальный сервер» или «виртуальная машина». То есть агент перестает ассоциироваться с конкретной аппаратной системой, поскольку может лишь делить один и тот же физический сервер с множеством других агентов. Через современные технологии виртуализации множество различных аппаратных средств могут быть объединены в единую аппаратную платформу с точки зрения программного обеспечения. Хранилище данных может быть размещено в «облаке», то есть с физической точки зрения это хранилище никак не принадлежит агенту.
Однако при различных аппаратных платформах и платформенных реализациях вообще, логические реализации агентов (алгоритмы, реализованные в агентах) могут быть одинаковыми, в том числе структуры данных, механизмы обучения, правила обработки данных (процессинг) и пр. С точки зрения целостности система является совокупностью реализаций, которые определены проектировщиком системы. С точки зрения собственности, в этом случае к составным частям системы можно подходить аналогично финансовому лизингу (финансовой аренде) в управлении финансами: а именно, если вы берете в аренду некоторое оборудование, закупаемое специально для Вашей компании, или которое может быть использовано только Вашей компанией, оно должно быть учтено на балансе вашей компании.
При вариативности платформы для универсальной модели, нет смысла держаться некоторого эталона внутри платформы. Как мы определились ранее, агент представляет собой «черный ящик» и никого не должно волновать, что скрыто внутри него. Если мы и хотим оценить правильность построения этого агента, то это следует делать через коммуникацию с агентом, подобно тому, как это определяется тестом Тьюринга.
Построение информационной системы
Вариации архитектуры и требования к системе
Мы очень многое знаем про определенность, статичность, четкую последовательность действий и строгое определение структур данных в программных системах. И наоборот, не так много сказано про возможности вариаций – не про девиации, то есть отклонения от норм, а про наличие общей формы и вариации в реализации обработок и структур данных, которые формируют индивидуальность каждой из экземпляров программных систем. То есть, с одной стороны, мы декларируем основные принципы систем, с другой стороны, мы должны понимать, насколько гибкими являются эти системы. Гибкость достигается за счёт вариативности структур этих систем. Тремя столпами любой информационной системы являются данные, обработка и коммуникация. Коммуникацию сейчас оставим без рассмотрения как производную от обработки данных.
Архитектура и составные части интеллектуальной системы, разумеется, диктуются задачами, которые должны выполняться агентом, их масштабностью и способом реализации этих задач.
Вместе с тем, выбор языка программирования, платформы, серверов, сама реализация должна включать в себя определенный набор механизмов и методов. Их мы и рассмотрим.
Принцип универсализма системы означает, что интеллектуальная система не должна работать по заранее определенной программе. Её алгоритмы должны быть модифицируемыми и гибко изменяемыми. Процесс обучения самой системы, как необходимое условие для интеллектуального агента, должен включать в себя не столько изменение, усвоение операционных данных, а скорее формирование управляющих данных, с помощью которых агент сможет применять новые методики, новые практики, новые умения. То есть агент должен не просто воспринимать новые данные и распознавать новую информацию, но и стремиться лучше и более эффективно учиться в будущем.
Программа в современном понимании – это процедурный код либо объектно-ориентированный код, который инициируется событиями. Когда мы говорим про модификацию или изменение алгоритма, это означает, что код собирается из составляющих частей на основе поставленных целей. Соответственно, событийно-ориентированные программы если не заменяются, то дополняются программами, основанными на целях, которые к тому же собираются в зависимости от целей и налагаемых на их достижение условий.
Предъявление таких требований к возможностям интеллектуальной системы означает, что для его реализации должны применяться механизмы, которые до сих пор не реализованы в языках программирования, такие как модификация или воспроизведение программного кода или мета-программ.
Данное выше описание как нельзя лучше подходит под системы класса BPM (Business Process Management, управление бизнес-процессами) и технологии SOA (Service Oriented Architecture, сервисно-ориентированная архитектура), когда конечная система складывается из компонентов как из кубиков. Но здесь есть одно значительное «НО!», которое заключается в том, что компоненты в системах с такой архитектурой являются статичными, и они не обладают достаточной гибкостью, чтобы именно собирать их как кубики, а не переписывать и проектировать составляющие их компоненты каждый раз заново, как это и делается на практике.
Требование необходимости в реализации описываемого агента не ограничивается процедурами обработки данных – это требование относится также и к данным. Для каждой функциональной задачи требуется строить структуру данных, которая позволяет хранить исходные данные, результаты обработки, статистику и производные данные для отчетности после получения из внешних источников и в процессе обработки.
В качестве примера: в системах управления производственным планированием структуры данных включают базовые данные, такие как центры работ (оборудование), производственные маршруты, списки материалов (спецификация готового изделия и полуфабрикатов). В систему вводятся планы по производству и выпуску готовой продукции. Система управления производством формирует план производства для каждого вида оборудования из плана выпуска готовой продукции. Затем по результатам выполнения работ в систему вводятся данные по фактически использованным материалам, времени выполнения работ и пр. После чего система формирует отчеты и накапливает статистические данные.
Для каждого вида информации во всех системах определяется структура данных, которая впоследствии наполняется единичными или массовыми данными.
При этом реализация требования универсальности для агента требует не только гибких правил обработки данных, но также и гибких структур данных, которые способны модифицировать и преобразовывать не только сами данные, но и структуры данных.
Например, в описанной выше производственной системе мы можем структурно разделить полуфабрикаты и готовую продукцию, если они имеют существенных различий в их свойствах.
Вариации структур данных и операций
Философия в качестве измерителя для понятий применяет оппозиционную модель. В ней свойство универсальности балансирует между фиксированной, статичной, неизменяемой структурой и максимально гибкими возможностями системы – универсумом. При этом, естественно, любая программная информационная система реализуется на основе некоторой структуры данных и программной составляющей, специфичной для её задач.
Например, система управления персоналом позволяет вам создавать новые поля в карточке сотрудника. Но при этом, система определяет, что должна существовать определенная таблица «карточка сотрудника», а каждый сотрудник должен быть идентифицирован табельным номером.
Таблица «карточка сотрудника», поля «табельный номер», «ФИО» и пр. – это и есть предопределенная структура данных. Возможность увеличения или уменьшения универсальности – добавление полей, удаление и изменение полей, реструктурирование таблицы и пр. и является реализацией универсальности системы, а её возможность к изменениям является свойством вариативности системы.
Вариативность касается как возможностей в обработке данных, так и возможностей в использовании структур данных. Рассмотрим эти две составляющие раздельно.
Означает ли максимальная гибкость в операциях, что система должна отойти от какой-либо структурированности программного кода? Нет, не означает. Это вопрос относится к понятию полноты вычислимости по Тьюрингу. Известно, что машина Тьюринга обладает полнотой вычислимости, то есть она может реализовать любой алгоритм. Следовательно, чтобы достичь достаточной вариативности по обрабатываемым алгоритмам, наш агент должен иметь возможность реализовать машину Тьюринга.
Формального определения критерия универсальности в структурах данных не существует. Однако основываясь на существующих практиках и теориях, можно вывести такой критерий. Основными принципами управления данными являются возможность хранения единичных и массовых данных, а также возможность хранения связанных данных. Производными требованиями к структурам данных является контроль целостности над связанными данными (контроль на разрыв связей и на согласованность данных), а также возможность поддержки сложных и упакованных (в некоторые структуры) данных.
Крайним примером статичности информации является выбитая в камне надпись. Физическая сущность носителя таких данных гарантирует его долговечность и неизменность. Максимальную гибкость в структуре данных мы стремимся получить через лёгкость изменения данных и через простоту в определении структур данных. Для надписей структурой является естественный язык, в информационных системах структура данных определяется платформой – языком программирования (типы данных), аппаратной структурой (например, размер машинного слова), реализацией языка программирования (различные виды языка Basic определяют различный размер для типа int), СУБД и пр.
Поскольку мы делаем упор на данные, мы должны обратить внимание на три важные составляющие, связанные с ними – хранение, извлечение и запись, обработка и обмен (коммуникация). Для передачи данных с их предварительной упаковкой используется языка разметки XML и JSON, который дает возможность «завернуть» всё, что угодно. Для хранения большого объема данных со сложной структурой обычно используется СУБД (системах управления базами данных) на основе реляционной модели данных либо, что реже, базы данных, основывающиеся на иных моделях данных. Для обработки данных используется несчетное множество программных технологий – языков, платформ, framework’ов, библиотек и т. п.
Предопределенная (априорная) информация агента
Любая программа предполагает определенный сценарий или несколько сценариев выполнения операций и действий. Например, в программах управления персоналом одним из сценариев является ввод данных о сотруднике, ввод данных о позициях штатного расписания, прием сотрудника на работу.
Если мы рассматриваем агент как некоторый универсум, как решение, которое может работать с различными структурами данных и реализовывать различные алгоритмы, то одним из важных вопросов является «с чего начать?».
Часто дети говорят «я умею всё». Под этим они подразумевают, что потенциально они могут научиться любому умению, впитать любое знание. Однако практически у них нет никаких жизненных навыков. Они действительно могут научиться, но еще пока ничему не научились. У них есть потенциал, но пока нет знаний.
С другой стороны, существует понятие априорных данных, когда система заведомо обладает определенным набором данных, а не только структурами данных. У людей обычно такие предопределенные знания называются генетической памятью.
Таким образом, интеллектуальная система также должна иметь некоторые предопределенные алгоритмы и данные. Прежде всего, такие предопределенные алгоритмы касаются обмена информацией с другими агентами. Кроме того, это встроенный интерфейс для получения данных, для вывода данных и для инициации выполнения заданий.
Парадокс Рассела для операций, автогенерация кода
Обсуждение автогенерации кода начнем с описания парадокса Рассела, хорошо известного в теории множеств: пусть К – множество всех множеств, которые не содержат себя в качестве своего элемента. Содержит ли К само себя в качестве элемента? Обычно этот парадокс иллюстрируется несколькими, насколько занимательными, настолько и абсурдными задачами:
Парадокс брадобрея: деревенскому брадобрею приказали брить всякого, кто не бреется сам и не брить того, кто бреется сам. Может ли брадобрей брить самого себя?
Парадокс мэра: в стране вышел указ о том, что мэры городов должны жить не в своем городе, а в специальном городе мэров. Может ли мэр города мэров жить в городе мэров?
Парадокс Рассела сам по себе неразрешим из-за самой постановки задачи, поскольку он ссылается на множество всех не включающих себя множеств, то есть в задачах противоречие задаётся аксиоматически, в самом определении. Чтобы свести математический взгляд на вещи к естественному, и если хотите, к бытовому понимаю, сравним этот парадокс с парадоксом всемогущества: попросите всемогущего сделать камень, который он не сможет поднять. Если получится, значит его всемогущество утратило силу, а если нет – то он и не был всемогущ.
Аналогичный парадокс, связанный с модификацией программного кода, возникает в задачах искусственного интеллекта. А именно, может ли программный код модифицировать и выстраивать сам себя? Или в другой интерпретации: может ли программный код строить другой программный код, не содержащий сам себя?
Как же соотносятся множества из парадокса Рассела и генерируемый программный код? На элементарном уровне код состоит из команд и операций. Их стройная последовательность и является кодом, который требуется получить. Но на уровне постановки задачи генерации никакого программного кода еще нет, это обобщенная информация или мета-информация о том, каким должен быть генерируемый код. Это и есть множество (задач), не содержащее другое множество (команд). Задача – это поручение процессору выполнить определенную команду. Получается, что, создавая программу, и записывая её в память мы даем поручение процессору выполнить определенный набор команд. Когда же процессор идет по этой последовательности команд, он рассматривает каждую из них в текущем контексте выполнения (регистры, состояние памяти и пр.). Понятие множества, не содержащего само себя – это фактически мета-информация (задачи) о мета-информации (командах), в которой не содержатся задачи более низкого уровня, то есть представления задач с более детализированным видом, хотя формально этот более абстрактный вид мета-информации остается мета-информацией. Подробнее представление мета-информации будет рассмотрено ниже.
Разумеется, парадокс Рассела не является краеугольным камнем для возможности генерации кода. В нашем случае, наоборот, мы понимаем, что одна программа может сформировать программный код (об этом ниже), и сама программа – это код. Так может ли идти речь о воспроизведении кода как об аналоге всемогущества?
Среди идей искусственного интеллекта существует идея самомодифицирующихся программ. На практике обычно программы не модифицируют себя сами. Есть ограниченный класс программ, которые изменяют свой код, такие как системы безопасности и их антагонисты – вирусы. С помощью механизма самомодификации программы обычно пытаются защититься от их распознавания. Идея самомодификации искусственного интеллекта состоит в самовоспроизведении кода, подобно рельсоукладчику на железной дороге, который кладет рельсы, а затем и едет по ним же.
В связи с тем, что самомодифицирующиеся программы, за исключением специфических, указанных выше программ, сейчас фактически не встречаются, поднятый мной вопрос на основе парадокса Рассела не так уж наивен для сегодняшнего уровня развития информационных систем.
Существует вид программирования, основной задачей которого является генерация программного кода путем самомодификации либо путем создания новой программы. Такой вид программирования называется мета-программированием.
Мета-программирование, собственно, предлагает два варианта – это шаблоны и внеязыковые средства, такие как синтаксические и лексические анализаторы. Полиморфизм объекто-ориентированного подхода программирования также предлагается как один из инструментов мета-программирования. Частным случаем мета-программы является «квайн» (quine): программа, которая выдает на выходе точную копию своего исходного текста. Тем не менее, какие бы технологии программирования мы не перечисляли, созданием программ в мета-программировании занимаются люди, а подходы призваны лишь упрощать написание кода.
Что же формирует код или, говоря простым языком, заставляет программы исполняться? Крупным классом программ, порождающим программный код, являются компиляторы. Противоположностью генерации низкоуровневого исполняемого кода является исполнение кода высокого уровня при помощи программ-интерпретаторов, которые на ходу анализируют исходный код и исполняют инструкции программ. Существует и компромиссный вариант между компиляцией и интерпретацией программ. Это технологии, осуществляющие трансляцию исходного программного кода в байт-код или в p-код (пи-код). Байт-код является более низкоуровневым, p-код – в большей степени высокоуровневым. Внутри исполнимого модуля эти виды кода исполняются интерпретатором.
Существенным отличием интерпретаторов и p-кода от компилированного кода состоит в том, что, используя механизмы интерпретации, система «на ходу» может выполнять скрипты на том же языке программирования.
В качестве альтернативы внешние программные коды также могут встраиваться в систему. Например, Microsoft предлагает собственный SDK, основанный на Visual Basic for Applications (VBA), подобно тому, как VBA существует в офисных продуктах Microsoft – MS Word, MS Excel и пр.
