?

Log in

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

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

Системная информатика [23 Jun 2016|04:37pm]
Моя идея остаётся прежней: моделирование, программирование, онтологизирование (и, думаю, обучение как в machine learning) -- это предметная область для одного и того же отношения абстрагирования, как мереология -- это предметная область одного и того же отношения "часть-целое" в разных его ипостасях и вариантах.

Ну, проектирование/конструирование (и программирование в смысле проектного управления, создание программ работ) -- это частный случай, просто абстрагирование будущего, будущих полных темпоральных частей целевой абстрагируемой (т.е. проектируемой/конструируемой/целевой для программы работ) системы.

Конечно, акценты тут разные:
-- программирование (поскольку сюда неявно включается алгоритмика как абстрагирование действий и работа с данными как абстрагирование объектов и свойств со всеми оговорками, что объекты могут сами по себе абстрагировать действия) тут наиболее общо, но оно позволяет "оживлять" абстракции, манипулировать ими, строить имитационные модели. В программировании также уделяется много внимания формализму моделирования: синтаксису и семантике. Глубина абстрагирования -- метапрограммирование.
-- Моделирование тоже наиболее общо, ибо это сама суть абстрагирования: оставлять в одной системе самое важное от другой, абстрагирование в чистом виде. Но, увы, акцент на запуск модели на исполнение, "оживление" этой абстракции тут не делается. Ничего, мы пойдём другим путём: при языках моделирования очень часто можно найти каки-то более-менее полноценные (полнотьюринговые) языки программирования -- как языки запросов или декларативные языки ограничений. Например, SPARQL при RDF (чтобы не сложилось впечатления, что речь идёт только о процедурных языках) или OCL при UML/SysML. Глубина абстрагирования -- гирлянда метамоделей.
-- Онтологизирование само по себе наиболее общо, ибо в программировании и моделировании неважно что абстрагируется, а онтологизирование обращает внимание на реальность мира и аспекты "истинности" моделирования (глубоко занимается самим отношением абстракции), привносит философскую логику и заставляет задумываться о способах моделирования пространства, времени, а также задумываться о преобразованиях одних классов моделей в другие, парадигмах абстрагирования и их совместимости друг с другом. Глубина абстрагирования даже не рассматривается, ибо органически входит в дисциплину.
-- Обучение тоже наиболее общо, ибо обращает внимание на эпистемологический аспект абстрагирования, "как получили эту абстракцию", а не онтологический "что там наабстрагировали". Глубина абстрагирования явно обсуждается в современном machine learning. А ещё обсуждаются разные парадигмы моделирования, включая многоуровневые распределённые представления (machine learning).

Работа с абстракциями, воплощёнными в текст и коды (понимаемый широко, "всё есть текст", включая паттернирование "символами" на картинках и т.д.) -- это информатика, работа агентов (людей и компьютеров) с текстами и кодами я разбирался с этим тут: http://ailev.livejournal.com/1008054.html, дисциплины информатики там были философская логика, когнитивная наука, лингвистика, компьютерная наука. По факту, к уже выраженному в этих прежних (это был июнь 2012) текстах добавилось (машинное) обучение. Ну, и "компактное описание" я заменил на "абстрагирование" (тут я шёл как раз от deep learning, в коннекционистской парадигме уровни нейронной сети как раз уровни абстракции, равно как и в гирляндах символического метамоделирования -- цепочек классификаций и специализаций).

