Обсуждение

Пожалуйста, не учите людей плохому. Те же самые ошибки, о которых я вам говорил и месяц и два месяца назад, всё ещё в слайдах. Только ещё добавились новые, типа того, что ансамбль нейросетей предшествует обучению, и про сравнение нейросетей с аспектным программированием. Ну откуда вы это берёте? Скажем, АОП вполне хорош, когда аспекты ортогональны друг другу, просто паттерны комбинирования неортогональных аспектов -- это функциональная парадигма, и она с ООП плохо сочетается -- т.е. проблема на практике исключительно в несовместимых правилах компоновки кода и разбиения на объекты. Но у вас почему-то АОП "плох" из-за "сложности отладки"! Нету никакой связи сложности отладки и методов компоновки кода, отладка сложна, когда data flow сложный и нет методов интроспекции данных. Вам кажется, что нейросети сложно отлаживать? Но и файловые системы, и базы данных без файлового менеджера, удобного API или IDE тяжело отлаживать. Дальше, у вас почему-то distilling knowledge отличается от transfer learning. Наверное, потому что вы выделяете ансамбль нейросетей в отдельную сущность, отличающуюся от одной нейросети? Но ведь это чушь: и то, и другое классический "чёрный ящик", он же модуль. Пока он "работает", вам не нужно заглядывать вовнутрь, делить его на подмодули или перекомпоновывать. Не понимаю также ваше категоричное высказывание о слабости спецификаций нейросети -- заблуждения плохого менеджера Le Bottou я уже вроде бы разбирал. Вот вам императивный модуль, постройте на него "сильную спецификацию", расскажите человеческим языком, что он делает, и что он не делает: a = set([...]) # array with 10k elements def is_good(x): q = 0 for c in x: if c in a: q+= 1 if q >= 2: return False return True Увы, любая сложная технология неотличима от магии, в том плане, что "работает, но непонятно почему". Модули "специфицируемы" только пока вы с помощью них решаете тривиальную задачу, легко выражаемую человеческим языком -- то есть хорошее специфицирование модулей -- это не техническая проблема, а проблема устройства человеческого языка. Я думаю, всё проистекает из двух корней: 1) вы не потрудились формально объяснить, что такое "плохая" модульность. Во всяком случае, в слайдах этого нет. 2) вы зациклились на идее end-to-end learning, и везде предполагаете, что нейросеть неделимая и должна быть одна на систему. Но тогда почему вы не сравниваете это с одномодульным классическим программным обеспечением, типа, "на sed плохо писать большие программы". Вот просто возьмите и замените везде в ваших слайдах слово "нейросеть" и "нейросетевая модель" на слово "модуль", а "обучение" на "программирование" -- и ничего же не поменяется. Наверное, нужно обогатить ваш лексикон понятием "net surgery", а дальше уж поди дозреете, что особенность нейросетей лишь в том, что обучать их можно при наличии данных, а данные не всегда имеются на каждую часть нейросети, и end-to-end-learning как раз обходит эту проблему, а в классическом модульном подходе ту же самую проблему приходится решать анализом + синтезом + построением модульной архитектуры, и почему-то вы этот "анализ задач модуля" и "синтез модулей" воспринимаете как лёгкую процедуру, и оставляете только "построение архитектуры". У вашей "модернизации заменой модулей" та же самая отнологическая проблема -- должны быть модули в наличии, и спецификация модулей должна совпадать, а иначе получим "конфликт онтологий". Ага, было бы это легко, мы бы уже к звёздам летали. А вы попробуйте на практике заменить модуль из 1С на модуль из SAP-а, и обнаружите, что ваша теория концентрируется на мелочах и упускает главное. В общем, я считаю, что вы на самом деле противопоставляете друг другу крупноблочную сборку и мелкоблочную. Нейросетевые решения тяготеют к крупноблочной сборке, представляемые вами классические системы -- к мелкоблочной. Но это следствия разных решаемых задач. Вы можете сколько угодно крупные модули делить на мелкие, если это будет улучшать качество решения задач -- хоть в нейросетях, хоть в классических программах. Но ввиду специфики задач, для которых применяются нейросети -- деление на более мелкие модули не помогает. Потому что если бы помогало, то давно бы уже написали классическую мелкоблочную программу для решения этих задач.

