Повышение защищенности вашей работы от ошибок с помощью экспертной оценки

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

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

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

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

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

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

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

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

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

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

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

Обзор этапа исследования данных

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

Обратите внимание, что на данном этапе выполняются три типа проверок для подтверждения правильности выбора подхода:

  1. Проверка технической достоверности, которая часто проводится вместе с инженерами по данным / программному обеспечению, поддерживающими проект, предназначена для того, чтобы гарантировать, что предлагаемый подход может быть успешно внедрен и поддержан инженерами.
  2. Обзор исследования, в котором коллега помогает специалисту по обработке данных проверить свой процесс и рекомендации. Мы поговорим об этом чуть позже.
  3. Проверка объема и достоверности KPI, проводимая с ответственным лицом, ответственным за продукт, чтобы убедиться, что рекомендуемый подход остается в рамках проекта и, похоже, соответствует KPI проекта.

Мотивация

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

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

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

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

Цели

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

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

Состав

Подготовка к обзору состоит из трех шагов:

  1. Специалист по анализу данных готовит презентацию (не обязательно слайды) о процессе исследования, через который он прошел.
  2. Специалист по анализу данных назначает длительную встречу (не менее 60 минут; в прошлый раз это заняло два часа) с рецензентом.
  3. Рецензент просматривает контрольный список (перед встречей).

В своем выступлении аналитик пытается затронуть следующие семь пунктов:

  1. Напоминание: объем проекта и потребности в продукте.
    Всегда начинайте с этого момента, поскольку основной задачей проверки является оценка того, насколько хорошо выполняется процесс и насколько хорошо сделанный выбор соответствует масштабам и потребностям проекта.
  2. Первоначальные рекомендации и KPI.
    Во многих случаях это будет первый раз, когда проверяющий DS увидит перевод потребностей продукта в технические KPI, и это хороший шанс подвергнуть это коллегиальной проверке. Покройте характеристики проблемы и ограничения.
  3. Сделанные предположения.
    Мы все делаем серьезные предположения о таких вещах, как формат данных, доступность, допустимые ошибки и типичные шаблоны использования продуктов. Сделайте их явными.
  4. Используемые данные и способы их изучения.
    Результаты исследования данных могут оправдать как некоторые предположения, так и выбор подхода, который будет представлен, поэтому представьте их четко.
  5. Список возможных подходов / решений.
    Первый важный результат фазы исследования: карта ландшафта решений с подробным описанием плюсов и минусов каждого из них, включая предположения, а также, возможно, с изображением источников и отношения между ними, если это необходимо.
  6. Избранный подход и обоснования.
    Ваша рекомендация. Это наиболее важный результат этого этапа, но помните, что для построения маршрута вы должны сначала иметь карту. Контекст, предоставляемый ландшафтом решения, должен позволить вам объяснить выбор рецензенту, а также исключить альтернативы.
  7. Какие возможные неудачи приведут к альтернативному выбору?
    Я считаю, что этот продукт этапа исследования, о котором часто забывают, не менее важен, чем ваша рекомендация. Теперь вы подкрепляете его планами на случай непредвиденных обстоятельств, прямо рассказывая о том, как можно хеджировать и учесть неотъемлемый риск исследовательского проекта.

Наконец, вот предлагаемая структура обзорной встречи:

  1. DS на рассмотрении: презентация фазы исследования
  2. Рецензент: общий отзыв
  3. Рецензент: изучение контрольного списка (см. ниже)
  4. Рецензент: одобрить или отклонить
  5. Вместе: итоговые очки действий

Контрольный список

Список сосредоточен на вопросах, которые следует решить на этапе исследования. Я разделил его на десять категорий:

  1. Свойства данных
  2. Допущения подхода
  3. Прошлый опыт
  4. Объективное выравнивание
  5. Реализация
  6. Масштабирование
  7. Композиция- / Разрывная способность
  8. Требования к информации
  9. Адаптация домена
  10. Устойчивость к шуму / смещению / отсутствию данных

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

Свойства данных

