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

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

Инструменты для аналитики разделяются на две категории: code-only и low-code. Первая категория - это вотчина "хардкорных" дата-сайнтистов, общающихся с высокими технологиями "на ты", а low-code инструменты предназначены для более широкого круга пользователей, в том числе и для тех, для кого словосочетание "искусственный интеллект" прежде всего взывает всего отсылку к тем самым фильмам начала 90-х с приятной монотонной озвучкой.

Об отношении хардкорных дата-сайтнистов к low-code инструментам в одной картинке

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

В этой статье отобраны шесть наиболее популярных мифов вокруг low-code инструментов анализа данных. Чтобы не ограничиваться теорией, будут приводиться практические примеры реализации таких инструментов, разработанных компанией Polymatica.

Миф #1. Визуальные инструменты нужны только для тех, кто не умеет программировать

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

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

Как выглядит EDA в визуальном интерфейсе

В качестве примера можно привести работу пользователя в модуле Data Discovery платформы Polymatica ML, в котором производится автоматическая "диагностика" каждого признака и их для разносторонней оценки витрины данных и выявления полезных закономерностей. Такие расчеты выполняются не только на единоразовой основе, но и по расписанию для оценки степени “дрейфа данных” во времени, для своевременной реакции на изменения внешних условий и появления новых трендов.

Подробнее о дрейфе данных читайте в статье NoML community.

Жизненный цикл аналитического проекта состоит из множества этапов, и время прохождения каждого из них играет важную роль. Владение навыком работы с кодом – всегда плюс, но его бывает недостаточно для того, чтобы в нужные сроки построить и реализовать модель в бизнес-процессе компании. Усложняет ситуацию кадровый дефицит доступности на рынке продвинутых аналитиков, обладающих знаниями бизнеса. Время, потраченное от постановки задачи на создание модели до ее реализации в бизнес-процессах (time-to-market) - одна из основных метрик, по которым бизнес оценивает эффективность работы аналитических подразделений. Наличие “рук”, способных решить задачу в нужный срок – вопрос совсем непраздный.

Миф #2. Использование визуальных инструментов приводит к потере управляемости

Бытует мнение, что визуальные инструменты ограничивают контроль над процессом анализа по сравнению с использованием code-only инструментов.

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

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

Пример, в котором код и графический интерфейс дополняют друг друга

Система поддержки принятия решений Polymatica Decision Manager позволяет пользователям выстраивать логику расчетов как с помощью бизнес-правил, в виде графического конструктора формул, так и с помощью кода на языках Python и SQL, задействуя широкий набор библиотек Open Source для решения сложных, нетиповых задач.

Миф #3. Машинное обучение - слишом сложная задача для визуальных инструментов

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

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

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

Пример low-code инструмента для MLOps

С помощью инструмента управления моделями Model Manager, обеспечивается централизованное управление на всех этапах жизненного цикла модели. Так, например, процесс тестирования моделей запускается сразу после заполнения опросника в данном Web интерфейсе, а внедрение модели в Docker контейнер займет считанные минуты, без необходимости создавать и поддерживать специальный код-обвязку.

Актуальным трендом является запрос на интерпретируемость ИИ: компании, работающие с моделями, хотят убедиться в том, что логика алгоритмов не противоречит здравому смыслу. Low-code инструменты, помогают решить задачу интерпретации моделей с помощью методов PD, ICE, LIME, SHAP. Результаты наглядно представляются в интерфейсе пользователя, как в табличном виде, так и форме графиков. Что получит заказчик разработки моделей, представитель бизнес-подразделения? Модель перестанет выглядеть как “черный ящик” с непонятными принципами работы. Каждое отдельное предсказание модели получиться объяснить, разложив прогноз модели на факторы влияния, которыми оперировал алгоритма.

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

Миф #4. Визуальные инструменты не подходят для больших проектов

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

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

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

Миф #5. Работу в визуальных интерфейсах сложно автоматизировать

Автоматизация процессов с помощью CI/CD набирает популярность в процессах связанных с разработкой ПО. На первый взгляд, концепция использования графических инструментов анализа данных имеет существенные различия с классической софтверной разработкой. Аналитические инструменты появились раньше, чем практика использования GIT и CI/CD.

Зачем нужен MLOps когда есть CI/CD?

