Многоагентный умный дом

[17th]

Я что-то неправильно понял, или вы изобрели функциональный язык программирования в картинках?

[DenisKoronchik]

В данных примерах по сути так и есть. Основная задача — сделать данный язык универсальным и ограниченным. Чтобы все, что запрашивает пользователь (на любом языке, с любым диалектом) можно было свести к этому языку. А все агенты просто общаются между собой с его помощью. Можно назвать его внутренним языком системы. Пока сложно себе представить нечто более универсальное, но я надеюсь этого дело дойдет.

[x893]

Что то мне это напомнило
http://www.state-machine.com/qm/

[niksan3d]

Современные системы управления с использованием ии мне напоминают известную цитату с баша:
XXX: понедельник
I-Bot Translate 39M2: Monday
XXX: вторник
I-Bot Translate 39M2: Tuesday
XXX: среда
I-Bot Translate 39M2: environment
XXX: среда
I-Bot Translate 39M2: environment
XXX: день недели, сука… среда!
I-Bot Translate 39M2: day of week, bitch… environment!

[DenisKoronchik]

Все верно. На уровне БЗ среда (как день недели) и среда (как окружение), имеют два разных узла (две разные сущности). Проблема чуть выше, как понять про какую среду идет речь. Я пока не имею цели решить данную проблему, пусть её решают профи в естественно языковых интерфейсах. Просто в проекте есть инфраструктура, когда я текущий resolver понятий заменю на лучший (это выключить текущий агент и включить другой).

[ACPrikh]

Дельфи в свое время имел замечательный хэлп, так как имел «See Also». И можно было «думать около». Или в Вики «имеются другие значения».
В топологическом смысле надо иметь не дерево, а сеть. Плюс диалог с юзером для уточнения (прохождения сложной топологии).

[neadekvatnij]

Подход правильный. Напоминает сюжет фильма «Прибытие» — для начала нужно научить пришельцев понимать «наш» язык.

[DenisKoronchik]

Я когда начинал работу над «умным домом», прочитал одну фразу, которая просто предопределила с чего стоит начинать: "Чтобы создать систему, способную действовать и размышлять, надо сперва создать систему, которая умеет взаимодействовать и понимать" — Адам Чайер (руководитель разработки SIRI)

[Godless]

как физически вы хватаете голос? микрофоны по всему жилищу?

[DenisKoronchik]

Сейчас пока телефон, уже в процессе прототип на часы (Android). Распознавание текста там уже есть, надо лишь отправить его в БЗ. Часы сейчас хороши, так как можно по ним сразу персонифицировать запросы.

[Godless]

Понятно, спасибо

[ondister]

Так ведь не в голосовом интерфейсе дело. Штука в том, что создается сложная модель физического умного умного дома в виде семантической сети.

[win0err]

Подскажите что-нибудь интересное про МАС. Желательно, чтобы ещё и примеры клёвые были

[DenisKoronchik]

Извините меня, но я не понимаю что вы имеете ввиду под MAC? Да еще и с примерами. Можете уточнить про какой из MAC-ов вы ведете речь? Спасибо

[win0err]

Естественно, многоагентные системы

[DenisKoronchik]

Я даже не могу Вам порекомендовать конкретную литературу сейчас. Читал я её еще только когда мы начинали делать технологию это 6-7 лет назад. Наверное для общих понятий подойдет вот эта ссылка. И наверное вот такая еще статья.
А вот список библиотек и софта.

[eao197]

Интересно, а почему вы начали делать свою реализацию агентов на C++, а не взяли какую-то из уже существующих реализаций той же Модели Акторов для C++?

[DenisKoronchik]

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

Так вот когда встал вопрос что нужно сделать хранилище БЗ и инфраструктуру для агентов. Я смотрел в сторону разных графовых БД, так как основной критерий был — это качество хранения графа и возможность навигации по нему. Но среди графовых БД на тот момент (2011 год) не нашлось таких, которые позволяли бы реализовать подписку на события. Решено было писать свою (благо опыт у нас уже такой был).

Также на тот момент не было еще четкого понимания как будут работать агенты, поэтому был реализован простой механизм нужный тогда. А потом по мере роста он перерос в нечто большее. Да и наверное нету смысла тянуть монстра и писать еще много кода чтобы получить от него то что требуется. У нас в планах сделать БЗ распределенной и там будет целая инфраструктура для распределенного запуска агентов. Возможно в этот момент стоит будет снова глянуть на различные реализации МАС.

[eao197]

то необходимо реализовать лишь интерпретацию этого формализма в виде программной или аппаратной реализации

Собственно, тогда вообще два вопроса возникают:

1. Чем «SC-код» отличается от уже известных моделей вроде Actor Model или CSP? И почему именно SC-код был нужен.

2. Даже если вам нужна была реализация SC-кода, то вы могли делать ее не с нуля, а взяв за основу что-то готовое. Тем самым минимизировав затраты на разработку все системы. Поскольку какие-то вещи, вроде поддержки многопоточности, вы бы переиспользовали, а не создавали заново. Отсюда и вопрос: почему не было взято-то что-то готовое?

[DenisKoronchik]

1. SC-код это формализм, способ представления информации. Если проводить грубую аналогию, то это способ кодирования информации (сейчас мы используем бинарный 0 и 1 повсеместно). SC-код позволяет записать любую информацию, при этом еще сохранить семантику. Другими словами SC-код — это язык представления информации (знаний), но не модель многоагентной обработки знаний. Дальше над SC-кодом синтаксис которого прост надстраиваются разные языки представления знаний. Каждый из них — это по сути набор правил как и с помощью каких отношений представляются знания по теории множеств, алгебре, геометрии, физике и т. д. Так строится база знаний. Среди множества этих языков есть и язык который я описывал статье (команд-запросов). Один из таких языков описывает агентов.

2. Так как SC-код — это способ представления знаний (абстрактный, а значит мог быть реализован большим количеством способов), то и смотрели на графовые БД. Но на тот момент ничего подходящего не нашлось. Но даже сейчас можно ядро заменить (хранение) на графовую БД, и просто оставить тоже АПИ оно на чистом си, все остальное будет через это АПИ работать с любым хранилищем. Что касается агентов, то имеющиеся библиотеки вряд ли нам помогли бы, так как все равно пришлось бы реализовывать очередь событий из памяти их вызов обработчиков.

Еще раз повторюсь, когда дойдет дело до распределенного хранилища, то скорее всего мы будем что-то такое использовать. Но на текущий момент в этом нет необходимости. На вызов параллельных агентов было потрачено около 30 часов, не так уж и много.