Data Science в реальном мире, B otXO

Ученый-прагматик

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

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

TL; DR (краткое изложение 5 идей):

  1. В первом понимании «Искусственный интеллект - движущаяся цель» я смотрю, как на индустрию ИИ влияет тот факт, что не существует четкого определения того, что такое ИИ. Я утверждаю, что из-за нечетких определений того, что составляет систему ИИ, маркетологи, а не инженеры решают, что будет называться «ИИ».
  2. Во втором понимании «Инженерное дело - узкое место» я утверждаю, что подавляющему большинству компаний нужны инженеры ИИ, а не ученые ИИ. Это связано с тем, что большинству компаний лучше разрабатывать прагматические решения на основе существующих исследований, чем проводить собственные исследования. Я также обсуждаю твердые инженерные принципы, которые могут создать или сломать промышленные системы искусственного интеллекта.
  3. В третьем понимании «Удержание предпочтительнее индукции» я утверждаю, что важно создавать простые решения, прежде чем открывать большие пушки. Создание простых решений имеет ряд желаемых свойств, таких как обеспечение хорошей базы и простота обслуживания. Я утверждаю, почему специалисты по данным должны отдавать предпочтение нисходящему подходу восходящему подходу и стремиться разработать независимое от данных решение, когда это возможно.
  4. В четвертом разделе «Манипулируйте уравнением проблема-модель-данные-метрика» я подробно рассказываю о том, что отличает прагматическую науку о данных в отрасли от академической и конкурентной науки о данных. Я утверждаю, что, поскольку промышленные инженеры могут изменять больше переменных уравнения, они должны владеть широким спектром навыков, от методов сбора данных до управления заинтересованными сторонами.
  5. В пятом понимании «Разработка означает правильный выбор» я утверждаю, что прагматичные инженеры должны найти баланс между различными противоположными желательными свойствами любого решения. Я объясняю, чем конечные цели промышленных групп по обработке и анализу данных отличаются от целей академических и конкурентных групп по обработке и анализу данных.

Эти идеи изначально были размещены на https://www.botxo.co/blog/.

Обсудить в Hacker News: https://news.ycombinator.com/item?id=20261274

1. понимание: искусственный интеллект - движущаяся цель

В отрасли искусственный интеллект - это то, чем вы хотите. Усвоение этого понимания поможет вам ориентироваться в пространстве AI-стартапов и проектов.

Что такое ИИ?

Искусственный интеллект определяется как любая компьютерная система, демонстрирующая «интеллект». Поскольку у нас нет формального определения того, что представляет собой интеллект, возможности ИИ постоянно меняются. Наше представление о том, что представляет собой интеллектуальная компьютерная система, формируется нашим восприятием человеческого интеллекта. Таким образом, компьютерная система кажется искусственно интеллектуальной, если она:

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

Почему определение такое неточное?

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

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

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

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

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

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

Последствия нечеткого определения

Это расплывчатое определение ИИ оставляет место для множества интерпретаций, что имело некоторые интересные последствия в отрасли.

  1. Начинающие специалисты по данным должны четко понимать расхождения между академической и практической, промышленной терминологией. По словам Рэйчел Томас из fast.ai, одна из самых частых жалоб специалистов по данным заключается в том, что они не могут создавать системы искусственного интеллекта, потому что компании, в которой они работают, требуется базовая цифровизация, а не продвинутое машинное обучение. Поэтому при изучении возможностей трудоустройства важно убедиться, что ваш талант соответствует реальным потребностям организации, а не бренду (внешнему и / или внутреннему).
  2. Менеджеры, которые хотят расширить свою команду по анализу данных, должны быть хорошо осведомлены об актуальных проблемах, которые необходимо решить новым ролям в области обработки данных. Как я утверждаю во втором понимании: Инженерное дело - это узкое место, потребность в инженерах в машинном обучении часто превышает потребность в ученых, занимающихся данными. Менеджеры также должны опасаться кандидатов, которые используют новизну области, чтобы выдать себя за более высокий пост, чем на самом деле. Подробно эта тенденция описана здесь и здесь.
  3. Как широко известно в отрасли: инвесторы, желающие вскочить на поезд искусственного интеллекта, слишком легко продают решения, которые просто называются интеллектуальными.

Любопытный случай с РПА

В качестве примера программного обеспечения, которое было переименовано в Искусственный интеллект, рассмотрим программное обеспечение Robotic Process Automation (RPA). Системы RPA - это настольные приложения, которые позволяют непрограммистам автоматизировать бизнес-задачи, создавая макросы на уровне рабочего стола. Автоматизация на уровне рабочего стола существует уже много лет (приложение Automator.app поставляется с macOS с 2005 года).

Переименовав макросы уровня настольных компьютеров в «Роботы» («R» в RPA), отрасль извлекает выгоду из недавнего ажиотажа в области ИИ. Поскольку большинство непрограммистов работают на уровне настольных компьютеров, RPA считается инструментом для замены интеллектуальных работников, что приводит к тому, что цены на лицензии на программное обеспечение конкурируют с заработной платой.

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

ИИ - это то, что вы хотите

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

2. Понимание: надежная инженерия - это узкое место, потому что сложность накапливается.

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

Беспорядок в инженерном деле

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

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

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

Программная инженерия похожа на обслуживание коробки проводов

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

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

Ценность обширных знаний

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

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

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

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

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

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

Нехватка разработчиков

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

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

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

Заключение

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

3. Проницательность: дедуктивное рассуждение предпочтительнее индуктивного.

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

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

Букварь по философии логики

Есть два способа обосновать любую проблему.

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

Учитывая посылку «Сократ - человек» и принцип «Все люди смертны», мы можем вывести знание «Сократ смертен».

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

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

