Рассказы об анализе: терминологический аппарат

Если в научной работе (аналитической) дается новое определение известного термина - это не означает, что автор претендует на лавры. С таким же успехом это может означать, что существующие определения в недостаточной степени или не с нужных сторон характеризуют предмет.

Приведу пример из реальной научно-исследовательской работы "Анализ информационной деятельности территориальных органов МЧС России". В ходе этой работы проводился анализ качественных данных (содержания) большого числа нормативных документов. В этих документах постоянно встречались термины "социальные медиа", "социальные сети", "блоги", "блог-площадки" и т. д., причем нигде не давалось определений того, что под этими терминами понимается, некоторые из них выступали, как взаимозаменяемые без какого-либо на то основания. Пришлось разбираться.

Блог, согласно расхожему определению, – интернет-журнал событий, интернет-дневник, онлайн-дневник. Однако для целей ведения системной деятельности в рамках организации такое определение недостаточно. В нашем случае блог разумнее определить как относительно регулярный по интенсивности, предметной области, авторству и характеру связи с соответствующей организацией поток мультимедийного контента и библиотека (архив) этого контента, доступ к которым является свободным и всеобщим и предоставляется посредством интернет-технологий.

Иными словами, "интернет-дневник" об организации может вестись ее сотрудником или сторонним лицом (второе характерно для известных компаний и организаций), публикации выкладываются относительно регулярно (несколько раз в день +/- несколько публикаций, раз в неделю +/- несколько дней и т. д.), содержание сконцентрировано на деятельности организации (могут присутствовать публикации на смежные темы), доступ на чтение имеют все (если речь не идет о внутреннем "блоге" в рамках интрасети, хотя в этом случае он ближе к корпоративной почте), причем для изучения доступны все когда-либо опубликованные материалы, кроме специально удаленных или закрытых.

По аналогии, социальная сеть часто определяется, как платформа, онлайн-сервис или веб-сайт, предназначенные для построения, отражения и организации социальных взаимоотношений. Мы и здесь дадим другое определение. Социальная сеть – это совокупность полной и частичной контактной и другой информации, связанной с людьми, организациями и другими сущностями (брендами, общественными объединениями, политическими партиями и т. д.), а также, возможно, информация о связях между ними, которые находятся в распоряжении субъекта и могут быть использованы в его интересах. При этом:

• под субъектом может пониматься разработчик социального сервиса, особа, получившая указанные данные через открытые интерфейсы сервиса, управляющий call-центра или центра опроса общественного мнения, человек, коллекционирующий визитные карточки и т. д. (способ получения информации неважен - важен ее характер);
• интересы субъекта могу включать расширение социальной сети с целью профессионального развития, адресное предоставление информации, личное общение и т. д.;
• связи в сети могут иметь как конкретный характер ("женат на"), так и общий ("коллеги", "друзья");
• как правило, предполагается возможность описания социальной сети в некотором формальном виде, в бумажной или цифровой форме;
• доступ к таким данным может быть полным или частичным, всеобщим или ограниченным, в зависимости от преференций субъекта (обладателя) и объекта контактных и других данных (того, чьими они являются).

Термин "социальная сеть" был некорректно адаптирован в русском языке в качестве собирательного обозначения сайтов, типа Facebook и Одноклассники. Настоящая социальная сеть – это теоретическая конструкция, состоящая из агентов и связей между ними. Понятие возникло в рамках развития теории малых групп, антропологии и биологии независимо в 60-х годах прошлого века. В английском языке Facebook, Twitter, MySpace и т. д. – это "онлайн социальные сервисы" или "сервисы социального взаимодействия" (англ. "Social networking service"), и это более корректные термины.

Сервис или веб-служба, веб-сервис (англ. "web service") — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами (здесь соглашусь с Википедией). Как правило, имеет четкое и ограниченное назначение, может использоваться как непосредственно из браузеров, так и через открытые программные интерфейсы другими приложениями.

Блог-площадка – веб-сервис, позволяющий размещать блоги и управлять ими.

Социальный сервис или онлайн социальный сервис – веб-сервис, предоставляющий различные возможности по управлению социальными сетями и одновременно выступающий в качестве блог-площадки. В зависимости от реализации конкретный набор возможностей может быть различен: в LiveJournal менее выражена социальная составляющая, а в LinkedIn – блог-составляющая. Facebook, Twitter, ВКонтакте, Одноклассники и даже YouTube – это социальные сервисы (последний можно отнести к сервису видео-хостинга, но, на самом деле, он имеет все составляющие социального сервиса: профили, подписки и т. д.). Социальные сети разных пользователей пересекаются, в рамках сервиса действует унифицированная форма представления сетей, как правило, имеется открытый программный интерфейс (разной степени открытости) для извлечения из социального сервиса информации (с различными, меняющимися от сервиса к сервису ограничениями: в частности, социальный сервис LinkedIn устанавливает ограничения на характер информации о связях, которую можно извлечь посредством открытого интерфейса, причем ограничения носят как юридический, так и технический характер).

