Говорят: под Новый год
Что ни пожелается –
Всё всегда произойдёт,
Всё всегда сбывается.
С. Михалков
Конечно, хотелось бы назвать материал поконкретнее, но сама тема конкретности не предполагает. Что же касается термина «правдоподобные рассуждения», то это, конечно, навеяно книгой Джорджа (Дьердя) Пойи.
Вот поставленная задача, которую мыслится решить с помощью искусственного интеллекта (ИИ).
Есть завод, который может делать воздуховоды любой длины, формы, конфигурации и т.д.
Требуется дать потребителю возможность самостоятельно спроектировать произвольный воздуховод. Основная проблема/задача, как видится, в слове «произвольный», т.к., если воздуховод проектируется из стандартных элементов (т.е., по сути, конфигурируется из набора элементов и типоразмеров), то задача алгоритмизируется. Слово «произвольный» подразумевает на выходе бесконечное количество типов/размеров/конфигураций/форм воздуховодов.
Также нужно чтобы система:
- понимала, что проектируется воздуховод;
- сформулировала правила построения любых воздуховодов (плюс использовала известные ограничениях на входе) и отследила бы их выполнение при проектировании (или не давала пользователю спроектировать неправильно);
- после проектирования рассчитала бы все необходимые значения до уровня рабочей документации.
PS: В качестве «воздуховода» может быть любое изделие с заранее определённой топологией (ботинок, авиационный двигатель, ...).
Наверное, можно было бы не бросаться сразу к ботинку или авиадвигателю, а попробовать раздвигать границы постепенно: взять вообще все трубопроводы, от магистральных газопроводов типа «Уренгой - Помары - Ужгород» до гидросистем какого-нибудь погрузчика или станка.
Но для начала попробую разобраться с воздуховодами. Полагаю, что идти следует не от абстракции «произвольного изделия», а от требований к его работе, к тому, для чего это изделие (или система), собственно, нужно. Иногда анализ задачи приводит к неожиданным результатам.
На заводе, где я работал, прокладкой гидравлических трубопроводов по станку занималось бюро гидрооборудования, прокладкой электрических жгутов – бюро электрооборудования. Выглядело это так: ведущий разработчик, он же механик, отдавал нам почти готовый проект, и от нас требовалось по нему проложить трассы. Не всегда это было легко, поскольку при проектировании «основы» конструктор-механик про нас часто забывал и не оставлял нам каналов и окон в корпусных деталях. Поскольку электрики и гидравлики имели равные права, начиналась натуральная драка за наиболее удобные для прокладки коммуникаций места. Были случаи, когда мы недостаточно хорошо координировали свою работу, и на гидравлической документации в одном и том же месте станка были элементы гидравлики, а на электрической документации – электрики. Решение я увидел у коллег из Питера: там прокладкой коммуникаций занимался ведущий разработчик изделия, а электрики и гидравлики только давали ему геометрические параметры: диаметры и минимальные радиусы гиба труб, диаметры электрожгутов, габаритные и присоединительные размеры установочных компонентов. Разумеется, ответственности за функционирования электрических и гидравлических систем со специализированных подразделений никто не снимал, вопрос был только в прокладке трасс. Это я к тому, что взаимодействие главных проектировщиков здания и подразделения воздуховодов тоже неплохо бы проанализировать.
А теперь немного теории автоматизации проектирования и других процессов. Начинается всё с формализации, описания того, что делает «естественный интеллект». Эта формализация будет тем успешнее, чем изначально формализованнее работа этого «естественного интеллекта». Классический пример: разделение процесса изготовления изделия на операции, превращение этих операций в повторяющееся путём создания рабочих мест операционистов. В пределе – создание автоматов, массово производящих отдельные компоненты по жёсткому циклу.
Как бы ни считали конструкторы свою работу творческой, если конструктор занят проектированием однотипных изделий, в его работе неизбежно будут присутствовать рутинные фрагменты. Что же произойдёт, если эти рутинные фрагменты автоматизировать и отдать компьютеру? Рутинными станут следующие фрагменты, которые до этого повторялись реже и не рассматривались как объект для автоматизации. И так далее, при необходимом условии роста объёмов выполнения проектов. Потому что если объёмы проектной работы не растут, то и повторяемость расти не будет, а конструктора задействуют на другой работе.
Однако кроме роста объёмов проектирования автоматизация при прочих равных приводит и к повышению качества проектов. Конструктор быстрее набивает руку, у него становится больше возможностей анализировать сделанное, получать больше отзывов от тех, кто производит, внедряет и эксплуатирует его проекты. Это должно привести к формулированию новых правил и корректировке уже сформулированных. При этом по мере появления новых аппаратных платформ, повышения их производительности и увеличения объёмов хранения данных снимаются ограничения на сложность софта. Одним из таких явлений стал повсеместный переход от плоского черчения к объёмному моделированию объектов, сначала только геометрическому, а потом и наделению их различными свойствами. Это может быть жёсткость и прочность конструкции, центр масс – да что в голову придёт. В общем, нормальный, понятный эволюционный путь.
Под конструктором я подразумеваю не отдельное физлицо, а некое сообщество, способное воздействовать на разработчиков софта, которое к тому же само активно участвует в его разработке, привнося в этот софт свой опыт проектирования.
Но есть другой путь – искусственный интеллект. Это некий чёрный ящик, которому мы загадываем желания, а он их выполняет. Если отбросить всю словесную шелуху, именно это и остаётся. Что-то вроде цирковой собачки, которой зритель показывает цифры 3 и 2, а она тявкает ровно 5 раз. Зритель, может, и сам дрессировал собак, и они умели сидеть, лежать, ходить рядом и подавать голос, но вот чтобы складывать числа… Точно так же смотрит на ИИ обычный программист. Он понимает, что если имеется некая формализованная деятельность, то можно написать постановку задачи, сформулировать правила и написать их на каком-нибудь языке программирования, а данные поместить в реляционную базу, спроектированную по правилам Кодда.
И чем больше правил мы сумеем сформулировать, чем лучше будут эти правила, чем более квалифицированные конструкторы будут участвовать в её создании, тем совершеннее станет программа. То есть главный рецепт, на мой взгляд – привлечение к разработке софта предметных специалистов, обладающих знаниями и опытом, а не попытка дилетантов в создании воздуховодов (ботинок, авиадвигателей) прийти, и с помощью одной только математики (программирования, ИТ) устроить переворот в какой-нибудь предметной области.
Также следует помнить, что обучение в живой природе, это кнут и пряник. Учитель объясняет правила, а ученик по ним выполняет практические задания: решает задачи, пишет диктанты, ставит опыты. Потом учитель оценивает выполнение заданий и поощряет или наказывает ученика. Применительно к софту разница только в том, что нет представления о непогрешимости учителя и нерадивости ученика, потому что любая неадекватная работа программы, это недоработка программиста, её создавшего. Обучение в плане программирования – это ловля багов или формулирование и реализация новых (изменённых или дополнительных) правил. Поясню на примере работы навигационного софта. Первый этап разработки такой программы – определение кратчайшего маршрута. Второй – анализ скорости на участках маршрута с учётом пробок. Однако, применительно к Самаре (и, наверное, к другим российским городам), должно быть и понимание навигационным софтом того факта, что не всякая отмеченная на карте улица тождественна дороге.
Как-то по весне «Яндекс.Навигатор» повёл меня по улице XXII Партсъезда от Ставропольской до Карла Маркса. Несколько первых ям с водой я преодолел, но потом счёл за благо вернуться назад. Я понимаю, что разработчикам невозможно оценить проходимость каждой улицы для каждой модели автомобиля, но по статистике фактических проездов по предложенным маршрутам и характеру движения вполне можно корректировать предложения. Можно ли назвать дополнение навигационной программы новыми правилами элементами искусственного интеллекта? Простите, а с чего бы? Это – обычная оптимизация.
Следующие строфы стихотворения, вынесенного в эпиграф, помнят меньше, а они как раз самые важные:
Могут даже у ребят
Сбыться все желания,
Нужно только, говорят,
Приложить старания.
Не лениться, не зевать,
И иметь терпение,
И ученье не считать
За своё мучение.
Так что никаких чудесных чёрных ящиков, есть только обычная работа.
Несколько лет назад я написал о том, как нам в середине 80-х удалось создать программу проектирования гидроблоков с распечаткой сборочных чертежей на барабанном АЦПУ только потому, что перед этим процесс ручного черчения был предельно формализован, а сама разработка оптимизирована.
Однако перед этим мне понадобилось разработать гидроблок управления автооператором для смены инструмента. Он должен был размещаться на подвижном рычаге, к которому крепился автооператор, вписываться в габариты и иметь минимальную массу.
Здесь меня уже волновала не оптимизация разработки, а эффективность самого устройства. И вот это целеполагание, выбор приоритетов всегда будет оставаться за человеком – есть вещи, которые мы должны делать сами, не полагаясь на пресловутый искусственный интеллект.
Чего всем и желаю в Новом 2018 году!