Что касается исходного набора данных:

  • Как был сгенерирован? Как это было отобрано? Было ли оно обновлено?
    Например, 10% данных за последний месяц были взяты равномерно от каждого из пяти существующих клиентов.
  • Какой шум, смещение выборки и недостающие данные это привело?
    Например, один из клиентов интегрировался с нашим сервисом только две недели назад, что привело к смещению его данных в наборе данных.
  • Можете ли вы изменить выборку / генерацию, чтобы уменьшить или устранить шум? Систематическая ошибка выборки? Отсутствуют данные?
    Например, либо увеличьте выборку клиента с недостаточной выборкой в ​​два раза, либо используйте данные только за последние две недели для всех клиентов.
  • Можете ли вы явно смоделировать шум независимо от подхода?
  • Если набор данных помечен, как он был помечен?
  • Какое предубеждение в отношении ярлыков это привнесло? Можно ли его измерить?
    Например, ярлык может исходить от невнимательных пользователей. Маркировка очень небольшого (но репрезентативного) набора вручную с привлечением экспертов / аналитиков может быть легко управляемой и позволит нам измерить смещение / ошибку ярлыка на этом наборе.
  • Можете ли вы изменить или дополнить процесс маркировки, чтобы компенсировать существующую предвзятость?
  • Насколько похож исходный набор данных на входные данные, ожидаемые при производстве, структуре и схеме?
    Например, содержание некоторых элементов динамически изменяется в процессе производства. Или, возможно, отсутствуют разные поля, в зависимости от времени создания или исходного домена, и позже они заполняются или экстраполируются.
  • Насколько репрезентативен исходный набор производственных данных?
    Например, Распределение данных среди клиентов постоянно меняется. Или, возможно, это было сделано в течение двух месяцев весны, но модель вырастет, когда начнется зима. Или он мог быть собран до того, как был интегрирован основной клиент / служба / источник данных.
  • Каков наилучший набор обучающих данных, на который вы могли бы надеяться?
    - Определите его очень четко.
    - Оценка: насколько это улучшит производительность?
    - Насколько это возможно и дорого стоит?
    Например пометьте тональность 20 000 сообщений, используя три аннотатора, и укажите в качестве ярлыка для каждого из них режим / средний балл. Для этого потребуется 400 человеко-часов, которые, как ожидается, обойдутся в две-три тысячи долларов и, как ожидается, увеличит точность как минимум на 5% (это число обычно чрезвычайно сложно предоставить).

Допущения подхода

  • Какие предположения делает каждый подход в отношении данных / процесса генерации данных / изучаемого явления?
  • Разумно ли делать такие предположения о вашей проблеме? В какой степени?
  • Как вы ожидаете, что применимость будет связана с нарушением этих предположений? Например. Нарушение 10% → снижение производительности на 10%?
  • Можно ли проверить эти предположения независимо?
  • Какие-нибудь крайние / угловые случаи, нарушающие эти предположения?

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

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

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

Вот несколько примеров некоторых очень сильных и обычно неявных предположений, которые делают подходы:

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

Прошлый опыт

  • Какой у вас есть опыт применения этого подхода в целом или к аналогичным проблемам?
  • Находили ли вы какие-либо опубликованные (например, в блоге или статье) истории успеха / неудач применения этого подхода к аналогичным проблемам?
  • Вы обращались к коллегам за их опытом?
  • Какие уроки можно извлечь из вышеизложенного?
  • Если этот проект представляет собой попытку повторить и улучшить существующее решение: какие решения использовались для решения этой проблемы до сих пор? В чем были их преимущества и от каких проблем они страдали?

Целевое соответствие

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

  • Какие функции потерь можно использовать при подборе параметров модели? Как они соотносятся с ключевыми показателями эффективности проекта?
  • Какие метрики можно использовать для выбора модели / оптимизации гиперпараметров? Как они соотносятся с ключевыми показателями эффективности проекта?
  • Какие жесткие ограничения следует добавить, чтобы отразить KPI?

Для методов обучения без учителя:

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

Для обучения репрезентации без учителя:

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

Реализация

  • Есть ли реализации этого подхода на языке, который в настоящее время используется в вашей производственной среде?
  • Актуальна ли реализация? Постоянно поддерживается? Широко используется?
  • Есть ли успешное использование этой конкретной реализации компаниями / организациями, аналогичными вашей? По проблемам, похожим на вашу?

