Data & Science: управление проектами

14 апреля 2018
Москва, Россия
Купить видео
В избранное

Александр Белугин

Преподаватель в ФКН ВШЭ

Роман Чеботарев

CTO в Theta Data Solutions

Алексей Арустамов

Директор в Loginom Company

Андрей Белов

Руководитель службы подбора персонала для поискового портала в Яндекс

О мероприятии

Тематика: Менеджмент

На конференциях Data & Science эксперты по работе с большими данными рассказывают об их применении в науке, экономике и других сферах жизни. В этот мы говорили о бизнесе.

На конкретных примерах мы рассмотрели жизненный цикл проектов data science, поговорили о тонкостях реализации и проблеме аргументации результатов заказчику, затронули тему найма и оценки специалистов и обсудили различные форматы ведения data science проектов.

Для кого

  • Техническим директорам
  • Системным аналитикам
  • Инженерам по машинному обучению
Поделиться

Расписание

Развернуть все
14 апреля (суббота)
День 1
Показать
цену в
$
Получить доступ ко всем докладам
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Александр Белугин

Преподаватель в ФКН ВШЭ

Жизненный цикл коммерческого ML-проекта

Короткая версия доклада:


Согласно наиболее распространенной методологии машинного обучения CRISP DM, а также аналогичным решениям (SAS SEMMA, MS TDSP), процесс исследования данных начинается с понимания сути бизнеса и определения бизнес-целей.

Затем наступает очередь анализа и подготовки данных, моделирования, оценки решения и, наконец, внедрения непосредственно в работу предприятия.

Для выбора задачи и понимания бизнес-процессов действует правило 1% - если ожидаемый экономический эффект от ML-проекта больше этого показателя, то в этом направлении можно работать, оно стоит затраченных усилий. При оценке результата внедрения необходимо, чтобы KPI проекта и стратегия бизнеса совпадали, чтобы учитывались все факторы, - от чисто бухгалтерских до отношений с клиентами, чтобы в распоряжении разработчика имелись статистически значимые данные.

При этом следует учитывать фактор базы для сравнения - у организаций, бизнес-процесс которых нуждается в улучшении, эффект от него будет быстро утерян по мере отладки, а там, где сами процессы уже более или менее налажены, возникает необходимость повысить отдачу еще на несколько процентов благодаря новым ML-проектам.

После завершения необходимых расчетов, при начале реализации коммерческого ML-проекта разработчику важно учесть, допускает ли он полную автоматизацию или система будет иметь статус консультанта без возможности принятия решений, какие будут требования к техническим ресурсам и интерпретируемости полученных данных.

Еще один аспект эффективности внедрения, который нельзя недооценивать, - доступность данных, которые могут находиться в агрегированном, неоцифрованном или неудобном для чтения или ввода виде, и работа с которыми будет зависеть от каналов связи и скорости извлечения. Наконец, ещё одним фактором для выбора задачи является её новизна, которая определяется путём поиска и изучения открытых кейсов, научных публикаций, патентов.

После определения метрик, задач и целей проекта необходимо построить модель, для чего используется план экспериментов, предусматривающий добавление новых данных и их предобработку, а затем и тестирование по различным метрикам.

На этапе внедрения и развития готового продукта разработчику следует решить такие вопросы, как возможная скорость деградации, риски изменений исходных условий и среды, сложность или лёгкость переобучения, авто-оценка качества. По завершении оценки всех рисков и возможностей, остаётся определиться, насколько автоматизированной будет модель, в какой степени она сможет самостоятельно себя поддерживать и обновляться. Важную роль здесь будет играть система мониторинга – ИТ-сервиса, состояния, качества и результатов.

Оценивая все этапы в целом, следует отметить, что критически важными для всего проекта являются стадии постановки задачи, при которой определяется направление разработки, а также внедрения готового решения, т.е. самый первый и конечный отрезки рабочего процесса, когда фактор человеческой ошибки наиболее весом.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Роман Чеботарев

CTO в Theta Data Solutions

Fix Price, T&M или Success Fee — что выбрать для своего data science проекта

Короткая версия доклада:


Типовые организационные формы ведения DS проектов могут помочь разработчикам правильно выбрать правильную стратегию и избежать проблем с заказчиком на заключительном этапе реализации.

Одна из самых распространенных моделей, далеко не уникальная для DS, — это Fix Price, предполагающая фиксацию сроков исполнения, объёма оказываемых услуг и их стоимости, а также передачу клиенту прав на интеллектуальную собственность. Это наиболее распространённый способ организации проектов, а в случаях с тендерами крупных организаций — единственно возможный вариант.