Я потихоньку разбираюсь с темой, но "те же самые ошибки" вполне относятся не только к моим слайдам, но и к вашему этих слайдов прочтению. Конечно, модульный синтез является самой сложной частью архитектурной работы, это ключевая инженерная практика. Она не проста, формальных алгоритмов тут нет, разные наборы эвристик помогают только в самых простых случаях -- и планка сложности непрерывно растёт. Что касается интеграции данных (как вы пишете, "замены модуля 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) блоки побольше. Я думаю, что он указывает интересное направление. Насчёт того, как традиционный опыт и практики обеспечения модульности для программной и системной инженерии распространяется на коннективистские системы и системы, в состав которых включены коннективистские компоненты и/или модули -- это мы попозже поразбираемся. Вашу позицию (по большому счёту, она сводится к "всё то же самое" ) я понял, мою позицию я потихоньку формулирую, набираю материал. Что акценты смещаются на данные и процедуры обучения, я указал. Когда появятся устойчивые практики и поддерживающие их инструменты, можно будет вернуться к этому вопросу. Я буду потихоньку отслеживать, что в этой области происходит. Пока же ваши тексты для меня больше художественны, "вести с полей", они как-то не похожи на результаты какого-то осмысления и структурирования в обсуждаемой предментной области модуляризации. Я привёл какие-то диаграммы про само понятие модуля в начале презентации, но без пояснений вряд ли понятно, о чём эти картинки. Может, нужно добавить текста и про это. Жаль, не удалось записать видео, без объяснений слайды эти непонятны. Ничего, в этой области модуляризации мы никуда ещё не опоздали, всё происходит довольно медленно. Так что через некоторое время я доклад повторю.

>Я потихоньку разбираюсь с темой, но "те же самые ошибки" вполне относятся не только к моим слайдам, но и к вашему этих слайдов прочтению. Увы, звука лекции у меня нет, так что только слайды... >Попытался обогатить свой лексикон понятием net surgery -- нашёл только >http://nbviewer.jupyter.org/github/BVLC/caffe/blob/master/examples/net_surgery.ipynb (и все остальные упоминания ведут сюда). Да, кто-то пишет "network surgery", кто-то даже использует для обозначения того же самого "transfer learning" -- почему-то любят учёные изобретать свою терминологию для того же самого действия, наверное, чтобы выделяться. Так вот, http://cs231n.github.io/transfer-learning/ -- "Take a ConvNet pretrained on ImageNet, remove the last fully-connected layer (this layer's outputs are the 1000 class scores for a different task like ImageNet), then treat the rest of the ConvNet as a fixed feature extractor for the new dataset" -- вообще говоря, это уже "net surgery". Т.е. суть в том, чтобы оставить от обученной сети кусок, и его потом переиспользовать. А второй вариант -- fine-tuning: "Fine-tuning the ConvNet. The second strategy is to not only replace and retrain the classifier on top of the ConvNet on the new dataset, but to also fine-tune the weights of the pretrained network by continuing the backpropagation. It is possible to fine-tune all the layers of the ConvNet, or it's possible to keep some of the earlier layers fixed (due to overfitting concerns) and only fine-tune some higher-level portion of the network. " -- т.е., идея в донастройке имеющейся сети под другие данные. Кроме этого, transfer learning -- это ещё и перенос данных обученной сети в другую сеть. Ещё это называется "knowledge transfer in neural networks". Но всё это относится к работе с единичными модулями. Никуда не девается проблема с тем, что нейросетевые модули "крупные" -- но это вполне объяснимо тем, что задачи пока что решаются такие, что "один нейросетевой модуль в системе -- уже много". Вот когда нейросетей будут использоваться десятки, вот тогда можно будет поговорить про модульность. Поэтому я и говорю, что сейчас противопоставлять системы с тысячами модулей и системы с нейросетью и обвязкой вокруг неё -- это противопоставлять разные системы именно по количеству модулей, но делать из этого выводы про "слабые контракты". //разбил коммент на два//

Увы, я вижу, что основная проблема сейчас в недостатке инструментов для более мелкой модульной работы с нейросетями, и недостаток знаний и, главное, компьютерной мощности для подобных работ. Вот сколько людей хотя бы просто объединяют две нейросети в одну, или объединяют традиционные хранилища данных и нейросети? 1% от всех, кто занимается нейросетями? В работе по AlphaGo объединили три нейросети. Не три сотни, не три десятка -- всего три нейросети. Поэтому о какой вообще модульности можно говорить в этой области? И понятно, почему так: обычный модуль пишется за 3 человеко-дня, а нейросеть -- за 3 человеко-месяца. Всё изменится только тогда, когда будет более быстрое железо и будут готовы технологии автоматической подготовки данных, а также будет зоопарк готовых нейросетей (или API). Так вот, я считаю, что проблемы в системе из 10 модулей не такие, как проблемы в системе из 1000 модулей, и не такие, как в системе из 10000 модулей. И меня коробит именно то, что вы пытаетесь сравнивать разные по количеству модулей системы, пытаясь подвести под них общий базис. А особенности коннективистских компонентов -- может быть, я этот термин неправильно понимал. Имеется в виду, что его ответы на одни и те же вопросы изменяются с течением времени? Но это не так: в тот момент, когда данный компонент применяется в системе, он уже обычный модуль. Он не изменяется. Или имеется в виду, что он состоит из более мелких компонент, объединённых между собой? Так любой крупный модуль состоит из таких компонент. В чём тогда смысл термина? Просто подчеркнуть, что внутри нейросеть? Так я вам привёл выше пример -- это коннективистский компонент или нет? Понимаете, я много времени занимаюсь эвристическим подходом. Там всё то же самое, что и с нейросетями, только вместо процедуры обучения нейросети выступает программист, но он основывается на тех же данных, что и нейросеть. И также нет никакой спецификации -- часть примеров будет фейлиться, и заранее не сказать, какие именно. Попробуйте уложить это в свою матрицу "классический-коннекционистский". Вот, скажем, поддерживаемый мной модуль из 500 строк -- https://github.com/buriy/python-readability -- как вы этот подход классифицируете? ( вот описание алгоритма: http://stackoverflow.com/a/4240037/217895 )

Если это всё вы сводите к transfer learning, то на слайде 22 это у меня явно присутствует.

Я именно про то, что недостаток знаний и соответственно недостаток инструментов. Конечно, малая вычислительная мощность тут усугубляет проблему, но это относится к общим проблемам. Проблемы модульности коннекционистских систем я понимаю очень близко к тому, как это понимает Le Bottou в http://leon.bottou.org/slides/2challenges/2challenges.pdf Я всё понимаю про вечные дискуссии в программной инженерии про модульность и гранулярность, а также участвовал и в дискуссиях про модульности в строительстве атомных станций. Но меня больше сейчас волнуют коннективистские системы, обучающиеся. Хотя я понимаю, что разбираться с самим понятием модульности и решаемыми им проблемами нужно для всех типов систем, иначе можно легко выхолостить изначальное значение понятия и скатиться на обсуждение совсем других проблем. Не исключаю, что для коннекционистских систем так и может оказаться. Так, модульность голограмм весьма проблематична, а составление системы из разных голограмм -- это уже переход к другим проблемам, "обычной модульности".И тут нужно понимать, что обсуждается в каждый момент времени. Я предпочитаю говорить о когнитивных архитектурах, когда речь идёт о системе со многими нетривиально связанными коннекционистскими компонентами. Модульность когнитивных архитектур я пока не обсуждал, но Le Bottou чётко указывает особенность: во время работы системы модульный контракт плывёт, и поэтому ремонт или модернизация такой системы путём простой замены модуля вполне может не сработать.

Это-то да, но почему у вас "knowledge distillation" указан отдельно, как пункт? В той работе рассматривается как раз вариант 3 из transfer learning -- "student-teacher networks for knowledge transfer".

>Le Bottou чётко указывает особенность: во время работы системы модульный контракт плывёт, и поэтому ремонт или модернизация такой системы путём простой замены модуля вполне может не сработать. Не понимаю. Что такое "модульный контракт"? Обычная система тоже "обучается", только с помощью программиста. И во время багфиксинга в классических системах контракт модуля тоже "плывёт" после вносимых изменений. До багфикса был один контракт, после багфикса -- другой. Да даже в справочник в базе данных мы добавили новое значение и поставили флажок типа обработки (паттерн "стратегия", но данные для работы находятся в базе данных) -- контракт тоже поплыл, модуль до этого обрабатывал 3 ситуации, а теперь 4. Контракты не плывут только в системах, которые не меняются. Любое изменение (кроме рефакторинга), что в нейросети, что в обычной императивной программе -- это изменение контракта. Более того, если нейросеть меняется в процессе работы -- это чаще всего или классическое версионирование (заменили одну версию нейросети другой), или online-learning, т.е. крайне небольшой класс алгоритмов, на практике меняются в процессе работы лишь данные для рекомендательных систем или (с натяжкой) поисковые индексы -- и та, и другая модель не нейросетевые. Туда же можно отнести и изменения в базе данных по мере работы -- добавили новый город в справочник -- всё, контракт модуля, работающего с этой таблицей, поменялся! Пытаясь построить матрицу соответствий нейросетевых работ и классических, все "изменения нейросети" я бы относил не к работе, а к "подготовке модуля к эксплуатации: конструирование, наладка, настройка, подстройка". Потому что пока что нейросети классифицируют данные, предоставляют данные для принятия решений, но сами не принимают никаких решений (и тем более, решений "о самообновлении на production-сервере"), и никто не хочет, чтобы программа заглючила после обработки части данных, когда "непонятно, почему сломалось, вроде бы ничего не делали, но нужно опять вызывать специалиста, а пока придётся пару дней пользоваться резервной системой". Да это же кошмар для эксплуатации, когда такое происходит!

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

Это-то и проблема, что вы рассказываете. В классической инженерии модуль имеет жёсткую спецификацию, его заказывают у стороннего производителя, и метод работы называется проектирование. Если речь идёт о конструировании и взаимной подгонке, то это считается моветоном. Так, раньше болты и гайки были индивидуальными, каждая деталька индивидуальная. Конструирование и кастомное изготовление было запредельно дорого. Потом появились хорошо специфицированные модули, стандартные их интерфейсы. Программные библиотеки и пакеты тоже появились не сразу. А менеджеры пакетов и тем более встроенные в язык возможности менеджмента пакетов вообще только недавно. То, что вы описываете как модули -- это не модули, это как раз работа напильником по доводке конструкций с плохой модульностью. В нейросетевых моделях с модульностью пока тоже всё плохо организовано, про model zoo только-только говорить начинают, но даже в Caffe этим model zoo трудно пользоваться, и не только потому, что набор готовых доступных публично моделей супермал. Преодоление этой ситуации как раз и обсуждается в докладе.

И я вас очень прошу определить термины "коннекционистский компонент" и "коннекционистская система", которые вы использовали. В любой системе есть изменяющиеся компоненты и неизменяющиеся, а также связи между ними. Какие из них будут "коннекционистскими"? Термин не общепризнанный, и употребляется как ассоциативный, по сути, обозначает "основанный на связях" -- но что же это значит? Пока не определить используемые термины, каждый будет воспринимать всё по-своему, поэтому прошу вас не допускать введённых без определения терминов. Почти всегда, без определения у терминов-понятий не создаётся объёма, и даже если человек вам кивает, у него в голове лишь пустота. То же самое -- "когнитивный" -- что это значит? Был такой buzzword 5 лет назад -- BICA ("Biologically Inspired Cognitive Architectures"), даже сообщество такое до сих пор есть. Но что этот термин значит? До сих пор никто не знает. Аналогично, BI ("Business Intelligence") от IBM. Даже книжки по нему пишут. Но что это? Увы, это всего лишь типичный маркетинг уровня "Наша система оснащена фильтром Ultra Turbo(TM), системой очистки CleanDry (TM) второго поколения, и интеллектуальным модулем реагирования CognitivePro(TM)". Не заставляйте играть в bullshit bingo, вводите определения терминов сразу же при их первом использовании, и не думайте, что без определения их поймут так же, как вы.

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

>если всё из этой серии соберётся под зонтиком термина transfer learning Всё же под transfer learning обычно подразумевают перенос данных, уже накопленных нейросетями. Если переносят накопленные не нейросетями данные -- то это просто "machine learning/deep learning", в зависимости от строения системы, которая данные принимает. >с модулей (онтологии, "что есть") акцент переходит на обучение (эпистемологию, "как узнал") Давайте дальше с терминами разбираться. Я выше привёл питоновский модуль из 5 строк, 10000 ячеек данных и простого алгоритма. Это "что есть" или "как узнал"? Если онтологию порождает нейросеть, то это эпистемология? Если закодировать обученную нейросеть в виде данных, то это отнология? Как вы отличаете на практике эти две вещи? В чём их объём? > Когда-то "нейронными сетями" считался очень ограниченный класс архитектур (и даже автоэнкодеры-декодеры туда не попадали), autoencoder-decoder -- это не нейронные сети, потому что это архитектурный паттерн, и он может строиться на чём угодно -- хоть на нейросетях, хоть не на нейросетях. Например, на SVM или decision tree в роли декодера и/или енкодера. Он будет нейросетью, если построен на нейросетях (см. ниже). "Нейросеть" -- это что-то, что содержит в основном нейроны и обычно обучается методом обратного распространения ошибки, а нейрон -- это что-то, что суммирует данные на входах и обычно обрабатывает сумму какой-либо нелинейностью. >Так и transfer learning всё под себя утянет, что шевелится в плате обеспечения модульности. Зонтичный термин -- learning. Классифицируется так: что обучается и каким именно образом. Для learning нужен dataset, который может быть динамическим, аугментированным или набором сэмплов. Обычно представляется в виде таблицы из samples, где поля таблицы -- поля сэмплов. Обучается model, она учится аппроксимировать какие-то поля из dataset на основе других полей. Она классифицируется по внутреннему строению (linear regression, naive bayes model, GMM, SVM, глубокая нейросеть, decision tree, model ensemble,recurrent network, итп.). Модель может использоваться как самостоятельный модуль, может использоваться как замена для dataset при transfer learning, а может использоваться после обучения какой-то выдернутый кусок из неё для построения других моделей. Модель может обучаться -- learning или training -- (веса меняются), а может использоваться (веса не меняются). Отдельный класс моделей -- online learning models -- меняются непосредственно во время использования. Это название по принципу работы: алгоритмы online learning доучиваются за линейное от количества дополнительных данных время и не требуют повторения прошлых данных при дообучении. Нейросети при дообучении потребуется повторение всех данных, или она "уедет" и перестанет предсказывать первоначальные данные. А вот naive bayes хранит счётчики для уже полученных данных, добавление новых данных -- это лишь прибавление к соответствующим счётчикам.

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

>Конекционисткие архитектуры -- это опирающиеся на сети из каких-то унифицированных простых элементов База данных -- это коннекционистские архитектуры? Там тоже унифицированные простые элементы -- таблицы, типы данных, запросы.

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

В базах данных всё-таки локальные представления. В коннекционистских архитектурах подразумеваются распределённые представления. Но поскольку база данных это одна из вычислительных архитектур (вкупе с полнотьюринговым языком запросов), то и из неё можно сделать коннекционистскую архитектуру. Только работать она будет запредельно медленно (то есть не работать). Формальные определения всё одно не получатся. Недаром Георгий Петрович Щедровицкий любил говаривать, что "определение -- это гробик для умершей мысли". Мало того, что определение обычно только один какой-то viewpoint затрагивает, так ещё и порождает куцее понятие, не в полной мере отражающее новые коценпты. Все эти distributed representations не зря придумали.

>В коннекционистских архитектурах подразумеваются распределённые представления. А откуда у вас берётся это требование? Нейросети отлично линейную регрессию считают, посмотрите современные работы по Facial Keypoint Detection -- там никаких распределённых представлений нет. >Но поскольку база данных это одна из вычислительных архитектур (вкупе с полнотьюринговым языком запросов), то и из неё можно сделать коннекционистскую архитектуру. Только работать она будет запредельно медленно (то есть не работать). Т.е. она вполне может быть частью коннекционистской архитектуры. Насчёт скорости вы сказали наугад, базы данных разные бывают, бывают встроенные процедуры, а бывают просто графовые базы данных. Но вопрос был в другом -- простые элементы, соединённые друг с другом там тоже есть (реляционные взаимоотношения), почему она сама не коннекционистская архитектура? Т.е. как нужно исправить ваше определение, чтобы оно базы данных не включало? >Формальные определения всё одно не получатся. Недаром Георгий Петрович Щедровицкий любил говаривать, что "определение -- это гробик для умершей мысли". Зря вы так. Определения нужны исключительно для того, чтобы передавать мысли другим людям, потому что передать объём понятия без определения другому человеку практически невозможно. Вы обречены быть постоянно неправильно понимаемым другими людьми, если не будете опираться на определения. В преподавании точных наук это известно уже как минимум несколько веков. >Мало того, что определение обычно только один какой-то viewpoint затрагивает, так ещё и порождает куцее понятие, не в полной мере отражающее новые коценпты. Увы, приходится мириться с тем, что приходится использовать не идеальные воображаемые понятия, а те, которые легко выразить определением. Они могут отличаться, да. Но подумайте, какие есть альтернативы при передаче информации о классе объектов, вкладываемом в ваше понятие, другому человеку, без использования определений? >Все эти distributed representations не зря придумали. Понимаете, в виде fuzzy logic нечёткие представления были давным давно, в графовых базах данных есть spreading activation , LSH, шинглы, bloom filter и HMM были, правда, эффективных алгоритмов с их помощью до нейросетей не было, ну, за исключением LSH и шинглов. Те же HMM работали неплохо, но не масштабировались. Ну и в 2004м году SDR были описаны Jeoff Hawkins в On Intelligence -- но рабочих приложений сделать у них не получилось. То есть само представление данных ничего не решает. А вот рабочий алгоритм определения близости объектов без учителя с помощью distributed representations -- вот что действительно немного изменило мир. Тот же EM-алгоритм, применяемый для того же word2vec, опять же уже несколько десятилетий известен -- но поиск рабочих архитектур под задачу всё ещё необходим. И наилучшей архитектурой может оказаться вовсе не распределённая модель. В конце концов, механизм хранения слов в word2vec -- это обычный массив и индексация по ID слова! Поэтому мне слегка непонятен смысл вашего обобщения "коннекционистских архитектур", и я пытаюсь через определение понять, что именно вы им объединяете, надеясь понять, зачем.

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

Чтобы обсуждать какую-то архитектуру, нужно зафиксировать уровень представления. В информатике это крайне сложно: всегда есть какая-то многослойность (уровни микропрограмм-машинных языков--виртуальных машин-высокоуровневых языков-написанных на них DSL, или уровни онтологий в моделировании данных, где даже онтологический язык сам оказывается написанным исходя из каких-то онтологических предпосылок, и на любую upper ontology вдруг находится foundational ontology). Поэтому даже в базах данных кроме моделей данных самих баз данных можно легко находить их foundational модели (таблицы, например), да и для значений в этих таблицах тоже выделять какие-то представления. Нужно понимать, каждый раз какой уровень этой этажерки обсуждается. Коннекционистские (например, нейронные) многоуровневые представления интересны тем, что они позволяют аппроксимировать самые разные функции с незапредельной вычислительной сложностью. См., например, http://arxiv.org/abs/1602.04485. Базы данных не позволяли хоть как-то эффективно работать с широкими входными потоками, такими как аудио и видео, а по большому счёту и речь -- ибо структура входных потоков очень сложна, непонятно было, как их аппроксимировать с достаточной точностью. Коннекционистские представления за счёт однородности представления позволили дотянуться до эффективных вычислений с такими большими и сложными данными. Вычисления самые разные -- поиск аналогий, выделение частей-объектов, нахождение структуры, сжатие информации. А ниже уровнем там, конечо, тензоры (которые представимы списками, как это называют в Питоне или массивами, как это называют в других языках программирования, плюс всё это может лежать в каких-нибудь blobs в базах данных, это уже не так принципиально -- все эти тонкости одновременного использования representations и presentations, обсуждения "представления чего-то" и "представление на носителе/из чего-то"). Для меня этот переход существенно смягчает требования к работе с данными, выставляемые классическими онтологическими подходами, когда требуется для каждого чиха изобрести имя и дать ему строгое место в картине мира. Базы данных -- это ведь тот же онтологический подход, только с акцентом не на модели данных, а на сами данные в отрыве от их моделей, и предположении о закрытом мире. Трудоёмкость выявления онтологии и последующего описания обработок в этих онтологиях запредельна, много лет этим занимался. Переход от классических компьютерных онто-Логических к распределённым представлениям (что не меняет их онтологического статуса в философском смысле) даёт надежду на решение многих и многих задач, раньше недоступных для программной инженерии. Это прежде всего задача совмещения разных онтологий за счёт перехода к общему пространству значений (да, Everething2Vec очень близко к тому, что меня интересует -- 600-мерные вектора из одинаковых размерностей для меня коннекционистские вполне, а вот 600 типов из какой-то онтологии колонок в какой-нибудь базе данных о 50 таблицах -- нет). Про определения я совсем недавно (я ж онтолог) думал примерно так же, как вы. Но потом пересмотрел свою позицию, и к определениям теперь отношусь очень осторожно.