Прогнозирование

Почему люди так плохо прогнозируют будущее

21.06.2021 10:15:25 |

Автор: admin

Взгляд на наше космическое будущее из 1970-х годов

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

В те времена в ЮАР царила политика апартеида. Так вот, примерно 65% африканцев и 80% потомков индейцев предсказали социальные и политические изменения, равносильные концу апартеида. С другой стороны, только 4% белых граждан высказали такое мнение. Откуда различие? Всё просто.

Кого устраивает существующее положение вещей тот не верит в будущие изменения, хотя эти изменения очевидны для остальных. Результаты опубликованы в научной статье Идеология и утопия в Южной Африке. Методологический вклад в социологию знания", British Journal of Sociology, 14, 5976 (1963).

Проблема футурологии нереалистичный оптимизм.

Оптимизм и реальность плохо совместимы

Психологические исследования действительно подтверждают, что чем более желанным является будущее событие, тем более вероятным люди его считают: есть явная корреляция между ожидаемыми и желаемыми событиями, см. работу Прогнозирование изменений окружающей среды: снова исполнение желаний, European Journal of Social Psychology, Volume 5, Issue 3, 315-322.

На президентских выборах в США в период с 1952 по 1980 годы около 80% сторонников каждого из кандидатов ожидали, что их любимый кандидат победит в соотношении примерно четыре к одному (Когда пророчество не сбывается. Связь предпочтений и ожиданий на президентских выборах в США, 19521960 гг., Journal of Personality and Social Psychology, 45(3), 477491). Мы снова видим тот же эффект.

Люди искажают своё восприятие близких выборов таким образом, чтобы оно соответствовало их предпочтениям, говорится в более поздней работе тех же учёных.

И наоборот, чем больше страх результата, тем реже его предвидят. В ноябре 2007 года экономисты, участвующие в опросе профессиональных прогнозистов Федеральной резервной системы Филадельфии, предсказывали лишь 20-процентную вероятность отрицательного роста (так называется спад в экономической терминологии) экономики США в 2008 году, несмотря на видимые сигналы надвигающейся рецессии.

Фьючерсы на сырьё всегда выше реальных цен. Источник: Факты и фантазии о товарных фьючерсах десять лет спустя, 25 мая 2015 года, doi: 2139/ssrn.2610772

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

В прогнозировании будущего этот феномен называется нереалистичный оптимизм. В научной литературе его впервые описал Нил Вайнштейн из Ратгерского университета в работе 1980 года (Journal of Personality and Social Psychology, 1980, Vol. 39, No. 5, 806820).

Без особой причины он попросил испытуемых оценить вероятность того, что они столкнутся с определёнными негативными событиями в будущем, такими как развод, увольнение или ограбление. И внезапно оказалось, что все люди оценивают свои шансы ниже среднего. Люди искренне верят, что вероятность заболевания, травмы, развода, смерти и других неблагоприятных событий для них ниже, чем для других людей, даже если они подвержены тем же факторам риска. А вот вероятность положительных событий для себя оценивается выше среднего.

Нереалистичный оптимизм относительно будущих событий в жизни. Статья Вайнштейна, 1980

Беспокойство подсознательно влияет на прогнозы. Например, люди могут неосознанно собирать и анализировать только те факты, которые подтверждают желаемый результат: это показывают исследования в соцсетях перед президентскими выборами. Данный процесс может быть даже биологически укоренён. Исследования в области нейронауки показывают, что факты, подтверждающие желаемый вывод, легче откладываются в памяти, чем такая же важная, но менее привлекательная информация.

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

Люди не хотят верить негативным прогнозам даже когда сталкиваются с объективной информацией (Предвзятость оптимизма, Тали Шарот, TED2012, рус. яз.).

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

Для примера:

Будущее, в которое хочется верить

Бессмертие человека

Цифровое копирование мозга, добавление и удаление воспоминаний, знаний, навыков

Излечение болезней на молекулярном уровне

Колонизация Марса, затем Солнечной системы и ближайших систем

Демократическое мировое правительство

Будущее, в которое не хочется верить

Экологический кризис

Ядерная война

Самоликвидация человечества

Частные армии у корпораций и отдельных политиков

Взаимная ненависть социальных групп и народов

Деградация цивилизации до уровня Средневековья

Дальнейшее уменьшение объёма головного мозга сапиенсов

Невозможность выживания человеческих колоний за пределами Земли, только роботизированные миссии

Исходя из объективной реальности, научных данных и экстраполяции текущего курса человечества вторая группа прогнозов кажется более реальной (например, заметное уменьшение объёма головного мозга у сапиенсов началось около 2510тыс. лет назад, после перехода на сельское хозяйство, и продолжается сейчас; поэтому логично предположить продолжение тенденции это пункт7). Но оптимист отгоняет от себя мрачные мысли и старается больше думать о первой группе прогнозов. Серьёзные специалисты не будут слишком распространять идеи из второй группы их сочтут неприятными пессимистами и перестанут приглашать на лекции.

Твёрдые убеждения вторая проблема

Один из самых знаменитых футурологов Рэй Курцвейл. Он потерял отца в раннем возрасте, а теперь хранит все вещественные воспоминания о нём записи, заметки, фотографии, всего 50 коробок в хранилище в Массачусетсе, готовясь к своему предсказанию: к середине 2030-х годов мы сможем создавать аватары ушедших из жизни людей на основе всей оставленной ими информации.

Сам Курцвейл тоже готовится к бессмертию. Он принимает 90 добавок в день, регулярно сдаёт анализы крови и делает внутривенные инъекции, а последние два десятилетия работает с известным врачом Терри Гроссманом, чтобы остановить процесс старения. Но Курцвейл говорит, что это запасной план. На самом деле в 2030-е годы мозг человека подключится непосредственно к облаку для расширения сознания, а место живых органов в наших телах займут синтетические компоненты.

Исследования показывают интересный феномен. Чем дальше от нас событие по времени, например, смерть, тем более вероятен чрезмерный оптимизм (см. статью Источники предвзятости при прогнозировании будущих событий, Майкл Милберн, doi: 10.1016/0030-5073(78)90035-1). Более того, на предсказания в наибольшей степени влияет то, имеет ли данное событие жизненно важное личное значение для предсказателя.

Другой известный футуролог и писатель Марк Стивенсон отмечает, что люди, прогнозирующие будущее, становятся жертвами собственных предрассудков, желаний и жизненного опыта, которые часто отражаются в их прогнозах. Грубо говоря, примерно к 50 годам футурологи начинают предсказывать скорое изобретение таких технологий, как копирование разума и бессмертие.

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

Автор книги Суперпрогнозирование. Искусство и наука предсказания событий Филипп Тетлок из Пенсильванского университета изучил долгосрочные прогнозы 284 политических экспертов в 19842004 годы и зафиксировал точность их прогнозов.

Он обнаружил, что экспертов можно разделить на две большие категории. Первую он назвал ёжиками.

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

Но когда все предсказания были сложены и оценены, ежи уступили второй категории лисам. Это полная противоположность ежей. Они дают сложные советы и скептически относятся даже к собственным предсказаниям. Тетлок также обнаружил, что у лис меньше шансов стать знаменитыми, потому что сложные советы труднее объяснить в двух словах.

Например, в западной цивилизации укоренилась вера в прогресс идея о том, что человечество прогрессировало в прошлом, прогрессирует сейчас и продолжит прогрессировать в будущем. Эта вера исказила прогнозы относительно интернета. Мало кто предполагал, что интернет изменит цивилизацию к худшему в некоторых отношениях. Большинство предполагало, что изменения будут положительные, поскольку это соответствует идее постоянного прогресса. Так, в 2005 году только 32% интернет-экспертов согласились с мнением, что через десять лет большинство людей будут использовать интернет таким образом, чтобы отфильтровывать неприятную информацию, которая оспаривает их точку зрения на политические и социальные вопросы, так что политический консенсус станет невозможен.

Источник: Future of Internet, 2005 год

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

Если у человека есть твёрдые убеждения вроде веры в прогресс, то он искажает свои прогнозы таким образом, чтобы оказаться правым. Люди не любят ошибаться. Они предсказывают результаты, которые подтверждают их убеждения о мире: что демократия победит, что смерть это ненужная трагедия, что бог есть или его нет. Как только вы берёте на себя обязательства в отношении чего-либо, у вас появляется заинтересованность в результате, говорит Курцвейл. Твёрдые убеждения становятся корыстными убеждениями.

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

Ещё один интересный факт: сканы мозга показали, что человек принимает решение в среднем за 10 секунд до того, как осознаёт это дополнительный аргумент против бесстрастности решений и прогнозов.

Декодирование принятых решений до и после их осознания. Источник: Бессознательные детерминанты свободных решений в человеческом мозге, June 2008, Nature Neuroscience 11(5):543-5, doi: 10.1038/nn.2112

Что же получается

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

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

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

Учёным досталась самая грязная работа, Им приходится снимать розовые очки и заглядывать в страшную мглу реальности, отказываясь от личной точки зрения, убеждений и предпочтений

Иногда оптимистичные предсказания специалистов действительно сбываются, как это произошло с развалом системы апартеида в ЮАР. Но обычно излишний оптимизм всё-таки мешает в жизни: люди не делают прививки (меня это не коснётся), не ходят на регулярные медицинские осмотры (со мной всё будет хорошо), не пишут завещаний (я буду жить долго), покупают маленькие квартиры (нам этого пока хватит), берут кредиты, делают инвестиции, начинают бизнес, много работают (жизнь долгая, ещё успею отдохнуть) и впоследствии страдают из-за своего чрезмерного оптимизма.

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

На правах рекламы

VDSina предлагает облачные серверы с посуточной оплатой. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки.

Подписывайтесь на наш чат в Telegram.

Подробнее..

Категории: Мозг , Научно-популярное , Будущее здесь , Психология , Научная фантастика , Будущее , Прогнозирование , Социология , Бессмертие , Блог компании vdsina.ru , Нереалистичный оптимизм , Предвзятость подтверждения , Проекционная предвзятость , Твёрдые убеждения

Перевод Оптимизация платежей в Dropbox при помощи машинного обучения

19.06.2021 16:06:42 |

Автор: admin

Представьте ситуацию: вам нужно воспользоваться оплаченным (как вы думаете) сервисом и вдруг оказывается, что он отключен за неуплату. Такая неприятность портит впечатление от бренда, снижая поток прибыли, а внезапно отключенный клиент может не вернуться к сервису. К старту курса о глубоком и машинном обучении делимся переводом о том, как эту проблему решили в Dropbox, где обнаружили, что внедрение ML в обработку клиентских платежей помогает пользователям оставаться довольными и работает лучше внедрённых за 14 лет политик биллинга.

Платежи в Dropbox

Платёжная платформа Dropbox управляет обработкой платежей миллионов наших клиентов. Когда клиент приходит на сайт и хочет оплатить один из наших продуктов, мы просим его ввести платёжные данные в форму оплаты. После отправки формы система собирает данные и вместе с суммой, которую мы хотим снять, безопасно отправляет их к одному из наших внешних партнёров, обрабатывающих платежи конкретного типа.

Всё это происходит за кулисами, когда пользователь Dropbox становится подписчиком. Как только платёж завершается и аккаунт становится платным, также пользователь вступает в платёжный жизненный цикл. Всё это от начала до конца обрабатывается нашей платёжной платформой.

Продление подписки и сбои

Обычно подписчики Dropbox платят за подписку ежемесячно или ежегодно. Если клиент дал нам полномочия снимать оплату, повторный платёж списывается с банковской карты клиента автоматически. Когда оплата проходит успешно, подписка продлевается без каких-либо действий со стороны пользователя.

Однако, если попытка оплаты не удалась, клиент оказывается в потоке, который мы называем сбой обновления. На этот случай у нас есть процедуры восстановления, которые пытаются предотвратить прерывание подписки.

Рисунок 1. Недобровольный отток происходит, когда истекает срок действия кредитной карты, или же она аннулирована, или на ней нет средств и т. д.

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Рисунок 2. Попытки обновления

Сбои в оплате могут произойти по ряду причин. Среди них:

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

Некоторые причины могут быть устранены сами по себе, другие для восстановления подписки требуют действий клиента.

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

Команда платежей должна была вручную разделить пользователей на группы в зависимости от их признаков типа подписки, географического местоположения и т. д., а затем выполнить A/B-тест наших десяти или около того различных жёстко закодированных наборов правил, чтобы определить, какие из них лучше всего подходят для этих признаков. Затем команда платежей сохраняла оптимальный вариант политики для этой группы выставления счетов по умолчанию. Периодически команда проводила повторное тестирование, чтобы узнать, изменились ли для разных пользователей лучшие решения.

С другой стороны, этот подход доказал, что момент оплаты влияет на её успех, это позволило Dropbox поддерживать большее количество постоянных подписчиков. Но со временем многие правила перестали работать и достигли потолка эффективности. Кроме того, ручное обновление этих правил сложный, трудоёмкий процесс.

В стремлении уменьшить непроизвольный отток и необходимый для его поддержания объем работы, команда платежей в партнёрстве с командой прикладного машинного обучения для оптимизации выставления счетов экспериментировала с ML.

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

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

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

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

Вначале мы сосредоточились на том, чтобы спрогнозировать, когда следует попробовать взимать плату, т. е. определить лучшее время для оплаты во время продления подписки, а также повторить попытку взимания платы с учётной записи во время сбоя обновления.

Эксперименты проводились с различными сегментами клиентов, а конкретно начиная с отдельных клиентов и команд в Северной Америке. Мы построили модель ранжирования с градиентным бустингом, обученную на таких признаках, как типы сбоев платежей, шаблоны использования учётной записи Dropbox и характеристики типа оплаты. Модель ранжирует попытки оплаты по прогнозируемой вероятности успеха для каждого окна оплаты.

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

Нашей целью всегда была сквозная оптимизация неудачных попыток обновления. Процесс начинался с единственной моделью, и этот факт помог подтвердить, что ML применимо к решению задач такого типа. Тем не менее мы быстро поняли, что шаблон проектирования с отдельной моделью для каждой попытки оплаты только создал более сложную систему. Например, если бы мы повторили попытку оплаты 5 раз, прежде чем платёж удался, то так получили бы 5 моделей. И это противоречило цели применения ML снижению сложности биллинговой системы.

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

Когда эксперименты только начинались, мы работали с платформой платежей, чтобы загрузить и запустить модели. Из-за добавленных зависимостей архитектура сильно раздулась. Задержки прогноза в среднем составляли около двух минут.

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

Белый цвет представляет компоненты платёжной платформы. Фиолетовым цветом обозначены компоненты системы машинного обучения

Получение прогноза о следующем лучшем времени списания средств. Когда попытка не удалась, платформа платежей, чтобы получить следующее лучшее время, запрашивает модуль Predict. Запрос выполняется с использованием идентификатора клиента и его типа.
Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.
Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.
Генерация прогноза. Модель возвращает ранжированное наилучшее время оплаты. Этот прогноз отправляется обратно в модуль Predict, в свою очередь, результаты в биллинговую политику.
Логирование результатов прогнозов. Модуль Predict, кроме прочего, логирует результаты прогнозирования модели, а также другую необходимую информацию, которая может использоваться для устранения неполадок и анализа.
Расписание следующего платежа. Как только сервис платежей получает наилучшее время списания средств, он учитывает это время при планировании следующей попытки оплаты и сохраняет в Edgestore.

