Анализ и обработка данных — одно из ключевых направлений любой современной компании. У нас в ДомКлике оно существует с 2016 года, когда был нанят первый data scient’ист. С тех пор утекло много воды, менялись задачи и приоритеты, мы развивались. Сегодня у нас в этой области работает около 40 специалистов. Одна половина разрабатывает модели машинного обучения, а другая — поддерживает контур данных: создает хранилище, проверяет качество и так далее.
Казалось бы — что сложного — организовать работу нескольких команд? Есть данные, есть специалисты по их обработке, по идее на выходе должен быть Profit? Однако, как показывает наш опыт, простая мысль «хорошо делать — хорошо, а плохо делать — плохо» работает как минимум не всегда. Нужно искать ответы на множество вопросов — как встраивать Data Science команды в уже сформировавшуюся организацию, как обеспечить высокое качество и скорость разработки моделей, как эффективно наполнять бэклог новыми задачами — все это вопросы, на которые мы искали ответы.
Меня зовут Алексей Кузьмин, я руковожу направлением Data Science и работы с данными в ДомКлике. И в этой статье я расскажу о том, как мы решаем эти проблемы и как поддерживаем работу такого большого коллектива.
Формы организации
Начнем с ключевого вопроса — как вписать Data Science команды в имеющуюся организацию. Если почитать умные статьи и книжки, то можно выделить три формы организации работы DS-подразделения: централизованная, децентрализованная и гибридная, естественно, у каждой — свои достоинства и недостатки.
В централизованной схеме есть одна или несколько команд, которые разрабатывают data science-модели. Команды являются единым центром компетенции, а бизнес-подразделения компании — заказчиком для них. Схема хороша тем, что бэклог data science-команд прозрачен для руководства. Часто бывает, что от разных бизнес-подразделений приходят две конкурирующие задачи, и тогда можно сосредоточиться на той, которая будет полезна для компании в целом и принесет бо́льшую выгоду. Однако, при такой форме организации снижается оперативность, бизнес-подразделениям приходится ждать выполнения своей задачи. Также усложняется разработка (особенно на этапах исследования данных и понимания бизнес-проблемы) для Data Science-специалистов, так как переход от задачи к задаче требует погружения в новый контекст.
В децентрализованной схеме у каждого бизнес-подразделения есть собственная маленькая команда или отдельный человек, который разрабатывает data science-модели конкретно для этого подразделения. Преимущества схемы в том, что не теряется оперативность и специалисты всегда в контексте своей бизнес области. Зато теряется прозрачность. В такой схеме нельзя гарантировать, что специалисты работают над актуальными задачами. Например, если сейчас бизнес-подразделению горит сделать какой-то отчет, то это могут легко и не задумываясь поручить DS-специалисту, а это демотивирует. К тому же, с ростом численности теряется централизованный контроль за их работой. Чтобы этого избежать, приходится с каждым встречаться индивидуально, погружаться в его задачу, контролировать его работу. Это требует времени, которого не всегда хватает. Из-за этого часто страдает качество создаваемых решений.
В гибридной схеме есть основные команды, и дополнительно в каждом бизнес-подразделении есть свой аналитик или команда для решения определённых задач. Эта схема хороша, лишена недостатков двух других и пытается взять из них всё лучшее. Но, как показывает практика, такая структура хорошо работает лишь при большом количестве специалистов. То есть она эффективна только в рамках гигантских корпораций, а в компаниях с численностью до тысячи человек такая схема расточительна.
Как у нас?
В нашей компании принята централизованная модель. Это ��ознательное решение, потому что сейчас мы хотим понимать, что работаем над действительно важными задачами. Кроме того, наши специалисты отвечают за многочисленные корневые сервисы, которые обслуживают все подразделения в компании:
- чат-бот;
- модерация и проверка текстовых данных;
- распознавание и классификация документов и других изображений;
- модели прогнозирования, конверсии, рекомендаций и так далее.
У нас две централизованные команды. Одна занимается обработкой текстовых и голосовых данных, вторая отвечает за работу с изображениями. Задачи классического машинного обучения распределены по обеим командам примерно поровну. Эта организационная схема существует около полутора лет. Если в бизнес-подразделении возникает небольшая переходящая задача, которую надо сделать прямо сейчас, то благодаря большому опыту и наработкам по другим проектам зачастую удается ее решить достаточно оперативно и высоким качеством уже на этапе baseline.
Когда мы перешли к схеме с двумя командами, появилась новая проблема: часть задач в области работы с моделями была для них общей — создание и хранение обучающих и тестовых наборов, документирование, запуск обучения и т. п. Как следствие, в середине 2019 года мы создали третью команду, которая тоже относится к DS-направлению, но разрабатывает не модели, а инструментарий, в частности, небольшой внутренний реестр — платформу, в которой теперь хранятся почти все наши обучающие и тестовые наборы данных. Благодаря заложенному при планировании версионированию, мы понимаем на каких именно данных была обучена та или иная модель и можем воспроизвести обучение, если потребуется. Ну и разумеется мы больше не ищем датасеты в сетевых папках и таблицах хранилища )
Также мы создали сервис, в котором хранится информация по всем нашим моделям. При создании новой модели она сразу заносится в сервис, мы ее описываем, указываем обучающий набор данных, добавляем ссылку на репозиторий в Bitbucket. Разумеется, есть и библиотека на Python, которая при каждом обучении модели вносит в реестр запись об обучении, полученные метрики и артефакты(веса, структуру модели и так далее).
Платформенная команда очень помогла упорядочить работу над моделями: теперь мы знаем сколько их, какие они, сколько раз они обучались, как менялись их результаты. Но не надо думать, что она полезна исключительно для DS-специалистов. Команда создает централизованные инструменты Data Science для всей компании. Например, сейчас она разрабатывает сервис AutoML для прикладных бизнес-подразделений. Он поможет проводить умную аналитику без привлечения Data Scient’истов и снимет часть проблем централизованной модели организации.
Бэклоги
И напоследок расскажу о том, как мы формируем бэклоги команд.
Обе централизованные команды сейчас занимаются несколькими ключевыми направлениями. При традиционном Agile-подходе есть владелец продукта, который собирает бэклог и развивает продукт. Но когда в команде несколько таких продуктов, то, по нашему опыту, все владельцы продуктов задействованы в текущих задачах и им тяжело прорабатывать новые.
Поэтому мы ввели у себя роль бизнес-партнёра. Он не входит ни в одну из команд, а отвечает за проработку бэклога на будущее: обращается к прикладным бизнес-подразделениям, спрашивает, что у них есть интересного из задач и какие ключевые проблемы существуют, подсказывает, как могут помочь модели. Этот специалист способен верхнеуровнево проработать задачу и понять, может ли data science принести пользу. Он формулирует первичные гипотезы для проверки, анализирует их и передаёт командам. Благодаря этому мы поддерживаем актуальность бэклога в среднесрочной перспективе — мы понимаем, что когда решим текущие задачи, работа не остановится.
В сухом остатке
В сухом остатке структура Data Science подразделения устроена так:
- DS-руководитель: это я. Зона ответственности: формирование стратегии развития, поддержание DS-компетенции, работа с сотрудниками.
- DS-бизнес партнер. Зона ответственности: проработка новых задач и направлений на предмет применимости Data Science; аудит существующих процессов и внедрений моделей.
- Платформенная команда: разработка и поддержание централизованных инструментов — реестра моделей и датасетов, AutoML и др.
- CV и NLP-команды: прикладные команды, разрабатывающие модели.
Запросы на новые задачи от бизнес-подразделений или руководства сначала поступают на аудит бизнес-партнеру, и только затем поступают в бэклог прикладных команд. После этого они (прикладные команды) уже общаются напрямую с заказчиком. Схематично это выглядит так:
Резюме
Организация эффективной работы data science-коллектива в рамках большой компании — сложная задача. Мне не известны примеры, когда это было сделано сразу и хорошо. Это процесс, когда ты идешь от плохого к не такому плохому, и делаешь это раз за разом, пробуя и ошибаясь.
Надеюсь, что этот опыт будет полезен, или как минимум интересен читателям )