Это уже из области практики. Недавно разрабатывали методику прогнозирования синергетических чрезвычайных ситуаций. Смысл задачи таков: существует объект, на котором могут происходить различные аварии, приводящие к ущербу. Сценарии возможных аварий определены и зафиксированы в декларации безопасности объекта, вместе с такими параметрами, как вероятность возникновения инициирующих событий (брешь в резервуаре, наличие источника возгорания и т. д.) и ущерб, определенный по моделям, соответствующим характеру аварии (разлив вещества, пожар, взрыв и т. д.). Также известно, какие неблагоприятные природные явления могут возникать в данной местности и как часто (аномальный холод или жара наводнение, землетрясение и т. п.). Проблема в том, что в нынешнем виде вся эта информация существует по отдельности, а это неправильно – нужно учитывать взаимодействие всех факторов.
Кратко изложу свой подход к решению задачи. Возьмем, к примеру, аномальную жару. Она, очевидно, может повлиять на давление в резервуаре с веществом, как следствие, на вероятность трещины в резервуаре и вероятность аварии. Но это еще не все: та же аномальная жара вполне может повлиять на радиус зоны распространения физических параметров аварии, мощность взрыва, скорость испарения ядовитых веществ. Кроме того, необходимо учитывать и эффект домино или каскадный эффект: одна авария может привести к другой, та к третьей и так далее. Иными словами, если происходит первая авария, нужно понимать, куда бежать, а бежать нужно не только к уже взорвавшемуся агрегату, чтобы ее ликвидировать, но, возможно, и к тому агрегату, который, согласно расчетам, имеет наибольшую вероятность взорваться третьим в цепочке и/или нанести при взрыве максимальный ущерб. Почему третьим, а не вторым? Потому что возможно, что второй агрегат имеет настолько большую вероятность взорваться после взрыва первого, что находиться рядом с ним опасно, или, наоборот, он имеет настолько ничтожную с точки зрения ущерба зону распространения физических параметров даже с учетом внешних природных и техногенных факторов, что о нем не стоит беспокоиться, сосредоточив усилия на агрегатах 1 и 3. Я предлагал строить модель в виде деревьев всех возможных цепочек аварий, иными словами, я предлагал использовать деревья событий, где каждый узел – это авария, и пересчитывать параметры (вероятности аварии и параметров распространения) с учетом всего пути, пройденного из корня, то есть от первой, начальной аварии до данной.
Подход был отвергнут коллегами на основании того, что при его реализации возникает «комбинаторный взрыв», то есть объем необходимых расчетов растет взрывным образом с увеличением количества возможных сценариев аварий. Скажем, в декларации безопасности объекта зафиксировано n возможных сценариев аварий, тогда количество всех возможных цепочек будет равно количеству перестановок из n элементов. При 5-ти возможных аварийных сценариях, нам нужно будет работать со 120 цепочками и 325 узлами, что не так плохо, но уже при 10-ти возможных сценариях мы имеем 3 628 800 цепочек и 9 864 100 узлов. Это и правда мощно! В одной из рассмотренных деклараций безопасности число аварийных сценариев превышало несколько сотен, со всеми вытекающими цифрами.
Ключевой момент здесь не в самом отказе коллег от подхода, а в причине этого отказа. Разумеется, в ходе решения возникает комбинаторный взрыв: чтобы понять, как ситуация будет развиваться на следующем шаге, нам необходимо оценить ее на данный момент, а она зависит от всего, что уже нагрелось, разорвалось, вытекло или горит, то есть мы вынуждены «потрогать» каждую аварию на каждом шаге. Это метод полного перебора, он предлагался мною в качестве основы, а не в качестве готового решения. Разумеется, необходимо ограничивать перебор: ввести эвристики, применить принцип разумных предположений, распространить ограничения. Например, мы можем с уверенностью сказать, что если на агрегате уже произошло возгорание, то на нем уже не может возникнуть авария по другому сценарию, который предусматривает отсутствие возгорания. Мы можем считать, что на одном агрегате происходит только одна авария. Мы можем ограничить рассмотрение 2-мя или 3-мя авариями в цепочке (уровнями в деревьях) и углубляться в деревья по мере необходимости и развития ситуации. Было, куда стремиться, нужно было только подобрать методы сокращения необходимых вычислений и требуемой памяти, в наибольшей степени отвечающие целям защиты людей и имущества. Но подход был отвергнут только из-за порождаемого комбинаторного взрыва.
На сайте JSMapReduce есть простой пример того, как из небольшого набора исходных данных – 52 карт – порождается гигантский массив для обработки – 2 598 960 комбинаций из 5 карт, которые могут достаться игроку в покер. Эта цифра получается, как количество сочетаний из n элементов по k элементов без учета различных положений элементов.
Теперь представим себе, что игроков 4-ро, 5-ро или больше, и попробуем подсчитать количество всех комбинаций карт, одновременно находящихся у всех игроков (и в этом случае будет еще важно, у кого именно какие конкретные карты). Попробуем сделать то же для случая, когда несколько человек играют в «Очко», и карты раздаются из смеси 2-ух, 3-ех, 4-ех колод. Иногда большой объем данных и вычислений неизбежен (пока для данной задачи не найден алгоритм получше, если он вообще может быть найден), но, в принципе, для решения многих задач, где возникает комбинаторный взрыв, у нас на сегодняшний день есть и мощности, и алгоритмы.
Размышляя над этим, я сделал второе открытие: ученые могут не знать о современных возможностях технологий, и это само по себе нехорошо, но, что намного хуже, находясь в тенетах своего незнания, они могут делать ошибочные выводы о нецелесообразности тех или иных масштабных расчетов, невозможности применения тех или иных методов, недостижимости приемлемой точности вычислений.
Причем здесь анализ данных? Все, опять-таки, очень просто: он зачастую связан с технологиями ничуть не меньше, чем с наукой. Деревья структуры, метод главных компонент, вычисление метрик и визуализация больших наборов данных руками не делаются, а потому требуют от аналитика «быть в теме» технологий, которые меняются куда быстрее фундаментальной науки. Иными словами, чтобы испечь пирог под названием «Результаты анализа», нужно замесить тесто из фундаментальной и прикладной науки, а также технологий, причем это касается и навыков работы с оными, а не только общих положений, и приправить все это солидной щепоткой интуиции. Методы добывания и обработки больших данных, MapReduce, программы построения статистических и других моделей, программы визуализации – это только на сегодняшний день, и это далеко не все.
Кратко изложу свой подход к решению задачи. Возьмем, к примеру, аномальную жару. Она, очевидно, может повлиять на давление в резервуаре с веществом, как следствие, на вероятность трещины в резервуаре и вероятность аварии. Но это еще не все: та же аномальная жара вполне может повлиять на радиус зоны распространения физических параметров аварии, мощность взрыва, скорость испарения ядовитых веществ. Кроме того, необходимо учитывать и эффект домино или каскадный эффект: одна авария может привести к другой, та к третьей и так далее. Иными словами, если происходит первая авария, нужно понимать, куда бежать, а бежать нужно не только к уже взорвавшемуся агрегату, чтобы ее ликвидировать, но, возможно, и к тому агрегату, который, согласно расчетам, имеет наибольшую вероятность взорваться третьим в цепочке и/или нанести при взрыве максимальный ущерб. Почему третьим, а не вторым? Потому что возможно, что второй агрегат имеет настолько большую вероятность взорваться после взрыва первого, что находиться рядом с ним опасно, или, наоборот, он имеет настолько ничтожную с точки зрения ущерба зону распространения физических параметров даже с учетом внешних природных и техногенных факторов, что о нем не стоит беспокоиться, сосредоточив усилия на агрегатах 1 и 3. Я предлагал строить модель в виде деревьев всех возможных цепочек аварий, иными словами, я предлагал использовать деревья событий, где каждый узел – это авария, и пересчитывать параметры (вероятности аварии и параметров распространения) с учетом всего пути, пройденного из корня, то есть от первой, начальной аварии до данной.
Подход был отвергнут коллегами на основании того, что при его реализации возникает «комбинаторный взрыв», то есть объем необходимых расчетов растет взрывным образом с увеличением количества возможных сценариев аварий. Скажем, в декларации безопасности объекта зафиксировано n возможных сценариев аварий, тогда количество всех возможных цепочек будет равно количеству перестановок из n элементов. При 5-ти возможных аварийных сценариях, нам нужно будет работать со 120 цепочками и 325 узлами, что не так плохо, но уже при 10-ти возможных сценариях мы имеем 3 628 800 цепочек и 9 864 100 узлов. Это и правда мощно! В одной из рассмотренных деклараций безопасности число аварийных сценариев превышало несколько сотен, со всеми вытекающими цифрами.
Ключевой момент здесь не в самом отказе коллег от подхода, а в причине этого отказа. Разумеется, в ходе решения возникает комбинаторный взрыв: чтобы понять, как ситуация будет развиваться на следующем шаге, нам необходимо оценить ее на данный момент, а она зависит от всего, что уже нагрелось, разорвалось, вытекло или горит, то есть мы вынуждены «потрогать» каждую аварию на каждом шаге. Это метод полного перебора, он предлагался мною в качестве основы, а не в качестве готового решения. Разумеется, необходимо ограничивать перебор: ввести эвристики, применить принцип разумных предположений, распространить ограничения. Например, мы можем с уверенностью сказать, что если на агрегате уже произошло возгорание, то на нем уже не может возникнуть авария по другому сценарию, который предусматривает отсутствие возгорания. Мы можем считать, что на одном агрегате происходит только одна авария. Мы можем ограничить рассмотрение 2-мя или 3-мя авариями в цепочке (уровнями в деревьях) и углубляться в деревья по мере необходимости и развития ситуации. Было, куда стремиться, нужно было только подобрать методы сокращения необходимых вычислений и требуемой памяти, в наибольшей степени отвечающие целям защиты людей и имущества. Но подход был отвергнут только из-за порождаемого комбинаторного взрыва.
На сайте JSMapReduce есть простой пример того, как из небольшого набора исходных данных – 52 карт – порождается гигантский массив для обработки – 2 598 960 комбинаций из 5 карт, которые могут достаться игроку в покер. Эта цифра получается, как количество сочетаний из n элементов по k элементов без учета различных положений элементов.
Теперь представим себе, что игроков 4-ро, 5-ро или больше, и попробуем подсчитать количество всех комбинаций карт, одновременно находящихся у всех игроков (и в этом случае будет еще важно, у кого именно какие конкретные карты). Попробуем сделать то же для случая, когда несколько человек играют в «Очко», и карты раздаются из смеси 2-ух, 3-ех, 4-ех колод. Иногда большой объем данных и вычислений неизбежен (пока для данной задачи не найден алгоритм получше, если он вообще может быть найден), но, в принципе, для решения многих задач, где возникает комбинаторный взрыв, у нас на сегодняшний день есть и мощности, и алгоритмы.
Размышляя над этим, я сделал второе открытие: ученые могут не знать о современных возможностях технологий, и это само по себе нехорошо, но, что намного хуже, находясь в тенетах своего незнания, они могут делать ошибочные выводы о нецелесообразности тех или иных масштабных расчетов, невозможности применения тех или иных методов, недостижимости приемлемой точности вычислений.
Причем здесь анализ данных? Все, опять-таки, очень просто: он зачастую связан с технологиями ничуть не меньше, чем с наукой. Деревья структуры, метод главных компонент, вычисление метрик и визуализация больших наборов данных руками не делаются, а потому требуют от аналитика «быть в теме» технологий, которые меняются куда быстрее фундаментальной науки. Иными словами, чтобы испечь пирог под названием «Результаты анализа», нужно замесить тесто из фундаментальной и прикладной науки, а также технологий, причем это касается и навыков работы с оными, а не только общих положений, и приправить все это солидной щепоткой интуиции. Методы добывания и обработки больших данных, MapReduce, программы построения статистических и других моделей, программы визуализации – это только на сегодняшний день, и это далеко не все.
Комментариев нет:
Отправить комментарий