Социальные медиа – в описании на Википедии дается классификация, с которой я склонен согласиться с определенными оговорками. Социальные медиа - вид массовой коммуникации, обобщенное название с точки зрения содержания информации, размещаемой пользователями:

• для социальных сервисов;
• блогов и микроблогов;
• форумов;
• сайтов отзывов (хотя, по сути, это те же форумы, где пользователь дополнительно может дать оценку интересующему товару / услуге, но он может дать эту оценку и без комментария);
• фото и видеохостингов;
• сайтов знакомств;
• геосоциальных сервисов (предоставляющих пользователям "отметиться" в том или ином месте на карте, заведении и т. д.).

Почему важно уточнить приведенные выше понятия? На это есть несколько причин:

1. Таким образом формируется представление о двух видах деятельности организации в Интернете: работ по созданию, публикации, продвижению контента, поисковой оптимизации, опросам общественного мнения и т. д. – с одной стороны, и работ по развитию социальной сети – с другой, и только совокупная системная работа по обоим направлениям может давать ожидаемые и позитивные плоды в рамках информационной деятельности.
2. Это позволяет выполнить декомпозицию задачи информационной деятельности в Интернете, поскольку указанные области пересекаются, взаимодействуют, но не совпадают, в них применяются разные методы из разных областей науки, разные критерии оценки эффективности.
3. Помимо прочего, расхожие определения отражают взгляд на определяемые феномены, системы с точки зрения пользователей - авторов публикаций, поставщиков информации, читателей, либо сервисов. Данные же мною определения отражают парадигму анализа данных - это взгляд человека, который должен извлекать информацию и подвергать ее анализу.

В нормативных документах, посвященных информационной деятельности МЧС, встречается еще несколько терминов без определения, в частности "топовые блоггеры", но, к сожалению, ни тогда, ни сейчас я не могу их определить – это вопросы, которые могут стать темой дальнейшего исследования, поскольку здесь требуются специфические методики оценки "топовости" в зависимости от целей использования "блоггеров", которые еще тоже предстоит уточнить.

Я снял несколько видео, где рассказываю про указанную научно-исследовательскую работу, так что, если будет интерес, милости прошу. :)

Рассказы об анализе: Почему? Открытие второе

Это уже из области практики. Недавно разрабатывали методику прогнозирования синергетических чрезвычайных ситуаций. Смысл задачи таков: существует объект, на котором могут происходить различные аварии, приводящие к ущербу. Сценарии возможных аварий определены и зафиксированы в декларации безопасности объекта, вместе с такими параметрами, как вероятность возникновения инициирующих событий (брешь в резервуаре, наличие источника возгорания и т. д.) и ущерб, определенный по моделям, соответствующим характеру аварии (разлив вещества, пожар, взрыв и т. д.). Также известно, какие неблагоприятные природные явления могут возникать в данной местности и как часто (аномальный холод или жара наводнение, землетрясение и т. п.). Проблема в том, что в нынешнем виде вся эта информация существует по отдельности, а это неправильно – нужно учитывать взаимодействие всех факторов.

Кратко изложу свой подход к решению задачи. Возьмем, к примеру, аномальную жару. Она, очевидно, может повлиять на давление в резервуаре с веществом, как следствие, на вероятность трещины в резервуаре и вероятность аварии. Но это еще не все: та же аномальная жара вполне может повлиять на радиус зоны распространения физических параметров аварии, мощность взрыва, скорость испарения ядовитых веществ. Кроме того, необходимо учитывать и эффект домино или каскадный эффект: одна авария может привести к другой, та к третьей и так далее. Иными словами, если происходит первая авария, нужно понимать, куда бежать, а бежать нужно не только к уже взорвавшемуся агрегату, чтобы ее ликвидировать, но, возможно, и к тому агрегату, который, согласно расчетам, имеет наибольшую вероятность взорваться третьим в цепочке и/или нанести при взрыве максимальный ущерб. Почему третьим, а не вторым? Потому что возможно, что второй агрегат имеет настолько большую вероятность взорваться после взрыва первого, что находиться рядом с ним опасно, или, наоборот, он имеет настолько ничтожную с точки зрения ущерба зону распространения физических параметров даже с учетом внешних природных и техногенных факторов, что о нем не стоит беспокоиться, сосредоточив усилия на агрегатах 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, программы построения статистических и других моделей, программы визуализации – это только на сегодняшний день, и это далеко не все.

Рассказы об анализе: Почему? Открытие первое

