Virtual Laboratory Wiki
Advertisement

© Михаил Нетов, 2011

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



Назначение документа (abstract). Принятые сокращения.

В данном документе описывается в общем виде один из возможных подходов к организации процесса создания Искусственного Разума (ИР). Изначально предполагается, что эти работы будут производиться в рамках парадигмы моделирования структуры и функций реального, биологического мозга человека. При этом, отдельные компоненты мозга могут моделировать различные коллективы исследователей - разработчиков. Не вдаваясь в последнее, в данном документе рассмотрен вариант сетевого объединения их рабочих моделей. Для этого предложена общая среда передачи сообщений, введена абстрактная модель компоненты искусственного мозга и предложен протокол кодирования и адресации передаваемых сообщений (т.е. взаимных воздействий) между такими компонентами.

(Для справки - общий контекст данного документа на этом сайте: Михаил Нетов:ИИ )

Принятые сокращения

В данном документе используются следующие сокращения:

  1. ИИ - искусственный интеллект в смысле "сильного ИИ", синоним искусственного разума (ИР).
  2. ИМ - искусственный мозг - субстрат ИИ и ИР. Предполагается, что ИМ состоит из множества взаимодействующих компонент - моделей компонент реального биологического мозга человека. Подробнее о свойствах отдельных компонент ИМ (будет) написано здесь.

Требования к возможной архитектуре связей компонент ИР

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

  1. Модели отдельных компонент ИМ могут существенно изменяться в ходе работы над проектом. Они могут как просто уточняться и дополняться, так и радикально перестраиваться в случае получения качественно новых данных о работе реальных прототипов указанных компонент. При этом желательно, чтобы уже установленные связи между моделями компонент ИМ оставались функциональными (т.е. чтобы действия одного коллектива разработчиков минимально влияли на других). Для этого архитектура связей между компонентами должна быть максимально абстрактной, независимой от внутреннего устройства компонент ИМ.
  2. Разработчики компонент из других коллективов могут не знать внутреннего устройства и состава моделей других компонент и, соответственно, должны иметь единый, независимый от этих моделей, интерфейс для адресации информационных входов и выходов из/в своих собственных компонент.
  3. Представления разных коллективов разработчиках о составе входов/выходов между их моделируемыми компонентами могут не совпадать. Таким образом, возможны ситуации, когда к компонентам будут приходить адресованные входные сигналы, для которых в текущей модели данной компоненты не будет предусмотрено никакой продуктивной обработки. Общая архитектура связей должна предусматривать такую возможность.
  4. Некоторые компоненты мозга имеют существенную геометрическую протяженность и размеры (например, кора и ее отдельные зоны, гиппокамп и т.д.), а другие компоненты их не имеют (отельные ядра, целиком иннервируемые приходящими аксонами). Предлагаемая архитектура связей компонент ИМ должна поддерживать оба эти варианта адресации.
  5. Аппаратнно-программная реализация архитектуры связей ИМ должна выдерживать значительные информационные потоки между компонентами ИМ. Отсюда, практически необходимо следует, что она должна быть масштабируемой на множество компьютеров (т.е. ее можно будет легко "усиливать" просто добавляя к ней новые компьютерно-сетевые ресурсы).


Варианты среды передачи сообщений

В качестве базовой подсистемы реализующей указанную архитектуру связей ИМ предлагается использовать одну из стандартных систем передачи сообщений из области ИТ с добавлением правил адресации информации между компонентами ИМ. В качестве примера и первого кандидата на такую подсистему можно рассматривать открытое, свободное программное обеспечение (СПО) RabbitMQ , весьма известное среди подобного класса систем, предназначенных для скоростной передачи законченных сообщений между различными информационными системами и их компонентами. Среди достоинств данной конкретной системы можно выделить следующие:

  1. Наличие стандартных интерфейсов к великому множеству языков программирования и стандартных систем.
  2. Высокая производительность (Пример_1, Пример_2 )
  3. Возможности адресации от одного ко многим, подписки на определенные типы сообщений, наличие приоритетов сообщений и прочее (здесь и здесь).
  4. Возможность простой масштабируемости на произвольное (и расширяемое) множество имеющихся компьютеров.

Недостатки RabbitMQ для проекта ИМ:

  1. Все сообщения, в конечном итоге, помещаются в очереди адресатов - компонент, и если последние не успевают своевременно выбирать свои сообщения из этих очередей, они могут быстро вырасти и стать неуправляемыми (в смысле затрат аппаратных ресурсов). Соответственно, каждая имплементация любой компоненты ИМ должна быть снабжена обработчиком входящих сообщений (воздействий), которые должны максимально быстро опустошать свои очереди входящих сообщений (даже если для этого придется сообщения просто "выбрасывать").
  2. Все системы передачи сообщений являются асинхронными. С одной стороны, это дает возможность всем компонентам ИМ не простаивать в ожидании сообщений от других, но с другой, это допускает значительное рассогласование скорости работы отдельных компонент ИМ. Например, возможна ситуация, когда отдельные компоненты будут работать значительно быстрее других и могут просто "забрасывать" их своими сообщениями, а последние будут просто не успевать на них реагировать (и будут их просто "сбрасывать"). В целом существует множество способов подстройки скоростей работы компонент друг под друга, однако, отладка подобной рассогласованности скоростей возможна только при мониторинге их совместной работы, о чем будет сказано далее.

