Взгляд аналитика данных на наш процесс

Недавно один из стартапов, с которыми я консультируюсь (BigPanda), попросил меня высказать свое мнение о структуре и потоке проектов в области науки о данных, что заставило меня задуматься о том, что делает их уникальными. И менеджеры, и разные команды в стартапе могут посчитать разницу между проектом по науке о данных и разработкой программного обеспечения неинтуитивной и запутанной. Если не указывать и не учитывать явным образом, эти фундаментальные различия могут вызвать недопонимание и столкновения между специалистом по обработке данных и ее коллегами.

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

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

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

Я разделил этот процесс на три аспекта, которые выполняются параллельно: продукт, наука о данных и инженерия данных. Во многих случаях (включая большинство мест, в которых я работал), может не быть инженера по обработке данных, который бы выполнял эти обязанности. В этом случае специалист по анализу данных обычно отвечает за работу с разработчиками, чтобы помочь с этими аспектами. В качестве альтернативы, специалист по анализу данных может провести эти приготовления, если они окажутся самыми редкими из всех зверей Бога: специалист по полному стеку данных! ✨🦄✨. Таким образом, вы можете заменить инженера данных на специалиста по данным всякий раз, когда он упоминается , в зависимости от вашей среды.

На временной оси я разбил процесс на четыре отдельных этапа:

  1. Определение объема
  2. Исследовать
  3. (Модель) Разработка
  4. Развертывание

Я постараюсь провести вас по каждому из них по порядку.

1. Этап оценки

Определение объема проекта по науке о данных имеет большее значение, чем для любого другого проекта.

1.1. Потребность в продукте

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

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

1.2. Идея первоначального решения

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

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

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

1.3. Подготовка и доступность данных

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

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

1.4. Объем и ключевые показатели эффективности

На этом этапе необходимо вместе принять решение о масштабах и ключевых показателях эффективности проекта.

KPI должны быть определены в первую очередь с точки зрения продукта, но гораздо более подробно, чем раньше; например Что касается трех вышеупомянутых потребностей в продуктах, они могут стать «теперь клиенты могут использовать информационную панель со статистикой CTR и прогнозами по категориям», или «будет сокращено количество пропущенных лекарств для пользователей старше 65 лет. не менее чем на 10% в течение следующих двух кварталов » или « клиенты будут получать еженедельные прогнозы часов пик в своих аэропортах с детализацией не менее часа и приблизительной точностью не менее ± 50% ».

Затем эти KPIS следует преобразовать в измеримые метрики модели. Если повезет, это будут очень точные показатели, такие как «прогнозирование ожидаемого CTR объявления с приближением не менее X% в не менее Y% случаев для любого объявления, которое показывается не менее недели, и для любого клиента с историческими данными более двух месяцев ». В некоторых случаях, однако, придется использовать более мягкие метрики, такие как «время, необходимое для изучения темы с использованием сгенерированных расширенных запросов, будет сокращено и / или качество результатов улучшится по сравнению с исходными запросами» . Это особенно верно, когда модель предназначена для выполнения некоторых сложных функций человека.

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

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

Ограничение области действия 1: я считаю более продуктивным явное ограничение области действия; например, если вы решили, что модель, основанная на многоруком бандите, является наиболее многообещающим подходом для начала, вы можете определить объем проекта как одну двух-трехнедельную итерацию разработки модели, развернув модель независимо от ее точности. (например, если оно превышает 60%). Затем, если повышение точности ценно (в некоторых случаях может оказаться меньше), разработку второй модели можно рассматривать как отдельный проект.

Ограничение объема 2: Еще один вариант ограничения объема - использование возрастающей степени сложности; например, первый проект может быть направлен на развертывание модели, которая должна только предоставить довольно большой набор кандидатов рекламной формулировки и цветовых вариаций для ваших собственных людей, занимающихся успехом клиентов, с которыми можно будет работать; второй может попытаться построить модель, которая дает меньший набор предложений, которые покупатель может увидеть сама; и последний проект может попытаться создать модель, которая выделяет один вариант, ставит еще несколько ниже и добавляет прогнозы CTR и демографический охват для каждого варианта.

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

Тем не менее, функция «метрика-значение продукта» может быть ступенчатой ​​функцией, а это означает, что любая модель, работающая при некотором значении X, бесполезна для покупателя; в этих случаях мы предпочтем повторение до тех пор, пока этот порог не будет подавлен. Однако, хотя в некоторых случаях этот X может быть очень высоким, я считаю, что как специалисты по продуктам / бизнесу, так и специалисты по обработке данных склонны переоценивать высоту этого шага; очень легко заявить, что что-либо с точностью менее 95% (например) не имеет ценности и не может быть продано. Однако во многих случаях тщательное изучение и оспаривание предположений о продукте может привести к получению очень ценных продуктов, которые могут быть не такими требовательными с технической точки зрения (по крайней мере, для первой итерации продукта).

1.5. Утверждение объема работ и ключевых показателей эффективности

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

Общие замечания по анализу объема работ

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

2. Этап исследования

2.1. Исследование данных

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

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

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

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