Почему я вообще взялся за эту область? Во-первых, у меня случился пару лет назад ренессанс лирических отношений с математикой и программированием, причиной которому послужило как раз открытие мною анализа данных. Для меня это было что-то совершенно новое: новый взгляд на казалось бы известные вещи, новые цели, комбинации методов, и наука, и не совсем наука. В общем, мне интересно этим заниматься и интересно об этом рассказывать. Кроме того, эта первая причина послужила толчком к парочке открытий, которые стали, соответственно, второй и третьей причинами.

За 11 лет работы в высшей школе мне часто приходилось слышать от студентов (математиков и математиков-программистов), что их учат непонятно чему, чему бы в тот момент их ни учили, да и когда я сам был студентом, меня посещали те же мысли. И вот, спустя годы, начав заниматься регрессионными моделями, кластеризацией и прочими штуками, я стал периодически ощущать дежавю. Кластеризация, метод ближнего/дальнего соседа? – Где-то это было. Проверка гипотез? – Да, у меня был «трояк» по математической статистике, но я что-то такое помню. Средний кратчайший путь в социальном графе? – Да, да, да… И в какой-то момент меня осенило: не то, чтобы учили не тому – учат не так!

Я как-то, еще на первом курсе спросил своего преподавателя по математическому анализу Михаила Семёновича Кильдюшова (дай ему Бог здоровья и долгих лет жизни) о правильной методике преподавания с его точки зрения. Он ответил:

Мне кажется, нужно идти от частного у общему и от общего снова к частному.

Я себе это представляю так:

1. Рассматриваем задачку, которую непонятно как решать, после чего решаем ее с помощью некоторого метода.
2. Подробно рассматриваем сам метод, чем расширяем границы его применимости.
3. Рассматриваем другие задачки, которые можно решать с его помощью.

Я когда-то взял за правило держать дома книги по всем областям математики и по всем технологиям, с которыми я работаю или может быть буду работать (в части технологий это была не самая умная моя идея: они устаревают). У меня есть книги по математическому, комплексному и функциональному анализу, топологии, методам оптимизации, квантовым полям и пр. и др., и, что интересно, только одна из них по характеру изложения полностью соответствует описанному выше принципу, остальные даже близко не приближаются.

Все или почти все книги по разделам математики (и, думаю, не только по ним), принадлежащие перу отечественных авторов, которые мне доводилось видеть (а это порядочно), написаны так, что их невозможно применять на практике. Они написаны фундаментальными математиками для фундаментальных математиков. Чтобы понять математическую статистику по такому труду, сначала нужно изучить том по теории вероятностей, а до него – пару томов по линейной алгебре и математическому анализу. Зачастую отсутствуют примеры практических задач. Недавно начал читать книжку по нечетким множествам. Прочитал 70 страниц, встретил один глупый пример про пирожок с нечеткой стоимостью, да и тот не был рассмотрен до конца, я уж молчу про его практическую ценность. Прочитал всю книгу, долго плевался от явных ошибок в формулах (стр. 9, первая страница основного содержания:

какое из двух высказываний «x не принадлежит A» или «x не принадлежит A» , является истинным, а какое ложным

(привет издательству «Питер»). В очередной раз убедился, что неопределенность можно формализовать, но так и не понял, что на практике со всем этим делать, когда применять, и что можно получить в результате (привет учебно-методическому объединению по «Прикладной информатике» на базе родного МЭСИ, которое рекомендовало эту книгу студентам, обеспечив гриф Министерства образования). А, между прочим, мне через неделю обрабатывать кучу анкет, где встречаются вопросы с открытым ответом. И что я должен делать?

Возможно, я выбираю не те книги, но это не отменяет того факта, что учили и меня, и моих студентов именно по ним! В итоге, чтобы применить что-то из изложенного таким образом на практике, я сначала должен держать в голову кучу голой, ни к чему не привязанной теории, а потом еще изогнуть мозг таким образом, чтобы решить с ее помощью что-то, при полном отсутствии практического опыта.

Это был один полюс. Второй полюс – это «книги рецептов», где рассматриваются исключительно практические примеры. Если книгам первого типа не хватает реализации пунктов 1 и 3 из рассмотренного выше подхода, то книгам второго типа не достает содержания по пункту 2 – описания метода. В результате, если твоя задачка слегка или даже сильно похожа на рассматриваемую в таком «кулинарном справочнике», это еще отнюдь не гарантирует, что ты с его помощью свою задачку сможешь решить: нюансы, которыми твоя задача отличается от примера, могут быть критичными для используемого в книге метода, нивелирующими возможность или обоснованность его применения.

Истина, как обычно, лежит где-то посередине, между этими двумя полюсами, и там очень мало российских математических книг. Зато, что интересно, там очень много книг по программированию. Правда, лучшие и наиболее известные книги по программированию они, как бы, традиционно не отечественные (прошу прощения у российских авторов), как и соответствующие технологии. Зато разница в методологии изложения и результат обучения по фундаментальным математическим и программистским книгам лично для меня очевидны: сложный математический метод, применение которого представлено в виде программы на императивном языке программирования я способен понять, если не «влёт», то за конечное время, а вот если он расписан формулами… В общем, в последнее время и по математике я предпочитаю книги от зарубежных авторов.

Причем здесь анализ данных? Все очень просто: суть анализа данных в получении результата, но необходимость количественно оценивать свою уверенность в этом результате дополнительно требует и определенной теоретической подготовки (например, нужно понимать, корректировать ли результаты множественной проверки гипотез или нет, чем различаются разные варианты такой коррекции). То есть в рамках анализа данных мы совмещаем теорию и практику, причем это может быть теория откуда угодно и практика откуда угодно, и мы берем от теории все необходимое, но только необходимое, которое мы можем получить, опять-таки, откуда угодно (из фундаментальной, практической книги, из Интернета и т. д.). К примеру, один из методов фильтрации данных заключается в применении преобразования Фурье с последующей фильтрацией данных в их частотном представлении и обратным преобразованием. Этот метод появился давно и призван был решать проблемы, связанные с радарами и сонарами. Мы можем применять его к другим данным, не задумываясь о радарах, доказательствах теорем и физике волн, но должны представлять себе границы применимости метода. Итого, в анализе данных мы берем отовсюду столько, сколько нужно, но не больше – этим он мне и нравится, мне кажется, что он представляет собой выход из «фундаментального тупика», в котором оказываются многие люди, которые 5 лет учили математику, а теперь не могут решить ни одной практической задачи за границами 4-ех действий арифметики.

Рассказы об анализе: суть анализа данных (моя версия)

Пользуясь подсказкой Влада, я решил начать эту рубрику. Посты, как обычно, будут весьма нерегулярными,чаще всего практически ориентированными, и если будет написана какая-то чушь, то все 10-15 читателей моего блога смогут мне об этом сказать. :)

