Комментарии

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

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

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

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

— Оптимизация автопарка
— — FMS с искусственным интеллектом, способные предоставлять данные и события в режиме реального времени, могут анализировать данные о трафике, погодных условиях и других факторах, оптимизируя маршруты в режиме реального времени, сокращая время в пути, расход топлива и улучшая своевременность доставки.
— — ИИ может принимать соответствующие решения о диспетчеризации на основе данных о наличии транспортных средств, квалификации водителей и других аспектов, сокращая время простоя и повышая эффективность использования парка, т.е. «умная диспетчеризация».
— Техническое обслуживание и ремонт
— — Способность прогнозировать необходимость технического обслуживания на основе анализа данных позволяет предприятиям проводить его заблаговременно, что в свою очередь снижает риск поломок и минимизирует время простоя.
— — Программное обеспечение для управления автопарком на основе искусственного интеллекта также может помочь в составлении расписания и предупреждении о необходимости технического обслуживания на основе данных об износе и использовании техники в режиме реального времени. Это позволяет снизить вероятность поломок и улучшить состояние транспортных средств.
— Соблюдение требований и безопасность
— — Благодаря возможности отслеживать поведение водителей, например, скорость, ускорение, торможение и прохождение поворотов, компании могут решать любые потенциальные проблемы со своими водителями, чтобы снизить вероятность аварий.
— — Кроме того, на основе полученных данных предприятия могут проводить индивидуальное обучение и тренинги.
— — Это также поможет обеспечить соблюдение таких нормативных требований, как Hours of Service (HOS) и Electronic Logging Device (ELD).

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

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

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

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

Направление бизнеса в нужное русло

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

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

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

iOS-разработка никуда не денется — даже несмотря на ограничения

Ситуация в iOS-разработке тоже сложнее, чем несколько лет назад, — по данным hh.ru, если с 2022 по 2023 год количество вакансий Android-разработчиков сократилось на 20,5%, то предложений для iOS-разработчиков стало меньше на 29,9%.

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

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

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

Хоть наём и сократился, но рынок точно не исчезнет. Россияне по-прежнему покупают iPhone, а пользователи App Store традиционно платят за приложения, причём в полтора раза больше, чем пользователи Android и Google Play. Доля вакансий iOS-разработчиков сократилась, но в абсолютном количестве их всё ещё много.

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

3. Нативная разработка по-прежнему будет востребованнее кросс-платформенной

Рост спроса на кросс-платформенные инструменты традиционно называют в числе тенденций каждого последнего года. Данные hh.ru подтверждают, что количество вакансий для Flutter- и React Native-разработчиков действительно увеличилось с начала 2023 года.

— «В стартапах кросс-платформенные решения приживаются, потому что так маленькие компании могут за более короткое время охватить большую долю рынка. Среднепродуктовые компании в 2023-м “щупали” кросс-платформу и оценивали, насколько им подходит, например, Flutter. Равнодушие продемонстрировал бигтех — там слишком большой багаж и долгая история поддержки проверенных продуктов»

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

Кроме того, Flutter — один из вариантов, с которым можно заходить в поле PWA-разработки (создания приложений, выглядящих для пользователя как сохранённые закладки сайтов). Такие сервисы нужны не только вместо тех, что удалили из App Store и Google Play, — их в принципе проще поддерживать из-за единой кодовой базы. Среди удачных примеров можно назвать «Диск» от Сбера или приложение «Тинькофф», которое разработали в PWA-формате ещё до санкций.

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

— «В последние пару лет кросс-платформа снова ожила. Во фрилансе сейчас сильно популярен Flutter. Небольшой процент бизнес-логики занимает Kotlin Multiplatform. Но многие эксперты сомневаются: а не повторится ли история с поиском серебряной пули? Ярких доказательств пользы на реальных проектах почти нет — скорее, больше маркетинга. Также усложняет веру в кросс-платформу отказ от неё многих крупных компаний. Наём качественных специалистов чаще идёт туго, сложно найти талантливого универсала. Команды закрываются и переводятся на натив»

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

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

— на кросс-платформу не перейдут сервисы, которые взаимодействуют с железом смартфона и имеют много «нативного» функционала. Например, приложения, работающие с AR, картами, криптоподписями или сим-картами,

— менеджмент давно существующих компаний консервативен и с трудом перестраивается на новые способы разработки продуктов.

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

