Category: it

Category was added automatically. Read all entries about "it".

2019

Слайды курса "Машинный интеллект -- текущее состояние и перспективы" (декабрь 2019)

Вот 65 слайдов для последнего потока курса "Машинный интеллект -- текущее состояние и перспективы": https://yadi.sk/i/C2nj0CcJk7au6g.

Курс https://system-school.ru/machine прошёл 7 декабря 2019 года, это было аж четыре месяца назад (в AI как в детстве: четыре месяца длятся как четыре года у взрослых!). Я с тех пор немного подправлял слайды, но не слишком сильно. А вчера опубликовал текст "Дело спасения утопающих -- дело интеллекта самих утопающих" (https://ailev.livejournal.com/1509601.html), который предполагает существенные дополнения контекста (глобальный распределённый интеллект как верхний системный уровень) для обсуждения именно машинного интеллекта. Что-то мне подсказывает, что спрос на курс про интеллект (машинный и человечий) появится к осени, как раз перед второй волной бардака с онименяизоляцией. Тогда и обновлю слайды, и курс проведу.

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

И я понимаю, что это всё абсолютно неприкладное знание. Это просто упорядочение содержимого головы, чтобы текущий мутный дождик технологических новостей раскладывался в голове на правильные полочки, а полочки были не конца прошлого века, а state-of-the-art.
2019

Конференция "Прикладное системное мышление"-2020, день второй