Существует много определений для понятия «анализ данных» (раз, два, три), но я бы свое сформулировал так: это сбор данных об объекте или процессе и/или трансформирование имеющихся или новых данных в форму, допускающую манипуляции ими с применением известных, модернизированных или новых математических методов с целью получения новой информации. Зачастую эта информация представляет собой ответ на некий вопрос относительно указанного объекта или процесса, и качество такого ответа (в частности, точность) может быть оценена количественно.

Последнее замечание относительно оценки качества результата мне кажется чертовски важным и часто упускаемым из виду. Когда «аналитики» с экрана телевизора говорят о скором росте цен на золото или о скором их падении, они никак не характеризуют степень уверенности в своих заключениях – это «угадайка», «шаманство», «догадки», но не результат анализа данных. На самом деле, такие заявления заслуживают даже меньше доверия, чем прогноз по поводу встречи со слоном на Кутузовском проспекте в Москве из известной истории («Шанс встретить слона на Кутузовском проспекте составляет 1 к 2: можно встретить, а можно не встретить»), потому что, на самом деле, любая оценка лучше, чем никакая. Здесь нужно оговориться, что наличием «практически никакой» оценки далеко не всегда можно оправдать отсутствие усилий по вычислению оценок более точных. Это касается как самого прогноза («Насколько широк интервал, в котором, согласно прогнозу, будет колебаться значение интересующего нас параметра?»), так и оценки качества этого прогноза («Насколько в процентном исчислении мы уверены, что интервал будет именно таким?»). Это очень важный момент, и я к нему еще вернусь.

Я сам писал и пишу много статей, в которых даю пространные комментарии, основанные на интуиции или своих пристрастиях, но они касаются содержания таких вопросов, как тенденции развития информационного общества, компьютерных игр, образования, перспектив той или иной технологии, опасностей, которые могут быть с нею связаны, и так далее – речь идет о качественных характеристиках объектов или процессов. К цифрам я в этих случаях не притрагиваюсь, и всегда оговариваюсь: «мне кажется», «вполне возможно», да и целью этих работ является, скорее, не выяснение чего-то конкретного, а наведение на мысли, попытки разобраться в различных содержательных и философских аспектах вопросов, может быть что-то изменить в подходах других людей, если они захотят меня услышать и со мной согласятся, в течении процессов. Это не является анализом данных – анализ данных таких целей не преследует, их может преследовать тот, кто будет использовать результаты анализа данных. Поговорить за жизнь – дело очень хорошее, когда есть что сказать, хочется поделиться мнением или опытом, который в цифрах не выразишь, но нужно разграничивать ситуации и предметы, в отношении которых такие разговоры уместны и не уместны. Что касается биржевых аналитиков, то, как говаривал мой преподаватель в этой области, «многие из них делают деньги на заявлениях, а не на самой торговле», так что в некотором роде им все равно.

