Open source-стратегии: как Сбер развивает AI/ML-технологии — Максим Савченко, управляющий директор Sber AI Lab

На днях со мной согласился поговорить Максим Савченко, управляющий директор Sber AI Lab. Кстати, 29 ноября коллеги из лаборатории собирают большое мероприятие «Open Source & AI Agents», где поделятся опытом DS-спецы, исследователи и бизнес-лидеры. Там можно пообщаться с экспертами из индустрии, а если захотите выступить с докладом, организаторы открыты к предложениям (контакты — в конце поста). Далее делюсь расшифровкой нашего разговора по теме open source-подхода. Максим, расскажи, пожалуйста, о своей экспертизе и опыте работы с открытыми проектами в рамках запуска и развития Sber AI Lab, которая сегодня является одним из стратегических подразделений Сбера. Сейчас я — управляющий директор Sber AI Lab, которая была создана осенью 2017 года. Тогда я фактически стал её первым сотрудником — во всяком случае, после профессора Тужилина, который должен был её возглавить. Sber AI Lab существовала до лета 2025 года, а затем у нас произошла небольшая реорганизация, и ее переименовали в Центр практического ИИ. По ходу существования и развития лаборатории я пытался запустить создание open source-технологий в Сбере, в частности, в нашем подразделении. Осуществить это удалось только через пару лет — в 2019 году мы смогли впервые вывести в опенсорс одно из наших решений. Честно скажу, что до этого были некоторые сложности — идея делать опенсорс именно внутри компании находила поддержку далеко не у всех руководителей. У них были опасения на счет того, что создание опенсорса будет способствовать оттоку из организации ноу-хау. Однако этих людей удалось переубедить, и шесть лет с того момента мы разрабатываем системное ПО с серьезной математической составляющей. В целом open source в Сбере занимаются и другие команды — например те, которые работают с технологиями PostgreSQL и Greenplum, а также RuGPT. Однако создание полностью своего софта, причем системного, тяжелого ПО с серьезной математической составляющей — это наша специализация, и сегодня мы — единственные, кто это делает в Сбере. Если же смотреть в масштабе страны, то таких команд действительно мало, даже если брать отрасли, далекие от AI/ML. Есть удачные кейсы, где системный софт развивают внутри корпораций — например, ETNA в Т-Банке, а также RecTools в МТС. Это классные решения. Люди берут технологии уровня state of the art и реализуют их удобным для себя образом, чтобы DS-специалисты в компании могли получать к ним доступ, экономили время и силы. На такие технологические разработки ряд компаний охотно дает деньги. У нас же нет ни одной библиотеки, которую мы делали бы для импортозамещения, либо исключительно с точки зрения технологического «удобства» (чтобы в Сбере было удобно пользоваться какими-то алгоритмами, которые созданы на Западе или в Китае). Каждая библиотека, которую мы создаем, имеет под капотом набор оригинальных исследований. Как правило это — две-три статьи уровня A/А*. В таких статьях мы разрабатываем оригинальные подходы, алгоритмы, инструменты или методы, которые позволяют решать те или иные интересные нам задачи эффективнее чем все, что сейчас есть в мире. У нас есть порядка десятка открытых библиотек, хотя не все они взлетели. Некоторые были заморожены — например, Sim4Rec. Мы сделали симулятор, который позволяет, по сути, создать цифровых аватаров большого количества людей и на основе анализа их действий оценивать качество рекомендаций или как минимум ранжировать алгоритмы — смотреть, какие из них будут работать лучше относительно друг друга. Дело в том, что в задачах на ретро-данных сложно оценить качество рекомендаций: вы видите, как люди реагировали на те рекомендации, которые уже им показывали, но не знаете, как они отреагировали бы на другие товары и услуги. Но, как мы видим на примере Sim4Rec, далеко не каждый кейс с готовым результатом и публикациями на ведущих конференциях получает успешное развитие. Такие проблемы есть и у западного бигтеха, который, так же, как и мы, участвует в ведущих конференциях и занимается опенсорсом. До запуска Sber AI Lab мы были в числе тех, кто open source в Сбер активно «заносил». Это было примерно в 2015-2016 годах, когда мы отказывались от проприетарного софта, с помощью которого банк строил модели. Уже тогда работать с западным софтом было проблематично, и мы эту угрозу видели. Я тогда продвигал в первую очередь open source на Python — нам было нужно что-то верхнеуровневое, скриптовое, потому что у нас многие специалисты переходят в data science из финансистов и дата-аналитиков. Моя логика заключалась в том, что наши люди должны уметь работать на тех технологиях, которые мы будем создавать. Если же смотреть глубже, то до опенсорса я пытался делать «inner source» в Сбере. У нас около сотни человек занимались схожими вещами, и у меня возникла идея, что нам нужно разумнее тратить наши ресурсы. Пусть по меркам мирового бигтеха не такие значительные, но в масштабе России существенные. Вопрос был в том, как внутри банка распространять разработки и создать среду для этого. Этой темой я занимался около шести лет, но после нескольких попыток понял, что inner source «не заводится», причем не только у меня, но и у других сделать это не получается. И возникла идея использовать для трансфера технологий внутри большой корпорации open source. Поэтому для меня open source — инструмент, решающий задачи бизнеса. Какие есть пути выхода в open source в вашем случае? Ты называешь ваш open source «каналом доставки» research-решений в продакшен? Мне очень нравится делать то, что я делаю. Мы гордимся своей работой. Но в России не так много людей, которые делают нечто подобное. Я сейчас подразумеваю использование опенсорса как канала поставки исследований бизнесу. В России есть отличные ребята, которые пишут классный код на основе исследований. Например, это команда ИТМО (FEDOT — автоматизация машинного обучения). Такие коллективы есть не только там — еще есть энтузиасты Физтеха (взять хотя бы DeepPavlov). Но все эти примеры — это академический опенсорс. Это класс решений, которые создаются учеными и (часто) для ученых. Количество их «потребителей» измеряется десятками — максимум сотнями тысяч. Для более широкого применения в бизнесе, как правило, требуется индустриальный уровень софта. Это значит, что продукт должен работать на больших объемах, с жесткими SLA, хорошей документированностью и интрегрируемостью. Если эти требования не выполняются, его будет сложно использовать в бизнесе и для решения задач государства — не потому, что академический код плохой, а потому что он нужен для повышения эффективности исследований. А индустриальный код нужен для решения конечных задач граждан, бизнеса, промышленности и так далее. Создание такого кода — издержки, которые университеты нести просто не могут. В итоге есть неплохой код академического класса — это распространенный тип опенсорса в России, а также есть индустриальный код — например, им занимается Arenadata. Она берет Apache Spark, Greenplum, PostgreSQL и создает под российские условия адаптированные решения на базе опенсорса промышленного класса — например, для обработки данных. Такое делает и Сбер, хотя у нас это не всегда открытые решения. Это — индустриальный код, с помощью которого решаются технические задачи, но не создаются новые технологии. Вы ограничены рамками, которые заданы теми, кто создает ядро выбранной вами технологии: в рамках заданного фундамента и дома вы можете добавить этаж, сделать ремонт, расставить мебель, но вы не можете выходить за рамки общей конструкции, которая вам дана. И тут мы приходим к пониманию того, что замахиваться на создание с нуля оригинальный технологий на базе оригинальных исследований — это достаточно редкая история для опенсорса в России. Основные классы опенсорса у нас это: 1) форки существующих решений, которые делаются в интересах бизнеса, промышленности, государства; 2) академические проекты в интересах науки и образовательной деятельности; 3) небольшие разработки для широкого спектра пользователей (вроде автоматического переключения раскладки) от команд энтузиастов, хотя таким командам нередко удается делать классные штуки в рамках опенсорса; 4) исследования, причем тщательно отобранные, которые которые решают конкретные задачи бизнеса. Причем в последнем случае мы говорим не о задачах гипотетического бизнеса, который может возникнуть через пять лет, и не о задачах, которые «могли бы» существовать, а о реальных проблемах, где требуется научный подход. Вы решаете эти задачи и публикуетесь на конференциях высшего уровня не ради галочки и не для повышения статуса. Публикация — это не гарантия того, что у вас все «заведется». Но валидация на базе А/А*-конференций позволяет говорить о том, что вы наняли правильных людей, которые хорошо работают и решают у вас действительно актуальные задачи. А результаты вы уже воплощаете на промышленном уровне. В таком случае вы получаете инструмент или канал доставки ваших разработок и исследований бизнесу. Потому что вашим конечным потребителем является владелец платформы, для которого вы делаете ее ядро. Если вы добились такого уровня интеграции, когда каждая последующая ваша разработка становится мгновенно доступна такому потребителю и владельцу платформы, то вы таким образом создаете не просто способ монетизации науки и технологий, но и дешевый канал доставки, практически до нуля снижающий издержки донесения науки до бизнеса. Так каждая ваша научная разработка и метод быстро дойдет до потребителя и принесет пользу. > PyTorch-Lifestream: Learning Embeddings on Discrete Event Sequences (статья, код) > Tsururu: A Python-based Time Series Forecasting Strategies Library (статья, код) Но даже для крупной организации это сделать не так дешево. Поэтому мы работаем чуть иначе чем условные H2O, где делают, в том числе, решения с нуля с трудозатратами уровня сотен человеко-лет. Мы же активно переиспользуем существующие опенсорсные «кирпичики» и за счет этого ускоряемся, снижаем издержки на создание новых библиотек. Когда у нас уже есть пара статей, трудозатраты на которые могут занимать от 3-4 до 8 человеко-месяцев в зависимости от уровня конференции, то создание production ready-библиотеки — это несколько человеко-лет, возможно более десятка, но не сотни. Определенные ограничения такого подхода тоже есть — например, возникает вопрос обратной совместимости и стабильности элементов. И даже с такими лайфхаками Сбер — практически единственная компания в России, которая идет по этому пути в опенсорсе. Я могу назвать некоторые примеры других мест, где умели продуктивизировать науку. В какой-то момент это была ABBYY, другой более яркий пример — это ЦРТ (Центр речевых технологий). Определенного класса наука была в JetBrains. Закончилось это вопросами экономики. Те же JetBrains зарабатывали здесь очень небольшую часть денег, которые их бизнес приносил. В свою очередь, ЦРТ сейчас является частью экосистемы Сбера. То есть вам нужен либо якорный партнер, либо очень большой рынок, который Россия пока дать не может. Что с этим делать, я пока не могу сказать. Помимо усилий по подготовке исследований вы как-то дополнительно продвигаете публикации и результаты с точки зрения «обучения» широкой аудитории тому, чем вы занимаетесь? Делаете ли хабрапосты или что-то еще? Для меня open source — это инструмент, который позволяет эффективно распространять софт внутри крупной организации и подключать к сотрудничеству университеты. Но тут есть проблема — существуют важные вопросы защиты данных и соответствия требованиям регуляторов. Как правило, у вас есть внутренний сегмент, подключиться к работе с которым университеты просто так не могут. Вторая проблема состоит в том, что если вы работаете не на реальных данных, а на синтетике, вам сложнее гарантировать, что то, что вы сделали, будет работать в реальном мире. Open source-подход позволяет грамотно решать эти проблемы на этапе доработки ваших решений, подготовки каких-то материалов, когда нужно подключать университеты. Они для нас — что-то вроде «разгонного блока», который, пусть и не является основным приводом, но дает классный буст там, где это требуется. Без университетов мы бы не сделали и половины всего. В этом контексте получить деньги на НИРы гораздо проще и эффективнее, чем набирать людей в штат. Если говорить о продвижении, мы пытались что-то делать на хабре и сотрудничали с ODS, но быстро поняли, что людей, способных заниматься тяжелым, системным софтом, не так много, чтобы они могли работать в свободное время для души. Вклад таких энтузиастов у нас минимальный. Основное мы делаем сами, что-то еще делают люди из корпораций и университетов. Поэтому в какой-то момент я отказался от того, чтобы активно заниматься популяризацией, и на хабре мы пишем не так часто. В целом у нас достаточно сильный коллектив — десятки квалифицированных специалистов, в том числе PhD, нанятые на международном рынке труда, а также несколько Kaggle-мастеров. Мы выигрываем профильные соревнования и обходим команды H2O и Amazon на своих же технологиях, за которыми стоят масштабные оригинальные исследования, а также входим в топ-3 команд в мире с наибольшим числом ACM RecSys-публикаций. О том, что такое в России есть, мало кто знает, но для нас сейчас это не главное. Грубо говоря, деньги команде дает организация, и нам не нужно активно продвигать себя, чтобы получить финансирование. При этом у нас есть активное направление с образовательными курсами по нашим open source-технологиям. Например, это — курсы по RePlay, LightAutoML, pytorch-lifestream. У нас были попытки выходить за пределы и просчитывать варианты другой экономики. Но объем продаж, который мы могли бы сделать, работая с другими DS-командам через облака, не такой большой, чтобы затевать эту историю сейчас. Не у всех потенциальных потребителей зрелость бизнеса дошла до нужного уровня, другие не хотят отдавать что-то в облака, третьи — хотят делать все своими силами, пытаются заявить о себе. Не все в этом плане сводится к деньгам, особенно если мы говорим о крупном бизнесе. За последние несколько лет опенсорс стал динамичнее с точки зрения лицензионной политики. Ваши открытые решения имеют разные лицензии: MIT, Apache 2.0, BSD 3-Clause. Чем обусловлен их выбор? Большая часть того, что делаю я, выходит под Apache 2.0. Изначально я предлагал брать MIT, но юристы посчитали, что она недостаточно защитит права банка на интеллектуальную собственность. Apache 2.0 в данном случае стала разумным компромиссом. Для меня важно учитывать правила, по которым я должен играть в корпорации. У нас процесс выхода в open source включает несколько этапов: от получения свидетельства на регистрацию ПО в Роспатенте и заканчивая работой с юристами по дальнейшим шагам. За много лет работы у нас сложился определенный процесс. Помимо лицензий и code of conduct есть и некоторые другие инструменты для регулирования совместной работы с сообществом, вроде contributing-гайда и CLA (contributions license agreement) — используете ли вы их? Минимально необходимые вещи мы стараемся закладывать. Но с учетом того, что мы развиваем сотрудничество внутри организации и работу с университетами-партнерами, слишком уж сильно в это мы не вкладываемся. Да, чтобы снизить издержки на вовлечение новых партнеров, мы используем такие вещи, которые доступны в наших репозиториях. Код мы также стараемся документировать. Если этого не делать, то даже DS-специалисты нашего банка будут использовать другие инструменты. Мало сделать, мало занести — надо, чтобы люди хотели использовать то, что вы делаете. В это мы много инвестируем: создаем учебные курсы и руководства, как сами, так и с привлечением университетов. Как вы управляете обратной связью и мониторите свои открытые проекты? Есть отдельный специалист или команды занимаются своими проектами? Здесь у меня ситуация следующая. Если говорить про продукт, то в первую очередь у него есть владелец. Как правило, это — тимлид соответствующей команды, который отвечает за то, чтобы бизнес был удовлетворен. Бизнес же дает обратную связь по внутренним каналам. Параллельно мы смотрим, какие комментарии дают внешние люди. Если речь идет о том, что у нас что-то не работает, это ценно. Поэтому тимлиды смотрят, что прилетает извне, хотя в основном это положительные отзывы, а объемы остального крайне низкие. За такой обратной связью могут смотреть и senior-специалисты. Я также, как руководитель, заглядываю в репозитории и по мере необходимости могу уточнять, как идет работа. В работе с университетами есть закрепленные люди, которые отвечают за сотрудничество и совместные проекты. Здесь PM’ы и senior-специалисты несут ответственность за качество НИР, а за управление несет ответственность тимлид. Обратная связь тут живая, и работа с ней идет по ходу развития проектов. В качестве саммари мог бы ты, пожалуйста, дать верхнеуровневый взгляд на то, что дает открытый подход вашему Центру и Сберу в целом? Для меня наука, статьи и open source — это инструмент решения конкретных проблем. Он позволяет экономить и зарабатывать деньги. Если банк что-то делает много лет — в нашем случае восемь лет — можно говорить о том, что это рационально и разумно. Если делать саммари того, что open sourсe-подход позволяет нам осуществлять: Во-первых, в столь крупной организации, где есть жесткое регулирование, он позволяет быстро и эффективно перебрасывать технологии из места, где они появляются, туда, где они требуются. Замечу, что зачастую это не так просто делать даже в ведущих технологических компаниях. Например, определенные сложности появляются, если вашим продуктом является скорее статья, а не технология. Тогда статью сперва берет одна ваша команда и реализует в бизнесе, потом берет другая ваша команда и реализует в бизнесе (и так далее). Получается, ваша компания многократно платит за одно и то же. Выход в данном случае — это создание сквозных технологий. Мы в свою очередь разрабатываем RePlay. Это — один из ключевых элементов нашей рекомендательной системы AmazMe (решение, которое используется во всей экосистеме Сбера), где в команде также есть классные специалисты, которые пришли, в том числе, из Intel. Но мы все это делаем вместе, и по итогу получаем один фреймворк с результатами исследований, хотя там есть и много чего еще, что к науке отношения не имеет (вроде интеграций и метрик, которые делают люди, находящиеся ближе к бизнесу). Такая коллаборация работает гораздо эффективнее, чем делать все это в трех местах одновременно. В целом же open source-подход позволяет получить более развитую и зрелую технологию, чем если вы пустите это на самотек. Во-вторых, мы можем подключать внешних контрагентов — университеты и Академию наук. Здесь важно понимать, что какой бы огромной корпорации вы ни были, собрать в одном месте нужные компетенции практически нереально. Но за счет open source-подхода вы можете быстрее и дешевле выходить на партнеров с нужной экспертизой. В-третьих, чтобы делать решения мирового уровня, нужна команда мирового уровня. Для этого к вам должны идти люди, которые что-то круто умеют и хотят делать. Они выбирают место работы не только по финансовым условиям. Важны результаты работы, они со временем становятся портфолио, доступным другим коллегам, которые могут оценить его и понять, что вы делаете крутые вещи. Это существенно упрощает привлечение очень квалифицированных людей, без которых делать продвинутые технологии невозможно. Это три ключевых момента, которые дает нам open source-подход, хотя есть и другие. 29 ноября коллеги проводят мероприятие «Open Source & AI Agents», где поделятся опытом DS-спецы, исследователи и бизнес-лидеры. Если захотите выступить, организаторы открыты к предложениям (написать можно Алексею). Тематические треки, по которым возможно предложить свой доклад: • Open Source как основа инноваций в ИИ: от инструментов к агентам • Тренды Open Source в Data Science: библиотеки для машинного обучения • Разработка Open Source фреймворков для ИИ • Сообщество Open Source: коллаборация и вызовы • Практика с Open Source инструментами: анализ данных в Python • Open Source в исследованиях ИИ: публикации и коллаборации • Масштабирование Open Source проектов в ИИ • ИИ Агенты на базе Open Source: введение и примеры • Будущее ИИ Агентов: интеграция с Open Source экосистемой • От Open Source к ИИ Агентам: вызовы и возможности