?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Сколько уровней в интеллект-стеке? Много. [23 Oct 2017|01:15am]
Обсуждали сегодня, что интеллект-стек много глубже, чем я его показываю: уровень аппаратуры там нужно рассматривать тоже платформенный -- в учебнике Дэвида Харриса и Сары Харрис «Цифровая схемотехника и архитектура компьютера» 7 уровней для аппаратуры (http://ailev.livejournal.com/1193158.html):

И когда NVIDIA интересуется уровнями интернет-стека выше аппаратного GPU (https://ailev.livejournal.com/1380163.html),

то это она делает поверх уже довольно глубокого аппаратного платформенного стека самого GPU -- того стека, который для неё основной.

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

Можно расщеплять и другие уровни интеллект-стека. Так в learning algorithm platform для глубокого обучения сегодня выделяют уровень описания (в том числе динамического) computation graph, а потом компилируют/интерпретируют граф в вызовы вычислительной библиотеки. Компилятор/интерпретатор обычно означает наличие дополнительного уровня. У Харрисов тоже упрощённая архитектура. Например, у мейнфреймов можно было найти в аппаратуре дополнительный уровень процессорных микропрограмм. У GPU совсем другая архитектура, но рассуждения для неё очень похожи.

Спрос (деньги!) при этом идёт сверху, от прикладного уровня интеллект-стека, а вот прорывы -- от самых нижних уровней, от devices по Харрисам. Подрыва интеллект-стека можно ожидать от квантовых компьютеров, от мемристорных компьютеров, от аналоговых нейроморфных компьютеров -- от самого низа стека, задействующего другую физику.

Зачем это всё? Для разделения труда, для модульности. Это всё борьба со сложностью. Ошибка улучшения какого-то словя не распространяется по системе неограниченно. Ошибка отслеживается на интерфейсе платформенного слоя и не проходит выше. Поэтому каждый слой можно улучшать независимо от других, просто соблюдая контракты платформенных уровней. Неизбежно получаемые при этих улучшениях ошибки не будут неконтролируемо распространяться по системе -- они будут отслежены на ближайшем интерфейсе платформенного уровня.

UPDATE: Поскольку речь идёт о системном мышлении, то это стандартный способ размышления -- вот, например, из свежих попсовых (а что вы хотите от venchurebeat?!) материалов, которые обращаются к понятию AI full-stack company: https://venturebeat.com/2017/10/20/youre-not-an-ai-company-until-youre-a-full-stack-company/. Статья сама по себе ни о чём, но автор там говорит, что прикладной уровень в интеллект-стеке тоже дробится, это тоже не один уровень, а целый стек уровней. Хотя автор довольно странно и спорно выделяет там уровни этого стека -- "every level of the solution: big data, analytics, and user experience (UX). A bot or an algorithm can’t and shouldn’t just stand on its own".
28 comments|post comment

Системное мышление в управлении конфигурацией [23 Oct 2017|12:55pm]
Я вёл семинар по управлению конфигурацией в Атомстройэкспорт-НИАЭП 20 октября 2017 (https://www.facebook.com/igor.shumakov.9/posts/1274196842727077), и в рамках этого ведения читал двухчасовую установочную лекцию по системному мышлению в управлении конфигурацией. Раз уж ссылка на слайды утекла, то вот эти слайды (https://www.slideshare.net/ailev/ss-81094137):

Основная мысль была в том, что системное мышление контринтуитивно и проблемы с объяснением configuration management самым разным стейкхолдерам возникают не из-за собственно сложности работы с конфигурацией, а из-за непонимания основ системного мышления:
-- конфигурация прежде всего воплощения системы, а не описаний, документы лишь описания физической системы (и если физическая система ещё не существует, то в 4D это ничего не меняет -- там нет "ещё" и "уже", рассуждения ведём в методологическом времени).
-- конфигурационная единица определяется инженерами (они нарезают систему на части разными методами -- функциональный анализ и модульный синтез в сочетании с компоновкой прежде всего), но в целях менеджерских (именование делается для обеспечения логистического учёта: менеджеры обеспечивают поток конфигурационных единиц между инженерными станциями их обработки).
-- холархий может быть множество разных, минимально функциональная, продуктная, размещений (по терминологии IEC 81346-1). Разным стейкхолдерам для разных целей столько много не нужно, но собирающим целое системным инженерам (к которым можно отнести и управляющих конфигурацией) нужны они все три, и даже больше.
-- управление изменениями (в том числе управление работами, в том числе и WBS) привязано к объектам конфигурации: каждая практика работает с какой-то частью системы, каждая работа происходит с какой-то частью системы (или описанием, но опять-таки каждой части системы).
-- позиционное кодирование (KKS, RDS-PP) хорошо, но иерархическое на заранее неизвестное число системных уровней (предлагаемое, например, IEC 81346) лучше. В том числе оно решает вопросы именования частей системы, сборка которой делается несколькими уровнями подрядчиков.
-- софт неважен, важна дисциплина, которую софт поддерживает: конфигурационное управление это дисциплина, она не специфична именно для атомной отрасли, и её основное содержание идёт из системного подхода.
-- неважно, распределённая ли учётная система, или централизованная. Принципы управления конфигурацией могут быть поддержаны и в случае распределённой системы, и в случае централизованной системы. Этот вопрос я не разбирал подробно на семинаре, но по этой линии я обычно и на решения с блокчейном выхожу (это ж про учёт), например в явном виде я поминал распределённые ALM/PLM в http://ailev.livejournal.com/1259878.html.

Управления изменениями практически не касались, и без этого времени не хватало. Зал там был огромный, но совсем не пустой: было более полусотни человек из самых разных организаций системы Росатома. После установочной лекции я вёл живое отраслевое обсуждение (было ещё три доклада с жаркими дискуссиями) до самого конца дня, но это я оставлю без комментариев, обычно про клиентов я в блоге не пишу.
post comment

navigation
[ viewing | October 23rd, 2017 ]
[ go | previous day|next day ]