Логический уровень, уровень абстракции, уровень объективации, все эти "мета" -- это всё про одно и то же (http://ailev.livejournal.com/1073932.html):

Подробней про разные "мета" -- http://ailev.livejournal.com/1204705.html, про формальное образование в этой области -- http://ailev.livejournal.com/1263511.html, логические уровни Бейтсона (эпистемологические, "обучения", а не онтологические его результатов) затрагиваются в разделе "когнитивной архитектуры" http://ailev.livejournal.com/1210678.html, многступенчатая объективация и объективизация --http://ailev.livejournal.com/1132449.html. И, конечно, сюда нужно добавить коннективизм в количестве: отношение между представлениями в разных уровнях нейронной сетки, разные уровни абстракции и архитектуры из разных стеков (уход от чистой иерархии слоёв-уровней, выход в сложные fully differentiable architectures с памятью, вниманием, различными обработчиками логики, выполнением алгоритмов и т.д.).

Системный подход включает в себя абстрагирование как основной метод борьбы со сложностью, включая абстрагирование в рамку деятельностного подхода (ага, подход в подходе):
-- Конкретное абстрагирование оформляет (frame) интерес стейкхолдера (деятельностной позиции, абстракции мыслящего существа, оставим на потом спекуляции про мыследействующих и абстрагирующих существ). Так сказать, "теория субъективной информации" (http://ailev.livejournal.com/66325.html, 2003).
-- Мереология ведущее отношение для абстрагирования (системы это холоны), она даёт возможность договориться по поводу того, что именно в реальном мире в конечном итоге абстрагируется в длинных цепочках метаабстрагирования. Системный подход -- это аналог структурного (иерархического) внимания в окружающий мир. Это позволяет строить описания каких-то частей мира, соответствующим системам в их границах, отделять фон от систем. В моих учебниках это "zoom-select". Подробней это раскрывается в http://ailev.livejournal.com/860017.html
-- есть жизненный цикл системы (указание на обеспечивающую систему -- http://ailev.livejournal.com/1248044.html), практики абстрагирования (практики определения и документирования определений -- создания полного описания) в этом жизненном цикле обязательны. Моделирование всегда было неотъемлемой составной частью системного подхода, а проектирование -- составной частью системноинженерного подхода. Программирование в какой-то момент через кибернетику тоже неудачно пыталось вписаться (пока не стало понятно, что кибернетика с её обратной связью совсем-совсем не эквивалентна информатике как таковой, и даже классической computer science как части информатики).
-- Поскольку деятельность коллективна, стейкхолдеров в ней много и ещё больше их интересов, то абстрагирований тоже нужно много, и разных для удовлетворения разных интересов. Но все полученные абстракции связаны между собой тем, что они про одну и ту же систему (или её части): любая абстракция это абстракция системы (или типа систем).
-- в силу коллективности деятельности, любое абстрагирование по мере роста его объема становится абстрагированием-в-большом (programming-in-the-large -- и см. как пример http://ailev.livejournal.com/748188.html, 2009г., и тамошний разбор сервис-ориентирования в современном программировании)
-- абстракции есть всегда, если есть система (наше знание о том, что есть система -- это уже абстракция), но они должны быть документированы для работы с ними -- разница между system definition и system description.
-- каждая абстракция имеет модальность (алеатическую, деонтическую, темпоральную), эти модальности могут меняться в ходе жизненного цикла.

Если соединить системный подход и расширенную распределёнными представлениями и коннекционизмом (http://ailev.livejournal.com/1228029.html) информатику (т.е. учесть, что все тексты и коды -- это описания тех или иных систем на разных уровнях абстрагирования, и эти описания отвечают разным интересам коллективно действующих стейкхолдеров), то будет системная информатика. Конечно, при этом придётся как-то справиться с коннекционисткой проблематизацией и в информатике (все эти end-to-end fully differentiable architectures) и в системном подходе http://ailev.livejournal.com/1252230.html

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

Например, можно считать, что все существующие языки -- это на каком-то уровне абстракции различные частные методы описания (viewpoint) каких-то определённых (view) системы.

Заново подойти к SysMoLan как языку системного абстрагирования (онтологизирования, программирования, моделирования и т.д.) -- http://ailev.livejournal.com/1127145.html (2014 -- обратите внимание, там как раз попытка выйти на "системную информатику", но на примере одного языка и без попыток обозначить предметную область, чисто на "обобщениях из практики"), http://ailev.livejournal.com/1169972.html (2015, требования к формализму), или даже ещё более старым идеям Симултрека (http://ailev.livejournal.com/611877.html -- 2008, "Датацентрика -- это концептоцентрика. Документоцентрика -- это символоцентрика").

В принципе, можно было бы ввести концепцию "достроения языка до системного", считая каждый язык каким-то частным методом описания (veiwpoint), порождающим "частное описание" (veiw, которое само состоит из набора моделей -- всё строго по ISO 42010). Для этого нужно понять, что же означает в информатике наличие какого-то текста на языке? Означает только одно: исполнение его в каком-то смысле. В этом-то и секрет, что исполнение или оценка языка совершенно необязательно предписаны! Одна и та же модель/программа/онтология (не заморачиваемся тут разницей между definition и description -- например, разницей между онтологией и онтологическим описанием) может быть оценена (eval) или исполнена (execute) в разных смыслах: из одного текста можно породить разными способами много других, например можно текст программы интерпретировать, а можно сначала компилировать (т.е. изготовить по образцу одного текста другой текст). и только потом интерпретировать. Программа для станка с ЧПУ так вообще приводит при её интерпретации к изменениям в реальном мире (впрочем, даже обычная компьютерная программа тоже приводит к изменениям в реальном мире, только очень маленьким -- типа краски из пикселей на бумаге или по-разному пропускающих свет фотонов на экране). А 3D-модель тоже оказывается вполне исполнима: она декларативна, но это не мешает её исполнять 3D-принтеру, воплощая систему. Так сказать, "обратное моделирование", reverse modeling, воплощение!

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

В принципе, никакой особости определения системной информатики нет. Системная химия (http://ailev.livejournal.com/1117783.html -- про разные сложные и самоорганизующиеся молекулярные системы, в которых проявляются какие-то нетривиальные эмерджентности), системная биология -- это всё про физический мир. Мы же тут о мире абстрактных объектов и его связи с физическим миром (через носители/media, выполнители/interpreters и всё такое).

В этом плане системная информатика должна как-то собирать различные описания в кучку. Скажем, в проекте http://rosettacode.org сравниваются описания решений математических главным образом задач на разных языках программирования. Там есть классический T-shirt: описание задачи (текст выходных данных + что нужно сделать), алгоритм (что делается = модель-решение для "что нужно сделать", текст на языке программирования) и output (текст выходных данных). Если брать языки моделирования, то сразу становится очевидным, что их нельзя сравнить с языками программирования: там нет этой тройки текстов "вход-алгоритм-выход". Но это не совсем так! С точки зрения системной информатики, всё это моделирование имеет смысл только для ответа на какие-то вопросы. Это просто означает, что есть ситуация (описание модели), модель (код, формальный текст решения для данной ситуации -- результат абстрагирования, выраженный в языке какой-то метамодели) и есть вопросы, которые задаются модели, предполагающие её исполнение в каком-то смысле. То есть интерпретатор тут не "виртуальная машина языка" (читающая программу и выполняющая её над входными данными -- интерес при этом фиксирован: выполнение программы), а "виртуальная машина модели" (читающая запрос для какого-то интереса и выполняющая его над моделью как входными данными). Этот интерпретатор может быть либо человеком, либо нет -- и тогда язык запросов это и есть язык моделирования! Это хорошо видно на парах декларативных языков OCL и UML (и любая запись на UML может быть выражена в OCL!), SPARQL и RDF/OWL. Получается, что языки моделирования -- это какие-то подмножества для своих часто стремящихся к полнотьюринговости языков запросов, просто выраженные в другом синтаксисе и отражающие только часть возможностей языка запросов.

Замечу, что этот подход отличается от "интеграции моделей на базе онтологий", к чему вели и Sztipanovits в http://ailev.livejournal.com/675208.html и https://www.simantics.org/ и наш собственный заход в dot15926. Онтологии никуда не делись, но они "внутри". И появилось явно выполнение этих онтологий, они не рассматриваются вне языка запросов. А язык запросов к онтологиям оказывается просто хорошим языком программирования, во всей его полноте и мощи. Ну, или его можно легко реализовать с учётом какой-то специфики модели -- тоже как встроенный DSL.

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

Либо можно пойти другим путём: нужно взять язык с развитой рефлексией и метапрограммированием (например, какой-нибудь Лисп. См., например, контекст появления Лиспа в дискуссии про универсальные языки моделирования/программирования http://justy-tylor.livejournal.com/246591.html и http://justy-tylor.livejournal.com/246877.html) и считать, что это и есть системный язык -- и порождать дальше языки моделирования из него по потребности (ну, или писать на нём в соответствии с удачными другими языками моделирования). Например, можно думать о том, чтобы (пока justy-tylor не предложит какого более удачного решения) брать тот же язык Julia, в котором в части рефлексии и метапрограммирования вполне Лисп внутри, и
-- реализовать на нём DSL для выражения моделей ArchiMate 3.0 (при этом можно даже сохранить вывод этих моделей в виде правильных графических диаграмм! Это ж просто будет такой viewpoint -- графическое описание). Дальше два использования: 1. просто глазеть на диаграммы, используя подмножество языка для удобной их текстовой записи (или даже удобного графического редактирования), 2. выполнение запросов. Учитывая, что ArchiMate 3.0 подразумевает расширения себя разными атрибутами и типами элементов, то легко можно представить самые разные запросы -- от "сколько практик у нас в модели" до "посчитай необходимую производительность для сервера" (этот пример про подсчёты на основании диаграмм архимейта -- прямо из книжки автора языка. Но там ArchiMate даётся как внешний DSL, и этот подсчёт реализуется независимыми от языка средствами. А у нас ArchiMate является встроенным DSL к Julia, поэтому просто пишем на Julia запрос к структурам ArchiMate-на-Julia. Julia к этому ArchiMate является и языком ограничений (хотя так не принято называть, это ж не логический язык!) и языком запросов (хотя так тоже не принято называть, не подразумевается какой-то модели данных) -- но если допустить, что внутри самого языка (а не сбоку на диске) есть модель, то всё становится на свои места.
-- выполнить план по линии Modelica-на-Julia, описанный в третьем пункте тут: http://ailev.livejournal.com/1271980.html
* * *
Тем, кто меня читает много лет, должно быть всё понятно. Кто читает совсем недавно -- не будет понятно ничего. Единственное, что могу посоветовать, это попробовать прочесть посты и материалы по ссылкам из текста. Если и там непонятно -- то в тех материалах тоже много ссылок, и так "до дна", пока не станет понятно.

По-хорошему, дальше две линии работ:
-- нужно как-то вытащить все эти обрывки мыслей по ссылкам, развернуть их, причесать и сделать учебник. Ибо как россыпь постов это всё необозримо. Когда-то у меня было такое же состояние дел в части системного мышления, пока я не сосредоточился и не написал учебник, аж две версии (http://techinvestlab.ru/systems_engineering_thinking). Вот и тут нужно писать учебник системной информатики, при всех текущих с ней непонятках.
-- взять какой-то язык с похожим на лисповое метапрограммированием (а хоть и Julia -- заодно там нет тяжёлого наследства программистской объект-ориентированности), и дорастить его до языка системного моделирования (оно же программирование, оно же онтологизирование, оно же проектирование и т.д.). Точнее, "спустить" его до DSL моделирования в его составе (что потребует описания на нём соответствующих метамоделей).
-- ну, и нужно отслеживать что там происходит в части коннекционистского моделирования-как-обучения (моделирования естественного языка, моделирования языков программирования, моделирование планов и цепочек действий, выражения концептов и понятности моделей-в-распределённых-представлениях и т.д.).
* * *
UPDATE: системная информатика -- это "информатика с системным мышлением в голове". Системная инженерия тоже так определяется: как "просто инженерия", только с системным мышлением в голове (ср., например, с http://ailev.livejournal.com/1157398.html).

UPDATE: некоторая дискуссия к этому посту ещё и тут: https://www.facebook.com/ailevenchuk/posts/10207409851418535
10 comments|post comment

Киберэкспертиза: мифы и реальность [23 Jun 2016|10:04pm]
Доложился сегодня по теме "Современные технологии в экспертизе: чем они могут помочь и может ли искусственный интеллект заменить эксперта" на семинаре «Российский рынок научно-технической и технологической экспертизы» в РВК. Слайды вот (http://www.slideshare.net/ailev/ss-63389239):


Мой силуэт (понятно, камера смартфона выбирает ярко показать мои слайды, а не меня -- поэтому только силуэт) даже попал на фотограцию тут: https://www.facebook.com/photo.php?fbid=1042447812458398&set=a.402371099799409.81588.100000795665039&type=3&permPage=1

Было, конечно, много забавного -- уж насколько на этом семинаре была попытка не обсуждать государственную экспертизу, один из чиновников в зале затребовал принять закон по экспертизе. Ему возразили, что это только в неразвитых странах такие законы, в других странах больше полагаются на этику -- а её в закон не впишешь, тем более что экспертизы бывают ой какие разные. Он не унимался: в Белоруси и Казахстане есть такой закон, и нам тоже нужно! Я ответил, что не нужно вспоминать бешеный принтер: он, как дьявол, немедленно ведь припрётся! Так и случилось: тут же к моей фотографии приложили ссылку на то, что такой закон в бешеный принтер уже внесён: http://asozd2.duma.gov.ru/main.nsf/%28SpravkaNew%29?OpenAgent&RN=1075772-6&02.

Консультанты потребовали похожего: только не закон, а стандарт -- только не как в OECD, а прям как в ISO 9001! И они тогда смогут немедленно нанести непоправимую пользу (ну, вы же знаете какой бизнес вокруг стандартов ISO серии 9000?). Я не дал смягчить это заявлением переходом от этого стандарта ISO к стандарту CMMI как примеру -- и дальше уйти на "уровни зрелости экспертизы". Нет, для всех этих "процессных стандартов имени ISO 9000" есть ISO 15504 (SPICE), который вполне наведёт вам эти уровни зрелости мимо всяких CMMI, особенно если вы напишете свой стандарт, описав "процессы" по ISO/IEC TR 24774:2010. Сразу скажу, мне эта инициатива кажется ничуть не лучше инициативы закона. Когда я писал слово compliance в своей презентации, мне и в голову не приходило, что люди могут тянуть в эту сторону тяжёлых обязательных требований -- хоть закона, хоть "обязательного процессного стандарта". Я-то писал про стандарты уровня организации (например, формат и примерное содержание полей отчётного документа экспертизы, что принимается и изменяется по ходу дела внутренними решениями фонда или компании).

Но славно посидели, основной докладчик много любопытного порассказывал про разницу отечественной организации экспертизы и международной.

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

UPDATE: какое-то обсуждение этого поста случилось в https://www.facebook.com/eduard.proydakov/posts/1126196367438832
8 comments|post comment

navigation
[ viewing | June 23rd, 2016 ]
[ go | previous day|next day ]