Совсем недавно состоялся официальный релиз аналитической платформы Loginom, но она продолжает непрерывно совершенствоваться. 26 сентября 2018 года в рамках конференции Loginom Day 2018 Алексей Арустамов рассказал о новых возможностях платформы.
pdfLoginom 6.2 - обзор нововведений
Текстовая расшифровка выступления
Здравствуйте. Очень рад видеть тут такое большое количество людей. Чувствуется, что аналитика становится всё более и более популярной. Сейчас уже, наверное, всех достали аналитикой, потому что, когда открываете журнал, там везде анализ под тем или иным соусом.
Я хотел бы рассказать в этой части презентация о том, что произошло с того момента, как мы объявили о выходе Loginom, это было 2 ноября прошлого года (почти год назад). Что за это время было сделано, какие возможности появились, что в ближайшее время появится.
Во-первых, за это время продукт очень интенсивно развивался. 22 ноября мы только-только показали продукт людям, это уже через месяц предоставили бета-версию, и 25 января продукт увидел свет. Спустя, буквально, полтора месяца после этого он стал финалистом конкурса «Лучшие аналитические системы», который производился аналитическим агентством при правительстве Российской Федерации. Вообще, продукту было полтора месяца – видимо, он произвел хорошее впечатление на аналитиков.
После этого мы буквально каждый месяц выпускали патчи, старались его развивать как можно быстрее. Сейчас у нас уже на очереди 6 патч к продукту, и готовится к выходу версия 6.2, про которую я буду очень много говорить.
Хотелось бы сказать о том, как все развивалось до сегодняшнего момента. Когда продукт только появился, как и в любом новом продукте, там были какие-то проблемы, которые мы еще в тот момент не могли отловить, ошибки и всякие разные недочеты. Но надо понимать, что продукт только появился на свет, тем более, что он радикально отличается от предыдущей реинкарнации, в частности Deductor. Мы его фактически полностью переписали с нуля, поэтому трудно выпустить сразу идеальный продукт. Мы старались и продолжаем работать в этом направлении.
За это время было произведено более 300 различного рода улучшений. Большая часть улучшений касалась повышения стабильности. Исправлялись различного рода ошибки. Кроме того, некоторые типы ошибок возникали в ситуациях, которые мы вообще не могли у себя внутри отследить. То есть, это нужно было обязательно внедрять, смотреть, как это у людей работает, только тогда можно было хоть что-то отловить.
Много времени уделяли повышению оптимизации производительности. Разгоняли всё, что только можно, и настолько у нас хватало сил. Над этим тоже продолжаем работать.
Также исправляли вещи, которые касаются мелких улучшений интерфейса. «Мелких», потому что в основном интерфейс остался такой же, как и был (мы его достаточно неплохо проработали), но всегда возникают недочеты. Мы не можем все их отловить сразу, и, соответственно, мы все это улучшали постепенно.
Я хотел бы рассказать о функционале, который появился, а не об этих мелочах. Что касается направлений работы, куда мы прикладывали основные усилия, конечно, добавление новых алгоритмов, связанных с анализом данных. Мы говорим о том, что у нас продвинутая аналитика, поэтому должен быть богатый набор алгоритмов.
Много усилий приложили для того, чтобы каким-то образом улучшить визуализацию, потому что она помогает интерпретировать результаты.
Интеграция тоже немаловажная вещь, хотя бы потому, что в Loginom вообще отсутствует механизм ввода данных. Мы обязательно должны получить данные из какого-то источника, потом что-то с ними сделать, куда-то выгрузить. Поэтому важно было, чтобы интеграция была максимально простая, комфортная. В противном случае, это опять превратиться в проблемы. От которых мы столько времени стараемся отходить.
Следующее направление - это повышение удобства разработки. Loginom - это же конструктор, и поэтому в нем, все равно, что-то разрабатывается. Это не программирование в классическом виде, это - визуальное проектирование.
Последний вещь - это просмотр отчетов. Тут я хотел бы немножко остановиться на функционале, который касается просмотра отчетов. Дело в том, что на рынке присутствует сейчас много продуктов, которые позволяют хорошо визуализировать. Много продуктов, которые эту задачу решают хорошо.
Довольно часто я сталкиваюсь с такой ситуацией, когда люди говорят: «Чем ваш продукт лучше, чем какое-то средство визуализации?» Для меня это – загадка, потому что у этих продуктов совершенно разные функционалы, мягко говоря, ничего общего друг с другом не имеющий. Я считаю, что в нашем продукте должны быть средства визуализации, но, другое дело, что, если мы возьмем любой продукт, который отвечает за визуализацию результатов, в нем тоже есть механизмы, которые отвечают за расчёт каких-то показателей: среднее, группировка, - какая-то достаточно простая обработка данных.
Я считаю, если какие задачи можно решить простыми способами без каких-то дополнительных усложнения и без подключение еще одного дополнительного инструмента, конечно, надо использовать наиболее подходящие подручные инструменты. Поэтому, в процессе, когда вам требуется какая-то визуализация, не требуется какая-то сложная обработка, то продукты, типа Loginom, вообще не нужны.
Я думаю, что на рынке есть место и для более простой визуализации. Довольно многих клиентов не требуют какие-то навороты, связанные с отображением, с географическими картами, с отображением на мобильных устройствах.
Многим достаточно просто получить отчеты, это их вполне устраивает. Я думаю, что ситуация, когда у пользователя системы не будет каких-то особых требований или претензий по поводу красивой или навороченной визуализации, тогда наш продукт их вполне удовлетворит. Таких клиентов довольно много, в конце концов, не всем нужны навороты.
Теперь перейдем к алгоритмам. Но, перед тем, как перейти к описанию алгоритмов, я хотел бы сказать. Дело в том, что «добавлять в систему еще один алгоритм» - это не наша задача. Я считаю, что это довольно глупо, во-первых, есть много бесплатных библиотек. И зачем изобретать ещё одну штуку, которая конкурирует с этими десятками бесплатных библиотек.
На самом деле, мы не ставим задачу сделать в системе 500 методов, 600 методов. Наша задача – сделать алгоритм максимально простым. Я абсолютно уверен, что если этот метод решает какую-то задачу, но пользоваться им сложно, КПД от его использования будет маленьким, потому что люди не любят головную боль.
Когда мы добавляли алгоритмы, мы реализовали не просто сами эти методы, мы обязательно уделяли много внимания тому, насколько легко и просто можно будет пользоваться этими методами и алгоритмами, которые встраиваются в Loginom .
Для того чтобы ими можно было легко пользоваться, необходимо было решить несколько задач. Во-первых, вы знаете, что когда строятся какие-то модели, надо проверять структуру этой модели.
Следующее направление, которое тоже отнимает много времени, - это отбор значимых фактов. Люди любят собрать побольше фактов, и пусть система всё перелопатит. И этим делом тоже не хочется долгое время заниматься. Хочется, чтобы система там быстренько всё сделала на основе метрик, индикаторов, показателей.
Ещё одна важная штука - это защита от переобучения. Сейчас модели становится достаточно сложными, и многие считают, что это хорошо. Но, когда это происходит, система уже не в состоянии обобщить, а она в состоянии только запомнить что-то. Нужно было обеспечить какие-то механизмы, которые могли бы защитить от переобучения.
И последняя важная вещь, которая касается переобучения. Построить модель - это только часть проблемы, если мы хотим, чтобы этой моделью кто-нибудь пользовался, необходимо, чтобы пользователи могли интерпретировать полученные результаты, потому что, если у нас есть какая-то модель, как «черный ящик», она хороша для того, чтобы рассказать, как это круто.
Но люди не очень любят пользоваться «черным ящиком», особенно когда речь идет о задачах, где потери достаточно большие. Как только денег много тратится, люди боятся чихнуть, потому что понятно, что быстро построенный «черный ящик» может промахнуться. Поэтому обязательно должны быть какие-то механизмы, позволяющие понять, что построила модель, и интерпретировать всё это. А для этого помогают различные средства визуализации.
Те методы и алгоритмы, которые у нас реализованы, мы делали кучу обвязки, которая позволяла решать такие задачи, о которых я говорил. Только в этом случае аналитика становится ценной. Потому что люди хотят использовать, потому что они могут ее использовать.
Теперь пройдемся по тем алгоритмам, которые мы добавили в продукт, начиная с выхода версии 6.0.
Что это такое и зачем это нужно? Когда мы пытаемся анализировать данные, очень часто в данных большое разнообразие показателей. Например, мы анализируем риски, у нас есть 500 городов, мы мне должны, по большому счёту, для каждого города строить свою самостоятельную модель. Это бесполезно. И бесполезно брать каждый город и подавать, как входной фактор, потому что их много, и данных не хватит, чтобы построить адекватную модель. Поэтому нужно обязательно снизить разнообразие.
Один из вариантов снижения разнообразия это – квантование. Разбить большое множество на некоторые куски, приблизительно похожие или более-менее однородные. Например, если мы говорим про города, можно собрать большие города в одну кучу, средние - ещё одну кучу, маленькие - в третью кучу. В этом случае модель получается более простая. А вообще, чем проще модель, тем лучше. Не верное представление о том, что модель обязательно должна быть сложной. Наоборот, модель должна быть простая на столько, на сколько это возможно. Конечные классы по-другому называются как «квантование».
Квантование - это разбиение множества на диапазоны. Когда мы говорим о реализации конечных классов в Loginom, там считаются все показатели, которые объясняют, почему именно таким образом было проведено квантование, считается вес доказательств, считается информационная значимость, автоматически отбираются факторы, ранжируются. В результате, когда мы просто проводим какую-то простую вещь, связанную с квантованием, у нас получается огромное количество ценной информации.
На графике «Information value» показывает, какой вклад это поле вносит в конечный результат. То разбиение, которое производит этот алгоритм, оно оптимальное с точки зрения математики. Но, дело в том, что у аналитика может быть свое собственное представление о том, что такое «оптимальное» и «неоптимальное». При этом он может ручками все подправить. Это очень удобно, потому что позволяет совмещать экспертные знания с математикой.
В Loginom существует два варианта регрессии: линейная и логистическая. Это алгоритмы, которые нужно использовать в первую очередь, потому что ввязываться во все тяжкие и использовать сложные методы, не воспользовавшись простыми, - это достаточно глупо. Это модно, но это глупо.Причём речь не идет о том, что просто реализовать линейную или логистическую регрессию.
Мы встроили в эти алгоритмы механизмы, которые позволяют автоматически подбирать структуры этих моделей, которые защищают от переобучения за счет различных методов валидации, а также механизмы, которые позволяют автоматически определить значимость факторов. Есть три уровня сложности использования этих алгоритмов:
Это классический алгоритм, который называется ARIMA, но речь не идет только об этом алгоритме, потому что это очень сложно, а о том, чтобы максимально автоматизировать работу. Loginom автоматически подбирает структуру.
Все, что можно сделать без участия человека, алгоритм сделает без его участия. На основе этого у нас получается нормальная модель, которая хорошо интерпретируется. Основная фишка заключается не в модели, а в кейсах ее использования, чтобы можно было не особо задуматься о сложностях при проектировании.
Так как все говорят о нейросетях, было бы стыдно об этом тоже не говорить. Поэтому те нейросети, которые были реализованы в Loginom 6.0, мы еще над ними очень долго работали, в плане упрощения использования. Нейросети – это «черный ящик», людям только кажется, что это легко. Непонятно, как работать с этими результатами. Это одна из проблем, из-за которых была уже 3 или 4 эпоха вымирания нейросетей.
Чувствую, что сейчас на подходе 5 эпоха, когда они будут вымирать, потому что всегда была проблема с тем, что непонятно, как интерпретировать. Нейросети – это алгоритм, который мешает нормальной интерпретации. Он по тому и может решать сложные модели, потому что может строить сложные взаимосвязи. Кроме того, нужно правильно подбирать конфигурацию.
Для того чтобы решить эту проблему, мы не просто строили нейросети, мы туда добавили механизм, который позволяет автоматически подбирать конфигурацию. Вы указывайте, сколько слоев нужно, она сама перебирает и пытается подобрать ту конфигурацию, которая при минимальной сложности обеспечила бы приемлемое качество.
Это один из способов, при помощи которых можно противостоять такой проблеме, как переобучение нейросетей. Все, кто этим делом занимается, знают, что они все очень легко впадают в переобучение. Проблема в том, что когда у вас мало данных, любая нейросеть впадает в маразм, она начинает переобучаться, и получается неадекватная модель. Механизмом борьбы служит регуляризация.
Нельзя взять каждое поле по-отдельности и сказать, какой его вклад. Потому что они все переплетаются друг с другом, поэтому и получается строить сложные модели. Но при этом, при помощи различных статистик можно понять, что получается со значимостью этих полей. Это хоть в какой-то мере позволяет нейросеть сделать из «черного ящика» серым.
Когда мы создавали Loginom, мы говорили, что не хотим, чтобы люди программировали. Программирование остается сложной задачей, большинство людей не в состоянии будут эту задачу нормально решать. Но возникают такие задачи, которые проще закодировать, чем писать сценарии. Они, в основном, касаются циклов, сложной логики, использования библиотек.
Чтобы это решить, мы в Loginom встроили поддержку JavaScript. Это первый язык, который будет поддерживаться в Loginom. Чуть позже будет добавлена поддержка Python. Причина выбора этих языков проста: JavaScript – самый популярный язык программирования, он самый безопасный.
Одна из проблем, когда мы используем языки программирования на сервере, заключается в том, что там можно нагородить такого, что все испортить. В JavaScript изначально вся обработка ведется в «песочнице», то есть вы не можете получить доступ к другим данным. Это физически запрещено. Поэтому реализация является безопасной.
Для нормальной обработки необходимо, чтобы данные на вход подались, как нормальные структуры. Чтобы не нужно было выгружать в файлы, в базы. Чтобы система видела, какую-то обработку: таблицы, переменные. И чтобы результат представлялся тоже в виде каких-то таблиц или переменных. Чтобы это прозрачно и бесшовно встраивалось в цикл обработки. Иначе пользы в использовании какого-то языка становится мало.
Возможность поддерживания внешних библиотек. То есть вы можете внешние модули подключать, класть их в специальную папку. Благодаря этому все наработки, которые есть у вас или у других можно использовать. Я думаю, что вместе JavaScript и Python закроют 90% всех потребностей. Если не сможете в лоб решить, значит, с помощью языка сможете решить.
Эта штука очень мощная, но очень опасная. Потому что, на самом деле, вы можете прямо из сценария запустить любое приложение. Если такое происходит, то можно взять скрипт на любом языке и его тоже пульнуть. Но когда на сервер кладется какой-то код, который может исполнится, то последствия могут быть непредсказуемы, особенно, если это работает в облаке или какой-то корпоративной среде. При всём при этом, это последнее средство, если уже ничего не помогло.
Если речь идет о вызове какой-то внешней системы, она должна не просто вызываться, она должна быть встроена в конвейер. Туда можно передавать параметры и каким-то образом обрабатывать. Этим обработчиком просто так пользоваться нельзя, нужно обязательно заходить с правами администратора. По умолчанию это не работает.
Все, кто занимается визуализацией, знают, что она сводится в таблицы, графики, диаграммы, кубы. OLAP (сводная таблица, кросс-таблица) – это один из самых популярных способов визуализации. Было добавлено «Опциональное авто обновление». Когда мы добавляем какой-то функционал, мы отталкиваемся от кейсов использования, как это можно использовать.
Чаще всего используют следующий кейс работы с OLAP: есть доступные поля, их начинают набрасывать. Причем, чаще всего сначала надо набросать, а уж потом посмотреть результат. Вначале система работала таким образом, что как только в нее что-то бросали, она налету перестраивалась. Было не совсем понятно, зачем это нужно, потому что это – бесполезная трата времени.
Сейчас мы добавили возможность, когда вы можете отключить автоматическое обновление, набросать туда нужные элементы, а потом включить. Не будет промежуточной работы, вы сразу получите конечный результат.
Когда появляется какой-то показатель, хочется понять, откуда этот показатель вообще появился. Один из стандартных способов – это посмотреть детализацию. У вас есть какой-то узел, вы выбираете любую из ячеек и можете посмотреть, откуда эти данные там появились. Их можно куда-то выгрузить и дополнительно проанализировать.
Добавлен функционал сворачивания, разворачивания, и прочие возможности для более удобного юзабилити.
Задача классификации: у нас есть какие-то атрибуты, и результатом задачи будет ответ «да» или «нет». Это одна из самых популярных задач. Больше половины бизнесовых задач сводятся к задаче бинарной классификации. Для построения задачи можно использовать различные алгоритмы. Один из самых популярных алгоритмов – это логистическая регрессия. Речь не идет о том, чтобы просто построить модель, ее еще нужно оценить, оценить качество, атрибуты.
Для оценки качества бинарной классификации есть множество различных методов. Мы посмотрели на все продукты, которые есть на рынке, посмотрели, какие они считают атрибуты, и все, что нашли в этих продуктах, встроили в эту систему. При этом постарались показать это красиво и удобно. Здесь нет какой-то новой математики, но использование получается очень удобным: на одном экране вы получаете все возможные метрики оценки качества.
Здесь еще есть «Порог отсечения», вы можете выбрать порог отсечения, который выбран автоматически, либо управлять самостоятельно.
Возвращаясь к задаче про алгоритмы, я говорил, что одна из задач – не просто построить тот или иной алгоритм, а объяснить, как он был построен. «Отчет по регрессии» необходим для объяснения того, как построена модель. Здесь внизу считаются все показатели, которые нужны для регрессии. Справа отображаются все метрики, которые нужны для оценки той или иной модели: значимость, доверительный интервал.
Блок наверху – это дерево, которое позволяет понять, как построена модель. В принципе, можно построить модель, не отбирая факторы, тогда дерева наверху не будет. Дерево показывает, как перебирались модели. Важно, когда мы можем не только построить модель, но и проследить, как она строилась. Для каждого из этих узлов считаются показатели качества и прочие атрибуты.
Он похож на механизм настройки конечных классов, который вы видели ранее. Это способ, при котором вы получите ответ, почему было произведено именно такое разбиение. Здесь считаются все известные показатели.
У нас несколько сотен клиентов, которые использовали Deductor. Там было хранилище данных Deductor Warehouse, это хранилище данных, которое есть в Deductor, которое может работать на трех платформах, по вашему усмотрению. Ориентировано на то, чтобы аналитику было удобно извлекать данные.
Если вы используете хранилище данных, то вы видите показатели и атрибуты. В результате строится какой-то SQL-запрос, но конечному пользователю это знать не нужно. То есть теперь можно импортировать все данные.
1С – это одна из самых популярных учетных систем. Понятно, что нам нужно было как-то с этим интегрировать. Вы пишете запрос, 1С его как-то разруливает, и вы получаете правильный набор данных.
Изначально, у нас была поддержка WEB-сервисов, для этого использовались XML, SOAP+WSDL, и это правильно, потому что, когда вы используете SOAP+WSDL, вы получаете не только данные, вы получаете еще и описание структуры этих данных. Поэтому эта логика очень востребована.
Ее проблема в том, что она тяжеловата. Людям приходится писать описания – это плата за удобства интеграции. Все люди ленивые, они не хотят мучатся, а хотят выгрузить куда-то файл, чтобы система самостоятельно все это разобрала.
Сейчас существует огромное количество сервисов в стиле REST. И если раньше нам надо было писать WSDL, сейчас можно напрямую обратиться, настроить с помощью мастера подключение к этому сервису, выполнить запросы, положить данные, получить данные, а также в самом сценарии получить ответ. Вы можете обмениваться любыми данными, которые веб сервис может вам предоставить.
Это российская разработка, более того, это рязанская разработка, также как и Loginom. Это технологическая платформа. Сейчас очень много говорят про импортозамещение, во многих компаниях это – обязательное условие. ODANT внесена в реестр российских программ, она входит в «Российскую технологическую платформу».
Эта система, которая позволяет хранить данные достаточно сложной структуры. За основу взят XML движок, который позволяет хранить данные произвольной структуры. Система распределенная, она изначально работает как сеть, которая соединяет между собой узлы. Мы сделали не только интеграцию с ODANT, но также реализовали определенный сценарий.
В самом начале я говорил, что у людей должна быть возможность просматривать отчеты. Я говорил, что специализированное средство для просмотра отчетов всегда лучше. Но, я думаю, что чаще людям достаточно получить какой-то простой функционал. Вернемся к тому, как это реализовано у нас.
Раньше в Deductor была специальная программа Deductor Viewer. Там проектировалась логика, но там было отрезано все, что касается построения сценариев. Можно было только видеть отчеты. Сейчас такого нет. Потому что у нас нет самостоятельных приложений.
У нас приложением является браузер. Во-первых, появилась новая роль, роль Viewer, он отличается от остальных тем, что кроме отчетов он ничего.
Во-вторых, когда вы проектируете логику, вы можете отдельные отчеты выводить на панель отчетов. На одной панели можно объединить информацию о различных отчетах. Когда вы заходите под ролью Viewer, у вас нет возможности изменить сами данные, вы можете видеть только результат. У вас есть возможность манипулировать только отображением этих данных.
Последнее, о чем бы я хотел сказать, что мы сделали за этот год - электронный учебный центр и учебные материалы, которые мы разработали. Мы продолжаем говорить, наша задача сделать так, чтобы продвинутая аналитика стала массовой, чтобы все могли воспользоваться ей.
Несмотря на то, что мы стараемся упростить механизм: мы подбираем структуру моделей, для того, чтобы было удобно и комфортно, но всё равно решение любой задачи анализа – нетривиальная штука. Чтобы что-то делать, надо включать мозги. Вы не можете любой мусор туда подать. Поэтому, в любом случае, приходится людей обучать. Нам хочется, чтобы это было максимально просто и комфортно, но обойтись без этого не получается.
У нас за это время появилось 5 учебных модулей. «Бизнес-аналитика – наука о данных» - это самый большой учебный модуль, потому что все базовые вещи, которые касаются принципов построения сценариев.
Помимо этого даются еще и дополнительные модули, которые касаются работы в Loginom: «Стандартизация и очистка данных» - это одна из самых популярных задач. Очистка и обработка данных – это та еще морока, с которой приходится постоянно воевать. Нужно понимать, что это не идеальное решение этой проблемы.
Еще два дополнительных бизнес-курса: один посвящен обнаружению и изменению оттока, второй посвящён введению в кредитный скоринг. Мы продолжаем над всем этим работать, так что в ближайшее время появятся ещё модули. Они вообще регулярно будут выходить. И всем, кто начинает обучаться, если он подключается к какому-нибудь модулю, то всё, что появляется в течении года ему становится доступно.
В качестве примера я хотел бы вам показать, как выглядит курс «Бизнес-аналитика: наука о данных». Это не пять роликов, где надо просто щелкать. Я очень часто сталкивался с тем, сто люди под учебным курсом подразумевают ряд роликов. Как самоучитель игры на гитаре: посмотрел и научился играть. Так это не работает.
Если мы хотим, чтобы люди нормально пользовались анализом, нам нужно не просто дать информацию, нам нужно понять, нам нужно убедиться, что они поняли, о чем идёт речь. То есть, нужно проконтролировать знания, чтобы они сами ручками что-то сделали.
Если вы посмотрите на этот учебный курс, то увидите, что тут 21 лекция и еще 20 практических занятий. После каждой лекции мы вводим практические занятия, чтобы добиться того, чтобы люди сами своими ручками все это сделал. Если они все это не сделают самостоятельно, они на следующий день все забудут.
Кроме практических занятий туда входят мастер-классы, различные практические тесты для самоконтроля, итоговые контрольные задания. Мы уверены, что люди не просто прослушают, но еще и смогут потом на практике использовать те задачи, те методы и алгоритмы, о которых мы рассказывали.
Арустамов Алексей
Директор Loginom Company
Дата выступления:
26 сентября 2018