ML-операции

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

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

Бизнес-метрики

Коэффициент одобрения счетов. Основная метрика, которую нужно улучшить. При каждом продлении подписки в Dropbox все платежи за продление отслеживаются как часть единого счёта. Эта метрика сообщает нам, было ли обновление подписки успешным.
Коэффициент успешности попыток. Эта метрика помогает отслеживать успешность каждой предпринятой от имени пользователя отдельной попытки оплаты. Может быть предпринята одна, две, четыре или более попыток. Этот показатель наряду с показателем утверждения счетов помогает отслеживать, как можно быстро продлить срок действия договора с клиентом.

Внутренний мониторинг модели

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

Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.
Количество сделанных моделью прогнозов: количество рекомендаций, которые модель успешно выполнила без каких-либо ошибок.
Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

Наряду с мониторингом и оповещением для платёжной платформы и сервиса Predict мы также отслеживаем следующее, чтобы определить, насколько хорошо работает инфраструктура:

свежесть и задержки в конвейерах данных признаков;
доступность и задержка сервиса Predict;
доступность EdgeStore.

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

Ответственность за мониторинг этих показателей разделена между командой инженеров по платежам и командой прикладного машинного обучения. У нас есть руководства по устранению неисправностей с чёткими путями эскалации, помогающие дежурным инженерам отладить любые проблемы. Поскольку ML был новым для команды инженеров по платежам, мы потратили время на объяснение принципов работы систем и интерпретацию результатов модели. Это помогло двум командам успешно сотрудничать в работе над проектом и обеспечить бесперебойную работу.

Дальнейшие шаги

Наши эксперименты подтвердили, что система на основе ML превосходит систему формальных правил. Более того, без ручного управления и больших инвестиций производительность основанной на правилах системы со временем снижается, тогда как система ML не ухудшает показатели благодаря новым циклам обучения. Можно и дальше совершенствовать модели, добавляя больше релевантных характеристик и экспериментируя с их различными архитектурами.

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

Здесь мы видим, что в вопросах формальных правил искусственный интеллект может превосходить естественный, а значит, специалисты в области ИИ будут всё более востребованы бизнесом. Если вы не хотите оставаться в стороне от этой бурно развивающийся сферы технологий, то можете обратить внимание на наш курс о машинном и глубоком обучении, где студенты не только создают работающие модели ML и глубокие нейронные сети, но и получают все необходимые специалистам теоретические знания.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы

ПРОФЕССИИ

КУРС

Подробнее..

Категории: It-инфраструктура , Оптимизация , Искусственный интеллект , Машинное обучение , Machine learning , Сервисы , Блог компании skillfactory , Оплата услуг , Архитектура , Прогнозирование , Биллинговые системы , Skillfactory , Оплата

Как мы разогнали команду QA, и что из этого получилось

22.10.2020 18:09:59 |

Автор: admin

Или как получить неочевидные последствия, если отказаться от команды тестирования.

Полтора года назад мы разрушили команду тестирования: отказались от регресса, передали E2E автотесты на Selenium в поддержку разработчикам и разошлись по командам, которые пилят фичи, чтобы предотвращать ошибки в зародыше. В розовых мечтах нам казалось, что так будет больше пользы: QA работают над качеством, тестирование начинается рано, а разработчики пишут автотесты сами и никто им не мешает.

Но ~~не фартануло~~ получилось не совсем так. Розовые мечты окрасились дополнительными оттенками: никто не думает о качестве, автотесты всё хуже, а у разработчиков без команды QA (~~внезапно~~) стало больше работы. Так проявились последствия второго порядка, к которым мы не были готовы. Сейчас мы их исправляем и можем рассказать, что это за последствия, как они возникают, какой урон наносят и как попробовать их предугадать, чтобы не было так больно.

Что такое последствия первого и второго порядка

У Рэя Далио в книге Принципы есть понятие последствия второго порядка. Это неочевидные следствия наших решений, которые мы часто не можем предугадать. Например, в 60-х годах 20-го века в Китае развернули войну с воробьями. Воробьи съедали зерно, и чтобы они перестали его есть, Китай открыл охоту на птиц. За время охоты китайцы массово убили почти два миллиарда птиц.

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

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

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

У нас была команда QA и мы её разогнали

Теперь расскажу, как мы ощутили на себе последствия и первого и второго порядка. У нас была уютная выделенная команда тестировщиков из 7 человек: 4 из них писали автотесты, а 3 тестировали вручную. Мы в какой-то момент решили разделиться и разойтись по командам. Почему?

Потому что разработчики получали обратную связь слишком поздно.

Баги находились на этапе, когда уже вся разработка закончена, всё интегрировано и нужно проверить, что продукт готов к релизу. Приёмочного тестирования не было, его выполняли аналитики-продакты у которых не было навыков тестирования. Кроме этого тестировщики и разработчики находились в разных мирах и мало взаимодействовали.

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

Гипотезу сначала решили проверить на себе экспериментом: покроем критические сценарии регресса автоматическими тестами и откажемся от ручного регресса. Если в результате опыта количество хотфиксов и откатов релиза не вырастет драматически, то можно считать эксперимент удачным. Так и случилось хотфиксов больше не стало. Решено расходимся.

Примечание. В компании есть продукт Ресторан. В него входят все сервисы и наш монолит. Цель продукта максимально автоматизировать и оптимизировать работу всех сотрудников ресторана. Сейчас наша работа направлена больше на предотвращение ошибок. Теперь мы QA в продукте Ресторан: развиваем качества в продукте, участвуем на всех этапах проработки задач.

Последствия первого и второго порядка

Прямые последствия. Как и ожидалось, мы стали подключаться к проработке задач с самого начала, участвовать в PBR, планингах, воркшопах и нести на них экспертизу тестирования. Мы стали ближе к командам разработки, а точнее её частью и наши проблемы были и проблемами команды. В командах стала расти экспертиза тестирования, обеспечения качества и широкое знание системы. Мы в свою очередь стали больше погружаться в работу разработчиков и понимать их боли.

А теперь то, что мы не планировали это последствия второго порядка.

Никто не драйвит качество продукта. В этой проблеме есть 2 стороны:

качество с точки зрения процессов;
качество автотестов и пайплайна.

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

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

Все идеи были направлены только на улучшение состояния команды мы делали всё, чтобы выпустить качественную фичу, а не качественный продукт. В результате перестали появляться принципиально сильные решения, которые смогут поднять качество продукта на новый уровень.

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

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

Лишняя работа для разработчиков. Тяжело быть разработчиком. Если раньше они привыкли писать продуктовый код, который магическим образом проверяется и уходит на продакшн, то теперь им нужно самим писать тесты, править и стабилизировать. Мы на PBR определяем, какие сценарии должны быть покрыты тестами, а уровень автотестов разработчики выбирают сами.

Разработчики прошли несколько стадий принятия ~~смерти~~ пайплайна.

Отрицание. Все релизы Dodo IS катят разработчики. Они организуют процесс, комуницируют с командой нагрузочного тестирования, смотрят логи и мониторинг во время релиза. Разработчики, которые катили релиз, сталкиваясь с красным тестом, не пытались разобраться в его причине, а просто перезапускали пайплайн, пока он не становился зеленым 5710 раз. Всё потому, что не было доверия к автотестам.

Максимальное количество перезапусков, которые я нашел, 44 раза!!! Мне кажется, от полного отказа от тестов нас спасло правило которое мы приняли на одном из ретро Не релизим с красными тестами. Если тест красный разберись в чём проблема. Если проблема в тестах почини или заигнорь и сделай карточку на разблокировку теста, и добавь ее в бэклог.

Гнев: разработчики ругались на наши тесты, говорили что они ~~говно~~ нестабильные, плохо написаны, их нужно переделать, выкинуть и переписать (именно в такой последовательности).

Торга и депрессии не было, наступило сразу принятие: разработчики теперь могут сами писать E2E-тесты UI и API, стабилизируют и улучшают их.

Количество багов на проде стало увеличиваться. На продакшн стали просачиваться не критичные баги. На это есть несколько причин:

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

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

Как мы решаем эти проблемы

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

Создали гильдию QA Ресторана или Community of practice, в которую вошли все QA Ресторана. Цель сообщества драйвить качество всего продукта, распространять хорошие практики тестирования на все команды продукта. Это образование, которое совмещает в себе преимущества выделенной QA-команды и также мы получаем преимущества от нахождения QA в команде разработки.

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

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

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

Курсы. Проблему отсутствия компетенций закрываем курсами для ручных тестировщиков и парной работой с разработчиками с опытом в автоматизации.

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

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

Что бы мы сделали сейчас?

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

Например, потерю компетенций, можно было бы решить тем, что за несколько месяцев до перехода людей с компетенцией в автоматизации попросить их расшарить компетенцию на всех QA-инженеров в продукте или разработчикам из команд. А лучше и всем сразу.

Проблему с лишней работой для разработчиков никак не компенсируешь, но можно было бы снизить боль от написания тестов тем, что не ставить перед фактом, а:

показать ценность тестов в явном виде;
научить разработчиков эти тесты писать, улучшать и поддерживать;
сделать переход не таким быстрым (за неделю), а растянуть дольше.

Как научиться предугадывать последствия второго порядка

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

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

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

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

Как я теперь буду пытаться предугадывать последствия

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

Прежде чем принять решение задавать себе вопрос А что будет дальше? и добавить к вопросу временные отрезки. Что будет через 10 минут, 10 месяцев или 10 лет?
Тренировать свое мышление в сторону таких последствий, размышляя над разными ситуациями. Например, какие могут быть последствия первого второго или даже третьего порядка, если весь мир пересядет на электромобили, или, например, введут базовый безусловный доход. В этом упражнении нет правильных ответов, но оно позволит мыслить шире.
Помнить о том, что первая мысль в голове это первый порядок. Всегда.

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

P.S. Нам сейчас требуются 2 мобильных QA-инженера в продукт Открытие стран и в Дринкит. Мы ищем человека которому не все равно на качество тестируемого продукта и который развивается в автоматизацию. Задач и возможностей полно: можно расти и углубляться в автоматизацию, можно менять процессы и подходы в командах, а можно двигаться в сторону SRE-практик и стать mobile SRE инженером. Все зависит от ваших целей и предпочтений. Если вы хотите у нас работать, пишите в Телеграм: мне (@EvgenSkt) или нашему HR Саше (@alexpanev).

Если хотите узнать, как мы собеседуем и онбордим кандидатов, то оставим ссылки на статьи, где об этом писали: Собеседование в Додо Пиццу и Онбординг разработчиков (на слово разработчик можно не ориентироваться процесс практически идентичен для всех). А больше узнать о нашей культуре QA, можно в статье А не фигню ли я опять делаю? Как и зачем внедрять метрики качества.

Наш Телеграм-чат, если захотите обсудить статью и задать вопросы.

Подробнее..

Категории: Программирование , Тестирование it-систем , Тестирование , Тестирование веб-сервисов , Qa , Тестирование по , Прогнозирование , Блог компании dodo engineering , Прогноз , Последствия

Игра в Нострадамуса

23.05.2021 10:08:18 |

Автор: admin

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

Принцип Коперника

Теорема о конце света, буквально утверждает, что с 95 % уверенностью мы можем считать, что человеческая раса исчезнет в течение 9120 лет. Конкретный срок не определен точно, но что исчезнет это практически наверняка. Открыл и популяризировал теорему профессор астрофизики Джон Готт.

В основу своих рассуждений Готт положил, что живущие сейчас люди находятся в случайном месте всей хронологии человеческой истории. Это чистая случайность, что мы сейчас живём в 2021 году, и этот год ничем не предпочтительнее любого другого 20 000 года до новой эры, 1315 или 1917. Как положение Земли в солнечной системе не центральное, так и наш 2021 год. Это утверждение Готт назвал принципом Коперника.

Догадка посетила будущего известного ученого в 1969 году после туристического визита в Берлин, где он увидел Берлинскую стену. На тот момент стена стояла уже 8 лет. После несложных выкладок в уме, он сообщил другу, что стена простоит не меньше 2 и не больше 24 лет. Вот почему.

Пусть $inline$ время существования явления к настоящему моменту, а $inline$ сколько остаётся ему до конца. Считая, что попадание во временную точку t отрезка времени полного существования $inline$ случайно и равновероятно, имеем случайную величину

$x = \frac{t}{T+t}$

распределённую на отрезке [0, 1] равномерно. В этом случае доверительный интервал, с которым случайная величина $inline$ с вероятностью $1-\alpha$ находится внутри отрезка есть

$\frac{\alpha}{2}\leq x \leq 1-\frac{\alpha}{2}$

Выразим $inline$ через $inline$ и $\alpha$ и получим интервал для времени дальнейшего существования $inline$

$\frac{\alpha/2}{1-\alpha/2}t \leq T \leq \left( \frac{2}{\alpha} - 1 \right)t$

С шансами один к одному ( $\alpha=0.5$ ) Готт оценил сколько осталось Берлинской стене:

$\frac{t}{3} \leq T \leq 3t$

Умножил случайное число 8 на 3 и получил, что не более 24 лет. Во всяком случае, располагая такой оценкой уже можно принимать ставки.

Предсказания

Вдохновленный своим открытием, Готт сделал множество прогнозов. Наиболее знаменитый из них та самая Теорема о конце света, опубликованная в журнале Nature в 1993 году. Принцип тот же самый, разве что $\alpha=0.05$ , так сказать, чтобы наверняка, с вероятностью ошибки не более 1/20. В роли равномерно распределённой случайной переменной взято отношение $\frac{n}{N}$ , где $inline$ приблизительное число уже живших и живущих людей на этом свете, а $inline$ окончательное число всех, кто поживет за все времена. Оно составит не более $inline$ , то есть, если мы примем, что 60 млрд людей родились вплоть до настоящего момента (оценка Лесли), то тогда мы можем сказать, что с уверенностью 95 % общее число людей N будет менее, чем 2060 миллиардов = 1,2 триллиона. Предполагая, что население мира стабилизируется на уровне 10 млрд человек, и средняя продолжительность жизни составит 80 лет, нетрудно посчитать, сколько потребуется времени, чтобы оставшиеся 1140 миллиардов людей родились. А именно, данное рассуждение означает, что с 95 % уверенностью мы можем утверждать, что человеческая раса исчезнет в течение 9120 лет. Так написано в Википедии.

Следом за Готтом, давайте и я притворюсь Нострадамусом и предскажу, что

масочный режим (уже длится более 500 дней) вряд ли исчезнет в ближайшие 10 дней,
Хабр будет здравствовать никак не меньше еще пяти месяцев,
а Интернет не исчезнет минимум год.

Серьезно? Давайте поспорим!

В своей книге J. R. Gott III, Time Travel in Einsteins Universe (Houghton Mifflin, Boston, 2001), Глава. 5. Джон Готт сделал много предсказаний о судьбе государств, политиков, ток-шоу. Журнал The New Yorker посвятил ему статью How to Predict Everything. Казалось бы успех, но как это бывает в науке, критических статей и обзоров вышло еще больше.