В контексте программного обеспечения

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

Например, y = 2 * x - это общее правило, которое может обрабатывать все виды конкретных экземпляров x.

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

Вместо того, чтобы писать y = 2 * x, мы предоставляем компьютеру конкретные примеры (например, «Если x равно 3, то y равно 6») и используем алгоритмы машинного обучения для построения общеприменимых моделей.

Стек программного обеспечения 2.0

Андрей Карпати, директор по искусственному интеллекту в Tesla, ввел термин Software Stack 2.0 для описания того, что я люблю называть индуктивным программированием. Я предпочитаю термин индуктивное программирование, потому что, в отличие от программного обеспечения 2.0, он не означает, что этот тип программирования превосходит дедуктивное программирование (также известное как программное обеспечение 1.0).

Я считаю, что терминология «программное обеспечение 1.0 и 2.0» является результатом недавнего ажиотажа вокруг ИИ. Выбор между дедуктивным и индуктивным программированием должен зависеть от решаемой проблемы и доступных инструментов - один не превосходит другой.

Минусы

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

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

К недостаткам можно отнести:

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

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

Поэтапный подход

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

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

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

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

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

Заключение

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

4. Понимание: манипулируйте уравнением "проблема-модель-данные-метрика".

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

Промышленные, академические и конкурентоспособные специалисты по данным

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

4 компонента решения для обработки данных

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

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

Примером описания проблемы может быть: «Учитывая предложение из юридического документа, определите, насколько вероятно, что предложение содержит конфиденциальную информацию».

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

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

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

Как манипулировать каждым компонентом уравнения

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

Управление проблемой

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

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

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

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

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

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

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

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

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

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

3. Решение проблемы с более легким заменителем
Первоначальная проблема может быть настолько сложной, что вы не можете достичь достаточной производительности. Таким образом, вы должны довольствоваться решением менее сложной проблемы.

Управление метрикой

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

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

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

Рассмотрим метрику, используемую для оценки POS-тегировщиков. Стандартной метрикой является точность на уровне слов, а современные решения достигают впечатляющей точности ~ 95% для английского языка. Однако 95% -ная точность на уровне слов означает, что 1 из 20 слов классифицируется неправильно. В результате каждое второе предложение представляет собой текст, содержащий неверно классифицированное слово. Учитывая, сколько слов имеет однозначные POS-теги, качество исполнения не кажется таким впечатляющим.

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

Нестандартные показатели могут быть созданы как взвешенная комбинация:

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

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

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

Манипулирование моделью

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

В академических кругах предпочтительны простые модели, потому что они обычно применимы.

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

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

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

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

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

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

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

Манипулирование данными

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

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

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

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

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

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

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

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

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

  • Поиск дополнительных данных из открытых общедоступных источников.
  • Аннотирование данных внутри. Часто экономия от ручной маркировки данных окупается.
  • Написание хорошего описания аннотации и использование оплачиваемых человеческих услуг, таких как Mechanical Turk.
  • Создание графических пользовательских интерфейсов для аннотации данных и стимулирование пользователей к выполнению маркировки.

Преимущества знания разницы между разными типами науки о данных

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

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

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

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

Заключение

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

5. Понимание: инженерное дело - это правильный выбор.

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

6 вариантов, которые стоит рассмотреть

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

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

  1. Производительность. Производительность модели в наборе оценочных данных, рассчитанная по метрике.
  2. Возможности. Желательные свойства, такие как быстрое время прогнозирования, быстрое время обучения, легкость интерпретации результатов и доверительные интервалы, являются примерами функций.
  3. Время разработки: время, необходимое для разработки решения.
  4. Время оборота: время, необходимое для поддержания решения путем внесения корректировок.
  5. Вычислительные требования: требования к хранилищу, памяти, ЦП, графическому процессору и TPU.
  6. Требования к навыкам: уровень образования, необходимый специалистам по обработке данных, чтобы внести свой вклад в решение. Использование необычных технологий потребует времени для переподготовки новых специалистов по обслуживанию.

Сделайте акцент на правильных свойствах

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

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

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

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

1. Производительность

(Требуется / Фактически), Академический: (9/9), Kaggle: (10/10), Отрасль: (7/9)

Производительность находится в центре внимания всех трех контекстов.

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

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

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

2. Особенности

(Требуется / Фактически), Академический: (6/5), Kaggle: (0/0), Отрасль: (6/4).

Характеристики представляют собой своего рода всеобъемлющую категорию, охватывающую ряд желаемых свойств.

В соревнованиях особенности не имеют значения.

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

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

Возможности проектов по науке о данных включают:

  • Быстрое время обучения.
  • Быстрое время предсказания.
  • Общая применимость.
  • Нулевая ошибка обучения.
  • Интерпретируемость результатов.
  • Доверительные интервалы.
  • Новизна решения (очень важно для академических кругов)
  • Возможность запуска на устройстве. Возможность работать с зашифрованными данными.

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

3. Время разработки

(Необходимые / Фактические), Academic: (7/7), Kaggle: (7/7), Industry: (5/8).

Ученые и особенно соискатели сталкиваются с жесткими ограничениями по времени разработки.

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

4. Время оборота

(Требуется / Фактически), Академический: (3/2), Kaggle: (2/1), Промышленность: (10/5).

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

5. Вычислительные требования.

(Необходимые / Фактические), Академические: (2/2), Kaggle: (1/1), Отраслевые: (2/5).

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

6. Требования к навыкам

(Необходимое / Фактическое), Academic: (1/1), Kaggle: (2/2), Industry: (6/3).

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

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

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

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

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

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

Заключение

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

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

Эти идеи изначально были опубликованы на https://www.botxo.co/blog/.