Стоит учесть, что при выборе данной модели разработчик часто рискует столкнуться с желанием заказчика увеличить объемы и сроки, и задачей проект-менеджера на первом этапе проекта станет детализация бизнес-требований, функциональных требований, частных технических заданий. Необходимо разработать устав проекта с распределением и четким указанием лиц, отвечающих за конкретные направления. Также следует, насколько это возможно, избегать фиксации в контракте тех или иных показателей метрики качества (точность прогноза, классификации и т.п.), так как любые новые данные могут кардинально повлиять на бизнес-процесс и возможность успешного завершения проекта.

Вариант с моделью T&M (time and material) требует большей гибкости от заказчика и очень удобен для исполнителей, особенно небольших команд. В рамках модели расчеты ведутся пропорционально затраченному времени, задачи чаще всего жестко не определены, ставки фиксированы, предусмотрены регулярные платежи, право интеллектуальной собственности остается у клиента. Модель, как правило, используется тогда, когда заказчик не знает или не может чётко сформулировать задачу, и ему требуется помощь в её формулировке, либо тогда, когда есть необходимость в решении множества точечных задач, которые нельзя собрать в один контракт. Часто одним из результатов работ становится получение от заказчика ТЗ на следующий этап разработки, однако негативной особенностью T&M-модели является неравномерность загрузки и то, что проект может закончиться в любой момент.

Третья базисная модель — Success Fee — пока не получила широкого распространения в России, но, тем не менее, все чаще входит в деловой обиход при реализации DS-проектов. Идея модели состоит в том, что разработчик обязуется улучшить бизнес заказчика в какой-либо конкретной точке — увеличить определённый показатель или достичь определённого эффекта, которые, чаще всего, выражаются в денежной форме. В случае успешного достижения результата разработчик получает процент в зависимости от полученного эффекта. Как правило, работа осуществляется по сервисной модели, без вовлечения в неё клиента, который лишь обязуется предоставлять необходимые данные и осуществлять регулярные платежи. При этом интеллектуальная собственность остается у исполнителя.

Сложность модели в первую очередь обусловлена невозможностью четкого определения эффекта, который необходимо получить, и трудностями с его контрактным оформлением. Во-первых, необходимо определить базис для его расчёта, для которого используются исторические данные, на основании сопоставимых условий и с учётом погрешности измерений и расчётов. Во-вторых, нужно обговорить с заказчиком пересмотр исходных (baseline) метрик с определенной частотой, чтобы избежать так называемую деградацию эффекта, когда по прошествии определенного времени достигнутый разработчиком результат становится исходным показателем, на основе которого он должен добиваться новых успехов.

В-третьих, контракт с заказчиком должен специально оговаривать критичные и некритичные для исполнителя случаи изменения процессов у клиента. В-четвертых, необходимо контрактным способом зафиксировать минимальное количество использования сервиса, чтобы избежать ситуации, когда разработанный и внедренный проект почти не используется клиентом и не приносит вознаграждения разработчику.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Алексей Арустамов

Директор в Loginom Company

Как не работать в стол: управление проектами с высокой ценой ошибки

Короткая версия доклада:


Как правило, ML-проекты нацелены на решение задач в сфере поиска и предоставления различных вариантов рекомендаций. Для того, чтобы понять, каким образом такие проекты можно использовать в бизнесе, необходимо учитывать, что около 80% российской экономики приходится на традиционные отрасли (строительство, торговля, банковское дело), участники которых решают такие задачи, как оптимизация запасов, управление рисками, производство, логистика, поддержание клиентской лояльности.

Однако аналитическая поддержка решения этих задач, как правило, далеко не эффективна. Огромные массивы накопленных данных и проекты на их основе практически не используются или используются плохо, что в первую очередь объясняется отсутствием доступных интерпретаций и зачастую высокой ценой ошибки, что подрывает доверие заказчиков к Data Science в целом.

Таким образом, можно сделать вывод, что внедрению ML-проектов в большом бизнесе мешает отсутствие доверия, понимания и предсказуемости для заказчиков. Для преодоления данного препятствия необходимо чётко указать на имеющиеся ограничения, подробно раскрыть всю последовательность решений и аргументацию для каждого из них, провести тестирование и предусмотреть сценарии поведения системы в нестандартных случаях. Можно сказать, что основная задача разработчика в том, чтобы предлагаемый им проект перестал быть «черным ящиком» для заказчика.

В качестве примера рассмотрим эволюцию кредитного скоринга в России, который первоначально основывался на жестких правилах принятия решения в каждом конкретном случае. По мере накопления данных, стали внедряться обобщенные дженерик-модели, подготавливаемые различными бюро кредитных историй, доверие к которым основывалось на авторитете экспертов-разработчиков. По прошествии времени появились и индивидуальные модели, в построении которых принимали участие сами клиенты.