Первое очевидное возражение, которое приходит на ум, иллюстрирует комикс xkcd

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

Серьёзный анализ, который я не воспроизведу здесь, дан в статье Carlton M. Caves // Predicting future duration from present age: Revisiting a critical assessment of Gotts rule, 2008. В сухом остатке: оценка Готта имеет право на жизнь, но лишь в том случае, когда априорная плотность вероятности имеет вид:

$\omega (T)=\frac{1}{T^2}$

Такого рода распределение особенно тем, что оно инвариантно относительно масштаба шкалы времени. Проще говоря, оценка времени жизни по Готту применима только к тем объектам, для которых нет характерного времени жизни.

У многих интересующих нас объектов есть характерный масштаб времени. В среднем собаки живут 10-13 лет, люди 60-80, бабочки день-другой и так далее. "Собачьи года" для собак, календарный год для людей. К ним формула Готта неприменима. Встречаются в жизни и масштабно инвариантные распределения вероятностей, такие как закон Ципфа и другие ранговые распределения.

Последовательное применение принципа Коперника (оценки Готта) означает следующее:

взять случайный объект,
посмотреть сколько он уже существует,
оценить к какому рангу он относится (по порядку величины)

Житейский опыт говорит нам, что если взятый наудачу субъект, скажем, научный сотрудник попавшийся не вовремя на глаза директору, на коварный вопрос "а сколько ты уже пишешь свой труд-то?" отвечает "месяц где-то", то да, вряд ли он сделает всё к завтрашнему дню, но через пару лет уж точно. Оценка по порядку величин, всё нормально.

Заключение

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

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Категории: Научно-популярное , Статистика в it , Статистика , Vps , Прогнозирование , Vds , Блог компании маклауд , Быстрые серверы , Принцип коперника

Предметно-тематические тренды назначение и интерпретаци

12.06.2021 00:22:22 |

Автор: admin

Кононова О.В., Прокудин Д.Е.

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

Что такое тренд и какие виды трендов существуют?
Как, с помощью каких программных средств, построить тренд?
Как интерпретировать результаты построения тренда?

Существует несколько общепринятых подходов к интерпретации понятия тренд.

Тренд это представление в графическом виде изменения некоторой величины или группы величин, отражающих рассматриваемые явления или процессы в динамике на временном интервале, часто с элементами прогноза на последующие временные интервалы. Такое представление тренда всегда основано на количественных измерениях.

Тренд это представление информации о ситуации или явлениях в схематическом, табличном или текстовом (описательном) виде, отражающем срез, картинку, положение вещей за определённый интервал времени или на определенную дату. Такое представление тренда отражает качественные характеристики, содержание (семантику) исследуемых явлений. Часто качественные характеристики являются следствием обработки, анализа и интерпретации числовых данных, например, частот встречаемости терминов в тексте.

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

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

