[Из песочницы] Как мы организовали анализ и обработку данных в ДомКлик
Анализ и обработка данных — одно из ключевых направлений любой современной компании. У нас в ДомКлике оно существует с 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-коллектива в рамках большой компании — сложная задача. Мне не известны примеры, когда это было сделано сразу и хорошо. Это процесс, когда ты идешь от плохого к не такому плохому, и делаешь это раз за разом, пробуя и ошибаясь.
Надеюсь, что этот опыт будет полезен, или как минимум интересен читателям)
