Комментарии

Наконец-то дождался этого обновления! Как активный пользователь Pagelook, могу сказать — интерфейс стал просто летать. Особенно порадовало, что добавили новые функции, но при этом всё осталось интуитивно понятным.

Наконец-то дождался этого обновления! Как активный пользователь Рутвит, могу сказать — интерфейс стал просто летать. Особенно порадовало, что добавили новые функции, но при этом всё осталось интуитивно понятным.

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

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

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

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

Единственное, что вызывает вопросы — это отсутствие пока что версии для iOS. Но, учитывая темпы развития платформы, надеюсь, это вопрос времени.

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

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

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

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

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

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

Единственное, что вызывает вопросы — это отсутствие пока что версии для iOS. Но, учитывая темпы развития платформы, надеюсь, это вопрос времени.

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

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

Интересно наблюдать, как развивается этот проект. Психологическая социальная сеть — довольно нишевая тема, но DST Global явно знает, что делает. Обновление показывает серьёзный подход к продукту: и функциональность улучшили, и доступность расширили через RuStore. Похоже, что Epsylon действительно претендует на роль лидера в своём сегменте. Будем следить за дальнейшим развитием.

Наконец-то дождался этого обновления! Как активный пользователь Epsylon, могу сказать — интерфейс стал просто летать. Особенно порадовало, что добавили новые функции, но при этом всё осталось интуитивно понятным. А наличие в RuStore — это вообще топ, теперь даже бабушка сможет установить Однозначно плюс в карму разработчикам!

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

Основные компоненты SDK

— Библиотеки кода или фреймворк – это фрагменты кода, которые регулярно используются при создании приложений. Например: кнопки, переключатели, выпадающие списки и другие элементы. Фреймворк ускоряет разработку, так как такие однотипные элементы можно быстро встроить в будущее ПО.
— Компилятор – инструмент, который переводит код, написанный на языке разработки, в машинные коды и «собирает» приложение или плагин, чтобы их можно было запустить или подключить к существующему проекту.
— Отладчик – решение для поиска и устранения ошибок в коде проекта.
— Интегрированная среда разработки или IDE – удобный визуальный интерфейс, позволяющий ускорить и упростить процесс создания нового приложения.
— API(Application Programming Interface) – интерфейс программирования приложений. Он нужен для обеспечения обмена данными между приложениями или сервисами. API обеспечивает не только обмен информацией между разными платфорамами, но и позволяет сторонним программистам взаимодействовать с конкретным приложением и получать от него необходимые данные в понятном формате. Работать с API легче, чем с SDK, но он обеспечивает только очень ограниченную часть возможностей SDK.
— Примеры кода – хоть и не обязательная, но очень полезная часть. Позволяют более глубоко разобраться в работе конкретного языка или узнать какие-то полезные решения.

Какие преимущества можно получить с SDK

Если перевести это на более «человеческий» язык, то можно представить SDK в виде коробки с конструктором внутри, из которого вы можете собрать любую нужную вам модель. Фреймворк – это разнообразные детали конструктора, компилятором вполне может быть отвертка, ведь с помощью неё вы собираете из разных элементов готовое изделие. IDE будет похожа на специальные направляющие с разметкой, чтобы было удобнее и понятнее в процессе сборки, а примеры кода и документация будут представлены готовыми модельками или картинками с инструкциями, показывающими, как нужно действовать.

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

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

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

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

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

А тогда вопрос — какие какие основные компоненты SDK и преимущества можно получить с SDK?

Ключевые различия между SDK и API

SDK и API — важные инструменты для разработки ПО, у каждого из них свои особенности и способы применения.

Функциональность

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

Реализация

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

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

Совместимость

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

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

Размер

SDK — внушительный набор инструментов, поэтому для его установки нужно много места. К примеру, Android SDK занимает около 50 ГБ (в зависимости от версии). К счастью, загружать можно не все компоненты пакета.

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

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

Симбиоз SDK и API

SDK и API — это взаимодополняющие подходы, которые при совместном использовании создают мощную экосистему разработки.

Объединение сильных сторон SDK и API даёт следующие преимущества:

