?

Log in

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

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

Transhumanism, digital humanities, posthumanities [30 Jan 2013|12:01am]
Две встречи, два разных подхода к "человеческому".

Днём встречались сегодня с livingtomorrow (это один из руководителей российского трансгуманистического движения, http://transhuman.ru/), пообсуждали всякие интересные вопросы представления сложности. Оказывается, у занимающихся разными аспектами старения людей нет какого-то связного способа обсуждать их клочки исследований во взаимосвязи друг с другом, нет средств составить "большую картинку".

Старение многоуровнево (биохимия, клеточные механизмы, уровень тканей, уровень организма и т.д.), связано с интервенциями (жизненный цикл с этим связанный), накоплены огромные массивы данных, которые трудно соотнести друг с другом, ибо непонятны те абстрации, которые позволяют это делать. Я показал некоторые средства работы со сложностью, которые нашли люди из тусовки ISO 15926, которым требуется собрать в одно целое информацию жизненного цикла сложного процессного предприятия. Хихикну, что в каком-то биохимическмо смысле человеческий организм и его клетки -- это тоже process plant, "непрерывное производство". Поглядите на схему старения http://sciencevsaging.org/, мне она напоминает процессы из P&ID. Сейчас там самое развитое представление -- это CMAP, мы как раз интересовались подобным несколько лет назад. Сейчас-то мы продвинулись дальше, и вполне готовы поделиться наработанным -- у нас ведь есть .15926 Editor.

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

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

Вечером я читал три часа будущим магистрам по компьютерной лингвистике лекцию по digital humanities. Записи не велось, но есть слайды: http://www.slideshare.net/ailev/digital-humanities-jan13

Конечно, там на 21 слайде было про (digital) posthumanities, а digital humanities обзывались антиквариатом (а на первых слайдах я вообще говорю, что digital humanities было говорить осмысленно десяток лет назад, тогда же, когда было осмысленно уточнять "электронная почта", ибо до того и после того было и есть просто "почта", так и с этим уточнением digital к humanities. Другое дело transhumanities и posthumanities, этим студентам как раз с этим скоро (тут можно обсудить, когда будет это "скоро") придётся разбираться.
13 comments|post comment

Федерирование инженерных информационных систем разных стадий жизненного цикла [30 Jan 2013|08:08pm]
Обычно при необходимости федерировать данные информационных систем разных стадий жизненного цикла оборудования крупного инженерного проекта (например, PLM стадии проектирования с ERP стадии сооружения, а далее с EAM стадии эксплуатации) рассматривается только "передача проектной информации". Даже если сказать "передача данных жизненного цикла" (data handover), то обычно думают, что это "данные о структуре или документах целевой системы", но никак не "данные обеспечивающией системы по поводу целевой системы" (например, issues с ценной дискуссией по принятым техническим решениям и их основаниям, указаний на то, кто конкретно разрабатывал то или иное техническое решение).

Часть этих "данных по поводу проекта" (но не прямо "проектных данных") можно будет обсудить как «метаданные» (о разработчиках, например), но вот все эти issues, исторические данные по трудозатратам времени на разработку (для определения velocity и последующей оценки трудоёмкости модернизаций или ведения аналогичных работ) и т.д.. в дискуссию о метаданных не попадут. И опять мы останемся только с традиционными геометрией, P&ID для process plants и отчасти информацией каталога, но без управления конфигурацией – с соответствующими последствиями для конфигурации.

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

1. Используется ли онтология, корректно работающая с понятием система? Ппри проектировании речь идёт о функциональных объектах, закупаются физические объекты, эксплуатируютсяя физические объекты в функциональных позициях, нормализация данных должна быть доведена до 6й нормальной формы, т.е. нужна работа с 4D представлением проходящих по жизненному циклу объектов. Подробнее -- http://dot15926.livejournal.com/39300.html, когда успех "простой семантической интеграции", или MDM проекта, или "внедрения PLM-сервера" для информационных систем инженерной поддержки одной стадии жизненного цикла целевой системы пытаются закрепить прихватом систем другой стадии, и нарываются на потерю управления конфигурацией целевой системы. Этот чекпойнт как раз про предотвращает эти проблемы с управлением конфигурацией.

2. Предусмотрено ли управление конфигурацией и изменениями справочных данных (а не только проектных данных). Справочные данные тоже должны версионироваться, для них должны вестись issues, должна поддерживаться методология их разработки. Эту методологию и поддерживающие её инструменты нужно предъявить (гордо укажу на нашу "Методологию инженерии справочных данных ISO 15926 v.3" (http://techinvestlab.ru/files/RefDataEngenEnglish/RefDataEngen_ver_3_English.doc) и поддерживающий её софт .15926 Editor (http://techinvestlab.ru/dot15926Editor), разработанную последовательность чтения для образования (http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/).

Кстати, можно озаботиться и самим удобством создания справочных данных (увы, большинство конракторов предлагают рудиментарное редактирование низкоуровневых схем данных в плохих редакторах -- и каждое шевеление справочных данных становится рискованной операцией, особенно с учётом отсутствия управления конфигурацией и изменениями справочных данных). Какие средства обеспечения и проверки качества справочных данных предусмотрены (в MDM любят обсуждать, какие у них средства -- но речь обычно идёт не о самих серверах, а о внешних модулях "обработчиков" и "верификаторов". Именно о них речь).

3. Предусмотрена ли штатная передача не только проектных данных, но и справочных данных (классификаторов и справочников) для целевой системы? Ибо без контекста справочных данных проектные данные обычно невозможно использовать. В наших проектах это традиционная ошибка: систему, куда передают информацию, сначала долго-долго "на коленке", внештатно настраивают (переносят классификаторы и справочники -- однократно), а затем начинают передавать туда проектные данные. И тут выясняется, что при шевелении справочных данных в исходной системе интеграция разваливается: нужно как-то опять "на коленке", внештатно, внерегламентно производить "настройку" целевой системы -- корректировать эти классификаторы и справочники. Для того, чтобы передачу справочных данных было делать легко, нужно предусматривать class of class конструкцию (классификацию отношений классификации) в справочных данных. Иначе будут проблемы с управлением конфигурацией в условиях использования множества классификаторов (а их всегда много -- на разных стадиях жизненного цикла используются обычно разные классификаторы для по-разному определённых объектов, которые объединяются механизмом совмещения во времени их целых темпоральных частей).

4. Сколько времени проходит такт передачи данных? Опыт показывает, что медленная работа обычно оказывается для всех большим сюрпризом. Тут нужно задать вопрос заказчику: есть ли наборы данных, которые должны быть федерированы? Сначала для заказчика является откровением, что для интеграции данных нужно иметь какие-то образцы данных с самого начала проекта (а не в самом конце, как ошибочно обычно думает заказчик), а затем исполнитель проекта вдруг обнаруживает, что в данных заказчика есть не только огромное число содержательных проблем (кастом-элементы данных, не предусмотренные никакими предварительно настроенными и отлаженными в других проектах "адаптерами"), но и их просто много, и время передачи данных существенно влияет на организацию рабочих процессов ("нажал кнопочку -- пошёл обедать -- вернулся и проверил" существенно отличается от "нажал кнопочку, проверил, поправил, нажал ещё раз" (в первом случае может даже требоваться создание нового issue для исправления ошибки, во втором случае этого явно делать не нужно).

5. Предусмотрена ли федерация процессов (issue trackers и workflow engines) всех этих PLM (проектирование), ERP (сооружение) и EAM (эксплуатация) систем? Помним, что во всех этих системах хранятся как данные по целевой системе, так и данные по рабочим процессам предпринятия: технически передача данных по процессам и по целевой системе абсолютно одинаковы, просто никто не вспоминает, что любая передача информации подразумевает какое-то рабочее взаимодействие в части процессов, эти процессы нужно отмоделировать и передачу "эстафетной палочки" в сквозном процессе (workflow travesal) поддержать софтом -- http://ailev.livejournal.com/977531.html. Надо помнить, что любая "приёмка-сдача" происходит отнюдь не одномоментно (иногда и полгода, а подготовка к этому происходит много раньше -- стадии это только стадии, а вот практики жизненного цикла выполняются в ходе всего инженерного проекта) и данные в этот период времени ходят в самые разные стороны между информационными системами, сопровождаемые созданием и закрытием issue в них всех.

6. Кто ответственен за федерирование данных между стадиями жизненного цикла: как решается конфликт интересов? Интересы вендоров софта, подрядчиков проектирования и сооружения не совпадают с интересами собственника/эксплуатирующей организации (owner-operator), и успех всех крупных интеграционных/федерационных проектов, затрагивающих стадии жизненного цикла гарантируется только при очень жестком надзоре со стороны owner-operator. Это единственная по-настоящему заинтересованная сторона, остальные по совокупности причин заинтересованы в саботаже федерирования инженерных информационных систем разных подрядчиков, разных вендоров софта, разных подразделений одного даже подрядчика, которые работают на поддержке разных стадий жизненного цикла (проектировании, сооружении, эксплуатации). Это не техническое требование, но прохождение этого чекпойнта иногда потруднее, чем реализация сложного технического проекта. Если чекпойнт не проходится, то проект превращается в ИБД (имитацию бурной деятельности), реального федерирования систем не происходит -- дело ограничивается демонстрациями успешности на тестовых данных, а до промышленной эксплуатации в реальных инженерных проектах дело не доходит по совокупности причин. Часть этого вопроса -- кадровая: сотрудники каких организаций владеют интеграционным/федерационным ноу-хау, как это ноу-хау попадает в другие проекты owner-operator, что происходит в момент, когда заканчиваются контракты (кто и как вносит изменения в справочные данные, мэппинги и т.д.).

Конечно, все эти чекпойнты сейчас нельзя "купить" в виде готового решения. Решение, которое пройдёт удовлетворительно через все эти вопросы, потребуется разрабатывать (в том числе долго готовить организационно - не всё закрывается разработкой софта, справочных данных и мэппингов). Тем самым эти "чекпойнты" нужно по-хорошему было бы переописать (в соответствии с Основами -- http://ailev.livejournal.com/1051048.html) как последовательность альф интеграционного проекта и их промежуточных и конечных состояний, а уж эти состояния описать чекпойнтами более подробно. Ну, и дальше предложить посоревноваться разным поставщикам федерирования/интеграции инженерных информационных систем разных стадий жизненного цикла в предлагаемых ими практиках продвижения этих альф по состояниям от начального до конечного.
post comment

Когнитивные архитектуры, "другая физика", IBM Watson и логицизм [30 Jan 2013|11:28pm]
Неожиданно жаркая и безалаберная дискуссия в фейсбуке по поводу когнитивных архитектур: http://www.facebook.com/oleg.byakhov/posts/296971743759304

Я там тоже потоптался. Вот мои отрывки оттуда as is, хотя без контекста и мало что в них понятно (так, первую же фразу нужно понимать ровно наоборот -- я считаю там, что вообще не нужно сопоставлять человечьи и машинные когнитивные акты, но это понятно только при понимании полной фразы, на которую я ссылаюсь, а не только процитированного кусочка):
...
"машинный когнитивный акт можно гомоморфно сопоставить человеческому" -- я бы настаивал, что в этой фразе "можно" нужно менять на "нужно". А потом бы настаивал, чтобы определение "когнитивности" акта вообще не обсуждалось. Нужно решать задачи и предъявлять их решения. А все эти дискуссии про "истинную когнитивность", "истинную интеллектуальность" и прочая -- фтопку, эти дискуссии абсолютно бесплодны. Предъявляется задача -- предъявляется решение. Нет задачи -- никакие схемы не помогут, никаких актов, потому как непонятно, для решения какой задачи, для какой деятельности нужно будет потом использовать эту схему. И решать компьютер эту задачу, разумеется (pun intended, разумом имеется, хотя я этот "разум" и не определяю никак), будет не так, как Вася, а Петя не так, как Оля. Впрочем и компьютер-1 будет решать не так, как компьютер-2. Поэтому все эти схемы "истинной интеллектуальности" пока -- фтопку, давайте соревноваться в решении задач конкретными сложными техническими системами, в разных частях которых используются десятки разных схем разных когнитивных/интеллектуальных/безумных/статистических/игровых/примитивных актов.
...
про "другую физику процесса" -- сейчас квантовый компьютер отвечает за примерный подбор 200-300 возможных вариантов из астрономически большого их числа. А потом обычный компьютер тупо просчитывает за крайне малое время, какой из этих вариантов подходит. То есть сочетается и квантовое вычисление с его непрерывность, "может быть" и астрономическим перебором, и дискретное обычного процессора -- и никаких "моделирований человеческого мышления" (ибо зачем?!). Но если уж про тонкости, то в гейтах процессора идут вполне себе непрерывные электрические процессы, а логика нулей и единиц появляется после рассмотрения метасистемного перехода, на другом уровне рассмотрения. Так что все эти рассуждения про "непрерывность" и "дискретность" -- это разные способы затуманить суть дела. Да, "алгоритмы квантового компьютинга" это не алгоритмы (т.е. пошаговые процедуры) в обычном смысле этого слова, ну и что? Я не понимаю, зачем нам "другая физика процесса" кроме как для организации быстродействия, а "выращивание-воспитание" нужно обсуждать, абстрагируясь от "физики процесса". Deep learning вполне обсуждает "выращивание-воспитание", не обсуждая, на чём именно реализуются тамошние алгоритмы (а квантовые компьютерщики и сами эти алгоритмы лишают пошаговой природы, реализуя deep learning). И все они, конечно, активно обсуждают, сколько там тысяч или миллиардов элементов они смогут провязать за какое время, используя какую мощность и элементную базу.
...
Задача -- это то, для чего вам вдруг нужно что-то разложить что-то по двум полочкам. Ибо "сколько чертей помещается на кончике иглы" -- это не задача. Например, задача нахождения на произвольной фотографии случайно попавшего туда дорожного знака решается сейчас компьютером лучше, чем людьми (несмотря на все рассуждения про уникальность устройства человеческого зрения и ограничения современных компьютерных технологий). Насчёт того, что языки постановки задачи должны быть рефлексивны, а вычисления затрагивают саму формулировку алгоритма, и это должен быть exploratory computing, так это вполне себе понятно, но для разных задач это обычно устроено по-разному. А "универсальные алгоритмы" не работают нигде. В том числе у людей -- разные люди тренируют свои мозги для разных задач, и хирург решает свои задачи лучше, чем математик, а математик свои лучше, чем хирург -- поэтому не нужно замешивать все domains в кучу и искать "универсальный когнитивный акт", это бесплодно. Работать будут гибридные схемы, где будут федерироваться (sic, не "интегрироваться") независимо разработанные разные алгоритмы на основе разных представлений и идей по поводу "когнитивных актов". А когда работать не будут, будут появляться новые разработки алгоритмов и выражающих их языков для тех практических (а не схоластических) задач, которые нужно будет решать. IBM Watson на вопросы отвечает? Отвечает. Лучше людей? Лучше людей. Тем самым какой-то класс задач решает? Решает. Что не нравится-то? Экскаватор тоже не может построить высотный дом целиком, его используют только на стадии закладки фундамента, а дальше используют подъемный кран. Универсальность, конечно, хороша, но сложность берётся обычно не универсальностью, а специализацией. Сложный инженерный объект строят люди самых разных инженерных специальностей в их коллаборации, а сложные интеллектуальные задачи будут решать самые разные когнитивные архитектуры в их коллаборации.
...
Кстати, чтобы уж забить гвоздь по самую шляпку, и вернуться к тому, что делает IBM, то вот что пишет человек, который первый получил в свою лабораторию в колледже полномасштабный экземпляр IBM Watson (http://customwire.ap.org/dynamic/stories/U/US_WATSON_TO_COLLEGE?SITE=NDBIS&SECTION=HOME&TEMPLATE=DEFAULT&CTIME=2013-01-30-03-04-36) -- манифест логицизма в искусственном интеллекте: http://kryten.mm.rpi.edu/SB_LAI_Manifesto_091808.pdf (тоже, замечу, на основании рассуждений, аргументации, опыта выполнения проектов и т.д.). А это его же специально для Анны, как преподавателя философии: http://kryten.mm.rpi.edu/SB_Solving_Quiet_Crisis_111611.pdf
Это бы, конечно, причесать, оформить по-человечески, снабдить ссылками в изобилии. Но а) лень, б) всё равно это читать мало кто будет и в) а кто прочтёт, тот вряд ли что-то потом с этим будет делать практическое. Так что оставлю as is (а за контекстом сходите в оригинальный тред в мордокниге, если интересно).

Я ползу, ползу потихоньку в эпицентр всей этой слабой искусственной интеллектуальности. Крив мой путь, извилист, но неуклонен.
2 comments|post comment

navigation
[ viewing | January 30th, 2013 ]
[ go | previous day|next day ]