В настоящее время наиболее актуальное направление в кредитном скоринге – промышленное моделирование, предполагающее построение десятков, а то и сотен скоринговых карт. Доверие заказчиков здесь возникает не к конкретной модели, а к самому процессу их разработки. Основной инструмент доказательства адекватности скоринговой модели для заказчика – её паспорт, объёмный документ, содержащий раздел с информацией о сфере применения, блок подготовки данных (первичный аудит недостоверных данных, информация об исключаемых атрибутах, правила обработки редких ситуаций, описание формул и правил формирования атрибутов, требования к обязательным атрибутам, факторы риска, определение события, итоговая выборка), раздел моделирования (отбор атрибутов, построение модели, оценка её качества), описание системы мониторинга и блок финальной проверки. Чем больше данных в паспорте предоставляется клиенту, тем менее вероятность получения претензий к разработке с его стороны.

Обобщая сказанное, отметим, что доверие заказчиков к разработке повышается благодаря таким факторам, как указание области применения и ограничений, объяснение всех преобразований, указание правил обработки в граничных случаях, объяснение отбора факторов, объяснение модели (если это возможно), её тестирование, расчет индикаторов качества модели, осмысленность с точки зрения бизнес-логики.

Доверие клиентов необходимо взращивать, переходя от простых моделей к более сложным, тогда цена ошибки не будет стоп-фактором для внедрения и использования ML-проектов в бизнесе.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Андрей Белов

Руководитель службы подбора персонала для поискового портала в Яндекс

Нужно ли специалисту data science становиться ML-инженером?

Короткая версия доклада:


В ходе бесед со специалистами data science, аналитиками и разработчиками часто возникает вопрос: нужно ли им становиться ML-инженерами, как найти своё место на быстрорастущем IT-рынке? Специалисты data science, или аналитики, обладают компетенцией и техническими знаниями для работы с аналитическими данными, статистическим анализом, математическими моделями, большими данными. Схожим образом, ML-инженеры, или разработчики, также работают с данными, на основании которых выдвигают гипотезы и строят модели, однако, в отличие от первой группы, они также умеют писать production code.

Переход аналитика в разработчики дает компании то преимущество, что она получает универсального специалиста, что особенно важно для стартапов и небольших компаний. Однако и для крупных корпораций выгодно, чтобы кругозор её сотрудников постоянно расширялся за счет получения новых компетенций. В случае, когда аналитик, не будучи профессионалом в знании алгоритмов, пытается писать какой-то код, высока вероятность ошибки, что чревато большими потерями для компании. Кроме того, очевидно, что чем больше разделены функции внутри компании, тем сильнее снижается скорость реализации проектов.

На этапе production, если аналитик не знаком с ограничениями, характерными для этой стадии, то он рискует потерять время на ненужные эксперименты и представить разработчикам модели, которые физически не могут работать. Без знания основ написания production code этого очень трудно достичь.

В тех компаниях, где разделены функции data science и разработки, аналитики обычно получают данные от разработчиков. В процессе работы может выясниться, что полученные данные не полные, и их необходимо возвратить разработчикам, что увеличивает время реализации проекта. Далее, после построения модели, она поступает к разработчикам для внедрения и на этом этапе неизбежно сталкивается с ограничениями, характерными для этапа production, и уходит на доработку. Таким образом, процесс внедрения проходит через множество итераций, и результат получается либо неидеальным, либо он реализуется позже намеченного срока.

Аналитик, переходя в разработчики, получает возможность самостоятельно придумывать логику решений своих задач, принимать правильные решения относительно используемых инструментов для анализа данных, или же создавать собственные инструменты, тем самым максимально расширяя свои возможности. Стоит также учесть, что количество актуальных вакансий для разработчиков гораздо больше, чем у аналитиков.

Есть несколько способов перейти из аналитиков в разработчики. Первый – прохождение практических курсов, ШАД или Coursera. Также весьма полезно получение практических навыков программирования. Наконец, после получения теоретических знаний и самостоятельных практических занятий, наступает этап проверки знаний путем участия в конкурсах.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Билеты

Показать
цену в
$
Видеозапись
Доступ к записям всех докладов
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Организатор

Яндекс
http://fronttalks.ru/

Организационный комитет: Яндекс,

Похожие мероприятия

25 апреля 2018
Докладов 13
Просмотров 0
HR, аналитика, Бизнес, Кадры, Компания, обучение, Развитие, Рост, Стартап, Управление
4-5 апреля 2018
Докладов 39
Просмотров 90
CRM, HR, HR-tech, Автоматизация, аналитика, Инновации, Ит, Кадры, Маркетинг, Продукт, Рекрутмент, Технологии, Электронный документооборот
6 апреля 2018
Докладов 7
Просмотров 1
Agile, Бизнес, Гибкоть, Мотивация, Проект, Процессы, Развитие, Управление
показать еще