Без заголовка

Я потихоньку разбираюсь с темой, но "те же самые ошибки" вполне относятся не только к моим слайдам, но и к вашему этих слайдов прочтению. Конечно, модульный синтез является самой сложной частью архитектурной работы, это ключевая инженерная практика. Она не проста, формальных алгоритмов тут нет, разные наборы эвристик помогают только в самых простых случаях -- и планка сложности непрерывно растёт. Что касается интеграции данных (как вы пишете, "замены модуля 1С на модуль из SAPa" -- это ведь та же проблема), то там тоже проблем хватает, мы неоднократно были supervisers крупных проектов из этой серии и даже сами делали для этого онтологический софт. Попытался обогатить свой лексикон понятием net surgery -- нашёл только http://nbviewer.jupyter.org/github/BVLC/caffe/blob/master/examples/net_surgery.ipynb (и все остальные упоминания ведут сюда). Конечно, поэтому-то и стремятся к end-to-end learning и дифференцируемым насквозь архитектурам, чтобы не мучиться со всеми передачами репрезентаций между явно определяемыми модулями. Что end-to-end learning и autoML обходит эти проблемы, я, вроде написал (хотя на end-to-end learning специального акцента не делал, может и нужно было бы специально это сказать -- что уровень cognitive architecture может быть вполне выучиваемым, это нужно проговаривать явно и отразить на слайдах). Действительно, distilling knowledge можно за уши притянуть к общему термину transfer learning -- там терминология ещё свеженькая, много чего будет происходить (учитывая ещё и всплеск использования вероятностных подходов, где своя терминология. См, например, обсуждение терминологии по передаче результатов обучения откуда-то куда-то буквально год назад: http://ailev.livejournal.com/1211950.html). Крупноблочная сборка и мелкоблочная сборки -- не совсем так, хотя мысль Алана Кея была именно таковой: для биологических систем он считал, что внутренняя сложность "немодульной" сборки велика, и призывал делать сверхсложные не слишком модульные внутри (т.е. с огромным числом сложных взаимодействий, мимо каких-либо API) блоки побольше. Я думаю, что он указывает интересное направление. Насчёт того, как традиционный опыт и практики обеспечения модульности для программной и системной инженерии распространяется на коннективистские системы и системы, в состав которых включены коннективистские компоненты и/или модули -- это мы попозже поразбираемся. Вашу позицию (по большому счёту, она сводится к "всё то же самое" ) я понял, мою позицию я потихоньку формулирую, набираю материал. Что акценты смещаются на данные и процедуры обучения, я указал. Когда появятся устойчивые практики и поддерживающие их инструменты, можно будет вернуться к этому вопросу. Я буду потихоньку отслеживать, что в этой области происходит. Пока же ваши тексты для меня больше художественны, "вести с полей", они как-то не похожи на результаты какого-то осмысления и структурирования в обсуждаемой предментной области модуляризации. Я привёл какие-то диаграммы про само понятие модуля в начале презентации, но без пояснений вряд ли понятно, о чём эти картинки. Может, нужно добавить текста и про это. Жаль, не удалось записать видео, без объяснений слайды эти непонятны. Ничего, в этой области модуляризации мы никуда ещё не опоздали, всё происходит довольно медленно. Так что через некоторое время я доклад повторю.