— А так я бы советовал новичкам начинать с нативной разработки. Flutter — это всё-таки надстройка над нативом, и я, как и многие в индустрии, считаю, что здорово иметь бэкграунд в iOS или Android. Это закаляет начинающих разработчиков, даёт понимание архитектурных паттернов и так далее. Если знаешь особенности одной из платформ, то будешь писать более качественный код, в том числе и на Flutter»

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

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

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

— Работа с интерфейсом. Кнопки, переходы, анимация и жесты — перенос всех этих элементов и сценариев из макета в приложение входит в задачи разработчиков.

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

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

Чтобы выполнять эти и другие задачи, разработчики пишут код. Android-разработчики на языках Java и Kotlin, iOS-разработчики — на Swift и Objective-C. Такая разработка называется нативной.

Кроме нативной, есть кросс-платформенная разработка. При таком подходе разработчики пользуются Flutter, React Native, Kotlin Multiplatform и другими фреймворками, а потом написанный код адаптируется под разные платформы.

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

С направлением в мобильной разработке лучше определиться сразу, потому что фреймворки и средства разработки в них сильно отличаются и быстро поменять платформу не получится. Кроме того, у Android- и у iOS-разработчиков есть гайдлайны — нормативы, в которых описано, как должны выглядеть и работать приложения. И если у Google политика в этом более демократичная, то Apple может просто не пропустить в App Store приложение, которое не соответствует требованиям.

Ещё одно отличие — требования к системе. Для iOS-разработки необходим компьютер на macOS, причём не слишком старый. Всё потому, что среда разработки Xcode постоянно обновляется, а вместе с ней и требования к операционной системе. Например, самая актуальная версия программы требует macOS Ventura или новее, которая поддерживается на компьютерах Apple, выпущенных не ранее 2017 года. С Android всё проще, а актуальные требования можно прочитать в характеристиках среды разработки Android Studio. Например, сейчас для Android-разработчиков достаточно 64-битной Windows 8 и 8 ГБ оперативной памяти.

ИИ и геоаналитика только начинают формировать проекты и сервисы. Примеры единичны, но они есть и в России — в сегментах ретейла, строительства, государственного управления.

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

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

Мы постоянно говорим о том, что ИИ сокращает время выполнения задач и позволяет сосредоточиться на более важных процессах. А какие процессы более важные?

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

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

Главное отличие искусственного интеллекта от естественного разума в отсутствии воли. Сам ИИ не задает вопросов, что там – на глубине океана, в недрах Земли или на бескрайних просторах космоса.

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

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

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

При всех преимуществах применение ИИ связано и с различными рисками. Рассмотрим некоторые из них.

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

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

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

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

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

Команда VK Cloud перевела расшифровку подкаста Harvard Business Review HBR IdeaCast. В нем Сундар Пичай, генеральный директор Google и его родительской компании Alphabet, рассказывает о генеративном ИИ и других вопросах, касающихся искусственного интеллекта и развития крупных ИТ-компаний в будущем. Сделали краткую выжимку из этого подкаста и делимся с вами.

Роль генеративного ИИ в работе людей

Сегодня все вокруг говорят о генеративном ИИ. Но как воспринимать на рабочем месте возможности GenAI, которые есть уже сейчас и, может быть, появятся в ближайшем будущем?

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

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

Мультимодальные ИИ

Мы все создаем современные модели генеративного ИИ. Модель и рабочее решение, которые мы уже запустили и используем для своих продуктов, называется PaLM 2. Модель нового поколения, над которой мы работаем в нашем новом подразделении Google DeepMind, называется Gemini. Сегодня у нас есть модели, которые создают тексты, модели, которые создают изображения, и так далее. Но следующее поколение моделей будет мультимодальным. Они обучаются на разных модальностях: тексте, изображениях, аудио, может быть еще видео, и поэтому могут выдавать результаты в каждой модальности.

Что это означает? Например, вы говорите: напиши мне сочинение на эту тему. Модель не только напишет сочинение, но еще добавит к нему картинки, — она все это сможет генерировать. Или, допустим, вы хотите испечь пирог и спрашиваете рецепт. Она не просто выдаст вам текст, но и покажет картинки. И нам в Gemini нравится именно сама идея мультимодальности.

Использование моделями инструментов — еще одно направление развития, над которым мы все работаем. Человек все время использует разные инструменты. Вы берете калькулятор, печатаете в текстовом редакторе. Если вам нужно что-то узнать, вы это загуглите. И мы учим эти модели понимать, что в мире есть инструменты, которые можно использовать, если пользователю нужна помощь.

Интересный опыт использования генеративных ИИ

