?

Log in

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

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

Моделеориентированная пельменная инженерия [04 Mar 2015|12:06am]
Японская пельменная инженерия (реклама оператора 4G сети, http://youtu.be/4ViwSeuWVfE):


А вот моделеориентированная пельменная инженерия (http://youtu.be/uTnXF64JGR8):
2 comments|post comment

Формализм для SysMoLan: что он должен поддержать [04 Mar 2015|01:47pm]
Сегодня провели микро-семинар по SysMoLan с дальним прицелом на его формализм. Выясняли эквивалентность теоркатегорного представления и представления в функциональных паттернах, а также куда делать акцент -- на архитектуру предприятия или на архитектуру железных систем (эти альтернативы были прописаны в http://ailev.livejournal.com/1168256.html). Главным же был вопрос о user needs: кому всё это нужно и как может использоваться.

Из новых интересных сценариев добавился mining -- восстановление архитектурных диаграмм из более низкоуровневых представлений. Например, подъем архитектурной модели из уже написанных регламентов, или даже из материалов process mining. Главный вопрос тут -- в какой целевой язык поднимать результат representation learning (про обучение представлениям, представителем которого является deep learning см. http://ailev.livejournal.com/1045081.html). Извлекать фичи из текста на естественном языке (например, регламенты предприятия, деловая переписка) понятно как, но в каком языке эти фичи излагать так, чтобы с ними можно потом было что-то делать осмысленное? SysMoLan как раз может быть таким языком -- но кроме рассматривания глазками, что можно полезного затем делать с извлечённым (discovered, а не invented) архитектурным описанием? Если у нас есть не море текстов, а извлечённые из них формально записанные некоторые паттерны (aka модель: существенно компактифицированная информация по немногим аспектам того, что моделируем), что мы можем делать с этой моделью? Но сама постановка вопроса "что мы можем делать с моделью" довольно плодотворна.

Можем пялиться на модель глазками, и что-то понимать. Формализм для этого не нужен (архитектурные языки типа ArchiMate как раз для этого предназначены прежде всего).

Если у нас есть формализм для этой модели, то можно делать model cheсking, т.е. находить ошибки в этой модели. И далее заниматься их исправлением (в модели или в моделируемой системе, тут уже второй вопрос). Также формализм нужен, если мы идём по пути группы AtlanMod: любая модель нужна прежде всего, чтобы сделать из неё другую модель (преобразовать), и само преобразование тоже модель. Без формализма такого не сделаешь.

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

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

Эта проблема была в IBM Watson: более 100 обработок для самых разных данных. Решение: данные хранятся и обрабатываются неструктурированные, никакого препроцессинга (ибо препроцессинг обязательно убивает какую-то информацию, которая есть в исходном тексте, для одной или многих из этих более 100 обработок, плюс число этих обработок растёт и общего препроцессинга и структурирования для всех в том числе и будущих обработок не придумаешь). Но при обработке активно используется подведение под типы (классификация): это повышает точность ответа (презентация Chris Welty из IBM Research рассказывает про это подведение под типы подробнее). То есть хотим мы, или не хотим, а типы SysMoLan нам придётся разработать, или discover их, но тут уж не так важно. В любом случае, SysMoLan нужен, чтобы хотя бы дать синтаксис и семантику для записи найденных типов и отношений между ними, сохранить нарытое (mining ведь!) знание.

Обсуждение множества обработок для одних и тех же данных обозвали прагматикой: данные тупые (имеют синтаксис) и имеют как-то "объективированные" (семантика) значения, но не смысл. Смысл определяется обработкой, обработка (различные вопрошания к одной модели, одни и те же вопрошания к разным моделям) делается для чего-то -- это прагматика.

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

Мы тут занимаемся занимаемся языкостроительством. Нужен современный архитектурный язык, не хуже всяких Rust и Julia, только язык моделирования, а не программирования. Эта проблема решалась в языках программирования как "проблема выражения" (expression problem, http://en.wikipedia.org/wiki/Expression_problem). И эта же проблема решалась при разделении программ на базы данных и программы обработки/языки запросов.

Эта проблема усугубляется, если речь идёт об exploratory computing/programming/modeling (В анализе данных it supports human exploration as an iterative and multi-step process and therefore allows building upon a previous query on to the next, in a sort of "dialogue" between the user and the system. Second, it aims at supporting a variety of user experiences, like investigation, inspiration seeking, monitoring, comparison, decision-making, research, etc. Third, and probably most important, it adds to the notion of "big" the notion of "rich": Exploratory Computing (EC) aims at dealing with datasets of semantically complex items, whose inspection may reach beyond the user's previous knowledge or expectations: an exploratory experience basically consists in creating, refining, modifying, comparing various datasets in order to "make sense" of these meanings -- http://dl.acm.org/citation.cfm?id=2600037. Это тренд в анализе данных, http://en.wikipedia.org/wiki/Exploratory_data_analysis ему посвящаются отдельные треки конференций: http://eventseer.net/e/24893/. И он выходит от чистого исследования-наблюдения-анализа к исследованиям в ходе разработки, жизненного цикла синтеза: http://en.wikipedia.org/wiki/Exploratory_programming, http://perchta.fit.vutbr.cz/projekty/22).

Отсюда вопрос "Как разделить процедуры и данные, чтобы их пополнять независимо без перекодирования процедур и перемоделирования данных при малейших изменениях?" становится штатным, сами программы/модели должны позволять аддитивные инкрементальные добавления по мере понимания задачи -- и эти добавления не должны приводить к переструктурированию данных и переписыванию кода при каждом изменении. В базах данных ответ на этот вопрос привёл к переходу на графовые, факт-ориентированные, семантические технологии (в отличие от реляционных, объект-ориентированных, где слияние двух баз данных требует перестройки модели данных -- "что в одном проекте объект, то в другом атрибут, и наоборот", как сформулировал это консорциум Epistle). В языках программирования это породило концепции типа Multiple Dispatch (http://ailev.livejournal.com/1140646.html).

Ещё один источник проблемы -- это переход от programming/modelling-in-the-small к аналогичным in-the-large (http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small). Мы не можем добиться того, чтобы всё знание было получено одним программистом/модельером в одной точке. Если в exploratory programming/modeling in the small знание требует достаточной гранулярности в языке, то при переходе к in the large мы уже говорим о модульности в языке. Мы всё ещё вынуждены решать expression problem для добавки обработок и структур данных, но также вынуждены делать более тщательный model cheking для отслеживания конфигурационных коллизий. Это означает, что формализм в части модульности должен быть "из коробки".

Отсюда требования к формализму:
-- должен помогать expression problem (поддерживать exploratory modeling, дизайн-цель "постоянные изменения модели")
-- должен помогать конфигурационному менеджменту в части модульности (поддерживать modeling in the large "из коробки", by design)
-- должен помогать множественности обработок для модели (формальная прагматика, наличие не только данных, но и процедур/вычислений). Это, кстати, очень хитрый момент. Языки моделирования в этом плане не сахар, они не "исполняются" в обычном смысле -- не всё моделирование сводится к simulation. Попытки что-то такое сделать для ISO 15926 привели к встроенным в Python "языкам билдера и сёрча", но что может быть из этой серии для SysMoLan -- неведомо. По идее, он сам себе должен быть "билдером и сёрчем".

Пока же из возможных формализмов всё вполне выразимо в терминах теории графов (включая паттерны данных, а также вспоминаем про простоту спецификации ArchiMate) -- даже без особой необходимости перехода к логическому или теоркатегорному представлению. Но потихоньку становится понятно, какие вопросы могут быть к этому формализму, в каких сценариях построения и использования SysMoLan-моделей формализм может быть полезен.

Хех, однажды мы уже в эту речку входили, хотя и в более примитивной постановке (см. "Стратегия создания платформы языкоориентированного онтологического программирования .15926", июнь 2010 -- http://dot15926.livejournal.com/2570.html). Конечно, в итоге мы за пять лет так и не разработали универсальный моделер (это с самого начала было понятно, что невозможно), но зато разработали интеграционную платформу для инженерных данных dot15926, поднаторели в онтологиях и разобрались с паттернами данных. И узнали про прорывы в representation learning. Но читается текст 2010 года до сих пор свежо. В языкостроении всё мееееедленно.
13 comments|post comment

Киборги всё заполоняют [04 Mar 2015|06:29pm]
Современные чудеса (впрочем, это последние годы, когда такое воспринимается, как чудо):
-- парализованный человек управляет F-35 (пока только на тренажёре) через нейроимплант: http://www.washingtonpost.com/news/speaking-of-science/wp/2015/03/03/a-paralyzed-woman-flew-a-f-35-fighter-jet-in-a-simulator-using-only-her-mind/
-- дроны разговаривают с авиадиспетчерами, как обычные люди: http://www.rmit.edu.au/news/all-news/media-releases/2015/february/talking-drone-offers-aviation-safety-boost/ (и помним, что это сделали австралийцы. Agent-based система управления полётами именно австралийская, так что там всё не случайно. Теперь ждём, когда приятным голосом заговорит с пилотами и система управления полётами, в том числе она будет мило беседовать и с дронами тоже).

Почему возможны такие прорывы? IMHO, это representation learning.

А почему такой прорыв в representation learning? Не только потому, что случились нужные прорывы в алгоратмах и понимании. Ещё и сработал закон Мура: для representation learning начало хватать вычислительных мощностей (и начинает работать положительная обратная связь: чем больше теперь будет успех в этой области, тем больше производители компьютерного железа будут разворачиваться в эту сторону -- как когда-то произошёл разворот от центральных процессоров в сторону видеопроцессоров).

Я уже поминал тут великолепную презентацию Nathan Intrator о нейроинтерфейсах (https://events.yandex.ru/lib/talks/2768/) -- она вся про то же самое, про "богатые репрезентации", множество маленьких экспертов-фич, каждый из которых говорит что-то незначительное про крохотный аспект данных. Но коллектив таких экспертов (нейронная сетка ли, или любая другая "глубокая" или даже "мелкая" архитектура) способен на многое. Сам мозг тоже так работает, Натан приводит довольно необычный пример, анализа звука мозгом. Хотя 1 нейрон имеет разрешение 1миллисекунду, их коллектив достигает разрешения 100нс (это на 1:06:38 презентации). Когда мучаешь одни и те же данные разными способами много-много раз, то можно мого чего узнать. Если перейти на подобные принципы в компьютерном железе, то это будет архитектурная революция.

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

Даже нумерологам киборги могут пригодиться, они ведь видят невидимое не хуже, чем человек! Можно гадать не только по кофейной гуще, современный Android, например, гадает по кирпичным стенам и окнам (он видит надписи в регулярных структурах) -- http://vvagr.livejournal.com/2050638.html
13 comments|post comment

navigation
[ viewing | March 4th, 2015 ]
[ go | previous day|next day ]