Масштабирование

  • Как время вычислений / обучения зависит от количества точек данных?
  • С количеством функций?
  • Как хранилище масштабируется с точками данных / функциями?

Способность сочинять / ломать

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

Пример. Предположим, мы работаем над системой создания тематических динамических списков воспроизведения как часть службы потоковой передачи музыки. Это означает, что мы хотим автоматически создавать и обновлять плейлисты по таким темам, как «Новая инди», «Британская новая волна», «Феминистская музыка» или «Веселые песни о любви». Для дополнительной сложности мы также можем разрешить создание плейлистов для комбинаций тем, например «Феминистская новая волна» или «Новая мрачная инди». Или, возможно, мы хотим иметь возможность персонализировать каждый список воспроизведения для слушателя. В конце концов, если у нас есть модель, которая ранжирует песни для включения в тематический список воспроизведения, и другая персонализированная модель, которая ранжирует песни по тому, насколько вероятно, что они понравятся конкретному пользователю, мы можем захотеть объединить результаты двух таких моделей.

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

Требования к информации

  • В какой степени каждый подход зависит от объема доступной информации? Каково ожидаемое влияние на производительность небольших объемов информации?
  • Соответствует ли это объему доступной в настоящее время информации? С будущей доступностью?

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

Холодный старт и адаптация домена

  • Насколько быстро ожидается, что новые клиенты / категории / страны / домены достигнут минимальных информационных требований для каждого подхода?
  • Можно ли ожидать, что общая модель будет для них хорошо работать, по крайней мере, в качестве отправной точки?
  • Есть ли способ адаптировать уже подобранную модель к новой области? Ожидается ли, что это даст лучшую производительность, чем тренировка с нуля? Можно ли это сделать быстрее / дешевле, чем обучение с нуля?

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

Устойчивость к шуму / смещению / отсутствию данных

Устраняет ли подход шум в данных? Как?

  • Он его конкретно моделирует?
  • Если да, подумайте: насколько применима модель шума к процессу генерации шума в вашей проблеме?
  • Для аномалий / прогнозов / причинности / динамики: моделирует ли подход экзогенные переменные в системе?

Для контролируемых и частично контролируемых методов:

  • Насколько чувствителен каждый подход к предвзятости в маркировке?
  • Каковы последствия необъективной модели в вашем случае?
  • Применимы ли к этому подходу общие методы коррекции смещения?

Для всех методов:

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

Обзор этапа разработки модели науки о данных

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

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

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

Мотивация и цели

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

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

Состав

Подготовка обзора состоит из трех простых шагов:

  1. Специалист по анализу данных готовит презентацию (не обязательно слайды) о процессе разработки модели.
  2. Специалист по анализу данных назначает тщательную встречу (не менее 60 минут) с исследователем данных.
  3. Проверяющий DS просматривает контрольный список (перед встречей).

Проверяемый специалист по анализу данных должен осветить следующие моменты в своей презентации:

  1. Напоминание: объем проекта и потребность в продукте
  2. Выбранный подход после фазы исследования
  3. Метрические + мягкие и жесткие ограничения для выбора модели
  4. Используемые данные, предварительная обработка и разработка функций
  5. Рассмотренные модели, режим тренировки, оптимизация гиперпараметров.
  6. Выбранная модель, альтернативы и плюсы / минусы каждой.
  7. Следующие шаги: автоматизация, производство, оптимизация производительности, мониторинг и т. Д.

Такая же структура предлагается здесь для обзорной встречи:

  1. Проверенная DS: презентация фазы разработки модели
  2. Рецензент: общий отзыв
  3. Рецензент: изучение контрольного списка (см. ниже)
  4. Рецензент: одобрить или отклонить
  5. Вместе: итоговые очки действий

Контрольный список

И снова Филип Таннор создал контрольный список вопросов и проблем для использования при рассмотрении фазы разработки модели, разделенный на следующие категории:

  • Допущения в отношении данных
  • Предварительная обработка
  • Утечка
  • Причинно-следственная связь
  • Метрика убытков / оценки
  • Переоснащение
  • Время выполнения
  • Глупые ошибки
  • Тривиальные вопросы

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

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

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

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

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