Автоматизация – цель, а CI/CD – это средство. Какой здесь можно выделить тренд, применимый к low-code инструментам анализа данных? Ответом на запросы со стороны бизнеса на автоматизацию стало появление у графических инструментов программного API, в дополнение к графическому интерфейсу.

Наличие такого API, позволяет не только запускать различные процессы тестирования (включая A/B тесты моделей), но и шаблонизировать типовые задачи, сокращать объем рутинных операций, требуемых со стороны пользователя. Работа с помощью API востребована пользователями, владеющими навыками программирования – для них это возможность автоматизировать не только свою работу, но и процессы работы своих коллег, бизнес-экспертов.

Миф #6 Визуальные инструменты не подходят для совместной работы

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

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

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

Командная работа в графическом конструкторе создания ML моделей

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

По простому о сложном: убираем барьеры на пути к внедрению ML с помощью подхода Low Code

Несмотря на существование подобных мифов, компании, использующие аналитические инструменты low-code, способны эффективно решать практические задачи с помощью методов продвинутой аналитики. Сложные расчеты и современные алгоритмы становятся доступными широкому кругу пользователей, включая функциональных экспертов, которые разбираются в предметной области (маркетинг, риски, промышленность, продажи). В чем, прежде всего, заключается польза от “демократизации” анализа данных? Ключевой момент в том, что в итоге, продвинутая аналитика масштабируется для более широкого спектра задач, помогает повышать операционную эффективность за счет более точных и своевременных решений.

А с какими мифами использования аналитических инструментов приходилось сталкиваться вам? Интересно узнать о вашем опыте в комментариях ????.

Спасибо Наталье Яшенковой @kioto, Маргарите Александровой, Никите Атамасову и Ренате Ахметовой за помощь в подготовке этой статьи

Комментарии (11)


  1. vtal007
    28.12.2022 10:13

    Нативная рекламка Polymatica ML
    мило
    Токены не забыли проставить?


    1. Allront Автор
      28.12.2022 10:34

      Это один из примеров low-code платформ для аналитики, другие инструменты тоже интересно обсудить, но в таком случае статья получилась бы слишком объемной. А от щепотки практики в море теории хуже точно не станет :)


      1. vtal007
        28.12.2022 11:15

        ну да, причем почему то на этот "один инструмент" аж 2 ссылки. и ни одного аналога.
        разумеется "просто как пример", только пример почему-то именно эта софтинка

        Собственно, поэтому и называется "нативная", что не в лоб, а как бы "между делом"


        1. Allront Автор
          28.12.2022 11:31

          Для примера выбрал решение, с которым было больше всего практического опыта работы. Достаточно логично. А у вас был опыт работы в аналогах? Интересно узнать, если поделитесь.


          1. vtal007
            28.12.2022 11:45

            Конечно, SPSS, Statistica - мировые лидеры в области аналитики. Молчу уж про эксель
            Но Вы какой-то нонейм софт пропиарили

            раз Вы с этим (рекламируемым продуктом) работали, рассказали бы, что делали.
            Чем это лучше чем старый добрый питон с коллабом


            1. Allront Автор
              28.12.2022 11:51
              -1

              Лидерами не рождаются, ими становятся :)


  1. Lorendrake
    28.12.2022 10:35

    Сразу прошу прощения за занудство, но фраза "искусственный интеллект, который захватывает планету и отправляет киборга в прошлое…  " не верна в том смысле, что Киборг - это гибрид биологического и механического, базированный на биологической модели. А в прошлое отправлялся робот.

    p/s Да, и в описании к фильму тоже ошибка из непонимания термина :)


    1. Allront Автор
      28.12.2022 10:37
      -1

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


  1. GbrtR
    28.12.2022 20:58
    +1

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

    Т.е. не производителем системы и не А.Н. Онимом, а кем-то, кому есть доверие. И проекты должны быть не «смотрите я две стрелочки соединил и оно что-то сделало», а реальные, хотя бы среднего размера и используемые в проде, дольше пары недель.


    1. Allront Автор
      28.12.2022 21:35

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

      Вместе с тем истории, связанные с применением low-code инструментов для анализа данных, встречаются, пусть и не так часто как хотелось бы.

      Например, в этой статье https://habr.com/ru/company/sberbank/blog/489158/ рассказывается об опыте использования ML платформы с графическим интерфейсов. В данном кейсе команда Сбера является одновременно и разработчиком, и пользователем аналитического инструмента.


      1. GbrtR
        28.12.2022 22:10

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