Но вернемся к нашим баранам. Проще говоря, мы берем данные и крутим-вертим их в попытке понять, что происходит с объектом, что от чего зависит, как поведет себя процесс в дальнейшем, при других обстоятельствах и т. д., причем, получив некий результат, мы можем сказать, насколько мы в нем уверены.
Если сравнивать это определение с любимым мною же определением модели: «A является моделью B, если A отвечает на вопросы относительно B», то можно заметить, что анализ данных сводится к построению последовательностей моделей:

исходный объект или процесс -> данные об объекте или процессе -> измененная форма данных -> метод манипуляции данными -> результат манипуляций с данными,

то есть, по сути, анализ данных есть также и разновидность моделирования. С такой трактовкой тоже не должно быть проблем: в конце концов, как говаривал мой научный руководитель, «дифференциальное исчисление – это тоже моделирование», да и в обыденной жизни мы всяких моделей от манекенов (модель человека) и google-карт (модель земной поверхности, территориального деления, инфраструктуры и прочего) до счетчиков водопотребления (модель процесса перетекания воды из одного места в другое), термометра (модель изменения окружающей среды) и телевизионного изображений (модель реальности в отдельно взятом месте, в отдельно взятый период времени, если речь идет о репортаже, или модель человеческих взаимоотношений, если речь идет о телесериале для женщин – в этом случае это также модель сценария сериала, а также, возможно, событий из жизни каких-то реальных людей) используем сотни и тысячи и не задумываемся. Правда, что касается анализа данных, то в данном случае задуматься придется (в том числе мне), потому что эта работа скорее о том, как его выполнять (и не выполнять) в разных случаях, а не о том, как использовать его результаты.

Для определения места анализа данных или, в более широком смысле, науки о данных в системе наук и профессиональных занятий, часто приводят диаграмму Венна, разработанную Дрю Конвэем (Drew Conway). В переведенном на русский язык варианте она изображена ниже. Здесь я позволяю себе некоторое упрощение, считая анализ данных и науку о данных эквивалентными понятиями. В общем случае это неверно. Скажем, задача разработки или выбора эффективной технологии хранения тех или иных данных (например, разработки базы данных) не составляет цель анализа данных. Однако эта задача из области науки о данных, и для ее решения на каком-то этапе неизбежно возникнет необходимость применения и анализа, являющегося частью этой науки.

Диаграмма Конвэя дает представление о том, сколько всего нужно знать, чтобы быть грамотным аналитиком, о том, что без математики не обойтись, и о смежных областях, но не отвечает на вопрос о том, что же составляет ядро самой работы по анализу данных, что он представляет собой как процесс. Чтобы ответить на этот вопрос, я предлагаю свою диаграмму.

Я не нашел изображение черепахи, но «мировой бобёр» в данном случае подходит даже лучше, поскольку он трудолюбив, много чего грызет, и совсем не так медлителен. Бобёр – это Вопрос. Если нет бобра, то не нужно ничего делать, ничего анализировать. Вопрос возникает в некоторой предметной области (нередки и вопросы, актуальные для нескольких областей), которая в свою очередь является частью мирового информационного пространства (или океана). Если Вопрос возник, и мы предполагаем, что можно получить ответ на него с помощью анализа данных, то для начала работы нам необходимо три вещи:

• Идея – что, собственно, можно и нужно сделать. Идея может быть общей, например, в виде концептуальной модели или совершенно конкретной в виде метода, который мы собираемся применить (построение модели линейной регрессии, кластеризация по методу дальнего соседа, случайный лес и т. д.). Идея уточняется по ходу работы.
• Данные – то, чем предполагается оперировать. Данные нужно предварительно получить и трансформировать в какую-то пригодную для обработки форму.
• Инструмент – то, с помощью чего можно применить Идею к Данным (бумага и ручка, калькулятор, программное обеспечение для математических расчетов, визуализации, вычислительный кластер для обработки больших данных и т. д.).

Слоны на рисунке не просто так стоят вразнобой. Процесс анализа данных может начаться с любого из указанных выше аспектов, они могут иметь разный вес и значение в ходе работы и влиять друг на друга всевозможными способами:

• Иногда вне зависимости от характера и сложности Вопроса аналитики ограничены определенным набором Инструментов (например, только свободным программным обеспечением или теми продуктами, которыми они владеют), что в свою очередь вводит ограничения на Идею.
• То же самое можно сказать и о Данных: вполне может оказаться, что задачу надо решить, имея весьма небольшой набор весьма неполных Данных непонятно как полученных, что вводит дополнительные ограничения на Идеи.
• Если Данные нужно еще собрать (например, из социальных сервисов), то потребуются дополнительные Инструменты. Они также потребуются, если окажется, что Данных слишком много, или что вычисления, согласно Идее, слишком масштабны.
• Использование выбранных Инструментов для воплощения Идеи, то есть применения ее к Данным, может дать неудовлетворительный результат. В этом случае придется искать новые Идеи, Инструменты и/или Данные и т. д.

