Представьте, что вы лидер молодого, но быстрорастущего стартапа в области ML. Вам предстоит собрать команду, и вы думаете о том, каких специалистов вам предстоит найти:
Data Scientist — для создания прототипов моделей машинного обучения, подходящих по задачи вашего проекта;
ML Engineer — для внедрения в эксплуатацию моделей и сценариев, масштабирования;
Data Engineer — для создания ETL‑процессов, систематизации сбора и хранения данных;
DevOps/MLOps — для автоматизации процессов и развития инфраструктуры;
SRE — для обеспечения мониторинга и надёжности вашей инфраструктуры.
Организовать работу всех направлений с нуля будет задачей не из лёгких. Но как принять этот вызов, если вы не обладаете экспертизой во всех направлениях?
Современные ML-платформы
С ответом на этот вопрос выходим мы — команда Сбера по разработке ML‑платформы, специализирующейся на создании рекомендаций для внешних и внутренних продуктов бизнеса. Цель нашего инструмента — упростить внедрение систем, помогающих пользователю в выборе из ленты предложений (будь то выбор товаров, медиаконтента или оборудования для ваших сотрудников).
Платформа предлагает множество технических решений, требующихся для конкурентоспособности в мире ML. Рекомендательные системы непрерывно собирают и обрабатывают данные, обучают модели, выводят их в A/Б‑тестирование, ставят рекомендации в online‑, nearline‑ и offline‑режимах. Наше решение не исключение и имеет богатую инфраструктуру для разработчиков.
Решение этих задач отвлекает разработчика от главного — создания релевантного предложения для своих пользователей. Однако, благодаря платформенному подходу возможно разделение сфер ответственности, когда DS- и ML-специалистам не будет необходимости погружаться в подробности инфраструктуры. Именно здесь SDK выступает в роли «руки помощи», ведущей разработчика через весь путь разработки на платформе.
Принципы разработки SDK
Мы разрабатываем платформу более трёх лет, и за это время вывели для себя несколько правил создания продуктов, ориентированных на других разработчиков.
Понимание целевой аудитории
Успех SDK напрямую зависит от понимания потребностей и привычек пользователей. Неправильное же понимание аудитории может привести к созданию мощного продукта с неподходящим интерфейсом, и целевая аудитория не сможет увидеть преимуществ такого решения.
Для нашей платформы основными пользователями обычно являются аналитики исследователи и специалисты по машинному обучению, привыкшие работать с Python-библиотеками и специализированными фреймворками.
Стандартизация повторяющихся паттернов
Анализ подходов различных команд разработчиков часто выявляет схожие паттерны решения задач. Эти повторяющиеся элементы можно вынести в стандартизированные шаблоны, которые ускорят интеграцию новых пользователей
Изначально наш SDK появился как попытка стандартизовать подходы первых пользователей по взаимодействию с сервисами или данными. Позже через него получилось, наоборот, задавать стандарты, передавая лучшие наработки клиентам.
Однако стандартизация оправдана только при наличии устоявшихся подходов. Если решения и методы находятся в процессе формирования, то преждевременная стандартизация может привести к необходимости последующего переписывания кода.
Предоставление знакомых интерфейсов
Один из наиболее эффективных способов снижения барьера входа — скрытие сложности за простыми, интуитивно понятными интерфейсами. Например, процесс развёртывания модели, включающий в себя множество технических шагов (отправку запроса, аутентификацию, проверку статуса), можно обернуть в простую функцию:
Такой подход значительно упрощает работу пользователей и снижает количество ошибок при интеграции.
Разумное использование абстракций
Абстракции особенно полезны при работе со взаимозаменяемыми инфраструктурными компонентами. Они позволяют пользователям легко переключаться между различными технологиями без изменения кода, просто изменив конфигурацию.
Мы, как платформа, стараемся работать гибко и предоставлять пользователю выбор там, где это возможно. Например, если говорить о хранилище признаков, то мы можем предоставить базу данных, которая покроет большинство потребностей пользователя, или же дать что‑то более производительное, если такая потребность имеется.
Однако важно помнить: абстракции работают только тогда, когда можно полностью игнорировать технологию под капотом. Если пользователям регулярно приходится обращаться к настройкам базовой технологии, то абстракция «протекает» и смысл её теряется (доказано на печальном опыте).
Качественная документация как инвестиция
Как попадание с интерфейсом в пользовательскую ЦА, так и подробная документация может существенно повлиять на опыт пользователя
Подробная и понятная документация — это не просто справочный материал, а инструмент масштабирования поддержки. Хорошая документация снижает количество обращений в службу поддержки и ускоряет процесс интеграции. Документация должна быть настолько простой и понятной, чтобы её мог использовать любой разработчик без дополнительных консультаций.
Управление обратной совместимостью
Нарушение обратной совместимости — один из самых болезненных аспектов для пользователей SDK. Неожиданные изменения в API могут привести к полной остановке рабочих процессов. Чтобы избежать блокирующих багов и непонимания, рекомендуется:
заранее предупреждать о планируемых изменениях;
внедрять deprecation‑политики;
поддерживать устаревшие интерфейсы в течение определённого периода времени (например, шесть месяцев);
предоставлять руководства по мигрированию.
Ошибки — это нормально
Правила и рекомендации, описанные выше, мы вывели в ходе проб и ошибок, удачных запусков и забытых MVP. Будут ли повторяться подобные взлёты и падения? Конечно же «да».
Давление бизнеса на быструю разработку часто приводит к накоплению технического долга. Хотя быстрые прототипы могут дать краткосрочные результаты, долгосрочный успех требует баланса между скоростью поставки и детальной проработкой.
В первые два года мы вели разработку по принципу «амбициозные цели приведут к амбициозному развитию», что действительно эффективно работало долгое время. Однако мы пришли к тому, что скорость разработки снизилась, потому что у нас накопился техдолг, нам надо поддерживать уже имеющиеся решения, и стало ясно, что «девиз» перестал быть актуальным.
Важно действовать гибко, с пониманием, что принятые подходы могут устареть, и важно вовремя отловить этот момент, чтобы обновить их.
Преимущества и ограничения SDK
Нельзя не сказать о том, как работу с нами видит пользователь платформы. В его опыте явно есть вещи, упрощающие жизнь и усложняющие её. Что же он получает в конечном счёте?
Преимущества
Масштабирование команды: SDK позволяет продуктовым командам сосредоточиться на бизнес‑логике, делегируя разработку интеграций команде платформы.
Неожиданные улучшения: независимая разработка SDK может принести неожиданные улучшения производительности и экономию ресурсов.
Аккумуляция лучших практик: в стандарт попадают наиболее эффективные решения, проверенные различными командами.
Ограничения
Скорость внедрения: новые возможности проходят через процесс оценки и стандартизации, что может замедлить их появление в продукте.
Ограниченная гибкость: не все специфические решения могут быть включены в универсальный SDK, что может ограничивать возможности некоторых пользователей.
Заключение
В конце хочется сказать, что разработка SDK — это непрерывный процесс поиска баланса между простотой использования и функциональностью, между стандартизацией и гибкостью, между скоростью разработки и качеством продукта. Успешный SDK должен не просто предоставлять доступ к функциональности платформы, но и направлять пользователей по оптимальному пути решения их задач.
Ключевые принципы успешного SDK:
глубокое понимание потребностей пользователей;
стандартизация там, где это целесообразно;
предоставление интуитивно понятных интерфейсов;
разумное использование абстракций;
качественная документация;
ответственное управление изменениями API.
Соблюдение этих принципов поможет создать инструмент, который не только решит технические задачи, но и станет ключом к успеху для команд разработчиков, использующих ваш продукт.
Автор: @NMLS