При проведении самостоятельных научных изысканий можно использовать несколько типов трендов: предметный, концептуальный, тематический тренды. Для этого первоначально исследователем формируется терминологическое ядро направления, тематики исследования. Поисковые запросы с использованием базовых терминов позволяют подготовить подборку текстов для дальнейшего анализа с использованием специализированного аналитического инструментария, например,Voyant-tools(http://personeltest.ru/aways/voyant-tools.org),Tropes, (http://personeltest.ru/away/www.semantic-knowledge.com/tropes.htm),SketchEngine(http://personeltest.ru/aways/www.sketchengine.eu),T-Libra(http://personeltest.ru/away/www.softconst.ru/tlibra/) или аналитического аппарата, непосредственно встроенного в библиотечную систему или базу данных, например, Научная электронная библиотека (http://personeltest.ru/away/elibrary.ru), реферативная база научной информацииScopus(http://personeltest.ru/aways/www.scopus.com).

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

Примеры представления предметных трендов.

Распределение научных публикаций по предметным областям. Запрос: "e-Health" or "Digital Healthcare" (Scopus, 2008-2019)

Распределение научных публикаций по предметным областям. Запрос: "e-Health" or "Digital Healthcare" (НЭБ eLibrary, 2008)

Концептуальныйтренд.

Концептуальный тренд отражает информацию о количестве документов, соответствующих поисковому запросу за определенное количество лет (по годам, например, 2018, 2019, 2020) или временных интервалов (2010-2015, 2016-2020) для того или иного информационного источника. Концептуальный тренд может быть представлен в виде числового ряда или графически. Как правило, такого рода информация, по полученной в результате запроса первоначальной подборке материалов, предоставляется библиотечными системами автоматически. Результаты обработки и чистка первоначальной подборки с использованием уточняющих вторичных запросов или отбора анализируемого материала на основе экспертной оценки предполагает последующее использование дополнительного инструментария для построения трендов, например таблиц Excel.

Тренды, построенные на информации из различных источников. Запрос Цифровая экономика, 2015-2019

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

Тренды, отражающие динамику развития тематики исследования Электронное здравоохранение, 2008-2019

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

Тематический тренд.

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

Распределение научных публикаций по ключевым словам. Запрос: "e-Health" or "Digital Healthcare", 2008 (НЭБ eLibrary)

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

Пример тренда. Терминограмма как результат абсолютного частотного запроса, 2011-2018 (ЭБ T-Libra)

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

Цифровая экономика. Распределение терминов по семантическим группам, 2008-2018 (ЭБ T-Libra)

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

Цифровой туризм: тематический тренд (Trends, Buhalis and Law, 2008)

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

Статья подготовлена при поддержке благотворительного фонда Владимира Потанина.

Подробнее..

Категории: Научно-популярное , Тренды , Прогнозирование , Исследовательская работа

Предметно-тематические тренды назначение и интерпретация

12.06.2021 02:15:08 |

Автор: admin

Кононова О.В., Прокудин Д.Е.

Что такое тренд и какие виды трендов существуют?
Как, с помощью каких программных средств, построить тренд?
Как интерпретировать результаты построения тренда?

Существует несколько общепринятых подходов к интерпретации понятия тренд.

Предметный тренд

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

Примеры представления предметных трендов.

Распределение научных публикаций по предметным областям. Запрос: "e-Health" or "Digital Healthcare" (Scopus, 2008-2019)

Распределение научных публикаций по предметным областям. Запрос: "e-Health" or "Digital Healthcare" (НЭБ eLibrary, 2008)

Концептуальныйтренд

Тренды, построенные на информации из различных источников. Запрос Цифровая экономика, 2015-2019

Тренды, отражающие динамику развития тематики исследования Электронное здравоохранение, 2008-2019

Тематический тренд

Распределение научных публикаций по ключевым словам. Запрос: "e-Health" or "Digital Healthcare", 2008 (НЭБ eLibrary)

Пример тренда. Терминограмма как результат абсолютного частотного запроса, 2011-2018 (ЭБ T-Libra)

Цифровая экономика. Распределение терминов по семантическим группам, 2008-2018 (ЭБ T-Libra)

Цифровой туризм: тематический тренд (Trends, Buhalis and Law, 2008)

Статья подготовлена при поддержке благотворительного фонда Владимира Потанина.

Подробнее..

Категории: Научно-популярное , Тренды , Прогнозирование , Исследовательская работа

Облом, или как провалился любимый ИТ-проект

20.07.2020 20:10:45 |

Автор: admin

Его пример другим наука

Предисловие

Это грустная история о неуспехе проекта, который я считал потенциально успешным на все 100 процентов. И почему все кончилось обломом, я до сих пор толком не понимаю.

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

А почему такой скачок у такого-то показателя?
А кто совершил такую-то операцию?
А что будет с состоянием, если совершить такую-то операцию?
А что будет с состоянием, если изменить такие-то показатели на такие-то значения?

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

История проекта

Скоро сказка сказывается, да не скоро дело делается
Все названия фирм и банков не настоящие.

Фирма М. Начало

В М я участвовал в проекте валютного операционного дня банка(ОДБ). И тут я столкнулся с началами аналитики. Пришли нормативные документы, в которых определялись разнообразные нормативы деятельности коммерческого банка и регламент их применения. Нормативы определяли рамки риска для деятельности банка. И тут у меня, вдохновленного переводными книгами по экономике(упаси боже, было читать советские книги по экономике), забрезжила идея Аналитики проекта, позволяющего пользователю определять и рассчитывать любые экономические показатели и контролировать их на соблюдение нормативных или других ограничений. Я поговорил с руководителями(а это были три дамы: президент, председатель, директор!!!), но не убедил их в нужности самостоятельного проекта. И я фактически оказался не у дел и мне стало и скучно и грустно. Но тут мне предложили подработать на стороне разработать проект мультивалютного операционного дня банка(ОДБ) для фирмы НП. Я стал работать и в конце концов перешел в НП на постоянную основу разрабатывать проект мультивалютного ОДБ. Но задумка аналитики осталась в душе.

Фирма НП. Скромное продолжение

Итак, в НП я разрабатываю мультивалютный ОДБ. Помня о нормативах, упомянутых в предыдущем пункте, я их реализовал и подцепил к справке, которая выдавала определение показателя, формулу его вычисления и текущее значение. Все это было реализовано в лоб без всякой унификации и глубокой системы. Вот в Москве проходит очередная выставка банковских продуктов. И мы выставляемся. Подходит к нам одна банкирша и начинает знакомиться с нашим продуктом. Скоро звучит вопрос: А как у вас дела с нормативами?. Я ей показываю таблицу текущих значений нормативов, она нажимает F1 и тут появляется определение норматива и формула его вычисления. Она была безмерно приятно удивлена, заявив, что ни у кого похожего не видела. И тут я укрепился в идее об аналитике. Если уж решение в лоб для нескольких показателей приятно удивило клиента, то что будет, если ему дать настоящую продвинутую бизнес-аналитику. В общем, я еще более воодушевился.

Банк БСБ. Личное систематическое начало

Как-то я демонстрировал в банке БСБ свой проект валютного операционного дня. Автоматизацией в БСБ ведал мой бывший шеф из банка ПСБ. Он посмотрел проект, попил со мною пару раз кофе и пригласил на работу к себе. А мы уже внедряли проект в одном из банков. А я, увы, внедрять был не очень охоч. И я согласился на переход. И вот я в БСБ. С работой справлялся быстро и было много свободного времени. Начал осваивать Delphi. Ознакомился с эксплуатируемыми задачами в банке. Оказался целый конгломерат разнотипных задач. Каждая автономна и со своим подходом. Я еще раз понял, что нужна единая банковская аналитика. Работаю над ней по собственной инициативе. Набросал концепции и начала техпроекта и обращаюсь с задумкой к шефу. Но как раз шеф набирает кадры из вычислительного центра ПСБ и они показывают некие зачатки банковской аналитики, которой они пользовались в ПСБ. Все реализовано на Oracle Discovery. А шеф сам выходец из ПСБ и айтишники из ПСБ и все они знакомы. И шеф решил пользоваться тем, что принесут ребята из ПСБ и не рисковать новыми подходами. Итак, меня прокатили. Но я продолжаю разрабатывать проект самостоятельно. Времени хватало. Я самообразовываюсь читаю толстые книги: Управление финансами в коммерческих банках(автор Синки), Банковский менеджмент(автор Роуз), Финансовое управление фирмой(автор Смит и др. ). И еще больше укрепляюсь в своей идее.
Когда я уже ушел из БСБ, то узнал, что БСБ склоняется к мысле приобрести SAP, что в итоге и сделали. Потом несколько лет внедряли, и я уже не знаю внедрили ли. Да, было модно обращаться к западным продуктам. Объяснение простое: ведь это означало систематические зарубежные командировки за счет банка.
Меня продолжает вередить зуд аналитики. И вот я решил продвинуть ее на частном примере кредитования. Кратко о сути задачи. Есть портфель кредитных заявок. В общем случае весь портфель удовлетворить нельзя: может не хватить обеспечивающих ресурсов. Плюс ко всему есть набор нормативов, которым должно удовлетворять состояние банка. Значит есть проблемы выбора. А где есть несколько вариантов выбора, там возникает задача оптимального выбора. Критерий оптимизации может быть разным, например:

Интегральная процентная прибыль за некоторый период
Чистая приведенная стоимость выбора за тот же период

Дело осложняется тем, что каждый клиент характеризуется некоторым риском. Значит критерий должен взвешиваться по вероятности возврата кредита. Мне удалось свести задачу к задаче линейного программирования. Риск по клиенту задавался моделью эмпирического риска, которую пришлось разработать самому. Сложность представляли нормативные ограничения, которые задавались нелинейными формулами. Оказались, что они только по форме нелинейные и тождественными простыми преобразованиями их можно свести к линейным. Риск можно было задавать и априорно.
Итак, постановка сделана. Нужно получить в банке одобрение проекта. Иду к руководству. Руководство не может само оценить предложенные идеи и меня посылают в какой-то полунаучный отдел(забыл точное название) и я попадаю на консультацию к кандидату экономических наук, бывшему нархозовцу(институт народного хозяйства). Не знаю почему, но тот сразу ополчился против и понеслись фразы типа i,j все писать умеют. В подтексте слышится: Пришли тут неостепененные и Суди дружок не выше сапога. И никак ему не втолковать, что проект не претендует на науку, а предлагает конкретную разработку и алгоритм под неё, так что можно приступать к программированию. Но это никак не втолковать. В итоге никаких рекомендаций я не получил. Ну и фиг с вами. Пусть все будет как есть. Это был второй раз, когда я встретился с отраслевой наукой и второй раз я попал к ней на рога.

Фирма МРЦ. Личное систематическое продолжение

Шеф уходит возглавлять МРЦ. Он забирает меня с собой. Фирма денежная и может финансировать несколько проектов. Я начинаю зондировать разработку проекта бизнес-аналитики. Продолжаю делать наброски технического проекта. Разрабатываю средствами CASE структуру БД. И тут мне опять представился случай проявить инициативу. Полным ходом идет разработка системы RTGS(Real Time Gross Settlement) реализации в реальном времени крупных платежей. Проект курируется Европой. Регулярно приезжают холеные европейские консультанты, которых мы угощаем растворимым кофе из нехоленых ржавых банок. Регулярно в Европу ездит наше руководство. Обслуживает руководство переводчики из моего управления. И у меня в управлении стоит целый книжный шкаф ценных переводов по банковской проблематике. Большинство из них я не могу уразуметь, то ли из-за сложности тематики, то ли из-за качества перевода. Ну хорошо, разрабатывается RTGS. А что делать с мелкими платежами? Предполагается, что они будут реализовываться в режиме клиринга. На клиринг нет ни постановки, ни вразумительной терминологии. И вот я берусь самостоятельно разрабатывать проект Клиринг. Разрабатываю словарь терминов и приступаю к техническому проекту. Словарь даю на обозрение широкой публике. Энтузиазм из меня так и прет.
Но тут наступают новые политические времена. Арестовывают Винникову, председателя Нацбанка РБ. А мой шеф возглавил МРЦ по представлению Винниковой. И вот началось выдавливание всех, кто прямо или косвенно был связан с Винниковой. Шеф увольняется. И меня начинают прессовать. Даже сослали в дальнюю от моего управления маленькую комнатку. Приходит новый начальник. Я ему несу на рассмотрение свой проект клиринга. Начальник держит проект у себя около месяца. Я ждал, ждал и обращаюсь к нему. А в ответ услышал: Разработка проекта не входит в Ваши прямые должностные обязанности. Вот вам и инициатива. Я прошу вернуть проект. Начальник мнется, мнется, но все-таки возвращает проект мне и проект до сих пор пылится у меня на балконе. Да, кстати, по теме клиринга я написал в отраслевой журнал статью. В ней предлагалась модель, определяющая временной лаг клиринга, оптимизирующий использование ресурсов клиринга. Статью приняли и напечатали без всяких препонов. Воодушевленный я развил идею дальше и понес в журнал вторую статью. И тут по поведению редактора я понял, что канал перекрыт. И мне стало ясно, что пора сваливать самому, не ожидая пока попросят. Обращаюсь к фирме СК и предлагаю проект аналитики. Тут же получаю приглашение на работу. Значит, я на правильном пути.

Фирма СК. Начало венчурного финансирования

Итак, я в СК и руководитель проекта Zero. Это проект банковской аналитики. Кроме руководителя пока нет никого. Пока один. Начинаю реализацию на Дельфи. Проходит месяца три и меня вызывает технический директор и просит ознакомить его с состоянием проекта. Знакомлю. Уже кое-что есть. А директор говорит: А почему бы не перейти на самоокупаемость продавать проект по частям, которые уже реализованы? Я опешил. Начинаю возражать, что мол МАЗ не продает колеса, а продает самосвалы. Попикировались и разошлись.
Начинаю чувствовать пристальное внимание со стороны главного инженера. Это был мой непосредственный начальник. Вся проектная идеология исходила от него. Человек талантливый и с жесткими взглядами на управление и с мягкими пряниками похвалы. Он все время зондирует мои дела и однажды объяснился. Он разработал интерпретатор подмножества Паскаля и все банковские отчеты главного продукта фирмы делались на скриптах этого интерпретатора. Скрипты назывались ОПР, не помню почему. Так вот, сказал он проект нужно делать на ОПР и вся аналитика должна сводиться к отчетам, написанными на ОПР. Это был еще не приказ(а он, конечно, имел право приказать). Мы начали дискутировать. Я как плюсы своего подхода приводил объектный подход и гораздо более систематический подход к показателям вплоть до их кодирования и подход к аналитике не как к отчетам, а как к моделированию экономических ситуаций и анализу последствий моделирования. В общем была приятная нормальная дискуссия. Такие дискуссии продолжались несколько раз. Это хорошо, это правильно. Но, однако, ни он ни я не меняем свою точку зрения. Тогда босс предлагает организовать публичный диспут, в котором каждая из сторон представит свой список аргументов. Отлично. Но в день дискуссии я узнаю, что босс вмещался в мой список и скорректировал его на свой вкус с позиции начальства и представил исправленный список публике. Это меня шокировало. Ведь ты как начальник мог приказать мне работать так как ты считаешь нужным и я, или должен принять это, или уволиться. Но если свободная дискуссия, то не затыкай мне рот. Мы на равных. В общем диспут я проиграл, хоть и не с разгромным счетом. Бодался теленок с дубом. Я получил хороший урок корпоративной этики и стал искать новую фирму. И нашел АТЛ.

Фирма АТЛ. Конец венчурного финансирования

И тут, наконец, я получаю карт-бланш для любых фаз разработки. И разрешение на набор команды. Но когда я еще один работал, босс уже пригласил потенциальных клиентов на просмотр продукта. И вот банкир из Казахстана изъявляет желание приобрести проект. Хорошо, что босс спросил у меня готов ли я. Я отказался от внедрения: cамому разрабатывать и самому внедрять не слишком ли. И я стал набирать команду. Больше 8 человек в бригаде никогда не было. Каждому человеку давался приличный самостоятельный кусок проекта. Я составлял на него ТЗ и вперед. Через месяц, два становилось очевидным годится ли человек.
Итак, проект стал развиваться быстрыми темпами. Некоторые функции подсказывали потенциальные клиенты. Например, я демонстрирую проект французам. Дошел до графиков динамических рядов. И тут один француз спрашивает: А вы не скажете, почему в прибыли тут такой скачок?. И тут же мелькает мысль: Как это я, дурак, сам не додумался задать себе такой вопрос?. В результате появилась операционная декомпозиция набор всех операций, изменяющих заданный показатель в заданное время. А с операции можно выйти и на ее исполнителя.
Хранение и обработка динамических рядов, сценарное моделирование, виртуальные показатели, статистическая проверка гипотез, регрессии, поиск наилучших регрессий, обработка портфеля финансовых инструментов, разного рода декомпозиции значений показателей, разного рода компараторы все реализовывалось на мой взгляд быстро. Проект становился все солиднее. Я попробовал ради интереса реализовать Web-интерфейсы для создания Web-служб. Это оказалось несложным, но далее web-тематику мы не развивали.
Начали выставляться на ИТ-выставках. Я демонстрировал не презентацию, а реальную работу продукта. Позже я от этого отказался, так как это слишком большой стресс. У меня даже руки стали дрожать, когда нужно было реально продемонстрировать требуемое свойство. Интерес к продукту был и немаленький. Из одного солидного банка пришло ИТ-руководство. На следующий день пришла целая бригада из ИТ-департамента. Потом пришла бригада банкиров. А мне все показывай им. Ну думаю, дело на мази. Увы. А в большинстве приходили ИТ-шники. И до того дотошно расспрашивали, что однажды я прямо спросил: Так вы намереваетесь брать или просто так интересуетесь? А в ответ: Да нет, брать мы не будем, мы просто тоже делаем что-то подобное и поэтому интересуемся как дела у других. Я взял и напросился посмотреть их проект. Не отказали. Проект был реализован на java. Он имел дело только с генерацией показателей. И эта генерация занимала на мой взгляд слишком много времени. И, поэтому, генерация шла в ночное время.
Однажды прекрасным весенним выходным днем меня вызывают на работу. Нужно показать проект важному банкиру из Питера. Проект банкиру очень понравился и он попросил приехать в Питер и показать проект широкой публике. Едем. Присутствует весь менеджмент банка. Нас представили и тут до представления начались бурные дискуссии между менеджерами. Одна партия за существующий там проект, а вторая за нас. Мы слушали, слушали и попросили прервать дебаты. Мол, мы покажем проект, а потом дебатируйте. Так и сделали. В итоге решили, что мы переведем всю БД нашего проекта на питерский Progress, сохранив то, что уже есть в нем и дополнительно в рамках нашего проекта реализуем несколько новых функций. Потом все это мы покажем и далее решится судьба проекта. Мы реализовали то, что требуется и собираемся в командировку в Питер. И вот пришло время ехать. И тут шеф дает отбой. Что и почему, я так и не узнал, так как не был посвящен в бизнес-интриги. И Питер обломился.
Были посетители и из Парижа. Глава делегации был какой-то потомок русских эмигрантов. Русский он знал неплохо. Судя по всему, проект ему понравился и он в знак уважения(?) подарил мне ноутбук от IBM., правда не совсем последней модели. Ноутбук и сейчас работает. Вскоре шеф приказывает мне готовить проект для Парижа. Вот это да! Перевели на французский всю документацию. Локализовали проект. Обмениваемся данными с банком в Париже. Готовимся к командировке. И тут шеф говорит, что наш покровитель переходит на повышение в другую фирму, не связанную с нашей тематикой И все затихло.
Мой бывший шеф по МРЦ возглавил в банке ПСБ департамент стратегических исследований. И он разрешил мне поставить проект на апробацию. И что я вам скажу? Никогда не пробуйте эксплуатировать у заказчика сырой проект. Только навредите репутации. Так и случилось. После пары сбоев прохлада со стороны банкиров. Да и вид у всех типа Кому нужно дополнительная работа без дополнительной оплаты. В конце концов мой знакомый при очередной встрече за рюмкой и обсуждению текущего политического момента произнес сакраментальную фразу При такой политике не нужно аналитики.

Векселя

И тут представилась возможность реализовать маленькое подмножество аналитики на примере обработки векселей. Работа с субъектами полностью была взята из аналитики. Ну, и несколько показателей пригодились также. Быстро реализуем проект Векселя. Проект внедрен. Идет сопровождение. И тут грянул гром. В контрольные органы поступила кляуза, что на проекте отмыты деньги, а проект не делает то что нужно(Похоже дело было в том, что у нас работал сын заказчика проекта Векселя). И вот мы разработчики должны продемонстрировать проект ревизору. Хорошо, что мы детально изложили ТЗ и четко реализовали все пункты ТЗ в проекте. Продемонстрировали ревизору работу проекта по всем пунктам ТЗ. Придраться было не к чему. А проект стоил мизерные деньги и как на нем можно было нажиться не представляю. По крайней мере мы на нем не нажились.
Проект был спасен и мы уже подумывали о его развитии. Но тут президент запретил вексельную форму расчетов. И хотя нас просили сохранить всю инфраструктуру проекта(работа с субъектами хозяйствования), но о деньгах речь не шла и нам не было резона трудиться.

Поиск криминала

А тут подвернулся еще один проект, который можно и нужно было связать с аналитикой. Объявился интересный потенциальный заказчик. Он описывает нам предмет автоматизации примерно так. Есть множество субъектов и множество отношений между ними. Нужно определить прямые и производные атрибуты, которые характеризуют степень финансовой криминальности субъекта и на основании атрибутов криминальности выявлять подозрительных субъектов и отслеживать их. Предполагаемый заказчик говорил только, что нужно вести досье и дело на каждого клиента, а также собирать сведения о всех отношениях субъекта. Основные поставщики данных: МВД, банки, налоговые органы, собес, таможня, интерпол
Начались дебаты разрабатывать ли самим или брать покупной продукт. Заказчик склонялся к покупному варианту. Оно и понятно: зарубежные командировки, красивая реклама продуктов(сами продукты не имели демоверсий и их нельзя было реально пощупать), а деньги бюджетные, чего их считать. Я начал разрабатывать ТЗ. Скоро понял, что вряд ли оно будет завершено. Дело в том, что мой новый шеф пытался добиться того чтобы все документы, структуры, файлы были определены на стадии ТЗ. Фактически он хотел втиснуть в ТЗ техпроект. Вдобавок, каждое решение должно было протоколироваться за подписью заказчика и разработчика. Поэтому по каждому пункту ТЗ собирались совещания с заказчиком. Я высказал свои сомнения в успехе подобного подхода и стал параллельно по собственной инициативе разрабатывать самостоятельный проект на Дельфи. Мне было просто интересно. Основная информационная структура ориентированный нагруженный граф отношений. Узлы графа субъекты, ребра графа отношения, нагруженные типом, размером, датой начала отношений, датой активации отношения В графе могут быть различные поиски: цепочки однородных отношений, цепочки неоднородных отношений, цепочки заданной длины, циклы, цепочки отношений, с размерами превышающими заданный лимит и т.д. и т.п. Разработал соответствующие классы и сравнительно быстро реализовал проект. Я продемонстрировал его руководителю предполагаемого проекта поиска криминала. На нескольких десятках тысяч субъектов, сотен тысяч отношений, десятка полтора типов отношений, любая цепочка находилась примерно за секунду. А буквально на следующий день руководитель сказал, что заказчик прекратил с нами отношения. Как и следовало ожидать, дальше ТЗ дело не пошло. А прошло около года. Мораль: не нужно слишком взнуздывать заказчика. А может шеф и не хотел этого проекта. Дело в том, что он был ответственен и за проект ERP для КГБ, а проект горел
А я, работая с отношениями, заинтересовался языком Prolog, точнее Visual Prolog. Начал пробовать. И удивительно, если в Дельфи реализация поиска цепочек требовала немалых усилий и размера программ, в Прологе это делалось компактной декларацией. Вот что значит заточенность языка на проблему и его декларативность. Описание предметной области декларативно и поэтому оно сравнительно легко ложилось в декларации Пролога.
Но не очень понравились возможности Visual Prolog по выводу форм. И у меня забрезжила мысль, что каждой специфичной проблеме нужен свой язык. Язык проектирования и генерации отчетов, язык проектирования ввода данных, язык проектирования вывода данных, язык коммуникаций, язык обработки отношений, язык обработки списков, язык описания данных, язык бизнес-аналитики, язык размещения сервисов и управления ими, язык бухучета, Короче, нужны не универсальные, а предметно-ориентированные языки. Дело только в стандартизации интерфейсов между получаемыми модулями. Зачем мне вся мощь C# с Visual Studio, если я, например, разрабатываю только формы, или только отчеты, или только обмен с БД,
Проект был включен в аналитику в подсистему Отношения.

Отступление о технических писателях

Когда я стал работать с вышеозначенным руководителем(он также бывший физик), тот стал жаловаться, что никто из его молодых подчиненных не в состоянии толком написать документацию. Я вполне с ним согласился и всю документацию по своим проектам писал сам. Вплоть до презентаций на Powerpoint.
Теперь мне кажется, что проблема технического писательства еще более обострилась. Люди стали мало читать, а пишут только интернет-комментарии, которые иногда стыдно читать.
Какой язык самый главный? твой родной. Его нужно знать в первую очередь.

Попытка интеграции

Проектом интересуются, но проект не покупается. Я заволновался и стал искать причины. А в то время главным банковским ИТ-продуктом на рынке был операционный день банка(ОДБ). И я решаю расширить рамки проекта и сделать интегрированный проект, включающий в себя: ОДБ, кадры, депозиты, кредиты, натуральный учет, операционный учет. Шефа долго не пришлось уговаривать. С ОДБ дела пошли удовлетворительно. А вот с кредитами и депозитами получился конфуз. Дело в том, что кадры на эти проекты мне не пришлось набирать самому, а пришлось ограничиться людьми из одного перспективного, но неудавшегося проекта. Ребята молодые, бойкие, склонные к системному программированию. Так и слышно: сокеты, TCP/IP, Internet, паттерны Проходит месяц а, а прогресса никакого. Но каждое утро ребята бурно обсуждают Формула-1. Так и слышится А Шумахер то, а Алонсо то. После обсуждения формулы-1 переключались на алгоритм деления трафика интернета между сотрудниками. Да, был такой социалистический реликт справедливого дележа трафика между сотрудниками. Дело кончилось тем, что я предложил депозитникам и кредитникам уволиться. Что и произошло.
А тут начались новые времена. Фирмой владел и руководил приятный бизнесмен. Очень религиозный человек. И в фирме была толстая прослойка из его единоверцев. И все шло более-менее спокойно. А тут вдруг, я не знаю почему, появляется новый руководитель свежеиспеченный пенсионер КГБ высокого чина. Скоро мы получаем заказ на проектирование ERP для КГБ. С течением времени проект стал заваливаться и требовалось срочно укреплять группу разработки ERP. А мой проект был венчурным и работали в нем неплохие ребята. И вот начали выдергивать из моего проекта людей. И возразить нельзя: ведь мы сидим на шее других проектов. Так я вскоре опять остался один. А в фирме все росла прослойка КГБ. Начался проект по разработке аппаратуры шифрации-дешифрации.

Финал

В конце-концов, я остался один на проекте Аналитика. Подбросили сторонний заказ для управления МВД доработать ASP-проект. Доработал. И тут оказывается, что фирма банкротится. Это, кажется, был хитрый бизнес-ход: параллельно с процессом банкротизации возникла новая фирма с людьми из нашей банкротящейся фирмы и которые были целиком завязаны на КГБ- разработку криптографической аппаратуры. А старая фирма обанкротилась. И моя аналитика стала домашним проектом. Но по инерции интерес к проекту еще некоторое время не угасал. Пришла пора .Net. Я понял, что уже сравнительно легко перейти к SOA-архитектуре. Перевел почти всю бизнес-логику с Delphi на C#. Познакомился с WCF. Выделил сервисы. Определил интерфейсы. Реализовал шлюзы сервис-клиент. И вот она SOA-архитектура. Была задумка реализовать простую оркестровку сервисов, но, кажется, в этом уже нет необходимости. Эта функция стала системной.
Однажды звонит телефон. Звонили айтишники, которые задумали разработать бизнес-аналитику. Они обратились к владельцу портала tut.by у которого я когда-то разработал проект валютного ОДБ. Мой бывший шеф(царство ему небесное) всегда подходил ко мне на выставках и я ему рассказывал о своих успехах. Он высказал несколько дельных маркетинг-замечаний, которые заставили меня призадуматься. Так вот он направил ребят ко мне. Они рассказали о своих планах. Я им сказал, что их задумки уже давно реализованы, но положены на полку. И я им продемонстрировал проект. Они поняли, что это весьма трудоемкое дело и предложили выступить в роли толкателей моего проекта в банки. А я уже вступил в стадию пессимизма перспектив толкания в банки. Но ребята упросили меня попробовать. Я им дерзайте. Снабдил их рекламными материалами, письмом в банки и они пошли толкать. Результат оказался предсказуемым.
Я до сих пор не могу определить причины неуспеха.
Я попробовал отдать проект в EPAM. Там резонно ответили, что разрабатывают только под заказ, а венчурными разработками не занимаются. Есть у нас в Минске Парк Высоких Технологий ПВТ, работающий под покровительством президента республики. И в нем есть отделение Бизнес-инкубатор. Я послал туда предложение передать бесплатно им свой проект. Никакого ответа не последовало. Я посмотрел в интернете что такое инкубатор и нашел вот что. инкубатор (от лат. incubare, здесь высиживаю птенцов) аппарат для искусственного вывода молодняка сельскохозяйственной птицы из яиц. Он дает жирных, но неприспособленных для неинкубаторской, реальной жизни особей. Похоже на правду.

Описание проекта

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

Принципы

SOA
Под сервисом понимается автономное приложение коллективного пользования, функции которого предоставляются через анонсированный разработчиком API. Сервис можно размещать на любом компьютере сети. В архитектуре клиент-сервер сервис был один СУБД. В SOA сервисов может быть сколько угодно и размещаться они могут на разных компьютерах сети.
WCF связь клиент-сервис и сервис-сервис.
СУБД
В БД никаких хранимых бизнес-процедур. СУБД достаточно загружена стандартными запросами сохранения, обновления и извлечения данных. Отсутствие хранимых бизнес-процедур сильно облегчает смену СУБД. Особенно если еще стараться ограничиваться стандартом SQL.
А если обнаружится, что сервер БД слабо загружен, то на нем можно разместить сервис работы с показателями, например.
Отчеты
В отчетах не должно быть никаких бизнес-функций. Отчет просто отображение группы показателей в заданную форму. А сами показатели должны рассчитываться в бизнес-слое сервисом машины показателей.
Интерфейсы
Любое обращение к сервису должно быть только через интерфейсы.
Группы
Однотипные объекты(показатели, субъекты, операции) могут объединяться по любому допустимому логическому критерию. Групп может быть сколько угодно.
Эксплореры
Иерархические структуры должны отображаться в едином эксплорере

Основные функции

Ведение субъектов и их отношений. Поиск по отношениям. Ведение групп субъектов.
Ведение показателей и их динамических рядов. Ведение групп показателей. Значения показателей могут быть числовыми, текстовыми, логическими, календарными. Правило вычисления показателя любая композиция стандартных математических функций и агрегатных функций. Примеры агрегатных функций: максимум по субъектам, среднее по времени, минимум по времени. Значения показателя представляются в нескольких измерениях реальности: факт, план, прогноз индивидуальный, прогноз статистический, прогноз сценарный. Удивительно, но нигде в литературе я не нашел систематизированного перечня бизнес-показателей с их определениями, кодами, наименованиями и правилами вычисления.
Статистический анализ динамических рядов. Проверка статистических гипотез. Нахождение статистических параметров.
Регрессионный анализ. Нахождение наилучших регрессий.
Ведение портфеля. Получение платежного календаря.
Прогнозирование. Прогнозирование линейными трендами. Прогнозирование по портфелю фининструментов. Прогнозирование с учетом статистического отклонения прогноза от реальности.
Сценарное моделирование. Различные типы сценариев: операционный, портфельный, индикаторный.
Анализ. Различного рода анализаторы(декомпозиторы): разложение по показателям, по субъектам, по валюте, по исполнителям, по операциям.
Сравнения. Различного рода компараторы: сравнение по времени, по субъектам, по показателям.
Отображение в реальном времени. На каждого пользователя заводится табло своего типа, в котором отображается группа показателей.
Ведение плана счетов, иерархии объектов учета, иерархии бизнес-операций и их отображения на проводки.
Элементы бюджетирования: игра с распределением ресурсов.

Основные технологии

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

Функциональные сервисы

Бизнес-ядро. По запросу клиента предоставляет ему для использования бизнес-объект и забирает объект от клиента. Кэширует объекты. Управляет связью между бизнес-уровнем и уровнем хранения данных.
Текущее состояние субъекта. Это набор показателей субъекта на текущую дату.
Симуляционное состояние. Это набор прогнозных показателей субъекта на заданную дату при заданном активном сценарии развития.
Статистика. Позволяет находить статистические зависимости.
Анализ показателей. Статистический и графический анализ реальных и виртуальных показателей.
Субъекты. Ведение субъектов и навигация по их множеству.
Отношения. Позволяет анализировать сколь угодно сложные цепочки отношений.
Бухгалтерские проводки. Подсказывает бухгалтерские проводки для заданной хозоперации.
Бизнес-табло реального времени. В заданном темпе отражаются текущие значения показателей. Отображение табличное и графическое.
Портфель финансовых инструментов. Ведение фининструментов, навигация по их множеству, отработка сценария пассивной эволюции, определение платежного календаря.
Бюджетирование, точечное или распределенное во времени.

Технологические сервисы

Идентификация и аутентификация. Для новых бизнес-объектов генерятся идентификаторы. При вхождении пользователя в приложение проверяется его пароль в приложении.
Доступ. Реализовано два типа доступа: по разрешению, и по запрещению. Уровни доступа: тип, метод типа, экземпляр.
Машина показателей. Вычисляет значения производных показателей и сохраняет эти значения в БД. Показатели загружаются из БД.
Монитор событий. Отслеживается сформированный пользователем набор событий. О наступившем событии сообщается оповещателю, находящемуся в адресном пространстве приложения
Оповещатель. Приложение оповещается о наступившем событии. Оповещатель генерирует идентичное событие. На событие клиент подписывается сам или его подписывает технолог.
Объектооборот. Бизнес-объекты прогоняются по технологическому конвейеру.
OLAP. Особенность: базисом для OLAP-кубов служит не столько сырые данные OLTP-систем, сколько слой рассчитанных показателей над OLTP-системами. Это делает OLAP-разработки простыми и более производительными, чем непосредственно на оперативных данных. Размерность пространства измерений можно увеличить, подцепляя к показателю, соответствующий субъект и делая его характеристики размерностями куба.

Объекты

Все объекты делятся на:

D-объекты. Это голые данные без бизнес-функций.
B-объекты. Это бизнес-объекты, содержащие D-объекты и бизнес-функции.
P-объекты. Это объекты представления, содержащие D-объекты с атрибутами их отображения.
C-объекты. Это коммуникационные объекты, служащие для передачи D-объектов между разными адресными пространствами.
DB-объекты. Это объекты для отображения D-объектов на базу данных и получения D-объектов из базы данных.

Взаимодействие объектов:

D-объект объект данных

Предназначен для хранения данных. D-объект это B-объект без бизнес-функций. Объект данных содержит только данные и не содержит бизнес функции. Имя: <имя>D. Пример: HomoD.
Все объекты данных образуют D-дерево. Корень TopD
D-объекты содержат не бизнес-методы:

CopyTo
CopyFrom
Clone
GenId
GenParentId
ToString

Об идентификации
TypeId идентификатор типа. В таблице Tip каждому типу соответствует запись с Id=TypeId. В пределах типа может быть сколько угодно экземпляров. Их различают атрибутом Code.
Code идентификатор экземпляра в пределах типа. Значит, пара TypeId и Code дают идентификатор экземпляра. Однако разные поставщики данных могут поставлять однотипные экземпляры. Например, платежных поручений может быть сколь угодно. Чтобы провести идентификацию на этот уровень задействуем ещё экземплярный уточнитель IQ, который уникален в пределах всех экземпляров на все время жизни решения. Тогда тройка TypeId, Code, IQ и есть идентификатор в поле Tip. Можно было обойтись одним IQ, но это неудобно для ручной работы с БД.

B-объект бизнес-объект

Это все сущности, являющиеся элементами прикладной области, которая представляется как взаимодействие бизнес-объектов. Предназначен для хранения бизнес функций. Пример бизнес-объектов: человек, счет, платеж. Пример не бизнес-объектов: все виджеты(=контролы).
Бизнес-объект содержит объект-данные и бизнес функции. Имя: <имя>. Пример: Homo
Каноническое соответствие: <имя>D <--> <имя>. Каждый B-объект имеет методы:

Сохранить
Извлечь
Удалить

Все бизнес-объекты образуют иерархию. Корень TopB

C-объект коммуникационный объект

Предназначен для передачи данных. Он содержит данные в в форматек, пригодном для передачи данных между разными адресными пространствами. Имя: <имя>С. Пример: HomoC
Каноническое соответствие: <имя>С <--> <имя>D.
Все коммуникационные объекты образуют иерархию. Корень TopC
Методы C-объекта:

CopyToD. Копировать себя в D-объект
CopyFromD. Копировать на себя из D-объекта

P-объект представляемый объект

Предназначен для отображения данных на визуальные формы. Содержит объект данных и параметры визуального отображения.
Имя: <тип объекта>P. Пример: HomoP
Все объекты представления образуют иерархию. Корень TopP. Каноническое соответствие: <имя>D <--> <имя>P. Многие P-объекты совпадают с D-объектами, так как не нуждаются в параметрах визуализации.

F-объект форма

Служат для визуального представления объектов данных.
Имя: <тип объекта>F. Пример: HomoF
Все формы образуют иерархию. Корень TopF. Каноническое соответствие: <имя>F <--> <имя>P.
Все функциональные формы наследуются от TopF. Основные свойства и методы:
Каждая форма имеет методы:

Получить объект
Отобразить объект на поля формы
Сформировать объект из данных формы
Сохранить объект
Удалить объект

С каждой формой соотносится свой контекст выполнения UserContext, прописанный в TopF.
Все grid-таблицы на формах могут выдаваться в Exсel. Этот метод реализован в TopF. В графе Exсel можно вводить любой код показателя или допустимое правило вычисления.
Тракт обработки: вводимые атрибуты на форме --> экземпляр D-объекта --> экземпляр B-объекта --> бизнес-функция --> экземпляр D-объекта --> экземпляр DB-объекта --> кортежи таблиц в БД.
Тракт отображения: кортежи таблиц в БД --> экземпляр DB-объекта --> экземпляр D-объекта --> экземпляр P-объекта --> отображаемые атрибуты объекта на форме.
Единообразность поведения форм обеспечивается общим корнем форм. Альтернативный метод использование интерфейсов. Достаточно реализовать в компоненте интерфейс, а вызывающей программе проверить его наличие. Такая реализация предотвращает перегруженность корневой формы.

DB-объект объект базы данных

Предназначен для общения с БД: сохранение объекта данных в БД и извлечение из БД объекта данных.
Имя: <имя>DB. Пример: HomoDB
Каноническое соответствие: <имя>.D<><имя>.DB.
Все DB-объекты образуют иерархию. Корень TopDB
Все бизнес-объекты регистрируются в таблице Tip с уникальным Id. Специфика объекта отображается в специфичных таблицах.

Архитектурная схема

Уровень данных

Он имеет дело только с D-объектами. Они образуют D-дерево. Вершина D-дерева объект TopD. Назначение объекта TopD обеспечить одинаковое поведение всех D-объектов.

Уровень хранимых данных

Он имеет дело только с D-объектами и DB-объектами. DB-объекты образуют DB-дерево.
Функции:

Извлечение из внешней памяти объектов данных
Сохранение во внешней памяти объектов данных
Кэширование объектов данных

Посредством DB-объекта D-Объект может отображаться в несколько кортежей и в несколько таблиц БД.
В БД нет никакой бизнес-логики. СУБД хватает забот по SQL-запросам. При желании можно разместить бизнес-сервис на сервере СУБД. При желании можно разместить все на одном компьютере.
Для доступа к БД используется ADO.Net. Уровень имеет дело с двумя потоками данных:
От БД к уровню логики. Уровень данных извлекает из БД нужные данные и формирует из них бизнес-данные, которые на уровне бизнес-логики войдут в бизнес-объект.
От бизнес-уровня к БД. Уровень данных получает бизнес-данные от уровня бизнес-логики и кладет их в БД.
Есть возможность кэширования данных. Кэширование сохранение объекта в оперативной памяти, если объект часто используется. Так в банковских расчетах постоянно нужен корреспондентский счет. Скэшировав его, не нужно будет часто обращаться к БД он будет браться из кэша.
DB-объект имеет функции:

Взять данные из бизнес-объекта
Передать данные в бизнес-объект
Сохранить данные в БД
Извлечь данные из БД
Обновить данные в БД
Удалить данные из БД

Правильно отрабатывать многообъектную транзакцию(не делать самому Commit и RollBack)
Один из параметров вызова DB-объекта DB-connection

Каждому типу объектов сопоставлена таблица в БД с именем типа объекта. Все объекты имеют уникальный Id и представлены в таблице Tip. В этой таблице есть атрибуты, являющиеся общими для всех объектов:

Id
PId
TypeId
Code
Name
CreatedOn
Description
StateCode
Author

Все объекты в этой таблице образуют иерархию, которая есть иерархия типов. Это значит, что каждый тип представлен записью, а все экземпляры типа подчинены этой записи(PId экземапляра = Id типа).
Для типа его Id это TypeId; Code есть идентификатор в пределах типа.

Детали объектов представлены в таблицах, соответствующих типу. Например, атрибуты объекта Homo представлены в таблице Homo.
Все атрибуты типа содержатся в сцепке таблицы Tip и таблицы, соответствующей типу. Соответствующее представление именуется как <тип>_v. Например, Homo_V.

Вершина DB-дерева объект TopDB. Назначение объекта TopDB обеспечить одинаковое поведение всех DB-объектов.

Бизнес-уровень

Он имеет дело только с B-объектами. B-объекты образуют B-дерево.
Функции:

Реализация бизнес-функций
Предоставление бизнес-интерфейсов
Предоставление бизнес-служб(приложение коллективного пользования):
WCF-службы
Web-службы

Вершина B-дерева TopB. Назначение объекта TopB обеспечить одинаковое поведение всех B-объектов.

Уровень представления

Он имеет дело только с P-объектами и F-объектами.
Функции:

Запрос данных к бизнес-уровню и получение от него объектов данных
Отображение данных в формы и отчеты
Формирование объектов данных и передача их на бизнес-уровень

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

Управление видимостью интерфейсных элементов
Управление группами связанных кнопок
Тип шрифта
Цвет и т.д.

F-объекты образуют F-дерево. Вершина TopF.
Назначение объекта TopF обеспечить одинаковое поведение всех F-объектов.

Обязательные принципы

Минимизация энтропии

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

Разные имена одной сущности в разных модулях
Разная дисциплина компоновки кода
Разные рисунки для кнопок одинакового назначения
Разные подсказки для кнопок одинакового назначения
Разный стиль программирования. Так иногда цикл по списку начинают с 0 до Сount-1, а в другом месте с 1 до Count.
Разный стиль именования
Разный стиль комментариев иногда до кода {а сейчас будет представлен }, а иногда после кода {это был описан }

Приоритет глобальных целей над локальными

Под локальным уровнем понимается уровень модуля, а не приложения или уровень приложения, а не группы однородных приложений. Так стремление к локальной оптимизации может привести к глобальной неоптимальности, стремление к локальной изящности к глобальной неуклюжести. Пример 1: стремление уйти от глобальных переменных может утяжелить систему, требуя создать заново объект, который мог быть передан через глобальную переменную. Пример 2: при создании новой формы, может показаться, что ее не нужно наследовать от базовой формы. Поначалу все Ok и экономятся ресурсы. Но потом от формы может потребоваться выполнение общей функции форм, которая уже реализована на уровне общей формы, но ее нет в частной форме. Значит, форму нужно будет доделывать, дублируя то, что уже сделано в общей форме.
Адекватность(неизбыточность, но полнота) отображения(Принцип минимальной избыточности). Любое отображение должно быть настроено на контекст учитывать все уже заданные параметры. Так если клиент является физлицом, то в эксплорере нужно отображать только счета физлиц; Если речь идет о кредитах, то в эксплорере счетов должны отображаться только ссудные счета. Это относится не только к ouput- элементам интeрфейса, но и к input-элементам: комбобоксам, листбоксам поставщикам данных.

Ковариантность при смене базового субъекта.

Сейчас многие Query содержат начальные значения параметров привязанные к текущему базовому субъекту. Это удобно для просмотра в DesignTime, но это может привести к непереносимости проекта. Чтобы этого не случилось, нужно в RunTime всегда устанавливать значение параметра запроса.

Никакого видимого мусора

Мусор то, что не используется. Неиспользуемые элементы интерфейса должны быть невидимыми.

Слоение

Функций отображения не должно быть в бизнес-объекте.
Реализация бизнес- класса не должна использовать объекты и методы уровня представления.
Функций связи с БД не должно быть в бизнес-объекте
Реализация бизнес-класса не должна использовать объекты и методы уровня хранения.

Слабая внешняя связность

Условие слабой связности класса(внешняя связность) мера использования в классе других классов этой же предметной области. Желательно иметь слабо связанные классы. Это свойство называется изолированностью.Объект не должен в своих методах использовать как параметр объект класса, расположенного в дереве ниже по уровню или использующего объект как элемент агрегации. Пусть B наследник A и в A есть метод A.Do(prA:B). Тогда его нужно убрать из A в B: B.Do(prA:A).

Сильная внутренняя связность

Условие сильной сцепленности класса(внутренняя связность) класс должен содержать прикладные методы, объединенные семантикой. Так присутствие в бизнес-объекте методов отображения нарушает этот принцип. Сбоку припёку не должно быть. Класс- не безыдейный конгломерат, а монолитное образование, подчинённое общей бизнес-цели. То, что может рассыпаться, должно быть разъединено. Слабая внутренняя связность должна привести к распаду бизнес-объекта на несколько других объектов.
Один класс один модуль
Общее правило: один класс один модуль. Во всяком случае, в одном модуле могут быть только сильно связанные объекты

Связь с БД

За связь с БД отвечают специальные объекты брокер БД.

Связь Форма-объект

Каждой форме сопоставляется рабочий объект. Создает рабочий объект только терминальная форма. Объект может передаваться форме извне. Форма может передавать его другой форме. Каждая форма имеет методы ShowOnObject, GetObjectFromForm. Это виртуальные методы.

Локальность

Если форма вызывается из модуля, то она, как объект, должна быть локальной. Это предотвратит возможную коллизию параллельного использования одной формы.

Исключения

Все прерывания фиксируются в регистрационном журнале и передаются клиенту.

Кодификация

Все кодификации, которые потенциально изменяемы реализуются как кодификаторы структуры {код, имя}. Постоянные кодификации(дни недели, например) реализуются как перечислимые типы.

Реализация

Отображение дерева объектов в информационную базу
В таблице Tip прописываются все объекты одинаковым образом независимо от типа. В таблице Movement отображается движение объекта (смена состояний и выполнение методов) одинаковым для всех объектов образом.
Объекту TopB сопоставляется таблица Tip(Top обычно зарезервированное слово в СУБД, поэтому имя Top таблицы оказалась неудобным), а каждому конкретному бизнес-классу сопоставляется конкретная таблица в БД: объект Homo<>таблица Homo и т.д.
Отношения между субъектами фиксируются в таблице Relation.
При создании объектов, входящих в иерархию наследования должно соблюдаться вот что: не может быть терминальной записи без головной. Это нужно иметь в виду при ручном формировании базы импорте таблицы Банки, например. Чтобы добавить сущность Банк, нужно чтобы была сущность Предприятие. Чтобы добавить сущность Предприятие, нужно чтобы была сущность Субъект. Чтобы добавить сущность Субъект, нужно чтобы была сущность TopD.
На общем(независящем от типа) уровне реализованы эксплорер объектов, операция, продвижка объектов. Эксплорер объектов работает одинаково для всех типов объектов. На конкретном уровне работают формы специфичные для каждого объекта.

Эксплорер объектов

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

Двигатели состояний

Это формы, позволяющие продвинуть состояние

Операции

Работа с операцией унифицирована формой fOperation.
Из этой формы можно выйти на спецификацию объектов операции и на платеж операции. Пример выхода на платеж по кнопке Специфицировать платеж операции:

Эксплорер операций

Аналогичен эксплореру объектов.
Конкретную операцию можно выдернуть из эксплорера и посмотреть по кнопке Индивидуализировать.

Доступ

Управление доступом к бизнес-объектам делается на бизнес-уровне. Доступ может быть по разрешению или по запрещению. Доступ может быть:

К типам бизнес-объектов (Запрещен или разрешен доступ ко всем экземплярам указываемого типа и всем методам объекта этого типа)
К методам типа (Запрещен или разрешен доступ к указанным методам всех экземпляров данного типа)
К экземплярам (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и всем методам объекта этого типа)
К методам экземпляров (Запрещен или разрешен доступ к специфицируемым экземплярам указываемого типа и специфицируемым методам объекта этого типа)
К формам

Структура решения

Решение есть совокупность проектов(терминология Visual Studio). В решении около 200 проектов. Все проекты кучкуются так:

Data-проекты. Каждому D-типу соответствует D-модуль.
Business-проекты. Каждому B-типу соответствует B-модуль.
Communication-проекты. Каждому C-типу соответствует C-модуль.
Presentation-проекты. Каждому P-типу соответствует Р-модуль.
Interface-проекты. Модули содержат описания интерфейсов.
Technology-проекты. Содержат утилиты.
Infra-проекты. Содержат инфраструктуру решения.
Resource-проекты. Содержат ресурсы проектов.
Service-проекты. Реализуются сервисы.
Gate-проекты. Выполняют роль шлюза между сервисом и приложениями. В одноадресном варианте шлюз не нужен.
Application-проекты. Содержат конкретные приложения.
Test-проекты.
Delivery-проекты.
Site-проекты.
Addin-проекты.

Отображение структуры решения в каталог ОС: каталог ОС решения повторяет структуру решения.

Структура приложения

Старт-программа

Головная программа аутентифицирует пользователя. В головном модуле создаются все интерфейсы. Т.е. головная программа склеивает реализацию и объявление интерфейсов. Создаётся диспетчер приложения. Интерфейсы передаются диспетчеру приложения. Диспетчер создаёт формы и передаёт им соответствующие интерфейсы.

Реализация распределенной обработки

WCF-сервис

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

Обработка трафика от сервиса к клиенту:
Принять С-объект по API с сервисом
Преобразовать С-объект в D-объект
Передать D-объект клиенту
Обработка трафика от клиента к сервису:
Принять D-объект от клиента
Преобразовать D-объект в C-объект
Передать C-объект сервису по API c сервисом

Задача сервиса:

Обработка трафика от клиента
Принять C-объект
Преобразовать его в D-объект
Передать D-объект функциональной части по локальному API
Обработка трафика к клиенту
Принять D-объект от функциональной части по локальному API
Преобразовать его в С-объект
Передать клиенту C-объект

Web-службы

Все как и для WCF с заменой WCF-сервиса на WEB-сервис. Последний есть клиент над WCF-сервисом, с тем, чтобы остальные WCF-клиенты не замечали WEB-сервис.

Специфика

Объекты учета

Счета бухгалтерского учета основной источник аналитики. Основной объект аналитики показатель. В его описание входит код объекта учета, которому соответствует показатель. Поэтому чрезвычайно важно хорошо построить множество кодов объектов учета.
Объекты учета образуют дерево объектов учета. Его ведение доступно пользователю.

Дерево типов

Все типы решения образуют дерево. Это дерево отображается в таблицу Tip. Id записи TypeId типа. Все объекты представлены в Tip записями, подчинёнными записи типа объекта. Например, записи объекта Homo подчинены записи типа Homo записи с Id=Homo.TypeId. Такое решение позволяет создать универсальный эксплорер объектов, отображающий иерархию типов.

Движение

Движение экземпляра объекта есть смена состояний. Движения всех объектов определяются одинаково объектом Movement и хранятся в таблице Movement.

Отношения

Явные отношения те, которые поддерживаются информационной моделью. Например, отношение подчинения между субъектами.
Все неявные отношения между объектами фиксируются в таблице Relation при установлении отношения. При заключении кредитного договора должно фиксироваться отношение кредитования. При появлении изменений к плану счетов между документом План счетов и изменениями к нему устанавливается отношение Изменение. Оно явно не присутствует в модели. Выделение каждого отношения в явное отношение перегрузит модель.
Отношение можно специфицировать, вызвав форму Отношение.

Транзакции и целостность

Все экземпляры любых объектов(в том числе и субъектов) имеют уникальный идентификатор. Сфера действия уникальности БД на все времена работы проекта.
Все экземпляры сценариев имеют уникальный идентификатор идентификатор сценария. Сценарий последовательность воображаемых операций. Все экземпляры любых операции имеют уникальный идентификатор идентификатор транзакции. Сфера действия уникальности все таблицы на все времена работы решения. Операция может породить другие операции, которые без первичной, начальной операции не имеют смысла. Если отменяется начальная операция, то отменяются все порожденные операции. Такая цепочка операций рассматривается как одна транзакция и все операции цепочки получают одинаковый идентификатор транзакции. Пример цепочки: Открытие счета Заключение договора на открытие счета Оплата открытия счета. Этой цепочкой связываются три объекта: счет, договор, платеж. Отмена открытия счета отменяет и договор и платеж.
Каждая операция оформляется как часть транзакции. Каждая операция начинается и заканчивается регистрацией в журнале регистрации.
Объект может иметь связанные, присоединенные к нему объекты в списке CoObjects. Эта связка хранится в БД.

Базовый субъект

Это субъект, который является владельцем эксплуатируемой системы.
Если в двустороннем отношении или функции неясно с кого начинать, то начинать нужно с базового субъекта. Примеры:

Операция Купить. Покупает базовый субъект, а продает его контрагент.
Операция Продать. Продает базовый субъект, а покупает его контрагент.
Отношение Договор. Первая сторона, субъект это базовый субъект. Вторая сторона договора, контрагент это контрагент базового субъекта.

Доступ и регистрация

Любая функция начинает с отметки в журнале регистраций и завершает отметкой в журнале регистраций.
Доступ дифференцируется так:

Доступ к типам
Доступ к методам типа
Доступ к экземплярам типа

Условие доступа может интерпретироваться двояко:

На разрешение (что не разрешено, то запрещено). Пример: Id=1 доступ только к объекту с Id=1
На запрещение(что не запрещено, то разрешено). Пример: Id=1 доступ только к объекту с sysId<>1

Хотелось бы

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

Так в чем же причина облома?

Попытаюсь классифицировать возможные причины неудачи:

Это идея-фикс? Это не мне судить.
Невостребованность?
В невостребованность не верю. Востребованность почти очевидна. Не будем же мы дискутировать о невостребованности давления, пульса, РОЕ в медицине. Например, в последнее время на слуху ССП- сбалансированная система показателей. А это подмножество аналитики.
Отсталость по сравнению с аналогичными проектами?
Плохая архитектура?
Инструментарий?
Сверхученость?
Маркетинг?
За спиной не стояла крупная фирма, имеющая историческую репутацию?

Я склоняюсь к совокупности последних трех причин.
И последнее, чтобы не посчитать статью за рекламу проекта, я готов бесплатно отдать весь проект в хорошие руки. Это около 20 Мб исходников. Конечно, там будет над чем и посмеяться: это был мой первый проект на C#. Многими из современных свойств C# там и не пахнет. В первую очередь, я бы изменил событийный подход первых выпусков C# на современный, более высокоуровневый подход к событиям. Во-вторых, можно было подумать о возможности асинхронной обработки.
Заканчивая и, думая нажать ли кнопку Опубликовать, начинаю терзаться смутными сомнениями А кому это нужно? И что тебе надобно, старичина? А потом решил не отвечать на этот вопрос

Всем желаю никогда не встречаться с обломом любимых проектов. Успехов!

Подробнее..

Категории: Анализ и проектирование систем , Развитие стартапа , Моделирование , Архитектура , Показатель , Бизнес-аналитика , Прогнозирование , Сценарий

Как оптимизировать работу аэропортов с помощью машинного обучения

05.11.2020 18:21:17 |

Автор: admin

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

Наша команда более десяти лет разрабатывает приложения, которые управляют работой крупнейших аэропортов: Франкфурт, Дублин, Манила, Джакарта, Майами, Пекин. Аэропорты используют приложения для оптимального управления ресурсами, организации работы и контроля за потоками информации аэропортов, координации расписания рейсов.

Аэропорты, использующие наши приложения

Крупные аэропорты обслуживают сотни тысяч пассажиров, тысячи тонн грузов и сотни самолётов в день. Так, за 2019 год аэропорт Франкфурта обслужил более 70 миллионов пассажиров, более двух миллионов тонн грузов и более пятисот тысяч самолётов. То есть, в день аэропорт обслуживал порядка 190 тысяч пассажиров, более пяти тысяч тонн грузов, более тысячи самолётов. Такие показатели связаны с огромным количеством человеческих и материальных ресурсов. Для типичного пассажира внутренняя работа аэропорта представляется чёрным ящиком. Мы проходим набор рутинных процедур: собственную регистрацию, регистрацию или получение багажа, трансфер до самолёта и полёт. Кажется, всё достаточно просто, однако, это лишь вершина айсберга. Каждый видимый нами процесс включает в себя десятки подпроцессов, в которых задействованы сотни людей. Логично, что задачей менеджеров аэропорта является оптимизация процессов для снижения затрат на привлечение сотрудников и других ресурсов. Мы попытались решить это задачу.

Идея звучит достаточно просто: Если вы знаете, сколько пассажиров обслуживает аэропорт в конкретный день вы знаете, какой набор ресурсов для этого потребуется: сколько сотрудников должно выйти на работу, сколько автобусов будет использовано для доставки пассажиров к самолётам, сколько горючего этим автобусам потребуется. Таким образом, задача сводится к определению количества пассажиров в аэропорту в конкретный день в будущем. Это позволит менеджменту привлекать заранее известное количество ресурсов, а значит, точнее рассчитывать расходы. Поставленная задача является задачей регрессии, в которой необходимо установить зависимость количества пассажиров от других параметров.

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

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

День недели. От дня недели зависит как количество туристических рейсов, так и количество рабочих перелётов.

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

Важнейшим же шагом на пути к решению задачи стало предположение о влияние экономической ситуации в стране на пассажиропоток. А именно о том, что экономической рост стимулирует пассажиропоток, и между двумя этими величинами существует зависимость. Для динамической оценки состояния экономики мы решили использовать DAX, а также уровень занятости населения.

DAX

Deutscher Aktienindex German stock index важнейший фондовый индекс Германии. Индекс вычисляется как среднее взвешенное по капитализации значение цен акций крупнейших акционерных компаний Германии.

Ежедневные значения DAX, а также процент работающих граждан Германии были взяты с Yahoo Finance. Для обучения модели использовались данные о ежедневном количестве пассажиров в аэропорте за 2018 и 2019 год, взятые на kaggle. Сезонность, день недели и характер праздничности дня мы посчитали вручную. На подготовительном этапе были использованы исключительно открытые источники, данные из которых были сгруппированы в единый датасет.

Влияние состояния экономики на пассажиропоток не носит молниеносный характер. Должно пройти время для того, чтобы люди ощутили изменения на себе. Поэтому судить о текущем дне по текущему DAX не совсем справедливо. Нужно было найти оптимальный сдвиг DAX от текущей даты по величине коэффициента корреляции между DAX и количеством пассажиров. Такой поиск обозначил 5 различных сдвигов со схожим результатом: от 15 до 19 дней относительно текущей даты.

Следующим шагом был выбор используемой модели. Нашей целью было получение минимального значения MAE, которое говорило бы об ошибке в (количество людей / день). Были испробованы различные варианты разбиения датасета на тест и трейн, различные сдвиги DAX относительно текущего дня, различные модели и их параметры. Конкретно были рассмотрены Linear Regressor, Random Forest, Gradient Boosting, SGDRegressor. Параметры для моделей подбирались с помощью GridSearchCV.

MAE

Mean Average Error

Расчёт ошибки и точности предсказания происходил отдельно для каждого сдвига DAX для каждой модели. Результатом каждого прогона были графики как на картинке ниже. На каждом из таких графиков изображено реальное количества пассажиров из данных теста (синим) и график предсказаний модели на данных того же тестового датасета (оранжевым). Для уверенности в правильном обучении модели и недопущении её переобучения также сравниваются показатели MAE для теста и трейна. Их близость говорит о корректности обучения. Решение о компетентности модели и выборе данных принимались на основе MAE, однако привычный показатель score модели для каждого набора (сдвиг DAX + модель) тоже принимался во внимание.

Графики для Linear Regression со сдвигом DAX в 15 дней

При построении всех возможных комбинаций стало понятно, что с использованием любой модели наилучший результат достигается при использовании DAX со сдвигом в 15 дней. Как говорилось выше, при выборе модели, мы ориентировались на минимальность MAE. На основе этого критерия была выбрана модель Gradient Boosting с ошибкой в 297 человек. Это означает, что ошибка в день в среднем составляет вместительность одного самолёта.

Следующим шагом стало сохранение обученной модели с помощью pickle, использование REST API для взаимодействия с моделью и создание Docker-образа. После контейнеризации получаем готовое приложение, которое отвечает на вопрос о количестве пассажиров в аэропорту через 15 дней, исходя из DAX, уровня безработицы и информации о том, является ли день праздничным. Данное решение может быть встроено в инфраструктуру любого аэропорта при наличии данных о пассажиропотоке в прошлом. Необходимо лишь переобучить модель на данных конкретного аэропорта.

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

Подробнее..

Категории: Python , Разработка , Оптимизация , Машинное обучение , Транспорт , Финансы в it , Биржа , Исследования и прогнозы в it , Экономика , Прогнозирование , Блог компании deutsche telekom it solutions (ex t-systems) , Deutsche telekom it solutions , Аэропорт

Перевод Индексы PSI и CSI лучшие метрики для мониторинга работы модели

14.08.2020 18:11:43 |

Автор: admin

Представляем вам перевод статьи, опубликованной в блоге towardsdatascience.com.
Ее автор, Juhi Ramzai, рассказала об эффективных методах проверки моделей PSI (индексе стабильности популяции) и CSI (индексе стабильности характеристик).

Изображение предоставлено автором

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

А теперь перейдем к основной теме данного поста. Мы узнаем все о PSI (индексе стабильности популяции) и CSI (индексе стабильности характеристик), которые являются одними из самых важных стратегий мониторинга, используемых во многих областях, особенно в сфере оценки кредитных рисков.

Обе эти метрики (и PSI, и CSI) сосредоточены на изменениях в РАСПРЕДЕЛЕНИИ ПОПУЛЯЦИИ.

Основная идея этих метрик заключается в том, что модель прогнозирования лучше всего работает, если данные, использованные для ее обучения, не слишком отличаются от валидационных / OOT (out of time) данных в плане экономических условий, основополагающих допущений, стиля ведения кампании, направленности и т. д.

Например, мы разработали модель прогнозирования показателей оттока пользователей кредитных карт в условиях нормальной экономической ситуации. Затем мы приступили к тестированию этой модели, но уже в условиях экономического кризиса. Вполне возможно, что в этом случае модель не выдаст точный прогноз, поскольку не сможет уловить тот факт, что в разных сегментах дохода распределение популяции могло значительно измениться (и это могло привести к высокому фактическому уровню оттока пользователей). В результате мы получим ошибочные предсказания. Но так как сейчас мы это уже понимаем, то можем перейти к проверке изменений распределения популяции между временем разработки (DEV time) и настоящим временем. Так мы получим ясное представление о том, можно ли полагаться на результаты, предсказанные моделью, или нет. Именно это и показывают важные метрики мониторинга PSI и CSI.

Индекс стабильности популяции (PSI)

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

Приведенное выше определение как нельзя лучше объяснено в данной исследовательской работе. Я также привела ссылку на него в конце этого поста.

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

Индекс PSI отражает тенденцию к изменению популяции в целом, в то время как индекс CSI обычно сосредоточен на используемых индивидуальных переменных модели.

Источник

Изменение в распределении популяции может быть связано:

с изменениями в экономической среде, такими как экономический кризис, COVID-19 и т. д.;
изменениями в источниках данных;
изменениями во внутренней политике, которые прямо или косвенно влияют на распределение популяции;
проблемами с интеграцией данных, которые могут привести к ошибкам в данных;
проблемами при программировании/кодировании, такими как реализация модели или пропуск некоторых важных этапов в коде оценки качества работы модели.

Поскольку изменение распределения не обязательно должно сопровождаться изменением зависимой переменной, индекс PSI также можно использовать для изучения сходства/различия между любыми выборками. Например, для сравнения уровня образования, дохода и состояния здоровья двух или нескольких популяций в социально-демографических исследованиях.

ШАГИ ДЛЯ РАСЧЕТА ИНДЕКСА PSI (Ссылка)

Сортируем оцениваемую переменную по убыванию в оцениваемой выборке.
Разделяем данные на 10 или 20 групп (дециль).
Рассчитываем процент записей в каждой группе на основании оцениваемой выборки.
Рассчитываем процент записей в каждой группе на основании выборки разработки.
Рассчитываем разницу между шагами 3 и 4.
Берем натуральный логарифм (Шаг 3 / Шаг 4).
Умножаем шаг 5 на шаг 6.

ТАБЛИЦА EXCEL ИНДЕКСА PSI:

Изображение предоставлено автором

ПРАВИЛА ТОЛКОВАНИЯ (Ссылка)

Индекс PSI < 0,1 без изменений. Вы можете продолжить использование существующей модели.
Индекс PSI >= 0,1, но меньше 0,2 требуются небольшие изменения.
PSI >= 0,2 требуются значительные изменения. В идеале модель больше не должна использоваться. Ее следует обучить заново / заменить другой.

Также можно использовать условный диапазон форматирования красную, желтую и зеленую зоны (Red-Amber-Green zone). Красный цвет тревожное состояние, при котором индекс PSI составляет более 20%, желтый это 1020%, при этом модель должна находиться под наблюдением, а зеленый это этап, на котором модель считается пригодной для использования, т. е. < 10%.

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

Индекс стабильности характеристик (CSI)

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

Это помогает определить, какая изменяющаяся переменная в основном вызывает изменение метрик качества модели.

Когда эффективность модели ухудшается, проверка изменений в распределении переменных модели может помочь выявить возможные причины этого. Как правило, это делается после проверки, в результате которой выяснилось, что индекс PSI не находится в зеленой зоне (< 0,1 в целом). Таким образом можно проверить, какие переменные в основном задают распределение популяции.

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

При вычислении индекса CSI предпринимаются те же действия, что и при вычислении индекса PSI. Разница лишь в том, что решение принимается на основе значений выборки с этапа разработки для конкретной переменной (путем разбиения их на диапазоны и установки пределов этих значений в качестве пороговых значений). Затем при вычислении значений частот для любой валидационной / внеплановой (ООТ) выборки просто применяются те же пороговые значения к данным и вычисляются значения частоты (при помощи той же формулы, которую мы использовали при вычислении индекса PSI).

ТАБЛИЦА EXCEL ИНДЕКСА CSI

Изображение предоставлено автором

Таким образом, индекс PSI может помочь определить расхождения в распределениях популяций в целом, если они значительны, а индекс CSI может помочь еще больше сузить их до нескольких ответственных за это переменных.

Ссылка на исследование

Подробнее..

Категории: Искусственный интеллект , Машинное обучение , Machine learning , Data science , Big data , Data mining , Сбор данных , Блог компании plarium , Csi , Прогнозирование , Psi

Почему банки Европы скупают IT-шников

20.08.2020 04:17:11 |

Автор: admin

Вот среднегодовые вложения в IT нескольких крупнейших европейских банков:

BNP Paribas $7,1 млрд
HSBC $6,0 млрд
Societe Generale $4,7 млрд
Deutsche Bank $4,5 млрд
UBS $3,5 млрд
Barclays $3,5 млрд
RBS $2,9 млрд
Credit Suisse $2,9 млрд
Commerzbank $1,4 млрд

Это затраты как на собственные IT-отделы, так и на приобретение сторонних продуктов. Первая четвёрка в совокупности обгоняет Google (Alphabet Inc.) с его $21,4 млрд.

Тренд на цифровизацию постоянно звенит в новостях. Например, о внутренней реструктуризации Deutsche Bank, в результате которой 975 человек лишилось привычных мест трейдеров и банкиров. При этом половина сотрудников банка заняты в IT. Или о партнёрстве британского TSB Bank с IBM Services для внедрения облачных технологий и превращения первого в по-настоящему цифровой бизнес. Бюджет на реализацию проекта оценивается в 120 млн.

Не знаю, как для вас, а для меня это не просто 120 млн, а 120 млн фунтов стерлингов, Карл!.

Эта статья о том, что европейские банки хотят в IT. Это хорошая новость для нас с вами (ИТ-шников). Делюсь информацией, что сейчас происходит в Европе. Точнее, что нам удалось накопать. Будет много ссылок на источники.

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

Инвестируя в IT-технологии, крупнейшие европейские банки выбирают следующие финтех-компании:

источник CB Insights

В центре таблицы перечислены логотипы финтехов, в которые вкладывает средства тот или иной банк. Для наглядности они распределены по отраслям (столбцы):

блокчейн
анализ данных
личные финансы
управление капиталом
фондовые рынки
кредитование
электронные платежи
регуляторные технологии

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

Судя по таблице, у компаний R3 (блокчейн) и AcadiaSoft (регуляторные технологии) дела идут очень неплохо.

Итак, банки приобретают финтех, стимулируя спрос на него. Особенно активным он стал в текущем году. Посмотрим, с чем это связано и к чему успело привести.

Причины финтех-бума

1. COVID-19

Начну с него. Надеюсь, пирожок народного интереса к вирусу ещё не успел совсем остыть.

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

За ближайшие полгода большинство европейцев станет использовать электронные кошельки чаще, чем в период самоизоляции. По данным Deutsche Bank, к 2025 г. этот метод оплаты станет вторым по популярности после банковских карт. В связи с уходом от наличных платежей, 80% центральных банков мира разрабатывает собственную цифровую валюту. У 40% готов MVP, а 10% уже играются с пилотными проектами.

2. GAFA

Большая четвёрка Google, Apple, Facebook и Amazon тоже выходит на европейский рынок финансовых услуг. 2019 год принёс такие новости почти от каждого из брендов. Google объявил о запуске личных банковских счетов для пользователей. Проект носит кодовое название Cache и разрабатывается совместно с Citigroup.

Apple выпускает собственные кредитные карты, которые вскоре станут доступны в Европе. Facebook разрабатывает криптовалюту. Amazon приобретает финтехи, выстраивая свою финансовую экосистему.

Учитывая огромную аудиторию, доступ к обширным данным и возможности их обработки, эти гиганты столь же опасны для традиционных банков, как и привлекательны для обычного пользователя, как сказала бы Екатерина II.

3. Необанки

Ещё один грозный соперник, задающий высокую планку сервиса, необанки, существующие только в онлайне. По итогам 2019 г. их аудитория в Европе составила 15,3 млн чел. К 2025 г. её размер оценивается в 5085 млн чел., или 20% населения старше 14 лет.

Темпы привлечения клиентов необанками наглядно демонстрирует стартап Zelf. Существуя без приложения, он работает через мессенджеры и позволяет оформить карту только с помощью голоса. За первый месяц число предзаказанных карт превысило 260 000.

4. Мессенджеры и соцсети

Возможность перетереть со своим банком в чатике действительно востребована. Онлайн-переписка через сторонние платформы становится для банков полноправным каналом взаимодействия с клиентами.

43% всей аудитории интернета использует соцсети для работы, при этом 63% находят общение в мессенджерах более удобным и приватным по сравнению с другими видами коммуникации.

48% пользователей связывается с организациями через различные онлайн-чаты, а не по телефону. При этом 47% платёжеспособной аудитории с радостью ещё и совершит в мессенджере безопасный платёж.

5. Требования регулятора

Директива PSD2, введённая Европейской комиссией в 20182019 гг., обязывает банки предоставлять платёжным сервисам свободный и безопасный доступ к счетам клиентов. Формально она не требует открытого API но проще всего выполняется именно в такой форме. Это основа для Open Banking открытой экосистемы, где кроме банка, действует целый ряд провайдеров платных услуг.

В то же время, по стандартам Базеля III (стандарт регулирования банковской деятельности), инвестиции в IT вычитаются из капитала банков как нематериальные активы. Человеческим языком банк не сможет потраченными на IT деньгами закрывать свои долги. Это вынуждает банки рачительно подходить к выбору направления технологического развития.

6. Супераппы

Азиатский тренд, хорошо иллюстрирующий будущее открытого банкинга. WeChat, Grab, AliPay, Zalo и т.п. приложения, позволяющие выполнить множество операций с одного экрана. Например, пообщаться с друзьями, забронировать отель, вызвать такси, купить билет на самолёт, перевести деньги, заказать еду и т.д. Каждый суперапп способен стать единственным приложением для жизни.

Бренды в Евросоюзе пока не запустили полноценных аналогов. Шаги в этом направлении на Западе делают, например, Google Maps. Через них уже можно бронировать столики в ресторанах, заказывать такси и приобретать билеты на американские поезда. Есть положительные тенденции и в России (смотри приложения Яндекс, Тинькофф).

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

Рост применения технологий иллюстрирует и статистика банковских вакансий. Так, спрос на IT-специалистов продолжал увеличиваться даже во время пандемии. Правда тут нашлась только американская статистика. Но предположу, что в Европе этот тренд тоже себя проявил.

Например, в Goldman Sachs 44% открытых позиций для IT.

источник eFinancialCareers

Айтишникам в начале карьеры и при смене специализации стоит всерьёз задуматься о финансовой сфере. Вероятно, скоро в банкинге станет так же весело, как в геймдеве.

И что выходит?

Перечисленные факторы сформировали новый уровень пользовательских ожиданий. 60-85% клиентов банков всех возрастов предпочитают пользоваться мобильным и интернет-банкингом для повседневных транзакций, а 1025% даже для сложных операций.

Тем не менее, одного наличия банковского приложения уже недостаточно. Пользователи ждут безупречного опыта взаимодействия с ним. Так, 40% аудитории бросает цифровой продукт, если процесс регистрации и/или начала работы кажется им слишком сложным (а значит, и для дизайнеров интерфейсов работа найдётся).

Клиенты банков готовы пробовать услуги других брендов в поисках лучшего сервиса. Это объясняет огромные притоки аудитории в необанки. Например, к британскому Monzo еженедельно подключается по 55 000 человек, Revolut оценивает приток в 600 000 в месяц, немецкий N26 охватил 25 стран и достиг общей клиентской базы в 5 млн чел. Поскольку далеко не все пользователи при этом закрывают аккаунты в своих старых банках, драматичность текучки легко недооценить.

Новые приоритеты пользователей также включают:

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

В то же время, по данным Deloitte, текущие приложения банков не отвечают цифровым нуждам клиентов. Плохо реализованы процесс входа в приложение (люди недовольны в 41% случаев), интеграция со внешними сервисами (33%), и в общем люди хотят от банковских приложений больше функциональности.

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

источник Statista

Barclays Mobile Banking (Великобритания) 7 млн чел. в месяц
CaixaBank (Испания) 6 млн чел. в месяц
MaBanque (Crdit Agricole) (Франция) 5 млн чел. в месяц
Sparkasse (Германия) 2 млн чел. в месяц
Intesa Sanpaolo Mobile (Испания) 2 млн чел. в месяц

Скромный трафик в сравнении с технологическими стартапами. Всё говорит о том, что лидеры традиционного банкинга ещё не освоились в новой реальности.

Что касается общей удовлетворённости банками, картина такова:

Великобритания:

источник Fidelity National Information Services, Inc.

Германия:

источник Fidelity National Information Services, Inc.

Очевидно, что банки без отделений (Direct Banks на графиках), к которым относятся полностью цифровые банки, гораздо более любимы своими клиентами. Навряд ли традиционным банкам нравится этот разрыв.

К слову, отличная новость для российских технарей: менее 60% европейских вакансий могут быть закрыты резидентами. Учитывая популярность удалённой работы, растущую с весны, у наших соотечественников есть все шансы претендовать на место в перспективных необанках.

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

Это строчка обозначает конец статьи.

Для вас писали: Денис Элиановский, Станислав Лушин. Спасибо Станиславу за огромную проделанную работу по сбору статистики. А также Елене Ефимовой за картинку в хедере, Татьяне Китаевой за редактуру.

Подробнее..

Категории: Карьера в it-индустрии , Аналитика , Финансы в it , Статистика в it , Исследования и прогнозы в it , Банки , Прогнозирование , Финтех , Евросоюз , Fintech , Индустрия ит

Как построить прогнозную модель для маркетолога в SAP Analytics Cloud без привлечения датасайнтистов

17.12.2020 14:07:58 |

Автор: admin

Сегодня популярность проектов data science очень высока и бизнес понимает их важность и значимость. Рынок наполнен специалистами в этой области, которые умеют добиваться впечатляющих результатов. Но такие проекты нередко бывают дорогостоящими, и не всегда для простых задач нужно привлекать профессионалов в этой области. Создание некоторых прогнозов вполне по силам самим бизнес-пользователям. Например, специалисты из отдела маркетинга могут прогнозировать отклик на маркетинговые кампании. Это становится возможным при наличии инструмента, позволяющего за несколько минут построить прогноз и легко интерпретировать результаты с точки зрения бизнес-смысла.

SAP Analytics Cloud (SAC) облачный инструмент, совмещающий в себе функции BI, планирования и прогнозирования, он также оснащен множеством функций расширенной аналитики: интеллектуальными подсказками, автоматизированным анализом данных и возможностями автоматического прогнозирования.

В этой статье мы расскажем о том, как построено прогнозирование в SAP Analytics Cloud, какие сценарии доступны на сегодняшний день, а также как этот процесс может быть интегрирован с планированием.

Функциональность Smart Predict ориентирована на бизнес-пользователя и позволяет строить прогнозы высокой точности без привлечения специалистов Data Science. Со стороны пользователя системы прогноз происходит в черном ящике, но в реальности это, конечно же, не так. Алгоритмы прогнозирования в SAC идентичны алгоритмам модуляAutomated Analytics инструмента SAP Predictive Analytics. Об алгоритмах, лежащих в основе этого продукта, есть множество материалов, мы предлагаем прочитать эту статью. На вопрос: Получается, Automated Analytics переехал в SAP Analytics Cloud? - мы отвечаем - Да, но пока только частично. Вот какая разница и сходство в функциональных возможностях инструментов (рис.1)

SAP Analytic Cloud в настоящее время предлагает 3 прогнозных сценария:

Классификация. В данном случае предполагается бинарная классификация: предсказываются значения целевой переменной, которая может иметь только два значения -да и нет или 0 и 1. Примерами сценария классификации могут быть:

Прогноз оттока клиентов, где целевая переменная предсказывает, уйдет клиент или нет.

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

Выявление мошенничества с целевой переменной, указывающей, была ли транзакция или требование мошенническим, или нет.

Регрессия. Предсказывает числовое значение целевой переменной в зависимости от переменных, описывающих ее. Примеры регрессионных сценариев:

Количество клиентов, посещающих магазин в обеденное время.

Выручка от каждого клиента в следующем квартале.

Цена продажи подержанных автомобилей.

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

Выручка по каждой продуктовой линейке в течение следующих нескольких кварталов.

Количество велосипедов, арендованных в городе в течение следующих нескольких дней.

Командировочные расходы в ближайшие несколько месяцев.

В процессе прогнозирования мы будем работать с тремя типами датасетов: тренировочным, прикладным и результирующим (рис. 2)

Процесс прогнозирования в SAP Analytics Cloud осуществляется в несколько простых этапов. Мы рассмотрим его на примере прогнозирования оттока клиентов интернет-магазина. Для начала нам необходимо загрузить в систему тренировочный датасет из системы-источника или excel файла. Также SAP Analytics Cloud позволяет прогнозировать в режиме Live (избегая загрузки данных в облако) на таблицах SAP HANA. В этом случае для пользователя SAC процесс остается неизменным, но построение прогноза происходит на стороне SAP HANA с использованием библиотеки Automated Predictive Library (APL).

Наш тренировочный датасет имеет следующие поля:

Customer ID	Уникальный ID каждого клиента
Usage Category (Month)	Количество времени, проведенное клиентом на портале в текущем месяце
Average Usage (Year)	Среднее количество времени, проведенное клиентом на портале за прошедший год
Usage Category (previous Month)	Количество времени, проведенное клиентом на портале за прошедший месяц
Service Type	Флаговая переменная, указывающая тип сервиса клиента: премиум или стандарт
Product Category	Категория продукта интернет-магазина, наиболее часто заказываемая клиентом
Message Allowance	Флаговая переменная, указывающая, давал ли клиент согласие на получение сообщений
Average Marketing Activity (Bi-yearly)	Среднее число маркетинговых предложений для клиента за последние 2 года
Average Visit Time (min)	Среднее количество времени, проведенное клиентом на портале за каждый визит
Pages per Visit	Среднее число страниц интернет-магазина, посещаемых клиентом за один визит
Delta Revenue (Previous Month)	Разница между выручкой от данного клиента за предыдущий и текущий месяц
Revenue (Current Month)	Выручка от данного клиента в текущем месяце
Service Failure Rate (%)	Доля случаев, когда пользователь сталкивался с ошибками в работе портала
Customer Lifetime (days)	Количество дней с момента регистрации
Product Abandonment	Число продуктов, которые были помещены клиентом в корзину, но не оплачены за последний квартал
Contract Activity	Флаговая переменная, указывающая, отказался ли данный пользователь от услуг интернет-магазина. Целевая переменная, которую мы будем прогнозировать.

Следующим шагом построение прогноза будет выбор сценария прогнозирования.

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

После этого мы создаем прогнозную модель и выбираем заранее подготовленный датасет, как источник данных для обучения. У пользователя также есть возможность редактировать метаданные. Далее мы выбираем целевую переменную, ее мы будем прогнозировать. В нашем случае это переменная Contract Activity, идентифицирующая отток клиентов. Также мы можем исключить некоторые переменные, если понимаем, что они никак не повлияют на формирование прогноза. Например, в нашем случае точно можно исключить Customer ID. Это может ускорить процесс выполнения прогноза, но их сохранение не мешает процессу моделирования.

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

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

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

Прогностическая сила (KI) указывает на долю информации в целевой переменной, которую могут описать другие переменные модели (объясняющие переменные). Гипотетическая модель с прогностической силой 1,0 является идеальной, поскольку позволяет объяснить 100% информации целевой переменной, а модель с прогностической силой 0 является чисто случайной.

Достоверность прогноза (KR) показывает способность модели достичь той же производительности, когда она применяется к новому набору данных, имеющему те же характеристики, что и обучающий набор данных. Приемлемой считается достоверность прогноза не менее 95%.

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

Кроме этого, на рисунке ниже мы видим кривую производительности AUC ROC. Ось X показывает, какой процент от общей выборки составляют положительные цели; ось Y представляет их верно идентифицированный процент, который обнаружил алгоритм. Здесь необходимо пояснить, что положительными целями в данном случае считается целевая группа, а именно клиенты, отказавшиеся от услуг интернет-магазина.

Зеленая кривая олицетворяет некую идеальную модель с максимально возможным процентом обнаруженной цели. Например, если 25% общей выборки будут составлять ушедшие клиенты, то идеальная модель правильно классифицирует все 25% таких клиентов.

Красная кривая показывает минимальный процент обнаруженной цели, полученный случайной моделью. То есть случайно взяв 10% населения, вы бы определили 10% клиентов.

Синяя кривая показывает процент обнаруженной цели с использованием нашей модели. Например, если 10% выборки составляют ушедшие клиенты, мы обнаруживаем примерно 75%. Чем ближе синяя линия подходит к зеленой, тем лучше модель. Чем больше расстояние между красной и синей линиями, тем больше лифт модели.

Кроме того, SAC предоставляет возможность увидеть, как именно ключевые факторы влияют на целевую переменную.

Например, посмотрим более подробную аналитику по предиктору Average Visit Time, показывающему среднее количество времени, которое клиент проводит на портале интернет-магазина. По умолчанию предлагается отследить влияние этого фактора на столбчатой диаграмме, но также существует возможность настройки различных типов визуализации.

Мы видим, что клиенты, проводившие на страницах интернет-магазина от 10 до 22 и от 1 до 3 минут, имеют наибольшую склонность отказаться от услуг. Напротив, покупатели, находящиеся на портале от 3 до 7 и от 7 до 10 минут, показывают наименьшую вероятность уйти. Результаты выглядят волне логично: уходят те, кто проводили на сайте или слишком мало, или слишком много времени. Подобный анализ можно провести по всем ключевым предикторам.

Также для оценки качества получившейся модели SAC предлагает проанализировать матрицы неточностей, различные графики, иллюстрирующие эффективность модели (лифт, чувствительность, кривая Лоренца и плотность) и смоделировать возможные выигрыши и проигрыши от использования данного прогноза.

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

На выходе мы получаем датасет с прогнозными значениями целевой переменной, на основе которого может быть легко сформирована модель данных. Она, в свою очередь, может являться источником данных для построения аналитической отчетности в SAC. Например, для этого кейса мы использовали интеллектуальную функцию Smart Discovery и получили автоматических дашборд на спрогнозированных данных.

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

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

Кроме того, в процессе создания отчетов пользователи также могут использовать прогностические функции, например, автоматический прогноз. Он позволяет продлить график временного ряда.

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

Также прогноз можно добавлять в таблицы и использовать оттуда данные, например, как базу для будущего плана.

Таким образом, процесс прогнозирования в SAP Analytics Cloud достаточно прост и максимально ориентирован на бизнес-пользователя, но дает возможность получения прогностических моделей высокого качества для решения типовых бизнес-задач.

Данный инструмент является stand-alone решением и может стать частью мультивендорной архитектуры. Интеграция SAP Analytics Cloud с решениями SAP нативна. Кроме того, существует стандартный бизнес контент для различных индустрий и линий бизнеса. Отчеты могут быть дополнены прогнозными и плановыми данными, а также обогащены функциями расширенной аналитики.

Автор Анастасия Николаичева, архитектор бизнес-решений SAP CIS

Подробнее..

Категории: Облачные сервисы , Облака , Analytics , Cloud , Блог компании sap , Аналитика данных , Прогнозирование , Bi , Sap analytics cloud

	Русский
	English