Автомагическое моделирование данных
Сегодня с одним из западных инженеров обсуждали странное: он утверждал, что любые попытки автоматизировать инженерную работу будут наталкиваться на саботаж со стороны инженеров -- ибо общепринятый способ оплачивать инженерный труд это почасовка, а автоматизация эту почасовку значительно уменьшает. Про конкуренцию ему, похоже, ничего не известно, "все инженерные компании во всех странах не хотят автоматизировать работу с данными -- там везде технологии 80-х, большие стройки идут на эксель-таблицах". Он считал, что "не хотят". Моя точка зрения -- "не могут".
Разнообразные PLM-системы крайне трудно осваиваются (практики управления конфигурацией и изменениями контринтуитивны и трудоёмки), но не в этом дело. Дело в том, что такие системы крайне трудно интегрируют в себя разные виды инженерных данных, особенно если речь идёт о небольших компаниях. Этот западный инженер сказал, что в его знакомой компании вся инженерия обслуживается главным образом пятью сотнями эксель-табличек, связь между которыми есть только в головах людей. И если где изменить одну цифирьку, то это потом нужно отразить ещё в 10-15 местах, о которых люди должны помнить -- само там ничего не изменится, а должно бы. Но тратить время на выкладывание из головы связей между таблицами экселя никто не будет, "нас и так неплохо кормят" -- так не только российские инженеры говорят, но и многие западные.
Это всё из серии "зелен виноград", кавалерийский наскок в задаче интеграции данных жизненного цикла не срабатывает, и руки у инженеров и окружающих их инженеров данных (которые уже ушли от того, чтобы быть программистами, но не пришли к тому, чтобы стать инженерами -- типичные сотрудники всяких служб работы с НСИ, служб PLM, "отделов САПР") опускаются.
Я рассказал про интересные новости в части прохода от формального языка к естественному языку для работы с данными -- Naturalizing a Programming Language via Interactive Learning, https://arxiv.org/abs/1704.06956. we start with a core programming language and allow users to "naturalize" the core language incrementally by defining alternative, more natural syntax and increasingly complex concepts in terms of compositions of simpler ones. ... Over the course of three days, these users went from using only the core language to using the naturalized language in 85.9\% of the last 10K utterances.
Если пойти по этому пути, то дистанция от инженеров до модельеров данных могла бы стать меньше. Но это только один из возможных путей, и не факт, что он главный. Нужны исследования.
Например, ещё есть заход Wolfram language с попыткой принимать запросы на естественном языке (с переспросами, если что-то неочевидно).
Экспериментов много, но промышленного прорыва, как с тем же самым экселем или реляционными базами данных, нет. Таблицы вместо текста оказались killer application. Графы вместо текста много, много богаче таблиц. Они радуют глаз, когда они на страницу. А когда они в промышленных масштабах, то глаз радуется, а мозг огорчается. А таблицы в промышленных масштабах мозг не расстраивают, хотя таблицы и не так красивы для глаза. Следствие: нерасстроенный и радостный мозг не знает, как все эти таблицы объединять! Поэтому строит граф, но "в уме", а не "в компьютере".
Что касается решения разных проблем интеграции данных жизненного цикла, то разговор об этом заводят нерды внутри инженерных предприятий, а сами инженеры не слишком понимают о чём речь: данные инженеры готовы обсуждать, и иногда (очень редко) даже готовы обсуждать модели данных, а вот мета-модели и тем более мета-мета-модели они обсуждать не готовы, их значения не понимают и понимать не хотят. Так что выход из текущего застоя -- это автоматизация работы нердов-онтологов, создающих модели данных и мета-модели для них.
Искусственный интеллект, решающий задачи моделирования, выделения важного из неважного, абстрагирования (специально не пишу тут слова "автоматизация", потому как речь не идёт о замене человека -- тут будет какой-то совсем другой набор практик. Так, персональный компьютер не автоматизировал работу секретарей и операторов ЭВМ, хотя и отнял у них работу. То же самое будет и с моделированием данных: ИскИн не автоматизирует работу сегодняшних модельеров-онтологов, он предложит совсем другие способы решения проблем.
А зачем вообще нужна эта формализация в инженерных проектах? Зачем моделировать данные и интегрировать затем эти модели данных? Для управление конфигурацией, отслеживания конфигурационных коллизий, организации проверок непротиворечивости и полноты описания системы. Все формализмы нужны прежде всего для гарантирования этой "правильности", "целостности", "непротиворечивости", "актуальности". Если мы хотим что-то воплотить в жизнь, получить хорошо работающее в реальном физическом мире, то описание этого чего-то в мире виртуальном должно быть непротиворечиво и полно. Легче всего это описание проверить, если его делать на языке без неоднозначностей, и этот язык должен выражать всё самое важное для создания системы и опускать неважное. То есть язык должен быть формальным, или формальным оестествлённым (но не естественным с его неоднозначностью и склонностью смешивать в тексте собственно содержание и множество ассоциаций, которые иногда могут быть полезны, но чаще только отвлекают).
Есть много идей, как восстанавливать и верифицировать инженерные модели данных масштаба жизненного цикла. Но это пока исследования. Промышленных технологий нет, купить на рынке пока можно только обещания сладкой жизни путём невероятных затрат ручного, тьфу, головного труда. Но всё будет, никуда не денется. Более того, всё будет относительно быстро.
Разговор с тем инженером закончился приятно: он похвалил наш инструмент -- .15926, https://github.com/TechInvestLab/dot15926. Славный был проект, мы многому в ходе этой работы научились.
UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210042527753798
Разнообразные PLM-системы крайне трудно осваиваются (практики управления конфигурацией и изменениями контринтуитивны и трудоёмки), но не в этом дело. Дело в том, что такие системы крайне трудно интегрируют в себя разные виды инженерных данных, особенно если речь идёт о небольших компаниях. Этот западный инженер сказал, что в его знакомой компании вся инженерия обслуживается главным образом пятью сотнями эксель-табличек, связь между которыми есть только в головах людей. И если где изменить одну цифирьку, то это потом нужно отразить ещё в 10-15 местах, о которых люди должны помнить -- само там ничего не изменится, а должно бы. Но тратить время на выкладывание из головы связей между таблицами экселя никто не будет, "нас и так неплохо кормят" -- так не только российские инженеры говорят, но и многие западные.
Это всё из серии "зелен виноград", кавалерийский наскок в задаче интеграции данных жизненного цикла не срабатывает, и руки у инженеров и окружающих их инженеров данных (которые уже ушли от того, чтобы быть программистами, но не пришли к тому, чтобы стать инженерами -- типичные сотрудники всяких служб работы с НСИ, служб PLM, "отделов САПР") опускаются.
Я рассказал про интересные новости в части прохода от формального языка к естественному языку для работы с данными -- Naturalizing a Programming Language via Interactive Learning, https://arxiv.org/abs/1704.06956. we start with a core programming language and allow users to "naturalize" the core language incrementally by defining alternative, more natural syntax and increasingly complex concepts in terms of compositions of simpler ones. ... Over the course of three days, these users went from using only the core language to using the naturalized language in 85.9\% of the last 10K utterances.
Если пойти по этому пути, то дистанция от инженеров до модельеров данных могла бы стать меньше. Но это только один из возможных путей, и не факт, что он главный. Нужны исследования.
Например, ещё есть заход Wolfram language с попыткой принимать запросы на естественном языке (с переспросами, если что-то неочевидно).
Экспериментов много, но промышленного прорыва, как с тем же самым экселем или реляционными базами данных, нет. Таблицы вместо текста оказались killer application. Графы вместо текста много, много богаче таблиц. Они радуют глаз, когда они на страницу. А когда они в промышленных масштабах, то глаз радуется, а мозг огорчается. А таблицы в промышленных масштабах мозг не расстраивают, хотя таблицы и не так красивы для глаза. Следствие: нерасстроенный и радостный мозг не знает, как все эти таблицы объединять! Поэтому строит граф, но "в уме", а не "в компьютере".
Что касается решения разных проблем интеграции данных жизненного цикла, то разговор об этом заводят нерды внутри инженерных предприятий, а сами инженеры не слишком понимают о чём речь: данные инженеры готовы обсуждать, и иногда (очень редко) даже готовы обсуждать модели данных, а вот мета-модели и тем более мета-мета-модели они обсуждать не готовы, их значения не понимают и понимать не хотят. Так что выход из текущего застоя -- это автоматизация работы нердов-онтологов, создающих модели данных и мета-модели для них.
Искусственный интеллект, решающий задачи моделирования, выделения важного из неважного, абстрагирования (специально не пишу тут слова "автоматизация", потому как речь не идёт о замене человека -- тут будет какой-то совсем другой набор практик. Так, персональный компьютер не автоматизировал работу секретарей и операторов ЭВМ, хотя и отнял у них работу. То же самое будет и с моделированием данных: ИскИн не автоматизирует работу сегодняшних модельеров-онтологов, он предложит совсем другие способы решения проблем.
А зачем вообще нужна эта формализация в инженерных проектах? Зачем моделировать данные и интегрировать затем эти модели данных? Для управление конфигурацией, отслеживания конфигурационных коллизий, организации проверок непротиворечивости и полноты описания системы. Все формализмы нужны прежде всего для гарантирования этой "правильности", "целостности", "непротиворечивости", "актуальности". Если мы хотим что-то воплотить в жизнь, получить хорошо работающее в реальном физическом мире, то описание этого чего-то в мире виртуальном должно быть непротиворечиво и полно. Легче всего это описание проверить, если его делать на языке без неоднозначностей, и этот язык должен выражать всё самое важное для создания системы и опускать неважное. То есть язык должен быть формальным, или формальным оестествлённым (но не естественным с его неоднозначностью и склонностью смешивать в тексте собственно содержание и множество ассоциаций, которые иногда могут быть полезны, но чаще только отвлекают).
Есть много идей, как восстанавливать и верифицировать инженерные модели данных масштаба жизненного цикла. Но это пока исследования. Промышленных технологий нет, купить на рынке пока можно только обещания сладкой жизни путём невероятных затрат ручного, тьфу, головного труда. Но всё будет, никуда не денется. Более того, всё будет относительно быстро.
Разговор с тем инженером закончился приятно: он похвалил наш инструмент -- .15926, https://github.com/TechInvestLab/dot15926. Славный был проект, мы многому в ходе этой работы научились.
UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210042527753798