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

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

жаргон

Начнем с установления некоторой номенклатуры:

Система: реальная система интересов, например, в страховой компании — полис, претензия или водитель

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

Состояние: значение набора свойств в модели данных в заданный момент времени

Переменная-предиктор: одно из потенциально многих свойств состояния, которое можно использовать для предсказания других свойств состояния или будущего состояния

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

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

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

Модель науки о данных: модель, которая принимает переменные-предикторы и возвращает прогнозы ("Наука о данных" является избыточной, но она используется для устранения неоднозначности слова "модель" в этом блоге).

Принципы

В этом разделе я представлю шесть принципов хранения данных глазами специалиста по данным.

Принцип 1. Четко разграничивайте пустые ярлыки и ярлыки по умолчанию

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

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

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

Эти примеры иллюстрируют лишь несколько случаев нарушения этого принципа.

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

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

Вместо этого часто используется один из двух альтернативных подходов:

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

Принцип № 3. Разработайте свои системы таким образом, чтобы они допускали выравнивание по мере поступления.
В страховых науках фраза «выравнивание по мере поступления» относится к применению новой модели ценообразования к историческим решениям по андеррайтингу. Полученные данные позволяют нам задавать контрфактические вопросы, например: «Что, если бы у нас была последняя модель ценообразования для пользователей?» Это важный процесс для сравнительного анализа новых моделей науки о данных.

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

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

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

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

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

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

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

Принцип № 5. Сокращение несанкционированного хранения данных
Без правильных технологий и предоставленных самим себе, многие технические и не технические специалисты в предметной области будут прибегать к использованию собственных децентрализованных механизмов для компиляции данных. (чаще всего таблицы). Хотя это лучше, чем ничего, эти механизмы имеют тенденцию порождать низкое качество, отсутствующие записи, несогласованные схемы, неструктурированные поля и т. д. Они также отнимают много времени. Наконец, с ними неудобно работать, особенно когда хочется соединить их с другими записями.

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

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

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

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

  1. Если правило А выполнено, остановитесь и откажитесь.
  2. Если нет, заплатите за отчет. На основании отчета, если правило B выполнено, остановитесь и откажитесь.
  3. Если нет, запустите модель А. Если прогноз модели А превышает пороговое значение, остановитесь и отклоните.
  4. Если нет, запустите модель B. Если прогноз модели B превышает пороговое значение, запросите проверку андеррайтером-человеком.
  5. Если нет, примите.

В этом примере генерация прогноза с помощью модели A сериализуется по правилу A и правилу B. Сериализация правила B по правилу A — хитрый маневр, поскольку мы обходим затраты на отчеты. Но что, если вычислительная стоимость модели A тривиальна? Мы упустили возможность сгенерировать прогноз, который можно было бы использовать для диагностики или построения будущей модели (см. принцип №3).

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

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

это обертка

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

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

Если вы хотите узнать больше о Root Insurance, посетите сайт joinroot.com или свяжитесь со мной в LinkedIn.