2.2. Обзор литературы и решений

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

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

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

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

Например, если производственная среда поддерживает развертывание кода Java и Scala только для внутреннего использования, и, таким образом, ожидается, что решение будет предоставлено на языке JVM, специалисту по данным придется глубже изучить реализации на основе Python, которые он обнаружил даже во время этого исследования. Этап, так как переход к этапу разработки модели влечет за собой их перевод на язык JVM.

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

2.3. Проверка технической достоверности

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

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

2.4. Обзор исследований

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

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

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

2.5. Проверка объема работ и ключевых показателей эффективности

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

3. Этап разработки

3.1. Настройка фреймворка для разработки моделей и экспериментов

Объем и сложность настройки, необходимые для начала разработки модели, в значительной степени зависят от инфраструктуры и объема технической поддержки, доступной специалистам по данным. В небольших местах и ​​местах, которые еще не используются для поддержки исследовательских проектов в области науки о данных, установка может сводиться к тому, что специалист по данным открывает новый репозиторий кода и запускает локальный сервер Jupyter Notebook или запрашивает более мощную облачную машину для выполнения вычислений.

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

3.2. Разработка модели

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

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

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

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

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

Этот сквозной подход может занять больше времени для настройки, и каждая итерация по типам и параметрам модели требует больше времени для тестирования, но это экономит время, которое позже оплачивается на этапе продуктивности.

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

3.3. Модельный тест

При разработке модели различные ее версии (и сопровождающий ее конвейер обработки данных) должны постоянно проверяться на соответствие заранее определенной жесткой метрике (ам). Это дает приблизительную оценку прогресса, а также позволяет специалисту по обработке данных решить, когда модель, по-видимому, работает достаточно хорошо, чтобы гарантировать общую проверку KPI. Обратите внимание, что это может вводить в заблуждение, поскольку, например, получить от 50% до 70% точности во многих случаях намного проще, чем получить точность от 70% до 90%.

Когда тесты показывают, что модель не соответствует требованиям, мы обычно исследуем ее и ее результаты, чтобы внести улучшения. Иногда, однако, разрыв в производительности очень велик, когда разные варианты выбранных направлений исследований все терпят неудачу - неудачный подход. Это может служить основанием для изменения направления исследований, возвращая проект в фазу исследования. Это аспект проектов в области науки о данных, с которым труднее всего согласиться: вполне реальная возможность отката.

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

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

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

3.4. Обзор разработки модели

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

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

3.5. Проверка КПЭ

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

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

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

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

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

Когда специалист по продукту убежден, что модель отвечает заявленным целям проекта (в удовлетворительной степени), команда может перейти к ее производству.

4. Этап развертывания

4.1. Создание решений и настройка мониторинга

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

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

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

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

Мониторинг: наконец, настраивается способ постоянного мониторинга производительности модели; в редких случаях, когда источник производственных данных постоянен, это можно смело пропустить, но я бы сказал, что в большинстве случаев вы не можете быть уверены в стабильности распределения исходных данных. Таким образом, настройка такой проверки производительности может помочь нам не только обнаружить проблемы в модели, которые мы могли упустить во время разработки и продуктивности, но, что более важно, изменения в распределении исходных данных, над которыми работает модель - обычно называемые ковариативный сдвиг - который может со временем ухудшить производительность идеально хорошей модели.

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

4.2. Развертывание решения

Если все настроено правильно, то этот этап, как мы надеемся, можно свести к нажатию кнопки для развертывания новой модели - и любого кода, обслуживающего ее, - в производственной среде компании.

Частичное развертывание. Однако возможно, что для проверки эффективности модели (например, для сокращения оттока или увеличения среднемесячных расходов на пользователя) модель будет развернута в таким образом, чтобы ему подвергалась только часть пользователей / клиентов. Это позволяет напрямую сравнивать влияние на любые измеримые KPI между двумя (или более) группами в базе пользователей.

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

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

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

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

Например, в случае обновления устройства пользователи, обновившие свои приложения / прошивки раньше, обычно попадают в определенную демографическую группу (моложе, технически подкованы, выше доход и т. Д.).

4.3. Проверка КПЭ

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

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

4.4. Решение доставлено

Пользователи и покупатели довольны. Людям, работающим с продуктом, удалось создать или адаптировать продукт, который они хотели, в соответствии с моделью. Были сделаны. Поджарены тосты, раздаются аплодисменты, и все в порядке.

Решение доставлено, и на этом я бы назвал проект выполненным. Однако он продолжает жить особым образом - обслуживанием.

Обслуживание

Настроив проверки работоспособности и непрерывный мониторинг производительности для модели, они могут вызвать короткие всплески работы над проектом.

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

Заключительные слова

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

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

Если хотите еще раз взглянуть на эту тему, я рекомендую прочитать сообщение моего друга Ори о гибкой разработке для науки о данных. Я также хотел бы поблагодарить Инбара Наора, Шира Меира Ладора (@DataLady) и @seffi .cohen за их отзывы.

Шэй - консультант по науке о данных. Также он работает над некоторыми общественными проектами.