Даже сам Вопрос может, на самом деле, проистекать не из потребностей в предметной области, а из Идеи («А что будет, если… ?»), Данных («Что бы нам с этим сделать?») или Инструмента («Куда бы нам это применить?»). Первый случай весьма распространен в форме научных изысканий, остальные два сомнительны с точки зрения конструктивности и вызывают дополнительные вопросы из другой сферы («Зачем мы купили эту базу данных / этот программный продукт?»).
По указанным причинам нельзя выстроить работу по анализу данных в виде четкой последовательности шагов, неизменной для всех случаев, но мы рассматривали аспекты, а не шаги, и эти аспекты позволяют достаточно четко представить, с чем придется иметь дело в каждом проекте по анализу данных.

Обучение безошибочности: 25 самых опасных программных ошибок и метод "подари другу грабли"!

25 февраля обновился список наиболее опасных программных ошибок (их тоже 25), публикуемый Институтом SANS и MITRE. Это весьма полезный документ для программистов (которые могут отобрать те ошибки, которые наиболее "близки" к выполняемой ими работе), для исследователей (поскольку ошибки ранжированы по уровню опасности и частоте обнаружения), для преподавателей (которым нужно каким-то образом заставить нынешних студентов не допускать этих ошибок или, хотя бы, помнить о них) и для любых других категорий специалистов. Бесполезен он только для пользователей, которым просто следует быть бдительными. Им, вообще, проще всего, но не потому, что бдительность что-то гарантирует, а потому что больше они ничего не могут сделать (работает принцип: "Сделай, что сможешь, и будь, что будет!").

Все ошибки, вошедшие в список, можно условно разделить на три категории по тому человеческому качеству, на котором они паразитируют: "Доверчивость" (например, к этой категории относится ошибка CWE-601: URL Redirection to Untrusted Site ("Open Redirect")), "Неаккуратность" (CWE-120: Buffer Copy without Checking Size of Input - классика жанра) и "Ложное ощущение защищенности" (CWE-327: Use of a Broken or Risky Cryptographic Algorithm). Я не буду их подробно рассматривать - в самом документе все очень хорошо разложено по полочкам, присутствуют подобающие метафоры и даже легкий юмор. Есть другой вопрос по теме блога: а можно ли научить будущих программистов не допускать промахов, которые впоследствии во время их трудовой деятельности могут вылиться в крупные неприятности?

Рассмотрим некоторые методы обучения:

• "Ребята, бывают вот такие ошибки, их допускать не надо"! Конструктивно? - Ни разу!
• "Ребята, представим себе, что это - настоящий сайт с ценной информацией. А вот так он ломается". Альтернативно: "Попробуйте его сломать". Чуть более захватывающе, но как только появляется слово "представим себе" - эффективность улетучивается. Дело опять в пресловутой разнице между теорией, учебной и реальной практикой. Я много раз говорил, что негативная роль этой разницы не так однозначна, чтобы с ней тотально бороться, но вот здесь тот случай, когда определенные вещи и отдельные характеристики modus operandi можно и нужно вбить в головы. Вымышленное злодейство на вымышленном сайте для этого не годится.
• "Ребята, вот сайт IBM (Microsoft, Google, Рамблер, Yandex, Gametrailers - добавить по вкусу). А вот так он ломается"! Еще более захватывающе и более продуктивно, но... грозит.

По моему мнению, в обучении делать что-то правильно или не делать чего-то неправильно лучше всего работают страх и унижение (в разумных пределах). Дух соревнования тоже работает, хотя его значение часто переоценивают (здесь все зависит от темперамента соревнующихся, а также о того, не имеет ли кто-нибудь из них тенденцию к переходу в защитную стойку: "Я все равно лучше всех, и я это знаю"). Поэтому мне кажется, что оптимальным вариантом является следующий: студенты ломают сайты друг-друга, но в организованной академической манере. Скажем, параллельно преподаются две дисциплины "Разработка веб-сайтов" и "Информационная безопасность" (или "Безопасное кодирование" и "Испытания ПО" - как угодно). У группы студентов №1 первую половину семестра идет только "Разработка веб-сайтов", где они занимаются соответствующей деятельностью, а у группы №2 - "Информационная безопасность", где они изучают теорию и ломают сайты созданные студентами из группы №1. Каждую неделю проводятся совместные занятия, когда все студенты встречаются и "делятся впечатлениями". Во второй половине семестра группы "меняются дисциплинами".

Идея здесь проста:

