Групповое мегамоделирование, теперь с "нейро" и машинным интеллектом
Что отличает современный мегамоделер от мегамоделера завтрашнего дня? Это я продолжаю разворачивать серию постов про системную информатику http://ailev.livejournal.com/1272169.html (системная информатика), http://ailev.livejournal.com/1273208.html (каким мог бы быть мегамоделер), http://ailev.livejournal.com/1274210.html (практика системной информатики).
Во-первых, современного мегамоделера ещё нет, ибо нет специально заточенного на это systems framework: инструментария, позволяющего создавать мегамоделер. Да, есть можество разных систем, которые приближаются к инструменту для создания разных частей мегамоделеров по своему функционалу (персональных, типа Eclipse, коллективных, типа PLM или GoogleDocs, самых разных -- см. оригинальный текст про мегамоделер в http://ailev.livejournal.com/1273208.html). И есть общее понимание, что для нормальной работы в каком-то проекте нужно поддерживать разные view, определяемые viewpoint. И что в мегамоделере должно быть можно как-то работать со множеством view. Что такое "работать"? Чем это отличается, например, от возможности иметь кучу разных приложений-окошек в рамках операционной системы? Ну, "работать" с разными view -- это прежде всего exploratory programming, в котором есть и данные, и язык выполнения операций, и обязательно REPL (http://ailev.livejournal.com/1140646.html), для чего нужно:
-- иметь откатку-накатку. Ибо знаем мы эту "работу": на каждые пять осмысленных операций приходится одна случайно и неправильно выполненная. Ибо exploratory programming. А поскольку отнюдь не все veiw текстовы, то это может быть очень нетривиальным.
-- иметь возможность работать с diff/merge, ибо по результатам редактирования view хотелось бы понимать, что происходит.
-- уметь найти ту часть данных, над которой нужно дальше работать. Это поиск, который быстро оказывается полноценным языком запросов, то есть полноценным языком моделирования-программирования. Т.е. на передней панели должна быть языковая консоль, простейшей командой в которой будет команда "найди". Найденное, понятно, отображается во view. Дальше можно обсуждать, должен ли мегамоделер уметь поддерживать множество базовых языков, или только один на всех. И тут же обнаружить, что если это язык программирования, то нужно сразу иметь возможность доступа к библиотеке, варианты редактирования текста программ и REPL, сразу захочется иметь notebook.
-- если мы видим что-то на экране, нужно иметь не только возможность inline редактирования, но и банального cut/paste -- а это сразу грабли, ибо cut происходит в одном представлении, а paste часто хотелось бы иметь в другом представлении. Скажем, в .15926 можно взять cut какой-нибудь онтологии (он обычно в триплах), а потом выполнить paste его в самых разных форматах -- например, в текст письма или вордового документа, где о тех же триплах и речи быть не может.
-- а теперь всё то же самое, но в режиме GoogleDocs, т.е. одновременного редактирования (множество точек редактирования)
-- а теперь всё то же самое, но с управлением конфигурации и изменениями (и опять вспоминаем diff/merge), включая распределённое управление конфигурацией и изменениями (http://ailev.livejournal.com/1260357.html, http://ailev.livejournal.com/1259878.html).
-- а теперь всё то же самое, но view и языков много, плюс поддержка alien данных, языков и всяческой прочей "липкости" (как обычно в PLM).
-- безусловно, удобная работа с "библиотечными viewpoints", которые плагинами включаются в состав мегамодели.
-- ... это можно продолжать и продолжать, но я уже писал обо всём этом.
Собственно, Systems Framework -- это инструментарий, позволяющий как-то уменьшить хлопоты по разработке подобных view, включающих самые разные модели для самых разных систем, поддерживающих множество самых разных видов данных (структурированные, неструктурированные, онтологии, коды, временнЫе ряды и т.д.).
Во-вторых, такой systems framework должен "из коробки" поставлять средства разрабоки персонального нейроассистента:
-- суфлёра для view, т.е. механизм организации подсказок (автоматического добавления мультур к культур, и дальше "генерация по намерению": http://ailev.livejournal.com/1269236.html). Как делать суфлёра не для одного view, а сразу для их множества -- это вопрос.
-- речевой интерфейс (есть, например, заявление, что он повышает производительность процентов на десять, если его прикручивать к САПР -- http://sk.ru/news/b/pressreleases/archive/2016/06/30/golosovoy-pomoschnik-sva-pomozhet-proektirovschikam.aspx). То же самое, нужно понимать, как работать со множеством view из одного голосового интерфейса, как это интерфейс связан не только с "вызовами из меню", но и со скриптами из языковой консоли -- как выглядит общение с REPL/notebook/editor в окне программы. Кроме распознавания голоса там ведь вкатывается полностью virtual collaborative assistant, поддерживающий диалог и уточнения (и задачи для них подобрать ой как не просто -- http://ailev.livejournal.com/1254114.html, но ведь такие "пустые" минимально наученные на работу с пустым megamodeler ассистенты, получается, должны входить в system workbench, а потом поддерживать работу со множеством "библиотечных viewpoints", плюс обслуживая ещё и разработку этих самых viewpoints (выполняя команды по поиску и установке необходимых плагинов).
-- всяческие "осознаваторы" (не хочу использовать термин "биологическая обратная связь" -- мне в разы и разы больше нравится метафора осознанности, вывода на уровень сознания, а не "возврата"): управление вниманием и cognitive load. Тут в полной мере вся тематика индивидуального управления cognitive load (в том числе и в учебном варианте: мегамоделер ведь абсолютно спокойно превращается в online judge! Словом, всё, о чём говорится в openmeta на эту тему: помощь в отладке интерфейса для viewpoint, т.е. профилировании, куда смотрит пользователь http://openmeta.livejournal.com/237342.html
-- а ещё "осознаваторы" на групповом уровне -- это про групповой cognitive load: http://openmeta.livejournal.com/236784.html
Как это всё могло бы выглядеть в части разворачивания разработки? Всё ж одновременно создать невозможно, и нужно сразу раскладывать на "очереди"! Я бы опирался тут на опыт того же .15926, в котором мы наступили на довольно много разных граблей (и было выкинуто на помойку штук шесть вариантов начального исходного кода).
Первое же решение -- нужно забыть о многопользовательскости, и сработать для начала с персональным решением, десктопным. Да, это убого, несерверно, немасштабируемо, но зато это может взлететь быстро и быстро быть опробованным архитектурно: вся механика связки языка, view, viewpoints, адаптеры к различным данным, и много чего другого.
Второе решение -- без каких-то прикладных задач ничего не будет. Нужно выбрать какой-то набор прикладных viewpoints, чтобы на их основе отлаживаться. Тут может быть несколько разных вариантов, но один из них -- поддержать обработку нейроданных (все эти вызванные потенциалы, ЭЭГ вкупе с миограммой, энцефалограммой, и всяким прочим). И нейролингвистику (обработку текстов, в том числе с учётом голосового тракта). Там куча view, сегодня это делается с использованием notebooks, и можно пробовать делать чуток более гибко. Плюс вылезут сразу всякие ограничения на распараллеливание и наоборот, на синхронизацию разных view, затыки по скорости, плюс наладится контакт с группами разработчиков собственно "нейро".
А потом, года через полтора, когда немного пыль осядет и станет немного понятно про этот systems framework, стартовать разработку для групповой работы -- отделить бэкенд от фронтэнда, полезть в функционал полноценной PLM и группового "нейро", и проверить масштабирование для BigData (правильные быстрые базы данных, микросервисы, работа с контейнерами, интерфейс через браузер и т.д.). Думаю, этот этап нужно будет ещё на несколько разбить, там ведь много всего. А совсем-совсем потом уж выходить на работу групп между собой (про смарт-контракты и прочие блокчейны и институализирующие группы разработчиков DAO при этом гусарам молчать, хотя для футурологов это может быть важно).
Это всё, конечно, "скрипка Энгельбарта" (http://ailev.livejournal.com/1158826.html): средства разработки, САПРы и IDE, да ещё PLM -- абсолютно непопсовые приложения, заведомо сложные. Но:
-- systems framework должен снизить сложность вхождения в разработку для нердов. Ибо сейчас обустроить инфраструктуру какого-нибудь исследования того же нейроинтерфейса с обработкой результатов -- это повеситься, всё "на коленке". Тот же Atom или Sublime Text гуманней, чем vim или emacs, и понижает входной барьер, хотя и не до совсем уж попсового уровня. Задача для systems framework может быть не столько дать возможность нердам достичь бОльших высот ("усиление возможностей уже немаленького человеческого интеллекта"), сколько дать возможность не-слишком-нердам выполнить задачи, для которых раньше нужны были сугубые нерды.
-- разработанные мегамоделеры могут быть в разы и разы проще. Например, разработанный при помощи Eclipse редактор Archi в разы и разы проще самого Eclipse. Это означает, что мегамоделер для "нейро" может оказаться достаточно простым для, например, использования в учебных процессах, т.е. даже для освоения нейромоделирования студентами (конечно, при использовании "библиотечных view").
Я развивал тему поддержки групповой коллективной работы совсем недавно, в ноябре 2015г., с акцентами на нейротехнологии в коллективном моделеорентированном концептуальном проектировании (http://ailev.livejournal.com/1229950.html). Что изменилось по сравнению с теми текстами? По большому счёту, не слишком много: концептуальное моделирование просто требует своего viewpoint и вполне может быть представлено в составе мегамоделера. На то и systems framework, чтобы мегамоделеры можно было разрабатывать для самых разных предметных областей, будь то:
-- системная информатика, т.е. разработка systems frameworks и плагинов различных viewpoints в их составе
-- нейрофизиология, т.е. разработка плагинов viewpoints для разных "нейро" и "био", которые нужны для того, чтобы systems framework стал neuro-based "из коробки" (предмет настоящего поста). Эти плагины должны войти в состав systems framework, причём я бы даже "нейро" не поминал при этом, как не поминают сегодня "поддержку графического интерфейса", хотя лет двадцать назад это было крутая характеристика, прямо как "голосовой интерфейс" или "тач-интерфейс" сегодня.
-- комплекс для лабораторных работ и/или студенческих проектов по нейрофизиологии на базе нейромегамоделера (для этого, конечно, нужно будет немного побольше neuro viewpoints, чем будет потребно для работы самого system workbench). И можно будет использовать в учебном процессе.
-- комплекс viewpoints для концептуального моделирования. Для начала хотя бы повторить функционал Archi, т.е. сделать viewpoint ArchiMate. Ну, и помнить, что в том же Archi есть ещё и canvas для концептуального моделирования. Тут и до начальных целей "нейронета" уже недалеко: поддержка не столько разработки, сколько самых начальных её стадий, концептуальных обсуждений, работа за пределами жизненного цикла (замечание bowin в http://ailev.livejournal.com/1217971.html).
По идее, этот пост нужно было бы отдублировать и в openmeta, но я считаю, что в нём всё-таки больше не психопрактик и "нейро", а системной информатики. Так что пусть будет в основной моей ленте, "Лабораторном журнале".
Для меня системная информатика -- это линия на борьбу со сложностью, продолжение линии систем усиления человеческой деятельности, того чем Энгельбарт занимался, Алан Кей, ну и мы как-то трепыхаемся в этом направлении -- несмотря на всю его инфраструктурность, заумность и непопулярность. Добавляем системный подход, "нейро" и машинный интеллект, но гнём ту же линию Mother of all demos и Dynabook.
Исследования, сугубая мета-деятельность, инструментальщина, она всегда под капотом. Делать карбюраторы и топливопроводы -- это непопулярно, скучно и годится только для нердов. Но без этой невидимой работы не было бы автомобилей и миллиардов довольных их пользователей. Кто-то делает абсолютно непопсовые инструменты (почти без денег), кто-то этими инструментами делает попсовые приложения (и получает все деньги). Да ещё там много уровней этих инструментов по линии уменьшения нердовости и увеличения попсовости (и много раз повторяющаяся поэтому история делёжки денег -- сказочка про вершки и корешки). Это я себя, конечно, успокаиваю. У меня в этом месте когнитивный диссонанс: я-то понимаю, что для "успеха" нужно идти в попсу на широкие потребительские рынки, но нравится мне обычно возиться в тех технологиях, которые эти рынки делают возможными. Скажем, на рынке ценных бумаг я занимался не торговлей, а выпуском самих ценных бумаг: нет эмиссии, нет депозитариев, и нечем торговцам торговать -- вот я этим и занимался. В случае мегамоделеров то же самое: можно было бы сделать "на коленке" таргетированный на какую-то предметную область мегамоделер и им торговать, но мне интересно делать инструмент, который будет их порождать: нашпигованный "нейро" и машинным интеллектом "из коробки" systems framework.
Во-первых, современного мегамоделера ещё нет, ибо нет специально заточенного на это systems framework: инструментария, позволяющего создавать мегамоделер. Да, есть можество разных систем, которые приближаются к инструменту для создания разных частей мегамоделеров по своему функционалу (персональных, типа Eclipse, коллективных, типа PLM или GoogleDocs, самых разных -- см. оригинальный текст про мегамоделер в http://ailev.livejournal.com/1273208.html). И есть общее понимание, что для нормальной работы в каком-то проекте нужно поддерживать разные view, определяемые viewpoint. И что в мегамоделере должно быть можно как-то работать со множеством view. Что такое "работать"? Чем это отличается, например, от возможности иметь кучу разных приложений-окошек в рамках операционной системы? Ну, "работать" с разными view -- это прежде всего exploratory programming, в котором есть и данные, и язык выполнения операций, и обязательно REPL (http://ailev.livejournal.com/1140646.html), для чего нужно:
-- иметь откатку-накатку. Ибо знаем мы эту "работу": на каждые пять осмысленных операций приходится одна случайно и неправильно выполненная. Ибо exploratory programming. А поскольку отнюдь не все veiw текстовы, то это может быть очень нетривиальным.
-- иметь возможность работать с diff/merge, ибо по результатам редактирования view хотелось бы понимать, что происходит.
-- уметь найти ту часть данных, над которой нужно дальше работать. Это поиск, который быстро оказывается полноценным языком запросов, то есть полноценным языком моделирования-программирования. Т.е. на передней панели должна быть языковая консоль, простейшей командой в которой будет команда "найди". Найденное, понятно, отображается во view. Дальше можно обсуждать, должен ли мегамоделер уметь поддерживать множество базовых языков, или только один на всех. И тут же обнаружить, что если это язык программирования, то нужно сразу иметь возможность доступа к библиотеке, варианты редактирования текста программ и REPL, сразу захочется иметь notebook.
-- если мы видим что-то на экране, нужно иметь не только возможность inline редактирования, но и банального cut/paste -- а это сразу грабли, ибо cut происходит в одном представлении, а paste часто хотелось бы иметь в другом представлении. Скажем, в .15926 можно взять cut какой-нибудь онтологии (он обычно в триплах), а потом выполнить paste его в самых разных форматах -- например, в текст письма или вордового документа, где о тех же триплах и речи быть не может.
-- а теперь всё то же самое, но в режиме GoogleDocs, т.е. одновременного редактирования (множество точек редактирования)
-- а теперь всё то же самое, но с управлением конфигурации и изменениями (и опять вспоминаем diff/merge), включая распределённое управление конфигурацией и изменениями (http://ailev.livejournal.com/1260357.html, http://ailev.livejournal.com/1259878.html).
-- а теперь всё то же самое, но view и языков много, плюс поддержка alien данных, языков и всяческой прочей "липкости" (как обычно в PLM).
-- безусловно, удобная работа с "библиотечными viewpoints", которые плагинами включаются в состав мегамодели.
-- ... это можно продолжать и продолжать, но я уже писал обо всём этом.
Собственно, Systems Framework -- это инструментарий, позволяющий как-то уменьшить хлопоты по разработке подобных view, включающих самые разные модели для самых разных систем, поддерживающих множество самых разных видов данных (структурированные, неструктурированные, онтологии, коды, временнЫе ряды и т.д.).
Во-вторых, такой systems framework должен "из коробки" поставлять средства разрабоки персонального нейроассистента:
-- суфлёра для view, т.е. механизм организации подсказок (автоматического добавления мультур к культур, и дальше "генерация по намерению": http://ailev.livejournal.com/1269236.html). Как делать суфлёра не для одного view, а сразу для их множества -- это вопрос.
-- речевой интерфейс (есть, например, заявление, что он повышает производительность процентов на десять, если его прикручивать к САПР -- http://sk.ru/news/b/pressreleases/archive/2016/06/30/golosovoy-pomoschnik-sva-pomozhet-proektirovschikam.aspx). То же самое, нужно понимать, как работать со множеством view из одного голосового интерфейса, как это интерфейс связан не только с "вызовами из меню", но и со скриптами из языковой консоли -- как выглядит общение с REPL/notebook/editor в окне программы. Кроме распознавания голоса там ведь вкатывается полностью virtual collaborative assistant, поддерживающий диалог и уточнения (и задачи для них подобрать ой как не просто -- http://ailev.livejournal.com/1254114.html, но ведь такие "пустые" минимально наученные на работу с пустым megamodeler ассистенты, получается, должны входить в system workbench, а потом поддерживать работу со множеством "библиотечных viewpoints", плюс обслуживая ещё и разработку этих самых viewpoints (выполняя команды по поиску и установке необходимых плагинов).
-- всяческие "осознаваторы" (не хочу использовать термин "биологическая обратная связь" -- мне в разы и разы больше нравится метафора осознанности, вывода на уровень сознания, а не "возврата"): управление вниманием и cognitive load. Тут в полной мере вся тематика индивидуального управления cognitive load (в том числе и в учебном варианте: мегамоделер ведь абсолютно спокойно превращается в online judge! Словом, всё, о чём говорится в openmeta на эту тему: помощь в отладке интерфейса для viewpoint, т.е. профилировании, куда смотрит пользователь http://openmeta.livejournal.com/237342.html
-- а ещё "осознаваторы" на групповом уровне -- это про групповой cognitive load: http://openmeta.livejournal.com/236784.html
Как это всё могло бы выглядеть в части разворачивания разработки? Всё ж одновременно создать невозможно, и нужно сразу раскладывать на "очереди"! Я бы опирался тут на опыт того же .15926, в котором мы наступили на довольно много разных граблей (и было выкинуто на помойку штук шесть вариантов начального исходного кода).
Первое же решение -- нужно забыть о многопользовательскости, и сработать для начала с персональным решением, десктопным. Да, это убого, несерверно, немасштабируемо, но зато это может взлететь быстро и быстро быть опробованным архитектурно: вся механика связки языка, view, viewpoints, адаптеры к различным данным, и много чего другого.
Второе решение -- без каких-то прикладных задач ничего не будет. Нужно выбрать какой-то набор прикладных viewpoints, чтобы на их основе отлаживаться. Тут может быть несколько разных вариантов, но один из них -- поддержать обработку нейроданных (все эти вызванные потенциалы, ЭЭГ вкупе с миограммой, энцефалограммой, и всяким прочим). И нейролингвистику (обработку текстов, в том числе с учётом голосового тракта). Там куча view, сегодня это делается с использованием notebooks, и можно пробовать делать чуток более гибко. Плюс вылезут сразу всякие ограничения на распараллеливание и наоборот, на синхронизацию разных view, затыки по скорости, плюс наладится контакт с группами разработчиков собственно "нейро".
А потом, года через полтора, когда немного пыль осядет и станет немного понятно про этот systems framework, стартовать разработку для групповой работы -- отделить бэкенд от фронтэнда, полезть в функционал полноценной PLM и группового "нейро", и проверить масштабирование для BigData (правильные быстрые базы данных, микросервисы, работа с контейнерами, интерфейс через браузер и т.д.). Думаю, этот этап нужно будет ещё на несколько разбить, там ведь много всего. А совсем-совсем потом уж выходить на работу групп между собой (про смарт-контракты и прочие блокчейны и институализирующие группы разработчиков DAO при этом гусарам молчать, хотя для футурологов это может быть важно).
Это всё, конечно, "скрипка Энгельбарта" (http://ailev.livejournal.com/1158826.html): средства разработки, САПРы и IDE, да ещё PLM -- абсолютно непопсовые приложения, заведомо сложные. Но:
-- systems framework должен снизить сложность вхождения в разработку для нердов. Ибо сейчас обустроить инфраструктуру какого-нибудь исследования того же нейроинтерфейса с обработкой результатов -- это повеситься, всё "на коленке". Тот же Atom или Sublime Text гуманней, чем vim или emacs, и понижает входной барьер, хотя и не до совсем уж попсового уровня. Задача для systems framework может быть не столько дать возможность нердам достичь бОльших высот ("усиление возможностей уже немаленького человеческого интеллекта"), сколько дать возможность не-слишком-нердам выполнить задачи, для которых раньше нужны были сугубые нерды.
-- разработанные мегамоделеры могут быть в разы и разы проще. Например, разработанный при помощи Eclipse редактор Archi в разы и разы проще самого Eclipse. Это означает, что мегамоделер для "нейро" может оказаться достаточно простым для, например, использования в учебных процессах, т.е. даже для освоения нейромоделирования студентами (конечно, при использовании "библиотечных view").
Я развивал тему поддержки групповой коллективной работы совсем недавно, в ноябре 2015г., с акцентами на нейротехнологии в коллективном моделеорентированном концептуальном проектировании (http://ailev.livejournal.com/1229950.html). Что изменилось по сравнению с теми текстами? По большому счёту, не слишком много: концептуальное моделирование просто требует своего viewpoint и вполне может быть представлено в составе мегамоделера. На то и systems framework, чтобы мегамоделеры можно было разрабатывать для самых разных предметных областей, будь то:
-- системная информатика, т.е. разработка systems frameworks и плагинов различных viewpoints в их составе
-- нейрофизиология, т.е. разработка плагинов viewpoints для разных "нейро" и "био", которые нужны для того, чтобы systems framework стал neuro-based "из коробки" (предмет настоящего поста). Эти плагины должны войти в состав systems framework, причём я бы даже "нейро" не поминал при этом, как не поминают сегодня "поддержку графического интерфейса", хотя лет двадцать назад это было крутая характеристика, прямо как "голосовой интерфейс" или "тач-интерфейс" сегодня.
-- комплекс для лабораторных работ и/или студенческих проектов по нейрофизиологии на базе нейромегамоделера (для этого, конечно, нужно будет немного побольше neuro viewpoints, чем будет потребно для работы самого system workbench). И можно будет использовать в учебном процессе.
-- комплекс viewpoints для концептуального моделирования. Для начала хотя бы повторить функционал Archi, т.е. сделать viewpoint ArchiMate. Ну, и помнить, что в том же Archi есть ещё и canvas для концептуального моделирования. Тут и до начальных целей "нейронета" уже недалеко: поддержка не столько разработки, сколько самых начальных её стадий, концептуальных обсуждений, работа за пределами жизненного цикла (замечание bowin в http://ailev.livejournal.com/1217971.html).
По идее, этот пост нужно было бы отдублировать и в openmeta, но я считаю, что в нём всё-таки больше не психопрактик и "нейро", а системной информатики. Так что пусть будет в основной моей ленте, "Лабораторном журнале".
Для меня системная информатика -- это линия на борьбу со сложностью, продолжение линии систем усиления человеческой деятельности, того чем Энгельбарт занимался, Алан Кей, ну и мы как-то трепыхаемся в этом направлении -- несмотря на всю его инфраструктурность, заумность и непопулярность. Добавляем системный подход, "нейро" и машинный интеллект, но гнём ту же линию Mother of all demos и Dynabook.
Исследования, сугубая мета-деятельность, инструментальщина, она всегда под капотом. Делать карбюраторы и топливопроводы -- это непопулярно, скучно и годится только для нердов. Но без этой невидимой работы не было бы автомобилей и миллиардов довольных их пользователей. Кто-то делает абсолютно непопсовые инструменты (почти без денег), кто-то этими инструментами делает попсовые приложения (и получает все деньги). Да ещё там много уровней этих инструментов по линии уменьшения нердовости и увеличения попсовости (и много раз повторяющаяся поэтому история делёжки денег -- сказочка про вершки и корешки). Это я себя, конечно, успокаиваю. У меня в этом месте когнитивный диссонанс: я-то понимаю, что для "успеха" нужно идти в попсу на широкие потребительские рынки, но нравится мне обычно возиться в тех технологиях, которые эти рынки делают возможными. Скажем, на рынке ценных бумаг я занимался не торговлей, а выпуском самих ценных бумаг: нет эмиссии, нет депозитариев, и нечем торговцам торговать -- вот я этим и занимался. В случае мегамоделеров то же самое: можно было бы сделать "на коленке" таргетированный на какую-то предметную область мегамоделер и им торговать, но мне интересно делать инструмент, который будет их порождать: нашпигованный "нейро" и машинным интеллектом "из коробки" systems framework.