На днях со мной согласился поговорить Максим Савченко, управляющий директор Центра практического искусственного интеллекта Сбербанка (Sber AI Lab).
Кстати, 29 ноября коллеги собирают большое мероприятие «Open Source & AI Agents», где поделятся опытом DS-специалисты, исследователи и бизнес-лидеры. Там можно пообщаться с экспертами из индустрии, а если захотите выступить с докладом, организаторы открыты к предложениям (контакты — в конце поста).
Далее делюсь расшифровкой нашего разговора по теме open source-подхода.
Максим, расскажи, пожалуйста, о своей экспертизе и опыте работы с открытыми проектами в рамках запуска и развития Sber AI Lab, которая сейчас выросла в Центр практического искусственного интеллекта Сбербанка и является одним из стратегически важных подразделений Сбера.
Сейчас я — управляющий директор Центра практического искусственного интеллекта Сбербанка (Sber AI Lab), которая была создана восемь лет назад как лаборатория искусственного интеллекта. Тогда я фактически стал её первым сотрудником — во всяком случае, после профессора NYU Тужилина, который должен был её возглавить. Sber AI Lab существовала до лета 2025 года, а затем преобразовалась в Центр практического ИИ.
По ходу существования и развития лаборатории мы работали над запуском и развитием разработки open source-технологий в Сбере, в ч��стности, в нашей команде. Осуществить это удалось только через пару лет — мы смогли вывести в open source одно из наших решений. Честно скажу, были некоторые вызовы на пути — идея делать open source внутри компании находила поддержку далеко не у всех руководителей. Были опасения на счет того, что создание open source будет способствовать оттоку из организации ноу-хау-решений. Однако стейкхолдеров удалось переубедить, и шесть лет с того момента мы разрабатываем системное ПО с серьезной математической составляющей. Во многом это все удалось благодаря поддержке первого зампреда Александра Ведяхина.
Разработкой open source в Сбере занимаются и другие команды — например те, которые работают с технологиями PostgreSQL, Greenplum, RuGPT. Однако создание полностью своего софта, причем системного, тяжелого ПО с серьезной математической составляющей — это наша специализация, и сегодня мы — единственные, кто это делает это в компании на регулярной основе. Если же смотреть в масштабе страны, то таких команд действительно мало, даже если брать отрасли, далекие от AI/ML.
Есть удачные кейсы, где системный софт развивают внутри корпораций — например, ETNA в Т-Банке, а также RecTools в МТС. Это классные решения. Люди берут технологии уровня state of the art и реализуют их удобным для себя образом, чтобы DS-специалисты в компании могли получать к ним доступ, экономили время и силы. В такие технологические разработки ряд компаний охотно инвестирует.
Нам удалось соединить такие практики с исследованиями, так что каждая библиотека, которую мы создаем, имеет под капотом набор оригинальных методов. В среднем это две-три статьи уровня A/А*. В этих статьях мы разрабатываем оригинальные подходы, алгоритмы, инструменты, которые позволяют решать интересные бизнесу банка задачи эффективнее чем все, что сейчас есть в мире.
Еще до запуска Sber AI Lab мы были в числе тех, кто применение open source в Сбере активно развивал. Это было примерно в 2015-2016 годах, когда мы отказывались от проприетарного софта, с помощью которого банк строил модели. Уже тогда работать с западным софтом было проблематично, и мы это видели.
Я и мои коллеги в лаборатории тогда продвигали в первую очередь open source на Python — нам было нужно что-то верхнеуровневое, скриптовое, потому что у нас многие специалисты переходят в data science из финансистов и дата-аналитиков. Логика заключалась в том, что освоить Python таким специалистам проще, чем Scala или Java.
До open source мы пытались делать так называемый «inner source» в Сбере. В банке тогда команды занимались схожими задачами, и была идея, что нужно разумнее тратить наши ресурсы и переиспользовать разработки внутри компании. Вопрос был в том, как внутри банка и экосистемы распространять разработки и создать среду для этого. В какой-то момент возникла идея использовать для трансфера технологий open source. Поэтому для меня open source помимо прочего это инструмент, решающий задачи бизнеса, снижающий издержки.
Какие есть пути выхода в open source в вашем случае? Ты называешь ваш open source «каналом доставки» research-решений в продакшен?
Мне очень нравится делать то, что я делаю. Мы гордимся своей работой. Но в России не так много команд, которые делают нечто подобное.
В России есть отличные ребята, которые пишут классный код на основе исследований. Например, это команда ИТМО (FEDOT — автоматизация машинного обучения). Такие коллективы есть в нескольких университетах, например, еще есть энтузиасты Физтеха (взять хотя бы DeepPavlov). Но все эти примеры — это академического опенсорс. Это класс решений, которые создаются учеными и (часто) для ученых.
Для более широкого применения в бизнесе, как правило, требуется индустриальный уровень софта. Это значит, что продукт должен работать на больших объемах, с жесткими SLA и т.д. Если эти требования не выполняются, его будет сложно использовать в бизнесе или для решения задач государства — не потому, что академический код плохой, а потому что он создается для другого, в первую очередь для повышения эффективности исследований, проверки новаторских подходов. А индустриальный код нужен для решения конечных задач граждан, бизнеса, промышленности и так далее. Разработка такого кода требует не только серьезных ресурсов, которых у энтузиастов в университетах часто может не хватать.
В итоге есть неплохой код академического класса — это распространенный тип опенсорса в России, а также есть индустриальный код — например, им занимается Arenadata. Она берет Apache Spark, Greenplum, PostgreSQL и создает под российские условия адаптированные решения на базе опенсорса промышленного класса — например, для обработки данных. Это — индустриальный код, с помощью которого решаются технические задачи, но не создаются новые технологии. Вы ограничены рамками, которые заданы теми, кто создает ядро выбранной вами технологии: в рамках заданного фундамента и дома вы можете добавить этаж, сделать ремонт, расставить мебель, но вы не можете выходить за рамки общей конструкции, которая вам дана извне. И тут мы приходим к пониманию того, что замахиваться на создание с нуля оригинальных технологий на базе оригинальных исследований — это достаточно редкая история для опенсорса в России.
Основные классы опенсорса в России, наверное, более 90% это: 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, это итог компромисса по итогам обсуждения с юристами. Процесс выхода в open source сейчас включает несколько этапов: от получения свидетельства на регистрацию ПО в Роспатенте и заканчивая работой с юристами по дальнейшим шагам. За много лет работы у нас сложился определенный процесс.
Помимо лицензий и code of conduct есть и некоторые другие инструменты для регулирования совместной работы с сообществом, вроде contributing-гайда и CLA (contributions license agreement) — используете ли вы их?
Минимально необходимые вещи мы стараемся закладывать. Но с учетом того, что мы развиваем сотрудничество внутри организации и работу с университетами-партнерами, слишком сильно в это мы не вкладываемся. Да, чтобы снизить издержки на вовлечение новых партнеров, мы используем такие вещи, но не более.
Код мы, конечно, стараемся документировать. Если этого не делать, то даже DS-специалисты нашего банка будут использовать другие инструменты. Мало сделать, мало донести потребителю — надо, чтобы люди хотели использовать то, что вы делаете. В это мы много инвестируем: создаем учебные курсы и руководства, как сами, так и с привлечением университетов.
Как вы управляете обратной связью и мониторите свои открытые проекты? Есть отдельный специалист или команды занимаются своими проектами?
Здесь ситуация следующая. Если говорить про продукт, то в первую очередь у него есть владелец. Как правило, это — тимлид соответствующей команды, который отвечает за то, чтобы бизнес был удовлетворен. Бизнес же дает обратную связь по внутренним каналам.
Параллельно мы смотрим, какие комментарии дают внешние люди. Если речь идет о том, что у нас что-то не работает, это ценно. Поэтому тимлиды смотрят, что прилетает извне, хотя в основном это положительные отзывы, а объемы остального крайне низкие. За такой обратной связью могут смотреть и senior-специалисты. Я также, как руководитель, заглядываю в репозитории и по мере необходимости могу уточнять, как идет работа.
В работе с университетами есть закрепленные люди, которые отвечают за сотрудничество и совместные проекты. Здесь PM’ы и senior-специалисты несут ответственность за качество НИР, а за управление несет ответственный тимлид. Обратная связь тут живая, и работа с ней идет по ходу развития проектов.
В качестве саммари мог бы ты, пожалуйста, дать верхнеуровневый взгляд на то, что дает открытый подход вашему Центру практического ИИ Сбера (Sber AI Lab) в целом?
Для меня наука, статьи и open source — это инструменты решения конкретных проблем. Они позволяют экономить и зарабатывать деньги. Если банк что-то делает много лет — можно говорить о том, что это рационально и разумно.
Если делать саммари того, что open sourсe-подход позволяет нам осуществлять:
Во-первых, в столь крупной организации, где есть масса ограничений и правил, он позволяет быстро и эффективно перебрасывать технологии из места, где они появляются, туда, где они требуются. Замечу, что зачастую это не так просто делать даже в ведущих технологических компаниях. Если вашим продуктом является скорее статья, а не технология, то нередко статью сперва берет одна ваша команда и реализует в бизнесе, потом берет другая ваша команда и реализует в другом бизнесе (и так далее). Получается, компания многократно платит за одно и то же. Выход в данном случае — это создание сквозных технологий.
Например, мы разрабатываем RePlay в плотной кооперации с коллегами, отвечающими за RecSys-платформу. Вся работа идет сообща, и по итогу получаем единый фреймворк с результатами исследований, хотя там есть и много чего, что к науке отношения не имеет (вроде интеграций и метрик, которые реализуют специалисты, находящиеся ближе к бизнесу). Такая коллаборация работает гораздо эффективнее, чем если делать все в трех разных местах. В целом же 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 к ИИ-Агентам: вызовы и возможности
