Коннекционистская проблематизация системного подхода.
Основной путь, по которому системный подход проблематизируется, относится к переходу от локальных представлений системы к распределённым (http://ailev.livejournal.com/1228029.html). С распределёнными представлениями беда: вся подробно разработанная "механика" уровней системы с отношением часть
( Read more... )
Про тысячи строк внесённых исправлений: моя самая первая работа именно такая и была -- участие в разработке объемистой платформы прикладного программирования, которую ваял десяток человек несколько лет. Но меня там больно били, если я писал пушисто, и заставляли переписывать примерно по тем принципам, которые исповедует команда Алана Кея -- каждый раз выяснялось, что можно писать в разы короче! Ну, команда так и писала, очень плотный код. Так что там где-то под сто тыс. перфокарт (это было в самом начале 80-х!) всё и болталось. А дальше я правил операционку RT-11 (часть -- прямо в редакторе дампов, так переводил на русский), дополнял её драйверами интерфейса МЭК, управляемого регистром модуля КАМАК. И так далее, довольно много лет. И ещё много лет непосредственно руководил проектами создания софта, а потом ещё и консультировал проекты по созданию софта или разворачиванию софта, а в последнее время по интеграции софта (та же модульность, только на другом уровне). Последние софтинки, которые выпустил TechInvestLab в open source -- https://github.com/TechInvestLab (а до этого был, например, Communiware).
Из создателей ООП я беседовал лично только с Donald Firesmith и Ivar Jacobson, их точка зрения близка к высказываемой Алан Кеем: слишком много программировавшие на wintel платформе привели современное программирование в тупик, а объект-ориентированность пошла как-то криво. Мы ещё обсуждали этот вопрос с Harold Lawson, он тоже считает, что современное программирование с текущим вариантом ООП на wintel в тупике -- и исправлять нужно, начиная с системы команд хардвера.
Reply
Вы считаете, что есть какие-то проблемы с модульностью в таких системах? Я не понимаю, почему вы так считаете.
> и в связи с этим сдвиг от онтологических рассмотрений знания к эпистемологическим, как более адекватным.
Расшифруйте, пожалуйста. В меру своего понимания, я не вижу здесь противопоставления -- вроде бы, современные базы данных включают в себя и абстрактные и конкретные знания. Что значит "сдвиг от"?
>И что нужно пошевелить в системном подходе текущей версии (документированной в классических стандартах системной инженерии, типа ISO 15288, ISO 42010 и недавно OMG Essence), чтобы можно было обсуждать в том числе и разработку систем машинного обучения.
А, так это бесполезно: подробные и аккуратные стандарты появляются только тогда, когда описываемая отрасль перестаёт меняться и начинает стагнировать или загибаться. Стандарт описывает всё общее из проектов. Но если в проектах нет ничего общего, то о чём писать в стандарте? Про чёрный ящик и потоки данных между этими чёрными ящиками, и life cycle этих потоков данных и этих чёрных ящиков? Ну тогда берите существующий стандарт, пишите, что вместо программиста теперь есть группа "программист+нейросеть", а на выходе у этой группы есть доп. модули в формате "модуль нейросети" вместо "библиотека кода", ну и соотв. доп. артефакты в виде "модуль нейросети", "архитектура нейросети", "данные для тренировки нейросети" и т.п. . Больше ничего не поменялось, просто часть кода пишет не человек, а компьютер.
Reply
Можете проглядеть http://leon.bottou.org/slides/2challenges/2challenges.pdf, там немного есть про эту модульность по-английски.
То, что вы пишете о стандартах, я даже комментировать не буду.
Reply
Давайте попробую выделить за вас вашу проблему модульности. А вы скажете, правильно или нет я это сделал, и согласны ли вы с моими выводами.
"Если программист оптимизирует полную вероятность параметра, то другой программист не может оптимизировать на основе этих данных полную вероятность другого параметра"
Один делает max P(X), второй max Q(X). Вместо этого, от них ожидают max R(X). Чтобы справиться, обычно нужно посчитать P(X) и Q(X) в каждой точке, а оттуда уже посчитать R.
Если рассматривать проблему в контексте управления людьми, то это ошибка менеджеров в отсутствии коммуникации между командами и противоречивых условиях задачи.
Эта проблема никак с ML/DL не связана, и характерна для любого процесса разработки программного обеспечения.
Если у двух программистов или дизайнеров в спецификации написано максимизировать разные величины, то они тоже не договорятся. И нет никакого заранее известного формального способа договориться. Аналитический поиск компромиссов в данной ситуации эквивалентен вычислению вероятностей в каждой точке в случае ML/DL вместо вычисления полной вероятности.
Так что здесь ничего не изменилось, кроме того, что договариваться нейросети друг с другом не умеют, и им нужна помощь программиста. Поэтому я и говорю, что вместо "программиста" теперь строительный блок для менеджера -- "программист+нейросети", а не "нейросеть" сама по себе.
> Use trained models as software modules: problematic because trained models offer weak contracts.
"Использование натренированных моделей как программные модули проблемно потому что они умеют только считать полные вероятности"
Эквивалент: "Использование программных модулей по спецификациям проблемно, потому что спецификации неполны"
> Use learning algorithms as software modules: problematic because the output of the learning algorithm depends on the training data
Эквивалент: "Использование модулей, сделанных по спецификациям, проблемно, потому что вывод модулей зависит от того, что написано в спецификации".
Практические примеры: в ядре Windows больше 20 разных реализаций сортировки, а в наборе библиотек Watson больше 50 реализаций превращения текста в слова: одна реализация удаляет запятые, вторая нет, третья превращает слова в маленький регистр, четвёртая разделяет can't на два слова ca и n't , а пятая делает всё вместе одновременно.
По-моему, это отличный пример для иллюстрации вашей воображаемо "более хорошей модульности" в случае обычной разработки ПО.
И похоже, все проблемы из-за того, что автор сравнивает тёплое с мягким: одну "неделимую" DL/ML нейросеть с модульной программой (тестируются модули). Вместо этого, парадигма должна быть другая: одна нейросеть -- это один модуль, а не вся программа. Тогда всё встаёт на свои места, а мы вспоминаем, что тестирование ПО бывает модульным и интеграционным, бывает отладка межмодульных взаимодействий, и тому подобное.
Ну а если вы хотите формальную верификацию DL/ML-систем ("strong contracts"), то сначала научитесь делать формальную верификацию классических систем, где есть пользовательский интерфейс или сложное состояние.
Если я не о том, то, возможно, вам придётся пояснить вашу коннекционистскую проблему ещё раз.
По мне, так нет никакой новой проблемы.
А под "эпистемологической проблемой" вы можете иметь в виду то, что нейросети "учатся" на данных, а софт "не учится". Это заблуждение. Вы можете исправлять модуль, если он выдаёт ошибку на каких-то данных -- "учить его". А можете "не доучивать" нейросеть -- использовать готовую нейросеть для другого набора данных.
Разница в подходах лишь только в том, кто осуществляет изменения -- ML/DL модель может доучиваться "сама", а обычный софт учит только человек.
Reply
Leave a comment