• если вам просто что-то рассказывают, вы быстро это забудете и вспомните только тогда, когда "грянет гром", возможно, уже будучи ответственным за ценную информацию;
• если при обучении вам что-то показывают, но вы сознаете искусственность ситуации в некоторых ее деталях ("представим себе, что это сайт с ценной информацией"), то это ощущение искусственности, скорее всего, расползется на всю проблемную ситуацию ("в реальной жизни такого не бывает");
• если даже ваш настоящий, ценный сайт ломает преподаватель, то это не дает должного эффекта, потому что а) скорее всего, он будет ломать "аккуратно" и б) предполагается (как минимум de jure), что преподаватель должен быть большим умельцем, чем вы;
• если ваш выстраданный сайт о маргаритках, за который вы грезили получить "отлично", накануне перед сдачей забил нецензурной бранью некий Сеня Батарейкин из параллельной группы (о существовании которого вы вообще лишь смутно догадывались), предварительно выпив пива... этого вы не забудете никогда!

Спору нет, метод рискованный: возможны конфликты, возможны жалобы и непонимание. С другой стороны, это сработает, а именно это и только это иногда и требуется.

Семь шапок из овцы: теория и практика в образовании, кто настоящий клиент вуза?

Не могу сказать точно, почему "вожжа попала мне под хвост" именно сей момент. Видимо на днях я краем глаза натыкался на очередную статью из области "максимальное приближение процесса обучения студента в вузе к будущей практической деятельности".

Вспомнить: сколько всего на эту тему уже написано было, чего только к этому не приплетали, включая технопарки и прочее. Согласен, есть позитивные результаты, далеко не всегда соответствующие декларируемым целям, но, по-моему, достижений куда меньше, чем деклараций.

Задумался: мы так привыкли слышать про необходимость вот этой спайки теории и практики, про ужасы отрыва первой от второй, про беды и нечеловеческие усилия компаний-работодателей по переучиванию новоиспеченных специалистов, что, кажется, уже несколько оторвались в этом страхе и потугах от здравого смысла. Моя мама заканчивала МИТХТ по специальности "Общая технология резины" с квалификацией химик-технолог. Вряд ли она могла подумать в процессе обучения, что ей предстоит попасть по распределению в СоюзГлавРезинСнабСбыт (я не забуду это название никогда), а затем в ГосСнаб и всю жизнь работать, по сути, экономистом. Вряд ли ее кто-то плановой экономике в вузе по ее специальности сильно учил, но проблем не возникало. А сегодня-то что изменилось?

Примерно семь лет назад (цитирую глубоко уважаемого мною А.В.Хорошилова бывшего тогда первым проректором МЭСИ по статье "Система управления знаниями в Образовательном научно-производственном комплексе МЭСИ" в кн.: 6-я Российская научно-практическая конференция "Реинжиниринг бизнес-процессов на основе современных информационных технологий. Системы управления знаниями". / Сборник научных трудов. - М.: МЭСИ, 2002.):

Сегодня обществу необходимы профессионалы не узкого, а широкого профиля...

А вот в "нынешнем" сегодня, судя по всему, "уже опять" все наоборот.

Я прекрасно понимаю, что когда у вуза тесные связи с определенным крупным работодателем, потребляющим большую часть выходящих из вуза кадров, сближение вуза с работодателем, теории с практикой и логично, и осуществимо причем без лозунгов - просто студенты, становясь выпускниками, переходят из-за учебного рабочего места на реальное. Но в повсеместную идею-фикс превращать сие стремление необоснованно, особенно когда X, то есть вуз, известен, а Y, то есть работодатель, - нет.

С чего вообще взято, что отличие теории/обучения от практики - это большая беда? Еще Ганс Юрген Айзенк весьма здраво высказывался по этому поводу (Айзенк Г.Ю. Психология: польза и вред. Психология: смысл и бессмыслица. Психология: факты и вымысел. - Мн.: Харвест, 2003.), говоря о том, что практик должен обязательно дать решение к предложенной задаче, причем за ограниченный промежуток времени, тогда как у теоретика/ученого время не слишком ограничено, и ответом к задаче может быть отсутствие такового. Видите? Как бы вы ни приближали теорию к практике - все равно не превратите одно в другое.

Есть, конечно, разные специальности/направления и, возможно, что практические занятия студента при обучении попросту будут совпадать с тем, что ему придется делать после ее завершения. Однако, например, в случае обучения программистов, невозможно научить человека писать именно те программы, которые он будет писать в будущем. Подчеркиваю: сейчас у нас настоящее, а будущее будет потом.

