?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Вычислительная креативность [24 Jan 2011|12:01am]
Вычислительная креативность (сomputational creativity) -- это о том, как сделать компьютер творческим (манифест 2002г. -- http://www.doc.ic.ac.uk/ccg/doku.php?id=grandchallenge). Искусственный интеллект, согласно лидеру этих креационистов в лучшем двойном смысле этого слова Simon Colton (http://www.doc.ic.ac.uk/~sgc/), будет проходить три стадии:
1. Уметь решать проблемы -- доказывать теоремы, решать трудные задачки.
2. Открывать то, до момента открытия неизвестно что, но полезное (например, выдвигать интересную научную гипотезу).
3. Синтезировать -- т.е. многократно проходить цикл открытий (постановки проблем) и последующего решения проблем в ходе создания какого-то творческого артефакта.

Это я наткнулся, разбираясь с приглашенной речью Simon Colton на конференции 2010г. по модульности онтологий "Towards Ontology Use, Re-use, and Abuse in a Computational Creativity" -- http://www.doc.ic.ac.uk/~sgc/papers/colton_womo10.pdf. По правде сказать, про модульность в этой речи была только одна фраза -- we hope that the creative usage of ontologies will lead to interesting developments in the theory of modular ontology design. Кто бы сомневался.

Вокруг Simon Colton много чего происходит, например обкатка несколько лет появившегося алгоритма MCTS (Monte Carlo Tree Search), совмещающего полный перебор и случайный выбор в комбинаторных играх (любых, например в таких "неподдающихся", как Go) -- http://www.mcts-hub.net/about/index.html

Или визуальные грамматики, как средство выражения: http://www.contextfreeart.org/.

Обзорчик тут: http://www.doc.ic.ac.uk/~sgc/talks/BISON_EU_Dec10_Talk.pdf -- и видно, что существенную часть в этом обзорчике занимает примерно то, что когда-то (до CYC) делал Lenat с EURISKO. Вот Simon Colton уже и до онтологий дошёл. Когда он начнет делать свой CYC? :-)

Я всё больше и больше убеждаюсь, что грамматики -- это очень правильная парадигма. В основе всего лежат паттерны, рифмы природы. Паттерны и прочие рифмы описываются грамматиками. Творчество -- это когда находишь грамматику/стиль, и правильным неразрушительным образом шевелишь её. И затем генерируешь тексты в соответствии с этой грамматикой. Генерировать новую грамматику -- творчество, "актуальное искусство". Генерировать тексты в рамках уже известной грамматики -- исполнительство. Находить грамматику, которая еще не существует в явном виде -- опять же, творчество.

Всё это только-только набирает силу, чтобы буквально через несколько лет стать мейнстримом: это новое моделирование, "моделирование моделирования" -- про автоматизированное создание/извлечение грамматик, а не генерацию чего-то по тщательно подготовленным человеком грамматикам. Генерирование грамматики и потом генерирование экземпляров, или открытие/анализ грамматики с последующим генерированием экземпляров.

Про generative design, который наполовину инженерный, наполовину "актуальное искусство", я уже писал много раз -- http://www.generatorx.no/, и совсем от этого отличный http://generativedesign.wordpress.com/, несть числа этим проектам, это уже мейнстрим.

Старый знакомый Continuator (который превратился ныне в моделирование Bebop) тоже где-то в этом месте: http://www.csl.sony.fr/items/2009/reflexive-interactions-and-jazz-modeling/ (жаль, что статьи 2009г. пока недоступны). Там упор делается на интерактивность и рефлексивность: онтология/грамматика (например, марковская цепь -- которая ни разу ни онтология или грамматика, но смысл имеет тот же) сначала извлекается, затем происходит её abuse, затем результат предъявляется породившему ее человеку -- правильное кривое зеркало, интерактивная рефлексивность, даёт поток по Чиксентмихаю (http://www.csl.sony.fr/downloads/papers/2008/pachet-08a.pdf, впрочем, я когда-то эту ссылку уже давал).

Kinect уже есть, можно делать стартап фирмы, которая выпустит программу-учителя танцев. Сначала программа понимает, как танцуют эталоны какого-то стиля. Затем на экран выводится аватар, и ученика просят повторять движения. Компьютер смотрит на ход повторений, и сочиняет тренировочные упражнения, которые убирают ошибки. И генерирует правильные объяснения, что делать -- для каждого отдельно, в реальном времени, эти объяснения даются голосом. Только выбирай эталонные стили, и учись.

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

Всё будет, нужно только время. И, похоже, этого времени нужно уже не очень много. Танцы ведь -- это тоже грамматика...
15 comments|post comment

Об единую/ое информационную/ое систему/пространство инжинирингового проекта [24 Jan 2011|05:08pm]
Нет никакой информационной системы инжинирингового проекта: есть множество самых разных информационных систем у разных контракторов. Но всегда есть желание сделать "коллективную единую информационную систему инжинирингового проекта для единой информационной модели системы и общее объединенное единое информационное пространство данных жизненного цикла системы". Нужно как-то записать в явном виде, зачем вдруг требуется это "единство" для системы (и тем более для "пространства" -- термин, никем не определенный, но больше всего по смыслу похожий на SoS информационных систем разных контракторов), и какова последовательность пряников на пути реализации интеграционных проектов инженерного компьютинга.

При этом помним, что репозиторий информационной модели проекта может быть централизованный (думаем об CVS и SVN) и распределенный (думаем о git), дело не в "хранении данных в одной базе данных". Хотя исторически поначалу будет превалировать централизация репозитория, и с этим невозможно бороться. Но нужно помнить, куда течёт речка истории, и почему появился git (по поводу которого спорят до сих пор). Для распределенной по разным юридически независимым контракторам системе управления конфигурацией информационной модели проекта (где "система" в глазах каждого смотрящего) язык как-то сам собой (без знания про system of systems) начинает говорить про "единое пространство", но для описания получаемых пряников этого не нужно.


1. Создать полное и детальное многоаспектное описание проекта, чтобы предотвратить коллизии:
-- объекты, наличествующие в одном описании, отсутствуют в другом (например, не все детальки из чертежа заказаны. Не все насосы из принципиальной схемы есть на чертеже. В планах испытаний только присутствующее в объекте оборудование, но и не меньше).
-- разные физические объекты занимают одно и то же пространство-время (например, балка из одного чертежа проходит сквозь трубу из другого чертежа)
-- характеристики из разных описаний не совпадают (заземленный провод из одной принципиальной схемы является фазой в другой)
-- нет неописанных коллизий со стандартами и нормативными актами (техрегулирование/compliance).

Тут три последовательных этапа:
-- обеспечить хоть какие-то разовые передачи между разными САПР в ходе проектирования (например, чтобы все насосы и трубопроводы из P&ID появились в 3D. Или чтобы в плане производства работ появился монтаж всего оборудования) -- "обмен данными" (data exchanges), "точка-точка".
-- собраться "в модели" полностью хотя бы раз, непосредственно перед сборкой "в металле": коллизии, которые проявятся при "виртуальной сборке" существенно дешевле коллизий, которые проявятся "в металле" и "в бетоне". Символизируется в data handover (моменте передачи данных проектирования на воплощение/сооружение), но не факт, что handover подразумевает "виртуальную сборку" с отловом коллизий, это нужно оговаривать отдельно. Это уже "интеграция данных" (data integration), "все со всеми".
-- переход к "непрерывной сборке" (сборке рано и часто: http://en.wikipedia.org/wiki/Continuous_integration). Появление слов mainline (текущая общая модель) вдобавок к baseline (утвержденная общая модель). Это уже другая парадигма, изменение способа проектирования. В частности, тут есть подзадача интеграции поверочных расчетов (которые начинают приравниваться к рабочим расчётам), и проект simantics показывает, что не все решения, пригодные для интеграции "документов проекта" пригодны для интеграции "динамических моделей проекта".

3. Информационная модель системы позволяет решать аналитические проблемы.
-- снижение номенклатуры используемого оборудования как существенный источник снижения полной стоимости владения (разные проектанты-контракторы должны пользоваться одним каталогом).
-- оптимизационные расчеты (решение обратных задач -- "какая должна быть толщина балки, чтобы держать заданный вес?)
-- ...
Особый вопрос: что тут может быть решено уже в рамках "обмена данными", а что требует "интеграции данных".

4. Информационная модель пригодна для порождающего проектирования (синтеза, "трансформации модели") -- "возврат буквы А в слово САПР".
-- разводка трубопроводов;
-- расстановка железобетонной арматуры;
-- ...
-- в пределе: автоматизированный синтез всей системы -- и не "из требований", а "в диалоге со всеми заинтересованными сторонами" (ибо требования на старте проекта противоречивы).
Тот же вопрос: начинать можно в рамках конкретных САПР (другой вопрос, откуда берется начальная проектная информация!) и обмена данными, и продолжать до уровня полной связной информационной системы проекта.
58 comments|post comment

navigation
[ viewing | January 24th, 2011 ]
[ go | previous day|next day ]