Мы в компании создали Lambda, виртуального собеседника на базе этих больших языковых моделей. Я с ним разговаривал. Мы придумывали для него разных персонажей. Например, можно было попросить его вести себя как планета Плутон и подолгу с ним беседовать. Отличный инструмент обучения. Фактически мы с сыном довольно много с ним разговаривали. От него можно было узнать много интересного о солнечной системе, задавать ему вопросы, но в какой-то момент во время беседы с Плутоном я вдруг почувствовал себя очень-очень одиноко. Диалог постепенно окрасился в мрачные тона. Это был первый опыт, который меня встревожил и показал мне, что в принципе возможно, как ИИ может влиять на человека.

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

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

Осторожность в создании искусственного интеллекта

Кажется, что Google более консервативен, чем некоторые компании, которые ринулись создавать ИИ-ботов, как их правильно ни назови, с довольно большой скоростью. Я имею в виду, что все это произошло буквально в считанные месяцы. Как же находить компромисс между потребностью оставаться на рынке, выпускать продукты, необходимостью создавать инновации и той осторожностью, о которой шла речь выше?

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

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

Все это важно. Именно это надо встраивать в компанию, чтобы аккуратно обойти острые углы и в то же время их сглаживать. У нас недавно прошла крупнейшая конференция разработчиков, где мы рассказывали о работе над искусственным интеллектом, которой мы занимаемся. Мы хотим сделать ИИ помощником для всех, кто пользуется нашими продуктами. Мы уже включили генеративный ИИ в 25 наших продуктов, в том числе Gmail, Google Docs, интернет-поиск, YouTube и так далее. Повторюсь: мы хотим действовать смело и ответственно одновременно.

Что такое «подушка безопасности» в создании искусственного интеллекта

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

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

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

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

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

Это не так уж сложно. Например, мы встраиваем их в инструменты для повышения производительности, скажем, Google Docs, Google Slides или Google Sheets; другие компании делают то же самое. Представьте, что ваши сотрудники привыкли использовать ИИ в качестве помощника. Чтобы сотрудники адаптировались к переменам в компании, важно изменить менталитет.

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

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

Как применить ИИ в своей компании

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

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

— Искусственный интеллект и машинное обучение для создания системы предиктивной аналитики, расшифровки данных и выявления тенденций

— 3D-технологии для внедрения новых инструментов Data Visualization, показа большего числа данных, в том числе с привязкой к географии

— XR для совместной работы и визуализации аналитики в интерактивном иммерсивном формате.

За какими технологиями нужно следить, чтобы быть в курсе развития BI-систем?

Я бы выделил целый ряд трендов:

— MD/MQ Data management

— Внедрение data-driven культуры в работу

— Внедрение self-service BI систем

— Data Visualization

— Data Storytelling

— Развитие ABI систем

— Аналитика в real time

— Data warehouse modernization

— Data governance

— Предиктивная аналитика

— Внедрение моделей машинного обучения

— Cloud BI

— Самостоятельная работа с данными

— BI-системы для мобильных устройств

— Добавление и совершенствование уведомлений в BI-системах

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

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

Как материализованные представления в потоковой базе данных с CDC-подходом и шаблоном CQRS позволяют реализовать масштабируемую и высокопроизводительную систему с микросервисной архитектурой для транзакций и аналитики данных в реальном времени. Разбираемся с паттернами проектирования микросервисов на примере интернет-магазина.
Что не так с шаблоном композиция API и другие проблемы микросервисной архитектуры в управлении данными

Микросервисная архитектура для распределенных систем позволяет обеспечить гибкость, масштабируемость и отказоустойчивость. Однако, как мы уже упоминали здесь, запрос данных из нескольких микросервисов в режиме реального времени может оказаться сложной задачей, поскольку для этого могут потребоваться сложные и трудоемкие операции извлечения данных. Материализованные представления вместе с паттерном проектирования разделения ответственности команд и запросов (CQRS, Command Query Responsibility Segregation) могут решить эту проблему, обеспечивая эффективный запрос данных микросервисов в режиме реального времени.

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

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

Это решение соответствует шаблону композиции API (API Composition). Суть этого паттерна в том, что он реализует запрос, вызывая сервисы, владеющие данными, и выполняет объединение результатов в памяти. Этот прием часто использует другой шаблон проектирования микросервисной архитектуры, шлюз API (API Gareway). Шаблон композиции API является достаточно простым в реализации. В частности, реализовать его можно с помощью технологии GraphQL, которая позволяет клиенту запрашивать только нужные данные из нескольких источников в одном запросе, выполняя федерализацию нескольких схем данных.

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