Сумятицы добавляют и сами работодатели: в отрасли ИТ (которая мне ближе всего), много активно развивающихся небольших и средних компаний, которые появились уже после того, как нынешние студенты стали студентами, и эти компании не всегда верят в то, что просуществуют до момента становления нынешних студентов в качестве специалистов. Именно небольшие компании чаще всего и предъявляют претензии к несоответствию выпускников их требованиям, но одновременно, если их разговорить (что получается не часто, но получается) сообщают о том, что им невыгодно и неинтересно сопровождать студентов пять лет в процессе обучения. Я сам (в качестве декана факультета) пытался нескольких специалистов уговорить почитать лекции и провести практические занятия - результат чаще был неудовлетворительным, что и понятно - им не до этого, они еще не понимают ценности воспитания кадров, хотя уже жалуются на их "неформатность". Крупные компании, например, жаловались реже - они уже привыкли, у них есть свои учебные центры, свои отделы и департаменты обучения, своя образовательная инфраструктура, дотягивающая "специалистов широкого профиля" до профиля, укладывающегося в формат компании. Тогда вопрос, кто в вузе должен приближать обучение к реальной деятельности? Преподаватели без помощи тех самых работодателей? Так процентов 50% из этих преподавателей никогда за стенами вуза не работали (я сам таким был, так что ругаться могу смело), о существовании других работодателей (окромя родного вуза) они лишь догадываются, либо принимают на веру рассказы друзей.

Еще один момент во всем этом связан с тем, кого вуз реально считает своим клиентом? Студента? Работодателя? В Советские годы таких вопросов не возникало, а сегодня он ой как остро стоит! Должен ли я готовить студента для работы у конкретного работодателя, если неизвестно, хочет ли студент у него работать? Должен ли я, прежде всего, угождать работодателю, если учесть, что платит мне, вообще-то студент?

Чтобы завязать с философией, расскажу, как я поступал. Я считал клиентом студента. Я всегда опирался на непреложное правило: функция декана и деканата - обучение и защита студента от всего в стремлении дать ему:

• достаточно знаний для самоопределения в смысле будущего направления работы;
• систему, в которую можно уложить все приобретенные знания, умения и навыки, а также те, что он приобретет в будущем;
• повод гордиться и чувство гордости за свою профессию.

Теперь о том, как это делалось. Чтобы получить образованного и компетентного специалиста, который сам сможет решать, какой род деятельности (или область) ему ближе и преуспеть в нем (в ней), нужна широта охвата знаний и глубина. Очевидно, что и то, и другое одновременно недостижимо в рамках учебного плана, поэтому я делал так: общие дисциплины должны были максимально широко охватывать отрасль, а дисциплины разных специализаций максимально уходить в глубину. Сами специализации выбирались по стратегии следования за трендами отрасли: в 2001-2003 годах были популярны: веб-программирование (сейчас студенты и сами этому быстро учатся), идеи искусственного интеллекта, компьютерная графика и прочее, чуть позже - мобильные приложения и Unix, еще позже - антивирусная борьба и интегративные решения. Насколько я был прав или неправ - это у моих бывших студентов нужно спросить (всем им привет, если кто увидит это сообщение).

Вот и все. Здравый смысл. В образовании развелось много лозунгов, которые, похоже, еще и ротируются периодически. Помните еще одну идею-фикс: всеобщее образовательное пространство на базе дистанционного образования (ДО), где разные вузы обмениваются компонентами учебных курсов между собой? Сколько лет назад это было? Что мы, в основном, видим сегодня? Не знаю, что видите вы, но я виду, что электронный курс в вузе может разрабатываться год - в корпоративном обучении при наличии сырого материала весь процесс от его компоновки до получения результата в виде готового пакета с курсом (например, в стандарте SCORM одной из версий), через вычитку, верстку, вторую вычитку, составление тестов и прочие стадии может завершиться за два дня. Множество вузов использует нестандартные "home-made" (доморощенные) системы ДО, не отвечающие никаким стандартам. Обо всяких там обменах наиболее продвинутыми частями курсов между продвинутыми вузами речи не идет. Почему? Идея опережала время? Да ничего подобного! Просто когда вуз говорит, что он "хочет влиться в единое образовательное пространство, да еще и обеспечить академическую мобильность студентов", он на самом деле думает "студенты мои, а в смысле пространства - нужно взять лучшее и ничего не отдать". Какое сотрудничество во время демографического и экономического кризиса? Тут бы бюджетные места заполнить, и еще как-то доходы сохранить.

Зато, пока суть да дело, идея и без вузов давно реализовалась:

Кому нужны университеты, когда у нас есть Google? Все переведенные в цифровую форму знания мира доступны нам в поиске. Мы можем соединить тех, кто хочет знать, с теми, кто знает. Связать студентов с лучшими учителями (которые сами могут быть студентами). Найти экспертов по любой теме. - Джефф Джарвис (Джарвис Дж. Что сделал бы Google? - М.: Аквамариновая Книга, 2009.)

Вот так-то. Есть реалии, а есть заезженные квази-великие псевдо-цели и вымыслы. Вуз (любой), услышь меня:

• Определи, кто твой клиент.
• Определи, что ты можешь ему дать, и как это лучше всего сделать.
• Делай это... или умри! Хватит лозунгов - давайте работать.