Во второй день мы практически не потеряли в численности, людей в пике была та же сотня (первый день я обсуждал в https://ailev.livejournal.com/1508452.html). Доклады были по сравнению с прошлыми годами несравненно сильнее в части методологии, это работает наш упор на системное мышление и онтологику: разговор об инженерии и менеджменте на крепком методологическом основании становится сразу серьёзным, без размахивания руками и ссылок на личное чутьё в качестве аргумента. Видео (кроме двух последних докладов) появится в ближайшее время в https://yadi.sk/d/mzj4OrkwOnNrdQ

Вот мои заметки по основным замеченным мной проблемам:

1. Неразличение уровней формализации на спектре мышления и используемой нотационной техники.
Псеводкод, текст с формальными идентификаторами, текст, код, схема, диаграмма -- всё это замешивается в невообразимую кучу. Текст полностью формальный и текст на естественном языке сравниваются с диаграммами, схема тут не поймёшь -- диаграмма или набор концептов (формальный или не очень формальный, "схемоид" на спектре формальности мышления, т.е. выражаемый в языке обычно всякими отходами от theory theory). Явная дыра в нашем курсе онтологики, прямое техническое задание заплатки к курсу. Но и другие курсы должны обратить у нас на это внимание, прежде всего курс "Системная инженерия", где Вячеслав Мизгулин поднял проблему необходимости текстовых описаний в инженерии и отметил в своём докладе недостаточность методологических материалов по стыку схематизации-рендеринга в части концептуализации и в части нотационной инженерии. Отдельно концептуализации разного уровня формальности, отдельно нотационные техники текстовые (с разной степени вменяемости синтаксисами!), отдельно нотационные техники диаграммные. Ну ведь правда же, когда говорят "псевдокод", то аспекты свободы концептуализации или свободы синтаксиса имеются ввиду, или обе свободы сразу -- непонятно.

Мне больше всего понравился кейс Антона Меркулова, где он для выражения архитектуры предприятия последовательно пробовал ArchiMate, собственную диаграммную нотацию (на основе существенно более компактной нотации из функциональных описаний для электроники) и остановился на свободном тексте с типизированными понятиями системного подхода сущностями, именованными на CamelCase (https://ru.wikipedia.org/wiki/CamelCase ), например, Роль_ПерекатчикСолнцаВручную. Тип позволяет делать проверки (например, не путаются ли роли и должности), идентификатор выражает концепт, а отношения и менее формальные понятия выражаются текстом. Дальше можно в этот "текстокод" вводить потихоньку другие конструкции. Ещё пара проектов демонстрировала текстовые архитектуры вместо диаграммных техник, так что процесс пошёл. Кирилл Гайдамака сделал замечание, что текущие языки требований тоже по факту представляют собой "текстокод" -- синтаксис задаётся текстовыми шаблонами, терминология выделяется из текста, но текст таки остаётся свободным, язык не формальный, а естественный. Но в этом "текстокоде" (боюсь, боюсь писать "псевдокод"!) люди с удовольствием делают правки (ибо чётко видны последствия правок, формализма достаточно), в отличие от полностью свободного литературного текста, с которым они отказываются работать. Давний спор (14 февраля 2019 года на заседании Русского отделения INCOSE я спросил, почему в одном и том же проекте одни и те же люди отказывались работать с текстами у Александра Лучкова, и отказывались работать с картинками у Кирилла Гайдамаки -- https://ailev.livejournal.com/1465997.html, и там ссылка на видео) получил разрешение: слово "текст" не отражало степень формальности этого текста, а "картинка" также не отражала степень формальности -- они отсылали только к типу нотации (и даже не к нотации, ибо для "текста" и "картинки" могли быть десятки нотаций для самых разных уровней формализации и разных вариантов концептуализаций/онтик предметной области). Теперь понятно, о чём нужно было спрашивать дальше!

Вопрос про "полнотекстовое на естественном языке представление против формального текста" обсуждался лет десять назад с Donald Firesmith (он приезжал к нам в Москву и резко выступал против того, что архитектура выражается только формальными языками, настаивая на необходимость текстовых документов. Но он как раз из "старых системных инженеров", о которых говорил Вячеслав в своём докладе). И этот же вопрос лишней формализации буквально вчера всплыл в закрытом обсуждении в фейсбуке (чем плохо тегирование по сравнению с текстами), и я там тоже отметился: 11 лет назад я писал про эту вакханалию лишней(т.е. не ведущей к проверкам, вычислениям или чему-то осмысленному) формализации/тегирования в https://ailev.livejournal.com/715272.html, и привёл байку Моя любимая байка про IBM Watson, который выиграл Jeopardy!, причём я лично участвовал в той встрече онтологов, где был этот диалог. Там спросили, почему люди в IBM не кодируют википедию в виде онтологии/knowledge graph (по сути -- не формализуют википедию), а используют полнотекстовую обработку? Ответ был таков, что вопросы они не могут предопределить, а любое сжатие информации/формализация/схематизация/моделирование -- потеря ответа на какой-то неожиданный вопрос, ибо вопрос может быть про важное для спрашивающего, но неважное для формализатора. На удивление онтологов, что работа с полными текстами без их кодирования/сжатия в виде формальных представлений требует диких вычислительных мощностей, они ответили "так ровно поэтому IBM Watson -- это прежде всего суперкомпьютер!". Все эти соображения остаются верными и сегодня, когда говорим о knowledge graphs. Если не очень понятна цель, то чересчур сжатые формализации быстро оказываются бесполезными в тот момент, когда цель становится ясной и оказывается не той, которая была при формализации.

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

Особенно обидно было то, что неудачные нотации закрывают хорошие концептуализации. Так, всё направление GORE (goal-oriented requirements engineering) появилось как указание на необходимость учитывать человеческие цели (ролевые интересы, предпочтения и намерения по реализации предпочтений) в инженерии требований, особенно разбираться с возникающими конфликтами между стейкхолдерскими ролями: разбираться не столько с требованиями, сколько с проектными ролями, которые тянут эти требования каждый в свою сторону в силу своих предпочтений. Моделями требований начали называть представления, в которых кроме требований указывалась трасса к проектным ролям и их конфликтам. Но у языков для моделей требований с их графическим представлением не нашлось много интересных кейсов по моделям требований (хотя тот же ArchiMate явно указывает, что учитывает фреймворк i* в своей концептуализации, то есть он в какой-то мере язык GORE, т.е. включает подъязык требований -- вот тут у меня есть абзац на эту тему в разговоре про SysArchi и там пара ссылок: https://ailev.livejournal.com/1454948.html).

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

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

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

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

Вторая засада в этой проблеме непоняток между разработчиками и архитекторами именно софта -- это длинная цепочка описаний: архитектура описывает программу, код тоже описывает программу, которая описывает домен. Описывает ли архитектура домен и что мы там делаем с DDD? Ответы тут очень, очень невнятны.

3. Проблема мереологии софта
Мереология -- это подраздел онтологии, занимающийся отношениями частей и целого. Для софта:
-- отношения "вызова" путаются с отношениями "часть-целое" (я немного затронул этот вопрос в "мереологии практик мышления": https://ailev.livejournal.com/1508228.html).
-- мереология описаний (кода), мереология софта в момент исполнения, мереология данных, мереология домена и их трассировки друг ко другу -- это всё разное. Сегодня это не очень различается в части работы с системными уровнями, а надо различать. А то обсуждаются системные уровни непонятно чего. Помним при этом, что функциональные разбиения -- это разбиения в момент работы/operations, и они связаны с назначением/функцией (а она в свою очередь упирается в то, что это даёт для моделирования софтом домена, и если не просматривается целевой домен, то что-то с функциональностью не так, архитектура не архитектура). Мой опыт таков, что софтовые архитекторы испытывают огромные трудности с функциональными описаниями и мереологией функциональных объектов! Впрочем, архитекторы предприятий тоже (это ж разговор про практики, труднопонимаемые "процессные объекты").
-- мереология платформ может быть выстроена разным образом. Например, сам "вызов" может быть превращён в 4D объект "сессия" и сервер/платформа и клиент/надстройка над платформой могут выступить взаимодействующими объектами на одном уровне (как показано было в великолепном архитектурном докладе Ивана Подобеда), или можно идти традиционным путём "стеков", где платформа/сервер уровнем ниже её надстройки/клиентов -- и так на много уровней вверх. И в одном и в другом случае можно развести команды (по платформенным уровням или по модулям в рамках одного уровня в разных мереологических вариантах концептуализации домена), но какие-то примеры таких мереологических развилок в моделировании можно было бы рассмотреть в ходе обучения системному мышлению. Повторюсь, обучать нужно не только архитекторов, но и всех остальных.

Я написал в чат спикеров конференции, что считаю сегодняшний день крайне полезным. Почему? Да вот же -- три пункта, которые я тут записал (1. Путаница между формализационным и нотационным аспектами при обсуждении моделей. 2. Редукционизм разработчиков. 3.Мереология софта), это же довольно точные задания на исследования преподавателям наших курсов -- и это не абстрактные исследования из разряда "интересненько", а исследования в ответ на реальные проблемы, которые пришли из производственной жизни. Когда результаты этих исследований попадут в курсы, наши выпускники будут способны замечать проблемы из этих пунктов в своих проектах и они будут знать, в каком направлении искать решение этих проблем. Мир станет чуточку лучше. Так что очень полезно сегодня посидели, я очень доволен.

Наконец-то собрался попробовать в "Братьях Караваевых" калитку с уткой (калитки -- это такие финские пирожки. Похоже по конструкции на хачапури по-аджарски, только тесто слоёное, вместо сыра картошка, а вместо яйца утка. Понятно ведь описал?!). Очень вкусно, рекомендую! За едой беседовал на два фронта: за соседними столами обедали друзья, которые заканчивали сегодня очередной поток "Системного фитнеса". А после конференции я зашёл в зал, где этот "Системный фитнес" только-только закончился, и таки встал на руки: сделал колесо. Впервые после перерыва в три десятка лет. Показывать это ещё совсем нельзя (к земле я был явно не перпендикулярен, это попало на видео, и там градусов шестьдесят -- для первого раза после трёх десятков лет это ОК, но и хвастаться нельзя). Так что я ещё и на двух мероприятиях Школы сегодня побывал -- на конференции и на "Системном фитнесе"!

UPDATE: обсуждение в чате блога с https://t.me/ailev_blog_discussion/1942
2019

Systems priors в representation learning = systems deep learning

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

В современной дискуссии по тому, как сделать искусственный интеллект обсуждаются priors (иногда их называют innate priors, иногда architectural priors), то есть знания о мире, которые должны лечь в основу интеллекта как способности решения самого широкого класса задач. Deep learning -- это про поиск priors в удобных репрезентациях мира. Как презентовать мир, как строить модели мира в сознании (технически понимаемом! любителей медитаций и антропоморфности просьба не беспокоиться!) AI. Вот Yoshua Bengio в посте от 27 декабря 2019 с комментом о его пленарном выступлении на NurIPS (https://github.com/MontrealAI/MontrealAI.github.io/blob/master/aidebate/yoshuadefinitiondeeplearning.png): "Everything in my NeurIPS talk is really about adding priors to help learn better high-level representations". Речь идёт о многоуровневых представлениях мира, что и называется deep learning (при этом representation learnin -- это работа в том числе и с одноуровневыми представлениями. См. мои заметки 2012 года на эту тему, "я занимался deep learning ещё до того, как это стало модным" -- https://ailev.livejournal.com/1045081.html).

У меня гипотеза, что совершенно необязательно брать priors прямо из конструкции мозга (примеры priors интеллекта см., например, у François Chollet "On the Measure of Intelligence", https://arxiv.org/abs/1911.01547, там более близкий пониманию набор, чем у того же Bengio -- более высокоуровневые priors. Никто не сказал, что сами priors одноранговы! И я делю priors на innate/в аппаратуре и pretrain, как в языковых моделях, подробней в https://ailev.livejournal.com/1498481.html). Вполне можно брать priors из тех интеллектуальных практик, которые позволяют этому самому мозгу (вернее, коллективу мозгов!) иметь дело со сверхсложными ситуациями. Я имею ввиду системный подход.

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

Вот я бы что пробовал сейчас, так priors, связанные с системным представлением мира -- systems deep learning. Почему deep learning? Потому что по определению системное рассмотрение -- многоуровневое. Так что речь идёт о системной специализации representations learning, а именно многоуровневому обучению представлениям, systems deep learning. Простая мысль, что мир многоуровневый не так очевидна. Мереология, похоже, встроена в мозги как priors, а все описания тем самым привязаны к частям и целым -- к уровням системы, они системны. Редукционизм большинство людей знают как "просто умное слово, означает упрощение", значения его как упрощение в части игнорирования именно системных уровней не понимают. В этом фишка моего поста. Я и говорю: вставьте это в аппаратуру -- и неважно, самый нижний это уровень, или уровень когнитивной архитектуры (железо, микропрограммы, более высокий уровень -- неважно. Главное, запрограммируйте).

А ещё нужно заметить, что коннективизм, конечно, распространяется за пределы мозга -- а на совокупность мозгов тоже. Те же концепции памяти, внимания, сознания. Ибо мозги семи с половиной миллиардов человек плюс компьютерные мозги (память, процессоры), связанные уже и компьютерными коммуникациями, вполне себе простые элементы, на которых моделируется мир -- строятся распределённые представления мира, и эти представления (representations) должны быть системными. Каждая команда проекта, моделирующая в своих мозгах и компьютерах сложную систему может быть представлена как набор более-менее однородных простых элементов (элементы из уровеня conversational maturity level из https://medium.com/intuitionmachine/an-advanced-capability-maturity-level-for-artificial-general-intelligence-b300dafaca3f). И рассуждения "на способных к диалогу мозгах как примитивных элементах" при этом будут такими же, как в deep learning, коннекционистскими и речь пойдёт о глубоких представлениях. Я просто добавляю, что эти рассуждения должны быть системными -- учитывать многомасштабность, уровни физической организации окружающего мира. Вот он, нейронет.

Так что моя мысль проста: рассмотреть systems deep learning, где priors по тому, как устроена коннективисткая система моделирования мира, берутся из системного подхода (то есть не просто "выделять объекты", а выделять части и целые, на много уровней, разными способами). И эмерджентность, конечно, моделировать причинными графами (важность causal inference в тематике AI -- https://ailev.livejournal.com/1498998.html). Эти причинные/causal диаграммы должны строиться с учётом системных уровней, чтобы быть осмысленными: причины на более низком уровне, следствия проявляются как эмерджентные свойства следующего системного уровня.

Вот к этому можно прикручивать работы типа https://form2fit.github.io/ и https://cs.stanford.edu/~kaichun/partnet/ -- там как раз изучаются отношения часть-целое в инженерии, простейший случай.

UPDATE: обсуждение ВКонтакте -- https://vk.com/wall-44016343_26574, обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10217184890108393
2019

Фронтир фронтира: интеллект, причинность, внимание и сознание в тематике AI в 2020

Сейчас в идёт активное обсуждение доклада Yoshua Bengio "From System 1 Deep Learning to System 2 Deep Learning" -- https://slideslive.com/38921750/from-system-1-deep-learning-to-system-2-deep-learning. Основная идея этого доклада в том, что для канемановского быстрого и медленного мышления в AI основной прогресс произошёл в области System 1, быстрого интуитивного мышления. И теперь нужно решать проблемы рассудочного медленного мышления -- в том числе и проблемы связи быстрого и медленного мышлений.

Ключевое направление -- это осознание связи вычислений с реальностью через концепцию причинности (causal inference). Тут нужно прежде всего указать на работу Bernhard Schölkopf "Сausality for machine learning", https://arxiv.org/abs/1911.10500 (я уже писал о ней в https://ailev.livejournal.com/1498813.html). И дальше просто знакомиться с материалами в тамошнем списке литературы. Высказываемые идеи по причинности как основе для интеллектуализации тупых сегодняшних искусственных интеллектов абсолютно не новы. Вот, например, очень похожий по идеям текст Carlos E.Perez "A New Capability Maturity Model for Deep Learning", https://medium.com/intuitionmachine/an-advanced-capability-maturity-level-for-artificial-general-intelligence-b300dafaca3f, это 28 июля 2018. Я тоже писал в июле про причинность -- "ложь, наглая ложь и причинный вывод (causal inference)", https://ailev.livejournal.com/1435703.html

Затем по линии работы с вниманием (которое уже понимается абсолютно формально, как веса учёта в текущем вычислении тех или иных входных стимулов -- никакой "психологии") всплывает тема сознания. Внимание сегодня одно из центральных понятий в тематике машинного интеллекта, но Bengio делает замечание, что "сознание" существенно демистифицированно уже, и сегодня можно этот термин употреблять в приличном обществе, не привлекая внимания санитаров (https://mc.ai/deep-learning-cognition%E2%80%8A-%E2%80%8Aa-keynote-from-yoshua-bengio/ -- похоже, что Bengio говорит одну и ту же речь на самых разных тусовках). Его выбор -- это Global Workspace Theory, и он напоминает свою работу The Consciossnes Prior по формализации сознания для целей AI (https://arxiv.org/abs/1709.08568). Я в своё время указывал на Attention Schema Theory (https://ailev.livejournal.com/1193568.html), но буквально в сентябре 2019 появился текст про "стандартную теорию сознания", который в том числе гармонизирует Global Workspace Theory и Attention Schema Theory (и ряд других) -- https://booksc.xyz/book/77159558/f47955 (можно почитать и краткий пересказ её идей -- https://selfawarepatterns.com/2019/09/29/a-standard-model-of-consciousness/).

Мысль о том, что речь идёт о AGI -- это уже даже не обсуждается, но AGI уже не понимается буквально как антропоморфный. Речь идёт об интеллекте в его абстрактном/математическом понимании, а не "похожем на человека в части господства на планете", страшилки из научной фантастики и жёлтой прессы тут не при чём. Пример механистического понимания (как сейчас принято говорить, вкладывая абсолютно положительное значение в это слово) интеллекта с выходом даже на математические определения я приводил, рассказывая о работе François Chollet "On the Measure of Intelligence", https://arxiv.org/abs/1911.01547 в "Развиваем интеллект (развиваем способности, а не компетенции)", https://ailev.livejournal.com/1498481.html.

Моё собственное замечание остаётся прежним: нужно прямо все новинки этого фронтира тянуть в обучение людей. Врождённый первичный интеллект нам у кожаных мешков простым способом не поднять, но вот через обучение трансдисциплинам мы можем поднять интеллект вторичный, как способность быстро разбираться с новыми ситуациями -- поднять broad abilities людей, дающие возможность быстро приобретать task-specific skills. Ну, и прочие идеи нужно прямо тащить в обучение людей. Вот, например, как я тащу тематику сознания/осознанности, текст "Системная осознанность, 2019" -- https://ailev.livejournal.com/1487672.html

Итого: в эпицентре фронтира AI в 2020 году будет обсуждение самой интеллектуальности как таковой, медленного мышления в связи с причинными рассуждениями (в том числе контрфактуальность, интервенции), плюс роль сознания (в том числе разборки со вниманием) в мышлении. И напомню: мышление я понимаю как функцию интеллекта, внешнее поведение. Мышление -- это решение новых классов задач через создание для этого новых компетенций. А если компетенции уже есть, то это не мышление, это просто думание. Трансдисциплины учат мышлению (meta-learning), учат быть более интеллектуальным.

И, конечно, все старые темы "узкого AI" при этом остаются -- все эти "задачи планирования" и прочие NP-полные задачи.

Для отвлечения внимания от сути поста: в старом тесте десятиборья по пониманию естественных языков теперь лидирует Baidu, тамошний алгоритм ERNIE имеет результат 90.1 из ста -- http://research.baidu.com/Blog/index-view?id=128. Люди заработали 87.1, этот результат уже победили нейросетки от Гугля, Майкрософта, Фейсбука, а теперь вот и из Baidu (которая победила их всех). Но эти нейросетки нельзя назвать очень интеллектуальными, они настроены на решение очень узкого класса задач. Хотя если вам нужно отвечать на вопросы в каком-нибудь колл-центре, то вам не нужен профессор-отвечальщик. Вам и интеллект кошки сойдёт, если клиенты будут уходить с ответами на свои вопросы. Главное, что такой "специализированный недоинтеллект" уже сегодня стоит дешевле грибов в расчёте на один ответ. А с реальным интеллектом пока всё не так радужно, но и ни разу не застой. А журналисты-гуманитарии, свободно трактующие "интеллект" и "сознание" с ни разу не формальными их определениями, быстро внесут необходимую шумиху и неразбериху -- скучно не будет.
2019

lytdybr

На курс по машинному интеллекту в субботу пришли главным образом выпускники СМС. За кофе шутили, что они-то знают, зачем им этот курс, а не прошедшие СМС -- не знают. Может, так оно и есть ))) Забавным было то, что я сам сильно впечатлился собственным рассказом: я же собираю всё это разрозненными кусочками, а тут вдруг рассказал в том числе и самому себе большую целостную картинку. Ощущение -- это повторное попадание в перестройку, когда было непонятно и ново вообще всё, старые деятельности были обесценены, а новые ещё не были известны. И это происходило со всей страной (СССР) в целом, начиная с 1987 года. А тут перестройка начинается для всего глобуса, вот прямо сейчас. При этом перестройка в СССР-России быстро закончилась (по факту где-то в 1992-1994), и наступил очередной стабилизец. А тут всё только начинается (дата старта по всем известным мне графикам -- 2021 год, когда новые технологии, профинансированные в последние несколько лет, выйдут на массовый рынок), и нет ощущения, что быстро закончится. Главный фактор изменения, конечно, это универсальный интеллект (интеллект, решающий задачи, недоступные человекам -- я подробней писал об этом тут: https://ailev.livejournal.com/1498481.html).

Следующая тема для размышлений -- это работа Bernhard Schölkopf "Сausality for machine learning", https://arxiv.org/abs/1911.10500 от 24 ноября 2019. Читать её нужно ровно так же: написано для машинного обучения, а думать хорошо бы об обучении людей. Бернард чётко пишет в тексте ровно то, что я говорю про философов: философию настоящую делают ни разу не философы. Философы мутны и вторичны, а вот физики, математики, программисты и т.д. -- вот они всё и придумывают, что потом философы выдают за своё. Вот что Schölkopf он пишет: My first conscious encounter with Judea Pearl was in 2001, at a symposium on the Interface of Computing Sciences and Statistics.19 We both spoke at this symposium, and I recall his talk, formalizing an area of scientific inquiry that I had previously considered solidly part of the realm of philosophy. It stirred the same fascination that had attracted me to the research that I was doing at that time, in statistical learning theory and kernel methods. I had a background in mathematics and physics, had dabbled in neural networks, and was impressed when in 1994 I met Vladimir Vapnik who taught me a statistical theory underlying the philosophical problems of induction and generalization. Judea Pearl, another giant of our still young field of AI, seemed to be doing the same on a rather different but equally fascinating problem. Like Vladimir, Judea left me with a lasting impression as someone who has mastered not just technicalities, but has gained access to profound philosophical understanding. Философское понимание дают не философы. А философы? Они писатели, историки, кто угодно. Но идеи, меняющие мир -- не от них. Если интересны идеи, меняющие мир, нужно брать их от людей, которые их придумывают, а не от философов.

Впервые на дне "инженерия предприятия" курса СМС в это воскресенье я давал Архимейт не как рекомендацию, а как опцию. Sic transit gloria mundi. А что в альтернативе? Тексты, конечно. Тем более что в текущем потоке нашёлся человек, более-менее успешно использующий для описания архитектуры тексты в таблицах (на Airtable он говорит, что сделал 10 проектов), и полностью подтвердивший мою критику Архимейта как визуального языка (они и Архимейт пробовали -- и хлебнули все недостатки графичности). Тут нужно сказать, что наш школьный проект оргразвития (https://ailev.livejournal.com/1497402.html) проходит тоже с архитектурой, выражаемой текстами в таблицах. Практики, чеклисты, вот это всё. И хоть до SysMoLan пока не близко, с текстами и таблицами всё одно лучше получается, чем с графикой.

Режим, когда целый день читаешь тренинг, а после этого идёшь на вечеринку (так у меня было в субботу и воскресенье) -- отличный режим. Целый день потихоньку входишь в стресс, а затем за пару часов вся биохимия из этого стресса перемалывается физической нагрузкой в приятной компании под хорошую музыку. Академик Н.М.Амосов после каждого визита к министру здравоохранения запирался в туалете и приседал там сто раз: "гормональная буря должна сгореть в огне движения" -- https://zen.yandex.ru/media/vikent_ru/pochemu-akademik-100-raz-prisedal-posle-vizita-k-ministru-5de9b148e4fff000adb65fe3. Человек -- это не только мозги на ножках, но и ножки под мозгами.

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

Об цифровую трансформацию: то же оргразвитие, и даже не в профиль

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

Цифровая трансформация -- "цифровая" означает, что будет много компьютеров. Как будто их не было и в автоматизации! Автоматизация -- вроде как что-то делал человек, а потом это же стал делать компьютер. Но нет, если что-то стал делать компьютер, то он это будет делать по-другому, и человек тоже займётся чем-то другим: организация от использования компьютеров не столько "автоматизируется", сколько "трансформируется". Ага, с использованием компьютеров. По сути дела, речь идёт об организационном развитии

Можно было бы поддаться веянию времени и начинать говорить о цифровой трансформации, это ж синоним (цифровой -- компьютеризированный по самые брови, трансформация -- это как раз оргразвитие), но этот термин как придёт, так и уйдёт. Скоро, скоро уже заговорят о какой-нибудь "искусственноинтеллектуальной трансформации" или как это будет называться (когда выяснится, что подойдёт не просто работа с данными, а только работа с данными при участии машинного интеллекта), заменят компьютеры на квантовые -- это будет "квантовый оргскачок" и так далее. Вон, несколько дней назад Гартнер выдал новое слово "hyperautomation", гиперавтоматизация. Что, выучиваем и его? Больше buzzwords богу buzzwords?

Мы помним, что почта вдруг стала электронной, а потом просто почтой (а потом переписка ушла вообще мессенджеры и какие-нибудь Slack или MS Teams). Бухгалтерия тоже становилась механизированной (с Феликсами и табуляторами на перфокартах), а потом компьютеризированной, а потом осталась бухгалтерией.

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

Нам не нужно называть проект так, чтобы попадать в правильную строчку госбюджета. Все эти поветрия с модными buzzwords приходят и уходят, а шаги развития организации, которые нужно делать -- остаются. И они сегодня не бывают без компьютеров.

Повторюсь:
-- компьютеры используются для того, чтобы была память для модели организации (архитектура, операционный учёт)
-- компьютеры используются для управления коллективным вниманием к этой памяти (issue tracking, управление работами)
-- компьютеры используются для принятия решений (машинный интеллект, и не нужно думать об AGI. Любое вычисление подойдёт, лишь бы не в голове человека).

Подробней об этом я писал в:
-- системная осознанность, https://ailev.livejournal.com/1487672.html
-- киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием, https://ailev.livejournal.com/1488271.html

И мы всё это используем в нашем проекте развития -- использование информационных технологий в реализации стратегии Школы:
-- EdTech для blended learning -- те же PLM/ALM + CAD/CAM/IDE, только в образовательный профиль, https://ailev.livejournal.com/1473691.html
-- чего мне не хватает в MS Teams -- https://ailev.livejournal.com/1490524.html
-- стратегирование Школы системного менеджмента -- https://ailev.livejournal.com/1493744.html
-- видео семинара по созданию AIsystant и blended learning services, https://ailev.livejournal.com/1494270.html
-- чеклисты в blended learning services: не прощёлкать важное, но и не забюрократизироваться, https://ailev.livejournal.com/1497117.html
-- множество заметок в lytdybr (например, https://ailev.livejournal.com/1496250.html -- там я говорил про RPA как ведущий тренд)

Дальше нужно понимать, чем же именно проекты развития с компьютерами отличаются от "просто проектов развития". По большому счёту, ничем. Но в этих проектах развития заимствуется огромное число находок из управления жизненным циклом и управления работами из software engineering. В частности, в управлении жизненным циклом из существенных новаций можно заметить DevOps (плавно переходящее в NoOps, https://ailev.livejournal.com/1367897.html) и свеженький его извод SRE (site reliability engineering, включая обширную дискуссию его похожести и отличий от DevOps -- главным образом то, что в NoOps куда-то делись Dev, а в SRE они в полной мере присутствуют).

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

В НИУ ВШЭ мы читаем также курсы в магистратуре "Цифровая трансформация образования" -- https://www.hse.ru/ma/dt/. Там, конечно, всё завязано на госбюджет, поэтому "цифровая трансформация". Мы же сказали бы просто: это школа менеджеров развития образования. Если есть практика организационного развития, то есть и деятельностная роль -- управляющие развитием, менеджеры развития.

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

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216830525489499
2019

Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом

Человеческая деятельность коллективна. Но почему-то образование в части мышления часто сводят к умению пораскинуть мозгами в части решения каких-то олипиадных задачек: условие таких задачек полностью однозначно, время решения 2-4 часа одного человека, уточнений условий задачи не требуется, ответ короткий и по факту нигде дальше не используется (проверка/верификация есть, приёмки/валидации нет). Вот из школы и из вузов ровно такие люди и выходят: победители олимпиад, крайне сообразительные, умненькие.

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

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

В программировании это различение известно как программирование-в-малом (по сути, олимпиадное программирование, programming-in-the-small) и программирование-в-большом (programming-in-the-large). Я потом эту тему обобщил до моделирования, онтологизирования, проектирования (это ведь в всё одно и то же по большому счёту) в малом и большом (см. пост "Онтологические модели -- это про проектирование/программирование/моделирование-в-большом" ещё 2009 года, https://ailev.livejournal.com/748188.html). А потом говорил и про производство в малом и в большом (см., например "стандарты производства-в-большом, 2010 -- https://ailev.livejournal.com/851977.html, и продолжение про стандарты каталогизации -- https://ailev.livejournal.com/852642.html).

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

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

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

Мой пойнт тут в том, что деятельности-в-большом нужно и можно учить. Но это обучение не какой-то прикладной "олимпиадной" дисциплине. Это обучение трансдисциплинам: логике, онтологии, коммуникации (важно! коллективный характер проектов тут!), коллективному принятию решений (важно! это не самому "напружиниться, и решить"), научному мышлению, далее системному мышлению, вычислительному мышлению -- все из которых оказываются коллективными (да, и вычислительное мышление тоже! олимпиадное программирование имени Дональда Кнута осталось в далёком прошлом), а дальше кругозоры -- про практики системной инженерии, менеджмента, предпринимательства и т.д., и множество ролей для этих практик, без понимания которых проект в голову не уложишь. А не уложишь проект в голове -- будут проблемыв со вписыванием своей работы в работу команды, и работы команды в ещё более широкий круг работы всех остальных людей на планете. Будешь очень умным в части решения никому не нужных проблем, но идиотом в части реальной проектной работы. Умным теоретически (ибо хорошо вышколен в плане рукоделия -- хоть мыслительного, хоть ремесленного!), но бесполезным "по жизни".

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

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

Это просто ещё один способ говорить о Т-людях (глубокие прикладники, но с широким кругозором -- https://ailev.livejournal.com/1459798.html). Но в посте ещё и акцент на различие самих практик-в-большом и практик-в-малом. Владение трансдисциплинами позволит легче разобраться с более сложными практиками-в-большом (программирование того же кровавого энтерпрайза, например, по сравнению с олимпиадным программированием, или менеджментом в крупной организации по сравнению с менеджментом команды из только себя, любимого).

Отдельный вопрос -- а чем же практики-в-большом отличаются от практик-в-малом? Судя по тому, что происходит с тем же программированием по мере его превращения в программирование-в-большом -- практически всем! Собственно, мои посты 2010 года были как раз об этом. Вот трансдисциплины и нужны, чтобы понять -- учат вас прикладным рукодельным практикам-в-малом, или проектным практикам-в-большом. И далее принять осознанное решение по изучению той или иной прикладной практики -- даже не в момент её применения в каком-то проекте, а ещё в момент принятия решения об обучении!

Техноэволюция идёт (open-endedness, https://ailev.livejournal.com/1463013.html ), жизнь становится сложней. Нужно учиться, нужно как-то этой жизни соответствовать. Быть умненькими и не дебилами.
2019

Лекция "Машинный интеллект 2019"

Читал сегодня в Высшей школе менеджмента НИУ ВШЭ кругозорную лекцию "Машинный интеллект 2019" для DBA (doctors of business administration). DBA это вроде как следующая ступень после MBA, и точно так же это совсем не научная или инженерная степень. Студентами там сидели вполне состоявшиеся руководители и предприниматели. Лекция шла целый день, четыре пары.

Вот программа, это просто заголовки слайдов (значения всех умных слов там разъяснялись "на пальцах" и примерах, а математики и программирования не было вообще):

1. Интеллект: машинный и биологический
Будущее уже здесь, только оно неравномерно распределено. Откуда взялся человеческий интеллект? Искусственный интеллект: "то, что компьютеры пока не умеют делать". В чём суть сегодняшнего прорыва в машинном интеллекте? Всё быстро. Глубокое обучение: глубокие абстракции. Почему только сейчас? Тезис Sutton, 13 марта 2019. Сингулярность. Примеры сегодняшнего (а не будущего). NLP — обработка естественного языка. Goal: capuchin-like. Скорость исследований: растёт по закону Мура. Как устроены исследования. Ловкость, embodied intelligence. Заземление/grounding и embodied intelligence. Творчество и соревновательность (adversarial architectures). Open endedness. Там нет "интеллекта", в чём тогда крутость? Как относиться к AGI. Принципиальная схема киберличности. Киберличность и работа с вниманием. Роботы заберут работу? Чьи это виртуальные ассистенты? Adversarial attacks, deepfakes и так далее. Нейтральность технологий.

2. Интеллект-стек
Системные уровни интеллект-стека. Эмерджентность. Стек платформ машинного интеллекта. Платформы машинного обучения. Главный алгоритм. Альтернативный стек глубокого обучения. Малая связность: ключ к развитию и совершенствованию. Метафоры жизненного цикла "компетенции" (в том числе машинной). Языковые модели. Загон данных (data wrangling), сантехника данных (data plumbing). Проблема innate priors. Моделирование, программирование, проектирование, онтологизирование, формализация — это всё одно. Машинное обучение и уровень когнитивной архитектуры. Перспективы.

3. Применения
Мечты человечества (как оценивать прогресс?). Деятельностный кругозор ("как устроена жизнь"): применения AI везде, где есть применение людей. Инвестиции в AI. Forbs: обзор 50 AI startups (17 cентября 2019). Сегодняшний фронтир: автомобили. Инвестиции сегодня, результаты завтра. Что дают дешёвые качественные камеры? Ножиданные виды сервиса и слежку. Машинный перевод. Офисный ИскИн, который построил Джек. Научные открытия. Интернет вещей (IoT), BigData и AI, тесно связанные с предсказательной аналитикой. Робототехнические заводы (тёмные фабрики). Корпусная инженерия. Код и AI модели как ещё один тип медиа: магазины и облака. Взять идеи из машинного интеллекта в педагогику. Основные проблемы. Цикл жизни инженерных технологий: пример AI. Дилемма инноватора.

В ШСМ я эту кругозорную лекцию повторю 3 ноября 2019, http://system-school.ru/machine

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

Чего мне не хватает в MS Teams

Провёл вчера целый день в офисе MS (pun intended, речь идёт о помещении) в изучении MS Teams, читал тамошние пейджеры и много думал. Основной плюс -- Teams можно рассматривать как эдакую систему повышения осознанности в командах. Презентация продукта напирала на то, что Teams имеет много разных средств управления вниманием команды, это ровно в направлении мыслей по киборгизации команд: https://ailev.livejournal.com/1488271.html

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

Как живут вместе разработчики и клерки (разработчики сидят в Visual Studio и Azure DevOps, клерки в Office и Teams) -- непонятно, ибо в Teams всё выстроено вокруг офисных документов в папочках, а в DevOps вокруг системы управления версиями кода. Всё, что на вкладках в Teams (даже на вкладках Planner как тамошней реализации канбан-доски) -- остаётся на вкладках и не втягивается в беседы, хотя есть способы привлекать внимание ко вкладкам (коннектор может сообщить, что во внешней системе что-то произошло и выдать в беседу ссылку на место, куда смотреть).

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

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

Альтернативные решения (сразу в голову приходит стек Jira+Confluence+Slack) по тем же критериям более заморочены: они ориентированы на разработчиков больше, и меньше на менеджеров, предпринимателей и уж тем более на внешних людей. Остаётся признать, что нет в айтишном мире счастья, оно всегда впереди, как горизонт.

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

Ещё барьер для входа. MS Teams это форум+мессенджер+контент+групповые звонки и поэтому входной барьер там примерно вчетверо от входного барьера в одиночных приложениях. Нужно полчаса на то, чтобы разобраться в интерфейсе. Если человек к нам приходит на короткий шестичасовой курс, то будет ли он доволен, когда ему придётся в этом разбираться? Но на втором же коротком курсе это окупится сторицей. Или если курс шестидневный. Это опять же к вопросу, что у нас Школа представляет собой какой-то симбиоз кровавого энтерпрайза и социальной сети.

Записал себе в план набросать архитектуру курса blended learning (cейчас Школа использует фейсбук, телеграм, imind, яндекс.диск, почту и ВКонтакте для организации работы -- плюс зоопарк самых разных authoring tools, от Офиса и yEd до видеокамеры, Archi и совсем уж экзотических рисовалок у наших курсантов). Сказать, что связность всех бесед выше, чем она была бы в Teams -- нельзя. Но значительная часть бесед идёт в соцсетях или группах telegram и публична. Но часть наоборот, непублична -- обсуждения в учебных группах, обсуждения по линии менторства. Там обсуждаются рабочие проекты, они не любят яркого света. Вот как правильно поделить внешние и внутренние беседы -- это отдельный вопрос.

Что касается учебных проектов -- идеи из статьи про учебный CAD+PLM остаются в силе (https://ailev.livejournal.com/1473691.html), и будем их потихоньку реализовывать. Но думать и о социальном шлейфе, жизненный цикл курсантов начинается задолго до начала курсов и прекращается сильно после их окончания. С абитуриент-курсант/студент-alumni (при этом ещё для каждого отдельного курса и для школы со множеством курсов в целом -- есть разница) та же онтологическая проблема, что и с issue-task-notice: софт это должен поддерживать, но из коробки ни один софт это поддерживать не будет.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216340724924791
2019

Дискуссия о типах и SysMoLan продолжается

Обсуждение SysMoLan в чате представления жизни типами (https://t.me/typeslife) не утихает.

Философская логика
В частности, там пришёл Brenoritvrezorkre (The name Brenoritvrezorkre is written in Gloatre, a language invented by Vordb Dréagvor Uèzréèvb, https://katab.asia/2018/10/16/zurghtapre-of-cannibals/, Бреноритврезоркре — плохая примета, дурное предзнаменование) и рассказал всем, как нужно заниматься экдурантизмом и пердурантизом в частности и философской логикой в целом (для начала читать 18 томов учебника, вот ссылка на том 18, остальные сами найдёте -- https://b-ok.cc/book/3662367/9d5f0c. Не знаю, насколько знание этих восемнадцати томов может помочь в нашей задаче выразить в типах языка программирования понятия системного подхода в том небольшом объёме, который есть в учебнике (и для начала IEC81346 как подмножество этих понятий. Хотя это я лукавлю, стандарт-то большой и заковыристый, понятий там предостаточно). Знание этих восемнадцати томов учебника может помочь IMHO примерно так же, как знание всех томов Кнута может помогает программистам в их работе. И для меня неважно абсолютно, что такое possible worlds в логическом формализме и какая там история их создания. Для меня важно ровно то, что я могу при помощи possible worlds принимать решения в своём проекте: говорить о том, какая именно модель будет реализовываться и какие последствия будут от тех или иных моих решений, и как связаны мои планы и актуальное состояние. Абсолютно прикладное использование, реализация прагматического поворота в философии. Нет использования — не нужно обсуждать этот формализм, есть использование — нужно обсуждать.

Тем не менее, какое-то знание философской логики всё-таки помогает чуток разобраться. Скажем, меня прежде всего волнует описание физического мира в первую очередь, и в концептах системного подхода, а не описание описаний в любых концептах (например, при помощи очень часто встречающихся в IT URI и даже URL). Поэтому у меня ключевой вопрос про моделирование IEC81436, где в том числе обсуждается вопрос привязки документов к системам, а у justy_tylor ключевой вопрос про работу с документами без их привязки к системам.

Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

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

Дальше там был короткий спор про философию как таковую (моё отношение к философии как к художественной литературе, особенно в стране победившей истории философии вместо философии, см. "О философах как властителях душ" https://ailev.livejournal.com/1128233.html и там дальше про этих властителей дум роскошные комменты). Но это всё было сочтено оффтопом к теме чата.

Естественный язык против формул
Ещё темой было использование естественного языка -- почему мы не можем от него отказаться и говорить только формулами. [байка он] Лет так пять назад я попал на конференцию по аналитической философии, делал это руководитель логико-философского кружка ВШЭ Виктор Горбунов. Он сильно удивлялся, откуда инженеры знают про possible world и Дэвида Льюиса. Но занятно было другое: шли обычные для конференции разговоры-разговоры разных докладчиков, не произносилось ни одной формулы, всё как обычно. Но вдруг кто-то из зала сказал: "я, кажется, понял!". Он вышел к доске и исписал в гробовой тишине всю доску формулами. Ему поправили из зала одну ошибку (даже не ошибку — он мелом плохо нарисовал точку над одним из квадратиков), и дальше до конца дня ни в речах, ни на доске никаких формул не было. [байка офф]

У каждого человека свои представления в голове об уровне формализма, на котором он хочет работать. И работать нужно на полном спектре мышления, а не всё время "в формулах". Фишка в том, чтобы двигаться по спектру формальности мышления, а не просто работать в рамках одного формализма всё время (у меня про это много больше в книжке "Визуальное мышление", https://ridero.ru/books/vizualnoe_myshlenie/ или её можно взять бесплатно в info чата, можно посмотреть ещё вышедшие до этой книжки короткие тексты по развитию мышления -- https://ailev.livejournal.com/1425003.html и про творчество в системном мышлении https://ailev.livejournal.com/1425331.html).

На помянутой в байке конференции доклады были все об идеях Крипке, Льюиса и их коллег, но без формул. С формулами была только вот та самая вставка. Как я понимаю, людей на логическом отделении философского факультета учат отождествлять текст и формулы в обе стороны — формализовывать и деформализовывать. Поэтому они не стесняются говорить о формальном и текстом тоже, это абсолютно нормально. С архитектурными моделями точно так же: Дэвид Файерсмит предупреждает всех, что из архитектурной документации ни в коем случае не должен уходить текст и оставаться только модели на формальных языках моделирования -- ибо даже сам смысл выбора тех, а не иных способов моделирования (viewpoints) должен обосновываться текстом и представляться в составе документации, равно как и самое верхнеуровневое описание в виде "архитектурного эссе".

Почему для работы с формальными системами (особенно, если их несколько одновременно в рассмотрении) нужно иметь и естественный язык — об этом любит рассуждать John Sowa (родоначальник computational ontology, он и до сих пор бодрый дядька, недавно его чуть в сообществе Ontolog FORUM не забанили — он там сильно наехал на создателей очередного всеобщего онтологического ISO по поводу их заблуждений, там работала уже административная машинка и голосовательные популистские механизмы, а John "вынул гранату, кинул в окно — дедушка старый, ему всё равно". Я там член попечительского совета, с интересом наблюдал за этой историей борьбы здравого смысла с бюрократической политкорректностью. Онтологии дело нервное!). Так что формализмы и естественный язык нормально сосуществуют, и это не бага, это фишка/фича.

Народные онтологии
Обсуждали в том числе и использование народной (из общепринятых словарей) онтологии -- ибо были сделаны попытки использования теории типов с интерпретацией на базе "просто из вебстера". то у меня превращается. Вопрос на практике возник из непонимания, как делать системы тегов: на основе какой-то таксономии (которые вроде бы хоть как-то логически выверялись), или на основе народных представлений ad hoc (folksonomy). Любили при этом поговорить о фасетной классификации и всяких подобных материях. Потом оказалось, что:
а) предмет интереса во времени плывёт, и из старых текстов берут вовсе не ту информацию, по которой они были протегированы
б) полнотекстовый поиск заменяет все эти теги

Онтологии — это просто добавление к таксономиям разных типов отношений. Дальше мы уже обсуждали тут, что Грубер определил computational ontology как формализацию для концептуализации предметной области, но его поправили, заявив, что это должна быть shared концептуализация — то есть речь идёт о разделяемой (каким-то сообществом, folk) картине мира, а не любой картине мира.

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

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

У нас совершенно конкретная предметная область. И проход улучшения феноменологии для концептов из учебника был, это несколько лет обсуждалось в сообщстве Русского отделения INCOSE, обкатывалось на разных учебных курсах, понимание уточнялось и по возможности согласовывалось с современными онтологическими представлениями (в том числе представлениями из книжки BORO). Формализом там, конечно, и не пахнет, ну так я ж особо и не настаиваю — просто потихоньку обсуждаются разные уровни этого формализма (там ведь эти формализмы до самого низа, и всегда будут проблемы, не хотелось бы их прихватывать, начиная от уровня проблем оснований математики).

Foundational ontology и солвер для неё как менеджмент внимания/управление данными
В какой-момент я в очередной раз прояснил свой интерес в дискуссии: предположим, я пытаюсь сделать язык для системных описаний/моделирования, при этом заявляю, что где-то под ним должен лежать более общий язык онтологического моделирования. То есть foundational ontology, над ней upper ontology без понятия "система" (зато там понятие агента, возможных миров и т.д. -- онтологическое моделирование как таковое), а уже дальше middle ontology как системная онтология, системные концепты как только одна из рабочих онтологий в рамках upper ontology. Это вроде как должно быть удобно, когда приходится миксовать системные и не системные (каковых большинство, конечно) рассуждения.

Альтернативный подход -- понятия системного мышления нужно считать входящими в состав upper ontology "из коробки", и мэппить внесистемные понятия нужно не сначала к понятиям более общей онтологики, а только потом к понятиям системного мышления, а сразу к понятиям системного мышления. И понятия системного мышления базируются на более общих онтологических понятиях, но не образуют совсем уж отдельный уровень.

Я придерживаюсь сейчас этой позиции, примерно это же предложил Matthew West с его HQDM в альтернативу онтологии ISO15926, а также некоторые другие неожиданные товарищи (типа СМД-методологов, регулярно обсуждающих этот вопрос -- ибо для них в силу их гуманитарной ориентированности концепты upper ontology как-то неразрывно связаны с рассуждениями о боге, но хочется иметь светскую upper ontology, для чего и интересует системный подход как основа светской онтологии -- это эхо, конечно, чисто метафизической дискуссии, привет из прошлого. Тем не менее, это пример того, что желающих иметь системную upper ontology "из коробки" достаточно много и кроме меня и Matthew West).

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

И да, я понимаю, что работать в этом моделере придётся с самыми разными описаниями. Но нельзя терять тот аспект, что эти описания привязываются друг ко другу, и в конечном итоге к системам. Поэтому имена, к которым все эти описания привязываются в конечном итоге, важны. Стандарт IEC81346 даёт best practices в том, как делать имена для систем, и даже даёт best practices, как делать имена для документации этих систем (хотя этот вопрос там и не главный и значительно хуже проработан. Может, в последние годы там что-то изменилось с именами описаний, тоже вышли какие-нибудь практические рекомендации). Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

Дальше было заявление justy_tylor "Тут у нас разница в интересах. Если придерживаться "онтологической" терминологии, то мой интерес это foundational ontology. Я считаю, что только построив foundational, и подтвердив её удобство в мэппинге между используемыми на практике представлениями данных и modeling approaches, можно построить приемлемую upper ontology над ними. Потому что обратный подход (upper без приличной foundational) мы уже наблюдали, в том числе, в ISO 15926, и получались какие-то untested beliefs. Поэтому вопросами upper я не занимаюсь - рано".

Для меня это уже было понятно, для меня это звучит как:
1. Foundational ontology для моделирования описаний, но не для моделирования мира в целом
2. Foundational ontology для upper ontology из классической онтологики, без акцентов на системном подходе.

Это выборы justy_tylor в уже высказанной развилке: системное мышление в рамках upper ontology или системное мышление в рамках middle ontology. При этом я с тяжёлым вздохом говорю, что ни upper, ни systems middle ontology действительно ни при чём при выборе foundational.

Но дальше есть некоторое соображение. Я в своё время начинал работать в исследовательском вычислительном центре, где разрабатывалось много-много компиляторов, языков программирования и т.д.. И было поэтому много-много людей, которые занимались формальной семантикой языков. И почему-то успех был в ЖЦ, когда создавалось полностью неформальное ad hoc решение на диких эвристиках, и эти дикие эвристики вдруг оказывались хорошими, под них люди кряхтели и подыскивали формализм, потом подхакивали эту эвристику, чтобы не поломать её об формализм и дальше получали формальное успешное решение. А вот где сначала был формализм, потом попытки его "прикласть" через создание "прикладного языка с формализом внутри" — вот тут всё плохо было обычно. Учёные восхищались, система входила во все учебники как "удивительно простая и элегантная, решение всех проблем" — но популярности эта "элегантность и компактность формализма" явно не добавляла. Монады хаскела можно отнести к очередным примерам (пока хаскел с 1990 года уже 30 лет "продолжает набирать популярность", успел стать суперпопулярным и потом умереть тот же эклектичный перл, родившийся примерно в то же время, в 1987 году, а Питон от 1989 года успел стать суперпопулярным и не умереть). Оказывается, формализмы и обильная математика под языками программирования не являются гарантами их популярности -- и даже наоборот, как-то коррелируют с непопулярностью!

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

ISO 15926 рухнул IMHO ровно из-за выбора мощного рудиментарного формализма триплами. Триплами можно что-то выразить на очень низком уровне, это foundational ассемблер и должен быть очень глубоко под капотом. До удобных шаблонов с n-арностью в выражении мира мир ISO15926 так и не дорос, ло. Если бы сразу были шаблоны, то всё ещё могло бы состояться. А потом эти шаблоны бы посадили на какой-нибудь формализм, а хоть и те же триплы. Но потом, когда бы всё уже было понятно как устроено и был бы опыт моделирования. А иначе — 18 триплов, описывающих величину с указанием единицы измерения, я помню (). И никакого практического способа указать "x=5кг" вот этими вот пятью символами, ибо "шаблоны и как их выразить, чтобы не порушить формализм" было выдумано явно несвоевременно.

Прорывы типа реляционного формального исчисления и SQL — ну, это ошибка выжившего. Всегда есть исключения, которые на слуху именно потому, что они выжили. За счёт чего они выжили? Я высказывал какие-то свои соображения по поводу де-факто разделения языков управления данными и языка вычислений над данными. Это зыбкая граница в computer science и даже software engineering, но уж какая есть.

Так что я интересуюсь в чате у знатоков языков программирования: как принято типами языков программирования выражать онтологии? А мне отвечают: сначала нужно иметь foundational ontology, чтобы выражать онтологические upper ontology типы, для этого нужно придумать формализм, для него сделать солвер, и уж потом это всё выражать в Julia. Я время от времени задаю вопрос про "можно ли прямо типами языка и структурами данных Julia?" и получаю ответ, что нет — ибо должен быть не GPL+eDSL с моими типами и структурами данных, а GPL+язык запросов+солвер-с-формализом. Но поскольку время от времени появляются разные варианты ответов, то я продолжаю внимательно слушать.

Дискуссия дальше идёт о том, нужна ли вообще upper ontology или сразу микротеории без upper (но само понятие микротеории тогда как выражать? из какой оно онтологии?), а foundational ontology это и есть "новый upper" (у байесовцев в ML это называется innate priors — те концепты, что мы не можем выучить из мира и таки должны задать "в аппаратуре/алгоритме обучения"). Я готов и это обсуждение поддержать. Но моя мысль, что вот это "реализованное в аппаратуре" должно бы включать мир (физичный), модели (описание) и тех, кто описывает (агентов с их предпочтениями в интересах и намерениями по изменению мира, для чего им и нужны модели). А поскольку мир и агентов и описания, то можно смело туда сразу записывать и системный подход, как уточняющий тем, как управлять вниманием в мире. Управление вниманием, системное мышление из менеджерских/логистических краёв, оно не про трансформации.

Собственно, про это "управление вниманием", "менеджерское/логистическое" программирование для того, чтобы предоставить данные для трансформации возникло как моя реакция на реплику justy_tylor по поводу задач, которые он считает важным для языка работы с foundational ontology: "осуществление логического вывода (прямо в этом представлении), двухсторонний мэппинг с другими представлениями (оптимизированными под конкретные предметки), визуализация (таблицы, деревья, диаграммы), интеграция фрагментов описаний, разрешение конфликтов интеграции (как автоматически на машинном уровне, так и в diff-merge утилитах с участием человека), и так далее".

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

Содержательные задачи не требуют логического вывода, они лучше решаются по другому. Это для логистики (выбрать те данные, с которыми потом будет что-то интересное делаться) важно.

То есть получается, что есть один язык для собственно работы (какая-нибудь Julia), а все эти выводы-мэппинги и т.д. это управление памятью и вниманием над памятью (какой-нибудь SQL).

И все эти заходы на морфизмы — у меня прямо таки все кейсы перед глазами, когда менеджеры рассуждают про строительство предприятий, стараясь абстрагироваться, спички эти предприятия выпускают, вебсайты, или ракеты на Марс. Опыт показывает, что в итоге предприятие работает очень хорошо, пока у инвестора деньги не кончаются. Если строишь завод самолётов, то завод будет работать хорошо, только самолёты могут не летать )))

Надо будет подумать. Современный AI, конечно, все задачи сводит к управлению вниманием и памятью сегодня, но в знаниях не всё можно "вспомнить" или "найти где лежит". Чтобы в базе данных что-то появилось, туда нужно что-то класть. Языки запросов, как известно, базу данных не меняют, почему их и называют языками запросов. Это потом почему-то хочется туда и запись информации вставить. Всегда хочется.

Надо будет ещё подумать, почему эта формализация мне менеджеров против инженеров напоминает. При этом абсолютно понятно, что для логистики "что угодно достаём откуда угодно и транспортируем в заданном формате куда угодно, гарантируя непотерю содержания" и работы "делаем преобразования" требуются разные архитектуры, разные языки, разные способы работы. PLM и мэппинг — это про логистику, это ж lifecycle management, менеджмент. В принципе, инженер без логистики ничего делать не может (задачу он получает, входные данные и материалы получает, выход тоже у него уходит куда-то в другое место). Но разделение "логистика/внимание vs трансформация" при всей его неуловимости в области информационных технологий и математике по крайней мере хоть как-то объясняет мне происходящее. Разделение труда: одни на фортране считают режимы, а другие на логическом языке SQL (pun intended) выдирают из общих описаний материал, на котором первые считают эти самые режимы. Все довольны, всем счастье. Языки не представления знаний, а управления данными и инженерные языки для предметных вычислений. Хм. Как-то подозрительно всё сходится.

Так что нужно сделать два языка, как-то связанных друг с другом, или один мультипарадигмальный язык, в котором есть и язык логического вывода для управления вниманием/данными, и язык общего программирования для трансформаций данных. Общий язык для менеджеров данных и инженеров предметной области. Потому как разрыв мной ощущается где-то в этом месте: базы данных с языками запросов и по сопричастности логические языки и классические языки представления знаний с FOL/HOL в основе против каких-то специфичных преобразований на GPL и тогда логика в GPL появляется только для доказательств правильности (иначе все умрут, если логикой не долько добывать данные и доставлять их на обработку, но и обрабатывать/трансформировать/что-то с ними вычислять). И между этими языками вроде как неминуемые всякие ORM (object-relational mapping) и прочие GPL-logic mappings, которые я бы и хотел исключить -- почему и затеял всю эту дискуссию.

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

Грубо говоря есть какие-то CAD-с-редакторами и солверами разных domain, где так или иначе что-то типа Архимейта или 3D-моделера, а есть PLM с "базой данных и логистикой", куда все эти CAD втыкаются. Это общая структура разработки чего угодно, даже программного кода (есть IDE и есть Git). Я немного писал об этом в https://ailev.livejournal.com/1277009.html, и даже EduTech для образования может быть описана таким образом, https://ailev.livejournal.com/1473691.html.

И у меня гипотеза, что CAD будет всегда с GPL внутри (когда-то в AutoCAD был даже лисп, но потом всё нормализовалось). И IDE будут с GPL внутри, ибо "всякая достаточно большая программа содержит в себе кривой и плохой common lisp", уж так получается. А в PLM всегда важен мэппинг, чтобы взять данные из одного вида CAD и послать их часть в другой CAD на просмотр и редактирование (руками или программно — это неважно).

Фишка в том, что CAD и PLM не живут друг без друга, поэтому начинаем с моделера-CAD, а заканчиваем всё одно PLM-базой данных с кучей экспорт-импортов, или наоборот — начинаем вроде как с мэппинга-в-PLM, а заканчиваем сначала неизбежной визуализацией, а потом и обязательно редактированием WYSIWYG и для этого всё одно солвером, то есть приходим к группе CAD для разных domain, отражённых в начальной PLM-базе.

Если начинать с мэппинга, то сразу вопрос: а где брать системные модели, к которым мэппить всё остальное? Нужен таки моделер перед тем как к нему мэппить. Моя идея взять IDE типа Вижуал Студия и считать её моделером, если модель будет в текстовом eDSL системного моделирования. А потом да, к ней мэппинг, когда эта модель уже есть и есть средства её отображения. Прошлый вариант ТЗ уж как я его понимаю я формулировал в https://ailev.livejournal.com/1488488.html — и более точно пока сформулировать не могу. После этого текста из нового пока у меня только эта мысль про различие eDSL для управления данными (и представление знаний вроде как идёт сюда, тут все интеграции и прочие "семантические технологии") и для работы с данными (все матлабы и CAD вроде как тут, а логические языки не тут) с какими-то "мэпперами" из типов/foundational ontology языка рабочего языка программирования в типы/foundational ontology менеджерской базы данных, я продолжаю эту мысль думать дальше, она интересна. С этой мыслью domain онтологической работы и по сопричастности системной работы представляется мне немного другим. Трансдисциплины (онтологика и представление знаний, системное мышление) для управления вниманием, а оптимизация, порождение и прочее такое делается на других дисциплинах их eDSL.

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

Для меня это звучит более понятно как поиск foundational ontology для upper ontology из учебника. И для foundational ontology предполагается, что можно сделать движок/солвер/реализацию языка запросов и хранилище данных для этих запросов (но это не предполагает вычислений в инженерном смысле, а просто "управление данными"), а upper ontology из учебника при этом как-то закодировать в виде данных для этого движка. Такой подход подразумевает, что математически все запросы смогут быть исполненными (хотя гарантий времени исполнения и возможности оптимизации запросов не даёт никто, и это сильно меня напрягает: похожие проекты по формализации с похожей архитектурой все заканчивались печально, типа тех же разработок с BDI и агентским подходом и родственниками — математически там было всё ОК, но вот пользоваться софтом там было невозможно).

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

Теория прототипов, трансформеры и успех языков программирования
justy_tylor заметил, что "помимо упоминавшихся BORO, ISO 15926, Gellish, HQDM, а также книжки @ailevenchuk и мелькающей в последнее время таксономии IEC 81346, для понимания рассматриваемых тем неплохо бы прочитать:
1. Три тома материалов HOPL. https://en.wikipedia.org/wiki/History_of_Programming_Languages
2. Пару книг Лакоффа по когнитивной лингвистике: George Lakoff and Mark Johnson "Metaphors We Live By", George Lakoff "Women, Fire, and Dangerous Things: What Categories Reveal About the Mind".

Лакофф затем, что популярно описывает явления вроде "базового уровня восприятия", понимание которых является ключевым для создания эффективных EDSL".

Я нашёл это замечание очень интересным. Типы и FOL из theory theory поддерживают медленное мышление по Канеману, а прототипы (Лакофф! Первичное восприятие!) — быстрое. Если говорить об успехе в рамках теории percieved cognitive load, то эту нагрузку, получается, нужно считать не в типах/классах из theory theory, а в прототипах (https://plato.stanford.edu/entries/concepts/ -- про теории понятий, в том числе theory theory и prototypes, хотя там есть и другие). То есть в спектре мышления по мере движения по этому спектру в пространстве смыслов формализация не просто relax в рамках theory theory по мере движения влево, но и меняется её способ, и всякие "интуиции" по поводу тех же типов/классов (и отнесения к типам/классам) формулируются как прототипы для типов/классов. Это, конечно, гипотеза, но покрутить её было бы весьма любопытно. Если (как предложила @pionmedvedeva в какой-то момент) у нас таки спектр формальности, т.е. в середине там гибриды медленного и быстрого мышления, то по факту у нас где-то в середине будут и гибриды theory theory и теории прототипов.

Сам заход на то, что нужно для создания удобного eDSL поразбираться с мышлением, мне кажется важным. Понятно, что и IEC81346, и понятия из учебника системного мышления — они все из theory theory. И предлагаемые для них варианты концептуализации (предлагаемые foundational ontology) тоже из theory theory. Что про эти навороты будут думать люди, которые не прошли десятилетнего математико-логического тренинга (а, например, прошли пятилетний подобный тренинг) — это в дискуссии только разок мелькало, когда про когнитивную нагрузку говорили и в том числе теорию piercieved cognitive load как барьер к массовому распространению.

Очень, очень интересно. Это для меня вторая интересная мысль из дискуссии, после мысли про язык представления знаний как язык логистический для управления вниманием на какой-то памяти, но не трансформации. [при этом, конечно, сразу захочется его иметь и для трансформации, и попытки делать чисто логические вычисления для меня становятся чем-то типа недифференцируемого варианта трансформер-архитектуры для нейронный сетей: выкидывается всё, кроме работы внимания — https://medium.com/inside-machine-learning/what-is-a-transformer-d07dd1fbec04, и я понимаю, что это аналогия полная шапкозакидательства, но мы ж тут Лакоффа и метафоры обсуждаем, или что?! )))]

Логическое моделирование в системной инженерии
Вообще, должен сказать, что логическое моделирование в системной инженерии по факту есть (хотя его и нет — занимаются им единицы инженеров, это местный курьёз, который подаётся как мейнстрим примерно так же, как когда-то подавался пролог). Это OCL к UML, для которого есть профиль SysML. Он насквозь объект-ориентирован, но задним числом через UML и MOF к нему был приделан логический формализм, и есть текстовый язык OCL, который может выразить всё, что выражается тамошними диаграммками, плюс ещё много чего логического. Мне не нравится SysML, ибо системности и онтологичности в нём ноль. И GPL там совсем не предусмотрен. Но есть несколько моделеров (дико дорогих, но и опенсорс что-то есть). Есть и похожие решения с другими архитектурными языками, не опирающиеся на какие-то стандарты. Но они также не слишком системны. Так что ссылок не даю. Это если вы считаете, что я про них не знаю. У меня десять лет назад вышла статья в INCOSE INSIGHT — я там ругаюсь на SysML, https://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/