— Ускоренная разработка. Готовые компоненты SDK в сочетании с функциональностью API значительно ускоряют программирование. Такое сочетание позволит разработчикам сконцентрировать силы на уникальных функциях приложения.

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

— Упрощённая поддержка ПО. Модульная конструкция API и комплексные ресурсы SDK упрощают обновление и обслуживание приложений. Так разработчики могут легко корректировать свои проекты без изменения большей части кода и потери актуальности для пользователей.

Ключевые различия между SDK и API

SDK и API — важные инструменты для разработки ПО, у каждого из них свои особенности и способы применения.

Функциональность

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

Реализация

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

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

Совместимость

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

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

Размер

SDK — внушительный набор инструментов, поэтому для его установки нужно много места. К примеру, Android SDK занимает около 50 ГБ (в зависимости от версии). К счастью, загружать можно не все компоненты пакета.

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

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

Симбиоз SDK и API

SDK и API — это взаимодополняющие подходы, которые при совместном использовании создают мощную экосистему разработки.

Объединение сильных сторон SDK и API даёт следующие преимущества:

— Ускоренная разработка. Готовые компоненты SDK в сочетании с функциональностью API значительно ускоряют программирование. Такое сочетание позволит разработчикам сконцентрировать силы на уникальных функциях приложения.

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

— Упрощённая поддержка ПО. Модульная конструкция API и комплексные ресурсы SDK упрощают обновление и обслуживание приложений. Так разработчики могут легко корректировать свои проекты без изменения большей части кода и потери актуальности для пользователей.

Выбор инструмента зависит только от конкретных задач и ресурсов ИТ-проекта.

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

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

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

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

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

И кстати в эластике есть такая штука как роутинг, думаю, его стоит посмотреть.

blog.qbox.io/launching-and-scaling-elasticsearch

1. В эластике схема несколько другая. Есть индекс -> фиксированное количество шардов -> далее либо автоматом распределяется эластиком, либо опять же «автоматом», но с использованием routing key. У нас проблема в том, что нет 10 профилей для каждой соц сети, а есть 1 большой профиль со всеми сетями. Все «условно-уникальные» идентификаторы — это массивы таких идентификаторов. Поэтому для рутинга так ничего и не было придумано. Зато можно кешировать выборки по данным соц сетям внутри nested документов, что в свою очередь тоже повышает скорость индексирования

2. Много разных кластеров или 1 — это не принципиально. По сути в эластике индекс, шард, сегмент и так далее — это самостоятельные Lucene индексы.

Честно говоря, я никогда не работал с ElasticSearch, поэтому не знаю насколько мои вопросы корректны, но всё же есть пару вопросов:

1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)

Хорошая статья. Мы остановили свой выбор на Elasticsearch, так как по отзывам он был очень легок в настройке и использовании, имел отличные поисковые возможности и, в целом, выглядел как манна небесная. Так оно и было до тех пор, пока наш индекс не вырос до более-менее приличных размером ~ 1 миллиарда документов, размер с учетом реплик уже перевалил за 1,5 ТБ.

Даже банальный Term query мог занять десятки секунд. Документации по ES не так много, как хотелось бы, а гуглинг данного вопроса выдавал результаты 2х-летней давности по совсем не актуальным версиям нашего поискового движка (мы работаем с 0.90.13 — что тоже не достаточно старая вещь, но мы не можем позволить себе опустить весь кластер, обновить его, и запустить заново на текущий момент — только роллинг рестарты).

Низкая скорость индексации

Вторая проблема — мы индексируем больше документов в секунду (порядка 100к), чем Elasticsearch может обрабатывать. Тайм-ауты, огромная нагрузка на Write IO, очереди из процессов в 400 единиц. Все выглядит очень страшно, когда смотришь на это в Marvel.

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

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

Как показал опрос, проведенный научным сообществом Kaggle (который приобретен Google ранее в этом году), около 16 700 опрошенных из 1,3 миллиона членов сообщества чаще всего называли одними из самых больших барьеров в работе «грязные данные», за которыми следует отсутствие знаний в этой области.

Но что такое «грязные данные» и почему это такая проблема? Сегодня всем понятно, что данные являются горюче-смазочным материалом для цифровой экономики, но особенно это верно в таких областях, как машинное обучение.