Изменим архитектуру проектируемой системы, используя захват измененных данных (CDC, Change Data Capture) и материализованные представления для оптимизации запросов к микросервисам в режиме реального времени и повышения производительности.

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

Как фиксировать изменения данных – через триггеры на таблицах БД, опросы, логи или готовые решения типа Debezium. Триггеры, как частный случай хранимых процедур, могут использоваться для выполнения действия при определенных событиях. Подробнее о сходстве и различии триггеров и хранимых процедур мы писали здесь на примере Greenplum. Опрос регулярно запрашивает базу данных, чтобы узнать, были ли внесены изменения. Логи фиксируют всю активность базы данных, включая изменения, и могут использоваться для обработки в реальном времени. Каждый из подходов имеет свои достоинства и недостатки, которые следует учитывать для каждого конкретного сценария.
Как передавать изменения данных – синхронно или асинхронно. Синхронная связь полезна для кратковременных транзакций, а асинхронная связь идеальна для длительных процессов.
Как обеспечить согласованность данных между сервисами – через использование распределенных транзакций, что чревато проблемами с производительностью, или через согласованность в конечном счете, когда каждый сервис работает со своими собственными данными и в конечном итоге становится согласованным с другими приложениями.

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

CDC позволяет реализовать инкрементные обновления хранилища данных, фиксируя изменения, внесенные в системе-источнике, чтобы загружать только их в DWH. Это сокращает время, необходимое для полной загрузки, и обеспечивает постоянную актуальность данных в хранилище данных. Также CDC можно использовать для потоковой передачи данных из нескольких источников с целью их анализа в реальном времени. Наконец, CDC пригодится для обновления моделей AI/ML новыми данными. CDC фиксирует изменения, внесенные в исходную базу данных, и обновляет модели AI/ML новыми данными. Это помогает обновлять ML-модели с использованием самых последних данных, повышая их точность.

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

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

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

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

Сперва идентифицируем запросы, требующие доступа к данным интернет-магазина в режиме реального времени, например, списки недавно просмотренных товаров. Основная цель здесь — сохранить данные, требуемые службой запросов, в денормализованном формате, чтобы обеспечить быстрый поиск. Материализованные представления денормализованы и оптимизированы для конкретного запроса или представления в пользовательском интерфейсе, чтобы быстрее и эффективнее извлекать данные. Материализованные представления могут быть созданы с использованием баз данных или специализированных систем кэширования. Чтобы получать обновления в режиме реального времени и поддерживать согласованность этих данных, подписавшись на изменения состояния баз других микросервисов, целесообразно использовать потоковую СУБД, например, Rockset, Materialise, RisingWave и DeltaStream. Подробнее о потоковых базах данных, которые поддерживают аналитические операции с непрерывными потоками данных в реальном времени с помощью SQL-запросов, мы писали здесь и здесь.

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

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

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

Обмен данными микросервисов с потоковой базой данных можно реализовать с помощью паттерна Outbox. Он обеспечивает асинхронный и децентрализованный обмен данными между микросервисами.

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

Затем выходной буфер микросервиса обрабатывается процессором Outbox (отдельным компонентом или сервисом, например, потоковой базой RisingWave). Он читает события или изменения из буфера и асинхронно отправляет их другим микросервисам или хранилищам данных. Это позволяет микросервисам продолжать обработку запросов, не ожидая завершения обмена данными, что повышает производительность и масштабируемость системы.

Также для обмена данными микросервисов с потоковой базой данных можно использовать платформу потоковой обработки событий, например, Apache Kafka. Она позволяет публиковать и подписываться на потоки событий, отказоустойчиво хранить и обрабатывать их в реальном времени.

Я не претендую на особую экспертизу в этом вопросе, но сомневаюсь, что внедрение service mech окупится из-за перечисленных вами фич. Зато если вы хотите пойти в Canary Deployment, то (скажем, совместно с Argo Rollouts), можно получить реальный profit.

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

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

А есть хоть какая-нибудь оценка того, сколько реально позволило сэкономить применение Istio? Желательно не на «сферическом примере в вакууме», а на реальном. Мы вот заморочились, внедрили Istio по требованиям организации, словили кучу проблем с ним. И никто не видит никакой пользы. Терминирование TLS особо не нужно (безопасность требует шифровать всё); балансировки по кругу хватает; размыкатели цепи в теории штука неплохая, но нередко уже встроена в библиотеки, да и без зашкаливающей нагрузки особо не нужна; метрики — и так всё обвешено Прометеями настолько, что глаз смотреть не хватает.