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

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

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

Уровень инфраструктуры

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

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

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

К счастью, экосистема данных, похоже, движется в направлении, которое поможет преодолеть эту проблему. Ранее популярная архитектура Lambda, в которой пакетная и потоковая обработка разделены, уступает место растущей популярности своего родственного брата, ориентированного на потоковую передачу, архитектуры Kappa[1][2][3 ]. Несмотря на простоту, масштабируемость и низкую задержку Kappa, рост событийно-ориентированной архитектуры и непрерывной доставки в разработке программного обеспечения, по-видимому, являются основными мотивирующими факторами, стоящими за этим сдвигом. Эта тенденция предоставляет прекрасную возможность решить рассматриваемую проблему: если сообщество инфраструктуры данных интерпретирует и реализует архитектуру Kappa с сильным акцентом на унификацию, сложность инструментов может вскоре начать уменьшаться, а пользовательская база этих технологий будет расти.

Мы в Synnada решительно поддерживаем архитектуру Kappa и считаем, что достижение реальной унификации пакетной и потоковой обработки является ключом к широкому внедрению подходов, ориентированных на потоковую передачу. Вот почему мы прилагаем все усилия, чтобы сделать возможности потоковой передачи в Apache Datafusion доступными для всех со знанием стандартного SQL (и только стандартного SQL), упрощая создание и поддержку конвейеров данных в реальном времени, приложений. , или продукты.

Уровень интеллекта

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

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

Итак, что означает машинное обучение в реальном времени на самом деле? Мы видим несколько ключевых критериев для систем машинного обучения в реальном времени:

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

Сегодня люди пытаются использовать или, лучше сказать, форсировать такие идеи, как AutoML [1][2][3] из традиционного автономного ML в область ML в реальном времени, потому что это все, что у них есть. . Очевидно, что такие подходы не работают и привели к появлению целого ряда вспомогательных продуктов машинного обучения, таких как инструменты мониторинга моделей, платформы MLOps и другие.

Представьте, что мы используем систему AutoML для постоянного обновления наших моделей — насколько это будет дорого (и медленно)? Подумайте о том, чтобы пытаться собирать новые релевантные метки каждый раз, когда ваш инструмент мониторинга модели предупреждает вас о том, что ваша модель не синхронизирована. Если бы у вас была работающая система HITL, в этом не было бы необходимости.

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

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

Слой продукта

По мере того, как мы продвигаемся к разработке интеллектуальных агентов/систем, способных наблюдать, принимать решения, действовать и постоянно адаптироваться; Последнее препятствие, которое нужно преодолеть, — это упаковать и доставить эти агенты для практического использования. Наша цель должна состоять в том, чтобы предоставить богатый выбор полезных агентов, которые должны со временем специализироваться на среде каждого конечного пользователя. Мы считаем, что такая цель может быть достигнута только с помощью уровня продукта [1][2], который позволит тестировать, учиться и улучшать цикл создания и обслуживания. Итак, что требуется от такого слоя?

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

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

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

Авторы