Современные системы ИИ обычно учатся на примерах, поэтому, если демонстрировать им массу фотографий кошек, со временем ИИ начнет распознавать их основные характеристики. Такие компании, как Google и Amazon, смогли создать столь эффективные платформы распознавания образов и речи, потому что у них есть целые массивы данных от пользователей.

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

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

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

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

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

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

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

Если бы данными пользовались в режиме онлайн, «гниения» не возникало бы. Что этому мешает?

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

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

Или вот такой пример из практики. Мы строили модель, которая прогнозировала вероятность брака итогового изделия в зависимости от настроек производственной линии, комплектующих и т. п. Ничего не получалось до тех пор, пока не выяснилось, что если конкретным исполнителям удавалось «впарить» бракованное изделие, то они задним числом корректировали запись, как будто брака не было. Делали они это, понятное дело, чтобы максимизировать свою премию. Мы это смогли выяснить, анализируя логи и данные смежных систем. Когда разобрались, модель построили. То есть тут могут помочь как организационные меры по недопущению таких нарушений, так и технические — по аналитическому выявлению такого рода поведения.

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

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

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

При этом часто бывает невозможно решить задачу на уровне одного подразделения — нужно учитывать влияние смежных подразделений. У нас была задача, когда мы делали индивидуальные рекомендации для розничной сети. На исторических данных все работало нормально, а в эксплуатации бывали случаи, когда индивидуальные рекомендации не давали вообще никакого эффекта. Начали разбирать и быстро выяснили проблему. Одна наша программистка была клиенткой этой сети. И у нее в мессенджере два сообщения от сети. Первое — наше, индивидуальное предложение с небольшой индивидуальной скидкой на конкретный товар. И второе — общая рассылка по сети, что по случаю дня рождения скидка на все 20%. Естественно, на фоне этого эффект от нашего сообщения нулевой.

Зачем компании обращаются к системному интегратору, а не к консультантам, например?

У нас есть опыт десятков внедрений в разных отраслях. Мы знаем типовые сложности, с которыми клиенты сталкиваются именно в России. В то же время разбираемся и в железе, и в информационной безопасности, и во всех сопровождающих историях. То есть мы можем оказать комплексную услугу. Компании легче иметь одного ответственного подрядчика, который в состоянии закрыть все потребности, связанные с внедрением технологий от поставки оборудования до разработки всего необходимого программного обеспечения, создания BI-системы, «озера данных» и моделей для аналитики.

Каковы типичные ошибки компаний, которые хотят монетизировать свои данные и заинтересованы в их чистоте?

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

Опишу типичную ситуацию. Правление решает, что цифровизация нужна, выделяются деньги, кому-то в ИТ-отделе или специально нанятому директору по цифровой трансформации ставится эта задача. Дальше создается дирекция по работе с информацией, набирается талантливая команда. Потом они приезжают на региональный завод, где никто с «этими хипстерами» не хочет разговаривать. Либо говорят одно, а думают другое, либо открыто саботируют. Аппаратный вес директора по производству и его слово для рабочих гораздо более значимы, чем у приехавшего директора по трансформации. В девяти из десяти случаев результат столкновения планов с реальностью предсказуем.

Есть ли выход?

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

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

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

Важно, чтобы проект допускал на стартовом этапе логику R&D, когда есть исследование, а не просто подход: вот время, вот ресурсы — обеспечь результат. Вначале могут уточняться цель, метрики, вскрываться подробности. И те же закупки должны быть к этому готовы.

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

Но потом не менее важно уметь перейти от логики исследования к логике полноценного комплексного внедрения. И многие на этом переходе ломаются.

А что является самым важным для компаний?

Сейчас для всех важна эффективность производственных процессов. Если одна построенная на больших данных и машинном обучении модель позволит снизить брак на 3%, другая — сэкономить 2% сырья, третья — разгрузить на 10% склад, совокупный эффект будет существенен для экономики предприятия. Тот, кто первым сможет комплексно это сделать, вырывается вперед и обгоняет остальных. Среди наших клиентов в отдельных отраслях есть предприятия, конкурентоспособные на глобальном уровне. Рывок эффективности на 10–20% позволит им вырваться в мировые лидеры.

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