Привет, Хабр! Сегодня хотели бы поделиться историей разработки сервиса видеоконференций, рассказав о процессе создания продукта и его развитии. Итак, пару лет назад Jazz by Sber позиционировался и развивался как приложение для звонков между пользователями умных устройств Сбера. Довольно быстро он стал одним из основных сервисов для онлайн-общения внутри компании и быстроразвивающимся b2b-продуктом для массового рынка с AI и голосовым управлением.

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

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

Начну немного издалека, я в целом интересуюсь темой распределенной обработки данных с сохранением конфиденциальности, в частности активно смотрю на развитие такого направления, как Federated Learning. Часто попадаются статьи и материалы на эту тему, в которых наблюдаю некоторую терминологическую путаницу, тк термины Federated Learning и Confidential Computing часто используют как синонимы, но это не совсем так. Может быть я не совсем прав, но набор методов, для "обучения" (learning) и для "вычислений" вообще-то отличаются и не являются подмножеством друг друга. Поэтому в первую очередь хочу высказаться про мое понимание их фундаментальной разницы:

Добрался тут изучить ряд статей на тему Data Fabric, последнее время довольно много публикуется материала на эту тему: как про Data Fabric в целом, так и сравнения этого подхода с такими модными понятиями как Data Lake и Data Mesh. Собственно говоря, целью этого материла является кристаллизация основной составляющей концепции DF, в которой хочется оставить только саму суть.

Итак, что такое Data Fabric?

Это архитектура, подход, который говорит - не надо централизовать данные, надо навести в них порядок там, где они есть изначально и сделать над ними слой виртуализации данных, через ĸоторый потребители будут получать ĸ этим данным доступ. Data Fabric не требует замены существующей инфраструĸтуры, а вместо этого добавляет дополнительный технологичесĸий уровень поверх существующей инфраструĸтуры, ĸоторый занимается управлением метаданными и доступом ĸ данным.

Ну или чуть более длинно: “A data fabric is a modern, distributed data architecture that includes shared data assets and optimized data management and integration processes that you can use to address today’s data challenges in a unified way.” - тут и переводить не надо и таĸ все ĸрасиво написано :)

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

Данный текст является авторским переводом поста A Scalable Approach for Partially Local Federated Learning (https://ai.googleblog.com/2021/12/a-scalable-approach-for-partially-local.html).

Примечания: 

Меня довольно сильно интересует тема распределенного обучения ML моделей и в свободное время стараюсь изучать материалы, связанные с этой темой. Материалов не так уж и много, на самом деле, поэтому любая новая публиках на эту тему привлекает внимание. И 16 декабря в блоге Google AI был опубликован новый пост на эту тему, в котором авторы описывают новый подход в Федеративному обучения и я решил перевести его на русский язык, наедаясь, что кому нибудь этот материал так же может показаться интересным.

Для тех, кто не сильно знаком с этом темой, хочется сделать несколько вводных пояснений. Federated Learning (далее FL для сокращения) (так называется совокупность методов обучения ML моделей на распределённых данных) в общем то изначально дразнится Google и поддерживается в наборе инструментов TensorFlow. Почему именно Google? Дело в том, что FL решает следующую проблему: в стандартных подходах ML все базируется на том, что все данные, необходимые для обучения, доступны в рамках единого пространства памяти (централизованы на одном сервере/кластере), но есть много случаем, когда по соображениям конфиденциальности (связанными как с коммерческой тайной, так и с вопросами privacy и защиты пользовательских данных) мы не может все данные скопировать в единое хранилище. Вот FL и предлагает различные методики обучения, которые позволяют натренировать модель без централизации данных. Google с этой проблематикой сталкивается потому что является разработчиком мобильной операционной системы Android, многие функции которой требуют применения ML подходов. В частности, у них есть приложение GBoard - это мобильная клавиатура, которая подсказывает пользователю следующее слово в набираемой фразе, тем самым позволяя экономить время пользователю при наборе текста. Для того, что бы натренировать предсказательную модель, требуется обработка текстов, которые пользователи вводят в рамках переписки в мессенджерах и тп, и тут как раз и возникает проблема работы с приватными данными. Поэтому надо еще раз подчеркнуть, что текст ниже и прочие публикации Google на эту тему следует воспринимать в контексте именно этой проблематики, хотя подобные методы можно применять и в большом количестве других кейсов.

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

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

По итогам прочтения статьи «News recommender system: a review of recent progress, challenges, and opportunities» написал тут небольшие заметки о наиболее интересных, с моей точки зрения, моментах этого исследования.

Излишне говорить о важности систем рекомендации новостей, не буду пересказывать статистику о том, как вокруг нас растёт информационный поток, но надо отметить, что в дополнение к этому росту сейчас также довольно остро встаёт проблема fake news, что делает задачу персонализации новостной ленты еще более важной и требует применения подходом, когда анализируется не только meta-информация о контенте (что сейчас применяется в большинстве движков) но и сам контент, который становится все больше мультимодальными (представляет собой текст, аудио или изображение/видеоряд).

NRS (news recommendation system), так же как и рекомендательная система для любого другого контента имеет свои особенности, сложности и вызовы. Как отдельная доменная область, новости имеют особенности.