Category: it

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 (что-то сама статья там пока никак не появится, стоит как coming soon, и можно почитать краткий пересказ её идей -- 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

Лекция "Машинный интеллект 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/
2019

Роли начальников, роли помощников, роли любителей, роли карьеристов

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

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

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

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

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

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

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

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

SysMoLan как eDSL для Julia

В дискуссии о типах языков программирования/моделирования/представления знаний (там, кстати, уже 320 дискутантов -- https://t.me/typeslife) сегодня был очередной поворот: попытка вместо говорения об онтологии и представлении знаний (что сразу вызывает математических и философских духов) говорить о предметно-специфичности, продолжая программистскую традицию и попадая в программистский язык. Так что ответы на наши вопросы про языки моделирования разных предметных областей будем искать по ключевым словам "domain-specific".

Когда-то и Fortran называли domain-specific, ибо он только для formula translations, а не универсальный, как машинный язык. И то же самое было со всеми языками высокого уровня, они были domain-specific. Тем не менее, domain-specific пока чётче ведёт к цели, чеми использование всяких других слов. Нам нужно делать еmbedded domain-specific languages (eDSL) с domain-specific types (как онтикой предметной области) и domain-specific solvers (для того, чтобы интерпретировать модели в онтике/типах предметной области, задавать вопросы/делать запросы/вычислять).

В группе "Аттик" мехмата МГУ рассказывали, что нашли причину, почему Паскаль никак не мог победить Фортран в своё время. Они считали, что Паскаль был безблагодатен по сравнению с пакетными языками (Modula, Ada), ибо не было "пакетов" как раз для реализации общей для нескольких программистов системы типов — нельзя было делать "пакеты" как eDSL для domain-specific работы (те самые domain-specific types и domain-specific solvers, в терминах группы Аттик domains -- это были миры и solvers -- исполнители для этих миров). В Фортране же это реализовалось на раз-два через common-блоки! Потом какие-то аналоги common blocks начали делать в паскаль-компиляторах (но это уже потом! в учебниках паскаля это не было свойством языка, а только свойством реализации в конкретном компиляторе). Потом появились на краткий исторический миг пакетные языки, а потом domain specificity начали понятными словами объяснять как делать в ООП и в реляционных моделях данных — тут все эти "пакетные языки" и деревянные с сетевыми базы данных начала восьмидесятых и смыло в унитаз истории, где они и находятся до сих пор.

Вся дискуссия в чате крутилась вокруг того, что удобных для программирования eDSL языков программирования/моделирования/запросов к базам данных/представления знаний нет. Так что я продолжаю придерживаться мнения, которое выработалось у меня на прошлом такте дискусии (https://ailev.livejournal.com/1487293.html): работать тогда будем с Julia как хост-языком. И на Julia будем реализовывать структуры данных и солверы SysMoLan как eDSL.

Вчера на докладе на митапе по Julia (https://juliameetup.timepad.ru/event/1047482/, слайды https://yadi.sk/i/yBeUJJj1iuiJXQ, видео https://vimeo.com/360541672#t=4940s) я высказал ещё пару идей. Солверы для eDSL отличаются тем, что эффективно обрабатывают частные случаи -- предоставляют оптимизированные для этих частных случаев решения. И в Julia как раз отрабатывается такой подход на примерах методов оптимизации (JuMP) и методов решения систем дифференциальных уравнений (DifferentialEquations). Солверы этих систем -- это просто коллекция самых разных солверов, эффективных для самых разных ситуаций. Итого eDSL выглядит как набор типов, в терминах которых удобно описывать предметную область, плюс набор эффективных солверов -- типы должны универсально отражать задачи предметной области, а солвер должен устойчиво работать и жужжать в части скорости. Поэтому типы должны быть более-менее богаты в части их конструирования для отражения объектов и отношений в domain (сравнимы в этом плане с богатыми типами статических языков программирования), но динамическими, чтобы по ходу дела в runtime подбирать оптимизацию для solver. Ну, и проблема двух языков: на одном и том же языке и компактно и красиво (с рафинадом) высокоуровнево выражать domain, но не теряя низкоуровневости в скорости. И настолько не теряя низкоуровневости, чтобы эта оптимизация докатывалась аж до уровня железа -- до GPU. Вот Julia как раз имеет примеры таких решений. Вот этим путём и хочется пойти для SysMoLan: иметь возможность самых разных солверов для предлагаемых SysMoLan как eDSL структур данных.

Идти туда, как мне кажется, нужно в несколько шагов:

1. Сделать простой (архитектурный и требований) текстовый моделер для простых архитектур и использовать его, например, для обучения инженерии требований и инженерии системной архитектуры. У меня проходит в год сотня студентов и курсантов по разным линиям, вот это будет учебный софт. SysMoLan в объёме реализации IEC81346-1 для моделирования системного разбиения (чтобы можно было показать функциональное и конструктивное системное разбиение в их взаимосвязи на пару уровней) тут вполне подойдёт. Это MVP. Ничего вычислять даже не будем (может быть, будем проверять целостность, но и тут не факт), только отображать удобно. Солвер -- голова инженера. Для чего такое нужно? Для помощи со стороны компьютера в присмотре за вниманием в ходе архитектурной работы и работы над требованиями, речь идёт о киборгизация архитектора (вот тут про киборгизацию присмотра за вниманием: https://ailev.livejournal.com/1488271.html). Как над шахматными партиями удобней думать, если есть просто шахматная доска, на которую можно смотреть, так и архитектурный моделер помогает думать уже тем, что он помогает стабилизировать внимание архитектора.

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

В чате была дискуссия о том, что лучшим приближением к языкам представления знаний является common logic, и какой-нибудь FOL солвер. При этом SQL предлагался как успешный вариант языка для FOL -- без пояснения того, как это всё предполагается в работе у инженера. Ибо логические языки почему-то нигде не взлетели в их чистом логическом виде.

Тут ещё и социальные аспекты, конечно. Пара релевантных ссылок в Communications of ACM (http://cacm.acm.org/blogs/blog-cacm/173328-programming-languages-are-the-most-powerful-and-least-usable-and-learnable-user-interfaces/fulltext) -- там обсуждается вопрос, почему люди не хотят учить языки программирования (языки моделирования, языки мета-моделирования). Там вводят понятия cognitive load (http://en.wikipedia.org/wiki/Cognitive_load, связанные с использованием рабочей памяти умственные усилия), для разных людей они будут разные при изучении предмета. И далее говорится, что люди оценивают не реальную когнитивную нагрузку, а субъективно воспринимаемую (percieved) будущую нагрузку -- когда вы даже воспринимать её по факту не можете, ибо ещё не знакомы с предметом. Да, и полезность вы тоже представить не можете, ибо не знакомы с предметом. А решение "учить-не учить" принимается до изучения предмета. То есть бесполезно уговаривать что-то учить, потому как оно "полезно". Решение принимается не только и не столько по "пользе", сколько по "цене изучения" -- например, считает ли потенциальный ученик, что у него есть способности к предмету. Это всё expectancy value motivational theory -- https://www.researchgate.net/publication/265965932_Expectancy-Value-Cost_Model_of_Motivation. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it. Решение автор текста предлагает в повышении usability для изучаемых предметов (языков программирования/моделирования), но и learnability -- это разные свойства. Requirements нужно формулировать для обеих характеристик. Легко такую банальность предложить, трудно выполнить.

Вопрос мой в том, что современные информационные системы решают многие из тех задач, которые раньше считалось, что смогут решать только экспертные системы. И эти системы написаны на обычных языках программирования, а не на логических языках. Нет ли какого-то способа представления знаний, отличного от тупого использования логического языка? Логическая парадигма только одна из многих, и в языках программирования она явно не главная. Иначе мы бы видели вокруг сплошных потомков Пролога. Но нет, потомки Пролога везде маргинализуются, и никакая опенсорсовость им не помогает. CycL тоже делал OpenCyc, потом закрыл этот проект: не взлетело. Логическое не взлетает, на SQL делают только запросы в базу данных, а не программируют -- вот я и интересуюсь, что ещё на свете существует для представления знаний. Какая-нибудь Java для представлений знаний неудобна, но модели самых разных domain обрабатываются в мире главным образом на ней, а не на CycL или Agda. Получается, вся краса мира у нас уходит в язык программирования, который нужен для того, чтобы вызвать SQL над базой данных, в которых и отображён domain. При этом как domain отражается в реляционных базах данных — понятно, этому учат в университетах, и по большому счёту DDD (domain-driven design) тоже редко когда про язык программирования, чаще про базы данных.Ответа в чате я так и не получил, хотя обсуждение и было бурным. Так что за подробностями отправим в чат, а тут продолжим.

3. Иметь дифференцируемый язык представления знаний как eDSL, чтобы использовать этот язык не только для ручного ввода архитектурных моделей и моделей требований в рамках облегчения работы subject expert по knowledge aquisition, но и в рамках порождения/generation, а ещё в рамках оптимизации (про "дифференцируемое всё" я писал в https://ailev.livejournal.com/1464563.html). У Julia тут неплохая репутация: Viral Shah [один из разработчиков компилятора Julia] addressed the World Artificial Intelligence Conference, held in Shanghai Aug 29-31 with a discussion on "Julia: Generalizing Deep Learning with Differentiable Programming" (почему я и хотел бы держаться к Julia поближе, а не к C#, С++, R или каким-то другим языкам, не приспособленным для численных методов). Порождаемые архитектуры, оптимизируемые архитектуры, фронтир — вот это всё тут, все эксперименты с искусственным интеллектом и компьютерным творчеством.

4. А ещё нужно будет реализовать mapper (генератор конверторов/адаптеров/плагинов/мостов и т.д. -- систему типа .15926 https://github.com/TechInvestLab/dot15926/, только не обязательно на ISO15926, зато с удобным порождением парсеров и генераторов данных, eDSL для этого), ибо любой архитектурный редактор быстро будет нуждаться в частных моделях из разных САПР, и дело быстро дойдёт до полноценной PLM. Когда будет реализовываться мэппер, там результат будет вполне дискретный и формальный и FOL внутри, а вот методы получения моделей данных могут быть с использованием нейросетей, вероятностных языков и разных других численных алгоритмов. В итоге получится гибрид, а не только нейросети или только строгая логика. Вот, кстати, пример такого "загрузчика данных" (мэппера) для табличек: о "импорту табличек в программу", Flatfile can automatically match 95% of imported columns, using a combination of machine learning and fuzzy matching. Users can upload data via CSV, XLS, or simply paste from the clipboard — https://venturebeat.com/2019/09/10/flatfile-pursues-intelligent-data-importing-with-2-million-round/. JuliaDB при этом тоже работает с файлами табличек, в колонках которых могут быть любые типы Julia, а не только числа или строки, но всё-таки мэппер должен работать не только с табличными форматами. Первое, о чём спросят инженеры, так это о мэппинге 3D-моделей современных САПР.

Задача представления системных знаний на SysMoLan сложная, поэтому решаем её эволюционным путём, а не "сразу всё во взаимоувязке". Системный подход не должен становиться болезнью, когда вгоняет проект в analysis paralysis и заставляет "учесть всё-всё" в один подход и один проход.

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

Объединяем программирование, моделирование, представление знаний

24 августа в 13:11 был создан чат "Типы в языках программирования, моделирования, представления знаний" -- https://t.me/typeslife, и за прошедших четыре дня в него набежало уже 176 любителей поговорить о типах. Ох, и много было наговорено! Текста я туда написал тоже оченьмногабукофф, даже не буду сюда эти тексты копировать. Но сформулирую некоторые выводы.

1. В основе всего должен лежать какой-то "обычный GPL". Под этим "обычным GPL" имеется ввиду современный язык, на котором можно делать eDSL. Например, C# и Julia. Языки, на которых легко программировать, хорошая инфраструктура, приемлемая надёжность кода, надёжность обеспечивается понятностью. Языки, у которых дизайн-цель безопасность (доказательства правильности программ) -- они не подходят, а если для "обычного GPL" потребуется при передаче в production обеспечить безопасность, то ничего не нужно переписывать: просто будут воткнуты дополнительные аннотации и типизация таки будет проверена (средствами языка, или внешним чекером, это неважно), а то и в рантайме поставим дополнительные тесты.

2. Языки представления знаний -- это какая-то формальная машинка для работы с микротеориями. Обычно там какой-то логический движок, FOL плюс какие-то HOL расширения. SQL, SPARQL (забыть: триплы это тупик. Начинать нужно сразу с n-арных предикатов), Datalog и прочая -- вот это оно всё. Но смотреть нужно на CycL как на успешный движок. Другое дело, что языки представления знаний крайне не приспособлены для моделирования. Поэтому хорошо бы реализовать язык представления знаний как eDSL над GPL. И помнить, что язык для знаний -- это полноценный движок/солвер FOL прежде всего. Онтологика это онтология+логика.

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

Этот язык justy_tylor реализует как компилятор на C# (ему важна совместимость с корпоративной инфраструктурой и сахарность синтаксиса), а для меня важны были бы стыки с deep learning, probabilistic programming и NLU + всякое инженерное моделирование. Это сегодня главным образом Python и проблема двух языков, но конкурентом там потихоньку становится Julia. Поэтому можно думать о том, чтобы сделать eDSL как набор различных разогнанных на GPU FOL/HOL солверов по примеру DifferentialEquations, JuMP и Modia.

3. В языках важна их сахарность (этот тезис подробно развивал justy_tylor). По формальным моделям есть множество "эквивалентностей", но вот людям или удобней, или неудобней какие-то конкретные синтаксисы, а уж что там потом делает компилятор, преобразуя из удобного для хорошей нотации формализма в удобный формализм для быстрых вычислений -- это дело компилятора. Если нужно преобразовавать в триплы, то пусть солвер FOL это преобразует и оптимизирует где-то там внутри себя, а на поверхности должны быть паттерны, n-арные предикаты (я помню весь ужас перехода от триплов к представлению паттернами -- заборы и коровники на много частей стандарта). Язык с плохим синтаксисом и хорошей семантикой проигрывает языку с хорошим синтаксисом и плохой семантикой. Поэтому возможность "нотационных расширений" важна. Среди таких расширений можно назвать Prolog DCG как пример компактности "из ниоткуда" для парсинга (DCG -- https://www.metalevel.at/prolog/dcg или DCTG — http://cmsmcq.com/2004/lgintro.html, и можно поглядеть ещё работы по проекту FONC O-Meta с теми же целями "минимальный язык для парсинга", но там не FOL а хитро понимаемая объект-ориентированность -- http://tinlizzie.org/ometa/), какой-то синтаксис для possible worlds (и тоже в VPRI были работы на эту тему -- http://www.vpri.org/pdf/m2013002_experiments.pdf). Так что языко-ориентированность в том числе и нотационная -- она важна.

4. Ну, и eDSL для моделирования/simulations, всяческих микротеорий -- синтаксис, типы, солвер для модели. Это понятно, это не обсуждается. Пример тут Modia для инженерного моделирования. С этим всё понятно, тут нет особых вопросов.

Итого: нужно смотреть на то, что происходит с языками представления знаний: всякими knowledge graphs до того момента, когда их вливают в нейросетки -- какие там языки представления графа, что там с выводом, как ускоряют вывод. Отдельно алгоритмы, отдельно разгон на GPU -- хотя это связанные вопросы обычно). Последние интервью Дугласа Лената говорят о том, что там продолжается линия на "мы разгоним FOL с HOL над knowledge graphs с микротеориями и прочими хитростями до приемлемых времён, и таки победим всех, ибо common sense и причины таки у нас".

Но иметь какой-то eDSL проект по представлению знаний (солверы FOL-HOL, посаженные на GPU) в Julia, напоминающий JuMP и DifferentialEquations -- это было бы интересно.

Самый большой риск: логические языки все эзотеричны, они ещё более эзотеричны, чем функциональные языки (про Curry-Howard помним, да), и языки представления знаний в классической чисто логической традиции выражения FOL поэтому рискуют быть такими же эзотеричными, как Пролог или CycL сотоварищи. Другое дело, что SQL это и FOL и тьюринг-полный язык, так что необязательно речь идёт о чём-то страшном-страшном. Так что там могут быть "форматы представления FOL" и собственно FOL-солверы. Но это детали.

Всё одно дело мутное. Эти самые вопросы с foundation ontolgy и upper ontology и выражением микротеорий (что нарушает всю "консистентность вывода" в рамках программы -- и нужны средства работы с микротеориями, которых нет в существующих системах типов языков программирования, плюс коммуникационные вопросы по обмену/федерированию знаний в этих микротеориях), похоже, нужно искать таки в языках знаний, а не языках программирования или языках программирования баз данных. И прикручивать болтами к экосистеме deep learning, NLU и прочим пришельцам из вычислительной математики. Так что пока меня не убедили, что в Julia это всё делать бессмысленно. Наоборот.

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