Кроме указанной системы передачи сообщений RabbitMQ есть и другие их бесплатные варианты (включая и написание собственного), но все они радикально отличаются от указанного уровнем оттестированности и подтвержденного использования в том числе и в промышленных системах. Тем не менее, если все-таки возникнет проблема недостаточной производительности подсистемы передачи сообщений, то придется пробовать на эту роль, соответственно, более скоростные, хотя и менее проверенные варианты.

Абстрактная модель компонент ИМ и адресация между ними

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

Предлагается в качестве такого единого представления всех компонент ИМ ввести прямоугольную горизонтальную структуру имеющую несколько слоев (см. рис.).

Адресация комп-нт.gif

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

Число слоев может быть от одного, для самых простых субкортикальных структур (типа отдельных ядер), до нескольких. Номер слоя может быть и двухуровневым, например, для областей коры, может быть номер слоя - 3.2, который подразумевает подразумевается второй подслой третьего слоя данной области коры. Если номер подслоя не указан, то адресатами подразумеваются все нейроны слоя в данной локации.

Далее, конкретные локации воздействия в рамках одного слоя компоненты ИМ задаются двухмерными координатами от средней диагональной точки слоя. При этом координаты могут указываться как в миллиметрах так и в процентах от максимальной координаты в рамках данного слоя (со знаком). Например, на рисунке показано вхождение сигнала во второй слой абстрактной компоненты ИМ по координатам (X=-50%, Y=-100%).

Радиус воздействия определяется не отправителем сообщения о воздействии, а обработчиком воздействия. Т.е. отправитель воздействия задает только слой, точку (или точки) воздействия а также тип воздействия (например, тип выделяемого медиатора). А уже сами обработчики воздействия понимают на какой радиус от заданной точки оно распространится (радиус приходящего аксона). Это сделано для упрощения (сокращения) передаваемых сообщений.

Случай частых массовых передач данных

Для некоторых компонент ИМ характерно частое получение больших массивов данных. Например, это характерно для всех визуальных компонент ИМ таких как LGN, Подушкообразное тело таламуса, верхнее четверохолмие, зрительная кора первичная, вторичная и т.д. Аналогичная ситуация складывется и для обработки аудиальных данных. В этих случаях разумно ввести возможность посылки матричных данных (двумерных массивов) с указанием именной карты распределения этих данных в адресуемой компоненте. То есть в подобных компонентах заводятся собственные карты распределения двумерных данных определенных типов. После этого данной компоненте можно передавать двумерные данные с указанием имени их распределения в указанном слое компоненты. Например, (двумерный_массив; visual) передается в третий слой первичной визуальной коры. Там обработчик такого сообщения сам распределяет полученные двумерные данные по конкретным точкам третьего слоя, согласно имеющейся карте отображения с именем (тегом) visual.

Таким образом мы имеем два механизма передачи воздействий между компонентами ИМ, которые условно можно назвать "точечный" и "матричный". Если проводить аналогию с компьютерной графикой, то у нас имеется возможность, как "рисовать" отдельные точки на поверхности слоев компонент ИМ, так и "натягивать заданные текстуры" на эти слои. Само собой разумеется, что можно придумать и другие способы кодирования воздействий при их передаче от одной абстрактной компоненты ИМ к другой. Однако, для сохранения простоты и наглядности данного вспомогательного механизма в рамках общей задачи моделирования ИР, предлагается пока остановиться на указанных двух способах.

Организация мониторинга

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

Упомянутоя система мониторинга и отображения состояния ИМ в рамках предлагаемой нами архитектуры, может быть подписана на получение копий информационных сообщений между отдельными выбранными компонентами. Таким образом система мониторинга может не только отображать внутренние состояния отдельных компонент ИМ, но и передачу воздействий между ними. Это очень важно, поскольку вслед за этапом моделирования отдельных компонент с высокой вероятностью наступит этап отладки взаимодействия отдельных компонент при реализации ими различных когнитивных, психических и физиологических функций. На этом этапе разным командам моделирования отдельных компонент придется гораздо более плотно взаимодействовать между собой, и очень важно, чтобы это происходило на основе объективной системы отображения общего состояния систем и получения исходных данных о проблемах.

Заключительные замечания

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

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

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

--M.Netov 12:05, декабря 4, 2011 (UTC)

Advertisement